hey everyone, back again!
ive been experimenting a little bit, and i was trying to make my game Haste (found at https://www.lexaloffle.com/bbs/?tid=145177) be able to run at 60fps.
The original cart:
this worked a little bit, but many of the values were offset, and i wasnt able to simply halve them to make it twice as slow.
the main goal is to have more accurate times for speedruns, but also, i noticed that when running side-by-side against eachother, the v.16 (30fps) and 60fps counterparts look about the same amount of choppiness when moving around the map.
what i mean is, the 60fps version doesnt look smoother.
so is there a more efficient way to make the game run the same at 60fps than going through each value with trial and error?
and is there a way to make it look smoother with 60fps?
Currently on mobile but will check during the week.
1st, be sure you don’t have frame skips by checking stat(1)
Smoothness depends on the speed of things on screen.
If scrolling and player move at 1 pixel per frame at 30fps, your 60fps version will look exactly the same.
If your player moves at 2 pixels per frame, the gain in smoothness is significant.
If speeds are 1pixel per frame or below, you can still use 60fps to make things look better : your player will love 1 pixel onscreen every two framrs, but the camera ça move twice in the lean time.
You can have a smooth elastic dead zone in the screen center instead of a camera locked directly on the player
not EXACTLY sure how fast per frame you move, might test that when i get home.
wdym checking stat(1)?
and ill see if i can find how to make that deadzone youre talking about. similar to a metroid-type camera, yes?
The second cart seems to be running at 30fps... I can see you're setting _update instead of _update60 in init_menu(), you might want to fix that.
didnt see that one. yep, that fixed the 60fps problem, thanks a ton!
now, should i just go through each value to test them, or is there a quicker way to do that
@uncertifiedloaf , stat(1) is cpu usage, if you use _update() (30FPS target), you ideally want the cpu usage not to go over 50%, because you'll double the CPU load if you start to use update60() (60FPS target).
Having frame skips can make things more noticeably choppy: an irregular frame rate between 30FPS and 60FPS can feel less smooth than a stable 30FPS even if you have more frames in total.
That doesn't mean frame skips are to be avoided at all times : for example, if you have multiple maps stored as compressed strings in the source code, losing frames for half a second between levels is perfectly fine, it's the variation during game-play that should be reduced as much as possible. (unless you purposefully introduce frame skips to highlight impacts, for example)
And yes, I was speaking about advanced deadzone.
You can implement one just fine with 30FPS. If your deadzone is just a central rectangle. The advantage is that when you do a small jump back, the scrolling stops and it helps the player be more precise, but the drawback is you are reducing the ability of the player to look ahead.
If your player moves 30px per second, 1 px per frame, you can have a much bigger deadzone, and move the camera 1px per frame, so twice the speed of the player, until the player has his back against the deadzone border.
Adding some elasticity to the camera positioning looks great, as if the cameraman was trying to adjust, and the higher the frame rate, the smoother the camera effect.
[Please log in to post a comment]
