Jump to content
IGNORED

Pacman4K


DEBRO

Recommended Posts

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 :D

 

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 :D

 

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 by DEBRO
  • Like 2
Link to comment
Share on other sites

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

Link to comment
Share on other sites

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 :D

 

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 :D 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.

  • Like 1
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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... :twisted: Nah, you probably want to get this done yourself, but you two would be a great team.

 

Keep up the great work,

Tony

Link to comment
Share on other sites

  • 1 month later...
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.

  • Like 1
Link to comment
Share on other sites

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 :)

Link to comment
Share on other sites

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.

  • 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...