Hacker News Reader

Comment by smokel | Hacker News Reader

I like this perspective.

In the demoscene days, we used to obsess over 60 Hz guaranteed framerates. Code was constantly being profiled using raster bars. Our effects might have been crappy, but all was buttery smooth.

Then someone decided it would be a good idea to create a common user interface that would work on many different framerates and resolutions, and all was lost. Or people would try for complex 3D graphics and sacrifice smoothness.

Some people tried to convince us that humans have a 150ms built-in visual processing delay, and all would be fine. This is not the case, and we are still stuck with mediocre animations. The content has improved a lot though :)

View on HN

> Code was constantly being profiled using raster bars.

For those wondering: we'd change the background color from, say, black to blue for the "physics" part, to green for the "drawing" part, to purple for the "audio rendering" part... All in the same frame, while the frame was being drawn.

So you'd see on the border of your screen (usually outside of the drawing area you'd have access to) approximately which percentage of each frame was eaten by "physics", graphics, audio etc. and how close you were to missing a frame.

And it was quite "hectic" typically these color "raster" bars would jump around quite some from one frame to another.

But yeah there was indeed something very special about having a pixel-perfect scrolling for a 2D game running precisely at the refresh rate (50 Hz or 60 Hz back then). And it wasn't just scrolling: games running on fixed hardware often had characters movement set specifically in "pixels per frame". It felt so smooth.

