#14285 - wiz - Sat Jan 03, 2004 10:26 pm
Greetings everyone, and a happy new year!
Its been a while since I have been doing anything on the GBA. I'm planning to make an old game
on the GBA that I made a long time ago on the PC.
So now Im trying to plan it out; The game worked by having a large 2D array to hold the map.
During the game value changes could be made to that array resulting in changes to the map being
drawn.
How could this be achieved with such a low amount of RAM? I have an understanding this map data
would be held in ROM which is read-only.
I hope I'm clear with everything there, And thank you *very* much for your time and advice.
All the best.
PS I have tried to post a few times on the board, if there are multiple messages Im really sorry.
#14290 - sajiimori - Sat Jan 03, 2004 10:49 pm
If any area of the map can change at potentially any time, then it's gotta be in RAM.
How big is the map? If it's too big to fit in GBA RAM as it is, you can try to make the data representation more efficient. Perhaps you could use some very mild form of compression, but then you have to think about best- and worst-case performance of random map access.
After that you're looking at redesigning the game so that less of the map is "active" at a time (so inactive portions can be aggressively compressed or even completely offloaded).
Also, if any part of the map can potentially be altered, but relatively few actually are altered, you could store the original map in ROM and use a seperate "sparse" overlay map that stores a list of cells that have changed.
#14296 - XeroxBoy - Sat Jan 03, 2004 11:34 pm
If you're using single byte entries, you'd be able to fit a 512x512 tile map into EWRAM. Assuming 8 pixels per tile (generally, as small as you'd like to get), that's a 4096x4096 pixel map - absolutely gigantic, in other words, especially considering the pitiful resolution of the GBA.
If that's simply not big enough, you'd be best off using abstract map representation - in Super Mario World, for instance, levels weren't constructed directly from tile maps, but instead were described by a list of objects. So, instead of using 64 bytes to describe a 64x64 pixel brick (for instance), you'd use around five (ObjectType, XLocation, YLocation, HorizSize, VertSize).
#14302 - hnager - Sun Jan 04, 2004 1:46 am
I'm not sure if I follow what you mean in reference to SMW - there was no map in ROM?
#14309 - sajiimori - Sun Jan 04, 2004 2:30 am
No, he's saying that maps are effectively compressed by describing "aspects" of maps (a hill, a vine, a wall) instead of storing them as big arrays of tiles.
#14310 - XeroxBoy - Sun Jan 04, 2004 2:37 am
All there was were lists of predefined objects. Instead of an array containing all the tiles in a level, it'd just be marked as
-Ground located at 0,32, 32 pixels tall, 4096 wide
-Question block containing Yoshi located at 1024, 128, 16 pixels tall, 16 pixels wide
etc.
Then, of course, there's data stored in the header which described which tileset to use, how 'big' the level data was, whether the backgrounds scrolled, etc.
Backgrounds were, however, drawn in traditional tilemap fashion.
To be perfectly honest, I, perhaps, shouldn't have such courage in my convictions - this is just what I picked up from messing around with Lunar Magic, an excellent Mario World level editor. I didn't actually mess around with the ROM itself. So, if anyone knows any better, I would more than appreciate a correction here!
Edit: sajiimori posted ahead of me - and managed to be much more succinct, too!
#14317 - tepples - Sun Jan 04, 2004 3:45 am
| XeroxBoy wrote: |
| If you're using single byte entries, you'd be able to fit a 512x512 tile map into EWRAM. Assuming 8 pixels per tile (generally, as small as you'd like to get), that's a 4096x4096 pixel map - absolutely gigantic, in other words, especially considering the pitiful resolution of the GBA. |
For comparison, 4K by 4K pixels is about how big the overworld map is in The Legend of Zelda: A Link to the Past. The overworld map in Link's Awakening is about 2.5K by 2K pixels.
| Quote: |
| If that's simply not big enough, you'd be best off using abstract map representation - in Super Mario World, for instance, levels weren't constructed directly from tile maps |
This is the Right Way to do it. Case in point: the maps of the original Super Mario Bros. fit into only 8 KB out of the 40 KB binary. In addition, constructing maps from a list of objects makes it easier to switch things from being tiles to being sprites.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#14360 - wiz - Mon Jan 05, 2004 8:45 pm
Thank you all for the input!
some excellent ideas there and its given me a lot to think about. I hope one day I'll have a demo to show off and thank everyone for their help. Just reading on this board gives me a great learning experience.
Thanks a ton guys.
#14415 - sgeos - Tue Jan 06, 2004 4:52 am
You'll want to hold your map in a (large) array in ram. When you change a value in the array, set an update variable. Every frame check that variable. If it is set, then call a screen update function and reset your update variable.
You'll probably call the screen update function the first time the screen is drawn. It's job is to take your game's internal representation of the map, and turn that into graphics on the screen.
-Brendan