gbadev.org forum archive

This is a read-only mirror of the content originally found on forum.gbadev.org (now offline), salvaged from Wayback machine copies. A new forum can be found here.

Graphics > Gbamapeditor beta 4 problems?

#66512 - SimonB - Wed Jan 11, 2006 2:27 pm

Has anyone noticed any problems with Gbamapeditor beta 4 not saving tile numbers to the map correctly? Or any other problem for that matter...

As reported by Rory:

Rory wrote:
it saves incorrect tile numbers to the map [(tile numbers wrong after first row)], I wasted 4 hours of my life thinking it was me.

#66520 - Cearn - Wed Jan 11, 2006 3:37 pm

The first problem with that editor is that it defaults to 8bit screen entries, so you can't use memcpy or dma or whatever to copy it to a screenblock for text maps. You have to use a loop to unpack from bytes to halfwords.

The second problem, which is the one he had trouble with, is that when you set the tile-size to 16x16, only 17x17 entries are actually exported (for a 32x32 map; don't know about other sized maps).

As an alternative, consider mirach. Although is still does very little of what I had planned for it, at least it works.

#66524 - gauauu - Wed Jan 11, 2006 4:10 pm

I've also had good results with "mappy" (the map editor, not the emulator)....there's a utility out there somewhere (fmp2gba) which will automatically export mappy save files to C files, which is nice for big projects where you can just edit and save the mappy files, then let the makefile take care of everything else. (That's what I do in my game anguna.....each room gets it's own mappy file, then when I do a make, it will export and recompile the changed rooms)

Also, fmp2gba's source is available, and it's pretty simple code, making it easy to customize the export to whatever you need.

Of course, I've been meaning to try mirach also. Cearn's apps are generally pretty high quality.

#66525 - pure_ev1l - Wed Jan 11, 2006 4:17 pm

yeah, I'm Rory btw.

really dont use the program! I forgot to mention that second problem.

try my map editor, it has praticaly everything :-D

it will save maps as big as you like (max I have used is 2048x2048 as it crashed compiler trying to process it!)

and has some really neat options, like spray fill and zoom etc :)

#66526 - thos_thom - Wed Jan 11, 2006 4:43 pm

A word about this new map editor,

you might want to make a slight change to it before you make a few people angry. Make that a few *more* people angry.

I loaded a set of tiles i have been keeping for a long time, drew a nice picture with them, i have no qualms with the functionality of the editor.

I wondered what format your export... command exported to.

I clicked on it. I was given a save dialogue, this dialogue contained the name of my tileset and below it implied that it was going to save as a .c file. So i pressed cancel having learned what i needed to know.

A few minuites later i find that your program had writen the c file anyway over my tileset.

I loved those tiles.

You might want to fix that. Other than that i liked it.
_________________
--------------
^thom(as)?
--------------

#66530 - pure_ev1l - Wed Jan 11, 2006 5:31 pm

SUPER sorry :'( I fixed that flaw after sending it in, didnt nottice it b4, as in really, a few hours after I sent it and notticed....super sorry :'(

its the first release... and its less than a week old...

I've sent the new version.

I am truely sorry. dont know what I can do about that. fixed it as quickly as possible and I did try to get rid of all the bugs :-(.

but, a word in my favour, it is a beta... but sorry.

-Rory

#66534 - SimonB - Wed Jan 11, 2006 6:47 pm

updated version on the site now...

Simon

#66535 - pure_ev1l - Wed Jan 11, 2006 6:51 pm

wow... fast! nice work.

can't find it on tools, do you have a testing period? or am I blind? (know its on news)

-Rory

#66536 - SimonB - Wed Jan 11, 2006 6:55 pm

pure_ev1l wrote:
can't find it on tools, do you have a testing period? or am I blind? (know its on news)


We are currently re-doing the tool section so cant add any new stuff until we have sorted it out. It will be added as soon as we are done =)

Simon

#66708 - dovoto - Fri Jan 13, 2006 2:35 am

Played with the editor a bit...looks like a good start but some feature needed for it to work in most game creation situations:

-binary output
-tile flipping
-resizable tile set window (or dockable)
-layers
-brush preview (so i can see the current brush as i drag it accross the map to aid in placement)
-ability to place objects

more features that would be nice:
-brush history with ability to persist often used brushes
-arbitrary tile selection (ie to build a non-rectangular brush)
-have multiple tile sets open
-tile animation builder
-multiple palettes (of arbitrary bit depth)
-the ability to set properties on tiles and objects
-pluggin based output

...man...maybe we should make a list and start an open source project (in a decent language (c++ with SDL or some such or possibly .net and screw linux))..if i start it it will be .net so you linux fanatics better beat me to the punch :)

