Baby Pac-Man

[Swami]

Ok guys, truth time.

 

Part of the reason this has been sitting for so long is that I cannot figure out how to do it. I have looked at dis-assemblies, tried to disassemble the NES pinball rom which I thought was closest to what I was trying to do, and have gone through the past posts here. I am unable to make heads or tails out of any of this. I also think the collision detection will be much to involved to allow to happen in one frame, and the SIN / COS stuff eludes me. I am questioning my own intelligence here.

 

Sorry to let a bunch of people down, but unfortunately I think this is where it's going to stay. I can't do any more on it.

 

Bob

Dont feel disheartened. It was quite a leap into the unknown.

[Swami]

Ok guys, truth time.

 

Part of the reason this has been sitting for so long is that I cannot figure out how to do it. I have looked at dis-assemblies, tried to disassemble the NES pinball rom which I thought was closest to what I was trying to do, and have gone through the past posts here. I am unable to make heads or tails out of any of this. I also think the collision detection will be much to involved to allow to happen in one frame, and the SIN / COS stuff eludes me. I am questioning my own intelligence here.

 

Sorry to let a bunch of people down, but unfortunately I think this is where it's going to stay. I can't do any more on it.

 

Bob

How were the ricochets in this game going to be different from those in Frenzy or Crazy Brix?

 

Okay. Never mind. Youre speed is having to be constantly recalculated from gravity and events causing acceleration and deceleration. Sums of forces acting at different angles.

[Atari PAC-MAN Fan]

Ok guys, truth time.

 

Part of the reason this has been sitting for so long is that I cannot figure out how to do it. I have looked at dis-assemblies, tried to disassemble the NES pinball rom which I thought was closest to what I was trying to do, and have gone through the past posts here. I am unable to make heads or tails out of any of this. I also think the collision detection will be much to involved to allow to happen in one frame, and the SIN / COS stuff eludes me. I am questioning my own intelligence here.

 

Sorry to let a bunch of people down, but unfortunately I think this is where it's going to stay. I can't do any more on it.

 

Bob

 

Look on the bright side! We still have the entire maze portion of the game!

 

 

I don't know about you, but personally, I can do without the pinball half. Now I can actually enjoy the game instead of getting killed in 10 seconds flat.

[Jinks]

Maybe one day a math wizard could help you out!

You gave it one hell of an effort anyways and we are all amazed at what was accomplished.

Edited August 24, 2018 by Jinks

[iesposta]

I understand Bob.
Like when you gave me your games movement data, I did the first movement no problem, but the next one I didnt get working.
I understand what is going on, but just havent worked it out yet.
I plan to go back and figure my game out.

Have you looked into how they made 90s computer pinball?
It is like the the black & white Atari Sprint Driving game.
There is an invisible image of directions, think arrows , and when your car is at any of these coordinates it shows the way to move next.
The pinball uses layers of images and grayscale to show where the ball can be and how the pinball should move next.

 

If you don’t want to use math, use images!
Take a look at this:
https://gamedev.stackexchange.com/questions/43705/2d-collision-detection-for-pinball-game/43719

And if thats a no go, offer the pinball gameplay to another developer.
Someone in this nice AtariAge community may just do the pinball game part.

Edited August 24, 2018 by iesposta

[Trebor]

Ok guys, truth time.

 

Part of the reason this has been sitting for so long is that I cannot figure out how to do it. I have looked at dis-assemblies, tried to disassemble the NES pinball rom which I thought was closest to what I was trying to do, and have gone through the past posts here. I am unable to make heads or tails out of any of this. I also think the collision detection will be much to involved to allow to happen in one frame, and the SIN / COS stuff eludes me. I am questioning my own intelligence here.

 

Sorry to let a bunch of people down, but unfortunately I think this is where it's going to stay. I can't do any more on it.

 

Bob

 

WAY too hard on yourself - Questioning your intelligence.

 

Allow me to share a brilliant dev's track record...

 

Armor Attack II (XM Enhanced)* | Apr 16, 2013 | Done

Asteroids/Asteroids Deluxe (XM Enhanced)* | Oct 14, 2007 | Done

Asteroids (Vector Edition Hack)* | Jul 24, 2005 | Done

Astro Blaster (XM Enhanced)* | Feb 01, 2014 | Done

Astro Fighter (XM Enhanced)* | Jul 26, 2015 | Done

