Tile streaming engines in games with large tile counts

Ask anything your want about Megadrive/Genesis programming.

Moderator: BigEvilCorporation

Post Reply
BigEvilCorporation
Very interested
Posts: 209
Joined: Sat Sep 08, 2012 10:41 am
Contact:

Tile streaming engines in games with large tile counts

Post by BigEvilCorporation » Sun Sep 06, 2015 6:59 pm

Hi!

My artist and I have a small tech demo of our game which is looking and playing really nice, but it's using all of the available tile space (1536 with current register settings) for just one small section of a level. We've spent a fair while redesigning parts of the level and shuffling tiles around to make them reusable and managed to wrangle it down a bit, but with each iteration we lose quite a lot of graphical fidelity.

I've been looking into tile behaviour of titles with comparable graphics, and it seems a few games stream tiles in as the player moves around.

Sonic 3 loads a new section of level every so often (I dumped the VDP memory to a bitmap at various stages of the level and compared with an image diff tool) but nothing too fancy, which might be manageable if we could split the level up into sections and ensure the tile counts of any one "screen" (scroll plane width x height) don't spill over.

Sonic 3D Blast's tile view looks absolutely mental; it seems to stream in rows of tiles with every movement. It's a very graphically rich game so no surprises there.

I'd like people's thoughts on tile streaming engines - best methods of authoring the levels in a way which allows for streaming without any one view exceeding a set number of tiles. It would probably require the engine to calculate tile IDs in realtime and upload rows/columns of map data along with the tile graphics (at the moment I just have a map data streamer, the tiles are static, but could be expanded to modify the IDs as it uploads). I guess tiles would have two IDs - one is the index in the ROM, one is the index in the VDP - with a reference count in RAM for each tile (or perhaps I could get away with just a bit vector of tiles which must be loaded, but there would be extra CPU cost scanning the current section of map to set/unset the bit).

I might prototype a few methods and see how it goes, but in the meantime has anyone tackled this problem before?
A blog of my Megadrive programming adventures: http://www.bigevilcorporation.co.uk

Sik
Very interested
Posts: 936
Joined: Thu Apr 10, 2008 3:03 pm
Contact:

Re: Tile streaming engines in games with large tile counts

Post by Sik » Mon Sep 07, 2015 2:36 pm

