[0.13.*] [Twinsen] 30 Hz graphics mode limits UPS to 30

[svercer]

For various reasons, I play Factorio in a 30 Hz graphics mode. Yes, on purpose.

However, the game is nearly unplayable for reasons which should have nothing to do with graphics! Specifically, the game usually runs at half speed. There seems to be some kind of UPS-limiting effect which tries to cap UPS at FPS. I realize this is probably useful when FPS should be at 60 but isn't because the system can't keep up, but I have a graphics card which can and does eat Factorio for breakfast. So I shouldn't have my UPS capped at 30 . Perhaps this can be a toggled option, or the game can detect when the refresh rate is 30 Hz (btw, I'm in the vsync-not-available mode you recently enabled, so I can't just disable that) and rate limit UPS to 2*FPS instead.

Just to make sure my explanation is complete, sometimes it seems UPS jumps up for a while and gets un-limited at 60, perhaps if the game temporarily thinks that FPS is over 30; however, it quickly returns back down to 30.

Unfortunately this is making the game effectively unplayable. I don't live my life at half-speed, even if you think that 30Hz graphics modes are just as strange

[Zeblote]

If your graphics card "eats factorio for breakfast", then you should have no problem running it at 60 fps.

[Twinsen]

That is odd.
I could not reproduce it. Sometimes you need to restart the game twice for vsync to turn off after updating. Can you try again see if you still have the problem?

Can you post a log so I can see your system configuration and settings?

Also can you post a screenshot with your timings?
Press F4, select show_time_used_percent and make a screenshot.

Thanks

[BlakeMW]

If your graphics card "eats factorio for breakfast", then you should have no problem running it at 60 fps.

Could be displaying factorio on a device which only supports 30Hz, such as some TV models.

[Twinsen]

I think I figured out what is happening.
It can only happen when vsync is on.
And even so i did some changes in Version: 0.13.14 that will probably fix it even for vsync. Let me know how it goes.

[svercer]

The log indicates that vsync is disabled.

Getting the repro was a little difficult because pressing F4 seemed to temporarily suppress the effect (if you can believe it), but I've attached a screenshot with the requested info and the log from the same run.

[Twinsen]

Why is your game running in OpenGL? Did you have an AMD card previously and started the game for the first time on AMD card?
First try setting it force-opengl=false in config.ini

Also something seems to be forcing Vsync on. Try looking in the Nvidia Control Panel and see if you set Vsync on there and set it to application controlled.

[svercer]

Hmm... I did just switch from an AMD card, although the bug repro'd on the old card as well as the new. I haven't fiddled with vsync settings, but it seems this would be a bug even if it only happens when vsync is on =)

I'll try the vsync and opengl settings tomorrow and report back.

[svercer]

Changing the opengl setting releases the game to run at 60 FPS, and the UPS along with it (after several minutes of testing). Thanks!

I don't see any evidence that the game should have been running in vsync even under opengl though; config.ini and the log both had 'vsync=false' and the nvidia control panel had 'use application setting'. Also, previously, the FPS occasionally went up to 60 temporarily, so it doesn't seem to have been vsync, at least not exactly (although FPS=graphics mode refresh rate is certainly not a coincidence).

Completely aside from the weird graphics behavior, is the general behavior of UPS being limited to FPS considered by-design, though? Couldn't the game be allowed to run at 60 UPS whenever CPU contention isn't an issue?

[kinnom]

Changing the opengl setting releases the game to run at 60 FPS, and the UPS along with it (after several minutes of testing). Thanks!

I don't see any evidence that the game should have been running in vsync even under opengl though; config.ini and the log both had 'vsync=false' and the nvidia control panel had 'use application setting'. Also, previously, the FPS occasionally went up to 60 temporarily, so it doesn't seem to have been vsync, at least not exactly (although FPS=graphics mode refresh rate is certainly not a coincidence).

Completely aside from the weird graphics behavior, is the general behavior of UPS being limited to FPS considered by-design, though? Couldn't the game be allowed to run at 60 UPS whenever CPU contention isn't an issue?

fps is limited by ups, not the other way around

[Twinsen]

Completely aside from the weird graphics behavior, is the general behavior of UPS being limited to FPS considered by-design, though? Couldn't the game be allowed to run at 60 UPS whenever CPU contention isn't an issue?

fps is limited by ups, not the other way around

Actually it's more complicated.
Here is a snippet of code and a technical explanation: (counter is the number of game updates per frame)

Code: Select all

      //UPS dropping logic
      //since prepare does not really take long, tests show the best thing to do is to have FPS=UPS.
      //we just do extra updates if the renderer is still rendering: slow, or is spiking, or we have high game speed
      if (counter > 1 && rendererIsWaitingForUpdate || counter > 5)
        continue;

This means that if the game has finished redering and is waiting for update, the update thread will start dropping UPS so we can draw the next frame ASAP(rendererIsWaitingForUpdate is false when we are waiting for vsync, so that's ok). I prefer to drop UPS quite violently because on big maps if i prioritize UPS it will drop FPS to the ground with very little UPS gain.

It happens sometimes that when you use vsync at 30hz the threads get synced in such way that it starts dropping every second game update(i never managed to reproduce it but based on some simulations on paper and the fact that it somehow happened to you means it can happen).

If you want to help investigate this further, I did some changes in Version: 0.13.14 that will probably fix it even for vsync. Let me know if you can make it happen again.

[svercer]

To force vsync, should I switch back to opengl? Or will setting vsync=true in config.ini work even without the visible vsync option?

> It happens sometimes that when you use vsync at 30hz the threads get synced in such way that it starts dropping every second game update

So, no joke, as a dev myself (not game dev though) I kind of suspected that it might be something kind of like that since any deviation from exactly 30 FPS caused UPS to quickly rise back to 60, but it was so far-fetched that I didn't say it and just stuck to the facts. =) Presumably one could test this theory by seeing if it repros at 15Hz, but I'll let someone else look at the screen for that one...

[Twinsen]

To force vsync, should I switch back to opengl? Or will setting vsync=true in config.ini work even without the visible vsync option?

vsync=true on direct3d will turn vsync on for the first run(it will turn off at the second run)
i would try with both
force-opengl=false and force-opengl=true