How to limit framerate?

[Nop90]

I just completed the remake of Impossible Mission on the Lynx and started polishing the game. The biggest issue of the game is a not constant framerate in different rooms.

 

The code is already heavily optimized to avoid slow instructions (like * / %), the performance bottleneck is the GFX drawing.

 

For the elevator screen I used chained sprites, in the rooms at first I not used it for memory limits, now I forked the code and I changed it to use chained sprites, but to find the needed memory I have to load some code from the cart every frame (and pay attention  to not do it while playing PCM samples from the cart 😒). This code is very buggy at the moment and doesn't seem to have a big boost of speed.

 

I'll try to fix it, but I want to try a different way on the code without the chained sprites. I'd like to limit the framerate to the lowest value (about 12 FPS) so all the rooms run at the same speed, and tune the engine (I can do it', I don't update sprites every frame at the moment).

 

I tried using tgi_setframerate, but id doesn't work as expected. The first screen of the game is a splash screen with a 255 color image that works fine at 50 FPS, but flickers with other framerates (higher or lower). If I set 50FPS for the splash screen then I change to 12 in the game init code it seems to not work.

 

If I set 12 FPS from the beginning it works ok for most of the rooms, but some of them (especially the code rooms that have only few sprites) run much faster.

 

So the first question is: how does tgi_setframerate work? Can I set every value I want or not? Why do I see the described weird effects?

 

The other question is: how could I limit the framerate in other ways? I think I could track the execution code of every frame and wait before starting a new one till a constant amount of time. Not very clean but should work. Are there other strategies?

 

 

[42bs]

36 minutes ago, Nop90 said:

So the first question is: how does tgi_setframerate work?

This is the LCDs frame rate. Atari recommends 60Hz, some games run with 75Hz. 50Hz looks ugly on original screens.

[42bs]

38 minutes ago, Nop90 said:

The other question is: how could I limit the framerate in other ways? I think I could track the execution code of every frame and wait before starting a new one till a constant amount of time. Not very clean but should work. Are there other strategies?

I think this is the only way. I would read buttons while waiting though. To keep responsiveness.

[Ninjabba]

I'll probably get scolded for this approach, but I achieved this by writing a constant number of sprites and make sure to draw them off the screen when I don't need them. Not at all elegant but quite easy to implement.

Edited April 17 by Ninjabba

[laoo]

I use vertical blank interrupt code that counts from 0 to a given value n, I swap video buffers when n is reached and then zero the counter. In the main loop I just wait when the counter changes from n to 0 and start drawing then (It's oversimplified, but that's the idea).

 

[Nop90]

6 hours ago, Ninjabba said:

I'll probably get scolded for this approach, but I achieved this by writing a constant number of sprites and make sure to draw them off the screen when I don't need them. Not at all elegant but quite easy to implement.

I did it the same in some game of mine 😉, but this time I have to find a solution that doesn't use too much memory

 

5 hours ago, laoo said:

I use vertical blank interrupt code that counts from 0 to a given value n, I swap video buffers when n is reached and then zero the counter. In the main loop I just wait when the counter changes from n to 0 and start drawing then (It's oversimplified, but that's the idea).

 

Great solution, it's easy to add a counter in the audio driver already linked to VBL interrupt handler. Thanks.

[Nop90]

The fame limit using a counter in the VBL interrupt handler works really fine and it added only 11 bytes in the resident sector. Also I set the screen refresh rate to 60Hz and I limited the framerate to 20FPS (seems to be a nice value). Limiting all the different part of the game to the same FPS makes it easier to keep constant the timer of the game.

 

Now I have to tune all the animations with this setting, but should not take too much.

 

Thanks again to everyone for the support.

[42bs]

22 hours ago, Ninjabba said:

I'll probably get scolded for this approach, but I achieved this by writing a constant number of sprites and make sure to draw them off the screen when I don't need them. Not at all elegant but quite easy to implement.

A sprite off-screen is not drawn at all. SUZY skips it. So the same sprite takes different number of cycles whether it is fully, partly or not inside the 160x102 pixels of the render buffer.

Edited April 18 by 42bs

[Nop90]

3 minutes ago, 42bs said:

A sprite off-screen is not drawn at all. SUZY skips it. So the same sprite takes different number of cycles whether it is fully, partly or not inside the 160x102 pixels of the render buffer.

Yes, SUZY skips it, so there is no effect on the drawing time, but I think that the loading time of the sprite data into SUZY is different if the sprites are chained or not. If I remember well, reading the Lynx patents it seems that SUZY has some data buffer in it and at low level it should prefetch some data for the next sprite while it parses the current one.

 

Is this correct?

[42bs]

SUZY does burst read, but no parallel or out-of-order processing. And no pre-fetching of the next SCB.

[42bs]

I haven't checked it yet, but there should be a difference if the sprite is out of the right or bottom boundary compared to upper or left (if normal drawing is used).

 

 

[Ninjabba]

54 minutes ago, 42bs said:

A sprite off-screen is not drawn at all. SUZY skips it. So the same sprite takes different number of cycles whether it is fully, partly or not inside the 160x102 pixels of the render buffer.

You're correct, I forgot that I was drawing them behind the background sprite to get the desired behavior.

[Turbo Laser Lynx]

3 hours ago, Ninjabba said:

You're correct, I forgot that I was drawing them behind the background sprite to get the desired behavior.

Ahaa, nifty idea if it indeed works. 😄

[Fadest]

For A Bug's Lynx, during the speed coding, as the game was becoming faster and faster when you eat the gems, I stacked them on the same position. Was a bit crap, but I guess it was a nice 3AM workaround

[42bs]

1 hour ago, Fadest said:

For A Bug's Lynx, during the speed coding, as the game was becoming faster and faster when you eat the gems, I stacked them on the same position. Was a bit crap, but I guess it was a nice 3AM workaround

Cheater

[42bs]

1 hour ago, Fadest said:

For A Bug's Lynx, during the speed coding, as the game was becoming faster and faster when you eat the gems, I stacked them on the same position. Was a bit crap, but I guess it was a nice 3AM workaround

This is BTW the reason, Space Invaders speeds up (the arcade version). The less monsters, the quicker.

[Fadest]

Yes, but while it is fun in Space Invaders (game becoming frantic after some time), it is not appropriate in a game like ABL.

And speed coding is always cheating If you want to make clean stuff, you end up with the skeleton of your project, and nothing more after 24 hours.