Question:The other day I came across your website, and found it very interesting − especially your video game articles, and tales of life in Japan − in fact I'm actually drinking an Asahi beer as I write this. Incidentally, I was once a subscriber to "The Journal of Computer Game Design", and remember reading your tutorial with Dan Chang at the end of 1992 about the programming of the NES M.C. Kids.

I've got a couple of questions, and wonder if you can assist with any advice about the following and/or point me in the direction of any further resources, such as good links on the Web?

(1) Curved Platforms.

I'm just getting into OpenTUME, so I'm sure this question may be answered after a little experimentation. With curved / variable height walking surfaces, such as those found in games such as the SNES Earthworm Jim, because TUME is so feature−rich, in order to get a Quick Start, what specific areas of TUME should I be learning about, or concentrating on to implement this?

(2) Object Management Systems.

Being interested in Gameboy Advance programming, I'm researching the various (possibly innovative) systems and ways that programmers managed the SNES and Genesis object (sprite) memory. i.e. how they allocated and handled (a) the image data that was placed in VRAM once at the start of level and left there, and then 🍺 the other object image data which had to be DMA'd every frame, such as hero and enemy animations. Plus all the other considerations, such as different object sizes (8x8, 8x16, 32x32 etc.) that make up an image, and how to make best use of the object VRAM without any, or too much fragmentation. Did a few techniques gain prominence amongst developers, or did people end up using many disparate methods?

Answer:Generally I would think of VRAM as characters (characters = text = fonts = one 8x8 16 color block of memory on the SNES/Genesis or 4 color on Gameboy. I don't know the details of GBA but it looks like a SNES (since they are porting SNES games) so I'm going to assume it's similar.

So up front I would decide that say the first 900 characters of VRAM were going to be used by the backgrounds. Those would be loaded once at the beginning of the level. Some of them may be updated in realtime to produce what we called "animated chararacters". An example would be the water and grass and plants in any 2D Zelda game.

Using tUME and TP16 you could tell TP16 various character animations and it would arrange them so they were all contiguous in VRAM so that uploading them could be as quick as possible.

It sounds like you may not have done console programming before. Up until has PS2/Dreamcast almost all programmers treated VRAM as VROM. In otherwords, NOTHING CHANGES IN VRAM UNLESS IT ABSOLUTELY HAS TO. This was even true for Playstation 1. Unlike say PC programming where you don't know how much VRAM you're going to have so people treat it like a cache. On consoles taking this position will guarntee that you're game will not perform on par with it's peers.(1)

Of course you do have to update VRAM sometimes. For sprites generally you'd just do start at the top of available VRAM (backgrouds started at bottom) and DMA what you need into VRAM for each character's sprites. Same with the sprites themselves. You're system may have 64 sprites available, your first character needs 12 of them, you use the first 12, the next character needs 7, use the next 7. Every frame you'd do this all over again. I call this planning for the worst case. On consoles, until the PS1, all games were required to run at 60hz (or they'd look lame compared to the competition usually). In order to achieve that you need to make the WORST case work fast. Not the best case. Adding code to check if something is already in VRAM or tracking where characters are in VRAM will only slow down your WORST case meaning that you will stop running at 60hz faster than if you had done it the other way and just did it all every frame. I'm almost pretty sure that's how GBA will playout too.

For sprites you might have a struct like this to define one shape of an animation

struct spritebasedimage { byte width; // in sprites byte height; // in sprites byte spritedata[width*height*sizeof8x8char]; }

So you'd mult width*height to figure out how many sprites you needed, you'd arrange those sprites into a rectangle and DMA the image data to VRAM.

A more compressed format might be

struct spritepos { byte xoff; byte yoff; byte flags; // like xflip, vflip } struct spritebasedimage { byte numsprites; spritepos spritesinfo[numsprites]; spritedate[numsprites*sizeof8x8char]; }

The advantage here is that the sprites don't have to be in a rectangle they can be in any strange arrangement. Usually we wrote tools that given an image file would figure out a semi optimal arrangement and write it out.

Also we always used assembly so the structures above are actally possible in assembly vs C where you can't have variable sized inline arrays.

As for curved platforms you should download tumedocs.zip and read TP16.doc