Possibility to set FPS

[ttulka]

It would be handy to set FPS from the game code. This would save developers some boilerplate code.

export function update(): void {
    // next update will be called in 0.5 sec
    w4.setFPS(30);

    // ...

What do you think?

[aduros]

What situations would changing the FPS be useful?

[ttulka]

Each game has its own update speed, usually depending on the level. For instance, your Tetris speeds up the falling of the bricks. Instead of counting the delay in the game code, one could simply change the FPS like this:

w4.setFPS(GAME_FPS[currentLevel]);

This is probably not the only one approach, but similar mechanism would be handy for game developers.

[aduros]

Hmm, there could maybe be a memory register for it, although for simplicity I feel like it should remain a constant 60 FPS and leave it up to the game to handle. It doesn't seem like that much boilerplate.

Note that tone() durations are measured in "frames" (1/60th of a second), so redefining the length of a frame might create some confusion there.

[ttulka]

Maybe is changing FPS not ideal, I agree. Still, I believe some out-of-the-box mechanism for controlling the game speed provided by the platform would be really handy.

All in all, it is a problem every game must deal with. Why not solve it once and use it everywhere?

As feedback from other users would be helpful. It'd make sense to postpone this.

[leroycep]

I think at very least the speed should be limited. Playing the examples on my main monitors is difficult because it runs at 144 Hz, which makes the games much faster.

[FaberVitale]

Documentation is currently a bit misleading:
incorrectly assumes that FPS is always at 60 but the amount of times rAF runs the callback is tied to several factors:

• is device running in power save mode?
• What's screen refresh rate?
• can the device keep a constant frame rate

For instance on my mac plugging and unplugging the power cord changes the frame rate from 60 to 30.

I think there are 2 possible approaches:

1. Expose a function to cap the frame rate.
2. Change update signature from fn update(); to fn update(timestamp: WASM i64); where timestamp is the argument that rAF passes to loop .

[ttulka]

@FaberVitale Thanks for clearing things up!

When the platform cannot call update in a constant interval it should provide a way to get the current FPS to ensure consistent speed. The first option proposed by you makes sense to me. Alternatively, load<u8>(w4.FPS); would fit well to the platform's API style.

A workaround would be using a timer in the game's code and performing (or not performing) update based on the time (number of milliseconds) since the previous update.

[DenialAdams]

Documentation is currently a bit misleading: incorrectly assumes that FPS is always at 60 but the amount of times rAF runs the callback is tied to several factors:

* is device running in power save mode?

* What's screen refresh rate?

* can the device keep a constant frame rate

For instance on my mac plugging and unplugging the power cord changes the frame rate from 60 to 30.

I think there are 2 possible approaches:

1. Expose a function to cap the frame rate.

2. Change update signature from `fn update();` to  `fn update(timestamp:  WASM i64);` where timestamp is the argument that rAF passes to [loop](https://github.com/aduros/wasm4/blob/main/runtimes/web/src/index.js#L343) .

Sorry to trouble you @FaberVitale , but could you share how you were able to overlay the frame rate? It may be helpful for an issue I'm running into. Thanks :)

[FaberVitale]

@DenialAdams

• 1 Open "rendering" section

• 2 Toggle on "frame rendering stats"

[rajsite]

Another use case (for either setting a lower bound FPS or reading the current time between frames, etc) could be for running on low-power devices. I'm using wasm4-aot to make a GameBoy Advance ROM out of a wasm-4 game. Using that approach is difficult to hit 60fps but it's still amazing it works at all!

Can see the difference between running the wasm-4 build in the browser and running in an online gba emulator (just click "Run Anyway" if it complains about the ROM format). The GBA rom isn't hitting 60 fps in the emulator so the game feels slow.

I ended up scaling all tick oriented constants (by eye-balling the movement speed) and the time scaled ROM in a gba emulator at least moves a little better even if the FPS is lower.