New pacman for atari 2600

[negative1]

finally made a good run of the 9th-12th key, it just keeps repeating, but wanted to make sure.

 

this is the HARDEST version of pac-man, patterns don't work consistently, and red speeds up superfast,

you can't really make an error

 

spliced from stella, using savestates:

 

 

later

|| | || | |

n e gative 1

[insertclevernamehere]

I have not played this yet.  Does it have game variations like the original release Pac-Man and does it have a 2 player option?

[AW127]

This game should really be finalized, it's a superb Pac-Man version, even across systems!

[stlouisrod]

Bummer this version doesn't deal with diagonal joystick presses. The 4k version does just fine. As an Atari 800 machine code developer, this is quite easy to deal with. Simply use bit-level checks on the joystick register, NOT specific values for up/down/left/right.

[negative1]

5 hours ago, stlouisrod said:

Bummer this version doesn't deal with diagonal joystick presses. The 4k version does just fine. As an Atari 800 machine code developer, this is quite easy to deal with. Simply use bit-level checks on the joystick register, NOT specific values for up/down/left/right.

i didn't notice any difference in the gameplay, or problems.

don't think it made any impact for me.

 

later

| | | | | |

ne gative1 

[+Karl G]

5 hours ago, stlouisrod said:

Bummer this version doesn't deal with diagonal joystick presses. The 4k version does just fine. As an Atari 800 machine code developer, this is quite easy to deal with. Simply use bit-level checks on the joystick register, NOT specific values for up/down/left/right.

What in your mind is the correct way to deal with diagonals? Should they count as either direction, or neither direction?

[BrianC]

The diagonal behavior is odd. Pac-Man will move up or down if a diagonal is held when he hits a wall. 

[Thomas Jentzsch]

6 hours ago, Karl G said:

What in your mind is the correct way to deal with diagonals? Should they count as either direction, or neither direction?

They should work based on the current direction and prioritize changing direction. E.g. when moving right, pressing right+up (or even only up!) should result into moving up if possible. If not, continue moving right.

 

That way you can go around corners much easier.

 

I really dislike games where you fight the controls instead of the game. And this would be such a case. Even Pitfall! (and many other games from back then) got the cornering right, more than 40 years ago. So there are no excuses now.

[Thomas Jentzsch]

1 hour ago, BrianC said:

The diagonal behavior is odd. Pac-Man will move up or down if a diagonal is held when he hits a wall. 

Pac-Man does it wrong. Ms and Jr Pac-Man are much better here (though still not perfect).

[SoundGammon]

22 hours ago, stlouisrod said:

Bummer this version doesn't deal with diagonal joystick presses. The 4k version does just fine. As an Atari 800 machine code developer, this is quite easy to deal with. Simply use bit-level checks on the joystick register, NOT specific values for up/down/left/right.

The original arcade version of Pac-Man uses a 4-way joystick! I know because I have one that came from Pac-Man machine. In one of the old "how to play" Pac-Man books, it mentioned cornering and said to push the joystick prior to the turn you want to make!

[Thomas Jentzsch]

59 minutes ago, SoundGammon said:

The original arcade version of Pac-Man uses a 4-way joystick! I know because I have one that came from Pac-Man machine. In one of the old "how to play" Pac-Man books, it mentioned cornering and said to push the joystick prior to the turn you want to make!

Yup, that's what I mentioned above in brackets.

[DINTAR816]

On 5/12/2024 at 1:46 AM, BrianC said:

The diagonal behavior is odd. Pac-Man will move up or down if a diagonal is held when he hits a wall. 

 

22 hours ago, Thomas Jentzsch said:

They should work based on the current direction and prioritize changing direction. E.g. when moving right, pressing right+up (or even only up!) should result into moving up if possible. If not, continue moving right.

 

That way you can go around corners much easier.

 

I really dislike games where you fight the controls instead of the game. And this would be such a case. Even Pitfall! (and many other games from back then) got the cornering right, more than 40 years ago. So there are no excuses now.

I tried to do that but with the cut corner it's more difficult, it only works in the previous versions without cut corner.
Maybe I can try again.

[Thomas Jentzsch]

14 hours ago, DINTAR816 said:

I tried to do that but with the cut corner it's more difficult, it only works in the previous versions without cut corner.
Maybe I can try again.

Why does cutting the corner make it more difficult? 

[DINTAR816]

On 5/13/2024 at 4:35 PM, Thomas Jentzsch said:

Why does cutting the corner make it more difficult? 

It is not easy as in the versions without cut corner, because in those versions Pacman moves only vertically or horizontally, however in this one he does it in both directions at the same time when pacman is crossing a corner, that complicates things, at least the ways I tried didn't work (Pacman kept moving constantly between the two directions).

[JeremiahK]

I wrote a Pacman clone several years ago in Python for the Blender Game Engine.  I can't find the project now, but I do recall having a hard time getting the cornering to work correctly.  Here is how I remember doing it.  (Step 2 is where cornering is handled.)

 

1. Get Pacman's Move Direction
   • The desired direction InputDir is read from player input (North, South, East, or West).
   • If InputDir is valid at Pacman's current tile:
     • MoveDir is set to match InputDir.
   • Else:
     • MoveDir is not changed; Pacman just keeps trying to move in the same direction he is already moving.
   • -
2. Center Pacman Within His Current Tile
   • If Pacman is moving East or West:
     • Check if Pacman's North/South position is centered on his current tile.
     • If Pacman is not centered, move North or South towards the center.  (This is how the cornering happens!)
   • Else if Pacman is moving North or South:
     • Check if Pacman's East/West position is centered on his current tile.
     • If Pacman is not centered, move East or West towards the center.
   • -
   • NOTE: The original Pacman didn't center perfectly.  Since the tiles were 8x8 pixels, the "center" was off by 1 pixel, causing some corners to be tighter than others.  I didn't bother implementing this in my game.
   • -
3. Move Pacman in the Direction He Wants to Go
   • If MoveDir is valid:
     • Move Pacman in the MoveDir direction.
   • Else:
     • Don't let Pacman go through the walls.
     • Only let Pacman move forward to the center of the tile, but no further.
   • -

 

I believe the difficulty is coming from the fact that on the Atari, you can press the joystick diagonally, trying to go both North and West simultaneously.  Figuring out which way the player actually wants to go is tricky.

 

One idea I have is to store which direction Pacman was moving in the previous tile (not the previous frame), and save this to PrevDir.  Suppose Pacman is moving West, and reaches a T-intersection tile.  Pacman can continue West, reverse East, or turn South.  If the player is pressing South-West on the joystick, then since both moves are valid, PrevDir is checked.  Since Pacman was moving West in the previous tile, we know that the player wants to turn South, not continue West.  (So the game should prefer changing the direction over continuing the same direction, when possible.)  If somehow the player is pressing South-East on the joystick, they probably want to reverse and go East, but this situation should be extremely rare.

 

Also, "illegal joystick inputs" where 3 or 4 directions are being pressed should probably be ignored altogether.

[stlouisrod]

I think you are on the right track. Non-diagonals are easy as the target destination is only one "tile". But on diagonals, test the 2 possible tile destinations (see diagram below). If only one is free, simply go that way. If both are free, choose the direction that's opposite the "momentum" of Pac-man (in the case below, down). Hopefully this isn't over-simplifying things

 

*****

  P <--- momentum (joystick pressed South-West)

* ***

[Thomas Jentzsch]

Yup.

 

That's what I tried to suggest above.  

[JeremiahK]

On 5/12/2024 at 2:06 AM, Thomas Jentzsch said:

They should work based on the current direction and prioritize changing direction. E.g. when moving right, pressing right+up (or even only up!) should result into moving up if possible. If not, continue moving right.

Exactly, Thomas said the same thing in fewer words.  I tend to over-explain things so I'm 100% sure nothing is misunderstood.

 

I did want to explain my algorithm for "Set-Direction, Center-Pacman, Move-Pacman" because I'm not sure how @DINTAR816 is implementing movement and cornering; that may be where the true problem lies.

[JeremiahK]

Also, as I mentioned, make sure you are only checking Pacman's direction in the previous tile, not the previous frame.  If you go by frame, then Pacman will change his mind on every frame.