Sonic and Sega Retro Message Board: SANiK - Viewing Profile - Sonic and Sega Retro Message Board

Jump to content

Hey there, Guest!  (Log In · Register) Help

Group:
Tech Member: Tech Members
Active Posts:
408 (0.1 per day)
Most Active In:
Sonic 2 HD (Archive) (232 posts)
Joined:
21-September 04
Profile Views:
3582
Last Active:
User is offline Jul 03 2015 09:19 PM
Currently:
Offline

My Information

Age:
Age Unknown
Birthday:
Birthday Unknown
Gender:
Male Male

Contact Information

E-mail:
Click here to e-mail me

Previous Fields

National Flag:
None
Wiki edits:
6

Latest Visitors

Topics I've Started

  1. Sonic Pocket Adventure's Debug Mode

    23 January 2011 - 01:39 PM

    What is the scientific reason that Sonic Pocket Adventure / SPA enters debug mode when using an emulator? I have the actual hardware and pressing Options at the SEGA screen does not work. It might be that debug mode is removed from my build if there are others capable of entering debug mode without an emulator. So are there?

    Debug mode's activation is often cited as an emulator bug. Did anyone look into it further? The most prominent Sonic Pocket Adventure hacking was done by Rolken in this thread, but being in 2006 it seems his efforts are long dead and so are the links.
  2. Sonic X-treme Re-Engineering project

    19 December 2004 - 10:34 PM

    Already set up "advertising" at the cult site. So, why not here?

    Posted Image

    I added spinball (no spindash yet), and fixed up a few things. Here is the latest engine release:

    http://jamesseph.php...anik/sx_rel.zip

    (Btw, music has been downsampled to make the download smaller)

    Keys:
    F1 - switch between level and boss engine.
    F2 - Pachuka mode =D (Turns off chrome on the Metal Sonic model)
    Q - Metal Sonic goes BOOM, nahh, just kidding, he goes -1 on the X axis
    E - Metal Sonic goes +1 on the X axis
    A - Metal Sonic goes -1 on the Z axis
    S - Metal Sonic goes +1 on the Z axis
    Z - Sonic does Spinball
    Left/Right - Hold to speed sonic up
    Up/Down - Alter the distance between Metal Sonic and Sonic

    NOW you can report any bugs:
    Known bugs:
    1) Sonic can go through the wall (barrier)
    2) Camera goes nuts when sonic's position equals metal sonic's position

    Any others?
  3. Issue 1: Sonic Adventure PC and DC model formats

    14 December 2004 - 06:09 PM

    In hopes of getting more beginners interested in next gen hacking, I am going to be releasing my notes on the model formats and later on other formats. Do note, the point of these issues is to hopefully show that SEGA used the SAME format from game to game. The format first appeared in the game NiGHTs, then it got updated and was used in Sonic Adventure, to be updated and used again in the Dreamcast BIOS, then in SA2, then in PSO, etc. Due bear in mind that some notes may have errors and some are incomplete.

    Issues that I will be releasing:
    • Issue 1: Sonic Adventure PC and DC model formats (version 2 of format)
    • Issue 2: Nights model format (version 1 of format)
    • Issue 3: Sonic Adventure 2 model format (version 3 of format)
    Memory sizes that I use:
    • byte = 1 byte
    • word = 2 bytes
    • dword = 4 bytes
    • ----------------
    • sbyte = 1 byte (signed)
    • sword = 2 bytes (signed)
    • sdword = 4 bytes (signed)
    • ----------------
    • float = 4 bytes
    • pointer = 4 bytes

    Quote

    //SADXmdl structures
    //Do note, unless it's already NULL, ALL pointers need a "key" subtracted from them for them to work. The key depends on the type of file the model is in.
    /*Keys:
    #define KEY 0x400000  //*.EXE
    #define KEY 0x10000000  //*.DLL
    #define KEY 0xC900000 //DC version
    */


    typedef struct VERTEX
    {
      float x;
      float y;
      float z;
    } VERTEX;

    typedef struct UV
    {
      word u;
      word v;
    } UV;

    typedef struct POLY
    {
      //If you use strips:
      byte strip_dir; //If this is 0xFF, you draw the strips in strip[1],strip[0],strip[2] order
      //If strip_dir is 0x00, you draw the strips in strip[0], strip[1],strip[2] order
      byte strip_total;

      /*Do remember, you draw strips like this:
      1) Read 3 strips
      2) Draw the 3 strips as a triangle
      3) Read 1 new strip (a strip is actually 1 vertex reference)
      4) Draw the new triangle using the 2 old strips and the newly read strip
      5) Go back to step 3
      In simple words, it's a list of triangles with two points shared between them
      */
      word *strip;

     
      //If you use triangles:
      word tri[3];


      //If you use quads:
      word quad[4];

    } POLY;

    typedef struct MESH
    {
    /*The upper byte in mat_flags tells what type of poly that poly points to.
    If (mat_flags >> 8) == 0xC0, then use strips.
    If (mat_flags >> 8) == 0x00, then use triangles
    If (mat_flags >> 8) == 0x40, then use quads*/

      word mat_flags; 
      word poly_total;
      POLY *poly;      //The polys are stored as strips, triangles, or quads, based on the bits in the mat_flags
      dword PAttr;      //Not much is known
      dword PNormal;  //Not much is known
      dword VColor;    //Vertex color, not much is known
      UV *uv; //UV's are applied to the poly's and not to each vertex. Hence, one vertex can have 3 different UV's depending on the poly being drawn.
      dword _null; //This _null is not there for the DC version of SADX
    } MESH;

    typedef struct ATTACH
    {
      VERTEX *vertex;
      VERTEX *normal;  //If normal is not null, then the model uses normals
      dword vertex_total; //The vertex_total is the same value which tells the normal total
      MESH *mesh;
      dword material; //Material struct was cracked by Dude, waiting for info for it. (This is actually a pointer to data)
      word mesh_total;
      word material_total;
      float center[3]; //Center of the sphere
      float radius;    //Radius of the sphere, used for collision
      dword _null; //This _null is not there for the DC version of SADX
    } ATTACH;

    typedef struct OBJECT
    {
      dword flags;
      ATTACH *attach;
      float pos[3];
      float rot[3];
      float scale[3];
      OBJECT *child;
      OBJECT *relate;
    } OBJECT;


    Hopefully that clears up how the structure works.
    *gets to work on describing the Sonic Adventure 2 and NiGHTs model format*

    Quote

    Ripping models from files

    Things to know:
    • The attach struct is ALWAYS before the OBJECT struct.

    • On the DC, the start of the object struct minus 0x5C = start of the ATTACH struct

    • On the PC, the start of the object struct minus 0x60 = start of the ATTACH struct

    • Why the difference in 0x5C and 0x60? Simple, variable dword _null is not there on the DC.
    Now if we know where an object struct is, we can figure out the rest of the model.
    • We read an OBJECT struct from a file

    • We also keep track of where we read the OBJECT struct from.

    • Now, we subtract 0x5C or 0x60 from where we read the OBJECT struct from depending if we are on the PC or the DC.

    • If the OBJECT.attach - KEY /*The key depends on the file type*/ == file offset that we read the OBJECT struct from - 0x5C or 0x60 is true, then the OBJECT struct is for real.

    • Now we apply the KEY to all the pointers and load the model. (Do note that there may be more models in one file so you should keep searching actually)

    • If the OBJECT struct was a false alarm, we move the file offset 4 bytes up, and read an OBJECT struct in all over again. It's back to step one for us.


    *Refer to the Cult for newer versions of this guide if you think something might have been fixed up*
  4. Sonic Heroes TXD utilities BETA

    11 October 2004 - 02:36 PM

    READ ALL THAT FOLLOWS WITHOUT SKIPPING A LINE!!! YOU MUST REDOWNLOAD BOTH TOOLS OR YOU'LL NOT FIX THE BUG!!

    1) These TXD unpackers are in BETA stage. That means there might be a problem.
    2) If the topic changes to "Sonic Heroes TXD utilities" without the BETA part, then that means you should update your tools.
    3) You MUST, and I say MUST update both, the UNPACKER and the PACKER.
    Reason for this being was because when the unpacker unpacked, some dds images in the txd pack had the alpha flag on and the others which HAD to have the alpha flag on, had the alpha flag set to off.

    TXD_UNPACKER:

    Usage:
    1) Drag the *.txd file onto the unpacker.
    2) Watch it unpack.
    3) Do note, that if you have a file outputted called "DDA" instead of "DDS", that means that THAT DDS has alpha turned on.
    So remember:
    DDS - Direct Draw Surface image
    DDA - Direct Draw Surface image WITH alpha
    4) Why do we need a DDA file type? This is for use when you want to repack everything. The repacker needs someway to figure out what image uses alpha and which one doesn't.

    Download:
    http://jamesseph.phpwebhosting.com/users/s...xd_Unpacker.exe

    TXD_PACKER:

    Usage:
    1) Drag the *.dds and *.dda files onto the packer.
    2) Watch it pack.
    3) The output should be in a file called "out.txd."

    Download:
    http://jamesseph.phpwebhosting.com/users/s...xd_Packer.exe
  5. NiGHTs model format hacked

    06 October 2004 - 08:04 PM

    THANKS so much to SSNTails for cracking his head open with me to solve this one:

    The endy thingy magigy:
    Posted Image

    Some sort of stage: (Mind you, I never played the game)
    Posted Image

    Some tower thingy:
    Posted Image

    DO NOTE!!!
    The ripper is in a BETA stage so it's missing things such as:
    rotation
    positioning of child objects
    FINDING ALL models (The current formula gets stopped easily by coincicides)

    Also note, NiGHTs uses elevation maps for the terrains. That's 2D grid data, which is something totally different to what this does.

Friends

SANiK hasn't added any friends yet.