IGNORED

Playfield math question

Recommended Posts

Seeing as how I just completed a term of college level algebra I probably should be able to figure this out, but I can't. In the sample program draw.bas to place a playfield pixel where the sprite is, these calculations are used:

g=(player0y-7)/3

h=(player0x-10)/4

Now this is for a 32x32 playfield. What needs to be changed to make this code work with a 32x11 screen? Thanks.

Share on other sites

Seeing as how I just completed a term of college level algebra I probably should be able to figure this out, but I can't. In the sample program draw.bas to place a playfield pixel where the sprite is, these calculations are used:

g=(player0y-7)/3

h=(player0x-10)/4

Now this is for a 32x32 playfield. What needs to be changed to make this code work with a 32x11 screen? Thanks.

Yow, that can depend on which kernel you're using and which player you're talking about. Are you talking about the standard kernel?

Michael

Share on other sites

h remains the same.

g=(player0y-7)/{3x(32/11)}

Share on other sites

Seeing as how I just completed a term of college level algebra I probably should be able to figure this out, but I can't. In the sample program draw.bas to place a playfield pixel where the sprite is, these calculations are used:

g=(player0y-7)/3

h=(player0x-10)/4

Now this is for a 32x32 playfield. What needs to be changed to make this code work with a 32x11 screen? Thanks.

It's really 32x12, with the last row hidden. Typically for a standard-height playfield, you divide by 8, e.g.:

g=(player0y-7)/8

The 7 may or may not be correct depending on your sprite height. Also important is what pixel of the sprite should be associated with a playfield pixel (in draw.bas, it's the tip of the arrow cursor, but in a game it might be a pixel in the center.) For that matter, the 10 in the equation for h may vary for this same reason (and sprite width.)

Personally, I find these values by trial and error instead of trying to figure them out.

Edited by batari
Share on other sites

For the standard kernel, I believe the x coordinates range from 1 to 160 for both players:

player0x = 1 will put the leftmost pixel (bit 7) of the player sprite in the leftmost color clock of the visible screen area (i.e., not counting the 68 color clocks that occur within the horizontal blanking period).

player0x = 160 will put the leftmost pixel of the player sprite in the rightmost color clock of the visible screen area (which means the other 7 pixels of the player sprite will be wrapped around to the left side of the screen).

So to convert the player0x coordinate to a pfpixel column, you would need pfcol = (p0x - 1) / 4. Of course, the first four playfield pixels (i.e., PF0) aren't used by bB's playfield, so using that formula, a pfcol value of 0 would actually be the leftmost pixel of PF0, so you would need to modify the formula to be pfcol = (p0x - 1) / 4 - 4. That means some p0x values would give you "illegal" pfcol values.

Off the top of my head, I don't remember the y value for the topmost line, but if I remember correctly, the height of the player sprite makes a difference, and the y coordinate gives the position of the bottom line of the player sprite.

For the multisprite kernel, things work differently.

player0x ranges from 0 to 159. (Yea!)

However, player1x through player5x range from 8 to 167. That is, if you set player0 and player1 to identical shapes, and you want to position them at the same horizontal positions (but let's just say that they're going to be at different vertical positions, so they're above and below each other, but not on top of each other), then you could do player0x = 40, and player1x = player0x + 8, and they would be lined up. But if you did player1x = player0x, then player1 would be 8 color clocks to the right of player0.

So the formulas for the multisprite kernel would be as follows:

pfcol = p0x / 4 - 4

pfcol = (p1x - 8 ) / 4 - 4 (also for p2x, p3x, p4x, and p5x)

Additionally, note that this is just for the left playfield pixel. Depending on the width of the player-- 8 color clocks, 16 color clocks, or 32 color clocks-- the player may straddle more than one playfield pixel.

Now, for the y coordinates I do remember a little about them, because I've been working on a game that uses the multisprite kernel. First of all, the y coordinates go bottom-to-top instead of top-to-bottom, as in the standard kernel. Also, the player sprites don't begin to display "properly" at the same lines-- by which I mean, the player0 sprite will begin to show up at p0y = 91, whereas the player1 (2,3,4,5) sprite will not begin to show up until p1y = 84. Further, the y values do not correspond to each other, just as the x values differ by 8. For y, the difference is 3-- that is, p0y = 87 and p1y = 84 will put player0 and player1 on the same lines, or p1y = p0y - 3.

Also, since player0 begins to show up at p0y = 91, that would correspond to p1y = 88-- except that player1 doesn't start to show until p1y = 84, so you can't position player1 (2,3,4,5) as high up on the screen as you can player0.

As with the standard kernel, the player height affects the vertical positioning, but in this case the y value determines where the topmost line of the player will be. Consequently, the lowest possible y position will depend on the height of the player. For a player that is only 1 line high, p0y = 5 is as low as you can go, and p1y = 3 is as low as you can go.

Now, I'm not sure which y values correspond to which playfield rows, but I'll check later.

Michael

Edited by SeaGtGruff
Share on other sites

Thank you for your responces so far. As for what playfield I'm using it's the default 32x12 playfield.

I'm asking about this because while trying to work on my final version of Tron I am having a horrible time trying to draw a light wall behind the light cycles as they drive. I was about to give up as I have been spending weeks on the problem and allways comming close to, but not being completely sucessful, until I thought about the draw program and figured that maybe I could give that a try.

As for the sprite, the light cycles are 6 pixels high and 6 pixels wide. Here are a couple of pics to show what they look like.

Edited this post to add that I'm using the standard kernel in answer to SeaGtGruff's question.

Edited by jbs30000
Share on other sites

Actually, it looks like taking batari's advice about dividing the y position by 8 instead of 3 and then working on the values to add or subtract inside the parenthesise is working out fairly well. Thanks.

Edited by jbs30000

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.

×   Pasted as rich text.   Paste as plain text instead

Only 75 emoji are allowed.