wareya
New member
Hi, this will just be a straightforward infodump. Sorry for any strangeness.
https://www.youtube.com/watch?v=7FaOqn8ypJ4&hd=1&t=1m#t=1m
Before you ask: No patch, sorry. The required modifications take place in what is normally compressed data. If you want to do this yourself, you might need a Zelda 64 decompressor.
This applies to every Zelda 64 game. It might apply to Mario 64 and Animal Crossing as well, but I haven't even looked at them yet.
06:54 <@dtm> wareya: will you please make a post to emutalk.net containing the explanation you just gave me here, along with the other details you linked?
A few weeks ago, as I was trying to turn a PAL version of MM into an NTSC version (No, the region byte isn't a complete solution), I realized that different parts of the engine were running at different framerates. Ingame would run at 16.66 FPS. The file selection screen would run at 50 FPS. The pause menu would run at 25FPS.
Since I've worked on games with framerate changes before (see http://wareya.tumblr.com/post/81226191435/making-gg2-suck-less-physics-simulation-scaling) I immediately recognized this as some kind of framerate decimation or frameskipping. All I had to do was get into a memory state debugger (the same things 12 year olds use to make gameshark codes) and it was right in front of me (base/x = target framerate, in this case 60/1,2,3=60,30,20). Set some write breakpoints and I have the entire list of functions that set the decimation value. Changing the writes to load a different value into RAM changes the framerate without changing the physics significantly. Hallelujah!
No, this doesn't work very well on real hardware. Targeting a higher framerate than possible will NOT result in graceful framerate changes; the game will slow down.
Further info:
http://pb.ajf.me/index.php?topic=12.msg24#new
05:47 < wareya> The game has a "delta time" implementation built-in
05:48 < wareya> the ways its controlled is with a framerate decimation value (so to speak)
05:48 < wareya> it's normally set to 1 on the file select screen, 2 when paused, and 3 ingame
05:48 < wareya> 60fps 30fps 20fps respectively
05:48 < wareya> the game assumes that it's running at 20fps
05:48 < wareya> but there are some things that read the decimation value to tell how fast they should simulate
05:49 < wareya> with as link's movement and various animations
05:49 < wareya> The problem is that link's movement changes.
05:49 < wareya> Some things don't work right when you set it to a higher framerate
05:49 < wareya> like crawlspaces
05:49 < wareya> and anything involving link's gravity
05:49 < wareya> also, in MM, termina field enemy respawns time too fast
05:49 < wareya> so 60fps will have enemies respawn in 1/3rd the time
05:49 < wareya> the only solution is to basically rewrite every single buggy actor
05:49 < wareya> so it's virtually impossible to fix these problems
05:50 < wareya> alternatively, you could add an actor flagging system and make buggy ones run at a set framerate
05:50 < wareya> then the camera would be smooth and everything else would run at 20fps
05:50 < wareya> not ideal, but "sort of" a direct ugprade
05:50 < wareya> also it obviously doesn't work on real hardware for performance reasons
07:07 <@dtm> wareya: orly. WHY DID THEY DO THIS in the first place? :-D
07:07 < wareya> they're not bug-identical, but OoT 3DS tried to keep as many non-breaking bugs as possible
07:07 < wareya> uhhh
07:07 < wareya> zelda 64's engine is based on mario 64's
07:07 < wareya> very good chance that in early beta they were working on 30fps code
07:07 <@dtm> is the performance ceiling so low that they had to BRUTALLY anchor it down for consistency?
07:07 < wareya> then realized they had to make it 20fps
07:07 < wareya> for performance reasons
07:07 < wareya> adding in delta time just in case they could go back to 30fps at some point is a win/win
07:07 <@dtm> i mean why not let it do what it does? let the fps cards fall as they may?
07:07 < wareya> they have to rewrite things anyway
07:08 < wareya> framerate variance is REALLY annoying
07:08 < wareya> it makes physics change in consistency or speed
07:08 <@dtm> i just don't understand why anything is tied to fps at all
07:08 < wareya> because writing games logic is hard
Me ****ing around in nemu until I hit it: http://youtu.be/4J9fRWiQLn4 http://youtu.be/N3i34GPHmAA
https://www.youtube.com/watch?v=7FaOqn8ypJ4&hd=1&t=1m#t=1m
Before you ask: No patch, sorry. The required modifications take place in what is normally compressed data. If you want to do this yourself, you might need a Zelda 64 decompressor.
This applies to every Zelda 64 game. It might apply to Mario 64 and Animal Crossing as well, but I haven't even looked at them yet.
06:54 <@dtm> wareya: will you please make a post to emutalk.net containing the explanation you just gave me here, along with the other details you linked?
A few weeks ago, as I was trying to turn a PAL version of MM into an NTSC version (No, the region byte isn't a complete solution), I realized that different parts of the engine were running at different framerates. Ingame would run at 16.66 FPS. The file selection screen would run at 50 FPS. The pause menu would run at 25FPS.
Since I've worked on games with framerate changes before (see http://wareya.tumblr.com/post/81226191435/making-gg2-suck-less-physics-simulation-scaling) I immediately recognized this as some kind of framerate decimation or frameskipping. All I had to do was get into a memory state debugger (the same things 12 year olds use to make gameshark codes) and it was right in front of me (base/x = target framerate, in this case 60/1,2,3=60,30,20). Set some write breakpoints and I have the entire list of functions that set the decimation value. Changing the writes to load a different value into RAM changes the framerate without changing the physics significantly. Hallelujah!
No, this doesn't work very well on real hardware. Targeting a higher framerate than possible will NOT result in graceful framerate changes; the game will slow down.
Further info:
http://pb.ajf.me/index.php?topic=12.msg24#new
05:47 < wareya> The game has a "delta time" implementation built-in
05:48 < wareya> the ways its controlled is with a framerate decimation value (so to speak)
05:48 < wareya> it's normally set to 1 on the file select screen, 2 when paused, and 3 ingame
05:48 < wareya> 60fps 30fps 20fps respectively
05:48 < wareya> the game assumes that it's running at 20fps
05:48 < wareya> but there are some things that read the decimation value to tell how fast they should simulate
05:49 < wareya> with as link's movement and various animations
05:49 < wareya> The problem is that link's movement changes.
05:49 < wareya> Some things don't work right when you set it to a higher framerate
05:49 < wareya> like crawlspaces
05:49 < wareya> and anything involving link's gravity
05:49 < wareya> also, in MM, termina field enemy respawns time too fast
05:49 < wareya> so 60fps will have enemies respawn in 1/3rd the time
05:49 < wareya> the only solution is to basically rewrite every single buggy actor
05:49 < wareya> so it's virtually impossible to fix these problems
05:50 < wareya> alternatively, you could add an actor flagging system and make buggy ones run at a set framerate
05:50 < wareya> then the camera would be smooth and everything else would run at 20fps
05:50 < wareya> not ideal, but "sort of" a direct ugprade
05:50 < wareya> also it obviously doesn't work on real hardware for performance reasons
07:07 <@dtm> wareya: orly. WHY DID THEY DO THIS in the first place? :-D
07:07 < wareya> they're not bug-identical, but OoT 3DS tried to keep as many non-breaking bugs as possible
07:07 < wareya> uhhh
07:07 < wareya> zelda 64's engine is based on mario 64's
07:07 < wareya> very good chance that in early beta they were working on 30fps code
07:07 <@dtm> is the performance ceiling so low that they had to BRUTALLY anchor it down for consistency?
07:07 < wareya> then realized they had to make it 20fps
07:07 < wareya> for performance reasons
07:07 < wareya> adding in delta time just in case they could go back to 30fps at some point is a win/win
07:07 <@dtm> i mean why not let it do what it does? let the fps cards fall as they may?
07:07 < wareya> they have to rewrite things anyway
07:08 < wareya> framerate variance is REALLY annoying
07:08 < wareya> it makes physics change in consistency or speed
07:08 <@dtm> i just don't understand why anything is tied to fps at all
07:08 < wareya> because writing games logic is hard
Me ****ing around in nemu until I hit it: http://youtu.be/4J9fRWiQLn4 http://youtu.be/N3i34GPHmAA
Last edited: