Why is there such a large discrepancy in animation speed?

[z9385pdi]

The animation speed is stable (as in QB64) if I launch the program with sbasici. But if I launch the program with sbasicg -r, the animation speed is very steady.

P.S. I’m running Windows 11.

[Joe7M]

Hi z9385pdi,

Can you please add an example? When I want to have smooth animation speed, I always use showpage() at the end of the game loop. Once you use showpage() SmallBASIC will stop render to screen automatically, but only does it when triggered by showpage(). When combining showpage() and ticks() you can also ensure a constant frame rate not exceeding a certain limit. (see here)

[z9385pdi]

Please have a look at the 3dtorus.bas example. You will notice an obvious difference in animation speed when running it with sbasici and sbasicg -r.

[Joe7M]

I had a look to 3dtorus.bas. I also see that the animation is in case of sbasici smoother. I think the reason is, that the FLTK version and the SDL version of SmallBasic handle automatic rendering to screen differently. As I wrote, for smooth animations, showpage() should be used. Here 3dtorus with showpage and limiting the animation speed to 60 fps (only the relevant part of the code).

cls
ElapsedTime = 1
const FramesPerSecond = 60

repeat
    starttime = ticks()
    anglex = (anglex + 1) mod 360
    angley = (angley + 1) mod 360
    anglez = (anglez + 1) mod 360
    RotateAndProject Model(), anglex, angley, anglez
    DrawModel Model() ,  Poly()
    print "FPS: "; round(1000/ElapsedTime)
    showpage()
    endtime = ticks()
    ElapsedTime = endtime - starttime
    if(ElapsedTime < 1000 / FramesPerSecond)
      delay(1000 / FramesPerSecond - ElapsedTime)
      ElapsedTime = 1000/FramesPerSecond
    endif
until

[z9385pdi]

The modified code runs fine in sbasici, but it gets stuck about a second after launch in sbasicg -r.

[Joe7M]

I tested with sbasicg in Linux and it worked as expected. In Windows it freezes, because in sbasicg (SDL-version) delay don't like 0 as parameter. I have to check, what the problem is. Work-around is delay(ceil(1000 / FramesPerSecond - ElapsedTime)). ceil will round to the next larger number.