here is an example of a tile editor that is ALMOST good enough if you need some inspiration:)
http://nessie.gbadev.org/
_________________
www.drunkencoders.com

#66724 - LOst? - Fri Jan 13, 2006 5:45 am

I still can't live with a map editor that outputs 8x8 tile maps. I want to have meta options. Most of the games I want to design use 16x16 tiles, and I want them to be meta blocks and not saved in the layout data as 4 8x8 tiles.

So I have decided to make my own private editor that can perform what I want. It may take a year or so until it is ready. Until then I am suspended from any work on DS or GBA games.
_________________
Exceptions are fun

#66764 - pure_ev1l - Fri Jan 13, 2006 11:11 am

dude, I can change mine to do that if you can just explain meta blocks?

as adding in 16x16 mode would be a breeze :-)

Quote:
-binary output
-tile flipping
-resizable tile set window (or dockable)
-layers
-brush preview (so i can see the current brush as i drag it accross the map to aid in placement)
-ability to place objects

more features that would be nice:
-brush history with ability to persist often used brushes
-arbitrary tile selection (ie to build a non-rectangular brush)
-have multiple tile sets open
-tile animation builder
-multiple palettes (of arbitrary bit depth)
-the ability to set properties on tiles and objects
-pluggin based output


ok, I may be up for adding most :-)... I would do a c++ version but I'm working on learning c++ my visual basics is better, this can be an open source version, but noone wants visual basic source :-(

problems / comments / questions about dovoto's comments:

