[Tanks]

Yeah it's nothing special, but it is the first thing released to the public that deals with levels in Rush-based games.

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.

[Techokami]

Ahem

I meant a usable program, rather than just information.

[Cruizer]

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.

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.

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.

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

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.

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.

This post has been edited by Cruizer: 22 December 2010 - 11:49 PM

[Polygon Jim]

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.

[Cruizer]

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?

[Techokami]

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.

Be careful! It seems that, partway in development, they switched things up. Each level has another archive that goes with it, the act_lz7 archive (the suffix means the archive itself is lz77 compressed) that contains level-specific actor collection files (where actor, in this case, means objects like enemies, items, gimmicks, etc), and there is also the archive act_com_lz7.narc which contains generic stuff like special effects and HUD elements. The ones in the /act directory seem to be residual files that are left over from a previous state of development (in fact they still lingered in the E3 beta but I don't think the game actually uses them even then!) and was cleaned up and cleaned out in Rush Adventure and Colors DS.
The actor collection files themselves contain graphic placement data, animation data, palettes, and graphics for certain object(s). For example, the rocket launcher Egg Pawn's file contains the badnik itself, and the rockets it fires.

[Cruizer]

Hope you guys had a good Christmas and new year :P

I've only just gotten onto deciphering .ev/.dc files, and so far, I haven't gotten a way to test them. .ev seems to be too inconsistent for me to understand for now, so I can't really report on them. Not to mention I don't understand what the decoration files do >_>

.dc however, I can explain its format. They are extremely similar to .rg files, except that there is a word after the X/Y locations for the object, which presumably denotes which object is at the location. I'm not sure what these values exactly say, but this is a start :P.

Also about these 256x256 sections, I'm not sure which way they are aligned on the map, other than Left to Right. I cant tell if it goes from the bottom row left, to top row right, or the other way around.

But thats all for now.

This post has been edited by Cruizer: 05 January 2011 - 11:07 PM

[Cruizer]

Alright, it's now confirmed .dc are decoration files. To prove, may I introduce you to section 253:


Do note, that this has been scaled down by a factor of 2. So any position given by any files is halved. Luckily we have no odd value objects :P
You'll notice 6 irregular black parts. These have been added by paint. the 253 so that we know this is section 253. The line towards the bottom right is...a smudge. It shouldn't be there, but no matter >_>

The other two dots, are special locations. The one at the top, is the spring. It's code is given as such:

CODE

z11.ev:

Block 253 Pointer.
Location: 0x3F4 - 0x3F7
Value: 30 16 00 00

Block Contents.
Location: 0x1630 - 0x163D
Values: 01 00 28 40 43 00 00 00 02 00 00 00 00 00

Now, springs like this are given the identifier 43 00. You can swap any object to a spring by making the word after the location values to 43 00. The isolated 02 value, seems to be a singular byte, and it relates to how high or low the spring bounces Sonic/Blaze. I've tried testing this value, however there doesn't seem to be a pattern to them. Values of F0-FF, 70-7F are little or no bounce at all. Values of 00-0F seem to be regular spring bouncing. 30-3F is pretty strong, however 40-4F is far stronger. I'll try looking into this more later, it's pretty confusing.

Now onto the .dc; This is what the .dc file says about that block:

CODE

z11.dc:

Block 253 Pointer.
Location: 0x3F4 - 0x3F7
Value: 94 16 00 00

Block Contents.
Location: 0x1694 - 0x169A
Values: 01 00 10 C8 10 00

Here's what it looks like in game:



Now this isn't -just- block 253. but it's the part we care about. That flower you see? THAT is what the .dc file is creating. So we now have a way to map decorations! Except we have to find all the decorations first, and if there isn't an easy way to do so, then I'll just produce sprites for it.

Also partially related, does anyone have something that can view .bac sprites?

This post has been edited by Cruizer: 12 January 2011 - 02:28 AM

[Cruizer]

So we're finally getting somewhere. I have preliminary rings maps for each 3 games. A friend is currently syncing them with the currently standing maps. So we're almost there! Techokami, the help I requested last night on IRC is no longer needed; it turned out I goofed up part of my recursive function (specifically, using the wrong variable). I'm about to get a script that reads .ev and .dc files, however it will be difficult. My current plan to do this will be to map out placeholders, sync them with the map and then play through each game until each object/event/decoration ID is taken down. After which, I'll (somehow) get necassary sprites, and rerun the script, but instead of having placeholder images used, I'll get the actual sprites in. At that point, the maps will be complete :P

Finishing these won't be it for me though, I'll be following through with hopes of developing a level editor. So in the meantime, here's a ring counter which counts how many rings there are in each map, and how big the map is (almost) in 256x256 pixel blocks.

Here's the script I used in it's entirety. It'll later be modified to work with .ev and .dc files. It also needs libripper.phps which is linked in the first post of this thread. Enjoy :D

[Max Firestorm]

Hmm... With this, is it possible to get things like the "cutscene" dialog sprites from Colours? I know the ones from Rush and Rush Adventure have been ripped (At least partly) but I'm having trouble finding the Colours ones on places like Spriter's Resource

[Techokami]

Decorations and other objects are stored as .BAC files. A friend of mine mapped out their innards a while ago and I really need to make a tool that rips from them directly :P

Also, like I told you earlier Firestorm, the cutscene sprites are stored as background images (BBG files) which are some sort of compressed 8bpp image data. You either need to use an emulator with a layer viewer, or crack the format.

[Cruizer]

Well frankly I can't make sense of that documentation of the sprites. I'd help, but I don't have a clue about palette data ^^;
However, I can make the mapping scripts without the sprites for now, since I only need to read a single file. I already know enough about .ev/.dc files to place them on a map, so I'll have them done by Thursday hopefully (since I'm now back at Uni, I can't do it today >_>). Soon, we shall have finished maps for all 3 games!

[Techokami]

but I don't have a clue about palette data ^^;

GBA 4BPP format. It's supported by libripper.

function makeGBAPallete( $source, $gd, $keeptrans = FALSE )
Generates an array of color data representing a palette in the GBA 4bpp format.
$source: address of palette data in working file
$gd: GD graphics resource to link this palette to
$keeptrans: preserve color index 0? If true, override color index 0's data with pure magenta. Defaults to false because a lot of palettes use a bad color for index 0 (leading to black on black) making the creation of alphatransparent images difficult.

I should make some docs for this thing.

[Max Firestorm]

Decorations and other objects are stored as .BAC files. A friend of mine mapped out their innards a while ago and I really need to make a tool that rips from them directly :P

Also, like I told you earlier Firestorm, the cutscene sprites are stored as background images (BBG files) which are some sort of compressed 8bpp image data. You either need to use an emulator with a layer viewer, or crack the format.

Totally didn't realise it was your thread XDD I obviously wasn't awake when I posted that...

[Cruizer]

So right now, there isn't anything that can create/view .bac sprite files?

Also I think I've made enough modifications to my script so it can handle all 3 map_eve files (rg, dc and ev). Although, until those .bacs are cracked and images are mapped, I can't actually go any further with the map creation due to lack of resources.

Also perhaps collision information is stored in .bac files? It doesnt seem that they are stored anywhere else.