+Random Terrain Posted July 13, 2009 Share Posted July 13, 2009 After I'm done with my adapted version of Robert M's joystick example, I'll see how fast I can get this maze game cleaned up enough to show it to others. What playfield resolution did you use? The plain old regular one: http://www.atariage.com/forums/index.php?showtopic=133068 Quote Link to comment Share on other sites More sharing options...
satyrsfaction Posted February 28, 2020 Share Posted February 28, 2020 OK, i still don't have a handle on this. my playfield is 30 playfield pixels high, and I'm using the ball as my player -- it's 6 pixels tall by 4 wide. since the the playfield is 88 tall, that means i'd be dividing by roughly 3, right? when I put in that value I get this: --- Unresolved Symbol List div8 0000 ???? (R ) Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted February 28, 2020 Share Posted February 28, 2020 7 minutes ago, satyrsfaction said: OK, i still don't have a handle on this. my playfield is 30 playfield pixels high, and I'm using the ball as my player -- it's 6 pixels tall by 4 wide. since the the playfield is 88 tall, that means i'd be dividing by roughly 3, right? when I put in that value I get this: --- Unresolved Symbol List div8 0000 ???? (R ) Take a look at this: randomterrain.com/atari-2600-memories-batari-basic-commands.html#multiplication Quote Link to comment Share on other sites More sharing options...
satyrsfaction Posted February 28, 2020 Share Posted February 28, 2020 is there a difference if you're using DCP+? i tried it again, and it compiled, but it still doesn't seem to be working right. I have it drawing a playfield pixel, and its still way off from the player's position. Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted February 28, 2020 Share Posted February 28, 2020 50 minutes ago, satyrsfaction said: is there a difference if you're using DCP+? i tried it again, and it compiled, but it still doesn't seem to be working right. I have it drawing a playfield pixel, and its still way off from the player's position. I looked back at one of my old test programs and when I was playing around with 88 rows with DPC+, these are the numbers I ended up using: _Convert_X = (player0x-13)/4 _Convert_Y = (player0y+player0height-1)/4 Those numbers may not be perfect since I switched to a different resolution and didn't continue playing around with 88 rows. I switched to 22 rows that are 8 scanlines high in my Fake Gravity Platformer Test and used these numbers: _Convert_X = (player0x-13)/4 _Convert_Y = (player0y+player0height)/8 If I remember correctly, the numbers change depending on the direction the player moves (when using collision prevention), so you have to play around with pfpixel until you get it working right. Quote Link to comment Share on other sites More sharing options...
Lillapojkenpåön Posted February 29, 2020 Share Posted February 29, 2020 3 hours ago, satyrsfaction said: OK, i still don't have a handle on this. my playfield is 30 playfield pixels high, and I'm using the ball as my player -- it's 6 pixels tall by 4 wide. since the the playfield is 88 tall, that means i'd be dividing by roughly 3, right? when I put in that value I get this: --- Unresolved Symbol List div8 0000 ???? (R ) If you make a new project with just your playfield and movable ball and post that it would be easier to help Quote Link to comment Share on other sites More sharing options...
satyrsfaction Posted February 29, 2020 Share Posted February 29, 2020 1 hour ago, Lillapojkenpåön said: If you make a new project with just your playfield and movable ball and post that it would be easier to help test.bas.bin test.bas Quote Link to comment Share on other sites More sharing options...
Lillapojkenpåön Posted February 29, 2020 Share Posted February 29, 2020 use pfpixels like this to find the pixel above, below, to the left of and to the right of temp5 = (ballx - 9)/4 temp6 = (bally + 14)/8 pfpixel temp5 temp6 on I also made some examples a while ago, but they are for the standard kernel, in the standard kernel playery is the bottom of the player, and the top would be playery - playerheight, so not like the DPC+ kernel, but left and right is probably the same, so it might be useful. 1 Quote Link to comment Share on other sites More sharing options...
satyrsfaction Posted February 29, 2020 Share Posted February 29, 2020 thank you everyone for your help. 1 Quote Link to comment Share on other sites More sharing options...
satyrsfaction Posted February 29, 2020 Share Posted February 29, 2020 18 hours ago, Lillapojkenpåön said: use pfpixels like this to find the pixel above, below, to the left of and to the right of temp5 = (ballx - 9)/4 temp6 = (bally + 14)/8 pfpixel temp5 temp6 on I also made some examples a while ago, but they are for the standard kernel, in the standard kernel playery is the bottom of the player, and the top would be playery - playerheight, so not like the DPC+ kernel, but left and right is probably the same, so it might be useful. ok, I'm confused ... when i put in your numbers and use pfpixel, the pixel appears way to the right and up from the player position. Shouldn't it be right on top of it? Or am I just not understanding this at all? Quote Link to comment Share on other sites More sharing options...
Lillapojkenpåön Posted February 29, 2020 Share Posted February 29, 2020 6 minutes ago, satyrsfaction said: ok, I'm confused ... when i put in your numbers and use pfpixel, the pixel appears way to the right and up from the player position. Shouldn't it be right on top of it? Or am I just not understanding this at all? Really? It appeared right to the right of the ball for me, but yeah, it's a good way to see when your calculation is in the right ballpark Quote Link to comment Share on other sites More sharing options...
orange808 Posted February 29, 2020 Share Posted February 29, 2020 Does anybody remember the exact x and y (relative to object coordinates) where the playfield starts and stops drawing? That's what you need to make a formula. Also, I would drop to ASM to make that calculation. Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted February 29, 2020 Share Posted February 29, 2020 18 minutes ago, satyrsfaction said: ok, I'm confused ... when i put in your numbers and use pfpixel, the pixel appears way to the right and up from the player position. Shouldn't it be right on top of it? Or am I just not understanding this at all? Are you using the latest version of batari Basic? https://github.com/batari-Basic/batari-Basic/releases Quote Link to comment Share on other sites More sharing options...
Lillapojkenpåön Posted February 29, 2020 Share Posted February 29, 2020 (edited) 2 hours ago, orange808 said: Does anybody remember the exact x and y (relative to object coordinates) where the playfield starts and stops drawing? That's what you need to make a formula. Also, I would drop to ASM to make that calculation. there's four pfpixels missing at each side, and each pfpixel is four regular pixels right? so guess it starts drawing pf at the 17th for x and 0 for y? to get the pfpixel for an objects x and y I think it's (player0y)/8 (player0x - 17)/4 atleast if the resolution is 11 rows and y is at the top of the object EDIT: Oh, all of these numbers are on the previous page in much more detail Edited March 1, 2020 by Lillapojkenpåön Quote Link to comment Share on other sites More sharing options...
orange808 Posted March 1, 2020 Share Posted March 1, 2020 (edited) X is the tricky part. Use this: lda xcoordinate and #252 clc sbc #15 clc ror clc ror sta pfpixelx That takes care of x. Now, for y... Try setting the total playfield lines (AKA the vertical axis or y axis) to something you can easily handle. There are 176 lines and (unlike the x axis) they all map directly to a y coordinate that you also use to position objects (objects are the players, missiles, and the ball). So, when you set the DF0FRACINC, DF1FRACINC, DF2FRACINC, and DF3FRACINC, start out using even multiples of 176. Don't set the total amount of lines to something that doesn't evenly multiply into 176. This could be said another way: if you divide 176 by the total amount of lines, there should be no remainder. There is a chart here: https://www.randomterrain.com/atari-2600-memories-batari-basic-commands.html#dpc_playfield_resolution Use that. Simple multiplication will get you the y coordinate. Now, you can use pfread to get what you need. Edited March 1, 2020 by orange808 More clarity. Fix link. Fixed code. First one stepped in 16 when it needed to step by 4. Quote Link to comment Share on other sites More sharing options...
satyrsfaction Posted March 1, 2020 Share Posted March 1, 2020 OK, serious offer. I'm finding this extremely frustrating. What would it take to get someone to just figure this out for me so I can get back to the fun part? Quote Link to comment Share on other sites More sharing options...
orange808 Posted March 1, 2020 Share Posted March 1, 2020 2 minutes ago, satyrsfaction said: OK, serious offer. I'm finding this extremely frustrating. What would it take to get someone to just figure this out for me so I can get back to the fun part? PM me. 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.