Jump to content

Photo

New pacman for atari 2600


1483 replies to this topic

#1476 Kosmic Stardust ONLINE  

Kosmic Stardust

    Princess Rescuer

  • 17,870 posts
  • Location:Milky Way Galaxy

Posted Mon Aug 6, 2018 12:18 AM

I hope I'm not getting too far ahead of myself, but could we ever see a Pac-Man Collection for the 2600? With Ms.Pac-Man and Pac-Man Plus and any other variants? It would be the definitive Pac Pack for the VCS in my book!!!!

Don't firget about havkem and ms hackem... ;-)

Pacman Collection for the 7800 simply reused the same engjne for all mazes with subtle tweaks between pacman and ms pacman modes.

Atari Pacman, Atari Ms Pacman, Hack em, ms hackem, Pacman arcade (ms pacman hack), debro pacman 4k, dintar new pacman 8k, that's seven right there.

#1477 DZ-Jay OFFLINE  

DZ-Jay

    Quadrunner

  • 11,297 posts
  • The P-Machinery AGE is almost here!
  • Location:NC, USA

Posted Mon Aug 6, 2018 5:19 AM

Hello, I'm working on this again and recently I've been making changes in the movement routine, now the objects are moving much faster, in the test I'm doing you can switch between normal and fast with the left difficulty switch.

With that change I made, it is much simpler to do the "cut corner", I am doing tests and I think it could work, although only advancing up to 2 pixels diagonally for now, the DZ-jay method is interesting, although I still don't  know how It works, neither know if I can do something similar here.

Soon I will be publishing a test version. ;-) 

Well, I know I have not written for a long time, I apologize for that, I'll try to be more active now. ;-)

 

 

Hi, DINTAR816,

 

My method is to use a look-up table for the movement deltas, rather than to just move in the direction of travel.

 

My algorithm is implemented in two parts:

  • First, the normal "move sprite" routine that runs on every frame, which follows the direction of travel.  It uses a look-up table indexed by Pac-Man's position within his current tile.
  • Second, the "update sprite direction" routine which runs when new input is detected.  It checks whether there is an exit towards the new direction and updates the current direction of travel if there is.  Otherwise, it keeps track of the new direction until the joystick is released.  It also updates the sprite's state to "moving," in case it was at rest.

We use a few variables to track state:

  • DirCurr - The current (valid) direction of travel.
  • DirNext - The next direction of travel, that is, the new direction the player pressed on the Joystick before it's accepted.
  • State - The state of the sprite (e.g., Moving, Rest, Dead, etc.)

Directions are tracked in a 4-bit vector that tells whether the sprite is moving Up (N), Right (E), Down (S), or Left (W).

 

Also, there are two coordinate systems to track:

  • Sprite absolute position - this is the (X, Y) coordinates of the sprite object on the screen, with the origin at the top-left corner of the screen.

    Stic_object_field_1.png
     
  • Maze virtual tile - this is the effective tile in which the sprite is at any moment.  Virtual tiles are the logical tiles in which sprites move and interact.  They are either open corridors or walls, just like in Pac-Man.  In Pac-Man they are 8x8 pixels, but in my game they are only 4x4 pixels since sprites are 8x8.  For example:

    tilemove2.png

    tilegame.png
     

All maze objects, targets, exits, etc. are tracked in virtual tile coordinates.  Translating between the sprite's absolute coordinates and virtual tile coordinates is a simple function.

 

There are also two major data tables:

  • Exit vector - a 4-bit vector indicating the exit/junction arrangement of every single virtual tile in the effective (i.e., traversable) play area.  These are packed into 4 per 16-bit data word.

    The Exit Vector is aligned with the sprite's direction vector so that checking if the current direction has an open exit is just a matter of masking with an AND operation.
; The format for each 4-bit vector is as follows:
;
;     3   2   1   0
;   +---+---+---+---+
;   | < | v | > | ^ |
;   +---+---+---+---+
;     ^   ^   ^   ^
;     |   |   |   |
;     |   |   |   `--------> Allow Up
;     |   |   `------------> Allow Right
;     |   `----------------> Allow Down
;     `--------------------> Allow Left
  • Move delta - A 64 record list of all possible movements available on a 4x4 pixel virtual tile.  The virtual tile has 16 possible position in which the sprite can be, and from each of those positions, the table offers to which target pixel the sprite can move for each of the possible directions (North, South, East, West).  16-positions x 4-directions = 64 possible deltas.
;                        |
;                        v
;
;           -1           0          1          2
;       +----------+----------+----------+----------+
;       |          |          |          |          |
;       |          |          |          |          |
;    -2 | (-1, -2) | ( 0, -2) | ( 1, -2) | ( 2, -2) |
;       |          |          |          |          |
;       |          |          |          |          |
;       +----------+----------+----------+----------+
;       |          |          |          |          |
;       |          |          |          |          |
;    -1 | (-1, -1) | ( 0, -1) | ( 1, -1) | ( 2, -1) |
;       |          |          |          |          |
;       |          |          |          |          |
;       +----------+----------+----------+----------+
;       |          |          |          |          |
;       |          |  ORIGIN  |          |          |
;  -> 0 | (-1,  0) | ( 0,  0) | ( 1,  0) | ( 2,  0) |  <-
;       |          |          |          |          |
;       |          |          |          |          |
;       +----------+----------+----------+----------+
;       |          |          |          |          |
;       |          |          |          |          |
;     1 | (-1,  1) | ( 0,  1) | ( 1,  1) | ( 2,  1) |
;       |          |          |          |          |
;       |          |          |          |          |
;       +----------+----------+----------+----------+
;
;                        ^
;                        |

If you use the diagram above for illustration, then you can see that "corner-cutting" is merely done by mapping some of the positions in the tile to diagonal targets.  For example, if the player pressed "Up" from positions (2, 0) we translate him to position (1, -1).  If he presses up again (or continues to press it), then from positions (1, -1) we translate him to position (0, -2).  Continuing to press "Up" from that point will just translate normally from (0, -2) to (0, -3), which actually is position (0, 1) on the bottom of the next tile above.

 

Obviously, movements in the center-line are mapped directly to an adjacent position.  For example:  If Pac-Man is again at position (2, 0) and the player pressed "Left" (or is already going in that direction), we translate him to position (1, 0) which is just the pixel to the left.

 

In each case, the translation is just the delta to add to each coordinate in order to land in the target position.  In other words,

  Source (2, 0) -> Target: (1, 0)   =   (2, 0) + (-1, 0)

 

 

Below is a description of the movement algorithm:

 

1. Move Sprite:  This is executed on every frame.

  • Skip if sprite state is "Not Active" or "Dead" or "At Rest."
  • Compute velocity and see if we need to move.
  • Get Exit Vector from look-up table:
    • Get sprite's absolute coordinates
    • Compute virtual tile coordinate
    • Use virtual tile coordinate as index into Exit Vector Table.
  • Check if the DirCurr has a corresponding valid exit in the Exit Vector.
    • If there is, continue movement routine.
    • If not, check if the sprite is at the center of the tile:
      • If it is:  set sprite State = "At Rest"; exit routine.
      • If it isn't, continue movement routine
      • (Pac-Man will move towards a wall until it reaches the center of the tile)
  • Get current delta movement entry from Move Delta Table
    • Note: this is the encoding in my program, sorted by direction.  It will give a number from 0 to 63.
    • Use that number as an index into the Move Delta Table (which was explained in a previous post).
    • The deltas are encoded in two bytes (X,Y), with the upper one representing the delta for the X axis.
; Compose delta table index:
;           5   4   3   2   1   0
;    ..//-+---+---+---+---+---+---+
;         | D | D | X | X | Y | Y |
;    ..//-+---+---+---+---+---+---+
;          \_____/ \_____/ \_____/
;             |       |       |
;            Dir      X       Y
; The X and Y offsets are packed in ROM on a single 16-bit word:
;
;   (-1, -1): $FFFF     ; X: -1, Y: -1
;   ( 0, -1): $0200     ; X:  0, Y: -1
;   ( 0,  0): $0000     ; X:  0, Y:  0
;
;     F   E   D   C   B   A   9   8   7   6   5   4   3   2   1   0
;   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
;   |             X Offset          |            Y Offset           |
;   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
  • Add the deltas to the sprite's current absolute position.
  • Test new position for tunnels and roll-over to other side if necessary.

 

2. Update Sprite Direction:  This is executed "on-demand," when new input is detected.

  • Get Exit Vector from Exit Vector Table:
    • Get sprite's absolute coordinates
    • Compute virtual tile coordinate
    • Use virtual tile coordinate as index into Exit Vector Table.
  • Check if the DirNext has a corresponding valid exit in the Exit Vector.
    • If not, keep DirNext and exit routine.  We keep DirNext in order to compare the next time we poll for new input to see if it changed.  If the input doesn't change, there's no need to re-compute.
    • If yes update state:
      • Sprite State = "Moving"
      • DirCurr = DirNext
      • Change sprite orientation (so that it faces new exit direction)

 

Whenever the "Update Sprite Direction" event changes the DirCurr, it will be picked up on the next frame when executing the "Move Sprite" routine.

 

I hope this offers some clarity.  I am willing to explain further if you or anybody is interested and to offer some code -- although all my code is for the CP-1610 CPU of the Intellivision, and I'm afraid I am not very familiar with the MOS-6502.  I can offer pseudo-code if desired.

 

     -dZ.


Edited by DZ-Jay, Mon Aug 6, 2018 5:37 AM.


#1478 DZ-Jay OFFLINE  

DZ-Jay

    Quadrunner

  • 11,297 posts
  • The P-Machinery AGE is almost here!
  • Location:NC, USA

Posted Mon Aug 6, 2018 5:54 AM

One other remark to the above is that I have the freedom on the Intellivision to trade storage for performance, because the CPU and ROM data is 16-bits and there is plenty of ROM available.

 

I don't do any VCS programming, but I am aware that it is only an 8-bit processor and that cartridge ROM is fairly small (compared to the Intellivision).  In my case, it becomes very useful and practical to pre-compute exit vectors and movement delta's in data tables and pack them in 16-bit data words.  Your mileage may vary quite a bit.

 

For instance, you probably will have to pack everything in byte-size data.  Thus, my 64 record movement delta table becomes 128 bytes, where two bytes are used to encode the delta for a tile, one for each coordinate (X, Y).

 

Also, my exit vector table uses 157 16-bit words to store 627 x 4-bit virtual tiles for the maze (the virtual map is actually 43 x 29, but we only store the "effective" map which is 33 x 19, without the outside border and walls, since they are not traversable.)

 

If you use a similar resolution to mine, you will have to pack 2 x 4-bit exit vectors per byte, resulting in a table of 313 bytes.  That's quite a bit, although I personally recommend it if you can afford it.

 

     -dZ.


Edited by DZ-Jay, Mon Aug 6, 2018 5:56 AM.


#1479 DINTAR816 OFFLINE  

DINTAR816

    Star Raider

  • Topic Starter
  • 59 posts

Posted Wed Oct 10, 2018 11:41 PM

Hello, here I am again, after 2 months, here is the test version with "cornerig" (finally!), it works fine (I think), I just need to improve it a bit.
 
DZ-jay, your method is difficult to apply here because it would require a lot of rom (many tables) for example I would need 4 times more rom for the "move delta" table (that is, 256), since my method uses 8 x 8 virtual tiles , thank you anyway for the detailed explanation, since it inspired me to make this possible.
 
Now it is also possible to increase the speed of the game with the right switch (in the "A" position the speed increases).
 
Enjoy. :)
 

Attached Files



#1480 Arenafoot OFFLINE  

Arenafoot

    Stargunner

  • 1,207 posts
  • videogamestores.net
  • Location:Watson, LA

Posted Thu Oct 11, 2018 12:09 AM

 

Hello, here I am again, after 2 months, here is the test version with "cornerig" (finally!), it works fine (I think), I just need to improve it a bit.
 
DZ-jay, your method is difficult to apply here because it would require a lot of rom (many tables) for example I would need 4 times more rom for the "move delta" table (that is, 256), since my method uses 8 x 8 virtual tiles , thank you anyway for the detailed explanation, since it inspired me to make this possible.
 
Now it is also possible to increase the speed of the game with the right switch (in the "A" position the speed increases).
 
Enjoy. :)
 

 

I love this version! Thanks DINTAR816!



#1481 DZ-Jay OFFLINE  

DZ-Jay

    Quadrunner

  • 11,297 posts
  • The P-Machinery AGE is almost here!
  • Location:NC, USA

Posted Thu Oct 11, 2018 4:20 AM

 

Hello, here I am again, after 2 months, here is the test version with "cornerig" (finally!), it works fine (I think), I just need to improve it a bit.
 
DZ-jay, your method is difficult to apply here because it would require a lot of rom (many tables) for example I would need 4 times more rom for the "move delta" table (that is, 256), since my method uses 8 x 8 virtual tiles , thank you anyway for the detailed explanation, since it inspired me to make this possible.
 
Now it is also possible to increase the speed of the game with the right switch (in the "A" position the speed increases).
 
Enjoy. :)
 

 

 

Ah! No worries.  I was afraid of that.  In the Intellivision I have a lot more ROM to play with, so I traded it off rather than having to compute the diagonal positions, which would have been another option.

 

I'm glad you got it working, though.  To me, cornering is one of the definitive characteristics of the real Pac-Man game, so implementing it goes a long way in retaining the feel of the original.  :thumbsup:

 

    -dZ.



#1482 Dionoid OFFLINE  

Dionoid

    Star Raider

  • 93 posts
  • Location:Leiden, Netherlands

Posted Thu Oct 11, 2018 5:18 PM

Amazing good version of Pac-Man for the '2600!!! Thanks!



#1483 Brian O OFFLINE  

Brian O

    Stargunner

  • 1,634 posts
  • [THIS SPACE FOR RENT]

Posted Thu Oct 11, 2018 7:51 PM

 

Hello, here I am again, after 2 months, here is the test version with "cornerig" (finally!), it works fine (I think), I just need to improve it a bit.
 
DZ-jay, your method is difficult to apply here because it would require a lot of rom (many tables) for example I would need 4 times more rom for the "move delta" table (that is, 256), since my method uses 8 x 8 virtual tiles , thank you anyway for the detailed explanation, since it inspired me to make this possible.
 
Now it is also possible to increase the speed of the game with the right switch (in the "A" position the speed increases).
 
Enjoy. :)
 

 

Awesome!



#1484 Kosmic Stardust ONLINE  

Kosmic Stardust

    Princess Rescuer

  • 17,870 posts
  • Location:Milky Way Galaxy

Posted Thu Oct 11, 2018 10:38 PM

Is this a release candidate? Getting closer to completion; glad to see it isn't abandoned, yet... ;-)




0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users