PF pixels-to-Sprite pixels?

[+Random Terrain]

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

[satyrsfaction]

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 )

[+Random Terrain]

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

[satyrsfaction]

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.

[+Random Terrain]

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.

[Lillapojkenpåön]

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

 

 

[satyrsfaction]

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

[Lillapojkenpåön]

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.

 

[satyrsfaction]

thank you everyone for your help.

[satyrsfaction]

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?

[Lillapojkenpåön]

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

[orange808]

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.

[+Random Terrain]

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

[Lillapojkenpåön]

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

[orange808]

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.

[satyrsfaction]

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? 

[orange808]

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.