Topic: Rapid Brickset Editor 2 (working beta!), Oct 1st.

Here's the thing I've been working on: cool

http://opensnc.sourceforge.net/rbe2 (new URL!)

RBE2 is a simple brickset editor like it's predecessor, but (we hope) with much better usability.

This is a public, working beta. It can be used by anyone, although it may contain a few bugs.

----------------

Update at: October 1st, 2012.
* It's now possible to change the brickset image in use.
* One can now create new bricksets. Bricksets are properly saved on the server, so you can resume your work at a later date.

Please remember to clear your cache (if you haven't), or simply press Ctrl+F5 after loading the program.

----------------

Update at: October 1st, 2012.
* RBE2 now supports brick layers. Pretty sweet stuff.

Important missing features are: the ability to create new bricksets and the ability to change the brickset image currently in use.

----------------

Update at: September 30th, 2012.
* the state of the brickset is now saved on the server. Try messing around with the bricks and refreshing RBE2.
* RBE2 now generates proper .brk's and .grp's
* Better algorithm to generate .grp's: bricks that are neighbors will be put together in the same group.

I also plan to add the possibility of assigning layers (default, yellow or green) to the bricks.

----------------

Update at: September 29th, 2012.
RBE has got a new user interface, designed to be more user-friendly. You may click around, hold and move the mouse cursor, or even use the mouse wheel. Please take a moment to explore the interface.

In my own tests, RBE2 allowed me to put together a simple brickset in much less time and with much less hassle compared to RBE1. Please let me know what do you feel.

RBE2 won't generate bricksets for now, and you still can't change the picture of the brickset, but here's what is planned:

* no need to deal with the clumsy Load/Save functions of RBE1 anymore. We plan to save the bricksets automatically in the server, so users can resume (and even share!) their work whenever they need.
* no need to copy & paste .brk's and .grp's. We plan to make a clean button to download these scripts.
* groups of objects (.grp's) will be generated based on connected clusters of bricks. That is, bricks that are neighbors will be put together in the same group.
* generate the bricksets (.brk's)
* allow users to upload/update their brickset images.

It might take a while for us to fully complete RBE2, since other tasks (0.2.0) are pending, but the most basic features should get done sometime soon.

Thanks to SilverstepP for the brickset image currently in use.

Last edited by Alexandre (2012-10-02 02:07:41)

Re: Rapid Brickset Editor 2 (working beta!), Oct 1st.

Yyyyeeeessss...! Finally. I'm cheering right now. lol

Re: Rapid Brickset Editor 2 (working beta!), Oct 1st.

shut up and take my money!!! tongue

Re: Rapid Brickset Editor 2 (working beta!), Oct 1st.

Which Open Surge tools are still under active development?  The wiki lists

Rapid Brickset Editor
Brickset Editor Tool
Level Creator
JBM Zonique
CodeWatcher

The Level Creator doesn't seem to be available anymore?
Language Editor

done

Re: Rapid Brickset Editor 2 (working beta!), Oct 1st.

I can't respond for the other tools listed, but JBM Zonique is currently in stasis. I'm planing however to update it further down the road.

Re: Rapid Brickset Editor 2 (working beta!), Oct 1st.

darkcity wrote:

Which Open Surge tools are still under active development?  The wiki lists

Rapid Brickset Editor
Brickset Editor Tool
Level Creator
JBM Zonique
CodeWatcher

The Level Creator doesn't seem to be available anymore?
Language Editor

among the listed, the only active project is RBE 2

Re: Rapid Brickset Editor 2 (working beta!), Oct 1st.

I'd like to make a request for the RBE2.

One thing I never liked about it is that you can only make 16X16 bricks. It would be nice if we had a selection tool so we could make bricks whatever size we want. (ie. 238X74)

Re: Rapid Brickset Editor 2 (working beta!), Oct 1st.

Bricks draw to the screen faster if they are multiples of 8 and the larger a brick is the slower it loads, the choice of 16 by 16 is a game making tradition and making bricks in these sizes can actually improve your performance by an amount that gets bigger by the brick.

If I knew then what I know now I'd tell you that the story's true.  Cause whatever you do, it comes back to you.  -Slaughter, Burning Bridges

Re: Rapid Brickset Editor 2 (working beta!), Oct 1st.

you can use groups to have a large brick, don't know if that help.

How come x8 bricks are faster is it to do with Allegro?

done

Re: Rapid Brickset Editor 2 (working beta!), Oct 1st.

Idk, but it would seam like that's the case.

11

Re: Rapid Brickset Editor 2 (working beta!), Oct 1st.

my experience is the opposite, lots of small bricks choke the engine far more than one huge brick. I would advise to keep the brick count as low as possible to ensure fast drawing times, regardless of brick size.

Re: Rapid Brickset Editor 2 (working beta!), Oct 1st.

KZR wrote:

my experience is the opposite, lots of small bricks choke the engine far more than one huge brick. I would advise to keep the brick count as low as possible to ensure fast drawing times, regardless of brick size.

I agree with KZR. Brick size doesn't matter; it's how many bricks there are. Quality over Quantity.

Re: Rapid Brickset Editor 2 (working beta!), Oct 1st.

The reason multiples of 8 draw faster has to do with the way computers process information.  Every single thing inside your computer is represented by binary, and binary breaks into sets of 8 to display things.  Therefore, there is less 'empty' information being processed when a tile is 16x16 than if it was 17x17.  So, if you want to make larger bricks I would suggest keeping within these multiples of 8 as much as you can, so 32x32 is a good size, 64x64 is a good size, and 128x128 is probably the largest I would personally go because when you start getting into images larger than that you have the potential to bog the entire engine.  Actually, if anyone is willing to custom define a tileset with sizes larger than 256x256, build a moderately sized level with it, and try it we can determine how much that will bog the engine if at all.  Just remember, we need most of our processing power to go to the game objects, so if this causes bogging it will likely be too much for many hacks because between that and the engine processing their objects there will be lag.

If I knew then what I know now I'd tell you that the story's true.  Cause whatever you do, it comes back to you.  -Slaughter, Burning Bridges

Re: Rapid Brickset Editor 2 (working beta!), Oct 1st.

I never said I wanted bricks that aren't coordinated by multiples of 8, I just wanted larger bricks.

Re: Rapid Brickset Editor 2 (working beta!), Oct 1st.

Yes, I am simply stating that your odds of having good working bricks is better if you use multiples of 8 for your larger bricks.  Remember that you can still define a brick set by hand, it's an essential skill to have in defining brick sets and is just what you need if you want to see just how large of a brick you can get away with in a level.  As for changing up the official tool, I can support it being able to choose from several brick sizes, but I know that introduces a world of work for Alex and you must understand that he only has so much time available for open surge development to begin with.

If I knew then what I know now I'd tell you that the story's true.  Cause whatever you do, it comes back to you.  -Slaughter, Burning Bridges

Re: Rapid Brickset Editor 2 (working beta!), Oct 1st.

S32X wrote:

I never said I wanted bricks that aren't coordinated by multiples of 8, I just wanted larger bricks.

S32X, have you ever tried Brickset Editor Tool ? It can handle bricks of any size. Very nice tool, but it is not maintained. The program is made by a guy whose nickname is Celdecea. Too bad he is no longer with us. sad

There was another attempt at building a brickset tool, this time from a guy called MTK358. It could also handle bricks of any size. Unfortunately, it is no longer available. Unfortunately, MTK358 is no longer here, either.

lunarrush wrote:

As for changing up the official tool, I can support it being able to choose from several brick sizes, but I know that introduces a world of work for Alex and you must understand that he only has so much time available for open surge development to begin with.

Yes, as lunar has pointed out, my time to work on opensurge is limited. I currently code the engine and work on the game. I also provide users some basic tools, so they can get things going, make their mods, and so on. There's a basic brickset editor (RBE) and a basic level editor (the built-in one), that, although far from perfect, work well for a reasonable pool of purposes.

The main reason why I fixed the brick size to 16x16 on RBE is because is greatly simplifies creating bricksets (it is fast!) and building the tool. Also, using 16x16 implies grid-compatible bricks. Unfortunately, RBE can't handle anything beyond that (other sizes of bricks, movable bricks, animated bricks, and so on). It is not supposed to.

Now, please understand that due to the workload, at this moment I'm unable to provide super flexible tools to modders - which I know they want and need. Now, these kinds of efforts have to come from the community. There's nothing stopping anyone from building better, more flexible tools. In fact, this is encouraged! Please go and make them! However, please do not expect them to come from the engine coder.

Re: Rapid Brickset Editor 2 (working beta!), Oct 1st.

Alexandre wrote:

S32X, have you ever tried Brickset Editor Tool ? It can handle bricks of any size. Very nice tool, but it is not maintained. The program is made by a guy whose nickname is Celdecea. Too bad he is no longer with us.

Indeed I have. But I never got it to work properly. When I tried to open it the program would crash.

Re: Rapid Brickset Editor 2 (working beta!), Oct 1st.

S32X wrote:
Alexandre wrote:

S32X, have you ever tried Brickset Editor Tool ? It can handle bricks of any size. Very nice tool, but it is not maintained. The program is made by a guy whose nickname is Celdecea. Too bad he is no longer with us.

Indeed I have. But I never got it to work properly. When I tried to open it the program would crash.

yes, we know. His tool has crashing bugs and it is not maintained, unfortunately.

Now, the initiative to improve things has to come from you, guys. There is nothing stopping you. smile

Re: Rapid Brickset Editor 2 (working beta!), Oct 1st.

lunarrush wrote:

The reason multiples of 8 draw faster has to do with the way computers process information.  Every single thing inside your computer is represented by binary, and binary breaks into sets of 8 to display things.  Therefore, there is less 'empty' information being processed when a tile is 16x16 than if it was 17x17.  So, if you want to make larger bricks I would suggest keeping within these multiples of 8 as much as you can, so 32x32 is a good size, 64x64 is a good size, and 128x128 is probably the largest I would personally go because when you start getting into images larger than that you have the potential to bog the entire engine.  Actually, if anyone is willing to custom define a tileset with sizes larger than 256x256, build a moderately sized level with it, and try it we can determine how much that will bog the engine if at all.  Just remember, we need most of our processing power to go to the game objects, so if this causes bogging it will likely be too much for many hacks because between that and the engine processing their objects there will be lag.

I'm not convinced this is the case.  It depends on how the game engine is written.  Binary doesn't have to break down in to 8s but 2s.  Commonly computers handle 8, 16, 32 and 64 bit values that give you positive integer ranges from zero to 255, 65535, 4294967295 and 18446744073709551615 respectively.    Your example could be true it if you stored 8 pixels with a 4 bit color depth in a 32 bit word.  If  KZR's experience is anything to go by it sounds like the bottle neck in the engine is processing bricks not drawing them.

BTW I had to use an online calc to get the 64 bit number
http://world.std.com/~reinhold/BigNumCalc.html

Last edited by darkcity (2013-02-10 17:31:57)

done

Re: Rapid Brickset Editor 2 (working beta!), Oct 1st.

Sorry, I was a bit wrong, things that are powers of 2 tend to process faster inside a computer, so we start at 2 then continue multiplying answer by 2 to get 4, 8, 16, 32, 64, 128, 256, and 512.  I've provided a link below that attempts to explain why game designers started using these numbers.  Also, I was not trying to mislead you when I said that engines tend to bog with bigger images, in fact many engines I know of don't have support for loading an image above a certain size to protect themselves from such slowdown.  What we need to do is preform some optimization testing with various brick sizes and see precisely which ones provide the best performance on multiple platforms.  We will need to write some engine code that can catch how optimum our performance is and print it to a readable file which can then be read by the mod developer to help them determine what size of brick they wish to use for their game.

Links:
http://gas13.ru/v3/tutorials/sywtbapa_w … prites.php

If I knew then what I know now I'd tell you that the story's true.  Cause whatever you do, it comes back to you.  -Slaughter, Burning Bridges

Re: Rapid Brickset Editor 2 (working beta!), Oct 1st.

lunarrush wrote:

Sorry, I was a bit wrong, things that are powers of 2 tend to process faster inside a computer, so we start at 2 then continue multiplying answer by 2 to get 4, 8, 16, 32, 64, 128, 256, and 512.  I've provided a link below that attempts to explain why game designers started using these numbers.  Also, I was not trying to mislead you when I said that engines tend to bog with bigger images, in fact many engines I know of don't have support for loading an image above a certain size to protect themselves from such slowdown.  What we need to do is preform some optimization testing with various brick sizes and see precisely which ones provide the best performance on multiple platforms.  We will need to write some engine code that can catch how optimum our performance is and print it to a readable file which can then be read by the mod developer to help them determine what size of brick they wish to use for their game.

Links:
http://gas13.ru/v3/tutorials/sywtbapa_w … prites.php

Thanks for clearing that up for me. I thought it was 2, but when you said 8 I thought I was wrong.

Re: Rapid Brickset Editor 2 (working beta!), Oct 1st.

Thanks for the link, I agree it makes sense to use those sizes.  Some way to test the engine would be good.   Maybe just try breaking it with tons of bricks or some massive bricks. cool

done

23

Re: Rapid Brickset Editor 2 (working beta!), Oct 1st.

darkcity wrote:

Thanks for the link, I agree it makes sense to use those sizes.  Some way to test the engine would be good.   Maybe just try breaking it with tons of bricks or some massive bricks. done

Like i experienced, with the first version of Rapid Brickset Editor, having a screen full of 16*16 bricks is a major source of slowdown. the more you tile or layer them up, the longer it takes to draw the next frame. I would personally advise to use small sizes only if necessary, sicking to larger blocks whenever possible. I had no troubles with drawing stuff up to 512*512. So, for example, if your level contains sections of various sizes, you can add bricks of various sizes as well, not only to create longer sections faster, but also to let you create smaller sections easily, without forcing the engine to work extra.