6 replies to this topic

[zhinchliffe]

I want to test collision of a certain x,y value with the playfield. i am making a platform game and want to "push" the player out in a direction if he gets stuck inside a platform, but the direction needs to be determined by which section of the player is embedded in the platform.

Edited by zhinchliffe, Thu Jul 31, 2008 8:45 PM.

[Random Terrain]

Maybe what you discovered could help somebody else. What was the solution to your problem?

[zhinchliffe]

i'm just using pfread now. i didn't know it existed beforehand.

edit: so pfread is not what I was looking for after all, because it calculates in playfield blocks rather than onscreen pixels. so hepl plox

Edited by zhinchliffe, Thu Jul 31, 2008 4:23 PM.

[zhinchliffe]

 rem fall if not touching ground
 if !pfread(b,l) then player0y = player0y + 1

 rem push left if in right wall
 if pfread(k,m) then player0x = player0x - 1

 rem push right if in left wall
 if pfread(j,m) then player0x = player0x + 1

i need to figure out what variables b, j, k, l, and m are in playfield blocks.

b should be the playfield equivalent of player0x+4
l should be the playfield equivalent of player0y+7
k should be the playfield equivalent of player0x+8
m should be the playfield equivalent of player0y+3
j should be the playfield equivalent of player0x

help a brother out!

EDIT: unless there's an easier way to detect collision with the playfield at a specific point - i'd love to hear it.

Edited by zhinchliffe, Thu Jul 31, 2008 7:35 PM.

[Random Terrain]

You can put a playfield pixel on the screen, then put up a sprite and with a couple of minutes of trial and error, you can line them up perfectly, then you'll know the x and y differences between your sprites and the playfield. Once you know that, you'll know what to use with pfread. Then you'll be able to do things like make a Pac-Man rip-off where your Pac-Man never touches or scrapes against walls and never changes shape and direction unless there is an opening.

[SeaGtGruff]

zhinchliffe, on Thu Jul 31, 2008 9:10 PM, said:

 rem fall if not touching ground
 if !pfread(b,l) then player0y = player0y + 1

 rem push left if in right wall
 if pfread(k,m) then player0x = player0x - 1

 rem push right if in left wall
 if pfread(j,m) then player0x = player0x + 1

i need to figure out what variables b, j, k, l, and m are in playfield blocks.

b should be the playfield equivalent of player0x+4
l should be the playfield equivalent of player0y+7
k should be the playfield equivalent of player0x+8
m should be the playfield equivalent of player0y+3
j should be the playfield equivalent of player0x

help a brother out!

EDIT: unless there's an easier way to detect collision with the playfield at a specific point - i'd love to hear it.

It would depend on which version of bB you're using, and which kernel you're using, since the equivalent numbers aren't the same for all versions and all kernels.

Assuming you're using bB 1.0 (as opposed to, say, 0.35 or before), and the standard kernel (as opposed to the multisprite kernel), then player0x would be 1 at the leftmost edge of the screen, which is the leftmost edge of PF0 (left copy). But PF0 isn't used in the standard kernel, so you want the leftmost edge of PF1, which should correspond to player0x = 17. Keep in mind that 1 playfield pixel is as wide as 4 player pixels (unless you're using double-wide or quadruple-wide players), so that means pfpixel 0 (1st pixel of PF1) spans player0x 17, 18, 19, and 20. Then pfpixel 1 spans player0x 21, 22, 23, and 24. And so on for the rest of the pfpixels. So...

"b should be the playfield equivalent of player0x+4"

b = 0 would be equivalent to player0x+4 when player0x = 13, 14, 15, and 16
b = 1 would be equivalent to player0x+4 when player0x = 17, 18, 19, and 20
b = 2 would be equivalent to player0x+4 when player0x = 21, 22, 23, and 24
etc.

b = (player0x - 13) / 4

"k should be the playfield equivalent of player0x+8"

k = 0 would be equivalent to player0x+8 when player0x = 9, 10, 11, and 12
k = 1 would be equivalent to player0x+8 when player0x = 13, 14, 15, and 16
k = 2 would be equivalent to player0x+8 when player0x = 17, 18, 19, and 20
etc.

k = (player0x - 9) / 4

"j should be the playfield equivalent of player0x"

j = 0 would be equivalent to player0x when player0x = 17, 18, 19, and 20
j = 1 would be equivalent to player0x when player0x = 21, 22, 23, and 24
j = 2 would be equivalent to player0x when player0x = 25, 26, 27, and 28
etc.

j = (player0x - 17) / 4

For converting player0y to a pfpixel row number, you need to keep in mind that each pfpixel is 8 player pixels tall, and the first player pixel line is 1. So...

"l should be the playfield equivalent of player0y+7"

l = 0 would be equivalent to player0y+7 when player0y = -7, -6, -5, -4, -3, -2, -1, and 0
l = 1 would be equivalent to player0y+7 when player0y = 1, 2, 3, 4, 5, 6, 7, and 8
l = 2 would be equivalent to player0y+7 when player0y = 9, 10, 11, 12, 13, 14, 15, and 16
etc.

l = (player0y + 7) / 8

"m should be the playfield equivalent of player0y+3"

m = 0 would be equivalent to player0y+3 when player0y = -3, -2, -1, 0, 1, 2, 3, and 4
m = 1 would be equivalent to player0y+3 when player0y = 5, 6, 7, 8, 9, 10, 11, and 12
m = 2 would be equivalent to player0y+3 when player0y = 13, 14, 15, 16, 17, 18, 19, and 20
etc.

m = (player0y + 3) / 8

I *think* those would be the right formulas, but you'll need to try them out, and adjust the formulas a bit if they're off.

Michael

Edited by SeaGtGruff, Thu Jul 31, 2008 8:11 PM.

[zhinchliffe]

all the player0x calculations are correct, but the y calculations see to be about 7 pixels too high. but when I try to subtract (or add, but i think it's subtract) 7, the collision detection just completely gets thrown out the window and goes crazy.

edit: nm figured it out. THANKS!!

Edited by zhinchliffe, Thu Jul 31, 2008 8:45 PM.