#18500 - dagamer34 - Sun Mar 28, 2004 1:45 am
What map editor does everyone use? I have been looking around for one and seeing which is the best. Some support a ton of features but isn't user-friendly and others and very simple.
Thanks for your input.
_________________
Little kids and Playstation 2's don't mix. :(
#18519 - batblaster - Sun Mar 28, 2004 10:09 am
HEHEHEHEH The best is Mine hehehe GBA World...
A friend put online here...
http://www.maxamor.net/GBAWorld_Installation_Italian.rar
http://www.maxamor.net/GBAWorld_update_exe.rar
Bye....
_________________
Batblaster / 7 Raven Studios Co. Ltd
------------------------------------------
#18523 - Lupin - Sun Mar 28, 2004 1:42 pm
The best is always the one you wrote by yourself because you may add features to it that you are missing in other editors and writing an good editor should not take longer than one day (if you are writing it in delphi or VB or any other easy-to-use language :))
I am writing all my converters by myself and i already wrote a map editor by myself... but i lost it :(
_________________
Team Pokeme
My blog and PM ASM tutorials
#18533 - DekuTree64 - Sun Mar 28, 2004 4:48 pm
Yup, I wrote my own too. It's a lot of work, but it seems it's the most common way to do it. And if you don't go overboard trying to make a whole-game editor like I did (or at least don't do it in C++), it will be a lot easier. Turns out by the time you can get a game maker working, you're good enough that USING a game maker takes longer than making batch files and typing character/monster type data by hand.
_________________
___________
The best optimization is to do nothing at all.
Therefore a fully optimized program doesn't exist.
-Deku
#18544 - tepples - Sun Mar 28, 2004 7:45 pm
The WRONG way to design a map editor for a side-view or top-view game is to make a 2D array of what hardware tiles are displayed in what positions.
The RIGHT way to design a map editor:- Decide what the objects in your game world will be.
- Decide what they will look like.
- Create a representation for a list of objects in a level. This representation will depend on characteristics of your target platforms' display systems.
- Given such a list, decide how to draw them to the display. This code is your compositor.
- Implement your compositor on both a workstation GUI platform (wxWidgets, GTK+, Allegro, SDL, Qt, or the like) and your target platform(s) (GBA, J2ME, J2SE for Applets, or the like).
- Make a PC program that lets the user edit the list of objects and draws them to the screen after each edit.
If you want to see an example of such an editor, download Lunar Magic for Super Mario World.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#18547 - poslundc - Sun Mar 28, 2004 8:22 pm
| tepples wrote: |
| The WRONG way to design a map editor for a side-view or top-view game is to make a 2D array of what hardware tiles are displayed in what positions. |
What about in overhead RPGs, where the contents of a map are not so easily broken down into locatable objects?
Dan.
#18550 - dagamer34 - Sun Mar 28, 2004 8:50 pm
I'm not sure I can write my own, since it would take up so much time and I have no idea how to start.
And I thought I was done with Windows programming...
_________________
Little kids and Playstation 2's don't mix. :(
#18553 - tepples - Sun Mar 28, 2004 10:02 pm
| poslundc wrote: |
| tepples wrote: | | The WRONG way to design a map editor for a side-view or top-view game is to make a 2D array of what hardware tiles are displayed in what positions. |
What about in overhead RPGs, where the contents of a map are not so easily broken down into locatable objects? |
It's true that special-purpose codecs are "not so easily" designed. But wouldn't it make sense to store one of many similar looking NPC houses as "house, a tiles wide, b tiles deep, painted in color scheme c", a wall as "south-facing wall, a tiles high, b tiles long, origin (x, y)", or a river or dirt path as a polygon, and then let the compositor decompress it into a 2D array of tiles? I can guess it'd allow for a much bigger map in the same amount of ROM space at the cost of a bit of loading time between map segments. Remember that keeping all other factors equal, it's a lot easier to get a 32 Mbit (4 MByte) game published than a 128 Mbit (16 MByte) game because the publisher of a smaller program incurs less replication cost from Nintendo. Therefore, compression is important in real-world designs.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#18556 - poslundc - Sun Mar 28, 2004 10:16 pm
Well, I think it's reasonable (in the RPG case anyway) to use a normal tiled map and then optimize it with something like LZSS compression if you make it to the publication stage.
That's my intent, anyway. :)
Dan.
#18578 - tepples - Mon Mar 29, 2004 4:15 am
| poslundc wrote: |
| Well, I think it's reasonable (in the RPG case anyway) to use a normal tiled map and then optimize it with something like LZSS compression if you make it to the publication stage. |
LZ77 is based on copying previous words in a moving window to next words. Because each map starts with a fresh window content, LZ77 doesn't exploit redundancies from one map to another. And because it isn't special-purpose, it doesn't exploit invariants in the game model. The LZSS implementations used in the Allegro library and in the GBA BIOS are LZ77 family algorithms.
On the other hand, LZ78 is a dictionary based method, and theoretically, multiple maps can use the same dictionary. Amortizing the size of the shared dictionary across multiple maps can exploit cross-map redundancies. The method I describe, naming attributes of multi-tile objects on the map and expanding them at runtime, feels like a two-dimensional LZ78. In addition, the "dictionary" analogy makes it easier for the map editor to "spell check" the levels that the user draws.
Remember that NES RPGs were 512 KB in size, and the size of graphics shouldn't more than quadruple (double color depth, double unique tiles) from the NES to the GBA. Do you think LZSS alone could have optimized all the maps of Super Mario Bros. down to just 10 KB or so?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#18585 - DekuTree64 - Mon Mar 29, 2004 6:36 am
I was thinking about using LZ78 for sprite compression, but from what I read, it just builds the dictionary as it decompresses, so there's no way to recycle the same dictionary over multiple files. Or do you know a good way to do it?
My RPG uses LZ77 on maps, which are broken into 16x16 tile blocks. The compression rate isn't incredible or anything, but it's certainly better than nothing. Mainly what it's good for is multi-layer maps, where the bottom layer is full of detail and doesn't compress well, but the upper layers are mostly transparent anyway, so they barely make any difference to the size as opposed to fully multiplying it. In that sense, RLE would work about as well, but LZ77 does get good enough rates to be worth using on the more complicated layers too.
Using a sort of level-scripting does seem to be the best in terms of compression, but I do wonder how you would go about designing a level editor for an RPG that way. Seems like it would take forever writing all the parametric object drawing bits with the number of different types of places in most SNES RPGs. Although it would be helpful for just designing levels to be able to draw out just the floor and have it calculate up all the walls and floor edges and such, and then specify detail objects here and there. I might have to try writing something like that sometime. Although it may be more time consuming than drawing the maps by hand...
_________________
___________
The best optimization is to do nothing at all.
Therefore a fully optimized program doesn't exist.
-Deku
#18591 - bomberman - Mon Mar 29, 2004 10:56 am
I use LevelMapper from http://www.gbatools.com
After having tried loads of them (Tile Studio, Mapwin, Mapster, ...), no one really offered everything I was looking for.
They all lacked more or less some features in different departments (edition, code generation, GUI, ...).
I found LevelMapper and am quite happy !
Only enhancement that I would really appreciate: windowed mode rather than full screen. Jamie, are you listening to me ? :O)
#18594 - tepples - Mon Mar 29, 2004 1:11 pm
| DekuTree64 wrote: |
| I was thinking about using LZ78 for sprite compression, but from what I read, it just builds the dictionary as it decompresses, so there's no way to recycle the same dictionary over multiple files. Or do you know a good way to do it? |
Some implementations of LZ78 use such a dynamic dictionary. However, other similar algorithms use a static dictionary. I might have been a bit loose in my application of the "LZ78" label, but its "dictionary" does seem like a good analogy to explicit dictionary-based compression.
| Quote: |
| Using a sort of level-scripting does seem to be the best in terms of compression, but I do wonder how you would go about designing a level editor for an RPG that way. |
Think of the difference between a "paint" program (a bitmap image editor such as GIMP or Adobe Photoshop) and a "draw" program (a vector editor such as Sodipodi or Adobe Illustrator).
| Quote: |
| Seems like it would take forever writing all the parametric object drawing bits with the number of different types of places in most SNES RPGs. |
You could design a way to make the editor and compositor extensible so that one can easily add new objects to place.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#18598 - poslundc - Mon Mar 29, 2004 3:00 pm
| tepples wrote: |
| Remember that NES RPGs were 512 KB in size, and the size of graphics shouldn't more than quadruple (double color depth, double unique tiles) from the NES to the GBA. Do you think LZSS alone could have optimized all the maps of Super Mario Bros. down to just 10 KB or so? |
Well, to be fair, let's keep it in the genre. Do you know what technique, say, Final Fantasy or Dragon Warrior used to store their maps?
Dan.
#18603 - Nessie - Mon Mar 29, 2004 7:46 pm
| Quote: |
| Think of the difference between a "paint" program (a bitmap image editor such as GIMP or Adobe Photoshop) and a "draw" program (a vector editor such as Sodipodi or Adobe Illustrator). |
Right, pixel and vector art are two very different approaches, and depending on what you are trying to do, one approach may be a very poor substitute for the other.
In fact, I suspect that if you ask an artist which approach they prefer, they'll respond with...depends on what I'm doing. If I need to paint, I'll use Photoshop (pixels). If I'm doing an ad layout, I'll use Illustrator (vector based).
So, suggesting that one approach is right or wrong completely removed from the context of the needs of the situation (which you have done)... | Quote: |
| The WRONG way to design a map editor...The RIGHT way to design a map editor.. |
..is completely ridiculous and a path that any experienced software/game developer would do well to avoid.
| Quote: |
| Do you think LZSS alone could have optimized all the maps of Super Mario Bros. down to just 10 KB or so? |
Honestly though, the game looks like it was extensively compressed, and much to the detriment of the levels. The game is sufficiently old, repetitive, and simplistic that using it to 'sell' your opinion that the map storage techniques it uses are ideal for seemingly every kind of 2D side-scroller/top-down (you haven't stated otherwise) hardly seems relevant to any modern game.
To keep it fair, how about suggesting a game (new or old) with more complicated levels that uses the approach you have proposed. Say, something on par with Lady Sia, Super Metroid, Metroid Fusion or Golden Sun, just to pick a couple of games off the top of my head.
| Quote: |
| Remember that keeping all other factors equal, it's a lot easier to get a 32 Mbit (4 MByte) game published than a 128 Mbit (16 MByte) game because the publisher of a smaller program incurs less replication cost from Nintendo. Therefore, compression is important in real-world designs. |
Maybe, however, if we imagine a hypothetical situation that is slighly more complicated than what you have suggested (the real-word is rarely simple, right?), one where you have a game with cookie-cutter levels and it happily fits on a 4 MB cart...vs...a game that has levels that are much more varied and it just squeezes on a 8 MB cart...
..with all other factors being equal, which game will the publisher spring for?
On the one hand, they have a game that may be more visually appealing and therefore more likely to be able to compete with other 'attractive' games out there.
On the other hand, the production costs may be cheaper but the game may be much harder to sell.
In any case, if you are seeking a publisher, I'd suggest that answering the question yourself is probably not suitable and may actually be offensive to a publisher. They will be the people funding your game, they will be taking the risk, and they would therefore want to carefully weigh all of the parameters of the product they will have to market, only one of which is cart size.
#18604 - tepples - Mon Mar 29, 2004 8:15 pm
| poslundc wrote: |
| tepples wrote: | | Do you think LZSS alone could have optimized all the maps of Super Mario Bros. down to just 10 KB or so? |
Well, to be fair, let's keep it in the genre. Do you know what technique, say, Final Fantasy or Dragon Warrior used to store their maps? |
I know Zelda 1 used an object based system similar to the one I describe.
After a bit of research, it seems that Dragon Warrior does indeed use a 2D array based system. However, it's based on 16x16 pixel metatiles rather than 8x8 pixel tiles; most of the GBA tile editors are hardwired to work on 8x8 pixel tiles. Sonic the Hedgehog 2 is based on 128x128 pixel(!) metatiles, and I can see how 128x128 pixel tiles would look almost like a dictionary based solution to some people.
| Nessie wrote: |
| If I'm doing an ad layout, I'll use Illustrator (vector based). |
I guess I just see RPG map layout as similar to ad layout more than to painting.
| Quote: |
| how about suggesting a game (new or old) with more complicated levels that uses the approach you have proposed. Say, something on par with Lady Sia, Super Metroid, Metroid Fusion or Golden Sun, just to pick a couple of games off the top of my head. |
I have a feeling that Super Metroid and Metroid Fusion store a door as "door, (x, y), access requires level A powerup or key-item B".
(backpedal backpedal) OK, maybe I was too strong in my initial assertion. The point I was ultimately trying to get across is that actual map editors are rather domain-specific, and the constraints of each game dictate what should go into the map editor. A map editor that directly describes which hardware tile goes in which hardware space often doesn't map well onto a game's domain. Now I recognize that a 2D array based solution may work best for some domains, but please, map editor developers, don't hardwire your editors to 8x8 pixel tiles.
Revised assertion:
WRONG IN MOST CASES: A game map editor that works directly in hardware tile space.
RIGHT: A map editor customized for your domain.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#18605 - LOst? - Mon Mar 29, 2004 8:20 pm
Nessie, your Map editor is quite good. I like how it can handle 16 color bitmaps, but I got a problem. I want the background to share the same palette as the foreground (playground), but I don't want the background to be parallax, but have it in a fixed size. Making two different maps with the same 16-color bitmaps will not give the same palette order :(
#18606 - LOst? - Mon Mar 29, 2004 8:29 pm
| Quote: |
| Sonic the Hedgehog 2 is based on 128x128 pixel(!) metatiles, and I can see how 128x128 pixel tiles would look almost like a dictionary based solution to some people. |
The block mappings for Sonic 2 (Genesis) are made up of 4 times 8x8 tiles putted together with different palette lines and different flip parameters into 16x16 tiles. Those 16x16 tiles are compressed with a format with an unknown name. Then these 16x16 tiles can use different flip parameters and are put together into 128x128 tiles which are yet again compressed with another format with an unknown name.
Then every byte in the level map are loaded up as a 128x128 tile making the whole level. These level maps are compressed too :P
#18619 - dagamer34 - Mon Mar 29, 2004 11:32 pm
I wish Nessie's map editor could handle 256-colors. That would definitely make my like a lot easier. And if it had an option of NOT optimizing my tileset so I control what is loaded into VRAM, it would be in my opinion, the best map editor around.
By the way, how do you use the collision layer in the editor? There is so little info on that feature in the readme.
_________________
Little kids and Playstation 2's don't mix. :(
#18620 - LOst? - Mon Mar 29, 2004 11:38 pm
| dagamer34 wrote: |
I wish Nessie's map editor could handle 256-colors. That would definitely make my like a lot easier. And if it had an option of NOT optimizing my tileset so I control what is loaded into VRAM, it would be in my opinion, the best map editor around.
By the way, how do you use the collision layer in the editor? There is so little info on that feature in the readme. |
256 colors are only for lazy game designers. You have a lot of more choices to have 16 color tiles bcause you can use different palette lines. And I hope Nessie will make it so you can change the palette the tile is using. Most of the platform games from Japan uses this technique, and I want to use it too.
#18622 - Nessie - Tue Mar 30, 2004 12:06 am
Regarding using multiple palettes for a single tile, the export optimization will detect tiles that are using the same bit-pattern, but a different palette.
In other words, I just save the art as a different .bmp, then change the palette to the desired colors (without actually changing the base art).
Then you just load this different 'tileset' into mapEd and paint away.
At export time, the tool should export the tile once... and each of the palettes used for that tile. Naturally, the map BG data is also adjust to reflect the shared tile but the different palette.
I intentionally did it this way because I didn't want to clumsy up the mapEd interface any more than it already was.
Anyway, if there are more mapEd questions, it might make sense to start up a different thread instead of hi-jacking this one?
#18623 - dagamer34 - Tue Mar 30, 2004 1:04 am
Just to close this topic up before I make a new one, I got the map editor to work with 256 colors, using the un-optimized mode and me converting the tiles seperately.
_________________
Little kids and Playstation 2's don't mix. :(
#18699 - LOst? - Thu Apr 01, 2004 9:13 am
| Nessie wrote: |
At export time, the tool should export the tile once... and each of the palettes used for that tile. Naturally, the map BG data is also adjust to reflect the shared tile but the different palette.
Anyway, if there are more mapEd questions, it might make sense to start up a different thread instead of hi-jacking this one? |
Let's hi-jack it a little longer since it has been dead one day alread :P
mapED seems smart if it can find out the same bit pattern for multiple tiles. So I'm happy with that.
Now, one thing that you must fix is to make the editor so you can make new layers in customized size, and not just in percent of the main layer.
I have made a few tilesets with 16-colors that are used for the level layout, but also for the background. The background uses HBlank to scroll in a 3-d parallax way. I have an upper level background which will be replace with a cavern background when the main character enters a mine climbing down a hole. The forground will be in the way of the background so you can't see when the background is switched. This must be done because compression and upload time of the new background will probably take more than one frame to complete.
The way of having this background swap will make the game more variable and funnier to play, but also funnier for me as a programmer to come up with the ideas. mapEd exports different palettes depending on how many tiles that was used, and that makes it impossible for me to do multiple backgrounds with the size of 256x256 and a level area of unknown (possible big) size, and still share the same tilesets and palettes.
I don't know how long it would take for you to make it possible to have customized sizes of layers so I can do this. But I hope you will think about it at least.
My game has been delayed because of this. I don't want to use other map editors because they can't be compared with yours. I could do a lot of hacks to try to make my level structure possible with the current mapED but then I would be forced to make just one map, and never be able to edit it again, because it will be a different palette/tileset result when exported.
Please help me Nessie
#18726 - Nessie - Thu Apr 01, 2004 9:48 pm
LOst?, I have a new-ish version of mapEd that does what you want.
If you want to try it out, PM me or contact me at gba_dev@yahoo.com and let me know where I can send a test executable.
Overall, there are tons of changes to the tool, so it desperately needs testing. :(
#18739 - RaBBi - Fri Apr 02, 2004 7:19 pm
I'm here too if you want beta-testing Nessie :)
_________________
Sorry for my poor english, but it would be worst for you to understand me if I speak in my native language, French ^^
#18755 - LOst? - Sun Apr 04, 2004 12:38 am
| Nessie wrote: |
LOst?, I have a new-ish version of mapEd that does what you want.
If you want to try it out, PM me or contact me at gba_dev@yahoo.com and let me know where I can send a test executable.
Overall, there are tons of changes to the tool, so it desperately needs testing. :( |
Wonderful to hear. I though my GBA programming day were over then those things stopped me from doing what I've always dreamed about. My big dream is not just to make a game like Mario, I want to make it more dynamically and deeper. I want the levels to be special, and not just the original 8x8 tile scrolling.
Thanks for helping me out! I'm very greatful