bBasic collision detection with playfield bands

[CapitanClassic]

The bBasic guide on Random Terrains site says this...

 

Quote

if collision (object,object)

Did You Know?

You need to place your drawscreenbefore the section of code that checks for collisions (the Atari 2600 has to draw the frame for the collision registers to get triggered).

This function is used for checking if two objects have collided on the screen. Valid arguments are playfield, ball, player0, player1, missile0, missile1. The two objects can be specified in any order.

 

The collision() function is only valid when used in an if…then statement.

 

Note that the collision detection is hardware-based and is pixel-perfect. The collision detection may or may not be suitable for your game.

The issue I am having is that my playfield is broken up into alternating bands of playfield pixels of different colors (p0 or p1 color). Each playfield pixel is 4x4.  I only care if a player collides with their opponents color playfield pixels.

 

If I want pixel perfect collision detection between a player and their opposing color playfield blocks, what possible ways can I go about achieving that.

 

i suppose I could flicker the playfield, only drawing the P0 opposing color playfield with the player. (and visa versa for P1). Then after I call drawscreen, only opposite color pfpixels will trigger collisions.

 

I suppose the other way is to take my 8 pixel wide x 12 pixel tall P0 sprite and perform a pfread(x,y) for any of the 6 possible opposite color playfield pixels that could collide (4 possible if aligned to the playfield/ divisible by 4), and calculate if a 4x4 pixel block would fall on any of the active pixels of the current player animation. (Would require getting the current animation pointer, and then bit-wise and with the y-scanline a 4-pixel wide box, then increment and repeat for the remaining 3 lines.

 

Is there some other way in bBasic to do this that I am missing, or can I store/erase the 6 possible P0 playfield pixels, call drawscreen again to get new collisions with only P1 pfpixels, then afterwards restore P0 pfpixels and call drawscreen again. Can I even call drawscreen multiple times before I actually want to draw the screen? [i am guessing no]

 

If I don’t call drawscreen early, I could kind of flicker the near P0 pfpixels by turning them off in the previous loop, then in the current loop all collisions(player0,playfield) will be valid collisions with P1 playfield pixels. Then I could restore the near playfield pixels I turned off. (So that is one more possible solution, near pfpixel flicker)

[+Gemintronic]

You might have to resort to creating a collision map as a static array.   That wouldn't allow for changes to the playfield of course.

 

Trying to make drawscreen and collision statements do anything more may be a red herring.

[RevEng]

 

 

17 hours ago, CapitanClassic said:

Can I even call drawscreen multiple times before I actually want to draw the screen? [i am guessing no]

Correct guess. The screen has to be drawn by the 2600 for the collision registers to see the sprite is colliding with the playfield.

 

17 hours ago, CapitanClassic said:

If I don’t call drawscreen early, I could kind of flicker the near P0 pfpixels by turning them off in the previous loop, then in the current loop all collisions(player0,playfield) will be valid collisions with P1 playfield pixels. Then I could restore the near playfield pixels I turned off. (So that is one more possible solution, near pfpixel flicker)

If you take this one step further, for objects that don't move every frame, you only need to flicker when there's actually a collision, and you need to sort out who's playfield object it was.

 

ie. the regular frame displays both sets of p0 and p1 playfield objects. When there's a collision, the next frame is the one where the player position doesn't get updated, and you display just p0 playfield objects. From the two frames of collision data, you can tell which type of collision it actually was. Use the "near playfield pixels" plan to narrow down the flicker to a smaller area.

 

[CapitanClassic]

1 hour ago, Gemintronic said:

You might have to resort to creating a collision map as a static array.   That wouldn't allow for changes to the playfield of course.

 

Trying to make drawscreen and collision statements do anything more may be a red herring.

Sorry, I should have mentioned the playfield is dynamic. 

I think I will go with flickering the near pfpixels. This will only take 6 bits for on/off status and 2 bytes for the x,y location of the top-leftt playfield pixel (could shrink this to 1 byte, since the playfield is 32x44 pfpixels, but alternating colors. So really 32x22 pixels). Upon detecting a collision with the playfield, I will flicker off the P0 playfield pixels (storing them so I can restore), then on the next frame check collisions again. Any collisions are real, so handle them appropriately, and restore the turned off P0 pixels no matter what.

 

I think I just need to worry about P0 player moving into contact with a new set of playfield pixels (using subpixel movement of .75 or less, so shouldn't be an issue in between 2 frames.)

Edited July 29, 2020 by CapitanClassic