Jump to content
IGNORED

New pacman for atari 2600


DINTAR816

Recommended Posts

Not bad.

 

The thing I really wish he'd fix is that the wakka-wakka rate is different depending on whether you're moving horizontally or vertically. You only get a correct-sounding wakka when eating dots vertically.

IIRC, Pacman 4k did this as well. It has to do with the maze graphics being compressed in the vertical domain (or stretched in the horizontal) to fit the entire maze onscreen. Fixing the tempo would mess up other aspects of the gameplay.
Link to comment
Share on other sites

It would be pretty trivial to fix. The game just has to detect whether Pac-Man is moving horizontally or vertically when eating a dot. If the former, play a full wakka. If the latter, play a half-wakka. Maybe some logic to prevent wakka fighting when going around corners.

Link to comment
Share on other sites

Just thought about the question - when Dintar816 soon is a millionaire (cause AT-Games pay him out for copyright-reasons) will he then still release a PAL60-version of V.7 or will he rather make a 2-year-trip all around the world ??? :P

Link to comment
Share on other sites

Just thought about the question - when Dintar816 soon is a millionaire (cause AT-Games pay him out for copyright-reasons) will he then still release a PAL60-version of V.7 or will he rather make a 2-year-trip all around the world ??? :P

Good question. One concern I have is if the AtGames has any sort of exclusivity clause that would exclude an AA store release. It would break my heart not to get this on cart... :_(

  • Like 2
Link to comment
Share on other sites

Good question. One concern I have is if the AtGames has any sort of exclusivity clause that would exclude an AA store release. It would break my heart not to get this on cart... :_(

 

I would hope that if this is licensed somehow that it would be licensed down to the level that say FROGGER was back in the FERG.

PARKER Bros got the cartridge rights and Starpath got the magnetic rights. Thus 2 very different versions of the same game for the same system.

 

So AT Games would get "Portable/Emulation" rights for Flashbacks and that would leave "Cartridge" rights open for AA. (One would hope)

 

I hope this is how it goes down if it becomes an issue. Granted I will always have the last released ROM on my Harmony to play on real hardware, but in the same breath I would still buy an 8k version on cart in the store if it was offered.

  • Like 1
Link to comment
Share on other sites

 

I hope this is how it goes down if it becomes an issue. Granted I will always have the last released ROM on my Harmony to play on real hardware, but in the same breath I would still buy an 8k version on cart in the store if it was offered.

Whatever the AtGames licensing terms, I hope you are right on this.

 

Wouldn't it be something if Namco gave their blessing for the cart release? Kinda like First Star's Boulderdash but not limited to XX copies or abhorrently expensive.

 

I'd pay an extra $5 to get a cartridge with "Officially licensed by Namco" or "Pacman © Namco. Used by permission" or some such. It seems they are aware of the homebrew ports and so far either secretly admired our efforts or at least not made efforts to stop their sale. So if we got a Namco license out of the 2600 and 7800 PMP ports, that would be awesome, even if it cost a couple bucks more for their approval.

  • Like 3
Link to comment
Share on other sites

Good question. One concern I have is if the AtGames has any sort of exclusivity clause that would exclude an AA store release. It would break my heart not to get this on cart... :_(

couldn't you just order a "one-off" cart from Al thru the AA store???

Link to comment
Share on other sites

  • 4 weeks later...

So it is confirmed now AtGames is using the older Debro 4k Pacman on the flashback portable. Still an excellent port but the new one (v7test, 8kb) is perfect IMO.

 

OMG! The "fix" for using Dintar816's Pac-Man was to use Dennis Debro's version!!

Look at John's video.

 

The different screen sizes, I would guess, is that John H's "older" one was the pre-release version that did have a larger screen.

Good news is that this year's model does show better color.

I can't say about the left-right viewing angle from a video because you physically have to see it with both eyes.

  • Like 1
Link to comment
Share on other sites

So it is confirmed now AtGames is using the older Debro 4k Pacman on the flashback portable. Still an excellent port but the new one (v7test, 8kb) is perfect IMO.

 

I noticed John is using my ROM pack on his AFP2, that is cool! First off that it will work on the 2nd edition of Portables and secondly, that something I compiled for the AA community is being enjoyed by others. ;-)

  • Like 4
Link to comment
Share on other sites

I noticed John is using my ROM pack on his AFP2, that is cool! First off that it will work on the 2nd edition of Portables and secondly, that something I compiled for the AA community is being enjoyed by others. ;-)

Is this one in AtariAge's official emulation menu ROM list or is this somewhere else. Thanks.

Link to comment
Share on other sites

  • 1 month later...

I noticed John is using my ROM pack on his AFP2, that is cool! First off that it will work on the 2nd edition of Portables and secondly, that something I compiled for the AA community is being enjoyed by others. ;-)

