FixedRateLogic needs converting from BMax to GLBasic!!!

[erico]

But sometimes digging an old thread with same subject/topic is really cool.
We get a glimpse of our/people´s mind 5 years ago.

[MrTAToad]

You do realise that the original post was created 5 years ago?

Fixed rate logic problems never get old though!

[spicypixel]

I use this.

Code (glbasic) Select Expand


CONSTANT FRAMES_PER_SECOND% = 60
CONSTANT SKIP_FRAMES% = 1000 / FRAMES_PER_SECOND
CONSTANT MAX_FRAMESKIP% = 2

Code (glbasic) Select Expand


FUNCTION GAME_LOOP:
    next_game_tick% = GETTIMERALL()
    LOCAL loops%
REPEAT
loops% = 0
WHILE( GETTIMERALL() > next_game_tick% AND loops% < MAX_FRAMESKIP%)
GAME_UPDATE()
next_game_tick = next_game_tick + SKIP_FRAMES
INC loops%
WEND
GAME_RENDER()
UNTIL (EXIT_LOOP% = TRUE)
ENDFUNCTION

I have functions for rendering and logic as you can see. The game loop function is initiated from my program state machine loop, and I return to my state machine when EXIT_LOOP% is true.

STATE MACHINE EXAMPLE

Code (glbasic) Select Expand


WHILE Quit% = FALSE
SELECT APPSTATE%

CASE AS_TITLE_SCREEN% ; EXIT_LOOP% = FALSE ; TITLE_SCREEN()
CASE AS_SETTINGS% ; EXIT_LOOP% = FALSE ; SETTINGS_SCREEN()
CASE AS_LEVEL_SELECT% ; EXIT_LOOP% = FALSE ; LEVEL_SELECT_SCREEN()
CASE AS_GAME_OVER% ; EXIT_LOOP% = FALSE ; GAME_OVER_SCREEN()
CASE AS_CREDITS% ; EXIT_LOOP% = FALSE ; CREDITS()
CASE AS_SECRET% ; EXIT_LOOP% = FALSE ; SECRET()
CASE AS_HIGHSCORES% ; EXIT_LOOP% = FALSE ; HIGH_SCORE_TABLE()
CASE AS_HIGHENTRY% ; EXIT_LOOP% = FALSE ; HIGH_SCORE_ENTRY()
CASE AS_HOWTOPLAY ; EXIT_LOOP% = FALSE ; HOW_TO_PLAY()
CASE AS_GAME_LOOP% ; EXIT_LOOP% = FALSE ; GAME_LOOP()
DEFAULT ; Quit% = TRUE

ENDSELECT
WEND

[sf-in-sf]

Hi everyone!
I would like to make my question clearer; using GETTIMERALL() is a polling technique as opposed to real-time interruption. Yes I could include some gettimeral() so the renderer looks at the time regularly, but I don't wish the "logic" to be delayed by all those lookup functions. I would like it to be interrupted automatically by the system's clock/tick/timer/milliseconds. Isn't it what happens when a renderer runs in the background as a thread?
   My goal: getting a responsive touchscreen, while the renderer is easily interrupted anytime. It's not about screen f.p.s. performance! There is an equivalent of what I want: a free Mandelbrot fractal tracer, on the android market. You set the zoom/centering/rotation with your fingers any time, and the renderer works in the background, as long as you don't touch the screen. You understand?
   How can I implement that with glbasic? With some  INLINE C code? Thank you!

(Is it that bad if the original question is a few years old?)

[spacefractal]

you should have created a new thread about it, so im might split it up? This is to avoid confuction which was that its happens here. Its two differnt thing now, so...

There is no callback like this on glbasic. This is something that should do require threading, but threading is something glbasic is not good at all and crash very easy. So sadly this cannot been done in glbasic at all. Recently im fixed such a callback issue in Android to prevent a threading crash.

So here its better idea to uses GETTIMEALL() and measure to a showscreen 5 seconds per fps or such. If you uses Android Extras, then KEY(1) a toggle key. KEY(1) wait that to been checked in your code to returns eiter TRUE or FALSE. When KEY(1) have been consumed, then its changes to FALSE automatic until the next key press.

There is no counterpart for TOUCHSCREEN really. But mightbeen im could add a little Android Extras function, which can been checked the last touched presses, like KEY(1)? Im put that to the TODO list. Its a easy to do that in SDLActicity.Java.

[Moru]

No, there is nothing wrong with digging up old threads. All posts have a date on them.

If you want to interrupt the calculation you need to keep checking GETTIMERALL() in your calculation loop to see if it is time to check for touches. Every time the user touches the screen you need to restart your draw anyway. It's hard to use threads in GLBasic without crashing so for the users sake, just run in one thread and avoid crashes. :-)