binary output: oredy going to do it in next version but I dont know asm, so need help, just give a sample of a map file and I can add that :-)
tile flipping: oredy planing that for next release, how would you recomend it saving the flipping? 3d array? or 2x 2d array? whats the standard?
resizable tile set window: why?
layers: oredy considering it for the next version :-P how would you like it implemented?
brush preview: why? not convinced.
ability to place objects: err you can oredy? just drag select it on tile's then paint, or do u mean something else?
brush history with ability to persist often used brushes: ok, if by brush history you mean undo, then yes I could add, persist wha..?
arbitrary tile selection: hmmm, thats a big change in code, dont think I will add this in any hurry :-/
have multiple tile sets open: why?
tile animation builder: arse. nope, aint doing it, you should have your animations conected with your palette in some way, not with the map file I'm sure.
multiple palettes (of arbitrary bit depth): why?
the ability to set properties on tiles and objects huh?
pluggin based output errr... :S... never made a prog with pluugin support, tell me how (I assume .dll, and a set call name in dll, like main or something, and a set data format for output to plugin dll's)

yeah, it is only a start, its only a few days old, so it will be better, shame I'm devoting my time to my game at mo :-S
_________________
-Rory

"Planning makes for a boring life, but a good game"

Last edited by pure_ev1l on Fri Jan 13, 2006 7:12 pm; edited 1 time in total

#66781 - gauauu - Fri Jan 13, 2006 2:46 pm

Quote:
I still can't live with a map editor that outputs 8x8 tile maps. I want to have meta options. Most of the games I want to design use 16x16 tiles, and I want them to be meta blocks and not saved in the layout data as 4 8x8 tiles.


I use mappy with 16x16 tiles, and use fmp2gba to export them as "meta blocks"

#66794 - Peter - Fri Jan 13, 2006 4:18 pm

Hi,

I wouldn't limit the map-editor for Game Boy Advance output/format only. Come up with an own map-format and provide information about the structure, so everybody who wants, can write a converter to get the map into the proper format.

pure_ev1l wrote:

tile flipping: oredy planing that for next release, how would you recomend it saving the flipping? 3d array? or 2x 2d array? whats the standard?

I would just use a flag.

pure_ev1l wrote:

brush preview: why? not convinced.

Not sure if it's what I think it is. I would like to see what tiles I'm currently using when I move the mousecursor over the map. Now it's pretty much like "uhmm ok, what tiles did I select?"

pure_ev1l wrote:

ability to place objects: err you can oredy? just drag select it on tile's then paint, or do u mean something else?

Placing game-objects is very essential for a level-editor. Only a background makes no game, you need to place objects (and I don't talk about the sprites for gba now). The objects should be movable on a pixel-basis and have a few additional integers assigned to enter an identifier for example, which the game levelloader on the targetdevice can use to create the proper resource. If an object could map a texture in the editor (for preview) it would be pretty cool too.

pure_ev1l wrote:

brush history with ability to persist often used brushes: ok, if by brush history you mean undo, then yes I could add, persist wha..?

A list of frequently used brushes is helpful. Undo/redo of course too!


pure_ev1l wrote:

tile animation builder: arse. nope, aint doing it, you should have your animations conected with your palette in some way, not with the map file I'm sure.

Mappy can do this. Well, actually I used tileanimations quite a lot and can't imagine to miss this.


pure_ev1l wrote:

the ability to set properties on tiles and objects huh?

Yes, very essential feature as well. It's to extend a tile with collision and surface information etc.


pure_ev1l wrote:

pluggin based output errr... :S... never made a prog with pluugin support, tell me how (I assume .dll, and a set call name in dll, like main or something, and a set data format for output to plugin dll's)

Personally I don't need a plug-in interface. If you provide information about the filestructure of your level-format it would be the best. This makes the workflow much easier. The Leveldesigner just send the level and the programmer can send it through the convert-chain. If you have a plug-in interface and the leveldesigner has to export it first, there is always a chance for getting the wrong file .. it happens all the time :)

pure_ev1l wrote:

yeah, it is only a start, its only a few days old, so it will be better, shame I'm devoting my time to my game at mo :-S

Good luck with the tool!

PS: MapEd from Nessie is a really cool editor, it just lacks of object placement and tileanimations features. Beside this, MapEd is great! Take a look at this tool, I'm pretty sure you'll find some inspiration :)

#66797 - Peter - Fri Jan 13, 2006 4:53 pm

dovoto wrote:
...man...maybe we should make a list and start an open source project (in a decent language (c++ with SDL or some such or possibly .net and screw linux))..if i start it it will be .net so you linux fanatics better beat me to the punch :)

Creating an open source map editor from scratch is actually a pretty cool idea! But special care has to be taken on code-reviews. A lot of source code available on the web is a total mess, it would be very sad to have "just another map editor that nobody can extend because the code is awful" :)

PS: *I* wouldn't use .NET, but probably only because I haven't done anything with .NET yet.

#66827 - pure_ev1l - Fri Jan 13, 2006 7:31 pm

getting alittle tricky to reply now, to many open 'discussions' but I'll try.

convince me on the meta, I dont see the point.

my code is pretty neat, but it is visual basic, does anyone think there is a point in making mine an open source collaberation? noone likes VB :-(

so you want multiple export formats? I was planing adding .s but noone has made a small template I can copy

brush preview: still dont see the point, but could add it I guess...not conviced its worth it

objects: ahh get your drift, but what format would I store them?

tile animations: no, I'm not saying there bad, all games shud have them, just that shouldn't they be on the tilepalette so that every bit of sea would be animated the same, not on the map, as that seems a huge waste of resources

screw plugin's

yeah, make an open source c++ map editor :-) if you do I'll scrap my project. why not use visual basic, I Know its a babies language, but it is good for this project in alot of ways.

can a admin rename this thread? to something usefull like open source map editor, or the name of my map editor?
_________________
-Rory

"Planning makes for a boring life, but a good game"

#66898 - LOst? - Sat Jan 14, 2006 6:11 am

pure_ev1l wrote:
dude, I can change mine to do that if you can just explain meta blocks?

as adding in 16x16 mode would be a breeze :-)


Time to explain then:

Map data is usually an array of words, each of them explaining how a tile should be shown. This data is dynamically scrolled over the GBA/DS hardware map. This is how you create maps in your editor.
This works for small maps, but making a map like as big as a world in Mario would require a lot of ROM space.

Now, one solution is meta block handling. Imagine you create a new map in your program, and use 8 tiles as width and 8 tiles as height of the map. You call this map meta entry 1. Then you do another map as big as the previous one, and you call it meta entry 2. Keep going like this until you have 200 different maps or whatever.

Now the actual layout editor will put each of these meta entries instead of tiles. So instead of putting 8x8 pixel tiles in your level, you will put 64x64 pixel tiles instead, which saves space. These 64x64 pixel tiles can not be hardware flipped because they are static maps and not a hardware tile. Instead, you use the flip status in the map for custom bits. The custom bits can be used to tell the game that you are running inside a building, over grass, on a road, or whatever. That's for the game to decide and not the editor.

Since meta blocks can be in different sizes, observe that I will now use meta blocks of 32x32 pixels in my examples below instead of 64x64 pixels for demonstration!

Okay, here is another example:

You have an array of maps that are 4 tiles width and 4 tiles height (called meta blocks) that I name here since I don't have any graphics to make this example easier for you to understand (you don't need to name them in the editor):
meta entry 0: ALWAYS EMPTY!
meta entry 1: "flat floor"
meta entry 2: "tree"
meta entry 3: "right slope up"
meta entry 4: "buildings" (Yea, you can fit some buildings in a drawing of 32x32 pixels, but they will be very small)

Okay, now in the map layout editor, which is 1x4 in size (yes that is small, but remember these are meta tiles and not hardware 8x8 tiles). The first block (x-1 y-1) will be set to be a tree. The map data now looks like this: 0x0001 0x0000 0x0000 0x0000. Okay, then we put a right slope at (x-2 y-1). The map data will now look like this: 0x0001 0x0003 0x0000 0x0000.

Well, a map that looks like this: 0x0001 0x0003 0x0001 0x0002 will in the game be a big map of 128x32 pixels, with drawings of a flat floor, following by a right slope, and then a flat floor again, and last we got a tree.
The map layout editor should show the meta blocks as if it was a hardware block. you simply replace 8x8 pixel tiles with 32x32 pixel tiles because the meta blocks in this case are is 4 x 4 8x8 tiles.

Okay, the editor is easy. It will output data like this:
Code:
const unsigned short* meta_blocks = {
// entry 1:
0x01FF, 0x015A, 0x015A, 0x0032,
0x014C, 0x0110, 0x0172, 0x0015,
0x0181, 0x0151, 0x0084, 0x0055,
0x0132, 0x0133, 0x0144, 0x0144,

// entry 2:
0x0132, 0x0133, 0x0144, 0x0144,
0x014C, 0x0110, 0x0172, 0x0015,
0x01FF, 0x015A, 0x015A, 0x0032,
0x0181, 0x0151, 0x0084, 0x0055,

// entry 3:
0x014C, 0x0110, 0x0172, 0x0015,
0x0132, 0x0133, 0x0144, 0x0144,
0x0181, 0x0151, 0x0084, 0x0055,
0x01FF, 0x015A, 0x015A, 0x0032,

... keeps going up to the last entry that you have made, or the limit of 1024 meta blocks (make the limit it the same as the GBA maximum tile VRAM count).

};


Okay, you notice that entry 0 is not saved because it is just zero tiles. Since we must be able to have an empty map at some places.
Also each word is a 8x8 pixel hardware tile that should be assigned to a palette line and should be able to be flipped. These are the meta blocks! And they can be reused many times in a map layout buffer.

