Setting FPS

DaddyJDM

@Z-Mann Thank you for this idea! It makes sense. I think I ran into this buffer queue sideways when I tried the approach @PB_____ suggested above. Somehow, I was not able to figure out the "right" dt to correctly get a "do-nothing" frame.

I actually tried something similar to your suggestion, the division of computation and rendering across two frames. Unfortunately, I messed it up and got "flashing" back and forth between blank frames and my scene. I think I will try again - it seems like the most promising approach, as far as I can understand right now!

vinicity

In my game, I'm not quite hitting 30 fps. Would I gain anything by using the pattern in @Z-Mann's answer above?

Currently I cannot fit both the calculations and the drawing command in the 1/30 seconds that would be necessary for a stable 30 fps frame rate (I'm currently hitting about 22-28 fps) . But if I do all calculations in one 1/30 second frame, call update(), and then do the drawing in the next, would I be able to get to more stable frame rate that way?

vinicity

Also, @Z-Mann, could you (or someone else) perhaps elaborate a little bit about the difference between timestep and delta time, and when and how to use which?

Z-Mann

@vinicity Delta Time and Timestep are used mostly interchangeably. Mostly! Delta Time refers more to the measured time of a frame (that would be why deltaTime() is the name of the function), while Timestep is the value you use to advance your game world, as in

timestep = deltaTime()
x = x + v * timestep

for simulating linear movement with speed v. Normally, those would be equal. But if you apply a fast forward or slow motion effect, you put a factor in between the two, as in

timestep = deltaTime() * 2 // fast forward at double speed
x = x + v * timestep

Or, sometimes it's necessary to calculate the game advancement between two render frames in two simulation steps:

timestep = deltaTime() * 0.5
x = x + v * timestep
x = x + v * timestep

That doesn't make sense in this simple example, of course, but racing games sometimes do this to accurately simulate suspension and ground traction.

Here, you have the opposite situation, you do one game update per several 'render' frames.

I don't think you get any advantage from the two step scheme if you never ever hit 30 FPS. Only if you have large frame-to-frame variance in processing/rendering time, it might help to flatten the bumps a bit. But the scheme should totally be extendable to three frames to try and lock to stable 20 FPS, if that's a framerate your game is still playable at. You need to distribute the work, then, the buffering only gets you so far. So (adopting the timestep variable name)

float timestep = 1/20
loop
  float nextTimestep = deltaTime()

 // do computational only work, using timestep

  update()
  nextTimestep += deltaTime()

  // do some more computational only work, using timestep

  update()
  nextTimestep += deltaTime()
  clear()

  // do rest of the work, still using timestep

  update()
  timestep = nextTimestep
repeat

vinicity

Thank you for the explanation. Very interesting, indeed. I have never really thought about or used these concepts before.

DaddyJDM

Alright, I've taken another try with it! I tried the "split frame" approach again. However, the optimal division of work still eludes me: In my main test case, I am somehow still not keeping up with the frame rate.

So... I am broadening the discussion a bit to ask a related question: How "expensive" are certain functions compared to others? Are there "known" bottlenecks to be careful of?

One thing I tested last night was object groups. In my Starfighter game, I use object groups to make a custom camera. In a small test program, I set up an array of 200 randomly moving objects, testing for collisions between each pair with objectIntersect. If I place all 200 objects in a group, I got around 13fps. If I did not put the objects in a group, I got closer to 15fps. I thought that was an interesting find.

My next idea is harder to test with a simple program, so I thought I would ask here: In a long program file (>1000 lines), is there a "penalty" for calling functions from opposite "ends" of the program?

Doriphor

You could probably also do

myTimer = setTimer(1/30, -1, functionName)

// Stuff

function functionName
    // Some other rendering-related code
    update()
return void

It might not suit every situation, but it's worth a thought.

I'm not sure about the -1 though, but it worked for my tests, and it should last for over a hundred hours at least, even if the timer can run out 🤔

PickleCatStars

That’s an interesting approach, and seems easy enough to try.

PickleCatStars

DaddyJDM: Apparently, it is known that FUZE is not fast with multidimensional arrays. Other than that though, I dunno. I often wonder about things like that myself, what’s expensive and what’s not etc.

Like, there’s a ‘distance’ function in FUZE, which is generally known to be expensive because to get the distance between vectors, part of the way to do it is to use square roots, which is expensive. Maybe because it’s a built-in function though, it’s not too bad. Also, am I slowing things down by using really long variable names? I dunno!

Doriphor

@toxibunny the interpreter probably at least tokenizes your code. I wouldn't worry about names (but I could be wrong)

Built-in functions also run at native speeds from what I can tell so they can probably also be safely used at will.