New pacman for atari 2600

[Rhomaios]

The times are similar to the arcade, only the first 9 levels have a second more, the following levels are equal to the original, exept that the levels do not have the time with 0.5 seconds left. This means that from level 19, the "energizer timer" always will have 0.5 seconds and not 0 as the original, so I did this from the beginning to make the game easier.

Although perhaps could change it and leave it as the arcade.

Nah, keep it. This isn't to drain quarters, but to have fun. A little ease is sometimes welcome.

[+Nathan Strum]

About the eyes, I changed it because some mentioned that they seemed very small, but I prefer how it was before because it distinguishes better when they look up and down. I do not know if the majority thinks I should leave it as it was before.

 

 

I can take them either way. The larger eyes are more reminiscent of the arcade, but your point about it being easier to see which direction they're looking is a good one.

Edited October 15, 2014 by Nathan Strum

[Andromeda Stardust]

Another thing I noticed was that the intermissions lack much of the polish the rest of the audio in the game has. All the sound effects are perfect, then hearing the animation stages, it seems that less effort was made. Maybe you ran out of bytes and will fix this in the 8k version.

 

As for the whole "rounding corners" fiasco, a workaround would be to accelerate Pacman as he approaches the corner if a direction is being pressed. This would have the same net effect of diagonal corner cutting, but may be much simpler to program.

[+FujiSkunk]

Another thing I noticed was that the intermissions lack much of the polish the rest of the audio in the game has. All the sound effects are perfect, then hearing the animation stages, it seems that less effort was made. Maybe you ran out of bytes and will fix this in the 8k version.

Or maybe he's still working on it and wanted to show that he is working on it since the requests are becoming more and more rabid. Give the guy some room to breathe already!

 

As for the whole "rounding corners" fiasco, a workaround would be to accelerate Pacman as he approaches the corner if a direction is being pressed. This would have the same net effect of diagonal corner cutting, but may be much simpler to program.

And much more prone to unintended side effects.

[Andromeda Stardust]

 

 

And much more prone to unintended side effects.

Everything has unintended side effects. Change one wrong byte and the game goes apesh!t. You should see how badly some of those rogue Game Genie codes can screw with Super Mario Brothers.

Edited October 15, 2014 by stardust4ever

[Nukey Shay]

No, not everything. Some routines assume/expect a given set of parameters or values...others do not. This is especially true of complex programs for platforms with very limited resources, because variables are often shared for multiple purposes. This game uses the method of cutting frame delay when changing direction (as does the one from Dennis). The optimum solution is to check if a different direction is pressed immediately upon reaching an intersection (and move if so).

[+darryl1970]

Hi, these days I have been testing the "flicker variable" in the 8K version, so I had not updated the 4k version as fast as it should.

In reference to the monsters' eyes: I think they are best how they are now. I played around with hacking the 8-bit version. I originally liked the bigger eyes, because I felt they resembled the arcade. However, since the dots appear through the eyes, I think it really distorts the look. So, I think the idea is better in theory than practice. The way they are now is probably the most solid solution for a single color monster, especially since these monsters do flicker some. Since they are already semi-transparent, I think the dots behind may distort them even more.

 

Speaking of the flicker though... Are you considering multicolor monsters for the 8k version, since you're testing the flicker version? Hmm. That would be cool, but not if it affects gameplay.

[Andromeda Stardust]

In reference to the monsters' eyes: I think they are best how they are now. I played around with hacking the 8-bit version. I originally liked the bigger eyes, because I felt they resembled the arcade. However, since the dots appear through the eyes, I think it really distorts the look. So, I think the idea is better in theory than practice. The way they are now is probably the most solid solution for a single color monster, especially since these monsters do flicker some. Since they are already semi-transparent, I think the dots behind may distort them even more.

 

Speaking of the flicker though... Are you considering multicolor monsters for the 8k version, since you're testing the flicker version? Hmm. That would be cool, but not if it affects gameplay.

If you mean the big eyes with black googley looking circles, I'd prefer to keep it clean and simple small squares. Yes the arcade had animated ghost sprites with eyes that had whites and looked different ways, but the VCS doesn't support multicolor and the black squares IMO look better than googley eyes. Since they also can't convey direction, it simplifies the code a lot by not having four sets of sprites. Or you could change the position of the black dots to simulate looking around at the expense of extra tile data. Simplification of sprite art is a given on VCS, so I'll take whatever I can get.

 

As for flicker, I think DIN wants to use intelligent flicker to minimize the flicker effect when ghosts are on different scanlines. Coding such behavior is not trivial.

[+darryl1970]

If you mean the big eyes with black googley looking circles, I'd prefer to keep it clean and simple small squares. Yes the arcade had animated ghost sprites with eyes that had whites and looked different ways, but the VCS doesn't support multicolor and the black squares IMO look better than googley eyes. Since they also can't convey direction, it simplifies the code a lot by not having four sets of sprites. Or you could change the position of the black dots to simulate looking around at the expense of extra tile data. Simplification of sprite art is a given on VCS, so I'll take whatever I can get.

 

As for flicker, I think DIN wants to use intelligent flicker to minimize the flicker effect when ghosts are on different scanlines. Coding such behavior is not trivial.

The monsters eyes currently do move on this version, the same as the original 8-bit Pac-Man moved. I think moving the little squares as they do now do convey direction, but it's subtle. Since they're not truly black, but the background, larger eyes start to show the dots underneath the monsters. It begins to look ugly. So, two votes for monsters with squares instead of big gaping holes.. lol. Looks great now!

 

I figure the flicker thing is just optimization. Sometimes optimizing can also allow more sprites per line, thus having a white layer. It was done in that Ms.Hack, but I think it would be a waste of time on this port. It's too clean how it is now, and too many players can slow stuff down and make things appear to jump around. Again, I am happy where it is now.

[Nukey Shay]

Ms.Hack uses 3 frames for the title character (2 showing the yellow bitmap and 1 for the red bow). This was fine, since the sprite was always that character. I tried using this for the multiplexed enemy/fruit sprite, and the animation became way too choppy. The only alternative would be to position the alternate missile sprite under the bitmap (using it's own missile doesn't work because the color is the same, and the ball would be the same color as the underlying PF)...OR multiplex all sprites and use both for each character. Optimizing the code gets you nowhere...the hardware still only has 2p 2m 1b on any given scanline.

[Andromeda Stardust]

Well, at least we have actual fruit this time instead of a "vitamin" that uses the ball sprite. Kudos on making the lower right fruits multicolored in some cases.

 

And it is technically possible to reuse sprite data on the same scanline by updating the TIA in the interim. Space Instigators does this to produce 9 sprite across the screen with zero flicker. Someone suggested using the ball sprite to expand the power pellets without having the blue "Oreo" effect. Bah whatever. Such trickery may not be possible to code in depending on the available CPU cycles in the current engine.

Edited October 16, 2014 by stardust4ever

[Nukey Shay]

Sprite duplication/reuse is possible when spacing is consistent (this is more common in score displays, for example). That method is not possible to use for stuff that needs to be able to overlap...like 2 enemies sharing the same tile. BTW the ball was *originally* used (that sprite shares PF color, hence the previous sandwich appearance). Current versions use a missile.

[Nukey Shay]

BTW Space Instigators uses a couple of tricks above the regular hardware sprite duplication. The scanlines coarse position both sprites multiple times to exceed the number of copies, and placing the routine in ram memory provides self-modification to the code (to skip copies that have been shot). Both of these methods still wouldn't solve the issues for Pac-Man's free roaming sprites: coarse positioning doesn't provide variable distance between sprites**, and the lack of remaining cycle time within a scanline means that bitmap data cannot be altered***

 

 

** There is a slight workaround, since the number of machine cycles wasted between RESPx rewrites can be adjusted in a self-modifying kernel. However, this is limited to 3-pixel jumps per cycle...so it's unlike the smooth animation that free-roaming sprites would require. It's actually possible to get 11 sprites per line as shown by the original demo which inspired Space Instigators (way back in 1998 IIRC). Fine positioning (HMPx) is still off-limits regardless, since that requires end-of-scanline HMOVE's to do it's business.

 

 

*** The original Space Invaders alters bitmap data within a scanline (that's how it's able to show invader explosions)...but it has most of it's cycle time available to do this because it's only using the built-in 3 copies per sprite and does not need to waste cycles on calling RESPx during the actual display of each scanline.

Edited October 17, 2014 by Nukey Shay

[Andromeda Stardust]

Honestly there's so much going on already with Pacman. Another thing to consider is each pellet takes a bit of memory away from the kernel, so all things considered it's a stellar port and the flicker or the ice cream sandwich power pellets don't bother me. Just the fact that DIN got in solid outer walls amazes me.

[Nosnhojr]

This is amazing in every sense of the word. Most of us accept that the 2600 isnt the most powerful system, but if the idea is to give a sense of playing the arcade game you have surpassed that in every aspect. Great work.

[Nosnhojr]

Are you in a position to release the WIP of the 8k version?

[dashv]

Maybe I've already said it but in case I haven't: Great job!

 

If this gets a cart release I am definitely buying!

[Andromeda Stardust]

Are you in a position to release the WIP of the 8k version?

It will be ready when it is ready. I would love to buy the "Full Monty" from the AA store someday. 8k, 16k, 32k matters not. The more perfect he can make this, the better.

[Brian O]

Any updates?

[DINTAR816]

Hello, I made a small update of the version of 4k, in this version I change the music intermission, add the "ready" (very small) and the third intermission now plays before levels 10, 14 and 18 as should be.

Now the "cruise elroy 1 and 2" are activated with a certain number of "dots" depending on the level as it should be (previously activated with two fixed values​​).

pacman2600_4k_int4.bin

I have not made ​​much progress in this version because I've been working more on the 8k version.

In this version of 8k I change the "kernel" to get back using the "BALL" for "power pills" now has a solid color, but I had to reduce it to 3 lines, to allow sufficient time for "hmotion" routine.

I'm also going to change the sound code to be easier to make the sounds, as close to the original (it will use more bytes for the sounds, but for this version it does not matter).

For intermissions I'm doing a separate kernel for improving them.

I'm also going to add a few options such as:

difficulty

points of dots: 10 or 15, "power pill" 50 or 65

pacman turbo speed, with "fire button"

and more.

Here I show you some pictures of this version of 8k:

Edited October 27, 2014 by DINTAR816

[Albert]

Excellent, glad to see an update!

 

You know what would be cool when you're finished? A cartridge version of the game that lets you select either the 4K version of the game or the enhanced 8K version from a menu.

 

..Al

[Albert]

So, this particular game runs very slowly for me in Stella 4.x (just updated to 4.1.1). Has anyone else seen this? The game seems to be running at about one-quarter the speed it should be, maybe even slower. I'm running in OS X, Yosemite, with a 4K display, on a Mac Pro (it's a very fast machine). I'm not seeing this slowdown with any other games. I tried deleting the app's preferences and Application Data folders, and that didn't make any difference. Does anyone have any ideas?

 

..Al

[Thomas Jentzsch]

Works fine with 4.1

[DINTAR816]

So, this particular game runs very slowly for me in Stella 4.x (just updated to 4.1.1). Has anyone else seen this? The game seems to be running at about one-quarter the speed it should be, maybe even slower. I'm running in OS X, Yosemite, with a 4K display, on a Mac Pro (it's a very fast machine). I'm not seeing this slowdown with any other games. I tried deleting the app's preferences and Application Data folders, and that didn't make any difference. Does anyone have any ideas?

 

..Al

This could be for one of two things, this game has 194 lines of image when most games are 192, or maybe it could be because I do not use the reg "VBLANK" to deactivate the "TIA" during the "overscan" in this rom.

[Albert]

This could be for one of two things, this game has 194 lines of image when most games are 192, or maybe it could be because I do not use the reg "VBLANK" to deactivate the "TIA" during the "overscan" in this rom.

I wonder if I'm the only one seeing this particular issue. I doubt it's the scanline count, since many games go over 192 lines without any issues (at least in Stella). I can't speak to the "VBLANK" register, though. Need to try this on my laptop (also running Yosemite) to see if the same thing happens. Better, still, will be to test this latest version out on real hardware.

 

..Al