pouët.net

Hi there,

I was wondering if it would make sense to apply fixed FPS limits to demos (or if any demo actually does this).
I just rewatched Agenda Circling Forth by FLT and while it IS a great demo still and it finally runs flawlessly on my machine (which is now at a high-mid-end 2022 standard) I wondered if some scenes render _too_ fast?
Using the nvidia-fps-counter it shows 230 fps in some scenes and 70fps in other scenes.
While I know it is cool to "let the beast run" and usually high-end-pc demos target bigger hardware than the average watcher can supply at the time of release I cant help but to ask myself if this doesnt somehow destroy the visual and artistic looks the designers of the demo have intended in the first place? Is a Demo only done for "todays state of the art" hardware and not for future generations?
(Also my 4070 Ti gets hot and loud(erish) while watching it, but eh).

So I keep asking myself if implementing a target-framerate for the demo or even each individual scene would be a thing? Or does this actually create problems im not aware of?

Turn on vsync?

As long as the demo calculates proper delta time between frames it's not a problem.

turning on vsync and a hard cap on driver level does solve this "problem" on my side but it still doesnt tell me what the creator of the demo intended to watch it at...

generally id expect modern pc demos are intended to run at 60fps ideally and no higher, altho agenda was actually intended to be locked to 30 originally if i recall.

I actually implemented a framelimiter for this years 4k at revision to ensure a cinematic look (the exe that was shown had a bug causing flickering but that's besides the point).

Pretty much any demo that makes use of feedback effects, of which even simple motion blur is one should be concerned with limiting the fps for a consistent result.

The expectation that PC demos are intended to run at 60hz appears antiquated considering that even cheapo gaming monitors and laptops come with 120hz+ displays nowadays.

If you dont restrict the FPS the GPU is going to blow up!

I was thinking about this and not sure if doing things wrong, as I heard someone associating performance also with energy waste. Then it was mentioned that throttling your rendering in a busy loop is "inneficient", meaning it would be better to wait (maybe with vsync or would it need some separate thread?) before just rendering fully.

I mean,. when I have some software render thing on PC and it's doing way more than 60fps, but I just use a timer and not wait till next refresh or something. I have no idea, would wait for vsync or timer still be a busy wait? It's good for benchmark but for any other application? I even hear the fan on my PC making full noise, so I know it's overworking rendering at 500fps or something. But I don't know, I just hear someone say "If you do something in a busy loop it's wrong" or something, and am puzzled, afterall I am not a computer scientist, I just did demos as I knew. But if there is a right way and I am unneccesary throttling the CPU for a demo that doesn't need to go over 60fps, then is vsync enough to claim I am not busy waiting? Not sure..

well, most demos are still made for parties and parties are not using high fps beamers yet :) so i guess most people making demos are still optimising for the 60hz compo experience.

I recall Navis making a point in some Assembly seminar that sudden framerate changes can be jarring and take you out of the demo. Also that you can try to avoid it by smoothly changing the number of rendered objects for example, even they aren't visible on screen.

Yes, if you have a big raymarcher just appearing in the middle of the scene, that would be quite bad for the experience. Best to kind of fade in - consider a circular cross fade so that you know that some pixels are going to be black while others will be doing heavy stuff, and return early from the marcher. Something like -


if (clamp (length (UV.xy-dist+(time-offset)),-1.0,1.0)<0.0) return vec3 (0.0);
return (raymarch());

your effect will "fade" in within a second or something, instead of an instance.

Depends on what the meaning of fixed FPS limits is.

If a scene renders too fast, (FPS through the roof) it'll probably gonna suck 20 years from now...
So yes, please make a timer-counter or something that can keep track of the frames youre drawing. For math/computational intensive stuff you either fade while its computing, or leave out some of the extensive computation (either optimizing it, or precalcing it into a big table).

Hmm are they though? I would expect the vast majority to be ignorant about FPS as long as it's high enough on their machine (or expected to be on the overpowered compo machine), authoring their demos uncapped on variable and high refresh rate displays.

Demos broadly aren't intended to run at any specific rate, but individual productions can be. In fact I strongly feel you should pick an FPS target while your making the demo. And I don't mean just a minimum framerate, but target as in that it ideally shouldn't run faster either. Many of my prods are intended to be to run at 24 Hz, or 30 maximum, and they start to look weird when you approach 60. Most of the time—especially in intros—I don't explicitly enforce this, but just design the content around the compo context so that it runs at the desired framerate on the PC used.

Epoch (For The Masses) does have an explicit limiter to 30 Hz though, but last I checked I think it wasn't working properly for some reason. And yeah, any sort of nonlinear stateful effects (like the particle system in the aforementioned example) especially should be designed for specific update rates, unless whatever solver your using remains appropriately stable. That's even if you scale things by delta time.

Going beyond 60 imo starts to put you firmly into the realm of diminishing returns, although specific kinds of content can of course still benefit from such higher rates.

In the late 90's we tackled this issue by simply not optimizing our code.

This is reminding me of running demos that were written for a DOS 486 (probably with "Turbo depressed) on a DOS Pentium. Realistically I'd imagine some demos would spin out of control on hardware that's 10+ years more recent simply because some render times were limited by the hardware and not a counter, and nobody caught it (or cared) because deadlines.