Sonic and Sega Retro Message Board: Sonic R Hacking - Sonic and Sega Retro Message Board

Jump to content

Hey there, Guest!  (Log In · Register) Help
  • 20 Pages +
  • ◄ First
  • 11
  • 12
  • 13
  • 14
  • 15
  • Last ►
    Locked
    Locked Forum

Sonic R Hacking Because somebody should.

#181 User is offline Felik 

Posted 30 October 2015 - 06:56 AM

  • Posts: 1695
  • Joined: 11-April 10
  • Gender:Male
  • Wiki edits:1
Random question:
I don't play all that many games so pardon my possible ignorance and/or lack of information, but but why Sonic R is like the only game that ever utilized the palette cycling effect from Radiant Emerald? That visual effect looks pretty cool and seemingly advanced tech-wise that I'm surprised more games didn't do the the same thing.

#182 User is offline TheKazeblade 

Posted 30 October 2015 - 09:18 AM

  • "Our Life is More than a Side-Effect"
  • Posts: 2686
  • Joined: 05-April 10
  • Gender:Male
  • Location:West Coast, US
So since the level model format has been figured out, does that mean custom maps can now be implemented?

I've always thought Sonic R had the capacity to be the basis of an almost Mario 64-esque game were the controls and better suited for low-speed maneuvers. I wonder how that would look.

#183 User is offline Atendega 

Posted 30 October 2015 - 09:30 AM

  • Lesser Sea Sponge
  • Posts: 577
  • Joined: 16-August 14
  • Gender:Female
  • Location:Comfy couch
  • Project:Collecting insults

View PostTheKazeblade, on 30 October 2015 - 09:18 AM, said:

I've always thought Sonic R had the capacity to be the basis of an almost Mario 64-esque game were the controls and better suited for low-speed maneuvers. I wonder how that would look.

For that to work well, the controls would have to be changed so that instead of steering like a car, the characters move directly in the direction you're pointing. I would imagine that would be VERY hard to implement.




#184 User is offline MainMemory 

Posted 30 October 2015 - 12:52 PM

  • Every day's the same old thing... Same place, different day...
  • Posts: 4239
  • Joined: 14-August 09
  • Gender:Not Telling
  • Project:SonLVL
  • Wiki edits:1,339

View PostTheKazeblade, on 30 October 2015 - 09:18 AM, said:

So since the level model format has been figured out, does that mean custom maps can now be implemented?

View PostInvisibleUp, on 27 October 2015 - 10:56 PM, said:

Of course, don't think this means custom levels now. We still have to figure out collision and AI and the metadata in the geometry file and all that fun stuff.


#185 User is offline DetoNtn 

Posted 13 February 2017 - 06:35 PM

  • Layout Master
  • Posts: 15
  • Joined: 28-January 17
  • Gender:Male
  • Location:Virginia
I'm interested in knowing if there's a Sonic R Windows 10 Compatibility mod, as I want to take hacking baby-steps with Sonic R. However, I can't seem to get my Sonic R disc to work. I have tried everything from this thread to all over the internet, and there's literally no up-to-date content on how to get it to run on Windows 10. Am I better off using a Virtual PC like DOSBox 95, or is there a potential D3DWindower/DXWnd or IDA fix to this?

#186 User is offline MainMemory 

Posted 13 February 2017 - 07:04 PM

  • Every day's the same old thing... Same place, different day...
  • Posts: 4239
  • Joined: 14-August 09
  • Gender:Not Telling
  • Project:SonLVL
  • Wiki edits:1,339
The 2004 version ought to work on Windows 10, if you can get it.

#187 User is offline DetoNtn 

Posted 14 February 2017 - 06:41 AM

  • Layout Master
  • Posts: 15
  • Joined: 28-January 17
  • Gender:Male
  • Location:Virginia

View PostMainMemory, on 13 February 2017 - 07:04 PM, said:

The 2004 version ought to work on Windows 10, if you can get it.


Alright, I'll try and get my hands on a copy. Thanks!

#188 User is offline Andrew75 

Posted 14 February 2017 - 10:37 AM

  • Technical Artist
  • Posts: 1913
  • Joined: 12-December 09
  • Gender:Male
  • Project:Project AXSX(Sonic Xtreme) + Misc Projects
Is anything still happening with this?

#189 User is offline Chibisteven 

