Zelda 64 Framerate "Conversion"

[wareya]

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

 

[dtm]

Here is wareya's background on the general theory of variable FPS in game engine design.

Here is a summary of wareya's further statements, which he could embellish:

For the increasing of OoT's FPS, there are currently several apparent courses of action. There are varying degrees of difficulty and accuracy, but they're all theoretical. And fully wacked out. But so was LLE ten years ago, and any Nintendo 64 emulation 20 years ago. Complaints thereof can go directly to /dev/null. <3

1) Rewrite the game's main loop so that actors are selectively simulated, as described above. This will have its own problems.

2) Write a game-independent mesh-interpolating graphics plugin of some sort. Technically, meshes are already interpolated, but only spatially. You'd want something that fills in the blanks temporally as well. Except, since the game doesn't provide the same kind of data time-wise, you need to use heuristics and threshholds to figure out what to interpolate. Good luck interpolating things that are undergoing LOD pop.

3) Write a game specific graphics plugin that ignores what the RSP/RDP are doing, replaces the game's rendering system, and just reads the game state itself.

4) Decompile OoT, reverse engineer and modify it for ten months or whatever.

 

[Fanatic 64]

5) Write a graphics plugin that does standard frame interpolation between finished frames.

6) Get a GameCube, Wii or 3DS and it's respective copy of OoT/MM.

7) Suck it up and play at 20 FPS. And be glad because emulators don't go below that framerate like the real console.

 

[wareya]

The GC and VC versions run at 20FPS as well.

5) adds a ton of processing issues and latency if it's going to look anything remotely approaching good.

7) Indeed.