don't click here

SADX/SA1 Hacking/Modding

Discussion in 'Engineering & Reverse Engineering' started by MainMemory, Aug 15, 2009.

  1. Blue Spikeball

    Blue Spikeball

    Member
    2,348
    957
    93
    Hey guys, I just made a new boxart-based SADX icon that matches the SA2 icon:
    [​IMG]

    For comparison:
    [​IMG]

    Also available as an alternate flavor that uses the official Steam version's icon for lower resolutions that 128x128 (64x64 is the highest and only resolution that icon was available as):
    [​IMG]

    The linked zip files include the mod loader-compatible game executables with the icon replaced, as well as the icon file.
     
  2. McAleeCh

    McAleeCh

    Oldbie
    1,470
    531
    93
    Tails' mouth moves in his flashback, so yes, presumably that would need addressing somehow. I don't think Sonic's or Amy's do, though, as they just speed quickly past the camera - and obviously Metal Sonic's doesn't due to him not actually having one! ; )

    Oh man, I forgot all about that image. Good shout - that's a great reference for how a more classic styled Sonic would have looked in the original DC Sonic Adventure. Reminds me of the Sonic R title screen a bit - slightly longer-limbed than classic Sonic is depicted nowadays, but still recognisably the original design, with the shorter spines, lighter blue, red soles and solid black eyes. Looks like the gloves are just solid white, too, which sort of explains their mitten like shape in the final game - I always found it a bit weird the characters' hands were just lumps with the fingers just textured on, but if the original intention was for more cartoony mitten-hands then then how they were modelled suddenly makes a lot more sense.

    Guessing that particular render was done pretty early in development - love that they didn't bother to paint out the segmentation in the limbs! Just wish there was a version without the text overlaid - it'd make a great reference to try and match should anyone actually try to implement a 'classic flashbacks' mod.
     
  3. SF94

    SF94

    Tech Member
    I've just added a code to the SADX Mod Loader which enables some hidden light adjustments that are made by the Mystic Ruins (the specifics of which are why I chose to post here and not the mod loader thread).

    SADX appears to attempt adjusting the light direction in the Mystic Ruins depending on the section and time of day. While all the code for these adjustments is fully functional, the final adjustments generated by this code go unused because of what looks to me like an oversight.

    There are global variables that are used to adjust the rotation of the stage's light. This is used in Casinopolis's main area. Consequently, the game only actually applies this rotation when the current stage and act are Casinopolis 0 (the main area). The adjustments made for the Mystic Ruins write to these same global variables seemingly under the assumption that it will actually get applied, but due to the aforementioned conditions for application, you never see this ingame.

    This was discovered when PkR and I were looking into why the light direction looked off in the Mystic Ruins when using the Lantern Engine compared to SA1 on the Dreamcast. Every other stage is effectively perfect at this point, so the Mystic Ruins was a very odd case.

    I believe this time of day light direction adjustment was also present (and not applied) on the Dreamcast. The reason for that is that the Mystic Ruins in SA1 has a fixed, downward-facing light direction. It very specifically ignores the light direction defined in the "SL" files, as we call them. This downward facing light direction is represented at some point in the pipeline as a directional vector, and is the default light direction for all stages. The light rotation is typically read from the aforementioned SL files and applied to the directional vector. But, since the condition for applying the dynamic rotation used by Casinopolis requires that the stage is currently Casinopolis, the light direction in the Mystic Ruins always remains downward-facing.

    So the discrepancy with my Lantern Engine arises when my implementation uses the light direction information stored in the SL files like it ought to, when on the Dreamcast, the Mystic Ruins is a special case for this time of day based adjustment. As we can see at this point, that didn't quite work out in Sonic Team's favor.

    Just an interesting thing I figured I'd explain. Enabling this code will restore the adjustment functionality by always applying it, regardless of stage or act.
     
  4. Blue Spikeball

    Blue Spikeball

    Member
    2,348
    957
    93
    Two questions:

    1) Where are the values for the SADX lighting system stored?

    2) Anyone knows how to edit this text?
    [​IMG]
     
  5. MainMemory

    MainMemory

    Kate the Wolf Tech Member
    4,735
    334
    63
    SonLVL
    Stage lights are supported by SA Tools, and are exported to Levels\Stage Lights.ini.

    That message is located in the CHAODX_MESSAGE_HINT file, which you can edit with SADXTweaker2's Chao Message File Editor. It's messages 91 & 92.
     
  6. Blue Spikeball

    Blue Spikeball

    Member
    2,348
    957
    93
    Thank you.

    Do you know if the SADX light values differ from the GC version?
     
  7. MainMemory

    MainMemory

    Kate the Wolf Tech Member
    4,735
    334
    63
    SonLVL
    I do not.
     
  8. Blue Spikeball

    Blue Spikeball

    Member
    2,348
    957
    93
    Well, the reason I asked about the lighting is that I would like to attempt to restore the GC version's Casinopolis lighting by adapting its light values for the Lantern Engine mod. Casinopolis was the one stage that actually received an interesting makeover in SADX, but the PC port botched its lighting and atmosphere, as covered by PkR's blog:
    GC:
    [​IMG]
    PC:
    [​IMG]
    So can you tell me what where these values are stored in among the game files? That way I can try taking a look at the equivalent files from the GC version and hopefully get the right values.

    Edit: Also, while we're at it, how do you tweak an area's fog?
     
  9. PkR

    PkR

    Member
    191
    24
    18
    SADX Dreamcast Conversion, The Emeralds' Awakening
    This is a very broad kind of question because there are several kinds of light values, and among those there are also different light types. Each of those may or may not be different between SADX Gamecube and PC.
    There are 3 different kinds of lighting (well, 4 if you count fake shadows but those aren't of much interest):
    1. Stage Lights. Those are exported by split in the PC version, and just recently we found them in the Gamecube version. There are differences between Gamecube and PC in some stages, but not everywhere and some differences are very subtle. To get the Gamecube version's lighting data, you need to dump RAM using Dolphin's debugger, open the dumped file in a hex editor and go to 0x0567DC0, which is the start of Stage Light data. The structure is the same as in the PC version starting with level and act IDs etc., but the values are Big Endian.
    2. Character and object light types, also known as LS Palette data. 0x56B3A0 in dumped Gamecube RAM, 0x903E88 in sonic.exe disassembly. Although the structure is the same, copying the values over from the Gamecube version won't be exactly accurate because half of the values, such as CO1 and CO2 colors etc., are ignored in the PC version, and because the PC version sets up character specular in a different way (it rotates with the camera on PC but is static on the Gamecube). Still worth a try if you want to mess with it, though.
    3. Vertex colors. Those are baked into the models so the only way to replace them is to replace the models involved. From my observations vertex colors seem identical between SADX Gamecube and PC.

    The comparison screens you posted show a difference involving vertex colors. For some reason the SADX PC renderer ignores vertex colors on some models, which is what you're seeing here. This isn't a matter of copying values from the Gamecube, it's an engine problem. If you find the models for pinball entrances in SADX PC, you'll notice that they still have vertex colors:
    [​IMG]
    Why the PC version ignores them, I have no idea.
    You wouldn't be able to recreate this using Lantern Engine because the marquees have a material flag to ignore lighting, which means they won't get palettized at all. Even if they were palettized it wouldn't look the same because vcolors aren't actual lighting, i.e. they are applied regardless of brightness index, light direction etc. Like I said, it's a matter of getting the model's built-in vertex colors to appear rather than palettizing the model.

    As for fog data, for every stage and act there's an array of FogData structures that define fog color, distances and an on/off toggle. Those aren't extracted by split at the moment but you can look them up in the disassembly. Alternatively you could look at the source of any Dreamcast level mod, where you can find DataArray pointers for fog data in different levels, which you can copy and use in your own mod.
     
  10. Blue Spikeball

    Blue Spikeball

    Member
    2,348
    957
    93
    Wow. Thank you very much for the elaborate and detailed explanation. I took a look at the memory values you mentioned, and it turns out Casinopolis's values are the same as the PC version (and were no help). So these level parts use vertex colors and ignore the actual lighting? Pity.

    Still, I was able to somewhat approximate the look of the GC lighting by creating a custom diffuse palette for the Lantern Engine:
    Before (no mods):
    [​IMG]
    After (Lantern Engine mod + my edit):
    [​IMG]
    Here's my edit. It's applied by extracting the file to mods\sadx-dc-lighting\system; rename or copy the original PL_90B.BIN first.



    Unrelated, but I just created a little mod that includes my previous fixes, in addition to a few new ones:
    http://www.mediafire.com/file/94hw6bs56fs45bm/Random_Fixes.zip

    Here's the list of fixes included:
    - The Casinopolis textures were replaced with the corresponding textures from the Dreamcast version (and GC version, for the textures that were replaced with new ones in SADX), which had better quality.
    - The machine that is used to upgrade E-101 in one of the cutscenes is properly textured now (it used the wrong textures in every version, even the Dreamcast original), plus I replaced the rest of the textures in the corresponding PVM file with the DC and GC textures while I was at it:
    Before:
    [​IMG]
    After:
    [​IMG]
    - The Chao Name Machine uses the screen texture from the Steam version, so it's properly labeled now. It was previously mislabeled as "Chao Adventure".
    - The Chao picture on the wall of the Station Square Garden was updated to use the Steam version's texture and text, so it no longer references the now defunct Chao Laboratory page.
    - The newspapers in the Station Square newsstand are properly textured now.

    To anyone who tries this patch, some things to keep in mind:
    - If you're using the Dreamcast Egg Carrier mod, my mod needs to be placed below it for the E-101 cutscene fix to take effect.
    - If you're using the Dreamcast Station Square mod, it should be placed below my mod to avoid texture conflicts.
    - If you're using the Dreamcast Chao Gardens mod, it should be placed below my mod to avoid texture conflicts.
    - If you're using the Dreamcast Casinopolis mod, it should be placed below my mod to avoid texture conflicts.


    Btw, I also included my edited palette file in the mod, but it was ignored by the Lantern Engine, whether this one was placed before or after my mod in the mod list. The only way I could get it to use the edited palette was by replacing the file in the Lantern Engine folder, as described above. Anyone knows why that is?
     
  11. Fred

    Fred

    Taking a break Oldbie
    1,563
    117
    43
    Portugal
    Sonic 3 Unlocked
    Good job on the E-101 room; that one seriously bugged me once I was made aware of it.

    Any chance of fixing the orange squares around his eye? Those don't seem to make any sense either.
     
  12. TheKazeblade

    TheKazeblade

    "Our Life is More than a Side-Effect" Member
    Was that not intentional? I always assumed that it was because his original eyes had been removed and replaced with his cyclops eye. Is it actually missing textures?
     
  13. Blue Spikeball

    Blue Spikeball

    Member
    2,348
    957
    93
    Could be intentional, or could be another screw up. Regardless, I've tried seeing if I could change it, but couldn't find any texture that corresponded to the red parts of E-101's face, so it's not as simple as swapping a texture. Just a guess, but it seems to use a solid color, so changing it may require some editing of the model, mesh or material data, an area I'm not currently familiar with :v:
     
  14. Clownacy

    Clownacy

    Tech Member
    1,053
    581
    93
    IIRC, in Gamma's flashback image of the under-maintenance E-101, he doesn't have that orange texture near his eye.
     
  15. PkR

    PkR

    Member
    191
    24
    18
    SADX Dreamcast Conversion, The Emeralds' Awakening
    So I took some time to find the models involved in that cutscene, and this is what it looks like in the model editor:
    [​IMG]
    As you can see, the actual model has the correct textures that match the flashback image. Even the eyes don't have the red thing going on anymore.

    It turned out to be a simple global index conflict. A lot of textures in PVME101FACTORY are the same textures as in OBJ_EC00 or OBJ_EC30 but they have different global indices, which sometimes conflict with other textures in OBJ_EC30. Replacing the textures in PVME101FACTORY with identical textures (but with different indices) from various other PVMs fixes this. I've just pushed an update for DC mods that includes a rebuilt PVM. This is what it looks like:
    [​IMG]

    Also, I would strongly advise against editing OBJ_EC30.PVM for this kind of a fix. First of all I think this cutscene uses PVME101FACTORY.PVM rather than OBJ_EC30.PVM, and the reason OBJ_EC30 worked is because some textures have the same global indices (they are supposed to be the same texture), so essentially you're doing the same thing that broke them in the first place. The textures in OBJ_EC30 are used by a lot of Egg Carrier objects and your edits will likely break objects that use mirrored textures (if used together with the DC mods) regardless of mod order. You also kept the original monorail logo texture with the alpha channel, which means the restored monorail logo will disappear again. Not to mention the objects that use the textures that you swapped in the mod. In general when making texture order changes I think it's better to edit the actual models rather than the PVMs.
     
  16. Blue Spikeball

    Blue Spikeball

    Member
    2,348
    957
    93
    Well done, just tried your fix and the cutscene looks perfect now.

    Well, I did warn that my patch could create some texture conflicts when I first posted it. I was aware editing the models would be a better solution, but I haven't looked into that area yet.

    Not that it was necessary in this case. So the problem was that some of the textures in PVME101FACTORY.PVM used the same index numbers as other textures, and the solution was as simple as assigning new values to them? Huh.
     
  17. SF94

    SF94

    Tech Member
    https://github.com/SonicFreak94/sadx-dc-lighting/issues/64

    I've implemented mod loader & Lantern Engine functionality to allow file replacement without editing the actual mod. It will be published as a stable release after the hacking contest is over.
     
  18. Blue Spikeball

    Blue Spikeball

    Member
    2,348
    957
    93
    That's great to hear, thanks for fixing that "issue". Just curious, what was it caused by? Does the mod loader automatically give priority to the Lantern Engine mod?
     
  19. SF94

    SF94

    Tech Member
    The mod loader hooks the function that creates file handles (i.e opens a file) in order to redirect paths to files replaced by mods. This doesn't apply to mods it loads, so the Lantern Engine required explicit API functionality to do the same thing. If the game loaded those files itself, it would have worked right from the get go. Probably for the best this way--mods can opt in to having their custom files replaced or simply ignore that functionality.
     
  20. Blue Spikeball

    Blue Spikeball

    Member
    2,348
    957
    93
    Thanks for the explanation.