don't click here

Sonic R Hacking

Discussion in 'Engineering & Reverse Engineering' started by MainMemory, Dec 1, 2009.

  1. Raz

    Raz

    Member
    38
    0
    0
    USA
    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?
     
  2. MainMemory

    MainMemory

    Kate the Wolf Tech Member
    4,757
    341
    63
    SonLVL
    Given that I was unable to find any instances of 1.0f anywhere in sonic_h.bin, the vertices might be stored as 16.16 bit fixed point, which is what the Saturn used, since it lacked an FPU (according to SANiK's notes on the NiGHTS model format).
     
  3. Raz

    Raz

    Member
    38
    0
    0
    USA
  4. MainMemory

    MainMemory

    Kate the Wolf Tech Member
    4,757
    341
    63
    SonLVL
    I'm not likely to be much help with decoding the model data, but if anyone figures out enough of it I'll make a modified SADXMDL for the models.
     
  5. Raz

    Raz

    Member
    38
    0
    0
    USA
    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 )
     
  6. Raz

    Raz

    Member
    38
    0
    0
    USA
    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]?
     
  7. MainMemory

    MainMemory

    Kate the Wolf Tech Member
    4,757
    341
    63
    SonLVL
    Well, Sonic R PC uses different formats than Sonic R Saturn. So it's likely Little Endian (in fact, Sonic Heroes is the only port I've seen that still uses big endian on PC) and potentially a completely different format.
     
  8. Raz

    Raz

    Member
    38
    0
    0
    USA
    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?
     
  9. Raz

    Raz

    Member
    38
    0
    0
    USA
    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 )

    [​IMG]

    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? :|
     
  10. Raz

    Raz

    Member
    38
    0
    0
    USA
    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

    [​IMG]
    [​IMG]
     
  11. Raz

    Raz

    Member
    38
    0
    0
    USA
    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
     
  12. MainMemory

    MainMemory

    Kate the Wolf Tech Member
    4,757
    341
    63
    SonLVL
    If you set every byte to FF, you'll end up with 0xFFFFFFFF, or -1 (16.16 fixed point uses 32 bits total), divided by 65536 gives -0.0000152587890625.
     
  13. Raz

    Raz

    Member
    38
    0
    0
    USA
    Ohh, that makes a ton more sense, thanks :D
     
  14. Raz

    Raz

    Member
    38
    0
    0
    USA
    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>
     
  15. Skeledroid

    Skeledroid

    Member
    227
    0
    0
    anything new on this?
     
  16. 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...
     
  17. MainMemory

    MainMemory

    Kate the Wolf Tech Member
    4,757
    341
    63
    SonLVL
    <a href="http://info.sonicretro.org/SCHG:Sonic_R_(PC)#sonicr.inf" 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">SCHG:Sonic_R_(PC)#sonicr.inf</a>
     
  18. But how do I edit it? Is there a proper program to open it?
     
  19. MainMemory

    MainMemory

    Kate the Wolf Tech Member
    4,757
    341
    63
    SonLVL
    A hex editor.