• Login
  • Register
  • Dolphin Forums
  • Home
  • FAQ
  • Download
  • Wiki
  • Code


Dolphin, the GameCube and Wii emulator - Forums › Dolphin Site › dolphin-emu.org articles v
1 2 3 Next »

Game Modification: 60 FPS Hacks and Patches
View New Posts | View Today's Posts

Pages (84): « Previous 1 ... 30 31 32 33 34 ... 84 Next »
Jump to page 
Thread Rating:
  • 3 Vote(s) - 5 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Thread Modes
Game Modification: 60 FPS Hacks and Patches
10-20-2016, 11:50 PM (This post was last modified: 10-20-2016, 11:54 PM by Meowmaritus.)
#311
Meowmaritus Offline
Zelda Enthusiast
***
Posts: 111
Threads: 0
Joined: Oct 2016
(10-20-2016, 06:53 PM)Zerowalker Wrote: Hmm, i can get the dividing part to work.
However, no matter what i do the game goes into and endless loop if i alter that section.

Even if i alter it by using the same function.
In this case "fmr f1, f31".
So if i replace that, with the same function, it will still go into an endless loop.
It makes no sense to me, shouldn't it be exactly the same, the only difference is a branch jump which i expect shouldn't really do any harm, except maybe a performance loss.

EDIT:


//Original Code
801a133c: fmr f1, f31
//Gecko Code
C21A133C 00000001
FC20F890 00000000
//ASM
Address: 801A133C
fmr f1,f31

It being an endless loop even with the original code sounds like some kind of LR problem or something like that causing a BLR to goof.
Paste the first 10 or so instructions of the Pikmin function you're injecting code into and the last 10 or so instructions and I'll see if I can help without you pasting an entire function in here (pasting an entire function might be dangerous in terms of forum rules, idk) 

EDIT: If that's the exact code your code generator spit out then something's wrong; there absolutely has to be a nop instruction at the end of all gecko ASM injection codes (so that the code handler has a "slot" in which to put the branch instruction). This is the proper way for that gecko code to be generated:
C21A133C 00000002
FC20F890 00000000
60000000 00000000
Find
Reply
10-21-2016, 05:19 AM (This post was last modified: 10-21-2016, 06:30 AM by Meowmaritus.)
#312
Meowmaritus Offline
Zelda Enthusiast
***
Posts: 111
Threads: 0
Joined: Oct 2016
I rewrote all of my code for the 60 FPS mod, making some improvements:
  • The same edits I mentioned doing in 64 lines of Gecko codes previously is now done in just 43 lines of Gecko codes.
  • I have a main update function on the script now which writes base values each frame that all the other codes read from.
  • I no longer save a 0.5 float in almost every single code (now its only saved in the main update function and accessed everywhere else).
  • All the custom data the main update handles is mapped in a symbol map file.
  • It is now much easier for me to add new code injections with my new format.
  • The best benefit of all: The desired framerate number is now adjustable entirely from one gecko code: 1 for 30 FPS, 2 for 60 FPS, 3 for 90 FPS, etc. All of my multiplication and division of various values scales off that modifier now, rather than relying on bit shifting, multiplying by hardcoded floats, etc. As soon as you change the value, the game's FPS will change immediately and all values will be scaled accordingly (there are a few values in the game are only read on loading screen transitions so that might be required. However, as of now, none of the codes require a screen transition)
  • Every single Gecko code has an exact corresponding .ASM file that's fully commented and both are always updated simultaneously. This makes it much easier for me to stay organized.
  • The codes lag the game noticeably less than before.


ALSO: A general update about the mod itself, rather than all this housekeeping junk: Previously you may have noticed on the Twilight Princess 60 FPS demo video I uploaded that the menus were all running at double speed. In Wind Waker I figured out how to make the menus still 60 FPS (and the animations are still double speed on the menu but seriously who cares) but without the cursor moving too fast to control properly, resulting in a really quick, snappy 60 FPS menu that feels nicer to control than the original.