Something has definitely been lost when the shift to 3D games happened: even playing, say, Counter-Strike at 99 fps (was it even doing that? I don't remember) wasn't the same.

People don't understand that their 144 Hz monitor running a 3D game still doesn't convey that smoothness that my vintage arcade cab does when running an old 2D game with pixel-perfect scrolling while never skipping a frame.

A lot of that smoothness was the lack of sample-and-hold blur on CRTs. Gaming LCDs now have modes that strobe the backlight to simulate this effect. Additionally, the importance of sample-and-hold blur declines as the frame rate increases. A 360Hz LCD displaying 360fps motion can look reasonably sharp even without strobing.

Blur Busters has detailed explanations, e.g.:

https://blurbusters.com/blur-busters-law-amazing-journey-to-...

> People don't understand that their 144 Hz monitor running a 3D game still doesn't convey that smoothness that my vintage arcade cab does when running an old 2D game with pixel-perfect scrolling while never skipping a frame.

The actual motion-to-photon delay (measurable with a high-speed camera) in a well optimized competitive FPS is somewhere around 20ish ms or less these days, so it's on par with it in regards to the input lag, and overall it's far smoother because of the higher frame rate, better displays, and way more thought put into tiny nuances competitive players complain about. A proper setup feels extremely smooth, responsive, and immediate.

> The actual motion-to-photon delay (measurable with a high-speed camera) in a well optimized competitive FPS is somewhere around 20ish ms or less these days, so it's on par with it in regards to the input lag

I.e. more than two frames between input and output. That is quite a lot, and AFAIK a large regression.

It’s the exact same amount of time - why would the frame count matter?

1 - 2 frames is a lot of time and latency this big is perceptible in many tasks, fast-paced videogames being just one of them.

It was in reference to high refresh rate screens - 1-2 frames is not much at 144+ Hz.

There’s a big difference in latency on a 10k$ machine and my “non-budget but on a budget” 3k$ machine. You can’t realistically expect people to pay pro-gaming prices.

There are great examples even outside of the gaming world. I wish there were videos around on how fluid were Scala Multimedia presentations on a bare Amiga 500 in the 90s. An 8MHz clocked machine (7.16 MHz here in the EU for PAL synchronization) that in that field would outperform gear costing at least an order of magnitude more. It was hugely successful back in the day in many local TV stations.

Not just that. You hit a key and the game could react in literally the next frame. There was an immediacy you don't get now.

Ever since the xbox360 era of games the game world has been updating in parallel with the rendering of the prior frame at the very least, that pipeline is quite commonly 3 frames long now. That is a lot of latency to get some macro concurrency.

Metal Slug on the PS4 was jarringly unresponsive compared to my expectations, though I'm not sure I've played it on an arcade machine in 20 years so maybe it's my memory or physiology at least partly to blame.

If I recall correctly, the PS4 controller has a disgusting amount of input delay. I noticed this most strongly on the FFX Remaster where you need to hit timer events before the arrow enters the shaded box.

It doubly screws you in the chocobo racing section because the controls assume no delay, meaning you can’t respond to hazards in time and constantly overcorrect movement.

Some multiplayer network games memoise the game state. When an input event arrives from a remote player it is applied to the game state that existed at the time of the event. Then the state is fast-forwarded to the present time and the game continues. Ideally you shouldn't notice this happening.

The obvious fix for laggy input is to apply the same processing to local input, but I've not heard of anyone doing this.

(I think this technique is known as netcode.)

Early versions of Android had this feature (Android 3-ish, 4-ish?)

Touch events were run through a filter to predict where the touch position would be some number of frames in the future -- presumably to compensate for page-flipping delays. Not sure it made much difference, mostly because smooth animations on old versions of Android were extremely difficult because of inadequate CPUs/GPUs.

The classes used to do predictive tracking don't seem to be used anymore in current best practice/current API sets.

I think native PS4 games did something like this to work around it. Final Fantasy X was a PS2 game ported to PS4, so I doubt they re-wrote their controller code to that extent, especially given how noticeable it was.

Strangely enough, I had the same experience with diablo 4 until I turned down some of the graphics settings. I'm not sure if it was some DLSS / frame generation thing or what, but the game felt sloppy to me. Especially in comparison to something like diablo 2 which feels razor sharp.

I wish modern game developers & graphics pipelines would spend more effort optimizing input latency. I'll stop noticing the graphics 2 minutes into playing the game. But if the input is laggy, I'll feel that the entire time I'm playing. And the feeling of everything being a bit laggy will linger long after I stop playing.

I’m totally with you. It has a generic art style, and with optimized settings, looks like goop. There’s never going to be a game that feels like how it feels teleporting through a whole act in D2. Everything loads instantly. And it keeps doing that even at high cast speeds.

> But if the input is laggy, I'll feel that the entire time I'm playing.

You've already bought the game at this point so most devs don't care.

They care a lot if they get bad reviews online. That translates directly into sales.

An insane amount of money and effort that goes into most AAA games. It seems like a stretch to accuse the industry of not caring about the quality of the games they make.

Well, yes, I explained myself horribly.

What I meant is that most people are way more sensitive to graphics than anything else. A lot of people will never play a game that is ugly but don't seem to mind laggy inputs.

There are a lot of games that, even without "real" input lag, have tons of animation dampening/inertia to the point that it makes them IMHO unresponsive, just to improve the "cinematic feel" and avoid characters instantly changing direction.

If you prefer responsiveness to having the player character spin be perfectly smooth, well, sucks to be you, because prettier games sell better.

Obviously this doesn't apply to fighting games or competitive shooters or anything like that where responsiveness is the point of the game.

> What I meant is that most people are way more sensitive to graphics than anything else. A lot of people will never play a game that is ugly but don't seem to mind laggy inputs.

Maybe. I wouldn’t be surprised most people are much more sensitive to input latency than we think. But when there’s input latency, they have no idea that that’s the problem so instead they attribute the slushy feel of the game on something else. Or just don’t enjoy the game as much without knowing why. Game developers talk a lot about “game feel” and this is the kind of thing they’re talking about.

Yeah, there's a lot of games where I don't care about lag. Donut County is a little drifty? Great, that fits the aesthetic. But some games really need to be tight.

The Metal Slug games are already at a disadvantage because they run at 30fps, unusually low for arcade games. All else being equal, lower frame rate gives higher input latency.

FWIW I took this impetus to check my TV settings, and poking around improved things. It's still not the arcade but it's better.

I think the difference is that 3D is inherently continuous (because it is simulating a 3d space) and requires another layer of abstraction on top of the controllers to work intuitively. 2D on the other hand is pixel based which is usually discrete (the world units are uniform in pixels), and also the character movement is 1:1 mapping on the controller. These two factors make 2D feel more responsive, and I'm guessing that once VR gets better it will close the abstraction gap and make the controller mapping (body/hand movement) 1:1.

Using pixel coordinates for 2D space is like sizing web elements in pixels - it's just plain wrong and will look vanishingly small on future higher-resolution monitors.

It's just plain wrong from today's perspective. Back when pixel sizes were predictable, one could exploit this at all levels.

Pixel artists would (and still continue to) consider every individual pixel, performing anti-aliasing by hand. Animations would be timed in relative to the (fixed) framerate, leading to optimal smoothness.

Reaching this level of fluidity is only recently possible again, at the cost of vastly higher hardware requirements. Most people haven't even experienced this, because of the suboptimal period we have been in for some time now.

You win some, you lose some.

I was speaking a little more abstractly. For 2D, even if you use an intermediate coordinate system, the transformation between the two can be mapped 1:1 with the controller (in theory, not that you need to), because controllers are 2D in design (specifically the directional arrows and joysticks, which have 2D coordinates). I think allows for more natural responsiveness. If controllers had 3D joysticks, or eventually when VR gets better at hand motion, then 3D responsiveness will improve.

Wasn't it common practice on older systems like, say, the SNES Sega Genesis? A design responsive to multiple resolutions wasn't really a thing back then as far as I know.

Imagine the richness of retro gaming today if they had had the foresight to design for resolution independence. Now only a vanishingly tiny subset of the best of the best games have the financial incentive or dedicated modding community to release in high definition.

At 14 I discovered that tiny response times are essential by observing terminal echos from a TCP client and server connection. I could clearly see a 50ms difference, down to about 15ms if I recall correctly. It wasn't until years later that I discvered high response+refresh monitors and from then on anything under 120FPS is just laggy if it's a game.

Reply on news.ycombinator.com