New pacman for atari 2600

[Andromeda Stardust]

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.

[+DZ-Jay]

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.

   

  

• 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:

   

  

   

  

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 August 6, 2018 by DZ-Jay

[+DZ-Jay]

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 August 6, 2018 by DZ-Jay

[DINTAR816]

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.

pacman2600_8k_v8test_corn.bin

[Arenafoot]

 

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!

[+DZ-Jay]

 

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.

 

-dZ.

[Dionoid]

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

[Brian O]

 

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!

[Andromeda Stardust]

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

[WildBillTX]

Thanks for the update! I love the fast mode switch, though it gets crazy fast on the higher levels.

[iesposta]

What he said:

 

 

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.

 

-dZ.

 

 

Thank you!

Arcade AI & sound never thought possible on the Atari 2600.

If you are familiar with the real Arcade game play, this is amazing.

 

Scary how often I forget this is on the 2600 because of the game play and sound, they start by going to their corners, they all reverse directions, changing to get to your position; Also like when they’re all coming for you, go toward Clyde because that’s your best chance of getting away due to the fact Clyde doesn’t make moves to get to your position.

[retrorandy]

This is so goddamn impressive! I just downloaded this to an Uno cartridge that I just bought. Holy smoke what a great version of the game for the Atari 2600! This truly is a labor of love and it is very much appreciated. Wow, it even has the intermissions!!!! Who would have imagined the Atari 2600 could look so good. I'm a fan of the Atari 8bit version of Pacman which I still dearly love, but this one blows that one out of the water.

It's wild to see new versions of our beloved classics still being ported to this system. Thank You!

[+Philsan]

It would be nice to add Atarivox high score save feature.

[KAZ]

Thinking of releasing this on cart yet, Dintar? I'd love to buy it!

[Andromeda Stardust]

Thinking of releasing this on cart yet, Dintar? I'd love to buy it!

× 1000000.

[Kurt_Woloch]

Just downloaded this new version as well... I think this is one of the best cornerings I've seen across all ports of Pac-Man and its variants.

[JJohnson]

This is amazing! Great job! Do you think any other 2600 game has some potential to be 'fixed' like you did Pac-Man?

[Keatah]

As a non-developer, but vintage enthusiast, I would say that many games could be remade in this fashion. As long as the dev has the skill set.. why not?

[+Nathan Strum]

This is amazing! Great job! Do you think any other 2600 game has some potential to be 'fixed' like you did Pac-Man?

 

Super Cobra Arcade has already been done, and Wizard of Wor Arcade is nearing completion. Space Rocks is a vastly improved remake of Asteroids as is Medieval Mayhem of Warlords. Space Raid is an all-new remake of Zaxxon, DK Arcade is a work-in-progress remake of Donkey Kong (DK VCS is another), Star Castle Arcade is a homebrew that set out to improve over another homebrew version of Star Castle, and there's already an excellent homebrew version of Pac-Man available, although at 4K in size, the challenge was to make as accurate of a version of Pac-Man within that constraint, rather than the most accurate version possible.

 

I'm sure there are others that I'm forgetting to mention. If you want stretch the concept a little and count Mission 3000 A.D. as a port of Bosconian, Draconian more than "fixed" that one. The forthcoming Aardvark is a completely new version of the unreleased Anteater prototype, and Lady Bug is a homebrew version of a Coleco game that was announced but (as far as we know) never existed. You can't fix a game much more than that.

 

All of these are all-new, from the ground-up creations - not hacks of existing games. There will almost certainly be more remakes in the future, but it really comes down to whether or not a programmer has the interest in taking on developing a particular game.

[Impaler_26]

 

I'm sure there are others that I'm forgetting to mention.

 

There's also Chaotic Grill , a great remake of Burger Time.

[Kurt_Woloch]

I think it wouldn't be too hard to "fix" Ms. Pac-Man building on the core of this version since the gameplay doesn't differ too much from the original Pac-Man.

[JJohnson]

I'm going to try this out soon. Does the level bug still exist? Can I reach level 256?

[Brian O]

Made some tweaks to the box art and cart, just to see how it would look.

[metoo3]

Just wanted to thank you guys for all your efforts you put in our beloved

Pac-Man. The result is simply stunning! 

BTW, is there any possibility to play the latest v7 release on a PAL box with proper colors? 

[+Kaboomer]

On 5/7/2019 at 9:25 AM, JJohnson said:

This is amazing! Great job! Do you think any other 2600 game has some potential to be 'fixed' like you did Pac-Man?

I always wondered if someone could dig into Missile Command and add the satellites that are in the arcade version: "Arcade Missile Command" if you will for the 2600!