Jump to content
IGNORED

Baby Pac-Man


PacManPlus

Recommended Posts

I know it's early and haven't even seen the ball in play, but the light blue on the play field might be better served as black. I know that choice wouldn't be as "authentic", but might be a better fit. And easier on the eyes, especially when tracking the ball. Just my $.02.

  • Like 1
Link to comment
Share on other sites

There has been quite a number of updates since the last video, the below is a quick one covering all (updated) sounds from the video portion and then a showcase of the latest table with bumpity, bump, bump...bump, bump:

 

https://www.youtube.com/watch?v=LK_OB2jc2Xc

 

Sounding (and looking) excellent! This is above and beyond!

 

One minor observation- In the arcade, you don't hear the background 'siren' noise while eating dots.

  • Like 3
Link to comment
Share on other sites

OK, here's another thing about the formulas I gave earlier... in them, I converted the ball movement into movement relative to the target and back to x/y using two turning matrices. But of course it's possible to roll those two into one matrix which will calculate the resulting speed values directly. To do this, you have to combine the formulas, so that:

 

x'' = x * (-cos(a)^2 + sin(a)^2) + y * sin(a) * cos (a) * 2
y'' = x * cos(a) * sin(a) * 2 + y * (cos(a)^2 - sin(a)^2)

 

Now this is a more complicated formula than the one above, but you can precalculate all the terms X and Y have to be multiplied with, and some of them even occur in both formulas. So you basically you need the following values calculated:

sin(a)^2 - cos(a)^2

cos(a)^2 - sin(a)^2 (which is the negative of the previous value)

sin(a) * cos(a) * 2

 

What's more, due to special properties of sinus and cosinus, the terms we are looking for also describe sinus curves, so that:

sin(a)^2 - cos(a)^2 = -cos(a*2)

cos(a)^2 - sin(a)^2 = cos(a*2)

sin(a) * cos(a) * 2 = sin(a*2)

 

Therefore, the term that directly transforms the source direction vector to the final direction vector gets reduced to:

x'' = y * sin(a*2) - x * cos(a*2)
y'' = x * sin(a*2) + y * cos(a*2)

 

So this basically reduces the necessary calculation to 4 multiplications, at least if you know the angle and thus the sin and cos values beforehand. Remeber, they apply to the slant of the object being hit, not to the angle at which the ball is hitting it.

 

And even for the "circle" collision check I described earlier, those sin and cos values should be able to be calculated rather easily by taking into account the position of the ball relative to the center of the circle.

 

For the collision check, we calculate the following values:

dx = x of ball - x of circle center

dy = y of ball - y of circle center

dx2 = dx * dx, this is dx2 squared

dy2 = dy * dy, this is dy2 squared

dx2+dy2, this is the sum of dx2 and dy2

r, the radius of the circle (pre-stored in ROM)

r2, this is the squared radius (can be looked up in a lookup table or already stored in ROM for that check)

 

Now the sin value is actually roughly (dx / r), and the cos value is roughly (dy / r)... OK, we need to do two divisions here, of a type that calculates a fraction of a byte value by another byte value (and expresses it in a byte where 0 = 0 and 255 in that byte = 1, so like a subpixel value).

You can now square the sin and cos values by multiplying them by themselves (or possiby using another lookup table for that) using a multiplication of two 8-bit values giving a 16-bit value out of which only the top 8 bits get used.

 

OK, I think I get carried away here... ;-)

 

Anyway, I also tried the latest binary. I think the ghosts now move a bit more random now, which is good. I also see the color change in the mazes when they repeat has been implemented, which is good as well.

 

As for the ball, I've seen that too. There was a yellow ball in there... I can imagine adding that as an option with the yellow ball being slightly bigger, lighter and "springier" than the normal grey ball... as if the yellow ball was made out of rubber vs. the normal steel ball.

 

As for the sound, as far as I know the Baby Pac-Man machine's sound hardware is probably derived from that of pinball machines and only plays one sound effect at a time which in turn may use multiple channels. So the way I'd do it would be to also play only one sound effect at a time, but let sound effects use both sound channels at once.

  • Like 2
Link to comment
Share on other sites

Hi Guys:

Thank you for the kind words, as always...

 

A few things:

  • Sound: I don't plan on changing the sounds at this point, I'm quite happy with the way they turned out. They may not be exact, but I think it's as close as I can get them. Being that the arcade game only has one sound channel, you know they meant for the siren sound to be constant but they couldn't because they only had that one channel. So I made the siren constant here... It's funny; I thought people would be pleased with that.
  • Collision: Aside from the playfield outline, there are actually very few places needed to check for collision: The bumper surrounding the saucers, the bumpers above the flippers, the guide between the two lanes on the outside of the bumpers, and the flippers. That's it. (I'm not counting the 'tile' collision detection like the saucers, the triggers for 'tunnel' and 'fruits', and the drop-down targets - those will be done on a tile/sprite level). If I split the screen into quadrants like someone mentioned, I can maybe check positional boundaries instead of collision with hard tiles.
  • Ball Physics: I have a feeling I will need to apply trial and error on this one. This is something I've never attempted before. I've seen everyone's comments and I will re-read them when I get to this. I do plan on using the 'rails' method in the 'fruits' and 'tunnel' lanes, saves a lot of headache.
  • Controls: At this point I also don't plan on changing the control scheme. It's basically taking into account both CX-40 and ProLine controllers, even the track and field controller will work, minus the bumping 'up' of the table.
  • TV Type: I forgot to mention that this game should auto-detect NTSC or PAL. Could someone with a TV type of PAL check this on real hardware for me?

