Baby Pac-Man

[Atariboy]

I bet in a few months you'll wake up in the middle of the night with the solution in your head, hop on a PC, and post a finished rom ready for final testing here at AtariAge a few hours later.

 

I can't imagine a mind like yours staying blocked for long.

[Kurt_Woloch]

OK... obviously I was only talking about Pac-Man like games being based on Ms. Pac-Man... you can't base Scramble, Circus Atariage or Berzerk on what was originally a Pac-Man game.

 

There's one more game I see some similarities with... Bentley Bear's jumping physics are also affected by gravity, as is the ball in Baby Pac-Man. However, it's obvious to me that the physics in Bentley Bear is somewhat "tweaked" since he comes down much faster than he goes up, which wouldn't happen this way in real life.

 

Feel free to use any of the routines or ideas I posted earlier if you (or your fellow programmer) can understand any of them and find a place for them! I can also try to find the "connection" of my routines to your existing source code if this would help.

 

Actually, not all of them: KC Munchkin, Astro Fighter / Blaster, Moon Cresta, Scramble, SCAA, Rip Off, Bentley Bear, Frenzy, Failsafe, Crazy Brix, etc. were all written from scratch, as was all of Baby Pac-Man. It's just this angle crap I'm having a hard time with.

Having said that:

- Super Circus Atari Age used a predetermined table for the clown movement (just like the original Circus Atari)

- Crazy Brix and Frenzy were not hard to deal with; all angles were at flat horizontal or vertical surfaces. Those are easy.

 

Thank you - all of you - for help and encouragement. I have received some PMs from another programmer (who is an excellent programmer, as well as a great person) offering to help and I will see what I can do.

Edited August 25, 2018 by Kurt_Woloch

[PacManPlus]

Thank you -

 

Believe it or not, I took the jumping directly from the Super Mario Bros. source code, but I had to increase the top of the arc as Bentley wasn't reaching the platforms I needed him to.

 

All:

 

There are two people helping me at the moment, so between the three of us I think I can say that we will be getting past this hurdle. I'm taking help from anywhere I can get it. As I've said before, I just need to get started with something that works, and I can take it from there.

 

Thanks, guys - hopefully this will now become a reality, and BPM will finally get a home port.

 

Bob

Edited August 27, 2018 by PacManPlus

[Albert]

That's great news, glad you're getting help from some others. Look forward to seeing the pinball portion of Baby Pac-Man working!

 

..Al

[TrekMD]

That is excellent and glad to see community support is helping this move forward.

[Andromeda Stardust]

Glad you are coming up with a solution PMP. Again, please consider using a rectangular x/y coordinate system rather than a polar angle/vector system. It will make things much simpler, even if lookup tables are still necessary to tweak collisions.

[Swami]

Best of luck to the team. I hope you are feeling better.

 

If it helps: a circle is a polygon with infinite sides one point each in length. One way to start out might be to start with squares or hexagons for circular bumpers and work your way up in sides. Same principle if there are any curved bumpers in the pinball game.

[Atariboy2600]

Thank you -

 

Believe it or not, I took the jumping directly from the Super Mario Bros. source code, but I had to increase the top of the arc as Bentley wasn't reaching the platforms I needed him to.

 

All:

 

There are two people helping me at the moment, so between the three of us I think I can say that we will be getting past this hurdle. I'm taking help from anywhere I can get it. As I've said before, I just need to get started with something that works, and I can take it from there.

 

Thanks, guys - hopefully this will now become a reality, and BPM will finally get a home port.

 

Bob

 

 

Awesome news.

[maxdrive]

That's great I'm sure you guys got this wish I had the skills you guys do

[ZylonBane]

Looking at the Baby Pac playfield, it seems chunky enough that you could get away with assigning a collision angle to every character cell of the playfield. Assuming you can do per-pixel collision of the ball against the playfield, that would get you playfield physics decently enough. As for the flippers, you could use the same approach for when they're full down and full up, but for the actual flipping, a pre-computed table of angle-velocity modifiers for each horizontal pixel of the flipper might be the way to go.

[PacManPlus]

We can lock this topic now.

 

Baby Pac-Man source code given in the '7800 Programming forum'.

I'm done.

[+x=usr(1536)]

We can lock this topic now.

 

Baby Pac-Man source code given in the '7800 Programming forum'.

I'm done.

 

Thank you for all the work you've put into this, Bob. It's a hell of an accomplishment as it stands, and your release of the source is greatly appreciated.

 

Seriously - good job. Thank you.

[Inky]

Thank you for your hard work on this PmP!

[TrekMD]

I was just playing the maze portion of the game today and it really is fantastic! Thanks for what you did, Bob! Hopefully, someone else can work the pinball side of the game so we can get the full game.

[Jinks]

I know it must suck like no one here can fathom to put all the hard work in and make an excellant game of professional quality up to the point of the mfking pinball portion and get jammed up.

Please know we all think you are awesome!

[Mayhem]

Yes, you are arguably the best 7800 programmer out there Bob also helps you share my birthday

[Kurt_Woloch]

Well, thanks Bob for this phenomenal work you did. As "promised", I took a deep look into the source code you posted. The first thing I found embedded in the ZIP files were the latest binaries where even the maze part seems to be a bit refined compared to the binaries that were last posted here. As for the code itself, I think I'd know where and how to continue, although I can't promise having the stamina to really complete the pinball part on my own (for me it's mainly about the time needed). Moreover, I never programmed for the 7800 before, though I did a lot of 6502 code for other systems. At the moment my free time is sparse though, but that might improve over the next weeks. I won't tell much more here right now because I don't know if anyone is supposed to build on that code or even publicly comment on what's been done and what's not, or if this topic should just be closed and the game be left as unfinished as it is now.

[PacManPlus]

Thanks guys... You are all too nice.

 

Kurt took the source code and ran with it. He's going to start me off (sorry that I have such a hard time 'getting' this stuff), and I will take it from there. I am going to replace the 'point value' screen during attract mode with the names of the people who helped me under 'special thanks'.

[Trebor]

Sounds like a great plan. Some awesome team work brought us the amazing Bentley Bear's Crystal Quest.

Baby Pac-Man appears to be destined for greatness as well.

[maxdrive]

Yeah one of the most underrated Pac man games a personal fav of mine I can not wait

[Kurt_Woloch]

Here's a little update... I've worked on this for a few hours now, and so far I've implemented the check for a slanted line (or should I simply say a diagonal?), so that now the game correctly detects when the ball has hit the right surface of the left bumper. That's not much, but it's a start...

 

however, I'm now unsure how to handle the aspect ratio correctly. To explain what I mean, the actual table of Baby Pac-Man has about a depth to width ratio of 7 to 6, while the table on the 7800 version is 216 x 128 pixels, which is a ratio of 27 to 16. While this would suggest that the table is higher than usual, this is actually more than compensated by the pixel aspect ratio of the 160 modes of the 7800. I guess that in PAL one pixel in that mode is twice as wide as it's high, so that would stretch the visible aspect ratio to 27 to 32, so it's a bit more wide than high. On NTSC, the pixels are about 20% higher, so there the aspect ratio would be 32.4 to 32, or 81 to 80. Now, the question is if this should represent a playfield which is actually 27 to 32, or 81 to 80 in size, or if it should represent one with a ratio of 27 to 16 with the pixels simply being squashed.Moreover, the ball is 7 pixels wide and 11 pixels high, which in PAL would look like 11 high and 14 wide, and in NTSC it looks like 13.2 high and 14 wide. Measured in percent of the playfield, this is 5.09% of the total height and 5.47% of the total width. On the original playfield, if the ball is round (which it should be), it occupies roughly 5.17% of the width and 4.4% of the height of the playfield (but that's not super exact).

 

Where this comes into play is when the ball is deflected from a surface that's not purely horizontal or vertical, because in that case, the angles, if stretched, might not look correct. The question is what to do here... should the playfield be assumed to be "squashed"? Or should the aspect ratio look right if watched on NTSC? Or on PAL? Just to illustrate this, depending on what the aspect ratio is, an incoming ball might be deflected at a different angle. To illustrate this, the picture shows the left bumper and an incoming ball. The question is, which deflection angle (assuming no additional power from the bumper) would be the right one?

 

Let's assume the ball coming in at the angle shown with the red arrow. With pixel aspect ratio 1:2, this would be a 45° diagonal. The bumper's surface, as I have measured and calculated, has a slant of 5/23, so with the aspect ratio this is stretched to 10/23, which is about 113°. Thus in this case the ball would be deflected so that it comes back at an angle of 1°, which is a bit over a horizontal line to the right. I'm showing this as the green arrow.

 

However, if I assume the ratio to be squashed differently (like the ball is), the slant would change to 7.86/23, which is about 109°. At the same time, the ball incoming at the same angle would actually have a speed (relative to it) of 1/14 "ball units" to the left and 1/11 "ball units" up, changing the incoming angle to 52°. This would cause the ball to come back at an angle of -14°, which is quite a bit under a horizontal line (1 down, 4 right), but measured in ball sizes, so it's actually 1 down, 5.09 right. I'm showing that direction as a blue arrow.

 

Finally, if I assume the actual pixel ratio to be correct, the slant changes to only 5/23, which is about 102°, and the ball now does 1/2 pixel to the left for each one down, changing the incoming angle to 63°. This would cause the ball to come back at an angle of -39°, which is nearly a diagonal, but shown at the pixel aspect ratio, so on screen it would be 1 down, 2 right. I'm showing this as a yellow arrow.

 

 

Now the question to you all is: Which angle do you think would be the right one?

[Atariboy2600]

How come it getting hard to do a pinball game even if there some on Atari systems but most are on Atari 8-bit and the 7800 is different then the other Atari

 

 

 

 

 

[PacManPlus]

Basically, because I'm an idiot.

 

Kurt, I'll take a look at the stuff you gave me tonight.

[Kurt_Woloch]

Hmmm... OK, I watched all three of those videos. In all three of them, however, they kept the usual aspect ratio of pinball tables, i.e. they are clearly higher than wide, or at least square. Also the ball doesn't look as squashed, but really round so in those games I'd assume that the correct deflection would involve angles that look right when shown on screen. If this is what you mean by those examples, then the best solution probably would be to assume that for deflection angles, a pixel is actually twice as wide as high (as it actually is in PAL).

[RevEng]

How come it getting hard to do a pinball game even if there some on Atari systems but most are on Atari 8-bit and the 7800 is different then the other Atari

Your reasoning isn't sound here. The basis of your comment seems to be "A8 pinball games exist, so they must not have been difficult to program."

 

Loads of difficult programs exist. Rescue on Fractalus isn't proof that fractal landscapes are easy, either.

 

If you were to ask Dave Snider, Bill Budge, or Bruce Artwick, I think they'd all agree that a pinball sim on 6502 is a tricky thing to code.