Jump to content
jrok

PF pixels-to-Sprite pixels?

Recommended Posts

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

Share this post


Link to post
Share on other sites

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 )

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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

 

 

Share this post


Link to post
Share on other sites

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.

 

  • Like 1

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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 by Lillapojkenpåön

Share this post


Link to post
Share on other sites
Posted (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 by orange808
More clarity. Fix link. Fixed code. First one stepped in 16 when it needed to step by 4.

Share this post


Link to post
Share on other sites

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? 

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...