Now have a look at the map layout buffer:
Code:
const unsigned short level_01 = {
// level is 6 meta blocks width and 5 meta blocks height:

0xYXXX, 0xYXXX, 0xYXXX, 0xYXXX, 0xYXXX, 0xYXXX,
0xYXXX, 0xYXXX, 0xYXXX, 0xYXXX, 0xYXXX, 0xYXXX,
0xYXXX, 0xYXXX, 0xYXXX, 0xYXXX, 0xYXXX, 0xYXXX,
0xYXXX, 0xYXXX, 0xYXXX, 0xYXXX, 0xYXXX, 0xYXXX,
0xYXXX, 0xYXXX, 0xYXXX, 0xYXXX, 0xYXXX, 0xYXXX
};

Where Y is custom bits used by the game, and not for your editor to choose. (X)XXX is the meta block index ANDed with 0x3FF to force the selection between 0 and 1043. Also it would be good to have a define or something that tells the game it shouldn't try to use a meta block that haven't been created, like: #define NUM_META_BLOCKS 34.

Now when you have the idea, you will understand that there are many ways for a game to read and draw the meta blocks over the hardware map. It is not for the editor to decide how to manage the meta blocks ingame.

People may have different ideas how to handle maps ingame. Therefore the best solution for a "meta block and map layout" editor would be for the user to be able to choose his own size of the meta block, as well as layout map size.

Meta blocks are simple hardware maps that replace the hardware tiles in a normal map. They are limited to use the same size over and over, which makes them like emulated hardware tiles using your own size. You benefit ROM size because the level layout array will be smalled since the meta block tiles are larger, but also you benefit ROM size because you can reuse each meta block over and over and don't need to create duplicates.



What's happening ingame?
Yes I need to take that up. Even if it isn't your business as the maker of the editor, it will be easier to understand how to make the editor if you understand how to use the meta blocks ingame.

C/C++ handles arrays in a slow way so that's why I haven't put the meta tiles as const unsigned short meta_tiles [size_of_meta] [number_of_metas]. Instead use linear arrays for the meta blocks like in the example above.
Now the game finds it's map location by dividing the meta block size with the map coordinates like this:
Code:
int meta_block_number = ( level_01 [ ((map_offset_y / meta_height) * layout_width) + (map_offset_x / meta_width) ] ) & 0x3FF;


Of course I use only integer divides here, so / 32 will be converted to >> 5.

Also my formula is for demonstration only. It will probably not work because I did the Y offset wrong (I do that all the time).

So now meta_block_number holds the number of the meta block. If you use 4 x 4 meta blocks, you just use this formula to find the original hardware tiles start offset:
Code:
unsigned short* meta_block_data = &meta_blocks [meta_block_number * meta_size];


Yes, the * meta_size will be replased by << 4 is the meta_size is 16 hardware tiles (4 x 4).


Now when you know the basic formulas, then the biggest challenge will appear. how to update meta blocks over the hardware map while you scroll. It's really complex and I have my own formulas for it that I want to keep a secret. It's up the the game developer to come up with a formula that fits his scrolling system the best.




So, what do you think? Meta blocks are not my invention. it is used by probably 90% of all side scrollers ever made. I will use it in my GBA/DS games. Will you?
_________________
Exceptions are fun

#68461 - TheBlackFrog - Tue Jan 24, 2006 8:02 pm

I use TileMax for gba-specific stuff. It has tile flipping and palette selection and is tailored to all of the gba's graphics hardware's features. It also has import/export plugin support so if there isn't a plugin for the kind of images/map data you want to import, or the format you want to output, you can code one yourself. I also do some non-gba map/tile work and for that I use mappy. I did at one point try out gba mapedit Beta 4 but that was long ago in the early days of gba development. Compared to more recent map editors, it is archaic. However at one point there really wasn't much choice (unless you wanted to use the *cringe* DOS-based Open tUME) and I think it should be kept up for download as it is clearly labelled as beta software.

Mappy: http://www.geocities.com/SiliconValley/Vista/7336/robmpy.htm
TileMax: http://www.seanreid.ca/project/TileMax/
Open tUME: http://members.aol.com/opentume/