don't click here

So I made something that renders Sonic Rush level maps

Discussion in 'Engineering & Reverse Engineering' started by Techokami, Dec 11, 2010.

  1. Techokami

    Techokami

    For use only on NTSC Genesis systems Researcher
    1,373
    81
    28
    HoleNet!
    Sonic Worlds Next
    Yeah it's nothing special, but it is the first thing released to the public that deals with levels in Rush-based games.
    To make it work, you need a few things:
    • A ROM, obviously, to get files from. You can try it with <a href="http://info.sonicretro.org/Sonic Rush (E3 beta)" target="_blank" style="background: url(http://info.sonicretro.org/images/5/50/Reticon.png) right no-repeat; padding-right: 20px; border-bottom: 1px dotted #3366BB; color: #3366BB; cursor:pointer; text-decoration:none;" class="wiki">Sonic Rush (E3 beta)</a>.
    • Tahaxan, or some other DS ROM file extractor plus a NARC extractor tool, to extract the files out of the ROM.
    • These three scripts. Don't forget to change the extension to .php after downloading!
    • Something that runs PHP and has the nuts to handle creating bigass images.

    So, you go into the ROM and take from the desired level's NARC files:
    • The .bk file, which is the metatile mappings
    • The .ch file, which is the graphics data
    • The .pl file, which is the palette data
    • The .mp files, which are the level map data (one has an "_a" suffix, the other a "_b" suffix)

    Now, you put these files into a directory that is in the same location as the three scripts. Then, you run rush_levelrip.php?game=A&level=B to generate the metatile images, which should only take a few seconds.
    You replace A with the directory you put the files in, and B with the name shared by the files you extracted, usually a z with two numbers.

    Finally, you run srlp.php?game=A&level=B to make the map images. This may take a minute or so to run, Sonic Rush levels are very large.
    You replace A with the directory you put the files in, and B with the name shared by the files you extracted, usually a z with two numbers. You can optionally add in &meta=C, where C is a manual override for the metatiles to use. You won't need to use this, unless you're trying to make maps of the hidden island stages in Sonic Rush Adventure.

    Also, in case you're wondering, here's how the .mp files are put together: the first word is the width of the level in metatiles (which are 64x64 pixels), the second word is the height of the level in metatiles, and every word after that until the EOF is a metatile ID. Little endian!

    Hopefully this will encourage someone to look deeper into the other files that make up levels in the Sonic Rush games, or even start making a level editor! :)
     
  2. Cruizer

    Cruizer

    Member
    28
    0
    0
    Australia
    Reverse Engineering the Rush series
    So will this only work with Sonic Rush, or can its sequels actually work with this?

    Had to increase PHP Memory allocation to 256MB to get these:
    Leaf Storm 1-A
    Leaf Storm 1-B
     
  3. Techokami

    Techokami

    For use only on NTSC Genesis systems Researcher
    1,373
    81
    28
    HoleNet!
    Sonic Worlds Next
    I wasn't very clear about it, but yes it works with any of the sequels (Rush Adventure and Colors)
     
  4. Cruizer

    Cruizer

    Member
    28
    0
    0
    Australia
    Reverse Engineering the Rush series
    Well thats good to know. :P

    I've done a little bit of snooping in the zone/act data myself, and it seems that the .rg files store the locations for rings. I've only gotten the basics of moving rings around, and am still having troubles understanding/properly moving them. But perhaps this information may be helpful in getting more features added to the maps? (Like Badniks and Springs/Gimmicks)

    I haven't a clue on how the Mapping scripts work, let alone know anything about PHP, so I can't say that I can help in the actual development of the mapping procedure, just that I have the capabilities of running the scripts :P

    EDIT: All maps have been done, except for Blizzard Peaks 2, and the hidden Islands.

    Sonic Rush
    Sonic Rush Adventure
    Sonic Colo(u)rs

    I have someone working on combining them at this very moment. So I'll updated when we have completed map layouts.
     
  5. Sparks

    Sparks

    Member
    3,144
    182
    43
    Sondro Gomez / Kyle & Lucy
    Those maps are freakin huge. :psyduck:

    And I see this got featured on the front page :v:
     
  6. Cruizer

    Cruizer

    Member
    28
    0
    0
    Australia
    Reverse Engineering the Rush series
    New update: The maps for Rush have been merged.

    The ring mappings seem to be going well, once we've conclusively found a way to put them in the map, the maps will look much prettier.
     
  7. Techokami

    Techokami

    For use only on NTSC Genesis systems Researcher
    1,373
    81
    28
    HoleNet!
    Sonic Worlds Next
    whaaa? =O
    Please do explain what you do know about the .RG files!
     
  8. Cruizer

    Cruizer

    Member
    28
    0
    0
    Australia
    Reverse Engineering the Rush series
    Well, I've only tested it with Leaf Storm's Boss map, and really only tested vertical movement, but locations are stored in the latter half of the file. And this format seems to be consistent with all other levels and bosses (including Rush Adventure and Colours), and this format is even used in Sonic 4.

    Anyway, looking into z13.rg from Sonic Rush, 0x20 seems to be the location where the locations are stored.

    the 06 00 values (at 0x20/0x21 and 0x2E/0x2F; I -think- they both denote it, I may be wrong yet) determine how many locations are to follow. after which, the values are matched in pairs. XX and YY. The XX value is the horizontal position (from the left; in pixels by the looks of it), and YY is the vertical value, coming downwards from the top.

    I'm also speculating that the first four values denote how many blocks there are of rings, or possibly something to do with the size of the ring map, and each block (I think it may be 256x256px or something around that size) is given a number of rings in it. I'm not entirely sure how this works yet, and this is only just educated guessing. I could be deadly wrong on this though. Thankfully, someone is helping me with it, so we'll get it soon yet.

    Oh also, .dc and .ev files (also within z##_eve.narc along with .rg) seem to also control objects. I've been focusing with rings at the moment, so I haven't a clue on these just yet.

    EDIT: Demonstrating. I changed 0xE0, 0xE2, 0xE4 (in z13_eve.narc) from "E8" to "D0" Here are the results:
    Before:
    [​IMG]

    After:
    [​IMG]
     
  9. Cruizer

    Cruizer

    Member
    28
    0
    0
    Australia
    Reverse Engineering the Rush series
    I know double posts are a cardinal sin, but it is with a breakthrough.

    I have the .rg files completely figured out.

    The first two words in the files, determine how many blocks of 256x256 pixel sections there are in the ring map.

    Then follows a a number of sets of two words, the first points to offset of section's ring modifier, the second is -always- 0. The number of sets corresponds to the number of sections.

    Finally, when at the offset the pointer specified, we get another word, which tells us how many rings there are in this section. After which, it is followed by two values/bytes, each for the X and Y positions within the section (as stated above).


    Example:
    [​IMG]

    First word 0052 (the values are backwards, I don't know why, but this is a key to this entire thing. Or perhaps it's always like this, and I'm completely new at hacking) means 82 horizontal sections (since 52(HEX) = 82(DEC)).
    Second word 000F; 15 vertical sections.

    Third word (appears 3C 13, but is actually 133C, pointing at 0x133C)

    [​IMG]
    [​IMG]

    Since this is the first section, we can see that the previous two words point to the last section. And by reading the word at 0x133C/0x133D, we can see that there are 0 rings. So lets go to a word that gives rings, namely the one on screen at 0x13C6.

    It says 09 00, which means 9 rings. the following values are the X and Y values (in hexadecimal pixels) of each ring. So there is a ring at each of the following:
    <div class='codetop'>CODE</div><div class='codemain' style='height:200px;white-space:pre;overflow:auto'>(192, 160)
    (192, 184)
    (192, 208)
    (192, 232)
    (192, 136)
    (216, 152)
    (216, 176)
    (168, 152)
    (168, 176)</div>


    And there you have it. .rg files are done and dusted. I'll move onto .ev and .dc files tomorrow and stuff. They look similar so it shouldn't be too hard.
     
  10. Techokami

    Techokami

    For use only on NTSC Genesis systems Researcher
    1,373
    81
    28
    HoleNet!
    Sonic Worlds Next
    Endians. The files in Rush use little endian format.

    But very nice and thorough analysis of the rings layout data!

    So here's the parts of a level we know:
    AT - Level Attributes (needs further exploring!)
    BK - Block Mappings
    CH - Character Data (graphics)
    MP - Map Layout (_a for Layer A, _b for Layer B)
    PL - Palette Data
    RG - Rings Layout
     
  11. Cruizer

    Cruizer

    Member
    28
    0
    0
    Australia
    Reverse Engineering the Rush series
    There is reason to believe that the .dc files are Badnik Locations, and .ev are all other Stage Objects, like Springs, Trick Rings and stuff. They are very similar to the format of .rg, but they differ so that all the different objects are able to be put in. So once again, I'll do some testing on a boss, and report back :P

    Also just to question about the .at files, Leaf Storm Boss' was just rows of 00 values. So what attributes would it possibly be?
     
  12. Techokami

    Techokami

    For use only on NTSC Genesis systems Researcher
    1,373
    81
    28
    HoleNet!
    Sonic Worlds Next
    Polygon Jim mentioned over MSN that DC files are Decoration Locations, and that EV is for other general objects.
    AT has at least information about where the top to bottom screen threshhold is.
     
  13. Cruizer

    Cruizer

    Member
    28
    0
    0
    Australia
    Reverse Engineering the Rush series
    If this is true, then how do we explain the values of 00's through the boss levels?
     
  14. Techokami

    Techokami

    For use only on NTSC Genesis systems Researcher
    1,373
    81
    28
    HoleNet!
    Sonic Worlds Next
    Because bosses only work on a single screen in Sonic Rush? To be honest I'm not completely interested in boss stage hacking, I'm focusing more on the normal levels.
     
  15. Polygon Jim

    Polygon Jim

    Eternal Tech Member
    0
    3
    0
    across town from Hinchy
    All the bitches.
    Good work on the .rg files, though for future reference you should probably check out big/little endian byte orders so you'll understand why things are in "reverse".

    I'm not %100 positive if the .dc files will be decorations in Rush, but they are in S4 which uses the same naming system for everything so I would assume they still have the same function between the games. Good luck on the .dc/.ev files.
     
  16. Tanks

    Tanks

    Member
    1,048
    108
    43
    Ahem: http://forums.sonicretro.org/index.php?showtopic=11076

    Anyway, yea, awesome work. I think I know someone who'd be willing to turn this into a level editor once this all gets figured out.
     
  17. Techokami

    Techokami

    For use only on NTSC Genesis systems Researcher
    1,373
    81
    28
    HoleNet!
    Sonic Worlds Next
    I meant a usable program, rather than just information.
     
  18. Cruizer

    Cruizer

    Member
    28
    0
    0
    Australia
    Reverse Engineering the Rush series

    Hey thanks :P
    I guess I should, probably to understand this. And yeah, Sonic 4 has a similar naming system, except I've heard that it's not in Little Endian format.


    Well Boss stages are small enough for me to make minor edits and see what happens. If I had something that could decompress, and recompress .narc files properly, then I could literally swap objects around and see what happens, making the understanding much easier; Trial and Error is my choice of weapon :P


    If Java can create images, and read these game files in HEX, then I think I'll give it a shot myself.



    While .dc, and .ev use similar format (like screen sections, and pointers), the actual object placement is obviously different. It seems to be that they have the same "Number in a section" as the rings do, however that they have extra values to identify the object. DC has four values (two words by the looks of it): X/Y position, and the object identifier. EV has 12, although other than the X/Y position word at the start, I don't have a clue what the other 10 do :P. I guess that's my task for the day.
     
  19. Polygon Jim

    Polygon Jim

    Eternal Tech Member
    0
    3
    0
    across town from Hinchy
    All the bitches.
    I was checking it out earlier and the .rg format between Rush and S4 and they are nearly identical besides the byte order. The only other difference is the pointers at the beginning are a dword(4 bytes) instead of a word(2 bytes). Besides that they are identical though it seems.
     
  20. Cruizer

    Cruizer

    Member
    28
    0
    0
    Australia
    Reverse Engineering the Rush series
    Well, that sounds right then, but beecause we aren't going to get massive stages (with fucktons of rings), it's most likely those other two values in that dword will remain at 00 :P

    Also looking elsewhere in the Rush ROM, it seems that object data is stored in /act. So perhaps there is something within those Sprite files that is used in .ev/.dc.

    Also since I can't do it, is someone working on how to make visual mappings so they can be combined with the maps?