Hard Light Productions Forums
General FreeSpace => FreeSpace & FreeSpace Open Support => Topic started by: Meatball on January 18, 2016, 09:41:41 am
-
It seems "limit frames-per-second is set at 120FPS, I don't like Vsync because it causes a huge input lag, I rather just use limit FPS but changing it in my AMD panel doesn't work, since the launcher has one built it that should work to but can I change it somehow? Seems weird to include a FPS limit but no way of changing the value.
-
First, Vsync should not cause huge input lag. What kind of fps limit do you want? Less or more than 120?
-
The engine is hard capped to 120 fps. There is a commandline flag to remove that limit, but it's for developer use only; we cannot guarantee that physics and gameplay logic actually work correctly when it is set.
-
I want to cap it less than 120fps, my monitor is a 60hz so I only need 60fps.
And what you mean Vsync should not cause a huge input lag? You've got to be joking with that statement... It CAUSE input lag, it's why people hate it and why g-sync and freesync exists, sadly I don't have a freesync monitor.
-
EVGA Precision X allows you to set a framerate cap, and I think MSI Afterburner and other overclocking utilities do this as well.
-
I want to cap it less than 120fps, my monitor is a 60hz so I only need 60fps.
Such a flag does not exist.
-
FSO limits itself to 60 fps by default, as long as you don't select "Don't limit frames-per-second" in the launcher.
Ignore me, I haven't had enough coffee yet this morning...
-
I want to cap it less than 120fps, my monitor is a 60hz so I only need 60fps.
And what you mean Vsync should not cause a huge input lag? You've got to be joking with that statement... It CAUSE input lag, it's why people hate it and why g-sync and freesync exists, sadly I don't have a freesync monitor.
It shouldn't cause input lay any more than your monitor's refresh rate already does. Make sure you don't have triple-buffering or similar turned on in your driver's control panel.
-
The engine is hard capped to 120 fps. There is a commandline flag to remove that limit, but it's for developer use only; we cannot guarantee that physics and gameplay logic actually work correctly when it is set.
My 144 Hz display weeps. :(
(i kid)
-
Here's how I have managed to limit Freespace Open to 30 FPS on Windows 7.
Open regedit and go to HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Volition\FreeSpace2
There should be a DWORD (32-bit) value called MaxFPS. If not, you have to create it.
Then set the value to 30 or whatever you want (tip: when setting the value make sure that the base is decimal unless you're a seasoned registry hacker and think in hex)
-
I hope you realize that you've now introduced a bunch of that input lag the original poster wanted to avoid.
-
Question:
Why is input latency tied to display frequency? :confused: What was :v: thinking? (honest question)
I would think they'd be kept separate. That sounds like a mess.
Although I think I remember hearing that some HUD elements (missile lock-on) were tied to display, and that kind of almost makes sense. But why input?
-
...Because multi-threading did not exist at the time. How exactly do you avoid tying input latency to framerate if you only have one thread?
-
...Because multi-threading did not exist at the time. How exactly do you avoid tying input latency to framerate if you only have one thread?
Well, you could always do a frame early if input arrives between frames (I don't know how high the base framerate would need to be for that to be imperceptible). Or, I guess you could take the input as it comes in, and when you actually handle the input next turn, take the delay into account (for example when determining when the ship started to move, when a weapon was fired, etc), in which case there'd only be visual latency. Of course that still assumes that you don't need to actively poll for input, and... I guess that's possible without multithreading? I don't know much about low-level IO, really.
Obviously not saying that's a reasonable requirement for a game or anything.
-
I think it's possible for input to be received as interrupts, at least that's what I remember from doing some embedded systems work at uni many years ago. I'm pretty sure the old-school keyboard handling was done via hardware interrupts. Not sure how that ends up being presented to the layer that FSO works at, i.e. through the OS and output from SDL. Anyway, if it was presented as an interrupt from SDL then perhaps an interrupt handler could be setup when FSO sleeps to implement the framerate limit. Said interrupt handler would probably just record the input, which is then processed when the next frame is processed, maybe with some sort of adjustment for the actual time that the input was received.
Anyway, leaving theory aside, (and this is a genuine question) what are the observable symptoms of input latency? I mean, at 60 fps I'm pretty sure I can't tell the difference if my input (keypresses, moving the joystick, etc) are delayed by up to 16.67 msecs. Or am I missing something?
-
Anyway, leaving theory aside, (and this is a genuine question) what are the observable symptoms of input latency? I mean, at 60 fps I'm pretty sure I can't tell the difference if my input (keypresses, moving the joystick, etc) are delayed by up to 16.67 msecs. Or am I missing something?
By input latency I think most people mean the time between an input (pressing a button, moving the mouse) and stuff happening on the screen (weapon firing). But what if you have a slow monitor that spends 32ms processing the image before displaying it? Then even if the time that it takes for an input to reach the game's input handling code was 0, you would still have 32ms worth of "input lag". In that case it might be better described as display lag because that's where the latency is. But this is arguing semantics.
Sensitivity to input lag varies among people. For me the most obvious sign is sluggish or delayed response to mouse movement although this is harder to notice in FS2 than in First Person Shooters for example because the ships have a limited turn speed (which also varies on a ship by ship basis).