Sonic R Hacking

Oh hey, thanks! Do you think I'll need to reverse each byte as I read forward, or read the whole file backwards? Or do you think the values are stored in there as they really are, in order, and structed out?

 

There is this info on the .GRD format that someone posted in one of my threads about it on Cult about 3 years back:

http://forums.x-cult.org/topic/2551-never-...dpost__p__44276

 

I found the post MainMemory was mentioning about SANik's model format notes, they look to be pretty detailed! Whether Sonic R uses this format or anything like it though.. not sure, since they were by Traveler's Tales.

http://sadxforum.freeforums.org/sanik-s-no...ormat-t191.html

 

MainMemory: Ooh :o

I'm not good with binary, but I'm in it for the learning experience here Python has some modules for handling binary so I'll see if I can get SANik's notes to work for a NiGHTS file first.. speaking of which.

Anyone have a NiGHTS model file I can use with that link?

( Repost of link: http://sadxforum.freeforums.org/sanik-s-no...ormat-t191.html )

 

Running some experiments on it, but just getting garbage data. I am seeing a big difference trying both big endian and little endian though. The garbage looks a lot more even in its randomization in big-endian, so I guess that's a start. :P I wasn't sure if there was a chance that developers converted to little endian when porting the game over to pc.

I read about a "vertex buffer" on the NIGHTS notes, that means I should expect to find a chunk of data that's 3*4byte vertex data right? Or am I gonna get chunks of structs like [vertex, whatever], [vertex, whatever] instead of [vertex, vertex, vertex, vertex]?

 

If we had both versions of the file we could probably do a checksum or quick compare to see if they're the same file.. I might have the saturn version lying around somewhere, could check after class.

So you think the model format has nothing to do with the NiGHTS format in SANik's notes?

 

I dunno if anyone came up with this already but I call it a "razter" :P
Unfortunately, it didn't work the way I planned, so I guess I can't call it anything but a point cloud, but here's what I got so far.

I wrote a python script to consume the entire model file 3*4bytes at a time, convert it from fixed point to float based on 16.16 (thanks cy, and thanks SANik's tutorial), and then I wrote it out into a point cloud hoping I'd be able to pick out a model at one of the offsets.

No go, but the resulting point cloud does lead me to believe it's Big-endian. The little-endian results seem like something that would happen when a byte is flipped around, looking kind of exponential. (Edit: I realized later on an offset forward by one would probably give the same effect.. so now I'm just confused xD )



I can post my code if anyone wants it. I'm kind of stuck what to do after this- if it's anything like nights it should have a float array and would have matched up at some point in the offset. Maybe I should try padding next. Maybe I should try IDA but I've no idea where to start there.

If only we could tell what part of the file Sonic R was accessing and tell when it was accessing it.. any ideas what to do from here? :|

 

FINALLY some kind of progress. I took a pot shot with a hex editor and FF'ed out a random block of addresses.. and I found the general area of the vertex storage location :D

I made an FF block from 0x5A0-0x710. Note to self, the first few bytes of that FF block seem to effect the lower left spike.

Here's the file if you want to see where the edits were made:
http://intertricity.com/retro/exp1/sonic_h.bin

I still have no clue what the beginning part of this file is, but I could guess that the vertex buffer might start vaguely around 0x4F0 since there seems to be a lot of 00's between that and the data at the beginning of the file.

Also... why in the world did the verts implode instead of zoom out? I set the values to FFFF.. and when I run the fixed point calculation on FFFF I get something like 1.0. If the model goes from 0.0 to 1.0 values, shouldn't the verts have exploded instead? Maybe the algorithm I'm using for fixed point is wrong :x

 

Personal notes so far (I fill these selections with FF's):
* Means I may have misread my handwriting

0x1718 - 0x1818 # Missing whole right hand
0x105c - 0x1124 # Missing Upper right thigh
*0x4E8 - 0x8C8 # Missing head and everything but body
0x8D2-0x942 # 4-5 tris missing from head
0x8D2-0x8E2 # Removes a poly in back of head
*0x9B2-0x9D2 # Missing poly on top of head

0x8D2-0xC12 # Missing polys of most of back of head

0xDE0 - 0xEA0 # Polys of left forearm
0x742 - 0x8D2 # Crash, need to restart computer
0x6EA - 0x74A # Part of a vertex buffer

0x1350 - 0x1360 # Textures messes up on a face of the lower left leg
0x1360 - 0x13EF # ~6 Polys missing
0x1340 - 0x1350 # Lower left leg missing

0x12F0 - 0x123F # Crash without warning, quick return to windows.

---- Here I started focusing on a particular area of the file-----

0x12F0 - 0x12FB # Single vertex on back of shoe
0x12FC - 0x1307 # Poly missing on front of left shoe
0x1318 - 0x1557 # Sonic's body is missing parts and is misconfigured
0x1318 - 0x1437 # Same as above. Am I filling over an attach struct?
0x1318 - 0x1327 # Missing 2 polys: front shoe left, bottom shoe left
0x1328 - 0x132B # Does nothing. Is this part of a poly definition where its defining a triangle instead of a quad, thus making it empty?

-- The next 4 bytes cause the program to crash, which makes me think they might be pointers (Since I set them to FF) --

0x132C - 0x132D # Crash
0x132C - 0x132F # Crash

 

Ohh, that makes a ton more sense, thanks :D

 

A little visual looking back over some of the previous post's address notes.
I'm having trouble getting that vert to do anything now.

<div class='codetop'>CODE</div><div class='codemain' style='height:200px;white-space:pre;overflow:auto'>+------+
|??????|
|//////|
+------+
|0x12F0|
| | # Single Vertex on back of left shoe
| |
|0x12FB|
+------+ # Beginning of poly buffer??
|0x12FC|
| |
| | # Poly missing on front left shoe
| |
| |
| |
| |
|0x1307|
+------+
|//////|
|//////|
+------+
|0x1318|
| |
| | # Missing 2 polys, front shoe left, bottom shoe left
| |
| |
|0x1327|
+------+
|0x1328|
| | # Does nothing, empty too.
| |
|0x132B|
+------+
|0x132C|
| |
| | # Crash
| |
|0x132F|
+------+
| |
| |
| |
| |
| |
| |
| |
| |
| |
|0x1447| # End of poly buffer?
+------+
|//////|
|//////|
|//////|
|??????|
+------+</div>

 

anything new on this?

 

Has anyone been able to edit the "sonicr.inf" file? It's in the game's directory. I believe that's the file where I can edit the resolution, among other options, but I don't know how to open it...

 

But how do I edit it? Is there a proper program to open it?