S2-SMS tilemaps

Holy crap! That proto tree in SHZ is still in!

Good job, Ambil, great to see hacking of this wonderful game.

 

uhhh, proto tree..?

 

<!--quoteo(post=198352:date=Jun 2 2008, 08:50 AM:name=Ambil)--><div class='quotetop'>QUOTE (Ambil @ Jun 2 2008, 08:50 AM)

The giant tree is not a proto tree. It's in the final game.
[/quote]

In the SMS version at least. Sorry, I have a better memory of the GG version. :P

 

Nice work indeed. Perhaps now GHZ3 can be hacked to not be so sadistic. =P

Also, I see that things like springs and rings are actual level tiles. Were the SMS/GG unable to handle objects placed in the level or something, because having to place them like pieces of level layout seems very inconvenient.

 

Heh, it looks like you can freely swap the foreground graphics (first half, from 1 to 87) between any two levels and they'd still look good.

 

Yeah, I'm stupid, I looked at Rolken's maps and saw it.

Spikes are also the same case here.

 

And, where are the Ending (Beta GHz) tiles?

 

Um... not to detract from your achievement, but before you spend time making handmade charts for the other 8-bit games, you can use this script as sttrom.php?level={3*zone}&game={s2gg|chaos|stt}&blocks=1 to generate block maps similar to those automatically, selecting/replacing the {} contents as appropriate. I guess I should have uploaded them myself, I didn't think anyone particularly cared

Anyway, if you want to use it but can't get it to work or don't know how or don't like how it displays, let me know and I can force myself through the trauma of reinstalling apache etc. <_<

Also, to elaborate on Ambil's response to the ring/spring/etc level tile oddities, when objects are defined as the "background" they can be scrolled effortlessly by the graphics chip by just moving the visible section of the graphics memory around, whereas if they're sprites you have to do all the scroll positioning manually on the z80. Plus the graphics chip had a pretty low sprite limit that you can already see creating issues when you get too many things on the same scanline. Note that the sum of sprites in the entire level is a moderate limitation but not really as much of a problem as how many things are onscreen at once. When sprites leave Sonic's general area, the game just stops tracking them outside of whether they exist; nearby sprites are much more expensive. But background objects are pretty close to cost-free, so it's a no-brainer to use them for things that don't move.

Relatedly, all the different item boxes except the 10ring share one block and one set of tiles in VRAM. When you get close to one, it reloads the relevant image into VRAM before the box scrolls onscreen. And I forget if Sonic 2 specifically uses this effect, but there are often several rings in a level that are defined as sprites instead of background in order to stick them in front of something or within a loop. STT does that right when you start the first level, which is why one of the rings looks out of sync with the others.

Knowledge is power!

edit: Whoops, I didn't realise this topic was so old. Oh well, what's done is done.

 

I don't think this is the big reason for defining objects in the level layout, since you can have the object definitions separate from the level layout and still draw them using background tiles instead of sprites. I do this with some objects, mostly rings and item boxes, in the NES game I'm making, since it has similar sprite limitations to the SMS. The cost for drawing them with background tiles on top of the level layout is practically the same as drawing with sprites though.

I believe that the main reason for this is that the objects don't need to be treated like individual objects with their own slice of RAM and their own AI routines, which is what really kills CPU time. Just play Sonic Chaos and see how the game lags when you approach a loop, which has only sprite rings. I don't think it's because of the sprites used, but because each ring must check for collisions with Sonic, while with the background rings, Sonic is the one that collides with them (because the physics engine already processes collisions with the level map, so it's just a matter of checking if the blocks he touches are ring blocks), so there is no need to process each ring individually.

I believe that the 8-bit machines can hendle a similar scheme as used in the MD/GEN games, and so far my NES engine is handling it pretty well, as there is plenty of CPU time left (although I haven't implemented the main object yet, which is Sonic), with the only big difference being that some objects are drawn with background tiles in order to save sprites.