Bentley Bear's Crystal Quest^ | Dec 20, 2015 | Done

Crazy Brix (XM Enhanced)* | Apr 27, 2016 | Done

Crazy Otto (Hack) (XM Enhanced)* | Jan 12, 2010 | Done

DLLTemplate (DL & DLL Template) | Jul 23, 2008 | Done

Dual Pac-Man (Hack)* | Sep 02, 2005 | Done

FailSafe (XM (Enhanced)* | Feb 27, 2010 | Done

Frenzy (w/Berzerk) (XM Enhanced)* | Dec 17, 2013 | Done

Hangly-Man (Hack)* | May, 31, 2005 | Done

Jr. Pac-Man (XM Enhanced)* | Sep 24, 2012 | Done

KC Munchkin | Apr 08, 2014 | KC Munchkin (Alt Movement) Apr 09, 2017 | Done

Meteor Shower (XM Enhanced)* | Feb 18, 2012 | Done

Moon Cresta (XM Enhanced)* | Nov 13, 2011 | Done

Ms. Pac-Attack (Hack)* | May 31, 2005 | Done

Ms. Pac-Man (Fast Hack)* | Mar 4, 2006 | Done

Ms. Pac-Man (Hack) (XM Enhanced)* | May 01, 2009 | Done

Ms. Pac-Man 320 (XM Enhanced)*^ | Aug 08, 2011 | Done

Pac Pollux (Hack) (XM Enhanced)* | Mar 05, 2006 | Done

Pac-Man (Hack)* | May 30, 2005 | Done

Pac-Man 320 (XM Enhanced)*^ | Aug 10, 2011 | Done

Pac-Man Collection (XM Enhanced)*^ / Updated Monsters | May 31, 2015 | Done

Pac-Man Plus (Hack)* | Jun 2, 2005 | Done

Rip-Off (XM Enhanced)* | May 02, 2012 | Done

Scramble (XM Enhanced)* | Feb 18, 2012 | Done

Space Duel (XM Enhanced)* | Oct 14, 2007 | Done

Space Invaders 7800 (XM Enhanced)* | Aug 01, 2008 | Done

Super Circus AtariAge (XM Enhanced) (POKEY 0450)*^ / (POKEY 4000) | Jun 11, 2017 | Done

Super Pac-Man (XM Enhanced)* | Oct 10, 2008 | Done

Ultra Pac-Man (Hack)* | Jun 19, 2005 | Done

..Last thing I'm questioning here is your intelligence.

The truth is you're human and not a machine. No human is an expert within every facet of the thing they pursue or are passionate about. You, my friend, have gone above and beyond on many occasions and left us in awe more than once.

You're not an expert on pinball physics or a genius in trigonometry, so what? Yes, it's a bummer you can't tackle the pinball portion, perhaps someone else will pursue that part in the future and there can be a collaboration of sorts...or not.

Either way, allowing it to rest for now may be best; especially, when reflecting upon your own prior experience. Remember when Frenzy was stuck in development and you couldn't figure out how to progress further with it? Time passes, and now we have Frenzy and Berzerk on the 7800 and a port on the NES!

So, don't sweat it, Bob. Nothing but huge respect for you and admiration for your humility and honesty.

I'm sure there are other projects/ideas you'll come up with and the progress with this one can be left at... "To Be Continued...?"

[MrBeefy]

Could the physics from circus atariage be adapted in some fashion?

[Jinks]

Could the physics from circus atariage be adapted in some fashion?

Clown physics? Is that even a thing?

[RevEng]

Clown physics? Is that even a thing?

Yeah, but it's not pretty...

 

[+frankodragon]

It's worse when a Physics teacher dresses up as a clown.

 

[Andromeda Stardust]

Thanks, guys...

 

Sorry about the gap, been dealing with personal issues.

 

Anyway, my plan is to have three variables: one for ball direction (32 values), one for 'x' velocity (8 speeds in each of 32 directions - read from a 256 byte table) and one for 'y' velocity (again, 8 speeds in each of 32 directions - read from a 256 byte table).

So far, the only issue I see is collision with the table... I will have to figure out an efficient formula for converting the old direction to the new, depending on the direction the ball is when it hits the table/flippers (flippers are actually tiles, not a sprite). This is going to be a lot of work for me... especially for the curves. :-/

 

Direction Values (only put a few numbers here for information - 
  but it basically starts off due right and works clockwise from there):

            $18
   $14       |       $1C
             |
             |
             |
 $10 --------+-------- $00
             |         
             |        
             |        
   $0C       |       $04
            $08 

Bob, do not give up! One gentle suggestion, use x/y rectangle coordinates, not polar vector data (angle + velocity). Computing polar coordinates on a vintage 8-bit cpu with no support for floating point trig functions is a bad idea.

 

Realistic parabolic trajectories are possible on 8-bit cpus. The x delta per frame does not change unless the ball colides with an object. The y delta per frame is decremented or incremented as the ball trajectory is bent by gravity. Downward velocity should be capped at some limit to prevent bugs associated with excessive ball speed leading to missed object collision.

 

Brian Parker made an NES homebrew pinball game in 2016, which like the 7800 uses a 1.79mhz 6502 derivative. Native asm code controlling raw ball physics could be shared between platforms with tweaking.

[+frankodragon]

I never taken any trig or calc because I sucked in algebra and geometry. But I looked up the angle of a pinball machine. Newer models have 6.5 to 7 degree while older ones have a 3.5.

[Andromeda Stardust]

I never taken any trig or calc because I sucked in algebra and geometry. But I looked up the angle of a pinball machine. Newer models have 6.5 to 7 degree while older ones have a 3.5.

That is irrelavent in a video game. Gravity pulls straight down on the tv screen. Pinball tables exist on a tilted plain because descent in Earth gravity is way too fast. Computing the rise over run and divide by Earth gravity will give you an approximation of ball acceleration on any given table. EMs had weaker solenoids than modern solid state so the tables were slower with less pitch. Solid state tables with electric relays allowed much more powerful solenoids enabling steeper embankments and faster gameplay.

 

To simulate the effects of gravity and ball travel in a parabolic arc, x velocity remains constant (until you hit something) and y velocity accelerates towards the bottom. This means the pinball slows down as it travels up, and speeds up as it travels down. None of these calculations require trig, just realtime adds or subtracts a delta value to the coordinate with every frame.

 

Pacman Plus is attempting to use polar coordinates (angle / velocity) instead of rectangular coordinates (x / y position and velocity). He constructed a rather large table of precalculated values so that the cpu doesn't have to compute them (8-bit cpus do not posess the capability of complex math like those performed by modern floating point cpu). I'm not trying to armchair develop here, but the angle/vector calculations are needlessly complex. 8-bit cpu cannot handle the complexity necessary to pull off vector math.

[+GoldenWheels]

Disappointing but if PMP is throwing in the towel on it....I know damn well it wasn't for lack of effort.

 

Maybe you rest it for a while Bob and you'll have an epiphany one night.

[John Stamos Mullet]

Is there a disassembly of Midnight Magic for the 2600 anywhere that might help?

[Inky]

PacManPlus, why not see if someone else can take over the pinball portion?

And if anyone here should question their intelligence, it's me. I wouldn't even know where to begin to attempt something like this.

[Swami]

That is irrelavent in a video game. Gravity pulls straight down on the tv screen. Pinball tables exist on a tilted plain because descent in Earth gravity is way too fast. Computing the rise over run and divide by Earth gravity will give you an approximation of ball acceleration on any given table. EMs had weaker solenoids than modern solid state so the tables were slower with less pitch. Solid state tables with electric relays allowed much more powerful solenoids enabling steeper embankments and faster gameplay.

 

To simulate the effects of gravity and ball travel in a parabolic arc, x velocity remains constant (until you hit something) and y velocity accelerates towards the bottom. This means the pinball slows down as it travels up, and speeds up as it travels down. None of these calculations require trig, just realtime adds or subtracts a delta value to the coordinate with every frame.

 

Pacman Plus is attempting to use polar coordinates (angle / velocity) instead of rectangular coordinates (x / y position and velocity). He constructed a rather large table of precalculated values so that the cpu doesn't have to compute them (8-bit cpus do not posess the capability of complex math like those performed by modern floating point cpu). I'm not trying to armchair develop here, but the angle/vector calculations are needlessly complex. 8-bit cpu cannot handle the complexity necessary to pull off vector math.

Would it be simpler to treat the vertical motion and horizontal motion completely separately, like two separate games, except maybe for moving flipper collisions? You would just implement the separate change in x position and change in y position, separately, at the end of each cycle. For bumpers, the velocity added to x or y could also be done separately, if the preceding method is possible. The velocity added to the x or y coordinate should be dependent only on the position of the bumper hit, and then only for the bumpers with curved shape (like circles). If this type of programming is possible no trig or even x/y ratio determination is needed (except moving flippers, ). The flippers are the most complex, though, since they are moving and their angle is changing and different points along the flipper are moving at different speeds.

[gambler172]

Hi Bob

 

never mind,i know the problems with another pinball game.

No one ever tried to port Baby Pac...it is some kind of

Video game and a real Pinball also...this makes it heavy to

port it......Keep your head up.....for me,you are the best 7800 programmer and a good friend too......

Come on...let us do A... you know,what i want

[Kurt_Woloch]

Oh dear... maybe I went too far with my explanations, but unfortunately the proper formula for deflecting balls at an arbitrary angle does contain Sin and Cos, and while there are ways to get around this in calculation, it's rather trickery to do so.

 

I don't think collision detection would take more than one frame (at least the way I proposed to do it), but on a collision it may take longer to properly calculate the new ball speed. On the other hand, it may not...

 

It's understandable for me if you can't wrap your head around that trigonometry stuff. I guess the maze portion was relatively easy to do since you already did multiple other games like this and they are probably all based on the 7800 version of Ms. Pac-Man, while there's no prerequisite for a pinball game.

 

So what do we do with this now? Bob, you said you had you had another version you didn't post where some glitches were fixed. Then there's the question if you would be willing to share the source code of the game so far so somebody else could try to continue work on it. Or do you not want to share it and just call the project dead?

[NRV]

If you dont want to use math, use images!

Take a look at this:

https://gamedev.stackexchange.com/questions/43705/2d-collision-detection-for-pinball-game/43719

That link also points to this demo/game:

http://www.pouet.net/prod.php?which=24499

 

That has a video.. (physics seems pretty good)

 

And the full source code is available (6502).

 

It has some equations with sin and cos, but they seem to be only precalculated tables.

The amount of memory needed could be a problem with this technique, but maybe it could work well with lower res maps.

[Swami]

That link also points to this demo/game:

http://www.pouet.net/prod.php?which=24499

 

That has a video.. (physics seems pretty good)

 

And the full source code is available (6502).

 

It has some equations with sin and cos, but they seem to be only precalculated tables.

The amount of memory needed could be a problem with this technique, but maybe it could work well with lower res maps.

That would be one approach. Set it up with only 8 angles first: 0, 45, 90, 135, 180, 225, etc., to 360 to start, the build up.

[PacManPlus]

It's understandable for me if you can't wrap your head around that trigonometry stuff. I guess the maze portion was relatively easy to do since you already did multiple other games like this and they are probably all based on the 7800 version of Ms. Pac-Man, while there's no prerequisite for a pinball game.

 

 

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.

 

It's not dead yet, I guess.

 

Also, Thank you Trebor - you are way too kind.

Edited August 25, 2018 by PacManPlus

[NIKON]

I have a question...is it easier to program a system that has hardware collision detection or software collision detection...I am by no means a programmer...it is just that most of the examples I have seen in this post come from systems with built in collision detection.

 

Just curios and if I am way out in left field here I do not mind people telling me about it.

 

 

Cheers

[+Cafeman]

Because of the reuse of player sprites and BG graphics, many games end up needing software collision routines anyway, perhaps in conjunction with the hardware collision registers. On 5200 and A8.

 

On the 2600 when the player repeat function is used, how does the game know which of the 3 sprites was hit with your shot? I assume it requires you to track x and Y values of everything?

 

Not sure about the more advanced 7800 hardware and what HW collision features it offers.

 

But overall, it is easier to just use the built in HW registers, as you just check for a value each frame.

[RevEng]

Not sure about the more advanced 7800 hardware and what HW collision features it offers.

There's no hardware collision on the 7800, so you're either checking special points (sprite to tile), doing bounding box checks (sprite to sprite), or some variation on those. Hardware collisions really weren't feasible, since everything is just a bitmap display-list object, and you can draw as many as you like if you have sufficient DMA.

 

As you guessed, on the 2600 collisions with a copy need to be sorted in software, with coordinate checks, if your game treats them uniquely. Combat side-stepped this by treating any collision with a copy as equal.