Posted 14 February 2017 - 09:30 PM

  • Posts: 1243
  • Joined: 20-August 08
  • Gender:Male
  • Location:US
  • Wiki edits:11

View PostDetoNtn, on 14 February 2017 - 06:41 AM, said:

View PostMainMemory, on 13 February 2017 - 07:04 PM, said:

The 2004 version ought to work on Windows 10, if you can get it.


Alright, I'll try and get my hands on a copy. Thanks!


Actually my 1998 (Expert Software) version works just fine with all the patches I have for it.

#190 User is offline InvisibleUp 

Posted 15 February 2017 - 02:06 AM

  • Posts: 107
  • Joined: 10-November 12
  • Gender:Female
  • Project:None
(Hey, look, I'm not dead)

The annoying thing about the 2004 version is that it needs to be properly installed. You can't just copy the files over and apply some patches and have it run. You need to actually install it, which leaves a nasty InstallShield Updater sitting there in your control panel, taunting you for all eternity. But it does run well, so there's that.

If you're using the 1998 version, you'll probably want a No-CD patch. Don't use this to pirate the game, please.

Replace 0x00C13C3 through 0x00C13C5 with bytes 9090
Replace 0x00C13EA through 0x00C13ED with bytes 9090EB


---

You'll miss out on the music, but I'm working on a fix for that. Honest. Already got a DLL coded and everything. It plays BRSTM and OGG files like a dream. What's the hold up? I have to inject initialization routines into the game's initialization function. It's a tightly packed thing, so I have to throw out the few lines of code that just clear unused memory and replace it with something. For just the music hack, that's fine. Just throw the new code in some unused area (like the old Network code), make a jmp to that, and that's that. Cool.

However, when it comes to adding custom characters with custom abilities and more polygons than the original (something I can't do just by changing out files), I have to dynamically allocate some memory large enough to fit all the models (the original was statically allocated to a certain size I can't change at all) and then replace every single reference to the old, static block of memory to the new dynamic block, which annoyingly is one byte larger so I have to shuffle code around and yeah... (I've counted 84 places I have to fix that. So far.)

Plus, any change in character physics or abilities whatsoever requires a complete rewrite of the core physics routine to go and route actions and attribute modifiers to dedicated functions for each character. (By default it's a monolithic nightmare of nested if statements where each character is hardcoded in.) If I want to draw something new to the screen (a boost bar, perhaps), I've got to rewrite the entire HUD display code to allow for more code.

---

Point is, hacking this game without a split disassembly is no fun, and doing all of that by hand with a hex editor is simply not possible. Instead, I've been working on a custom mod loader (with the super-original name "Sonic R Mod Loader", but it's by no means limited to that) that lets me compile C or ASM "patches" with GCC (or simply hand-code the hex), convert it into a "mod", and then install that mod. (The C/ASM functionality requires a Linux machine, fyi)

The "patches" (individual blocks of data or files) can reference other patches or "variables" (values set by a mod that can be updated my other mods) to determine where to patch and what should be patched there. For example, a mod for a character can have a patch that has a Jump function, and then another patch that registers that function (by inserting into a jump table) with an earlier mod that rewrites the physics code as described. Then, during execution, the game with the modified physics code can just use the jump table populated by all the other character mods to automatically go to the right subroutine.

In addition, I can write these new functions in C and reference other functions either from other mods (or the base game, if you're fine dealing with old Watcom fastcall conventions which no compiler supports.) The base game functions (needed for library calls among other things) are provided by an external script that takes an IDC file from and IDA disassembly, finds every subroutine and named memory address, and copies it's locations to a "game definition file" that the mod loader later parses and sets up support for.

What I'm saying is that it's neat and does a lot of cool things.

---

Here's the manual for the mod loader
if you want to get a taste. Note that this isn't final, but it's pretty close.

It's been in development for a while (well over a year), mostly because before I started I had no idea how C, any sort of GUI programming, SQL, or project management in general worked. My decision early on to program it in raw C with an old copy of Borland C++ 5.5 (with no debugger) in the vain hope of achieving Windows 95 compatibility didn't help much. (I've since upgraded to Visual C++ 6. For some reason. But it's using CMake as it's makefile, so it also compiles just fine on 2015 as well.)

Right now I'm almost ready for release. Every function I've described works except for the ability to alter mods installed before a variable was changed. (That's important for, say, reallocating blocks depending on how many elements exist). I'm rather proud of it, even if there might be a few things out there that do its job better. Hopefully you'll see something cool from me for the SHC.

---

That was a really long post that got off topic fast. But hey, at least you know how not-dead I've been. //forums.sonicretro.org/public/style_emoticons/default/smile.png

#191 User is offline Chibisteven 

Posted 15 February 2017 - 03:10 AM

  • Posts: 1243
  • Joined: 20-August 08
  • Gender:Male
  • Location:US
  • Wiki edits:11

View PostInvisibleUp, on 15 February 2017 - 02:06 AM, said:

You'll miss out on the music, but I'm working on a fix for that. Honest. Already got a DLL coded and everything. It plays BRSTM and OGG files like a dream. What's the hold up? I have to inject initialization routines into the game's initialization function. It's a tightly packed thing, so I have to throw out the few lines of code that just clear unused memory and replace it with something. For just the music hack, that's fine. Just throw the new code in some unused area (like the old Network code), make a jmp to that, and that's that. Cool.


Does it include FLAC support?

Anyway my method for disabling the CD check was to copy a file "SONR_CPY.txt" and "XXXX" from the CD-ROM. Removed drive letters "ABDEFGHIJKLMNOPQRSTUVWXZ" in one part of the executable (readable strings) and replaced it with this path "C:\Sega\SonicR\" (DO NOT USE THIS TO PIRATE GAME!). So I could use custom Audio CD that fixed the bizarre glitch I was having.

I then rip the game's soundtrack and adjusted the sample offset (it was awfully large offset, never seen something authored like that before with any PC game) until things lined up and then splitted it into separate audio tracks. Burned an audio CD-R with 15 seconds gaps between tracks and added an extra track at the end to avoid a CD playback glitch. Works like a charm for me.
This post has been edited by Chibisteven: 15 February 2017 - 03:16 AM

#192 User is offline MainMemory 

Posted 15 February 2017 - 12:00 PM

  • Every day's the same old thing... Same place, different day...
  • Posts: 4239
  • Joined: 14-August 09
  • Gender:Not Telling
  • Project:SonLVL
  • Wiki edits:1,339

View PostInvisibleUp, on 15 February 2017 - 02:06 AM, said:

Point is, hacking this game without a split disassembly is no fun, and doing all of that by hand with a hex editor is simply not possible. Instead, I've been working on a custom mod loader (with the super-original name "Sonic R Mod Loader", but it's by no means limited to that) that lets me compile C or ASM "patches" with GCC (or simply hand-code the hex), convert it into a "mod", and then install that mod. (The C/ASM functionality requires a Linux machine, fyi)

The "patches" (individual blocks of data or files) can reference other patches or "variables" (values set by a mod that can be updated my other mods) to determine where to patch and what should be patched there. For example, a mod for a character can have a patch that has a Jump function, and then another patch that registers that function (by inserting into a jump table) with an earlier mod that rewrites the physics code as described. Then, during execution, the game with the modified physics code can just use the jump table populated by all the other character mods to automatically go to the right subroutine.

In addition, I can write these new functions in C and reference other functions either from other mods (or the base game, if you're fine dealing with old Watcom fastcall conventions which no compiler supports.) The base game functions (needed for library calls among other things) are provided by an external script that takes an IDC file from and IDA disassembly, finds every subroutine and named memory address, and copies it's locations to a "game definition file" that the mod loader later parses and sets up support for.

What I'm saying is that it's neat and does a lot of cool things.

---

Here's the manual for the mod loader
if you want to get a taste. Note that this isn't final, but it's pretty close.

It's been in development for a while (well over a year), mostly because before I started I had no idea how C, any sort of GUI programming, SQL, or project management in general worked. My decision early on to program it in raw C with an old copy of Borland C++ 5.5 (with no debugger) in the vain hope of achieving Windows 95 compatibility didn't help much. (I've since upgraded to Visual C++ 6. For some reason. But it's using CMake as it's makefile, so it also compiles just fine on 2015 as well.)

Right now I'm almost ready for release. Every function I've described works except for the ability to alter mods installed before a variable was changed. (That's important for, say, reallocating blocks depending on how many elements exist). I'm rather proud of it, even if there might be a few things out there that do its job better. Hopefully you'll see something cool from me for the SHC.

That all seems very interesting, but it also seems to be rather complicated to work with. I would think it would be simpler to set up a system for DLL injection, like the SADX Mod Loader and its offshoots, so people can just write code in whatever language they want. Maybe there's some advantage to your system, or something in the way the game is coded that makes that difficult to accomplish though.

#193 User is offline InvisibleUp 

Posted 15 February 2017 - 01:36 PM

  • Posts: 107
  • Joined: 10-November 12
  • Gender:Female
  • Project:None
When I first started working on this, I looked at yours. No offense, but it just doesn't seem like it would work. Please correct me if I'm wrong, but your mod loader seems to mostly work by acting as a debugger and modifying RAM values. Sonic Adventure DX is a much better (or at least more generically) programmed that lets you get away with this stuff. With Adventure, I imagine you can just swap out files and play with memory addresses to get most things working, like custom characters or stages. That SA2 network mod program, for example,just injects a new player object into the game and updates its attributes on each packet. The core game is largely unmodified, and what modifications are there are trivial.

The problem is that Sonic R is programmed in such a way where simply altering memory and replacing files doesn't get you very far. To a degree, yes, I could alter player physics and level geometry and the such that way. But there's no memory hacks in the world that can get around the fact that sonic_h.bin is 8060 bytes large, course 5 has no Sonic tokens or ground, and that character 3 can't jump.

To fix things like that, I need to get deep down and start ripping out bits of code with other bits of code. I could do this with a simple IPS patch, but there's a problem. I only have so much room to play around with in the EXE. Several things are going to require code in the program init function, code in the course init, code somewhere else entirely, code that needs to be in a DLL, etc. And that list of things is going to potentially be different for every person, as they install different characters or courses or whatever. I can't just make an IPS patch that always uses a certain byte range in the EXE for, say, the function that gets called for a certain character when Jump is pressed. I'm going to run into conflicts doing that.

The Sonic R Mod Loader was mostly designed around one core concept: Clear and Add spaces. Certain mods can mark spaces as unused and clear, and other mods can then fill in those clear spaces. This solves the conflict problem by simply ensuring conflicts can never occur. And then the variables let the user or other mods alter where a mod installs itself, what its contents are, and how much space it allocates. The program is rather barbaric, as it literally just replaces bytes. But, unless I've been horribly mistaken, it's the best solution.

Think of it like a really smart IPS patcher. As a mod developer, I can just use it like a flat "replace X with Y" patcher, as the No-CD patch would. Or I can do the super fancy stuff I described earlier. It's a sliding scale. Maybe an approach like the SADX Mod Loader will work once I get the game in such a shape where I can just have arbitrary files on the disk loaded without complaint. But that's unfortunately not now.

In hindsight, though, I probably should have mentioned this with you guys before I started working on this. Knowing my luck, there was probably some much simpler solution that I entirely overlooked...
This post has been edited by InvisibleUp: 15 February 2017 - 01:38 PM

#194 User is offline MainMemory 

Posted 15 February 2017 - 01:49 PM

  • Every day's the same old thing... Same place, different day...
  • Posts: 4239
  • Joined: 14-August 09
  • Gender:Not Telling
  • Project:SonLVL
  • Wiki edits:1,339
The major point of the SADX Mod Loader is that you can inject a jmp or call instruction to a function within your DLL, effectively granting you infinite space for custom code. If you need to have multiple mods modifying the same block of code, we've got solutions for that too, with hooks and trampolines.
This post has been edited by MainMemory: 15 February 2017 - 01:51 PM

#195 User is offline InvisibleUp 

Posted 15 February 2017 - 02:15 PM

  • Posts: 107
  • Joined: 10-November 12
  • Gender:Female
  • Project:None
Oh. I should have noticed that beforehand. That actually sounds like exactly what I need.

...I really should have brought up my need for this earlier. Making my mod loader was a definite learning experience I needed, just for the sake of knowing C and Win32 enough to work on Sonic R or whatever else, and also making a decently size project.

I guess I just forged ahead in that direction because I had no idea how to make your mod loader work with Sonic R. Also, I assumed mine would have taken significantly less time to make.

I'm not sure what to do now... I'll release mine anyways, as I still think it's neat, but I'm not sure if I should actually use it or not considering all the limitations it has.

  • 20 Pages +
  • ◄ First
  • 11
  • 12
  • 13
  • 14
  • 15
  • Last ►
    Locked
    Locked Forum

1 User(s) are reading this topic
0 members, 1 guests, 0 anonymous users