Game Modification: 60 FPS Hacks and Patches

[Zerowalker]

Okay will try it out

As for the Pikmin code, i saw it.
But doesn't that do like the existing ones, just change the framedivider from 2 to 1?

EDIT:

The code worked as expected, awesome, thanks, learning some interesting stuff;D

[gamemasterplc]

It just does that as an assembly hack.

[Zerowalker]

Ah i see, well then it's the same basically what i am trying to learn here (but it's not my goal though).

I just tried to do the same thing my AR code does, by shifting between 30 and 60 on cutscenes.
It works but as with the AR code not perfect (it goes to 30fps during scenes which should be 60fps),
so need to look for more clues

[Meowmaritus]

(10-19-2016, 11:17 AM)gamemasterplc Wrote: If you want a negative offset include the 0xFFFF before the signed part.

Or you could literally just add a minus sign before it.

[gamemasterplc]

You have to subtract the offset from 0x10000 before placing the minus sign in front of it.

[Meowmaritus]

(10-19-2016, 11:38 AM)gamemasterplc Wrote: You have to subtract the offset from 0x10000 before placing the minus sign in front of it.

No you have to subtract the offset from 0x10000 before you add it to 0xFFFF0000.
The minus sign makes it where you don't have to subtract.

• Open CodeWrite
• For the ASM put this:
  stw r21, 0xFFFFFFFF(r20)
  stw r21, -0x0001 (r20)
• Convert it to a Gecko code
• You'll see that both instructions have a value of 0x92B4FFFF
  

And for that reason, I suggest you stop "correcting" what I say if you don't actually know for sure what you're talking about.

[Zerowalker]

Not really sure what you guys are talking about.

How can an address be signed/unsigned?

Isn't it absolute, i mean there is no "-487630" address right?

[Meowmaritus]

(10-19-2016, 12:01 PM)Zerowalker Wrote: Not really sure what you guys are talking about.

How can an address be signed/unsigned?

Isn't it absolute, i mean there is no "-487630" address right?

The address that the storage instructions actually write to are an offset relative to the address stored in the register you put.
So in the instruction stw r17, 0x434C(r8), we're storing r17's value in the address located 0x434C bytes after the address in r8
In that example, if r8's value were 0x817F1000, then r17's value would be stored in (0x817F1000 + 0x434C), which is equal to 0x817F534C.
That relative address value can be positive or negative.
If we simply change it to be stw r17, -0x434C(r8), then it stores r17's value in the address located 0x434C bytes before the address in r8 (0x817F1000 - 0x434C = 0x817ECCB4)
But yeah @gamemasterplc was wrong about multiple things pertaining to the storage values, so don't let his reasoning confuse you.

[Zerowalker]

Oh okay i see, but isn't that really a weird roundabout way to get to addresses?
Why not just access them directly, why does it need to have an offset like that? (or at least why does it have the possibility?).

Also, is it possible to use "If blabla then blr"?

[Aleron Ives]

(10-19-2016, 01:55 PM)Zerowalker Wrote: Oh okay i see, but isn't that really a weird roundabout way to get to addresses?
Why not just access them directly, why does it need to have an offset like that? (or at least why does it have the possibility?).

After recently getting some experience with how the GC addresses things, I think that's just the (rather crazy, from a PC standpoint) way it operates. If you're modifying x86 code, you'll see that pointers usually use absolute addresses to specific offsets, so it's easy to see what accesses what, even if you're just looking at the binary as a file.

The way GC uses relative pointers makes it impossible to figure out what's going on by just looking at the DOL; you have to debug the game live to know what the base offset is in order to know what the pointers are pointing to. Even something as simple as finding out where the game loads a string is easier said than done by just looking at the DOL. I'm not even sure if there's a specific way to convert offsets in a DOL into offsets in RAM (for converting DOL patches into memory patches for AR codes, for example) or if you have to do live debugging to figure that out, too. It's all quite confusing coming from an x86 background.

P.S.

I apologise if this is off-topic, but I think it's relevant to your question...