Help with flicker technique

[diogoandrei]

Hello there!

 

I've been playing around with the flicker ideia to get a glimpse of it (and it's possibilities). I got things working... hm, sort of. The thing is that I ran into a situation/problem and I have no ideia of what's going on.

 

My selector{0} variable sets if player1 will be a green square or a yellow crab figure, each with it's own pair of localization variables. So I have selector{0}=0 for the square and selector{0}=1 for the crab. That's doing alright.

 

Now, on the collisions...

 

if !selector{0} && collision(missile0,player1) then score = score + 10 : missile0y = 255
if selector{0} && collision(missile0,player1) then score = score - 1 : missile0y = 255

 

So, if selector{0}=1, I have the crab and if I hit it then I should have score=score-1. What's hapenning is that it's working the other way around. When I have selector{0}=1 and I hit the crab, the score adds +10... As I checked Stella's debugger, I have a collision and selector{0} is at 1 (attached picture).

 

So if I do this...

 

if selector{0} && collision(missile0,player1) then score = score + 10 : missile0y = 255
if !selector{0} && collision(missile0,player1) then score = score - 1 : missile0y = 255

 

Things start to work... hit the crab, get -1 on the score. Hit the square, get +10. Why?

 

I don't know if I'm doing something really, REALLY stupid (probably the case). Am I?

flicker_problem.bas

flicker_problem.bas.bin

[RevEng]

You need to put your drawscreen before the collision check - the 2600 actually has to draw the frame for the collision registers to get triggered.

 

As your code is now, you're checking collisions on the previous frame, which is why it works when you do things based on the wrong frame.

 

Not a stupid error... it's a pretty common mistake for those new to the 2600.

[diogoandrei]

You need to put your drawscreen before the collision check - the 2600 actually has to draw the frame for the collision registers to get triggered.

 

As your code is now, you're checking collisions on the previous frame, which is why it works when you do things based on the wrong frame.

 

Not a stupid error... it's a pretty common mistake for those new to the 2600.

 

Hey RevEng, thanks for the help. I really took drawscreen for granted there - but now it makes sense (it did solve another problem of mine also).

 

Let me take this opportunity and ask you about flickering: the way I did it it's how it usually go?

[+Random Terrain]

You need to put your drawscreen before the collision check - the 2600 actually has to draw the frame for the collision registers to get triggered.

If batari has that on the page, I can't find it, so I just added that to a "Did You Know?" box:

 

http://www.randomterrain.com/atari-2600-memories-batari-basic-commands.html#collision

[diogoandrei]

You need to put your drawscreen before the collision check - the 2600 actually has to draw the frame for the collision registers to get triggered.

If batari has that on the page, I can't find it, so I just added that to a "Did You Know?" box:

 

http://www.randomterrain.com/atari-2600-memories-batari-basic-commands.html#collision

 

Hey, it's the second time a question of mine ends up at RandomTerrain =)

[RevEng]

Hey RevEng, thanks for the help. I really took drawscreen for granted there - but now it makes sense (it did solve another problem of mine also).

 

Let me take this opportunity and ask you about flickering: the way I did it it's how it usually go?

You're welcome.

 

There's nothing wrong with the way you did it, but I use a variation on the technique. Instead I use a "frame" variable that I increment each frame.

 

mainloop
frame=frame+1

if frame{0} then gosub drawmonkey
if !frame{0} then gosub drawkillerbanana
drawscreen
goto mainloop

 

It seems like the same result as yours, but with my technique you can also use the same "frame" variable to allow events to happen every N frames...

 

mainloop
frame=frame+1

if frame{0} then gosub drawmonkey
if !frame{0} then gosub drawkillerbanana

temp1=frame&3 : rem ** temp1 will equal 0 every 4th frame
if temp1=0 then monkeycolor=monkeycolor+1 :rem ** make the monkey glow

temp1=frame&7 : rem *** temp1 will equal 0 every 8th frame
if temp1=0 then gosub move_accordion : rem ** make the accordion move

drawscreen
goto mainloop

 

The downside is my technique uses a byte instead of a bit like yours, but I usually want to move and animate things at less than full speed.

 

If batari has that on the page, I can't find it, so I just added that to a "Did You Know?" box:

 

http://www.randomterrain.com/atari-2600-memories-batari-basic-commands.html#collision

Looks good!

Edited January 4, 2011 by RevEng

[jrok]

You need to put your drawscreen before the collision check - the 2600 actually has to draw the frame for the collision registers to get triggered.

 

As your code is now, you're checking collisions on the previous frame, which is why it works when you do things based on the wrong frame.

 

Not a stupid error... it's a pretty common mistake for those new to the 2600.

 

Hey RevEng, thanks for the help. I really took drawscreen for granted there - but now it makes sense (it did solve another problem of mine also).

 

Let me take this opportunity and ask you about flickering: the way I did it it's how it usually go?

 

 

You should probably consider not going with native collision detection if you are going to use flicker in your program. Instead, you could set up bounding boxes for them to track whether or not one object has intersected with another. That way, you don't have to be concerned what frame you're in when testing collisions. This is especially helpful when you want to test collisions between two objects that share the same sprite, like the crab and the square.

Edited January 4, 2011 by jrok

[Piggles]

You need to put your drawscreen before the collision check - the 2600 actually has to draw the frame for the collision registers to get triggered.

 

As your code is now, you're checking collisions on the previous frame, which is why it works when you do things based on the wrong frame.

 

Not a stupid error... it's a pretty common mistake for those new to the 2600.

 

Hey RevEng, thanks for the help. I really took drawscreen for granted there - but now it makes sense (it did solve another problem of mine also).

 

Let me take this opportunity and ask you about flickering: the way I did it it's how it usually go?

 

 

You should probably consider not going with native collision detection if your are going to use flicker in your program. Instead, you could set up bounding boxes for them to track whether or not one object has intersected with another. That way, you don't have to be concerned what frame you're in when testing collisions. This is especially helpful when you want to test collisions between two object that share the same sprite, like the crab and then square.

 

To piggyback on Jrok's suggestion, if you're colliding sprites are different (p0 and p1) but are on opposite frames (one on even, one on odd), you can flicker the p0 every other frame, and flicker the p1 sprites two frames in a row, so that each p0 sprite can intersect with the p1 sprite depending on the current frame. Same for missiles if applicable.

[diogoandrei]

mainloop
frame=frame+1

if frame{0} then gosub drawmonkey
if !frame{0} then gosub drawkillerbanana

temp1=frame&3 : rem ** temp1 will equal 0 every 4th frame
if temp1=0 then monkeycolor=monkeycolor+1 :rem ** make the monkey glow

temp1=frame&7 : rem *** temp1 will equal 0 every 8th frame
if temp1=0 then gosub move_accordion : rem ** make the accordion move

drawscreen
goto mainloop

 

The downside is my technique uses a byte instead of a bit like yours, but I usually want to move and animate things at less than full speed.

 

Looks good!

 

Thanks! That did bring some light. Well, since the whole byte works also as a counter to slow down things, there's actually no downside. Just loved the temp1=frame&something... really, really clever! Thx a zillion!

 

 

 

You should probably consider not going with native collision detection if you are going to use flicker in your program. Instead, you could set up bounding boxes for them to track whether or not one object has intersected with another. That way, you don't have to be concerned what frame you're in when testing collisions. This is especially helpful when you want to test collisions between two objects that share the same sprite, like the crab and the square.

 

Yes, I am considering this for my next "research" on bB. Since I'll be trying a third object on player0, collisions x frames can get a bit naughty. Either way, I'll try it just for the sake of it. Thx =)

 

 

 

To piggyback on Jrok's suggestion, if you're colliding sprites are different (p0 and p1) but are on opposite frames (one on even, one on odd), you can flicker the p0 every other frame, and flicker the p1 sprites two frames in a row, so that each p0 sprite can intersect with the p1 sprite depending on the current frame. Same for missiles if applicable.

 

I'll check that also! Thx!