If I recall correctly, Debro's "Pacman 4k" as featured in the AA store did not have a public ROM release. The newer enhanced more arcade accurate version by Dintar816 is showcased in the acreenart on the box. "Pacman 4k" has narrow center walls. "New Pacman 8k" has fat center walls. Completely different codebase. Dead giveaway. From there the physics AI and sound in the "new" 8k version are more authentic, about as much sound accuracy as physically possible without stuffing the TIA register.

 

There's a number of different versions of Debro's "4k" Pacman floating about. The old release is slower and less frantic than the updated ROM. The AA store version has updated bassline and no cutscenes. The tweaked cutscene infused ROM has weaker basslines musically, and likely other subtle differences since the hack was applied to an earlier buikd to the finished product.

 

So which version of Debro's "4k" got included on this package? The John Hankok review isn't long enough to tell.

Link to comment
Share on other sites

Is there any "cornering" in this game? In the arcade game, when Pac-Man "cuts" around a maze corner at an intersection, he actually goes diagonally for a few pixels, while the ghosts have to reach the center of the intersection before changing direction. This can help you when you have a ghost right on your tail, if you can quickly zip through a bunch of corners.

Link to comment
Share on other sites

Is there any "cornering" in this game? In the arcade game, when Pac-Man "cuts" around a maze corner at an intersection, he actually goes diagonally for a few pixels, while the ghosts have to reach the center of the intersection before changing direction. This can help you when you have a ghost right on your tail, if you can quickly zip through a bunch of corners.

Discussed multiple times in this thread, but I think it's still being "planned", unsure if it's in there as is.

Link to comment
Share on other sites

  • 10 months later...

If making Pac-man go diagonally at corners is too difficult why not just run a buffer that tracks Pac-man's direction and when it changes give Pac-man a brief kick in the rear.

 

So, A0=last direction moved, A1=current direction moved. If A0<>A1 then is A0 180 degrees from A1? If so no corner else cornered and tempboost=1.

 

Pac-mans speed could always equal the base speed plus the tempboost amount. Normally tempboost would be zero but after a corner the tempboost would be a positive amount. The buffer could be extended and after x cells were all equal (Pac-man moving same direction for a while) the tempboost reset to zero.

 

I hope folks can follow that. It might not be arcade accurate but it might give Pac-man a way to shake the ghosties.

Edited by SIO2
  • Like 1
Link to comment
Share on other sites

The way I implemented cornering in my own game (which started as a clone of Pac-Man) was using a delta movement table for every possible position on a virtual tile. In the original Pac-Man, tiles are 8x8 pixels; in my game they were scaled to 4x4. This required 64 entries in the table:

 

4x4 pixels = 16 possible positions

Table = 16 x 4 possible directions = 64

 

This turned out to be surprisingly simple to implement, it just takes ROM to store, which is a scarce resource in the Atari VCS.

 

Here is a comment from my source code describing the technique:

; ===================================================================
; A "virtual" tile in the Christmas Carol maze is a 4x4.  The origin
; of the tile is two pixels from the left, and three from the top:
;
;      -1 0 1 2       |
;      +-------+      v
;   -2 |. . . .|    0 1 2 3
;   -1 |. . . .|    4 5 6 7
;    0 |. @ . .| -> 8 9 A B <- Center
;    1 |. . . .|    C D E F
;      +-------+      ^
;                     |
;
; This look-up table represents all available motions from every
; position in the tile.  We store the movement offset from the origin
; for each possible position.  For instance, from the origin (0, 0),
; the movement offsets are:
;
;   (0, 0):
;       ^ : (+0, -1) -> Move one pixel up
;       > : (+1, +0) -> Move one pixel right
;       v : (+0, +1) -> Move one pixel down
;       < : (-1, +0) -> Move one pixel left
;
; For "cornering", some positions allow a diagonal movement.  For
; instance, entering from the right (2, 0) and moving up:
;
;   (2, 0):
;       ^ : (-1, -1) -> Move one pixel up, one pixel left
;
; This diagonal movement will continue until the Elf reaches the
; center line, at which point, she will continue along the direction
; axis.
;
; The X and Y offsets are stored in ROM on a single 16-bit word as
; a scalar value biased by some magnitude.  For example, for a bias
; magnitude of +2:
;
;   (-1, -1): $0101     ; X: (-1 + 2 = +1), Y: (-1 + 2 = +1)
;   ( 0, -2): $0200     ; X: ( 0 + 2 =  0), Y: (-2 + 2 =  0)
;
;     F   E   D   C   B   A   9   8   7   6   5   4   3   2   1   0
;   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
;   |             X Offset          |            Y Offset           |
;   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
;
; To decode the value, just subtract the bias on retrieval.
;
; Copyright (c) 2010-2018, James Pujals (DZ-Jay)
; ===================================================================

And below is the table source I used, which I then compiled into the appropriate delta data for the table. I hope this helps.


; =============================================================================
; Virtual Tile Movement Matrix
; =============================================================================
; NOTE:
;   The maze "virtual" tiles are treated as a matrix of 4x4 points, each one
;   depicting a possible position where a sprite can reside at any time. The
;   table below should contain all positions for which movement is defined.
;
;   The format of the table is:
;
;       DIR | SOURCE | TARGET
;
;   Where the "DIR" value is one of the following direction attributes:
;
;       ^   -> Up
;       >   -> Right
;       v   -> Down
;       <   -> Left
;
;   and SOURCE and TARGET represent the source and target points, respectively.
;   The points should be taken from the diagram below:
;
;                        |
;                        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 movement is not defined for a specific point, it can be either supressed
;   entirely from the data, or represented by a null point of "()".
;
;   As with any other source data file, comments can be included on any line
;   by preceding it with a semi-colon ( character.  Blank lines or lines
;   consisting of only whitespace will also be ignored.  Surrounding whitespace
;   on any token, line or point, will be trimmed.
; =============================================================================
; Copyright (c) 2010-2018 James Pujals (DZ-Jay)
; =============================================================================

; ---------------------
; UP:
; ---------------------
^ | (-1, -2) | ()
^ | (-1, -1) | ( 0, -2)
^ | (-1,  0) | ( 0, -1)
^ | (-1,  1) | ()

^ | ( 0, -2) | ( 0, -3)
^ | ( 0, -1) | ( 0, -2)
^ | ( 0,  0) | ( 0, -1)
^ | ( 0,  1) | ( 0,  0)

^ | ( 1, -2) | ()
^ | ( 1, -1) | ( 0, -2)
^ | ( 1,  0) | ( 0, -1)
^ | ( 1,  1) | ( 0,  0)

^ | ( 2, -2) | ()
^ | ( 2, -1) | ()
^ | ( 2,  0) | ( 1, -1)
^ | ( 2,  1) | ()

; ---------------------
; RIGHT:
; ---------------------
> | (-1, -2) | ()
> | (-1, -1) | ( 0,  0)
> | (-1,  0) | ( 0,  0)
> | (-1,  1) | ()

> | ( 0, -2) | ( 1, -1)
> | ( 0, -1) | ( 1,  0)
> | ( 0,  0) | ( 1,  0)
> | ( 0,  1) | ( 1,  0)

> | ( 1, -2) | ()
> | ( 1, -1) | ( 2,  0)
> | ( 1,  0) | ( 2,  0)
> | ( 1,  1) | ( 2,  0)

> | ( 2, -2) | ()
> | ( 2, -1) | ()
> | ( 2,  0) | ( 3,  0)
> | ( 2,  1) | ()

; ---------------------
; DOWN:
; ---------------------
v | (-1, -2) | ()
v | (-1, -1) | ( 0,  0)
v | (-1,  0) | ( 0,  1)
v | (-1,  1) | ()

v | ( 0, -2) | ( 0, -1)
v | ( 0, -1) | ( 0,  0)
v | ( 0,  0) | ( 0,  1)
v | ( 0,  1) | ( 0,  2)

v | ( 1, -2) | ()
v | ( 1, -1) | ( 0,  0)
v | ( 1,  0) | ( 0,  1)
v | ( 1,  1) | ( 0,  2)

v | ( 2, -2) | ()
v | ( 2, -1) | ()
v | ( 2,  0) | ( 1,  1)
v | ( 2,  1) | ()

; ---------------------
; LEFT:
; ---------------------
< | (-1, -2) | ()
< | (-1, -1) | (-2,  0)
< | (-1,  0) | (-2,  0)
< | (-1,  1) | ()

< | ( 0, -2) | (-1, -1)
< | ( 0, -1) | (-1,  0)
< | ( 0,  0) | (-1,  0)
< | ( 0,  1) | (-1,  0)

< | ( 1, -2) | ()
< | ( 1, -1) | ( 0,  0)
< | ( 1,  0) | ( 0,  0)
< | ( 1,  1) | ( 0,  0)

< | ( 2, -2) | ()
< | ( 2, -1) | ()
< | ( 2,  0) | ( 1,  0)
< | ( 2,  1) | ()

  • Like 1
Link to comment
Share on other sites

Attached is the compiled table with actual values.

Here's an excerpt, with deltas for when the joystick is pressed up:

ELF_DELTA       PROC
@@data_start:
@@Up:           ; Direction: Up (^)
                ; ---------------------------------------
                ;                       Source:  Offset:
                ; ---------------------------------------
                DECLE   $0000   ;   0:  (-1,-2)  (+0, +0)
                DECLE   $FF01   ;   1:  (-1, 0)  (+1, -1)
                DECLE   $FF01   ;   2:  (-1,-1)  (+1, -1)
                DECLE   $0000   ;   3:  (-1, 1)  (+0, +0)
                DECLE   $0000   ;   4:  ( 1,-2)  (+0, +0)
                DECLE   $FEFF   ;   5:  ( 1, 0)  (-1, -1)
                DECLE   $FEFF   ;   6:  ( 1,-1)  (-1, -1)
                DECLE   $FEFF   ;   7:  ( 1, 1)  (-1, -1)
                DECLE   $FF00   ;   8:  ( 0,-2)  (+0, -1)
                DECLE   $FF00   ;   9:  ( 0, 0)  (+0, -1)
                DECLE   $FF00   ;  10:  ( 0,-1)  (+0, -1)
                DECLE   $FF00   ;  11:  ( 0, 1)  (+0, -1)
                DECLE   $0000   ;  12:  ( 2,-2)  (+0, +0)
                DECLE   $FEFF   ;  13:  ( 2, 0)  (-1, -1)
                DECLE   $0000   ;  14:  ( 2,-1)  (+0, +0)
                DECLE   $0000   ;  15:  ( 2, 1)  (+0, +0)
                ; ---------------------------------------
                DECLE   $0000   ;  16:  (-1,-2)  (+0, +0)
                DECLE   $FE01   ;  17:  (-1, 0)  (+1, -2)
                DECLE   $FE01   ;  18:  (-1,-1)  (+1, -2)
                DECLE   $0000   ;  19:  (-1, 1)  (+0, +0)
                DECLE   $0000   ;  20:  ( 1,-2)  (+0, +0)
                DECLE   $FDFF   ;  21:  ( 1, 0)  (-1, -2)
                DECLE   $FDFF   ;  22:  ( 1,-1)  (-1, -2)
                DECLE   $FDFF   ;  23:  ( 1, 1)  (-1, -2)
                DECLE   $FE00   ;  24:  ( 0,-2)  (+0, -2)
                DECLE   $FE00   ;  25:  ( 0, 0)  (+0, -2)
                DECLE   $FE00   ;  26:  ( 0,-1)  (+0, -2)
                DECLE   $FE00   ;  27:  ( 0, 1)  (+0, -2)
                DECLE   $0000   ;  28:  ( 2,-2)  (+0, +0)
                DECLE   $FDFE   ;  29:  ( 2, 0)  (-2, -2)
                DECLE   $0000   ;  30:  ( 2,-1)  (+0, +0)
                DECLE   $0000   ;  31:  ( 2, 1)  (+0, +0)
                ; ---------------------------------------

Note that "DECLE" is the Intellivision assembler's keyword for storing a 16-bit value (similar to "DATA" in any BASIC dialect).

  • Like 1
Link to comment
Share on other sites

I don't think diagonal movement is necessary imo. For instance, if Pacman is travelling up and four lines below a left turn when left is pressed, he would simply "warp" a couple pixels upwards and immediately begin a leftward trajectory. This behavior could potentially be abused by speedrunners however. Tapping left would snap pacman to the intersection, then tapping up immediately on the next frame would have him leaving the intersection in the same trajectory but a few pixels ahead of where he would have been without the cut.

 

If the player is a couple frames late so that pacman has left the intersection but not exited the snap to zone, he would still snap to an upwards trajectory and overall gain a couple pixels in vertical height. Even so, this would follow the spirit of the arcade game while allowing expert players to gain an advantage by warping. This doesn't cause any game breaking bus however so could be left intact.

 

Note that executing an up/left diagonal wont work in this case as left was the last cardinal direction actuated so pacman will still travel left instead of up even though up is still pressed. So you'd better find a goot four-way arcade stick before attempting to abuse corner cutting for speed boost. I like the idea of teleporting or snapping to the intersection to cut a corner. It follows the spirit of the arcade game even if the onscreen result is slightly different. 8)

  • Like 1
Link to comment
Share on other sites

I don't think diagonal movement is necessary imo. For instance, if Pacman is travelling up and four lines below a left turn when left is pressed, he would simply "warp" a couple pixels upwards and immediately begin a leftward trajectory. This behavior could potentially be abused by speedrunners however. Tapping left would snap pacman to the intersection, then tapping up immediately on the next frame would have him leaving the intersection in the same trajectory but a few pixels ahead of where he would have been without the cut.

 

If the player is a couple frames late so that pacman has left the intersection but not exited the snap to zone, he would still snap to an upwards trajectory and overall gain a couple pixels in vertical height. Even so, this would follow the spirit of the arcade game while allowing expert players to gain an advantage by warping. This doesn't cause any game breaking bus however so could be left intact.

 

Note that executing an up/left diagonal wont work in this case as left was the last cardinal direction actuated so pacman will still travel left instead of up even though up is still pressed. So you'd better find a goot four-way arcade stick before attempting to abuse corner cutting for speed boost. I like the idea of teleporting or snapping to the intersection to cut a corner. It follows the spirit of the arcade game even if the onscreen result is slightly different. 8)

 

That's what my algorithm does. The "diagonal" comes from the fact that you move one pixel in the current direction of travel, and one pixel in the new direction, cutting the corner. You still need some matrix to track where and how much to "snap" to, so you are not saving anything.

 

In my version, you don't have to do the computations in "real-time" because the table tells you where you need to go at all times, which saves a lot of cycles. It also constraints the movements to the grid, which comes for free.

 

The idea is to always accept the input, and not discard it, and use it to look-up in the table if it is legal to move. If it is, you move (diagonally if necessary). If not, you either continue facing a wall, or moving in the same trajectory; but you keep the input until the joystick is released because on the next frame it may be legal to turn.

 

It is very effective -- even on an Intellivision with a 16-way directional disc, with some clever heuristics to mimic a 4-way stick; and it gives the feel of the original game.

 

-dZ.

  • Like 2
Link to comment
Share on other sites

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. ;-)

 

  • Like 9
Link to comment
Share on other sites

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. ;-)

 

 

 

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!!!!

  • Like 1
Link to comment
Share on other sites

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...