Hi there,

I'm developing a metroid-like that I intend to release commercially.
It's somewhat in an "advanced stage" of development and there are plenty of things I'd like to talk about with you guys.
Since I figured it could be of some help for future readers, I may be creating new threads reguarly from now on.

--
Would you say it is mandatory to do my calculations based on the actual time spent in milliseconds (I think it is called Delta time ?) as opposed to rely on update() running every frame ?
If so, what'd be the best approach to do this clean ?

Since I started prototyping with P8 I just have a global that I increment on every step to count time and do my maths. I'm now wondering if I should do something about it.
According to the manual, Picotron's "t" returns how many seconds elapsed, but it's just incremented every 60 frames so it wouldn't help ?

Maybe I don't even need to worry about an eventual frame drop and just let it be as long as I put all the mandatory calculations in update() and not in draw() ?
What about porting games to another platform or dealing with a screen refreshing at 78 fps ?

I would love to know your take on this and what you guys usually do about it.
Thanks

Hi!
Have fun working on your game! I'd love to see a screenshot or gif :)
And if you intend to publish on Steam think about control schemes, on screen instructions and a custom pause menu as early as possible.
Measuring time in between frames isn't strictly necessary if your game runs at a stable 60fps-picotron will not execute it faster, only slower. If you need accurate measurements for something else you can definitely measure time with time(), but this is not like other engines that will give you as many frames as they possibly can. If you're thinking about movement related calculations and you're expecting frame drops it might be smart to account for it, but otherwise you should be fine.

Hi there thank you for your answer and sorry for the delay.

I had figured all I read about delta time might only apply to more ressource demanding games.

I was wondering if you guys do something about it.
And if it would be considered somewhat "bad" and not professional to not account for eventual frame drops in a game that is available for purchase.

On the other hand I wouldn't be able to say if it'd be better to let the game slow down to do all the calculations than actually jump a frame in order to stick to a constant framerate.

So I was hoping someone could share its secrets on how to deal with those things.

Picotron is a strictly fixed timestep. I like to define DT = 1/60 as a global constant. That'd make it easier to adapt in case Picotron ever introduces a dynamic timestep, but it's mostly so that things are measured in seconds. Picotron will skip calling _draw for some frames if drawing becomes too expensive. Calls to _update will only be skipped if either the _update call is too expensive, or the _draw call is taking several frames to execute.
In practical terms, it's a bad idea to compensate for lag in _update, because that will change how things behave, which is antithetical to the purpose of using a fixed timestep.

Thanks for the info 🙏
And the insight is very much appreciated.

I am often unsure what the good practice is, and end up moving forward blindfolded