Why Retro Games Tied Simulation to Framerate?

Oh yes ZOE2 demonstrated that very very well too.
So the game gave the impression that it had a slow mo effect instead of frame drops when that happened.
It certainly prevented the gameplay from feeling broken or unresponsive by framerate. Although I remember the slow downs I dont remember the game having a bad experience when they occured.
On the contrary I remember PS3 and 360 games where the framedrops ruined the experience

 

Played ZOE2 a good 5 hours in, on fat PS2 hardware, havent encountered any framerate drops yet? What i do notice with Transformers ps2, the one done by melbourne house, the game slows down a good bit, and blurs abit, to hide the FPS drops, but they are clearly noticeble.

 

Zoe doesn't drop framerate. It slows down

It also slow down on epic scenes so it feels deliberate

 

It seems that some developers prefer it for this reason and allowing player more time to react on hectic moments of gameplay, instead of suddenly missing change to jump due to failing framerate.

On PC developers were forced to handle it properly by either capping framerate or having variable frametime due to incredible pace of increasing performance on machines.
Early games failed and thus we had games like Falcon cga which was unplayable on any later machine. (Press throttle and see some random bridge go by before you could lift off.)

 

Software evolution. Originally you had a fixed game loop that did everything. Start frame > input > movement > draw graphics > draw frame > loop. This ties everything to the draw rate giving inconsistent behaviour. Somewhere along the line it was decided to run world update and drawing loops independently, such that even if a frame took 5 video refreshes to draw, the game could experience 5 updates to the game world, so everything was drawn in the expected place instead of moving 1/5th the speed. This now also means both faster updates than refresh allows, so 200+ Hz physics update on racers along with super fast input polling for low, low latency, and more efficient low-refresh rate on aspects of the game such as AI or physics working at less than draw speed.

This development may have been dependent on the development of hardware interrupts to allow thread switching; I'm not sure if it could be pulled off on the basic linear processors of old.

 

Perhaps the Nintendo 64 was the last example of this behaviour? I mean, you just can't play some Nintendo 64 games at 60 fps, as the ideal framerate, while you can play many other games from platforms of the era and above.

This is clearly visible in games like one of my favourite games ever, Diddy Kong Racing. You can't lock the framerate at 60 fps, either it is the original framerate or whatever your machine pulls off. I played Diddy Kong Racing at 240-450 fps, which means that the game just basically was like in Fast Forward mode x 20 most of the time, totally unplayable, yet the times per lap were accurate and you wouldn't be cheating at that speed, of course.

 

I guess it just made things more predictable and easier to test. Those games would run on just that particular platform so there was no need to account for a variable hardware target.

 

Making framerate and physics independent can have a high cost.
Physics usually only work if we update them with a constant timestep, e.g. the expected frametime. But when both gets out of sync, you have to do 2 physics updates per frame or none at all. Likely this makes the framerate inconsistent, causes input lag, etc.

The solution is either multithreading, or interrupting the physics work when frame needs to be drawn on older single core systems.
Both also require to store the previous state(s) of physics so the visible positions can be inter-/extrapolated to current realtime for display. This mostly causes a lag of one frame.

So if you know the hardware can hold fixed framerate like earlier consoles did, the best solution is to do both in sync to avoid all this complexity. That's why older games can't be emulated at higher framerate.

 

Versus fighter games are all about animation frames, so it's important to sync there although I'd be curious to see a post-mortem on how the folks working on Killer Instinct 2013 arrived at the 90Hz tic and its implications for online. That's probably something that would be of particular interest to all the fighters that use Unreal Engine 3/4 these days since the networking (so I've come to hear) is another thing to add to the garbage pile.

Team Ninja could learn a thing or two as well although I'm not sure if they simply have a relative explosion of data to sync considering it has the additional dimension of movement. It was bad enough that an online session saw additive latency depending on how many folks were in the lobby (not actually playing lol) in DOA5.

:V

 

Surprisingly a decent number of games can be emulated at a higher framerate.

 

Likely they are written with variable framerate in mind and adapt to the hardware power (nowadays standard).
Or maybe some emulators use special tricks as well?

 

Generally you have to modify the game code with a gameshark style cheat (MGS3 and Mario Sunshine are good examples). Games on newer systems like PS3 and 360 naturally are more likely to support variable framerates.

 

I guess this works by changing the numbers that relate to timestep? Must be quite a few per game - i wonder how people figure them out. I mean it's not like a score number that changes and so is easy to find. Maybe spotting differences between PAL and NTSC versions can help?

However, i appreciate the effort here. All those games would get lost without emulation.

 

Idk, in my experience it's been just one cheat.

Well, at least for MGS3. But it's not surprising that the engine supported 60 fps in that case. Mario sunshine seems pretty simple too with 2 different 60 fps cheats. Apparently the game was initially going to be 60 fps but they locked it down to 30 because it very occasionally dropped frames. Classic nintendo lol.

 

I have the impression that the initial MGS3 reveals demonstrated a 60fps or at least it was the initial framerate targeted. We can guess why they went with 30fps at the end

 

From what I remember reading, their locomotion/AI/visibility/animation systems all hadhto become way more complex when the levels became more organic. That was the reason for the drop.

 

On PC there have been examples of simulation or game speed being tied to framerate that caused problems when new hardware came out that rendederd those games unplayable. jlippo mentioned Falcon CGA, but also games like Wing Commander are unplayable at high frame rates. And it didn't stop with DOS games either. I remember upgrading my computer and finding that Wipeout XL ran too fast, and that the timer was lined to framerate, so it was impossible to get 2 cheackpoints in before running out of time. I think you see it less on PC because there was a history of it causing a problem, while on console there is a bit of well placed short sightedness in developing for fixed hardware. It's not like anyone was thinking about emulating the game on WiiU 20 years in the future when they were developing Starfox 64. The assumption was, once the next console comes out, it's all new games.

On a side note, I also remember playing Wolf3d from my original* floppy disk on a 1ghz Athlon and being amazed that it was playable. It's pretty uncommon for a game to contemporaneously push the technological envelope and not use features or techniques that break with newer hardware like that.

*sort of original. Floppy disks were easy to share.

 

Interestingly FF7 also runs blazing fast on emulation. Even the FMVs and sound play at faster speed.

 

Why doesn't it have online co-op?

ModCopyEdit: Bits copied to spin-off