Why Retro Games Tied Simulation to Framerate?

Discussion in 'Console Technology' started by Goodtwin, Feb 8, 2019.

  1. Goodtwin

    Veteran Newcomer Subscriber

    Joined:
    Dec 23, 2013
    Messages:
    1,076
    Likes Received:
    570
    While playing Star Fox 64 on my Wii U for the past couple days I noticed the game seemed more difficult than I remember on the N64. After doing some research, I learned that the emulation on the Wii U keeps the game running at the target framerate almost all the time, while the original N64 had a lot of slowdown. This causes the Virtual Console version to play a lot faster, and has taken some time to acclimate.

    Up until the PS2/GC/Xbox generation, slowdown and framerate drops were essentially the same thing. If the framerate dropped, the game speed slowed down. This was certainly true with the 8bit and 16bit consoles. What caused/enabled developers to separate the game simulation from the rendering framerate?

    I sort of prefer the simulation being tied to the framerate. It is easier to manage a chugging framerate when the game speed goes into slow motion. The judder we experience these days with framerates not maintaining the target framerate is more distracting in my opinion.

    So I suppose I am really just curious as how this game to be, and would be interested in knowing if this was more of a hardware or software related evolution?
     
    Nesh likes this.
  2. Nesh

    Legend

    Joined:
    Oct 2, 2005
    Messages:
    10,691
    Likes Received:
    1,418
    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
     
    Goodtwin likes this.
  3. vipa899

    Regular Newcomer

    Joined:
    Mar 31, 2017
    Messages:
    922
    Likes Received:
    348
    Location:
    Sweden
    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.
     
  4. orangpelupa

    orangpelupa Elite Bug Hunter
    Legend Veteran

    Joined:
    Oct 14, 2008
    Messages:
    6,823
    Likes Received:
    1,143
    Zoe doesn't drop framerate. It slows down

    It also slow down on epic scenes so it feels deliberate
     
    vipa899 likes this.
  5. jlippo

    Veteran Regular

    Joined:
    Oct 7, 2004
    Messages:
    1,236
    Likes Received:
    289
    Location:
    Finland
    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.)
     
  6. Shifty Geezer

    Shifty Geezer uber-Troll!
    Moderator Legend

    Joined:
    Dec 7, 2004
    Messages:
    39,581
    Likes Received:
    9,605
    Location:
    Under my bridge
    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.
     
    Goodtwin and Cyan like this.
  7. Cyan

    Cyan orange
    Legend Veteran

    Joined:
    Apr 24, 2007
    Messages:
    8,183
    Likes Received:
    1,981
    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.
     
  8. OCASM

    Regular Newcomer

    Joined:
    Nov 12, 2016
    Messages:
    754
    Likes Received:
    709
    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.
     
  9. JoeJ

    Regular Newcomer

    Joined:
    Apr 1, 2018
    Messages:
    260
    Likes Received:
    269
    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.
     
    Cyan, OCASM and AlBran like this.
  10. AlBran

    AlBran Just Monika
    Moderator Legend

    Joined:
    Feb 29, 2004
    Messages:
    20,002
    Likes Received:
    4,931
    Location:
    ಠ_ಠ
    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. o_O



    :V
     
    #10 AlBran, Feb 15, 2019
    Last edited: Feb 15, 2019
Loading...

Share This Page

  • About Us

    Beyond3D has been around for over a decade and prides itself on being the best place on the web for in-depth, technically-driven discussion and analysis of 3D graphics hardware. If you love pixels and transistors, you've come to the right place!

    Beyond3D is proudly published by GPU Tools Ltd.
Loading...