News: 11 March 2016 - Forum Rules

Author Topic: Is this something that's even possible?  (Read 2686 times)

Marscaleb

  • Jr. Member
  • **
  • Posts: 12
    • View Profile
Is this something that's even possible?
« on: May 26, 2014, 11:18:21 am »
So I have a problem with always wanting to expand whatever I'm working on to something beyond my abilities.  It's particularly annoying when I get an itch to hack/mod an old game.  I always want to make changes that I simply can't because I don't know or work with assembly.

But yet, I had an interesting idea last night, and well...  I just wonder if its even possible, or if I'm grossly misrepresenting how these games work.

Instead of trying to slip in changes and alterations to the code that the game runs, what if we pulled the code out of the game and ran it as its own program?

For the sake of argument, let's talk about a SNES game.  Would it be possible to extract the game's code (or certain portions of the code) as an assembly program and have it be run inside of another program?  Perhaps something like a custom SNES emulator, so the master program can duplicate all the called-for functions, (but effectively runs the game as its own self-contained program on one's computer.)  Then the master program could add to the game's functionality by writing its own functions that run in tandem with the extracted code.

Let's say we're talking about A Link to the Past, and we wanted to add a special death effect for a monster.  We have the game's basic gameplay extracted, so the game runs as if it was on a normal emulator.  Then within the extracted assembly program, we find a point where the monster dies and calls the death effect.  Then make a slight modification to that original code so that it instead calls a flag.  The master program sees this flag called, and then executes its own custom function and draws out is own death effect, potentially even one that exceeds the capacity of SNES.

Is this sort of thing even possible?  And to what extend is it possible; how much effort would be needed to make it possible?

It's just an idea I had last night.

FAST6191

  • Hero Member
  • *****
  • Posts: 3238
    • View Profile
Re: Is this something that's even possible?
« Reply #1 on: May 26, 2014, 11:59:30 am »
Yeah it is possible, maybe even with the groundwork already done. That said it might not work quite in the way you are thinking (yours is skirting dangerously close to magic box territory).

Game specific emulators have happened and if you look at some of the N64 hi res hacks and even some translations on similar systems it is basically what you describe -- the emulator watches various points and when it comes time to read/write/whatever an area it will stick its own stuff in there instead (or change it for its own stuff as it hands it off to the 3d system or 2d system).

Going a step further a handful of emulators support lua these days, lua is a full programming language and the emulators will have all sorts of hooks for said lua scripting. You do not even have to make flags in the code (though such things could help at some level if you really wanted).
FCEUX is the reference standard for this sort of thing and you can read more about that http://www.fceux.com/web/help/LuaScripting.html , not sure what to link for the N64 stuff but much of it is along the same lines, if not as polished.

reyvgm

  • Hero Member
  • *****
  • Posts: 1239
    • View Profile
Re: Is this something that's even possible?
« Reply #2 on: May 27, 2014, 08:36:27 am »
While these methods can work, they are really not optimal because they don't work on real hardware or cycle-accurate emulators. Or in the case of N64 translations (I'm looking at you, Sin & Punishment translation), they only work using specific set of plugins, meaning that as better plugins or better emus (such as CEN64, the cycle accurate emu) are released, then the translation is rendered useless.

STARWIN

  • Sr. Member
  • ****
  • Posts: 454
    • View Profile
Re: Is this something that's even possible?
« Reply #3 on: May 27, 2014, 10:15:50 am »
they only work using specific set of plugins, meaning that as better plugins or better emus (such as CEN64, the cycle accurate emu) are released, then the translation is rendered useless.
No, that has no effect on the usefulness of the translation.. a newer emulator doesn't magically create translations. If you mean unusable, still no, as the older version can be used.

I always want to make changes that I simply can't because I don't know or work with assembly.
If the modifications are simple enough, you can just try to do them at the assembly level, after reading a bit about the system in question.

Instead of trying to slip in changes and alterations to the code that the game runs, what if we pulled the code out of the game and ran it as its own program?
The game doesn't run the code, the game is the code. (well, code, and also data that the code uses, such as art, levels and stat-type values)

Would it be possible to extract the game's code (or certain portions of the code) as an assembly program and have it be run inside of another program?
The code is right there in the game image, so I can't think of any other kind of (simple) extraction than what emulators already do - they run the game.

Then the master program could add to the game's functionality by writing its own functions that run in tandem with the extracted code.
The way I interpret this is that the emulator could change the game state when certain conditions trigger. The benefit would be that you don't have to insert the modified code into the game. Still, you would have to define somehow the conditions.. how much of that can be done without the usual assembly knowledge? And the changes you make to the game state should not propagate uncontrollably into the game.. if it only changes emulator output, that would be simpler. But are there that interesting output-only changes?

Then within the extracted assembly program, we find a point where the monster dies and calls the death effect.  Then make a slight modification to that original code so that it instead calls a flag.  The master program sees this flag called, and then executes its own custom function and draws out is own death effect, potentially even one that exceeds the capacity of SNES.
So, you'd have to know the death effect condition at assembly level. There is probably no need to modify the game to "call a flag" (whatever that would precisely mean), as it is enough to have the condition listed in the emulator end. You'd still have to change that effect properly, and know how to do so.

Zoinkity

  • Hero Member
  • *****
  • Posts: 565
    • View Profile
Re: Is this something that's even possible?
« Reply #4 on: May 27, 2014, 02:41:23 pm »
Quote
Then the master program could add to the game's functionality by writing its own functions that run in tandem with the extracted code.
Effectively this can be done with an Action Replay/GameShark or similiar rdram-altering device.  In fact, that's the way I do console-side debugging with an N64.

Basic concept is you write code at some address you'd like to run, then use an rdram-modifying tool to either conditionally set a pointer to the new code or catch the code as it loads via the PI and swap it (or part of it) out for the new.  Two simple examples would be the F-Zero X track uploader which replaces one resource with another as they load and the GoldenEye stage upload and co-op extensions which replace parts of compressed code after it is loaded, decompressed, and assigned a TLB address.

Official console-side debuggers usually set up a thread in the game to manage the debug features themselves.  The advantage is you can basically watchdog and pause gameplay.