Pacman4K

[DEBRO]

Hi there,

 

This is something I've been doing off and on. I started writing this up about the time I was finishing up Climber 5.

 

@Nukey Shay and opcode

Here it is...finally

 

This is more of a fan project than anything. This is my favorite coin-op and I've wanted to do this since I bought the original cart as a kid. I don't know what I'll do with this when/if I finish it. I've got a number of things on my to do list. One of them is possibly entering the Mini Game Compo this year.

 

I'm exerimenting with timings right now. You'll notice some times where the maze changes color. This is when the fruit should appear. As you can see the timing needs a little work.

 

I still need to do some work in the kernel too. The flicker is really not where I want it to be. Still I think it's a good start.

 

If you press the fire button the background will change. This is so you can see there are no HMOVE lines in the maze area. Ignore the ones in the score and status kernels

 

Anyway..here it is...enjoy.

 

 

Edit...changed topic title

 

Edit...added final Pacman4K build. Archive contains both NTSC and PAL50 versions.

kernel_test.bin

Pacman4K.zip

Edited November 30, 2008 by DEBRO

[ZylonBane]

Since DEBRO neglected to mention what actual game he's talking about-- it's Pac-Man.

[uosipa llamxew]

Looks great so far!

[Zach]

[PacManPlus]

This looks awesome

 

I really hope you finish this -it's the best-looking 2600 version yet!

 

don't forget to make the 3200 point graphic and point table so we can make 'Plus' out of it!

[vdub_bobby]

[Lost Monkey]

Wow! Fantastic job so far!

[supercat]

I'm exerimenting with timings right now. You'll notice some times where the maze changes color. This is when the fruit should appear. As you can see the timing needs a little work.

1000202[/snapback]

 

It's hard to judge certain aspects of the kernel just by watching the demo; the monsters' motion is set up so that there are never more than two P1 objects on a scan line; it's impossible to tell how you handle that case.

 

I personally prefer from a gamer's perspective kernels that can share both P0 and P1, since such kernel designs often tend to flicker less than those that cannot. I believe Pesco/HackEm do this. While I appreciate your efforts at using Cycle-73 HMOVEs to avoid HMOVE bars, I'm not really sure it's a benefit here. You're never showing anything on the first 8 pixels of a "dot" scan line anyway. Perhaps in a different game it could be helpful, though.

 

I will grant that your demo certainly looks very nice. Without knowing the intricacies I can't tell how well it would translate into a game. Perhaps you need to demonstrate.

[Cybergoth]

Hi there!

 

I will grant that your demo certainly looks very nice.

 

Fully agreed. My only point of critic would be that it's just Pac-Man again...

 

Greetings,

Manuel

[DEBRO]

It's hard to judge certain aspects of the kernel just by watching the demo; the monsters' motion is set up so that there are never more than two P1 objects on a scan line; it's impossible to tell how you handle that case.

Hmmm....that's a good point. In theory in the worst case scenario they should flicker at 12htz. The fruit is not enabled that much so the worst case may not happen too often but it can. I'll be playing around with the kernel and flicker algorithm to try to reduce the flicker as much as possible. My eyes have gotten less sensitive to flicker in my old age.

I personally prefer from a gamer's perspective kernels that can share both P0 and P1, since such kernel designs often tend to flicker less than those that cannot.  I believe Pesco/HackEm do this.

I agree with you. I'd like exeriment with this. Moving 2 sprites in this 1LK will be tight but worth a try. That's part of the fun with programming the VCS

 

BTW, Pesco/HackEm does not do this. The ghosts and fruit share the same sprite so they would use a similar technique as I do. One thing they do is restrict the ghosts vertical movement.

 

While I appreciate your efforts at using Cycle-73 HMOVEs to avoid HMOVE bars, I'm not really sure it's a benefit here.  You're never showing anything on the first 8 pixels of a "dot" scan line anyway.  Perhaps in a different game it could be helpful, though.

HMOVE is hit before the dot kernel. There are about 3 scan lines where I don't have to draw any PF data. This is where HMOVE is happening. So hitting HMOVE normally would black out part of the maze. I had done the HMOVE during the dot kernel but that was too late. You would see the first part of the sprite data shifted to the right and then the rest positioned correctly. Also if I hit HMOVE normally during the dot kernel you could see it when the sprite entered/exited through the left tunnel.

I will grant that your demo certainly looks very nice.  Without knowing the intricacies I can't tell how well it would translate into a game.  Perhaps you need to demonstrate. 

I hope I can There's still a lot of work to do.

Fully agreed. My only point of critic would be that it's just Pac-Man again...

You're right and this is why I've stopped doing this a number of times. I've asked myself many times does the VCS need yet another Pac-man. This was really an exercise for me plus this was my favorite coin-op. When/if I finish this I don't know what I'll do with it. If anything, I'll have a cart made for myself.

[ZylonBane]

If you want a REAL challenge... Super Pac-Man is calling to you...

[Rob Mitchell]

Is anyone really surprised that you would program another pac-man!

 

Why don't you call it Debro-Man!

 

Rob Mitchell, Atlanta, GA

[supercat]

BTW, Pesco/HackEm does not do this. The ghosts and fruit share the same sprite so they would use a similar technique as I do. One thing they do is restrict the ghosts vertical movement.

 

I thought I'd seen two ghosts sharing a line without flicker. I'll have to look some more at that.

 

If you use a "zone-based" kernel, I don't see why making both sprites re-assignable would be more CPU-cycle intensive than allowing just one. RAM would be more of an issue, but not CPU time. Actually, if you can afford the space to pad sprite data with blanks, you could even save CPU time.

 

