Well we can distinguish here between frame-locked games, like most 90’s and earlier games, and frame-independent games.
Frame-locked games run everything on the number of graphics frame that tick by (each frame time = either 1/60 second or 1/30 second). If the game slows down the entire logic slows down and you literally are playing the game in slow motion. These are also games that can’t be run at higher frame rates without the entire game running at high speed.
Frame-independent games run everything on the real-world time passing (each frame time = current time - last frame’s time, hope it’s stable!). If it’s been a whole half-second since it last rendered to the screen, well, everything will have moved that far. If your framerate is low you are getting snapshots into a world moving by. PC games have been like this a lot longer because of the need to accommodate a mystery hardware. But these games should be able to scale to high framerates and treat temporal resolution as a target just like screen resolution.
Japan has held onto frame-locked programming for a long time (like many Japanese game coding practices…). Zone of the Enders’ 360/PS3 port revealed these issues when it permanently ran in slow-motion because it couldn’t sustain the 60FPS the game required.
I don’t know why overclocking the Super FX chip doesn’t make Star Fox and Stunt Race run faster but it’s either some clever high-level emulation hacks or those games are frame-independent. I have to assume they’re both frame-independent and designed to look like they’re in slow-motion to cover their bases of running at 15FPS or thereabouts.
This is the answer, with some kind of upper limit hardcoded, prob. Like already mentioned you can overclock the thing 1000% and it gets you limited results.
Ah, that makes sense – the game logic would run on the SNES and block between calls to rendering. I wonder if the 3D physics is calculated on the SFX chip or the SNES cpu?
In a general sense, I don’t either. It genuinely doesn’t make sense to me. It’s not something that I see or otherwise perceive, unless it gets ridiculous. In some cases, a perceptibly low framerate even can have its stylistic charm.
In the case of Star Fox, I think it may be on the verge of ridiculous. The game has always been viscerally difficult for me to look at. I hadn’t pegged it as framerate before; something about the low-poly geometry (not the low number of polygons – hell, I adore I, Robot – but the way they’re used), I’d always thought. But, no. It has to be more about how it all moves.
Yeah, if this is the same overclocking mechanism you’re discussing, this is a huge perceptual difference. The one on the right makes me uncomfortable to watch. I feel some mix of nausea and anger, watching it unfold. The one on the left seems playable. I can follow what’s happening.
It’s interesting that I never quite nailed why Star Fox has always pissed me off so much. This must be a big part of it.
My basic reaction all these years has been “This is so awful! Why does this amaze people?” Now… okay, I can see some of its appeal as a rail shooter. If I block the right side of the screen so that I don’t barf.
Everybody appreciates or dislikes framerate whether it rises to the level of consciousness or not. It’s at the core of how a game interacts with the human visual system. That same nausea/irritation you felt at Star Fox happens at 30fps too, just to a proportionally lesser degree, and correspondingly there’s an undercurrent of delight at smoothness and responsiveness when a game delivers 60.
Imagine if Genesis Sonic ran at 30fps. Everything zooming by in a slightly jittery manner and Sonic taking a little extra beat before he jumps. Totally undermines the experience, which is all about entrancingly smooth motion, right? Make that one technical change and the game may well have been a footnote.
I might even claim that a lot of the chatter about games not being as they were in the olden days (and the way that chatter has died down recently) is in part a reaction to framerate. 8-bit and 16-bit games are all solid 60fps except in the rare cases where they have slowdown, and the shift to 3d and frame independence came along with much lower framerates for a decade, before the recent recovery. Nintendo gets it, that’s why Mario 3d World runs at impeccable 60fps.
I don’t think framerate discussions the way we have them now can be applied to 2D games. With flipbook animations there’s a lot of stilted movement at much, much lower framerates than we’re used to, and at different framerates across the player, enemies, powerups, effects all over the place. I think you even have to consider how the low resolution impacts how smooth the scrolling looks, since it doesn’t have nearly as many interpolation steps as the background scrolls.
I definitely don’t get near as smooth an impression from 16-bit and earlier games as I do from modern 60fps games.
I think scrolling is a pretty good analogue of camera movement in 3d so I think that part of the framerate analogy totally holds. As for the low resolution, there’s a quantization problem which probably leads to some jitter and I wonder if some games purposely chose the player character speed to move at a multiple of 60 pixels per second to address it. Not something that I’ve ever heard of but it would make sense.
As for sprite framerate, you make a good point that it’s usually pretty low, but really high sprite framerates do exist and tend to be very praiseworthy. I’d highlight especially fighting games and Super Metroid’s Samus – it accounts for both their attractive look and also their legendary technical depth. Also, in platformers there are tricks around this – 2d Mario is basically a rectangle with tiny feet and Sonic either has blurred legs or is in a ball. Those are both fundamental design decisions, inspired by animation, tending to draw player attention away from sprite framerate and towards movement framerate which is still solid 60fps.
There’s also an interesting quirk that ultra high framerate characters in 2.5d games can sometimes look worse than a flipbook. I think it’s because simple-minded interpolation between keyframes doesn’t move like humans move and it’s an uncanny valley. It can be actually better to have low framerate and let the brain fill in the gaps.
there’s a quantization problem which probably
leads to some jitter and I wonder if some games purposely chose the
player character speed to move at a multiple of 60 pixels per second to
address it. Not something that I’ve ever heard of but it would make
sense.
Character speed at even divisors doesn’t work if you’re smart enough that have momentum and acceleration/deceleration, though. But I wouldn’t be surprised if max speed capped out in this way.
I know that I’ve been looking at this recently and noticing jitter in older games, and while I haven’t tested this theory much with engineers I think resolution is the main culprit. This would show up most at low speeds. I know that the ‘jitter’ is a subjective experience I’m having and I’m trying to figure out what causes it.
That’s a good point that minimal character movement can help the player look at the background instead of the character. When I look closely it usually appears that background scroll is smoother than character movement, too - the flight paths of parakoopas or moving platforms in Mario, for instance.
There’s also an interesting quirk about sprite framerate in that higher framerates can sometimes look worse there. I think it’s because simple-minded interpolation between keyframes doesn’t move like humans move and it’s an uncanny valley. It can be actually better to have low framerate and let the brain fill in the gaps.
I assume that’s just due to bad animation; the new Guilty Gears have figured out how to balance between keyframe holds and framerate-based interpolation to look like beautiful smooth animation. Keyframes are super-important in a way that animators trained on 3D and Flash seem to have trouble understanding.
[quote=“BustedAstromech, post:102, topic:2508, full:true”]
Character speed at even divisors doesn’t work if you’re smart enough that have momentum and acceleration/deceleration, though. But I wouldn’t be surprised if max speed capped out in this way.[/quote]
You could finesse this by having the camera not perfectly track the character during acceleration/deceleration, which is indeed common…
Ha, I can imagine pulling my hair out for several weeks trying to work out bugs in a ‘simple’ camera algorithm like that. Having spent weeks building smart cameras, this is an idea the younger me would happily take on but the older me would say, “design constraints need rethinking”
Oddly at the AAA place I’m working now we have a department called “Realization” whose entire job is “make sure the camera doesn’t look at walls, and also mini cutscenes”. And this is after the design willingly sacrifices player agency to minimize camera complexity!