FPS/UPS Problems (pre-prepare?) FIXED

[MyrcoCem]

So... the problem is rather easy to explain: neither FPS nor UPS ever reaches 60 and so the game stutters.

It is very consistent. i rarly see UPS and FPS reach 60 or the frame cycle at 16.6. pre-prepare goes between 2 and 60 at times but not really lower that that and averages around the value in the screenshot.

It happens on any new savegame and the stuttering is even there in the main menu screen and because that is almost all information i can give, im gonna list everything i tried to fix it so far:

- Tried almost all different graphic settings from high to low, fullscreen, windowed, vsync on and off
- Disabled steam overlay and closed all possible background things i could
- Monitoring next to all hardware stats: no overheating, no leakage, no high load on gpu, cpu, drives, or ram
- Different BIOS settings: high core speed, lower core speed, voltages, standard settings ofc, disabled dynamic frequenzy change by intel
- Did the same for my GPU: OC mode, slower mode and thats about all i can change
- Clean install on all of my drives from hdd to m2 ssd
- Disabling wireless mouse and keyboard because i went insane and someone on the internet said something
- Used a older game version and the 1 before latest GPU driver, all other drivers are up to date

My specs shouldnt be the problem i hope:

3080 GPU, 14600KF (so without integrated gpu that could be used), 32gb of RAM on 3200mhz via XMPII

[Rseding91]

Does this happen in 2.1?

[MyrcoCem]

just tried it out with the currenty pc configuration and yes it does still happen with the experimental branch

[Rseding91]

Does this happen with the zip version from the website? (the non-steam version)? Specifically the 2.1 version from here: https://factorio.com/get-download/2.1.1 ... n64-manual

If yes, I'd like to make a custom version of the 2.1.14 build with extra debug timings around the pre-prepare step to see if it can be pin-pointed where it's taking the time.

[MyrcoCem]

yes, still not working with the exact version your link sent me to

[Rseding91]

I sent a custom build with more debug timings in a PM.

[MyrcoCem]

i have to admit that we are now way outside of my field of knowledge but here is another screenshot. i cauth it at a "lower" pre prepare value of about 2 but the average still seems to be the same and tied to the process events value

and ignore the red line

[Rseding91]

Strange. I sent another build with more timings. But if it ends up where I think it will, I have no clue what to do about it.

[MyrcoCem]

here we go

[Rseding91]

That's what I was afraid of. The time is spent within SDL's poll-window-events. The strange part is - you see this issue on 2.0 as well as 2.1 means it's happening in SDL2 and SDL3.

I just noticed the log file says you have 3 different displays plugged in: 1 at 240hz, one at 60hz, and one at 30hz. Have you tried un-plugging all of them except the 3840x2160 60hz one and seeing if it makes any difference?

Other than that - I have no ideas what might be going wrong since it's code outside of our control (the 3rd party library we use for window creation/handling, and input handling).

Has it ever worked on this computer?

[MyrcoCem]

only using one of the monitors at 60hz doesnt help sadly.
it did actually work about half a year ago with next to no change on my pc since then.
what i am afraid of right now is that it could be related to intels f up on the 14th generation on cpus, but i would be able to confirm if that would even be a possibility

[MyrcoCem]

and no, its not working any better when i now play a version from early this year

[Rseding91]

On your Reddit post you mentioned having a high poll rate mouse (but you also said you tried disabling it), do you have a different mouse you could test with? Any basic mouse, as long as the current one is unplugged.

Just to try anything about what might be happening.

Or if you don’t, which mouse do you have? Maybe I could get one and see if it reproduces the issue for me.

[MyrcoCem]

ive gotten somewhere.
i tried the mouse again since it has a 8000hz rate and my older mouse wired and it worked fine then.
BUT then i used my new mouse again and it still worked and now i figured out, that just the bluetooth switch between on and off is the one and only reason for the problem.

it still is kinda strange and i would like to know the exact reason because all of my stuff is connected via their own adapters and nothing is actually connected to my pc via bluetooth

[MyrcoCem]

but i guess that my problem can be considered fixed and i wanna thank you for your help!
i asked chatGPT a lot too up to the point where it said that my only hope is actually asking Rseding91

[MyrcoCem]

okay now my last to actions were:

-cmd command "net stop bthserv"

-Disable the "Mediatek BT Adapter" and enable it again

the problem was fixed after the cmd command and i am not able to reproduce it anymore after running it again BUT i switched the driver on and off before that so both actions could in theory have led to the now permanent solution.

[Rseding91]

That's really weird. I wonder if the mouse was sending constant connect/disconnect messages which wound up within SDLs internal logic (handled when pump-events would get called maybe?).

[MyrcoCem]

i think we cant even say it was the mouse because i have way too many BT things, 2 Headsets, headphones, JBl Soundsystem, Gamepads, Keyboard and Mouse.
Non are connected usually, but ive heard about BT 5.4 features that make them auto connect at any time as soon as anything is "found"
But to my knowledge my headset would be the only thing capable of BT 5.4 and since it is "paired" with my pc it might be a constant loop of looking for the headset?

but even then, it is still not recreatable now so i guess it might have been some kind of error with the MediaTek driver that "fixed" itself after deactivating it