A thought quickly passed my mind about 3-D printing a small-scale pinball table and connecting the joystick ports to the triggers. While cool, that would be WAY too much work...

Bob

Edited by PacManPlus
  • Like 9
Link to comment
Share on other sites

Okay so far Im done on many of the layers for the label I just need to know if you wanted me to do a complete label layout with texts? and what format you wanted the file from Photoshop or Clip Studio?

 

Both art styles are nice, but I prefer the solid colors. Makes it look more like the artwork on the arcade cabinet.

 

Also, I went to an arcade a few days ago. Their Baby Pac-Man was out of order! Damn it!

  • Like 2
Link to comment
Share on other sites

Sound: I don't plan on changing the sounds at this point, I'm quite happy with the way they turned out.

 

I would strongly urge roping Dintar816 into taking a whack at the sound effects and music. He absolutely fecking nailed the sounds in

, to the point that even now it's hard for me to believe it's TIA making those sounds.
  • Like 1
Link to comment
Share on other sites

Both art styles are nice, but I prefer the solid colors. Makes it look more like the artwork on the arcade cabinet.

 

Also, I went to an arcade a few days ago. Their Baby Pac-Man was out of order! Damn it!

Your experience sounds similar to the experience I had with Baby Pacman at the 2014 Texas Pinball Fest. Out of order sign, not even plugged in... :sad:
  • Like 1
Link to comment
Share on other sites

I would strongly urge roping Dintar816 into taking a whack at the sound effects and music. He absolutely fecking nailed the sounds in Pac-Man 8K, to the point that even now it's hard for me to believe it's TIA making those sounds.

Very true, right?

 

I think I told Bob, who is already an excellent TIA sound maker, how Dintar816 does it.

Dintar816 told me, and I tried and failed at it for the longest time (as the method seems simple), but ends up needing some skill, luck if the sound effect needs 2 channels and you only have one. My Draconian and Mappy sound effects do sound like the arcade, they’re just not fondly remembered as is Pac-Man.

Link to comment
Share on other sites

Very true, right?

 

I think I told Bob, who is already an excellent TIA sound maker, how Dintar816 does it.

Dintar816 told me, and I tried and failed at it for the longest time (as the method seems simple), but ends up needing some skill, luck if the sound effect needs 2 channels and you only have one. My Draconian and Mappy sound effects do sound like the arcade, they’re just not fondly remembered as is Pac-Man.

 

Well, the sound effects being played in the arcade original of Baby Pac-Man (except for the music) are only playing one at a time... on the video part it's either the siren or the gobbling sound, but not both at once, and in the pin part you also only hear one effect at once, thus the effects could be coded so that each one takes up both channels since they're not supposed to be playing two at a time anyway.

Link to comment
Share on other sites

OK, here's another thing about the formulas I gave earlier... in them, I converted the ball movement into movement relative to the target and back to x/y using two turning matrices. But of course it's possible to roll those two into one matrix which will calculate the resulting speed values directly. To do this, you have to combine the formulas, so that:

 

x'' = x * (-cos(a)^2 + sin(a)^2) + y * sin(a) * cos (a) * 2

y'' = x * cos(a) * sin(a) * 2 + y * (cos(a)^2 - sin(a)^2)

 

Now this is a more complicated formula than the one above, but you can precalculate all the terms X and Y have to be multiplied with, and some of them even occur in both formulas. So you basically you need the following values calculated:

sin(a)^2 - cos(a)^2

cos(a)^2 - sin(a)^2 (which is the negative of the previous value)

sin(a) * cos(a) * 2

 

What's more, due to special properties of sinus and cosinus, the terms we are looking for also describe sinus curves, so that:

sin(a)^2 - cos(a)^2 = -cos(a*2)

cos(a)^2 - sin(a)^2 = cos(a*2)

sin(a) * cos(a) * 2 = sin(a*2)

 

Therefore, the term that directly transforms the source direction vector to the final direction vector gets reduced to:

x'' = y * sin(a*2) - x * cos(a*2)

y'' = x * sin(a*2) + y * cos(a*2)

 

So this basically reduces the necessary calculation to 4 multiplications, at least if you know the angle and thus the sin and cos values beforehand. Remeber, they apply to the slant of the object being hit, not to the angle at which the ball is hitting it.

 

/clip/

OK, I think I get carried away here... ;-)

/clip/.

 

I always ramble in posts, but someone may learn the information they are searching.

 

