So I made something that renders Sonic Rush level maps

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

 

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.

 

Those maps are freakin huge.

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

 

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.

 

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:


After:

 

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:


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)




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.

 

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?

 

If this is true, then how do we explain the values of 00's through the boss levels?

 

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.

 

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.

 

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.

 

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.

 

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?