BigEvilCorporation wrote:Sonic 3D Blast's tile view looks absolutely mental; it seems to stream in rows of tiles with every movement. It's a very graphically rich game so no surprises there.
That's exactly what it does, it streams the tiles as you scroll around. The engine has support for up to 4096 tiles for a level (for context, that's twice the size of VRAM), and that's just for plane A (the floor is done with plane B, though those tiles are not streamed). The big downside of Sonic 3D's method is that they had to leave all those graphics uncompressed, which is why the ROM is so tight in space... (and reminder that it's a 4MB game, i.e. it maxes out the address space without mappers)

Sonic 3D does something similar with objects as well (save a few common ones such as rings), it dynamically allocates room for them as they appear on screen and streams their sprites. Again, this means their graphics have to be left uncompressed in the ROM. Ouch.

EDIT: oh, also, before I forget:
BigEvilCorporation wrote:I guess tiles would have two IDs - one is the index in the ROM, one is the index in the VDP
Sonic 3D just reuses the same format for addressing the tiles (albeit now the IDs refer to ROM offsets rather than VRAM offsets), there's no "VDP index" because that's really just calculated off its position on screen. They sacrificed one palette bit in favor of doubling the amount of possible tiles (yup, the stages only use two palettes, floors aside).
Sik is pronounced as "seek", not as "sick".

Stef
Very interested
Posts: 3058
Joined: Thu Nov 30, 2006 9:46 pm
Location: France - Sevres
Contact:

Re: Tile streaming engines in games with large tile counts

Post by Stef » Mon Sep 07, 2015 5:16 pm

Not related to the topic sorry but both links in your signature are outdated Sik.

BigEvilCorporation
Very interested
Posts: 209
Joined: Sat Sep 08, 2012 10:41 am
Contact:

Re: Tile streaming engines in games with large tile counts

Post by BigEvilCorporation » Mon Sep 07, 2015 5:54 pm

Sik wrote:They sacrificed one palette bit in favor of doubling the amount of possible tiles (yup, the stages only use two palettes...
Wow, really? I was concentrating on the colours and trying to figure out how they squeezed so many in. Take Panic Puppet for example, the amount of greys used for the shading of the metal pipes. Plus rest of the scenery, plus Sonic, plus enemies, plus Flickies...

Time for harder look at that game.
Sik wrote:...floors aside
How do you mean? How did they split up plane A and B drawing with separate palettes?
Sik wrote:there's no "VDP index" because that's really just calculated off its position on screen
Ahh that makes sense. It didn't even occur to me that you could a whole plane's worth of tiles in at once. Is it 32H mode, or did they sacrifice some of the extra scroll width manually (software clamp and wrap)? 40H mode filled would need 2048 tiles, which is too many.
A blog of my Megadrive programming adventures: http://www.bigevilcorporation.co.uk

Sik
Very interested
Posts: 936
Joined: Thu Apr 10, 2008 3:03 pm
Contact:

Re: Tile streaming engines in games with large tile counts

Post by Sik » Wed Sep 09, 2015 12:59 pm

BigEvilCorporation wrote:Wow, really? I was concentrating on the colours and trying to figure out how they squeezed so many in. Take Panic Puppet for example, the amount of greys used for the shading of the metal pipes. Plus rest of the scenery, plus Sonic, plus enemies, plus Flickies...
Plane B and sprites don't have the two palette limit (they usually make use of the other two palettes, in fact).

Fun fact: the fiery flicky is just the pink flicky, but its portion of the palette got overwritten with the lava palette in Volcano Valley (I guess they left it as-is because it looks cool and fits the theme).
BigEvilCorporation wrote:How do you mean? How did they split up plane A and B drawing with separate palettes?
Hm, they aren't handled by the same routines? =P

But yeah. Plane B is used for floors (and slopes and things like the lava or running water), while plane A contains everything else that isn't a sprite. Since plane B uses its own tileset, it has different rules (for starters, only plane A has the two palette limit).
BigEvilCorporation wrote:Ahh that makes sense. It didn't even occur to me that you could a whole plane's worth of tiles in at once. Is it 32H mode, or did they sacrifice some of the extra scroll width manually (software clamp and wrap)? 40H mode filled would need 2048 tiles, which is too many.
41×29 = 1189 tiles. That's only enough for one plane though, which is why plane A is done like this but plane B isn't.
Sik is pronounced as "seek", not as "sick".

BigEvilCorporation
Very interested
Posts: 209
Joined: Sat Sep 08, 2012 10:41 am
Contact:

Re: Tile streaming engines in games with large tile counts

Post by BigEvilCorporation » Wed Sep 09, 2015 4:15 pm

Ah I misunderstood, I thought you meant some sort of palette swap happened between plane drawing, but that's not how VDP drawing works!

I'm going to implement this tile streaming and see how it goes. I doubt it'll be fast enough for the kind of speedy scrolling I'm after but no doubt I'll learn something along the way.

Bonus question: If you take a look at tile debug view in Regen whilst the intro FMV is playing, it's empty. Is that a Regen bug or are they doing something particularly clever to draw the FMV?
A blog of my Megadrive programming adventures: http://www.bigevilcorporation.co.uk

Sik
Very interested
Posts: 936
Joined: Thu Apr 10, 2008 3:03 pm
Contact:

Re: Tile streaming engines in games with large tile counts

Post by Sik » Sat Sep 12, 2015 11:58 pm

Regen bug, assuming you're looking in the correct place from VRAM =P

They are doing something clever in the monochrome FMVs, though (Sega logo and Game Over screen). They cram in four frames into a single image (using one bit of the pixel for each frame), then change the palette to show a single one of those frames. This is how they manage to make them 30FPS despite their size.
Sik is pronounced as "seek", not as "sick".

TapamN
Interested
Posts: 15
Joined: Mon Apr 25, 2011 1:05 am

Re: Tile streaming engines in games with large tile counts

Post by TapamN » Tue Sep 15, 2015 7:56 pm

BigEvilCorporation wrote:Bonus question: If you take a look at tile debug view in Regen whilst the intro FMV is playing, it's empty. Is that a Regen bug or are they doing something particularly clever to draw the FMV?
Regen defaults to displaying the tiles using palette 0 (which is all black), but the FMV uses palette 2. Click on palette 2 to use the FMV's palette.

BigEvilCorporation
Very interested
Posts: 209
Joined: Sat Sep 08, 2012 10:41 am
Contact:

Re: Tile streaming engines in games with large tile counts

Post by BigEvilCorporation » Sat Sep 19, 2015 9:36 am

Ahh yes, that'll be it. I was holding out for some insane optimisation!
A blog of my Megadrive programming adventures: http://www.bigevilcorporation.co.uk

Sik
Very interested
Posts: 936
Joined: Thu Apr 10, 2008 3:03 pm
Contact:

Re: Tile streaming engines in games with large tile counts

Post by Sik » Sat Sep 19, 2015 4:48 pm

Well, the 4bpp FMV is literally just each frame compressed with RNC (the same generic LZ-style compression format used for everythng else) and scaling it up vertically using raster effects (the low framerate kind of hides the fact they went with such a heavy compressor). There really isn't anything great about it and it takes up like about 150KB on the ROM. The two 1bpp FMVs are way more interesting in that sense.

I wonder how Red Zone does it, since the palette trickery wouldn't work there (due to the gradiented background, this needs flat colors to work).
Sik is pronounced as "seek", not as "sick".

Post Reply