Android Game Loop

[MrPlow]

Hi Sf and Gernot

Not sure how much this is down to my testing device
But two versions of a similar game Ball Breaker game - one on older compile (using 12.308) and one using v16

They should play identical - but the v16 is showing some lag and twitchy ball movement.

I am testing multiple builds - tweaking as I go - but the issue is still there - something intermittant.

[spacefractal]

nothing im can do really with this kind of info at all nor can fix it or nothing im can fix at all!

to tips you can:

 - avoid using off sceen buffer if you can. This can kill a lots of performance.
 - Floats can been twickle and strange as they might shown as 0.99998 rather than 1. Here nothing im can do at all!

Howover glbasic has allways has some very weird frame pacing (not frame rate) issues, property caused by LIMITFPS not working as intended.

[MrPlow]

Thanks SF

Its a strange one alright - it could be a float thing - but I might try moving out the functions from within the type (using self.variables etc)
It could be that.

Generally the app works fine - just a small 1 sec slowdown every 5 or so.
It could be my device...Nexus 2 - old now only Android 6.0

I have to order myself a new test device

[spacefractal]

im have no idea, but its a general issue with LIMITFPS, property in OpenGLRainbows::FlipScreens that does not calculate frames correctly at all some how.

Framepacing has allways been hell of a issue in glbasic since day one really. Here im do NOT talk about framerate, but more framepacing that is incorrect.

[spacefractal]

also in the flip side, im have fixed two of my game, so they can uses higher framerate than 60. etc Catchout and PowerUp Elevation. Actuelly you might cannot see it, but felling and movement is much more responsivity.

This is the main reason framerate matter. Its not about the look, but more about the controls and precision. No wonder Counter Strike players chase FPS those days. That is even on a 60hz screen.

So next release for both game im set LIMITFPS 144, true and possible to disable vsync.

But im have not checked how im did Karma Miwa. But no possible on Greedy Mouse and Spot Race throught. Greedy Mouse used frameskipe measure, which is a bad idea.... howover none of the game uses fast reaction controls anyway.

[dreamerman]

hm.. not sure if I was aware of those frame pacing issues, but in fact setting fps limit to 60 can cause some issues on 75/90/144 screens, and here one question raises. What's the best method to avoid possible problems, use VSYNC, LIMITFPS with some large number, use hand-made fps control function in WHILE loop or something else? For mobiles mostly as for PC dedicated title it may depend on game type.

[spacefractal]

this is depend on the game type. Genius Greedy Mouse is such a game that dont suffer a lots when frame paching happens at all, due the game type. This game used frameskip measure, which is same with Karma Miwa. So those games can only been played in 30/60fps as they are hard code that way.

CatchOut and PowerUpElevation was howover was calculated by system timer in mind.

But im do still see frame pacing issues, regaardless of system, sometimes stutter VERY hard! This is one of the main very annoying issue in glbasic, that has newer been fixed.

But my guess is the main issue is in that way LIMITFPS do calculating is bad and might conflict with your own frame skipping code based on the timer.

Its would been nice if im could set a LIMITFPS 0, TRUE, which should just skip that frame code completly regaardless of monitor type, but of course that code should stays when sync is disabled. Then its would been easier.

[MrPlow]

Thanks so much! That solved my issue using vsync and fps of 90 did the trick - along with jigging my timer code

One other question - i omitted the appcompat:1.0.0 - and it didn't seem to affect anything but it does reduce build by 1mb so if not required - i would rather leave it out

Is there any practical reason for it?

[spacefractal]

im thinks its got depreacted in a recent build. its was used for theme, but we dont use it. im should remove that really, but diddent do that to dont do any suddently mess.

[SnooPI]

It's very bad in a game to limit the number of frames per second.
You must use an unlimited FPS and a deltatime (and a vsync for a really smooth animation but this can cause a slowdown if the display takes longer than the refresh rate of your PC/Phone screen).

[spacefractal]

yes indeeded, but diddent do that for all games, nor want to do that. but its show ok and no have complain it throught. That the matter.

Vsync off can do cause very very bad screen tears, which is why im dont like that really. but for fps testing, of course its can been disabled here. most screen is still 60fps and most of us do retro games and should been 60fps anyway.

But controlling in a higher fps can been feels better. No doubt. Its have much less lag and delay.

[Qedo]

stupid question but is there a way in GLB to check the vsync of a screen?
ad maiora

[MrPlow]

Having an FPS limit is also needed for mobile so that your app or game is not draining the device battery power.
If less fps then less computing power over time elapsed - isn't that how it works?

I don't want to put the fps too high for risk of the Android OS telling the user to "Uninstall" for power draining.

[spacefractal]

this is what enabled VSYNC do:
its limit the FPS that is set to the hz of the screen, even you set a higher FPS (etc 144).

so battery drain should been same for a enabled VSYNC.

You could do various options eventuelly.

Brick Breaker is such a game that would give better control (less lag) for a high FPS.

Howover im have do newer ever seen a message to uninstall a app due battery drain here on any devices.