zhinchliffe Posted July 31, 2008 Share Posted July 31, 2008 (edited) 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 August 1, 2008 by zhinchliffe Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted July 31, 2008 Share Posted July 31, 2008 Maybe what you discovered could help somebody else. What was the solution to your problem? Quote Link to comment Share on other sites More sharing options...
zhinchliffe Posted July 31, 2008 Author Share Posted July 31, 2008 (edited) 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 July 31, 2008 by zhinchliffe Quote Link to comment Share on other sites More sharing options...
zhinchliffe Posted August 1, 2008 Author Share Posted August 1, 2008 (edited) 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 August 1, 2008 by zhinchliffe Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted August 1, 2008 Share Posted August 1, 2008 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. Quote Link to comment Share on other sites More sharing options...
SeaGtGruff Posted August 1, 2008 Share Posted August 1, 2008 (edited) 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 August 1, 2008 by SeaGtGruff 1 Quote Link to comment Share on other sites More sharing options...
zhinchliffe Posted August 1, 2008 Author Share Posted August 1, 2008 (edited) 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 August 1, 2008 by zhinchliffe Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.