Here's the contents of FPSHack_MAIN_UPDATE.asm if you wanna see:
Spoiler: (Show Spoiler)

#To be inserted at 80006410
#######################
##FPSHack_MAIN_UPDATE##
#######################

##### Set e3 to Base Addr #####
#We can mess with r3 because it gets loaded
#to the proper value in the vanilla instruction
#at the very end of this function (the one that we're replacing).
lis r3, 0x817F

##### Backup Registers #####
stw r10, 0x10 (r3)
stw r11, 0x14 (r3)
stw r12, 0x18 (r3)
stw r13, 0x1C (r3)
stfd f10, 0x20 (r3)
#0x24 used by f10
stfd f11, 0x28 (r3)
#0x2C used by f11



##### Load Useful Values #####
lis r10, 0x803F
ori r10, r10, 0x6854
lwz r10, 0 (r10) #Load WW frame counter

lis r11, 0x817F
lwz r11, 0x0008 (r11) #Load FramerateFactor


##### Set: byte LowHzFuncsRunThisFrame(817F0000) #####
#r12 = r10(Framecounter) % r11(FramerateFactor)
divwu r12, r10, r11 #r12 = quotient
mullw r12, r12, r11 #r12 = quotient * divisor
subf r12, r12, r10 #r12 = remainder

li r13, 0 #LowHzFuncsRunThisFrame = 0 (default value)
cmpwi r12, 0 #Compare the modulo'd framecounter to 0
bne- 0x0008 #If != 0, skip straight to LowHzFuncsRunThisFrame storage, storing 0
li r13, 1 #If == 0, then store 1 for LowHzFuncsRunThisFrame
stw r13, 0 (r3) #Store LowHzFuncsRunThisFrame(817F0000)


##### Set: FloatSlowdown(817F0004) #####
lis r12, 0x4330
stw r12, 0x30 (r3) #Store 0x43300000 into upper
li r12, 0
stw r12, 0x34 (r3) #Store 0x00000000 into lower
lfd f11, 0x30 (r3) #Load 0x4330000000000000 into f11

lis r12, 0x4330
stw r12, 0x30 (r3) #Store 0x43300000 into upper
stw r11, 0x34 (r3) #Store FramerateFactor into lower
lfd f10, 0x30 (r3) #Load (0x4330000000000000 + FramerateFactor) into f10

fsub f10, f10, f11 #Magically make f10 = the float representation of FramerateFactor

lis r12, 0x3F80
stw r12, 0x30 (r3)
lfs f11, 0x30 (r3) #Load 1.0 into f11

fdivs f10, f11, f10 #f10 = (f11 / f10) = (1.0 / FramerateFactor)

stfs f10, 0x0004 (r3) #FINALLY, store FloatSlowdown!



##### Set: WW Tick Rate Value (804C8D44) #####
#Number of ticks in 1/30 of a second: 1350000, or 0x00149970
lis r12, 0x0014
ori r12, r12, 0x9970 #Load default tick rate into r12

divwu r11, r12, r11 #r11 = (r12 / r11) = (Default tick rate / FramerateFactor)

lis r12, 0x804C
ori r12, r12, 0x8D44 #Load the WW Tick Rate address

stw r11, 0x0000 (r12) #Store the custom tick where the normal one would normally be.

##### Restore Register Backups #####
lwz r10, 0x10 (r3)
lwz r11, 0x14 (r3)
lwz r12, 0x18 (r3)
lwz r13, 0x1C (r3)
lfd f10, 0x20 (r3)
#0x24 used by f10
lfd f11, 0x28 (r3)
#0x2C used by f11

##### Execute Vanilla Instruction And Exit #####
lwz r3, -0x788C (r13) #VANILLA





