#31578 - Steve++ - Sun Dec 12, 2004 5:14 pm
I've been searching the forum for ideas for my game and its level editor. I came across this, by tepples:
| Quote: |
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. |
So far I've been thinking about the WRONG way. I like the sound of the RIGHT way. It reminds me of The Last Ninja (C64), although it didn't have scrolling.
Anyway, I was wondering what approach would be best (most viable) for a compositor on the GBA:
1. Generate large tilemaps at the start of each level/room. This requires the tilemaps to live in RAM.
2. Render the level on-the-fly. Could be too CPU intensive.
I'm particularly interested in method #2, because it requires the least RAM usage. I'm just not sure about the best way to go about it. Any ideas?
#31579 - tepples - Sun Dec 12, 2004 5:27 pm
| Steve++ wrote: |
| So far I've been thinking about the WRONG way. I like the sound of the RIGHT way. It reminds me of The Last Ninja (C64), although it didn't have scrolling. |
I apologise. I was a bit Mariocentric in that comment.
| Quote: |
Anyway, I was wondering what approach would be best (most viable) for a compositor on the GBA:
1. Generate large tilemaps at the start of each level/room. This requires the tilemaps to live in RAM.
2. Render the level on-the-fly. Could be too CPU intensive. |
NES games typically rendered the level on the fly.
| Quote: |
| I'm particularly interested in method #2, because it requires the least RAM usage. I'm just not sure about the best way to go about it. Any ideas? |
One way to make a world is as a grid of metatiles (look them up on Google if you don't know what they are). For each metatile, store several hardware tile numbers plus collision data.
Another way is to download some NES game editors and play with them in order to get a feel for the map data models used in those games. The "object oriented" approach I described applies to Super Mario World.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#31614 - Steve++ - Mon Dec 13, 2004 2:42 am
Thanks tepples. I was hoping you'd reply.
It seems a grid of metatiles is too constraining. For instance, if the cell size was 4x4 tiles, every object would need to be aligned by four tiles. I'm trying to think of a good scheme whereby objects only need to be aligned by one (hardware) tile. It needs to be fast. I was thinking of dividing the whole level into a grid with a cell size of, let's say, 8x8 tiles. The maximum object size would also be 8x8 tiles; each object would live in one, two or four cells. It should be easy enough to look at which cells are onscreen and, by looking at these cells, decide what to draw. The only problem I forsee is that of overlapping objects in the same BG layer, which just wouldn't work. Obviously, the editor I'm making will have to sort that out.
I should also talk to my level designer about the requirements. The problem is, until I have a working editor, he'll be fishing most of the time (uncontactable).
Any suggestions, especially from people who have attempted this sort of thing, are welcome.
Thanks again.
#31623 - sajiimori - Mon Dec 13, 2004 4:15 am
Make your artist's day: tell him he can use Photoshop, as long as he's careful to keep a lot of redundancy along tile boundaries. Then let your tools break up the images into map and pixel data.
#31628 - Steve++ - Mon Dec 13, 2004 5:38 am
An intriguing idea, but we don't have photoshop or psp. The only thing I've got is GraphicsGale. I'd rather settle on a format and then build a custom editor for it. Java's my friend. :)
Between posts I've been playing with various ideas. For instance, for the sake of avoiding palette headaches from importing tile data from bitmaps, I was going to have a colour quantisation process that takes place as part of the data export function. That would allow everything to be edited in 15-bit colour, yet the user would always be made aware of how many unique colours are being used for each level. Now I'm thinking that the quantisation process could take place in-game at the start of each level. The downside is that tiles will require 15 bits of storage per pixel. The upside is that if there are a lot of tiles that are common to a lot of levels, they don't get duplicated for (almost) every level in which they appear.
#31631 - tepples - Mon Dec 13, 2004 6:50 am
| Steve++ wrote: |
| Now I'm thinking that the quantisation process could take place in-game at the start of each level. The downside is that tiles will require 15 bits of storage per pixel. |
And it'll be dog slow. Real commercial games do the color quantization at compile time.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#31634 - Steve++ - Mon Dec 13, 2004 7:32 am
Perhaps I could make the editor restrict the number of colours per level to 255 (by way of restricting addition of further objects). Instead of run-time quantisation, it would simply require runtime palette and tile creation. I can't imagine that being too slow. I would just need an assert until the final build.
The only other alternative I can think of is some crazy edit-time quantisation algorithm that weeds out as many real duplicate tiles as possible. I would be tearing my hair out for weeks.
As far as the overlapping problem goes (mentioned earlier), I could probably use two hardware layers as for the foreground. Somehow I can't see four levels of parallax happening; that's just excessive.
#31760 - sgeos - Tue Dec 14, 2004 8:48 am
| Steve++ wrote: |
| An intriguing idea, but we don't have photoshop or psp. The only thing I've got is GraphicsGale. |
You could download the gimp.
-Brendan
#31805 - sgeos - Tue Dec 14, 2004 9:56 pm
| Steve++ wrote: |
| Somehow I can't see four levels of parallax happening; that's just excessive. |
You probably want to save a layer for the HUD or a special effect (fog). The HUD could be done with sprites.
-Brendan
#31820 - tepples - Tue Dec 14, 2004 11:54 pm
Sega Genesis games typically drew the HUD with sprites, using one layer for the playfield and one for the parallax background. It's even more practical to draw a HUD with sprites on the GBA, given the fast transfers to VRAM and the increased amount of VRAM (96 KB, with 32 KB dedicated to sprites, vs. 64 KB of Super NES and Sega Genesis).
And I second the recommendation of GIMP.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.