Billy Mitchell TG Banned, Scores Removed

[BiffsGamingVideos]

In a nutshell, the issue is that there is 1 pixel on the ghost and 1 pixel on the bad guy that are collision pixels. If they occupy the same space then that is a collision. However they can sometimes be off by 1 pixel and thus no collision. So a way around it is to check pac-man's collision pixel with every pixel around it to see if it's near a ghost's collision pixel. So instead of just 1, it'd being doing 9 of them. Now back in those days that may have been to much to do for speed or memory. Also, they programmed in assembly with limited power/memory. So I think is the programmer wanted to fix it, he could have. I think it was more of a decision to release a game to make money verses fixing something so minor (just an opinion).

[+DZ-Jay]

In a nutshell, the issue is that there is 1 pixel on the ghost and 1 pixel on the bad guy that are collision pixels. If they occupy the same space then that is a collision. However they can sometimes be off by 1 pixel and thus no collision. So a way around it is to check pac-man's collision pixel with every pixel around it to see if it's near a ghost's collision pixel.

Er... Not quite. There are no pixel tests involved. The sprites are 16x16 pixel objects laid on a play-field grid composed of 8x8 virtual tiles. At each decision point, after the sprites are moved, their position on the grid is computed by mapping their screen bitmap coordinates to the virtual tile coordinates. This is pretty much just a division by 2 with an offset to compensate for the virtual grid being larger than the object position area.

 

The virtual tile X and Y coordinates are then compared between Pac-Man and each one of the Ghosts: if any of them are equal, a collision is registered. It's quite elegant and simple.

 

tep392 is right that one possible solution would be to move the Ghosts before Pac-Man and test before moving Pac-Man. However, there would be an impact to game-play since now user input processing is delayed by the AI, which may result in a perceptible lag. Also, there is a chance of making the Ghosts much more aggressive by giving priority to their motion rather than Pac-Man.

 

Taken in isolation, none of these are a big deal, but they affect the delicate emergent behaviour that the actual game evinces due to its implementation.

 

I agree with tep392 that the pass-through glitch was most likely unintended, and just an inadvertent artifact of the implementation. Whether you call that a bug, a flaw, a feature, or just a side-effect, depends on your own point of view. I don't consider it a feature, but I don't consider it a bug or a flaw either.

 

dZ.

[tep392]

In a nutshell, the issue is that there is 1 pixel on the ghost and 1 pixel on the bad guy that are collision pixels. If they occupy the same space then that is a collision. However they can sometimes be off by 1 pixel and thus no collision. So a way around it is to check pac-man's collision pixel with every pixel around it to see if it's near a ghost's collision pixel. So instead of just 1, it'd being doing 9 of them. Now back in those days that may have been to much to do for speed or memory. Also, they programmed in assembly with limited power/memory. So I think is the programmer wanted to fix it, he could have. I think it was more of a decision to release a game to make money verses fixing something so minor (just an opinion).

The collision detection doesn't compare pixel level x,y coordinate, like a bounding box method. It's just checking if they occupy the same square in the grid. The fix is as simple as changing the time when the collision detection is performed. No additional CPU cycles necessary.

[+DZ-Jay]

The collision detection doesn't compare pixel level x,y coordinate, like a bounding box method. It's just checking if they occupy the same square in the grid. The fix is as simple as changing the time when the collision detection is performed. No additional CPU cycles necessary.

Perhaps. However, in Pac-Man, user input has priority over any other event. This allows the user to eat power pellets or dots even when he is overlapping one of the enemies. Changing the order of collision detection and their priorities will have a noticeable impact on this.

 

Your solution would work, but it doesn't come for free. The trade-off is in game-play mechanics.

 

dZ.

[tep392]

Perhaps. However, in Pac-Man, user input has priority over any other event. This allows the user to eat power pellets or dots even when he is overlapping one of the enemies. Changing the order of collision detection and their priorities will have a noticeable impact on this.

 

Your solution would work, but it doesn't come for free. The trade-off is in game-play mechanics.

 

dZ.

Any change in collision detection would by definition impact gameplay.

[BiffsGamingVideos]

"It's just checking if they occupy the same square in the grid."

 

But if you know that XY position, then couldn't one check pac-man's XY pixel point with a ghost's X+1, X-1, Y+1 and Y-1? So really that would be 4 additional checks.

 

- If the ghost's center is at 4x and 4y

- and then pac-man is at 4x and 5y

- Then if pac-man was going up the Y coordinated would flip flop and thus no collision.

 

- So really, you probably need just 1 additional check. If pac-man is going up, then check to see if the ghost is also at Y+1. If going left, then check it against X-1. and so forth. As long as you know the pixel points of the collision point, then just add or subtract 1. Now, of course, I am assuming that the programmer could be able to enable a collision routine. That may not even have been possible back then. It might have been just a compare and act on the result.

 

Like comparing 2 registers:

CMP R2, R1

 

Then do a jump if equal like:

JMP collision

Edited April 30, 2018 by BiffsGamingVideos

[BiffsGamingVideos]

Here's 1/2 finished game I started a while back. It has all of the pacman, ms pacman and jr pacman levels in it. It is pixel perfect. There is 1 big change in the gameplay to make it a sequal. So the game is not a clone but really different. (I can't say what the changes are as someone would just do it before me)

 

Maybe later this year I'll finish it and pitch it to Namco. Who knows?

[BiffsGamingVideos]

Just for kicks and giggles, here is a breakout, super breakout, arkanoid clone I started a while back and never finished. It's 2d and can change to 3d.

Edited April 30, 2018 by BiffsGamingVideos

[+DZ-Jay]

"It's just checking if they occupy the same square in the grid."

 

But if you know that XY position, then couldn't one check pac-man's XY pixel point with a ghost's X+1, X-1, Y+1 and Y-1? So really that would be 4 additional checks.

 

- If the ghost's center is at 4x and 4y

- and then pac-man is at 4x and 5y

- Then if pac-man was going up the Y coordinated would flip flop and thus no collision.

 

- So really, you probably need just 1 additional check. If pac-man is going up, then check to see if the ghost is also at Y+1. If going left, then check it against X-1. and so forth. As long as you know the pixel points of the collision point, then just add or subtract 1. Now of course I am assuming that if they then match the programmer could be able to enable a collision routine. That may not even have been possible back then,

 

It's a lot more than just one additional check. Here's how it works right now:

1. Get user input
2. Calculate Pac-Man's virtual tile coordinate
3. Test open exits available in virtual grid
4. Update Pac-Man's position
5. Compare virtual tile coordinates with all game objects (dots, power pellets, fruits, etc.)
6. Trigger all collisions detected
7. Calculate Ghost current virtual tile coordinate
8. Compute Ghost target tile (AI)
9. Test open exits available in virtual grid
10. Update Ghost position
11. Calculate new virtual tile coordinate and compare with Pac-Man's
12. Trigger the first collision detected
13. Repeat from #7 for each Ghost

The collision detection is not really a comparison of X/Y coordinates, it's a simple equality comparison (technically, a subtraction and test for zero).

 

Any change to the algorithm above would incur a significant change in code, not to mention an impact on game-play due to any changes in the emergent behaviour.

 

-dZ.

[+DZ-Jay]

Here's 1/2 finished game I started a while back. It has all of the pacman, ms pacman and jr pacman levels in it. It is pixel perfect. There is 1 big change in the gameplay to make it a sequal. So the game is not a clone but really different. (I can't say what the changes are as someone would just do it before me)

 

Maybe later this year I'll finish it and pitch it to Namco. Who knows?

 

I don't know if you have already, but you may want to check out The Pac-Man Dossier by Jamey Pittman. It describes the technical underpinnings of the game in great detail at a high algorithmic level, rather than in code. It can serve as a specification and guide for any clone or port of the game. It's a fascinating read!

 

-dZ.

[BiffsGamingVideos]

 

I don't know if you have already, but you may want to check out The Pac-Man Dossier by Jamey Pittman. It describes the technical underpinnings of the game in great detail at a high algorithmic level, rather than in code. It can serve as a specification and guide for any clone or port of the game. It's a fascinating read!

 

-dZ.

Yeah, i read that like 10 or 20 years ago. Although I read it somewhere else and it looked a little different. I especially like how there are marker tiles and the ghosts are trying to get to those tiles. If you didn't know about that then it's be tough to make a pac-man clone with close behavior to the arcade version.

 

Really good stuff.

Edited April 30, 2018 by BiffsGamingVideos

[Austin]

NEW PAC-MAN WORLD RECORD! 222,222,220. Level 1,000.

 

I guess Billy Mitchell owes someone $10,000.

 

You have too much time on your hands.

[Andromeda Stardust]

Regarding Pacman, collision detection is dead simple. The maze is logically divided into tiles. Pacman and ghost sprites are 16x16 pixels as rendered on the display, and are tracked visibly at pixel precision. For collision detection, the center pixel of Pacman and ghosts can only occupy one "tile" at a time. If pacman and ghost occupy the same tile at once, a collision occurs, resulting in either death of Pacman (normal) or the ghost is consumed (when blue).

 

Pacman nor ghost can overlap multiple tiles, so it is possible for Pacman and ghost to swap tiles on the same frame. Because Pacman and ghost never occupy the same tile simultaneously, a collision hit is not registered. Changing to a bounding box would be more computationally intensive since additional maths must be performed to calculate proximity, rather than a simple comparator.

 

Donkey Kong on the other hand uses bounding boxes to handle collision and point bonuses for clearing barrels. Occasionally a barrel point bonus isn't counted it Mario is too far away at the apex of his jump. Likewise the bounding box for point bonus is larger than for hit detection, allowing for instance point farming by jumping next to Donkey Kong on the rivet stage.

 

It's not a sampling rate problem, it's a grid problem. It doesn't use bounding boxes in the way you are thinking. Think of it as a board game like Trouble or Candy Land or whatever: You move your pieces across the board in little squares. The square in which your piece is at any given time, is your square. If two pieces land on the same square on the same turn, they have "collided."

 

What happens in the pass-through glitch is that you are in one square and your enemy is in an adjacent square, and you both move towards each other during the same turn: you end up in your enemy's square, and he ends up in yours, thus never landing on the same square.

 

The problem is that the squares that determine your and the enemies' positions cannot overlap because they are in a strict grid (thus, not a bounding box around the sprite, but tiles on a grid).

 

It's a flaw in that the collision detection is not 100% accurate all the time; but it's not a bug because it's not a coding error nor a design mistake: it was specifically chosen for its elegance and simplicity which afforded the targeting functionality of the enemies. It is what makes Pac-Man what it is.

 

Seriously, read the link I posted above, it's fascinating.

 

Notice that Ms. Pac-Man reduces the probability of the pass-through glitch by increasing the random number entropy, which prevents you from making simple deterministic patterns like in Pac-Man. However, it still happens randomly every once in a very long while.

 

-dZ.

To be totally fair, my post was in response to the unity issue. Pacman, and most classic era arcade games and 8- and 16-bit console games, use tile engines.

 

The 3d issue of bounding boxes missing their target is another matter entirely. If tracking the trajectory of an object once per frame, it needs to collide with scenery, enemies or some other object. The video frame is rendered 60 times per second but your hit detection system doesn't rely on the rendered output. Suppose a grapple hook can collide with any scenery, there is room for glitch or other error.

 

Most games allow the hook to be utilized at specific places where it benefits the player, thus limiting the opportunity for exploit. The grapple hook will have it's own trajectory and you can snap to nearby objects using a bounding box or distance estimation. This can compute collision with say vertices in a terrain map. Larger bounding boxes would make the hook feel less precise with larger snap too radius, but reduce the likelyhood of missing it's target or going through objects in it's path. A collision miss could be used to exploit the engine, especially if it allows the player to jump through walls where the hook has avoided collision.

[Asaki]

He(Billy) SHOULD just come out and say, "Yeah, we used MAME and some of it's features to enhance the story of the movie and that it was never intended to be considered as legit. However, I made a bad decision in allowing it to go on to protect the movie itself." I would imagine that a confession along those lines would go over well with the arcade community(of which I am a part) and sooner or later all of the hate would go away.

But he used similar MAME recordings for "live" video feed at two other live events, both of which occurred after the film's release and were only mentioned briefly in a text-only special feature on the DVD. The film doesn't benefit from this at all, only Billy does.

Edited May 1, 2018 by Asaki

[tep392]

Er... Not quite. There are no pixel tests involved. The sprites are 16x16 pixel objects laid on a play-field grid composed of 8x8 virtual tiles. At each decision point, after the sprites are moved, their position on the grid is computed by mapping their screen bitmap coordinates to the virtual tile coordinates. This is pretty much just a division by 2 with an offset to compensate for the virtual grid being larger than the object position area.

 

The virtual tile X and Y coordinates are then compared between Pac-Man and each one of the Ghosts: if any of them are equal, a collision is registered. It's quite elegant and simple.

 

tep392 is right that one possible solution would be to move the Ghosts before Pac-Man and test before moving Pac-Man. However, there would be an impact to game-play since now user input processing is delayed by the AI, which may result in a perceptible lag. Also, there is a chance of making the Ghosts much more aggressive by giving priority to their motion rather than Pac-Man.

 

Taken in isolation, none of these are a big deal, but they affect the delicate emergent behaviour that the actual game evinces due to its implementation.

 

I agree with tep392 that the pass-through glitch was most likely unintended, and just an inadvertent artifact of the implementation. Whether you call that a bug, a flaw, a feature, or just a side-effect, depends on your own point of view. I don't consider it a feature, but I don't consider it a bug or a flaw either.

 

dZ.

Another option would be to add add an additional check to the collision code, that checks for the very specific condition of Pac and Monster swapping positons, which should only happen if they pass thru each other. Would require saving the previous positons but could be coded efficiently.

[+DZ-Jay]

Another option would be to add add an additional check to the collision code, that checks for the very specific condition of Pac and Monster swapping positons, which should only happen if they pass thru each other. Would require saving the previous positons but could be coded efficiently.

Personally, I don't think the additional expense and effort is worth it. The pass-through glitch, as it stands, does not harm the game in any way. I would even say it adds to the quality of the game.

 

You can tell that it never bothered anybody, which is why it was left in Ms. Pac-Man and other derived games.

 

Fun fact: there is an actual bug in the targeting logic for one of the Ghosts, were a computation had a chance to overflow and corrupt the results. It is easy to fix, but doing so would not make the game better, just slightly different, so it was never fixed -- not even in Ms. Pac-Man.

 

Such are the intricate vicissitudes of Pac-Man's essence.

 

dZ.

[tep392]

Personally, I don't think the additional expense and effort is worth it. The pass-through glitch, as it stands, does not harm the game in any way. I would even say it adds to the quality of the game.

 

You can tell that it never bothered anybody, which is why it was left in Ms. Pac-Man and other derived games.

 

Fun fact: there is an actual bug in the targeting logic for one of the Ghosts, were a computation had a chance to overflow and corrupt the results. It is easy to fix, but doing so would not make the game better, just slightly different, so it was never fixed -- not even in Ms. Pac-Man.

 

Such are the intricate vicissitudes of Pac-Man's essence.

 

dZ.

I'm not suggesting it should have been changed. It's just the programmer in me thinking about possible fixes.

[Dauber]

Personally, I don't think the additional expense and effort is worth it. The pass-through glitch, as it stands, does not harm the game in any way. I would even say it adds to the quality of the game.

 

You can tell that it never bothered anybody, which is why it was left in Ms. Pac-Man and other derived games.

FWIW, it might be that it was left in Ms., Plus, and Jr. simply because the programmers didn't know it was there in the first place. After all, they're just hacks of Pac-Man.

[[d2f]Iggy*SJB]

FWIW, it might be that it was left in Ms., Plus, and Jr. simply because the programmers didn't know it was there in the first place. After all, they're just hacks of Pac-Man.

 

Do you know if it also happens in Super Pac? Pausing from writing the post and thinking about it, I seem to recall at least one time where I believe it happened. It rather shocked me as I thought I was dead so I let go of the joystick.

[+DZ-Jay]

FWIW, it might be that it was left in Ms., Plus, and Jr. simply because the programmers didn't know it was there in the first place. After all, they're just hacks of Pac-Man.

There is indication that they knew it was there. For one, if you consider the mechanism employed for more than a few seconds, you'll realize that it covers only 99% of cases. They probably just thought that the 1% was rare enough not to bother.

 

Like I've said before, the tile-based targeting and collision enables many of the other features in a simple, elegant, and efficient way; and the one case in which it fails does not really harm the game.

[Andromeda Stardust]

Personally, I don't think the additional expense and effort is worth it. The pass-through glitch, as it stands, does not harm the game in any way. I would even say it adds to the quality of the game.

You can tell that it never bothered anybody, which is why it was left in Ms. Pac-Man and other derived games.

Fun fact: there is an actual bug in the targeting logic for one of the Ghosts, were a computation had a chance to overflow and corrupt the results. It is easy to fix, but doing so would not make the game better, just slightly different, so it was never fixed -- not even in Ms. Pac-Man.

Such are the intricate vicissitudes of Pac-Man's essence.

dZ.

The "fun fact" as you put it, is that when pacman faces up, one of the ghosts targets the tile four spaces above and to the left of Pacman. It should have always been four spaces in front of pacman regardless of which way he was facing. Incidentally this oversight is what allows parking in the "safe zones" ie hiding out to the right side underneath a T-island, to work. Parking Pacman anywhere in the maze would have been impossible otherwise. This quirk in the ghost behavior algorithm was left in place for Ms Pacman not because the developers decided to leave it in, but because Ms Pacman started life as a Pacman enhancement kit before Midway bought the rights from General Computer Corp. As for Super Pacman and Jr Pacman, I have no idea. Namco found creative ways to tamper with the physics in later games, and never played quite the same. I would even argue that Super Pacman is no more related to the original as other maze games like Ladybug.

[+DZ-Jay]

The "fun fact" as you put it, is that when pacman faces up, one of the ghosts targets the tile four spaces above and to the left of Pacman. It should have always been four spaces in front of pacman regardless of which way he was facing. Incidentally this oversight is what allows parking in the "safe zones" ie hiding out to the right side underneath a T-island, to work. Parking Pacman anywhere in the maze would have been impossible otherwise. This quirk in the ghost behavior algorithm was left in place for Ms Pacman not because the developers decided to leave it in, but because Ms Pacman started life as a Pacman enhancement kit before Midway bought the rights from General Computer Corp. As for Super Pacman and Jr Pacman, I have no idea. Namco found creative ways to tamper with the physics in later games, and never played quite the same. I would even argue that Super Pacman is no more related to the original as other maze games like Ladybug.

 

The behaviour was left in Ms. Pac-Man because it didn't cause harm. The programmers making the enhancement kit took the time to patch some bugs and change some game-play elements, including adding entropy to the random number generator to make the game non-deterministic; yet didn't touch that. They reversed-engineered and documented the entire game source, so it's not like they didn't know it was there. The same with the "kill-screen" level counter bug, which they fixed.

 

The point of the specialized AI for each Ghost was to endow them with "personality," and this came across even with that bug, so nobody cared. We really can't tell the motivations of the original programmers, but it all points to it being such a minor and inconsequential bug, that nobody minds having it there.

 

By the way, speaking of "kill-screen," for those interested I found this fascinating explanation of how it happens.

 

-dZ.

[+DZ-Jay]

And speaking of Pac-Man and Ms. Pac-Man bugs, this is also very interesting.

[BiffsGamingVideos]

So getting back to that video about framerates. Locking a framerate is easy. I 100% think billy cheated but you can't go by a framerate to hang the guy. That can be easily manipulated. This is a screenshot from fraps which is used to record in game footage of software. You can lock the framerate in and choose which to use. If you want a smaller filesize you can not lock it. So framerate can not be used as pro or con here.

 

 

[+x=usr(1536)]

So getting back to that video about framerates. Locking a framerate is easy. I 100% think billy cheated but you can't go by a framerate to hang the guy. That can be easily manipulated. This is a screenshot from fraps which is used to record in game footage of software. You can lock the framerate in and choose which to use. If you want a smaller filesize you can not lock it. So framerate can not be used as pro or con here.

 

 

 

Framerate wasn't used as a lynchpin; screen rendering was. Framerate was just one item that was taken into consideration since it was known that MAME did not match the arcade game's framerate for quite some time.

 

Also, no external software would be necessary to record a MAME performance - it can output in .AVI format during gameplay. Not that that happened in this case, but I'm mentioning it for clarity.