EDIT (Didn't feel like triple-posting): I just wanted to mention that I FINALLY got all of Link's movement speed ironed out on Wind Waker. He now has proper gravitational acceleration and can successfully hop over tiny ledges. Next thing I'm going to work on is getting the darn Wind Waker's tempo to stop being doubled (getting the Iron Boots to equip properly on Link is next).
Find
Reply
10-21-2016, 07:07 AM
#313
theboy181 Offline
Member
***
Posts: 60
Threads: 6
Joined: Feb 2015
(10-21-2016, 05:19 AM)Meowmaritus Wrote: I rewrote all of my code for the 60 FPS mod, making some improvements:
  • The same edits I mentioned doing in 64 lines of Gecko codes previously is now done in just 43 lines of Gecko codes.
  • I have a main update function on the script now which writes base values each frame that all the other codes read from.
  • I no longer save a 0.5 float in almost every single code (now its only saved in the main update function and accessed everywhere else).
  • All the custom data the main update handles is mapped in a symbol map file.
  • It is now much easier for me to add new code injections with my new format.
  • The best benefit of all: The desired framerate number is now adjustable entirely from one gecko code: 1 for 30 FPS, 2 for 60 FPS, 3 for 90 FPS, etc. All of my multiplication and division of various values scales off that modifier now, rather than relying on bit shifting, multiplying by hardcoded floats, etc. As soon as you change the value, the game's FPS will change immediately and all values will be scaled accordingly (there are a few values in the game are only read on loading screen transitions so that might be required. However, as of now, none of the codes require a screen transition)
  • Every single Gecko code has an exact corresponding .ASM file that's fully commented and both are always updated simultaneously. This makes it much easier for me to stay organized.
  • The codes lag the game noticeably less than before.


ALSO: A general update about the mod itself, rather than all this housekeeping junk: Previously you may have noticed on the Twilight Princess 60 FPS demo video I uploaded that the menus were all running at double speed. In Wind Waker I figured out how to make the menus still 60 FPS (and the animations are still double speed on the menu but seriously who cares) but without the cursor moving too fast to control properly, resulting in a really quick, snappy 60 FPS menu that feels nicer to control than the original.


Here's the contents of FPSHack_MAIN_UPDATE.asm if you wanna see:
Spoiler: (Show Spoiler)

#To be inserted at 80006410
#######################
##FPSHack_MAIN_UPDATE##
#######################

##### Set e3 to Base Addr #####
#We can mess with r3 because it gets loaded
#to the proper value in the vanilla instruction
#at the very end of this function (the one that we're replacing).
lis r3, 0x817F

##### Backup Registers #####
stw r10, 0x10 (r3)
stw r11, 0x14 (r3)
stw r12, 0x18 (r3)
stw r13, 0x1C (r3)
stfd f10, 0x20 (r3)
#0x24 used by f10
stfd f11, 0x28 (r3)
#0x2C used by f11



##### Load Useful Values #####
lis r10, 0x803F
ori r10, r10, 0x6854
lwz r10, 0 (r10) #Load WW frame counter

lis r11, 0x817F
lwz r11, 0x0008 (r11) #Load FramerateFactor


##### Set: byte LowHzFuncsRunThisFrame(817F0000) #####
#r12 = r10(Framecounter) % r11(FramerateFactor)
divwu r12, r10, r11 #r12 = quotient
mullw r12, r12, r11 #r12 = quotient * divisor
subf r12, r12, r10 #r12 = remainder

li r13, 0 #LowHzFuncsRunThisFrame = 0 (default value)
cmpwi r12, 0 #Compare the modulo'd framecounter to 0
bne- 0x0008 #If != 0, skip straight to LowHzFuncsRunThisFrame storage, storing 0
li r13, 1 #If == 0, then store 1 for LowHzFuncsRunThisFrame
stw r13, 0 (r3) #Store LowHzFuncsRunThisFrame(817F0000)


##### Set: FloatSlowdown(817F0004) #####
lis r12, 0x4330
stw r12, 0x30 (r3) #Store 0x43300000 into upper
li r12, 0
stw r12, 0x34 (r3) #Store 0x00000000 into lower
lfd f11, 0x30 (r3) #Load 0x4330000000000000 into f11

lis r12, 0x4330
stw r12, 0x30 (r3) #Store 0x43300000 into upper
stw r11, 0x34 (r3) #Store FramerateFactor into lower
lfd f10, 0x30 (r3) #Load (0x4330000000000000 + FramerateFactor) into f10

fsub f10, f10, f11 #Magically make f10 = the float representation of FramerateFactor

lis r12, 0x3F80
stw r12, 0x30 (r3)
lfs f11, 0x30 (r3) #Load 1.0 into f11

fdivs f10, f11, f10 #f10 = (f11 / f10) = (1.0 / FramerateFactor)

stfs f10, 0x0004 (r3) #FINALLY, store FloatSlowdown!



##### Set: WW Tick Rate Value (804C8D44) #####
#Number of ticks in 1/30 of a second: 1350000, or 0x00149970
lis r12, 0x0014
ori r12, r12, 0x9970 #Load default tick rate into r12

divwu r11, r12, r11 #r11 = (r12 / r11) = (Default tick rate / FramerateFactor)

lis r12, 0x804C
ori r12, r12, 0x8D44 #Load the WW Tick Rate address

stw r11, 0x0000 (r12) #Store the custom tick where the normal one would normally be.

##### Restore Register Backups #####
lwz r10, 0x10 (r3)
lwz r11, 0x14 (r3)
lwz r12, 0x18 (r3)
lwz r13, 0x1C (r3)
lfd f10, 0x20 (r3)
#0x24 used by f10
lfd f11, 0x28 (r3)
#0x2C used by f11

##### Execute Vanilla Instruction And Exit #####
lwz r3, -0x788C (r13) #VANILLA





EDIT (Didn't feel like triple-posting): I just wanted to mention that I FINALLY got all of Link's movement speed ironed out on Wind Waker. He now has proper gravitational acceleration and can successfully hop over tiny ledges. Next thing I'm going to work on is getting the darn Wind Waker's tempo to stop being doubled (getting the Iron Boots to equip properly on Link is next).
Looking forward to more videos or even better something to test. Will these codes be cheat codes or will we have to inject ASM when it's released ?
Find
Reply
10-21-2016, 07:59 AM (This post was last modified: 10-21-2016, 08:09 AM by Meowmaritus.)
#314
Meowmaritus Offline
Zelda Enthusiast
***
Posts: 111
Threads: 0
Joined: Oct 2016
(10-21-2016, 07:07 AM)theboy181 Wrote: Looking forward to more videos or even better something to test. Will these codes be cheat codes or will we have to inject ASM when it's released ?

The current implementation consists of 11 Gecko ASM injection codes which are 97 lines long all together. Also I won't have anybody testing the codes. I'm going to get it where everything appears flawless enough that I have no doubts the game is playable to the end without any annoying glitches (NOTE: I'm not actually going to play the game to the end. I'm gonna go with my instincts on that and fix any bugs that arise). The mod is going really well and I'm getting much better and faster at the process as I go along. In fact, I mentioned that I'd be trying to get the Wind Waker (the item Link uses, not the game itself) to stop being double tempo about an hour ago and I've had it working properly for like 20 minutes now. I guess what I'm trying to say is that you can rest assured that I'll be finishing the mod very soon.

Also, for clarification: The reason I'm being so ridiculously secretive of this mod is because I do not want it to get leaked and for a lot of people to try it, only to find a fuckload of bugs and give up on all their dreams of playing their favorite 30 FPS Dolphin games in >=60FPS. My goal is for the mod to be so polished that if you take footage of the game running 60 FPS with the mod and apply frameskip to it, you should be unable to tell the difference between the frameskipped footage of the modded game and footage of the vanilla game (at a glance, at least).


FACTOID TIME: Wind Waker and Twilight Princess normally poll for input at 30 Hz but enabling my mods make the input polling rate increase alongside the framerate, making the game feel more responsive.


Edit: Just thought I'd mention that I'm fully finishing Wind Waker's FPS mod before I really get started on Twilight Princess's. When I'm done with the Wind Waker mod, I'm going to create a thread for both mods (since the game engines are really similar and require the same feedback for bugs etc). The Wind Waker mod will be available to play with but the Twilight Princess mod will just say "Coming Soon" or whatever. I'll definitely be sure to tell you guys about the new thread when I create it.

If I'm making any typos or errors or anything its because I've been awake for 26 hours (note: NOT because of me working on the mod all night I; just couldn't sleep. In fact, last night I mostly just played the Pokemon Sun and Moon demo)
Find
Reply
10-21-2016, 10:27 AM
#315
retroben Offline
N64 Code Hunter
****
Posts: 328
Threads: 21
Joined: Jul 2015
Twilight Princess has leftovers from Wind Waker such as several items including the Tingle Tuner as referenced in the article on tcrf,so that would explain the similarity,it makes me wonder if model imports would work between them for some interesting and fun results.

https://tcrf.net/The_Legend_of_Zelda:_Twilight_Princess/Unused_Models

Really wished they would have got images showcasing them fully by now,oh well.
A certain other character was a placeholder for another one as seen in the unused textures section.
Shield TV Pro (stock/non-rooted OTA 6.3)

Acer Aspire E 15 E5-575G-59EE

CPU: i5-6200U 2.3-2.8Ghz _ GPU: Nvidia GeForce 940MX 2GB (GDDR5) VRAM
Hyundai 8GB DDR4 Dual-channel SDRAM _ 1000GB HDD
New; CPU: Intel i9 9900KF_ GPU: Nvidia RTX 2060 Super | ◕‿◕
Find
Reply
10-21-2016, 12:16 PM
#316
Meowmaritus Offline
Zelda Enthusiast
***
Posts: 111
Threads: 0
Joined: Oct 2016
Just gonna leave this here https://youtu.be/yrLIpqnswjE
Find
Reply
10-21-2016, 12:37 PM
#317
JMC47 Offline
Content Producer
*******
Content Creators (Moderators)
Posts: 6,544
Threads: 29
Joined: Feb 2013
RIP. Looks fun when it works though.
Find
Reply
10-21-2016, 02:07 PM
#318
Meowmaritus Offline
Zelda Enthusiast
***
Posts: 111
Threads: 0
Joined: Oct 2016
I made another short little preview thingy https://youtu.be/U0_jh8h26mU
Find
Reply
10-21-2016, 02:17 PM
#319
theboy181 Offline
Member
***
Posts: 60
Threads: 6
Joined: Feb 2015
The second videos camera looked a little jerky. Has the camera been slowed down?
Find
Reply
10-21-2016, 02:36 PM (This post was last modified: 10-21-2016, 02:50 PM by Zerowalker.)
#320
Zerowalker Offline
Member
***
Posts: 208
Threads: 19
Joined: Jan 2016
Now this is a lot of posts,
amazing stuff has happenedBig Grin

Will ask two questions quick for this.

Does all games use a FrameCounter, as i noticed that in your WW code?

Also, my code Never does NOP i think, what code Generator are you using, i use CodeWrite,
but if it just has to be a NOP after each Gecko Code, i think it should be Fairly easy to mod.

And yeah it is the BLR that later causes a weird jump.
Though it seems to be effected by the save state, cause i notice that other save states work fine.
So not sure if it's the place of the game, or my save state that is corrupted by the code or something.
Find
Reply
« Next Oldest | Next Newest »
Pages (84): « Previous 1 ... 30 31 32 33 34 ... 84 Next »
Jump to page 


  • View a Printable Version
  • Subscribe to this thread
Forum Jump:


Users browsing this thread: 1 Guest(s)



Powered By MyBB | Theme by Fragma

Linear Mode
Threaded Mode