Game Modification: 60 FPS Hacks and Patches

[Zerowalker]

Okay was easier than i though, i found the solution, i could divide a value.

However, it would flicker in some occasions if i used r3 (it had a value stored, not an address), so it was never backup-ed for some reason.
I used r12 as it seemed to store an address at those times and the flicker was gone.

Now Particle Generation in Power and (Rotation Speed Whistle Effect) seems to be correct;D

[Meowmaritus]

(10-21-2016, 05:29 PM)retroben Wrote: From what I read,one VI value is global for TVs (NTSC) as 525 or 020D in hex,but I haven't seen that value in Gamecube RAM like I do in the N64's RDRAM unfortunately so it might be stored in the disc image data itself.

If it helps,the 60fps codes set to half of 000A4CB8 equals a 120fps speedup when CPU Override is 200% or greater and it changes the framerate scale value to 00.

In Wind Waker and Twilight Princess the VIs are stored in X and Y:
X = 640 (0x0280)
Y = 480 (0x01E0) in NTSC and 525 (0x020D) in PAL


...at least I think PAL does that.


Edit: I just realized I never even explained what my 044C8D44 000A4CB8 AR code actually does.
Upon loading a scene(e.g. title screen, outside on islands/sailing seas, inside grandma's house, new game cinematic, etc) in Wind Waker:

1. It loads 40500000|0x269FB20 (the amount of GameCube CPU ticks that pass each second)
2. It loads 30|0x1E (the targeted framerate)
3. It divides 40500000|0x269FB20 / 30|0x1E, which is equal to 1350000|0x149970
4. It stores the result at 0x804C8D44 (the address that the AR code writes to)
   

On each frame of Wind Waker:

1. It calls OSGetTime (a global GameCube OS function) and sees how many ticks have passed since the game has booted.
2. It stores that value for later (forgot what address)
3. It updates/renders 1 frame
4. It calls the waitForTick function (specific to Wind Waker/Twilight Princess engine):
   
   1. It loads the previous value saved from step 1.
   2. It loads the value from 0x804C8D44
   3. It gets the sum of two values.
   4. It calls OSGetTime and gets the current amount of ticks.
   5. It subtracts (Previous tick count from step 1 + value from 0x80[b]4C8D44[b]) - (current OSGetTime result) in order to get the amount of ticks it must wait to reach the next frame.
      

Disabling waitForTick, like another of my codes did, simply causes it to not make the thread sleep, which is why the FPS is so erratic; It depends on how long it takes to process all the instructions that frame. Thats also why disabling waitForTick cant go much higher than 60 fps without overclocking emulated CPU (and having a really fast PC CPU that can run it like that)

Anyways, the value my AR code uses is half of the one the game saves there, effectively doubling FPS

[JMC47]

So, what's the status on this now? I'm having a hard time following all the big posts full of stuff I barely understand

[Zerowalker]

But how do you reach the "60 VI" from a value of 640x480?

And that's very neat of the Game Engine, it makes things "easy" to keep track of, and i can imagine "easy" to modify as well.
How you were able to understand all that is mystery though xD

[Meowmaritus]

(10-22-2016, 07:16 AM)JMC47 Wrote: So, what's the status on this now?  I'm having a hard time following all the big posts full of stuff I barely understand

The status on the Wind Waker Framerate Hack is that it's properly rendering and mostly playable in 60 FPS (other multiples of 30 FPS still need a bit of work). However, I'm also fixing many bugs in it (things being double speed). I'm getting faster and faster every day at finding the values so the hack could be done within 1 week or 1 month. Likely only a week or two. Note that I'm aiming for 1 week since Dragon Ball Xenoverse and Dark Souls III DLC comes out in about a week. Also note, however that I can't afford either so if I were to play them it would probably be a bit later than that.

Anyways, Twilight Princess Framerate Hack is a whole different beast. Quite ironically, Link's beast form actually contributes quite a bit to the difficulty of creating this mod. Other factors of difficulty include: the excessive amount of mini games, the amount of items obtainable, the underwater movement mechanics, the magnetic field mechanics (Goron Mines), the secret sword skills for Link, the large amount of event-based sequences (the monkey taking Link's lantern and escorting him around, for example), the game being extremely hard to run in 60 FPS (lookin at you, Hyrule Field), and most of all, the improvements(for the devs, at least) made during the transition from the quickly-abandoned Wind Waker 2(google it) to Twilight Princess, which added a lot of complexity to the engine (and greatly increased the number of values that need to be modified in order to change the game speed).


