don't click here

S2-SMS tilemaps

Discussion in 'Engineering & Reverse Engineering' started by Ambil, May 26, 2008.

Thread Status:
Not open for further replies.
  1. Ambil

    Ambil

    I want that heinous hedgehog hammered! Member
    893
    0
    0
    Spain
    Fo'real this time, three years after my epic release of S2-SMS block maps, I present original work made by myself.

    As said in Hivebrain's SONIC 2 MASTER SYSTEM ROM HACKING GUIDE, levels are made up of blocks (32x32 pixels each), which are composed of tiles (8x8 pixels each).

    Every zone has its own block configuration, and it's uncompressed in ROM. If you remember my blockmaps, every pixel (I.e. every byte) means a 32x32 block.

    What I'm presenting is the collection of all blocks used in every zone. If you review them carefully, you will note some blocks are unused at all in the zone. Also, rings, springs and spikes are included here. They're considered part of the background because the SMS/GG doesn't have enough resources to handle lots of them as single sprites.

    Please note that, as all this work is hand-made (copying, flipping and pasting tiles from the ROM), some of the tilemaps are incomplete. I'm not out to finish all decorations such as all variations of grass and bricks in ALZ or all clouds in SHZ.

    Level maps:

    UGZ | SHZ acts 1/3 | SHZ act 2 | ALZ acts 1/3 | ALZ act 2 | GHZ | GMZ | SEZ acts 1/3 | SEZ act 2 | CEZ acts 1/2 (unfinished) | CEZ act 3 (not even started)
     
  2. SGR

    SGR

    Give me the gams. Member
    Holy crap! That proto tree in SHZ is still in!

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

    Ambil

    I want that heinous hedgehog hammered! Member
    893
    0
    0
    Spain
    Heh. Thanks.

    I bet there are loads of blocks unused at all in the game. I will do a complete list comparing with the level layouts, and in a few days we'll have the final list of unused blocks.

    Some of them have been already confirmed.
     
  4. SMTP

    SMTP

    Tech Member
    uhhh, proto tree..?
     
  5. Ambil

    Ambil

    I want that heinous hedgehog hammered! Member
    893
    0
    0
    Spain
  6. SGR

    SGR

    Give me the gams. Member
  7. Ambil

    Ambil

    I want that heinous hedgehog hammered! Member
    893
    0
    0
    Spain
  8. Robjoe

    Robjoe

    Member
    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.
     
  9. Ambil

    Ambil

    I want that heinous hedgehog hammered! Member
    893
    0
    0
    Spain
    Placing rings in third acts will be one of the improvements in my next hack.

    It was made to make it easier for the SMS. The Z80 would stress too much if hundreds of sprites were defined. Note there aren't many sprites in the SMS games.
     
  10. ICEknight

    ICEknight

    Researcher Researcher
    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.
     
  11. Ambil

    Ambil

    I want that heinous hedgehog hammered! Member
    893
    0
    0
    Spain
    Yes, because collision data is the same for all blocks with the same number, regardless the zone they are in.
     
  12. SGR

    SGR

    Give me the gams. Member
    Yeah, I'm stupid, I looked at Rolken's maps and saw it.

    Spikes are also the same case here.
     
  13. Mastered Realm

    Mastered Realm

    A green crystal Member
    And, where are the Ending (Beta GHz) tiles?
     
  14. Rolken

    Rolken

    Tech Member
    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.
     
  15. 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.
     
Thread Status:
Not open for further replies.