No idea why they attached the FPS directly to the hardware.
It’s the most trivial and straight forward thing to do. The game is a simple loop of:
get user input (can be nothing)
calculate new game state based on old state and input
draw new game state.
The speed of the game is now 100% dependant on the speed of computation.
NOT attaching fps to hardware is the hard thing, as you need to detach the game state loop and the drawing loop and then synchronize them. Doing that yourself is extremely complicated. Today developers don’t even need to think about that because the whole drawing loop is abstracted away by things like directX/Vulcan and the game engine. But without those tools, fps tied to CPU speed is basically the default.
And in fairness a lot of microcomputers at the time were closed specs. Even on PC for a while you were theoretically aiming at a 4Mhz XT or, at worst, also wanted to account for a 8MHz AT. By the time IBM clones had become… you know, just PCs, a lot of devs either didn’t get the memo or chose to ignore it for the reasons you list.
Most of the time “lazy devs” are just “overworked and underfunded devs”, but the point is, that didn’t start this century.
Also games have gotten way more complicated since the gameboy colour era. I’ve coded a basic 2D physics engine from scratch (literally just circles with soft collisions) and its not just enough to set up the vector math correctly. You can literally make a true to real life physics model (as far as the math of infinitely rigid perfect spheres on a perfectly flat plane goes anyway) and have all sorts of problems crop up because computers aren’t the universe and order of computation is a bitch.
Even the first Dark Souls had game ticks tied to the FPS because consoles had been standardized to 30 FPS for decades.
On the PC port, it was locked to 30 FPS, but a super popular mod unlocked the FPS, and at 60 FPS DoT effects ticked twice as fast, and at even higher FPS could kill you before you had time to react.
It’s the most trivial and straight forward thing to do. The game is a simple loop of:
The speed of the game is now 100% dependant on the speed of computation. NOT attaching fps to hardware is the hard thing, as you need to detach the game state loop and the drawing loop and then synchronize them. Doing that yourself is extremely complicated. Today developers don’t even need to think about that because the whole drawing loop is abstracted away by things like directX/Vulcan and the game engine. But without those tools, fps tied to CPU speed is basically the default.
And in fairness a lot of microcomputers at the time were closed specs. Even on PC for a while you were theoretically aiming at a 4Mhz XT or, at worst, also wanted to account for a 8MHz AT. By the time IBM clones had become… you know, just PCs, a lot of devs either didn’t get the memo or chose to ignore it for the reasons you list.
Most of the time “lazy devs” are just “overworked and underfunded devs”, but the point is, that didn’t start this century.
Also games have gotten way more complicated since the gameboy colour era. I’ve coded a basic 2D physics engine from scratch (literally just circles with soft collisions) and its not just enough to set up the vector math correctly. You can literally make a true to real life physics model (as far as the math of infinitely rigid perfect spheres on a perfectly flat plane goes anyway) and have all sorts of problems crop up because computers aren’t the universe and order of computation is a bitch.
Even the first Dark Souls had game ticks tied to the FPS because consoles had been standardized to 30 FPS for decades.
On the PC port, it was locked to 30 FPS, but a super popular mod unlocked the FPS, and at 60 FPS DoT effects ticked twice as fast, and at even higher FPS could kill you before you had time to react.
GTA San Andreas has an option to uncap the framerate on PC, which outright breaks certain mechanics.