I’ve heard stories over the years of some games not being able to handle a high FFB update rate and the game’s framerate therefore plummets if you don’t reduce the FFB update rate in the game’s FFB settings (or FFB text file or whatever). I’m having this problem in a game that I don’t believe offers the option to do that. It’s GTR 1 (GTR: FIA GT Racing Game). With FFB disabled (not the steering, just the FFB), the framerate is in the 700 - 1000 fps range but with FFB enabled it’s quite inconsistently in the 130 - 170 fps range. The Simucube 2 FFB destroy’s the game’s performance…or rather, I’m guessing, the game cannot handle the SC2’s default FFB update rate. I need the framerate to be either at a constant 240 or constant 360 fps for some specific reasons of mine.
Is there any way we can lower the FFB update rate or adjust some other sort of option within the SC2 so I can get this game to work “properly” with the SC2?
Its the game’s issue, if its controller interface is being built in such a way that processing is blocked until the update is fully sent to the device.
Ah that really sucks. It’s also happening in GT Legends as well which I play a lot. I’m guessing that means I’ll also have the issue in Race 07, GTR 2, and RFactor 1 if they don’t have the FFB reduction option that Automobilista 1 has
It’s all good. I found some workarounds that’ll get me the framerates I’m looking for.
Short version:
Setting the in-game FFB to less than “full” gives much less of a framerate hit
Long version:
I found out that setting the in-game FFB to less than “full” gives less of a framerate drop because the FFB isn’t constantly vibrating from the simulated engine RPM vibration.
Also, the other games (eg. GTR2) are more optimized and have higher framerates so even when the framerate drops massively from the FFB, there’s still enough headroom to give me plenty of fps.
GT Legends is similar but slightly lower framerates
GTR1 is the worst, I guess because it’s the least optimized. FFB at full is around 150 - 250 fps. Setting it to high, med, and low seems to give me a high enough framerate to almost always be above my target of 240 fps.
So, for GTR1 (and maybe GTL), I’ll just have to sacrifice the engine RPM vibrations I love (can possibly keep it on with the other games) and then the framerate should be OK
P.S. I think the reason why GTR1 has such lower framerates than the others is because it doesn’t seem to take advantage of more than 1 CPU thread. With GTL, GTR2, RF1, etc. there’s a large boost in framerate as soon as you set the game’s CPU affinity to 2 threads (or more but more than 2 doesn’t seem to make a difference). Doing the same with GTR1 makes absolutely no difference. Therefore the other games have much more framerate-headroom.
I was thinking of getting a 360 Hz monitor but I changed my mind because they’re too small (25" being the largest, I think). Therefore I’m sticking with my 240 Hz Samsung. Normally I don’t use Vsync and I also use G-Sync (unless using Nvidia 3D Vision on my previous monitors, you cannot use G-Sync & 3D at the same time) so I don’t care much about fluctuating framerates, however, I’m trying to do some tests / experiments with the following 3 scenarios:
a) constant 240 fps, 240 Hz, VSync
a) constant 240 fps, 240 Hz, Vsync off
b) fps as high as possible without going under 240 fps, 240 Hz, VSync off
c) framerate is as high as possible without ever going below 240 fps
I need to do more tests but I think the framerate still seemed a little stuttery when the fps was in the 250 - 350 fps range when the FFB was set to “full”. I wonder if it’s causing micro-stutters which the in-game framerate counter is not catching. I’ll have to do more tests to confirm if this is true. I’ll use MSI Afterburner to record framerate 1% and 0.1% lows with a fast update rate.
Even with G-Sync monitor you need to cap framerate by either forcing VSync in driver settings (disabled in game) or setting max frame rate at around 3fps below refresh rate, otherwise besides creating visual jitter you are just transforming electricity into heat.
Sorry to disturb! FFB has a refresh rate, Fe Iracing 60 Hertz, ACC maximum 333 Hertz. AC offers the possibility to lower the FFB refresh rate to half.
All of a sudden you write about the refresh rate of monitors and I wonder where the connection between them is.
Or did I missed a change in subject?
No. The subject is that turning FFB on in ISI engined games when using most, if not all direct drive wheels, causes a massive drop in the game’s framerate. The games apparently cannot handle something related to the way direct drive wheels. The option around this is to limit the game’s FFB update rate like Reiza added to AMS1 but most other ISI engined games don’t have this setting.
Yes I know how about how to properly setup GSync (enable GSync, enable VSync from Nvidia Control Panel, set game’s framerate limiter to around 5 or 6 less than the max refresh rate, if game doesn’t have a frame-limiter, use frame-limiter from RTSS).
But I’m not trying to get GSync working, I’m trying to get my game to either remain at a constant 240 fps with no fluctuations or have unlimited framerates without ever going under 240 fps. It seems the FFB settings in these games not only massively lower the framerate but also cause framerate drops and microstutters. FFB at Low/medium/high is better than full though.
If renderer and physics engine run on the same thread or use synchronization, higher physics/ffb update rate will affect fps. Wondering what tick rate they use and why it takes that long for SC2 to process received signal and return, usually even 400hz in ACC is not a problem, but they run physics on own thread.
Have you tried different USB port, what are your settings, may be some filters take long to process?
But the game is so ancient, they had only 60hz monitors at that time, so could be that everything optimized for that rate.
P.S. BTW, NVidia has frame limiter in driver now, no need to use RTSS.
Na, nothing to do with USB ports, I believe it’s something to do with the game and drivers. I believe Reiza said it only affects DD wheel users. Not 100% sure to be honest. Slowing down the game’s FFB update rate in AMS1 avoids the problem.
The Nvidia frame limiter from the driver induces more input lag than RTSS.
Use the game’s built in frame limiter for the least (or no) added input lag. If the game doesn’t have it, the next best option is RTSS.
Having said that, input lag is incredibly minimal at 120+ fps even if using the Nvidia frame limiter or RTSS instead of in-game. Heck, at 240 fps / Hz, I can even run full-on VSync with no perceivable input lag and drive fast, difficult cars just fine.
Hi Mika. Are you sure it’s purely down to the game and not possibly the wheel? This is what a dev from the RF2 forums said:
Slightly off-topic but in AMS the following changes were made compared to rF1. The physics rate was doubled from 360 to 720 Hz which should in theory make them slightly (by far not twice) more accurate. On top of that the FFB was changed to no longer be directly linked to the frame rate. However, when we tried doing FFB at 720 Hz we soon discovered that a lot of wheel drivers (some DD wheels including) were way too slow when we sent those commands. Therefore we had to settle for a maximum of 360 Hz and the option to go lower than that.
They both have less than 1 frame delay, higher lag was associated with older frame limiter set via NVidia Inspector
*As of Nvidia driver version 441.87, Nvidia has made an official framerate limiting method available in the NVCP; labeled “Max Frame Rate,” it is a CPU-level FPS limiter, and as such, is comparable to the RTSS framerate limiter in both frametime performance and added delay. The “Nvidia Inspector: 2> Frame Delay” setup detailed further below is legacy, and does not apply to the “Max Frame Rate” limiter, the setup of which is also now detailed below it.
You can also use new Ultra Low Latency, it limits framerate so you don’t have to do it via separate settings.
Anyway, digressing from your original problem here.
Ultra Low Latency has been around for at least 2 or 3 years and it doesn’t limit the frame rate.
I used to set Low Latency to “Ultra” instead of “On” but I researched it a lot and it’s only beneficial during certain situations. In other situations it can actually increase input lag compared to “On”. Also, it can lower the framerate whereas “On” doesn’t seem to affect the framerate. I’ve since learned to just always stick with “On” as it’s the safest and most consistent one, input lag wise, and it also doesn’t negatively affect framerate.
Thanks for the correction. It seems I was talking about the old Nvidia framerate limiter, the more recent one seems faster and equal to RTSS. Having said that, it’s always best to use the game’s built-in framerate limiter when it comes to latency as that Blurbusters articles mentioned.
Ultra didn’t work for me either, too jittery, I believe it only works at very high frame rates, but it does apply frame limiter.
Here’s the breakdown:
60hz = 59 fps
100hz = 97 fps
120hz = 116 fps
144hz = 138 fps
180hz = 171 fps
200hz = 189 fps
240hz = 225 fps
So this is essentially NVidia “optimal” limiter for max rate per refresh rate.
It didn’t apply any framerate limiter for me. I tried with GTR2 which should work since the setting should work with any non-DX12 game. I then read somewhere else that you also need to combine it with VSync in order for the Low Latency Ultra’s auto-framerate limiter to work. I tried that but still nothing, I only got the normal framerate cap due to VSync (240 fps @ 240 Hz).
Yup, Ultra can cause jitters (along with lower general framerates and even increased latency compared to On).
I read somewhere that said Ultra is best suited when you’re around the 60 - 100 fps range and when you’re GPU limited rather than CPU limited. To me, that sounds like it’s a way for people struggling with PC performance to try and still achieve low input lag.
EDIT: I’ve done some more reading. Mabe the Ultra auto-framerate limiter only works when you also have GSync enabled? I’m currently not using it on my new monitor.
Back in the day when these old games were around, it was amazing if you got 100 FPS from them. It is likely that any unoptimized FFB code was masked by other low performance components (GPU; CPU; memory).