Anyways, on to other news: I've been fretting about the really stuttery framerate and cpu slowdown on emulated CPU overclocks over 100% that I've been experiencing in Dolphin for almost a week now and I literally just now realized that Enable Dual Core has been off the whole time. I have no idea when I turned that off but I'm sure it was because I was getting frustrated with Dolphin's frequent crashes in debugger mode when I did. With the option on, like I usually keep it, I can run Wind Waker 80 FPS while viewing the entire Outset Island with the emulated CPU overclocked to 400%. Now I should be able to run the game at consistent 90 FPS with some tweaking of the CPU overclock and video settings, which will allow me to ensure that the hack's framerate multiplier actually scales the speed properly when set to 3 (30 FPS * 3 = 90 FPS). If it works on both 60 FPS and 90 FPS I can at least assume it will work for >= 120FPS (since the hack uses division and multiplication of the games' regular values rather than hardcoded new values). My monitor is only 60 Hz though so I can't experience for myself how smooth it is.


Edit:

(10-22-2016, 07:37 AM)Zerowalker Wrote: But how do you reach the "60 VI" from a value of 640x480?

And that's very neat of the Game Engine, it makes things "easy" to keep track of, and i can imagine "easy" to modify as well.
How you were able to understand all that is mystery though xD

The game itself doesn't find the VI's it just sends the 640x480 to some gamecube os functions. I'm not really very well versed in this kind of stuff; everything I tried to do to Wind Waker's video display settings when I first began trying to mod it just resulted in either absolutely nothing happening, the game immediately hardcrashing, or Dolphin crashing.

[Zerowalker]

Oh, Twilight sound like hell itself, can just imagine how painful it most be with such variables like events causing different results, i mean i am messing with super simple stuff and it takes like 24 hours to find one obvious thing.

It's awesome that you notice improvements in your skills yourself, that certainly adds to motivation!


Hmm, well GC functions themselves is something i guess i can't really access.
The only thing i actually want is the refresh rate (which int itself is basically the VI usually).
Though it doesn't seem to store such data, i can find 640x480 and 240x320 though, but those are useless as they can't tell me the refresh rate sadly;P
But it's not THAT important to have the data, it would just be kinda useful, even though i doubt 60fps+ would be that stable anyhow.

EDIT:

Have been trying forever without having a clue on how to prevent a certain bug from occuring with 60fps.
What happens is that you sometimes can't throw a Pikmin and you have to move around in order to do so, it's Very annoying and really make things hard in some combats.

I have tried out many things, but as it doesn't seem to be a value per say, and more about the update rate or something, i am kinda stuck.
I have investigated all functions with Throw, and these are the ones that seems to affect it (I used blr to skip each one of them).

Code:

 
  000fb1cc 000234 8010072c  4 throwPiki__4NaviFP4PikiR8Vector3f     plugPikiKando.a navi.cpp #Can Throw, But no distance
 00101f70 0003cc 801074d0  4 init__18NaviThrowWaitStateFP4Navi     plugPikiKando.a naviState.cpp #Prevents Throw - This gets Executed even on Fail at 60fps
  001023c8 00059c 80107928  4 exec__18NaviThrowWaitStateFP4Navi     plugPikiKando.a naviState.cpp #Throw Cause Stuck
 00102b18 0000a4 80108078  4 init__14NaviThrowStateFP4Navi     plugPikiKando.a naviState.cpp #Can Throw at Times, Bug alot
 00102bbc 00000c 8010811c  4 procTargetMsg__14NaviThrowStateFP4NaviP9MsgTarget     plugPikiKando.a naviState.cpp #Cause Only One Pikmin to be thrown
 00102bc8 000148 80108128  4 procAnimMsg__14NaviThrowStateFP4NaviP7MsgAnim     plugPikiKando.a naviState.cpp #Prevents Throw

If anyone has any insight at all, please give a shout

[JMC47]

Well, I would love to do a feature article + video on Dolphin's blog + youtube when it's ready. This isn't as someone affiliated as the team: as a fan of Wind Waker this really sounds like a dream come true and I want to make sure EVERYONE knows about it when it's ready.

[DarthVitrial]

So, dumb question from a huge fan of TP: is the 60fps hack you're working on only for the gamecube version, or will it work with the wii version(s)?

[Zerowalker]

Think he answered that before, and if i recall correctly, he will most likely not do it for Wii.

A huge reason being that Wii doesn't have a .map file, which is basically a file that will tell all functions and memory addresses which helps A LOT, in hacking.

(Don't take my word for it though).

[gamemasterplc]

The NTSC-U Wii version of Twilight Princess has a map file called RFrameworkF.map in the directory /map/RFinal/Release and the map file is accurate.