I really love pinball, from pong-like Video Pinball to 2600 Midnight Magic, to other system’s videogame pinball games using 2 or 3 screens.

Researching the physics and coding it for 2600 is beyond my ability without some help!

Even is it is simplified and not perfectly correct, there is “it is fun to play” or “it is not fun to play”.

 

There was a simple bouncing ball basic program in Antic magazine to type in to Atari 8-bit computers that had variables that were fun to change, and then see those changes physics variables results on the way the ball bounces.

Example: Changing gravity would decay the rebound bounce faster and it would come to rest quicker, or adding to rebound instead of subtracting creates impossible funny physics reactions.

I failed at even making those routines into code the 2600 could use as Atari home computers have more math functions in its Basic coding, and data from strings and all that - I get lost.

 

PLEASE help. Simple routines that even batari Basic could use would make fun games.

This far I know:

Coding sin and cos would use a data table lookup of say 0.00 to 0.99, no?

And cos is the same sin data lookup but reversed from the last value going to the first value?

 

I hope “bogax” is still around as he is genius with table data and coding math loops within loops that are elegant — even if I can’t wrap my head completely around what/how the code is actually doing things!

 

Another thread on this information would be wonderful as searching the internet returns college like results and not simple step by step how to for coding the basics of gravity, momentum, etc.

 

Sorry to ask this here, but this here now is the closest information I have been looking for a long time and huge love and anticipation for Baby Pac-Man game WITH PINBALL is fantastic to me beyond words! ❤️ love, wow! !

Link to comment
Share on other sites

PLEASE help. Simple routines that even batari Basic could use would make fun games.

This far I know:

Coding sin and cos would use a data table lookup of say 0.00 to 0.99, no?

And cos is the same sin data lookup but reversed from the last value going to the first value?

 

I hope bogax is still around as he is genius with table data and coding math loops within loops that are elegant even if I cant wrap my head completely around what/how the code is actually doing things!

 

Another thread on this information would be wonderful as searching the internet returns college like results and not simple step by step how to for coding the basics of gravity, momentum, etc.

 

Sorry to ask this here, but this here now is the closest information I have been looking for a long time and huge love and anticipation for Baby Pac-Man game WITH PINBALL is fantastic to me beyond words! ❤ love, wow! !

There's a heavily commented sample called "spacephysics" distributed with 7800basic. For maths and conditional logic, 7800basic syntax is identical to bB, so this might be a good starting place for you. It has sample code for angled velocity (thrust and shots), momentum, drag, bouncing off horizontal/vertical barriers, etc. Even if space physics isn't your goal, you can probably learn some basics of a physics game simulation on 6502 generally.

 

Some quick background concepts which may help you as you read the source code...

 

Each frame is your simulation's clock tick. (Planck time ;)) Each moving object has position (X and Y) and velocity (X and Y) variables. With every tick of the clock, the velocity variables are added to the position variables. You accelerate an object by adding some value to it's velocity - add smaller values every frame for thrust or gravity, add larger values once for quick jumps and bumps. You'll want to implement maximum positive and negative velocity values to avoid having overly high velocity objects doing weird things with your coordinate logic, like having objects appear to pass through one another. (ultimately this is a consequence of the large time unit we're kinda forced to work with)

 

In a basic simulation the sine and cosine tables are mainly used to covert an angled velocity into X and Y velocity components. (see the thrust tables in spacephysics) You don't want to think about the sine table ranging from 0 to 0.99, so much as thinking of the whole table representing a full sine or cosine wave, with the number of entries in the table being related to what you're using it for. ie. a thrust table has 1 table entry for each possible angle of rotation of the ship.

 

You don't have the relationship between sine and cosine quite right. A sine wave is identical to a cosine wave, but shifted one quarter wave. (or visa versa) Often 6502 games use this phase difference to represent both sine and cosine with 1 table, to save on ROM.

 

post-23476-0-44700900-1531072339.gif

 

You can see how the X,Y coordinate of any particular point/angle on a circle relates to sine/cosine via the following gif. This is why we use sine/cosine tables to convert angled velocity to X and Y velocity.

 

post-23476-0-72653600-1531080194.gif

 

In a simple sim, (perfect) bouncing of an object off a completely horizontal or vertical surface is just a matter of negating the velocity variable in question.

 

Things get much more complicated when objects can bounce off arbitrarily angled or curved surfaces, or if objects can bounce off other movable objects and transfer velocities to each other. (more complicated yet if the objects have differing mass) This is the reason why realistic pinball physics on a non-modern CPU aren't straightforward.

  • Like 5
Link to comment
Share on other sites

In which way could I help? What exactly are you trying to do?

 

I've gone through the instruction set of Batari Basic a bit, and unfortunately, it's not easy doing this in Batari Basic since while it does support 8.8 variable types, it doesn't support a multiplication between them, which is what we'd need for the calculations I gave above. So you'd probably have to insert those as an ASM section.

 


PLEASE help. Simple routines that even batari Basic could use would make fun games.

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