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

Is there really no way to limit fps? #749

Open
aaratha opened this issue Jun 24, 2024 · 5 comments
Open

Is there really no way to limit fps? #749

aaratha opened this issue Jun 24, 2024 · 5 comments

Comments

@aaratha
Copy link

aaratha commented Jun 24, 2024

I am compiling my game to WASM and hosting it on itch.io, and I've noticed that the speed at which it runs is completely different depending on the refresh rate of the device I'm using. It runs fine on my computer, but runs way too fast on my Android with 90hz. Is there any sort of automatic way to lock the physics process to 60hz?

@AdamSlayer
Copy link
Contributor

AdamSlayer commented Jun 27, 2024

I don't think there is any automatic way, but it should not be too hard to use get_time() and wait until the next physics tick for the appropriate time using sleep(). I use a tick debt system, so when one tick takes a little longer than it should, the other one will not sleep for as long to compensate this.

@aaratha
Copy link
Author

aaratha commented Jun 28, 2024

Yeah, this seems to be the only way... I don't think sleep() works in WASM, though.

@AdamSlayer
Copy link
Contributor

A better way to do this (if fps is too high) is to keep rendering without updating physics, so for example you render 2 frames for 1 physics update. And if fps is too low, you do the opposite - update physics multiple times every frame.

@aaratha
Copy link
Author

aaratha commented Jun 28, 2024

Oh, so I could have a couple fps ranges (58-62, 68-72, 88-92), for instance, and modify the processes based on checks against those? That sounds like it could work.

@Ztry8
Copy link

Ztry8 commented Sep 21, 2024

You can't use std::thread::sleep!

Puts the current thread to sleep for at least the specified amount of time.

The thread may sleep longer than the duration specified due to scheduling specifics or platform-dependent functionality. It will never sleep less.

This function is blocking, and should not be used in async functions.

You can only set the swap interval.

not-fl3 commented on Jul 28
Just for someone who will come here from google :)

Macroquad do not limit fps, it is not doing anything with fps at all. Some platforms (browsers in particular) gives us no control over fps, some - give siomecontrol over vsync, but it can be overriten by the user in the driver settings (windows), with env variable(linux) and, I guess, performance/battery saving settings (android/ios).

swap_interval : Some(0) in Conf might be a solution, but it does not guarantee a disbled vsync, it really is super platform specific and there are varios way user can enable/disable vsync.
https://docs.rs/miniquad/latest/miniquad/conf/struct.Platform.html#structfield.swap_interval

The swap interval is platform specific and requires additional OpenGL extensions to support it.
According to the OpenGL documentation, swap_interval values mean:
-1: adaptive vsync,
0: no vsync,
1: vsync.

Many questions about this have been asked before, and my answer is the same for all of them.
Here is a list of the same questions:
#755
#380
#360
#170
#52

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

No branches or pull requests

3 participants