HMOVE is hit before the dot kernel. There are about 3 scan lines where I don't have to draw any PF data. This is where HMOVE is happening. So hitting HMOVE normally would black out part of the maze. I had done the HMOVE during the dot kernel but that was too late. You would see the first part of the sprite data shifted to the right and then the rest positioned correctly. Also if I hit HMOVE normally during the dot kernel you could see it when the sprite entered/exited through the left tunnel.

 

The idea would be that you'd perform the HMOVE on a line of dots where the Pac/Monster wasn't. As for the tunnel, depending upon the size/placement of the zones there wouldn't need to be an HMOVE there.

[+Nathan Strum]

Very nice, indeed. If only something like this would have been done for Atari's version...

[Atariboy2600]

YES A real Pac-Man port! Hope it has the demo-play cartoon as well^_^

[Atariboy2600]

Here's an updated version of the label art of Pac-Man Arcade label I drew last year but took out the word ARCADE EDITION and just call it Pac-Man. I also made two diffent end label one with old Atari silver text and one from Pac-Man text.

[Albert]

I'll repost my comments from the Stella list..

 

--

 

Looks good--the ghosts remind me of the 5200 version of Pac-Man! Also, very nice with all the fruit graphics! Wish there was a way to avoid having the gaps in the playfield maze, though (which evokes memories of Ebivision's Pac-Man). It would seem that a respectable version of Pac-Man is somewhat of a holy grail of 2600 programming. I look forward to seeing further progress!

 

It would be interesting to see someone try to do a vertical maze without using scrolling, to more accurately reflect the aspect ratio of the arcade machine (which has the monitor rotated 90 degrees).

 

Even with the various flavors of Pac-Man on the 2600, I still think there's room for improvement in replicating the original arcade game. How much room, I don't quite know.

 

..Al

[Atariboy2600]

I'll repost my comments from the Stella list..

 

--

 

Looks good--the ghosts remind me of the 5200 version of Pac-Man!  Also, very nice with all the fruit graphics!  Wish there was a way to avoid having the gaps in the playfield maze, though (which evokes memories of Ebivision's Pac-Man).  It would seem that a respectable version of Pac-Man is somewhat of a holy grail of 2600 programming.    I look forward to seeing further progress!

 

It would be interesting to see someone try to do a vertical maze without using scrolling, to more accurately reflect the aspect ratio of the arcade machine (which has the monitor rotated 90 degrees).

 

Even with the various flavors of Pac-Man on the 2600, I still think there's room for improvement in replicating the original arcade game.  How much room, I don't quite know. 

 

..Al

1001116[/snapback]

 

I beleave the resion why it seem that Pac-Man keeps coming back in many diffent upgrades in grafix cuase after the first origanl release of the old Pac-Man we gave all of us Atari player a very bad taste in our mouth for 20+ years and we always dream of what if they got it right the first time way back or maybe waited till there cartirge space got larger or some what and maybe this time with this cart we can finaly get that dreat Pac-Man arcade port on the 2600 right.

[NE146]

It looks friggin great.

[Big Player]

I know it's only a demo but it's it is just as playable and has better sound than Ebivision Pac-Man.

[atwwong]

Dennis, just a few random thoughts...

 

Maybe when your done with PM, you could do minor alterations to the graphics and sell it as a homebrew.

 

Team up with Nukey... Nah, you probably want to get this done yourself, but you two would be a great team.

 

Keep up the great work,

Tony

[Heaven/TQA]

you could implement a easter egg to switch back the gfx to original pac man and the official version has altered gfx to keep namco away...

[DEBRO]

The idea would be that you'd perform the HMOVE on a line of dots where the Pac/Monster wasn't.  As for the tunnel, depending upon the size/placement of the zones there wouldn't need to be an HMOVE there.

I'm looking into re-writing my mock-up kernel. I want to remove the write to HMOVE at cycle 71 since it's reported that it could cause problems on some PAL systems.

 

I guess I'm missing your point about the HMOVE lines. I could end up with a HMOVE line in the tunnel. A ghost could be right below the tunnel which would cause an HMOVE line to be shown there.

 

I could make the objects sort of "jump" to the right side tunnel when they reach this limit on the left side but I don't like that the object would seem to magically appear on the right vs. having the smooth transition.

[Lord Helmet]

I'm a really big Pac-Man fan, so the more versions the better. It's fun to see so many different programmers efforts to do this game on the 2600. This one looks great so far. It reminds me of ebivision pac man, but the ghost animations are better. Nuley set the bar awfully high with his hack. Gives you bar to shoot for! Great work so far

[DEBRO]

I'm a really big Pac-Man fan, so the more versions the better.

So am I. It's my favorite coin-op.

It's fun to see so many different programmers efforts to do this game on the 2600. This one looks great so far. It reminds me of ebivision pac man, but the ghost animations are better. Nuley set the bar awfully high with his hack. Gives you bar to shoot for! Great work so far

I can't deny that it looks like Ebivision's version. I used it sort of as a model. I think my maze is a little more like the arcade though.

 

I want to make this as close to the arcade as I can get. I don't know if I'll include intermissions yet. Right now I want to focus on the game play. In the demo I posted some have said they think Pac-man moves a bit slow. That's the frame delay that's used in the arcade for the cherry level. I agree that it can be improved. All delays/timings will be tweeked a bit to fit the resolution of this version. The main obstacle for me right now is RAM usage.

 

Kurt did GREAT work on his hack. I stopped working on this a couple of times because of his excellent hacks. To his credit, everytime I've stopped, he kept pushing me to continue.