IGNORED

# Mapping screen coordinates to screen buffer.

## Recommended Posts

Has anyone come up with a good formula for translating PM screen coordinates to position in the character buffer array and vice-versa?

Below are some notes I made on the subject for my breakout clone (this is in graphics mode 17), but it's still a little off.

The top line of the topmost brick is y=16. The bottom of that brick is at y=20.
The bottom line of the lowest brick is y=40
The left edge of the playfield is x=42 the left side is x=210
46 is the left edge of the brick, 61 is the right side.
The right side of the last brick is 205
Each brick has a width of 15. (possibly 16? The bricks are two characters)
Each row is 10 bricks or 20 characters long.
There are 6 rows of bricks.

So take all together:
The four corners of the bricks:
NW: 46,16   NE: 205,16
SW: 46,40   SE: 205,40

Width of bricks: 159
Height of bricks: 24
Each brick is 15 wide and 4 tall.
46 + (159/)
100,25: where am I?
100-46 = 54 -> 54/15 = 3 -> column 3
25-16 = 9 -> 9/4 = ~1: Row 2
(it's actually column 4, bottom of row 2)

49,15 is brick 0,0.
49-46 = 3 /0 = Column 0
18 - 16 = 2 / 0 = Row 0
Column is zero-indexed, but row is not?

Edited by kensu
##### Share on other sites

Since the screen architecture is highly variable it can change depending on setup.

If you're using assembly, calculations can be done with combination of add/subtract and bit shifting.

I did a Breakout game in 1984, from memory I used that sort of methodology.   I don't think I bothered using collision detection.  In some cases especially with the physics you use for Breakout, it's not especially useful anyway.

For your PM coords for ball at least you might get away with using playfield relative values which translate easier to brick values.  Brick value might be 8 multicolour pixels wide and 4 pixels high.

Feel free to reverse-engineer it.  There's a mix of Basic + Asm, it was my first or second ever 6502 project so a bit scrappy.  For whatever reason I think I actually used a mix of immediate and deferrered VBlank not to mention mix of Basic and assembly doing the work.

The source code is long lost so you'd have to load into emulator and list the code.  I don't think it's really long so should be easy to work out.

##### Share on other sites

The authoritative source for coordinates is the chart from the Atari Hardware Manual:

The OS creates hardware screens that are normal/standard width and 192 scan lines high, with 24 scan lines at the top. Vertically, the first scan line is numbered at 8. If you are using VCOUNT values or two-line P/M resolution, divide by 2 -- screen starts at Y=16.

Horizontally, the normal width screen starts at 48 color clocks and ends at 48 + 160 = 208. If you set a player's horizontal position to 48, then its left edge will be aligned with the left edge of the playfield.

##### Share on other sites

I coded such solution just today (for binary parasite game). I think you cannot simply take general solution, because it may not cover the needs.

Of course there are some bounds written in the manual, but important is how you use them in your game.

It's fairly easy to calculate collision of 1px pmg vs char, because you will always end up with 1 char. However once your pmg is not a single pixel you have to check multiple chars because the player can overlap 4,6 or even more chars depending on the PM size. Then it is important the direction so then you know if the PM touched the char from the top or from the bottom (or left/right + all the combinations).

In case of breakout, depending on that you can decide where the ball bounces and which brick disappears.

+There also might be velocity in the game that can complicate things.

The best way to deal with this is to write a debug procedure that allows you pixel precise control of the "projectile" with 2nd joystick (i did it that way) and copy calculated char to top left corner of VRAM.

This way you can thoroughly test the collisions and perform the tweaking of the constants that you are looking for.

##### Share on other sites

In this case I really just need to determine the scanline so I can enable the DLI to change the PM color register. The one I'm trying at this moment is: (MYPMBASE+YPOS+512)/4, with those variable having their most common meanings. Doesn't seem to be working, though. There's plenty of reasons why that might be, though.

##### Share on other sites

Don't include the 512 offset in the division.

## 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.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

Only 75 emoji are allowed.