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

take_new_title and debug_run question #62

Open
lesleyrs opened this issue Feb 24, 2023 · 6 comments
Open

take_new_title and debug_run question #62

lesleyrs opened this issue Feb 24, 2023 · 6 comments

Comments

@lesleyrs
Copy link
Contributor

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
Copy link
Owner

jjant commented Feb 24, 2023

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
Copy link
Contributor Author

lesleyrs commented Feb 24, 2023

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
Copy link
Contributor Author

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
Copy link
Contributor Author

lesleyrs commented Mar 19, 2023

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
Copy link
Contributor Author

image

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

@jjant
Copy link
Owner

jjant commented Apr 22, 2023

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!

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

2 participants