IntyBASIC FRAME counting?

[Eisengrim]

I'm trying to make an elaborate explosion with sprites, and to prevent everything from happening too fast I've used a FRAME counter; e.g.,

c = FRAME + 10

WHILE FRAME < c

'sprite code here

WEND

 

This works very well, but only at the beginning of the game. After a few seconds the code just doesn't execute anymore. I suspect it's because the FRAME count gets too high for the loop, or turns over after maxing out, but I'm not sure. An alternative that sort of works is FOR/NEXT loops, but that brings the whole game to a halt while the loops execute. I bought nanochess's book and have tried to understand how FRAME is used, but still don't get statements in the example games like (FRAME AND 1). Is FRAME counting the way to go for solving my problem, or is there some other way to accomplish this?

[Zendocon]

You're using the variable c as opposed to #c.  Variables prefaced with a hash symbol are 16-bit, and variables not prefaced with a hash symbol are 8-bit.

 

Without the hash symbol, c has a maximum value of 255.  Since there are either 50 or 60 frames per second, depending on whether you enable PAL mode, the value of FRAME + 10 is going to overflow past 255 in about 4-5 seconds.

 

Similarly, be aware that 16-bit variables are signed by default (range -32,768 - 32,767).  FRAME is unsigned, so you'll eventually have the same problem unless you declare the variable using UNSIGNED.

 

I hope that helps.

[+nanochess]

FRAME is a 16-bit variable. The correct code would be:

 

#c = FRAME

WHILE FRAME - #c < 10

    ...your sprite code...

WEND

[Eisengrim]

Thanks! This definitely helps.

[artrag]

Your code is locking the Cpu.

You may consider an open  loop solution and the use of the wait command.

[Eisengrim]

How do open loops work in IntyBASIC?

[intvnut]

On 7/30/2019 at 5:58 AM, nanochess said:

FRAME is a 16-bit variable. The correct code would be:

 

#c = FRAME

WHILE FRAME - #c < 10

    ...your sprite code...

WEND

 

Although nanochess didn't state it out loud, the subtract-and-compare is needed to handle the case where FRAME wraps from 65535 back to 0.  That's another reason why #c = FRAME + 10 won't work properly, a little after the 18 minute mark on NTSC, although it'll recover in under a second.

 

(Imagine trying to find that bug during testing... "Weird glitch that happens every 20 minutes or so.")

[+nanochess]

12 hours ago, Eisengrim said:

How do open loops work in IntyBASIC?

It means to have a main game loop (like the ones used in my book):

 

game_loop:

    IF explosion THEN

       explosion_frame = explosion_frame + 1

       IF explosion_frame = 10 THEN

           explosion_frame = 0

       ELSE

           ... do things related to explosion...

       END IF

   END IF

   ... update sprites...

   WAIT

   ... handle game ...

   ... handle control ...

   GOTO game_loop

 

Although if your explosion stops the game, then you are doing it right.

 

[Kiwi]

I would use a synonym for FRAME like aniframe or timer and have that variable increase in the gameloop.  FRAME variable increase every time interrupts occur.  So the cases may miss if your game get busy with slowdown because interrupt occurred and FRAME been increased by 2. 

[Eisengrim]

Thanks for the suggestions. I have a loop like nanochess suggested already as the main game controller; I might move some animations inside to make things smoother.

[intvnut]

On 7/30/2019 at 5:58 AM, nanochess said:

FRAME is a 16-bit variable. The correct code would be:

 

#c = FRAME

WHILE FRAME - #c < 10

    ...your sprite code...

WEND

 

nanochess:  Do you need to declare #c to be UNSIGNED to make this work reliably? 

[+nanochess]

22 minutes ago, intvnut said:

 

nanochess:  Do you need to declare #c to be UNSIGNED to make this work reliably? 

No, because the result is always positive. And let us remind that the result is 16 bits.

 

Let us suppose FRAME reaches the value 0xfffc, then #c gets assigned 0xfffc.

 

FRAME = $fffc    FRAME - #c = $0000

FRAME = $fffd    FRAME - #c = $0001

FRAME = $fffe    FRAME - #c = $0002

FRAME = $ffff     FRAME - #c = $0003

FRAME = $0000  FRAME - #c = $0004

FRAME = $0001  FRAME - #c = $0005

FRAME = $0002 FRAME - #c = $0006

...

FRAME = $0006 FRAME - #c = $000a (10 decimal)

 

[intvnut]

On 8/2/2019 at 5:33 PM, nanochess said:

No, because the result is always positive. And let us remind that the result is 16 bits.

 

Let us suppose FRAME reaches the value 0xfffc, then #c gets assigned 0xfffc.

 

FRAME = $fffc    FRAME - #c = $0000

FRAME = $fffd    FRAME - #c = $0001

FRAME = $fffe    FRAME - #c = $0002

FRAME = $ffff     FRAME - #c = $0003

FRAME = $0000  FRAME - #c = $0004

FRAME = $0001  FRAME - #c = $0005

FRAME = $0002 FRAME - #c = $0006

...

FRAME = $0006 FRAME - #c = $000a (10 decimal)

 

 

I was more worried about the $7FFF => $8000 transition, as that would have been undefined behavior in C.  I guess signed integer overflow/wrapping is perfectly legal in IntyBASIC.  I guess C has given me some paranoia.