Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Never sleep with common.framerate.max -2 #1102

Open
wants to merge 2 commits into
base: master
Choose a base branch
from
Open

Conversation

illwieckz
Copy link
Member

Never sleep with common.framerate.max -2.

This is useful when benchmarking for performance, to avoid benchmarking the sleep function.

unvanquished_2024-04-22_034803_000

@slipher
Copy link
Member

slipher commented Apr 26, 2024

How can a busy loop where you just poll for events a million times per second possibly be better than sleeping?

@illwieckz
Copy link
Member Author

How can a busy loop where you just poll for events a million times per second possibly be better than sleeping?

Hmm… right I should better skip the loop entirely. 🤣️

Now done.

@slipher
Copy link
Member

slipher commented Apr 26, 2024

How is the new version supposed to be different than putting minMsec = 0?

@illwieckz
Copy link
Member Author

I was just going to say the same. 🤣️

I wrote that yesterday late in the night, it looks like my brain wasn't fully functionnal. 🤡️

@illwieckz illwieckz force-pushed the illwieckz/maxfps branch 2 times, most recently from 0d1177e to 5450acd Compare April 27, 2024 08:21
@slipher
Copy link
Member

slipher commented Apr 28, 2024

I don't like how there is only 1 value that enables the reasonable version of unlocked FPS and 2147483647 values that enable the version that clearly violates the system's design assumptions. It should be harder to do it by accident.

BTW I'd be skeptical of any "performance measurements" made with 0 ms frame lengths. Some code could be skipped if it assumes something is already up to date since the time hasn't changed...

@illwieckz
Copy link
Member Author

It should be harder to do it by accident.

Why not make sure this one never does anything unless cheat is enabled?

@illwieckz
Copy link
Member Author

illwieckz commented Apr 28, 2024

BTW I'd be skeptical of any "performance measurements" made with 0 ms frame lengths.

Well… we may benchmark the performance of the game, or the performance of the environment.

This also helps me notice how hardware pieces, hardware performance profiles, or drivers, or compiler level of optimizations, etc. have impact on how fast the computer go to compute the game (even if doing some part uselessy and redundantly). When reaching some level of fastness of the hardware and software environment, once I reach the 1000fps cap I can't know if this or that option makes the engine run faster.

I started thinking seriously about implementing this option in our code and just not rely on throwaway patches (like I did for years) when I delivered a computer some weeks ago and out of curiosity I ran the game, set -1 to common.framerate.max and with default configuration (so medium profile) I reached the 1000fps cap on 4K… I was like : « It looks like I will not be able to compare with newer hardware anymore »…

@slipher
Copy link
Member

slipher commented Apr 29, 2024

It should be harder to do it by accident.

Why not make sure this one never does anything unless cheat is enabled?

How do you mean? Max FPS can't be a cheat cvar.

@slipher
Copy link
Member

slipher commented Apr 29, 2024

I guess having another CHEAT cvar to disable all FPS limitations would work.

@illwieckz
Copy link
Member Author

illwieckz commented May 1, 2024

I added a commit that implements my idea of a cheat value.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants