We should probably think about the issue of how to handle unexpected tick lengths. If you ask for 60 fps you're also at a much higher risk of getting less than that if running on a slow computer or if your game is script heavy, in addition to large differences when vsync is disabled or enabled.
We should add an option to set whether vsync is off or on by default, because different games will want different things. Vsync is good when you're scrolling the screen quickly, but otherwise probably unwanted.
We could do automatic frame skipping, which still runs scripts and everything else as normal, but skips drawing the screen to try to make up time. However frame skipping can't solve the problem if most of the time is being spent in the script interpreter -- but if that's the case it's no longer the engine's problem.
We could make frame-skipping optional, in case you want to write your scripts so as to handle variable tick lengths yourself. However if you do want to do that, then I guess built-in animations and movements should also handle variable length ticks by skipping ticks as needed, otherwise scripting your way around variable-length ticks is a lot more work.
I guess that works out to 3 modes of handling unexpectedly long ticks
-the frame rate drops (current behaviour)
-frame skip
-no frame skip, but animations and motions speed up to give the same visual effect
That third mode is a lot more work work so would be added later or probably never.
TMC wrote:
I guess that works out to 3 modes of handling unexpectedly long ticks
-the frame rate drops (current behaviour)
-frame skip
-no frame skip, but animations and motions speed up to give the same visual effect
That third mode is a lot more work work so would be added later or probably never.
I guess that works out to 3 modes of handling unexpectedly long ticks
-the frame rate drops (current behaviour)
-frame skip
-no frame skip, but animations and motions speed up to give the same visual effect
That third mode is a lot more work work so would be added later or probably never.
I like the current behavior because it is predictable (not in terms of time, but in every other sense)
I like the option of frame skip. I have seen that done really well in emulators, and I think it would be a great option for some games.
I don't really understand the third option. I have no objection to it, I just have a hard time picturing how I would use it.
Thinking more about it, the third option probably isn't useful in practice and I wouldn't spend time adding it. It would only be useful if you could reduce the CPU load significantly by skipping whole ticks instead of just rendering frames. That's easily true if you're trying to run at 300 fps because you've set a high framerate multiplier (trying to fast forward through the game); but it's not worth the effort.
Yes, if the framerate target (eg 60fps) isn't being hit, then the game would run slower (things literally moving around the screen slower). Frame skipping means just not redrawing the screen for some frames to save time, so that the target can be hit (even if you can't see all those frames).
I'm still looking to hire someone to help with the sidescroll system if anyone is interested.
Check out Red Triangle Games!
Check out Red Triangle Games!
I updated Automagically! Bizzaro Carnival in Salad Kingdom to run at a framerate of 60. I adjusted the speed of some things, but it's an overall rough adjustment with the animations being clearly too fast.
I think going through this has shown me that any game that would be made with n increased framerate would need to be scripted with that in mind in order to really take advantage of it.
I think going through this has shown me that any game that would be made with n increased framerate would need to be scripted with that in mind in order to really take advantage of it.



