search

jjant / runty8

A Pico8 clone in Rust.
MIT License
222 stars 17 forks source link

`take_new_title` and `debug_run` question #62

Open lesleyrs opened 1 year ago

lesleyrs commented 1 year ago

What is the take_new_title function supposed to be used for? It returns the title name but I'm unsure how or why to use it.

Besides that I saw that debug_run/run_editor is running at higher fps than run, that could lead to some problems with timings not being the expected speed when later changing the setting since you can't immediately tell what fps your game is running at. I noticed this when playing a frames based animation but I couldn't really tell when running the example games for some reason? Although I appreciate having this setting available. 👍

jjant commented 1 year ago

If the user sets a new window title, we store it in the Pico8 struct. take_new_title is Option::take for it. The runtime grabs the new title, and if it's a Some it actually updates the window title.

debug_run/run_editor is running at higher fps than run

That definitely shouldn't be the case, and it may be a bug. IIRC the games should run at 30fps. Are you compiling in release mode (cargo run --release)? If not, it is normal that debug builds run in a slower-than-target frame rate.

lesleyrs commented 1 year ago

If the user sets a new window title, we store it in the Pico8 struct. take_new_title is Option::take for it. The runtime grabs the new title, and if it's a Some it actually updates the window title.

Ah ok so it has to exist for set_title to work, thanks.

That definitely shouldn't be the case, and it may be a bug. IIRC the games should run at 30fps. Are you compiling in release mode (cargo run --release)? If not, it is normal that debug builds run in a slower-than-target frame rate.

This isn't related to --release mode and it's 100% reproducible, when you set it to run while running a debug build it always runs at the intended speed. When you set it to debug_run in a debug build it looks like 60 fps. I could make a repro project but I think my project is simple enough so I'll just set it to public. https://github.com/lesleyrs/staking-challenge.git. You can easily tell from the speed of the animation win/lose "drop".

I see you're doing a similar thing for run_app, but I still don't get why your example games don't run at a higher speed like mine with debug_run and debug build or at least I didn't notice.

lesleyrs commented 1 year ago

I just tested my project on Linux and same happens there. I don't think it's something I did because all I'm doing to increase fps is change run to debug_run. Besides that just doing cargo run without --release. Any idea?

lesleyrs commented 1 year ago

I finished my game and the problem still occurs when using debug_run but I'm not using it in release so that's fine. Earlier commit with the problem is at git checkout 87055fa

It was quite nice to use rust instead of lua and have a 400 kb wasm build btw, so thanks for that :D.

Although I couldn't really figure out how to use functions to manipulate the values of the game struct so it turned into a big mess at the end. Was able to finish it regardless though without bugs I think. I figured out how to do it now though.

lesleyrs commented 1 year ago

image

Repro made in seperate branch https://github.com/lesleyrs/runty8-game-template/tree/fps-error, it only applies to draw() not update().

jjant commented 1 year ago

it only applies to draw() not update().

Ah-ha! That's the thing I was missing, I'd been checking fps for update only and that seemed fine. The problem is running the editor vs not running the editor. debug_run is just a wrapper over run_editor/run based on release/debug mode respectively.

I'll take a look to see what's causing this. Thanks!