search

SethRobinson / proton

Proton SDK: Seth's GL/GLES messy multi-platform C++ game SDK. Can output to Windows, OS X, iOS, Android, Linux (Raspbian too), HTML5, Flash
Other
84 stars 16 forks source link

OPTIMIZATION: Reduce CPU usage by ~6% #19

Closed playingoDEERUX closed 1 year ago

playingoDEERUX commented 2 years ago

This fixes that the CPU is put on full constraint, even with an FPS cap active. It happens because the accurate "sleeping" happens with the Sleep(0) (this doesn't actually sleep, at best it tells the cpu scheduler on the OS to reschedule execution for other threads, kind of like yielding) in the fpsTimer while loop.

But there should also be an inaccurate proper sleep to avoid maxing out one core, 1ms is good.

The new FPS cap remains very accurate at a stable 60 FPS (tested). Capping beyond 1000 FPS may cause inaccuracies but eh, who would ever do that?

SethRobinson commented 1 year ago

Sorry, just noticed this. I know sleep(0) doesn't make sense but I have a test machine where doing this fixed a weird "milky" effect on the mouse, I have no idea why but I'm afraid to remove it. It's possible this is no longer an issue but I'd like to do some testing first. This issue might only exist on extremely fast machines with high end gpus.

SethRobinson commented 1 year ago

Thanks, will add this. Will also change the sleep(0) to sleep(1)

iProgramMC commented 10 months ago

this fixed a weird "milky" effect on the mouse

If Sleep(0) wasn't added, the game would use 100% of the CPU time it gets from the system. Sleep(0) doesn't actually do a sleep, but it yields its time slice for other processes. This allows e.g. the mouse driver to poll the mouse, in cases such as USB mice where there needs to be a thread that constantly poll the mouse. Having a process that hogs all the CPU time it can get will inevitably cause other threads to lose CPU time to a process that's just sitting around, waiting.

In playingoDEERUX's commit, adding just 1ms sleep did have an effect.