Baby Pac-Man

[PacManPlus]

@imstarryeyed : I may add a few, but it seems like many of those options were there to make the game *harder* (which we don't need or want). However, I may add the one you mentioned (unlimited serve of the ball if no points score) as an option. Also, I'm thinking of adding the adjustable gravity as well.

 

@swami: That's a no go (I'm sorry) - I moved the pinball bitmap out of it's own graphic block to make room for code. I would have to create three different sets of both flippers (each with four different positions) to account for that kind of an option.

 

EDIT: I just re-checked the dip switches. Instead of gravity, I will add these two:

- Remember center arrows (after losing a life - the ones that award a bonus baby) yes / no

- 3 balls with no score before losing pinball, or unlimited.

 

Those should help. The other settings (starting with tunnels closed or no fruit at all) just make the game harder. I already have the number of lives and the 'remember energizers' settings there.

 

Didn't get to work on it last night much, but I'll be back to it hopefully tonight.

 

Thanks, guys

Edited December 4, 2018 by PacManPlus

[Kurt_Woloch]

It just occured to me this morning that the physical provisions for tilting are still missing in my code. So I've now amended my version of the code to let the bumpers only deflect the ball actively if there's no tilt. I've set the new variable PB_TILT equal to PB_VERVEL+3, and it's supposed to start out at 0 and increase with each nudge (and maybe decrease with time again). The question is, how much should you be able to nudge until Tilt kicks in? How roughly does that work on the real machine?

 

Also, what happens if there's a Tilt? I guess the bumpers lose power, which I've accounted for now in my version of the code, and the flippers cease working, which I suppose Bob will implement. But what happens to the targets if the ball still hits them? Do they deflect the ball in the same way still? Do they go down or do they stay up? And I guess the hole will just spit out the ball again without scoring and sounding, or does that behavior change as well?

[Swami]

It just occured to me this morning that the physical provisions for tilting are still missing in my code. So I've now amended my version of the code to let the bumpers only deflect the ball actively if there's no tilt. I've set the new variable PB_TILT equal to PB_VERVEL+3, and it's supposed to start out at 0 and increase with each nudge (and maybe decrease with time again). The question is, how much should you be able to nudge until Tilt kicks in? How roughly does that work on the real machine?

 

Also, what happens if there's a Tilt? I guess the bumpers lose power, which I've accounted for now in my version of the code, and the flippers cease working, which I suppose Bob will implement. But what happens to the targets if the ball still hits them? Do they deflect the ball in the same way still? Do they go down or do they stay up? And I guess the hole will just spit out the ball again without scoring and sounding, or does that behavior change as well?

I think its pretty much just game over. The table goes dead. No more balls.

[imstarryeyed]

@Kurt

 

Tilting is not easy on the real machine as it very very heavy. I have never gotten a Tilt warning just a Tilt as it is too heavy I think to give out warnings.

 

Honestly I don't use nudging on this machine and I was ok without it being implemented as anyone who owns this machine knows how hard it is to nudge. The reason the TILT is there is to not allow people to TIP the machine and wedge a textbook or something there to make the game play slower and easier.

 

Here is text from the manual from the section INSPECTION:

 

"1. Plumb bob tilt on left side of cabinet near front door.

2. Ball tilt above plumb bob tilt. Insert the smaller ball (15/16" dia.) into the ball tilt assembly, and adjust the bracket so the ball will roll free to contact the switch blade, if front of cabinet is raised..."

 

Having said that the home version I think would benefit from that as weight is not a real problem, the question becomes what to add that the machine does not really have built in.

 

I would say if you want to implement random number between 2 - 5 and make 3 of those numbers TILTs so you have a 2 out of 5 chance to get a good nudge after a safe 1st Nudge might be good. The same may hold true if you are using time the person is nudging the ball with. The Slam TILT on the Front of the Machine and the Pendulum TILT bob will wiggle if you nudge the machine but it is not easy to do at all.

 

If a person does nudge on 7800 version I would say the fairest thing would be to implement a TILT warning Sound / Graphic and you all can set the number of TILT warnings per game? I think a TILT warning would be good instead of a direct TILT and that is only if the player hit the wrong random numbers from 2 to 5. Giving out TILT warnings (settable by DIP switches) is how almost all modern and retro pinball machines work from the late 80's to the 90's. Seeing how the hitting the slam switch ends your game (SEE BELOW for Quotes from the manual), it might be best to be a bit more liberal on the TILT Slam warnings on the 7800 version if implemented. I however leave this decision to Bob and yourself as it is out of the original game play and just a suggestion.

 

In reference to what happens on a TILT:

Here is the reference from the manual under the section "GENERAL GAME OPERATION PINBALL"

 

Tilting the game results in loss of a Pac-Man. The flippers, etc., go 'dead/ Bonus points are not
scored. The purpose of the tilt penalty is to discourage the player from jostling the machine in
an attempt to prolong play Game action becomes normal after the ball kicker assembly serves
the ball to the piayfield.

 

...
Slamming the machine results in loss of the game. All feature lights go out, the game goes
'dead,* and a time delay occurs. The purpose of the time delay is to discourage unnecessary
abuse of the machine. After the delay the 'Game Over' light lites and the power-up tune is played.
The time delay occurs anytime the slam switch is made to contact. There is one factory installed
slam switch on the front door. (Any number of slam switches could be installed by the operator,
to meet his individual requirement.) The switch should be adjusted to have approximately 1/16"
gap between the contacts. The weighted blade should be adjusted to attain the desired sensi-
tivity. Opening the gap will reduce sensitivity.

 

....

 

I hope this helps

Edited December 5, 2018 by imstarryeyed

[Atari PAC-MAN Fan]

Baby Pac-Man running on my newly modified Wii U!

 

 

P.S. The Wii U makes an awesome emulation console!

[Atariboy]

Wish I was braver, I'd love to see what else my Wii U could do.

[PacManPlus]

Ugh.

I have two issues now.

 

- On a VERY rare occasion while playing the maze portion, there seems to be sprite graphic corruption for one frame. It immediately changes back to normal after that single frame, but I still would like to find out why that happens.

I'm trying to do a screen capture of the corruption, but it's VERY difficult to catch. If anyone happens to catch that, please post it here - it would be a help. (Thanks)

- Similarly, while I was playtesting, ONE time while moving from pinball mode to maze mode after losing the ball, five or six maze/dot tiles on the top left side of the screen got corrupt. The maze could not be finished after that. That's going to be a bear to find.

 

Also, it looks like I made a blunder.

Being that I thought that all scoring was multiplied by 10, I used the four 'scoring' bytes for each player to go in the millions and hard coded the two ending zeros that you see at the top. So ALL of my scoring, display, adding etc. was geared this way.

While doing the pinball section, I found that two items cause points that are less than 100: the bumpers, and the spinners (when the light isn't lit). Both are 10 points. Damn.

I'm going to leave them both at 100 points for the time being, and work on everything else first. I will revisit the scoring at a later time.

 

One step forward, two steps back.

Edited December 6, 2018 by PacManPlus

[Kurt_Woloch]

Hmm... this error sounds similar to what we had the other way round, when changing from maze to pinball. Could it be that after changing to the maze, there are still some pinball routines being called which change some bytes (for instance, spin the spinners, which by that time have become maze dots)?

 

To make sure that at least no further physics iterations get called after the ball drains, you could add the following to the transition code:

 

LDA #$01
STA PB_NUMBERITERATIONS ;skip the remaining physics iterations

as it's done when the ball enters a hole. That way the loop that does the physics iterations (part of which probably is the "exit to maze" code) terminates after this run.

 

However, after doing the physics iterations quite a few more things are done... gravity is applied, the ball is being displayed on screen, the upper ball is moved, then after the return from "Handlepinball", the arrows are flashed (don't know why this actually is outside of the Handlepinball routine while the other flashes are inside of it...). At least that's how it is in the code version I have...

 

- Similarly, while I was playtesting, ONE time while moving from pinball mode to maze mode after losing the ball, five or six maze/dot tiles on the top left side of the screen got corrupt. The maze could not be finished after that. That's going to be a bear to find.

[Kurt_Woloch]

About the sprite corruption issue: I did a bit of playtesting of your version over the last days, and I noticed a bit of unsteadiness in the movement of both player and enemies in the maze part. Therefore I suppose that there are times where not all that has to be done fits in a frame, and then the sprite info or display list get written just at the time they are supposed to be displayed, hence the corruption. I especially noticed this unsteadiness if Baby and the monsters are all in the lower half of the screen, and I was playing with the monster AI switched to Classic. Don't know if I'm on the right track here...

[RevEng]

That's a pretty common cause for non-persistent glitching of moving objects, so entirely possible.

[PacManPlus]

Just so you guys know what I'm talking about, this is a picture of what the corruption looks like (I lit the right blue arrow, and went into the right saucer. Upon switching back to the maze, this is what I saw:

 

Kurt, I added the lines you mentioned above. This helps the ball stay centered in the saucer when returning to the pinball screen, but the maze corruption still persists. Still looking.

Also, just know that the dot eating is a little slower horizontally than vertically because of the maze aspect ratio changing. Is this what you mean by unsteadiness? I only ask because I haven't noticed any since I changed the 'zone' computation routine back on page 5 of this thread.

[Kurt_Woloch]

OK... in the last version you posted, it's not yet possible to light the right blue arrow and leave the pinball part by placing the ball in the saucer, it's only possible to leave it by draining the ball, so I wasn't assuming there could be an error while doing that. But I still think it might be the additional routines that get executed after the transition takes place (if you put that transition into the handler I wrote, which gets called pretty much at the start of the pinball routines).

 

I see three possibilities to avoid this:

1. In the pinball part, only set a marker in the handler and then do the transition after everything else has been done. For instance, you could check if the ball is captured in a hole and the respective arrow is flashing or if it has drained in an extra routine which runs last.

2. Leave the transition in the handler, but upon returning from the handler, skip all remaining routines if the game state is not Pinball anymore.

3. Run the pinball collision and handler last (but this could break other things)

 

No, I didn't mean the dot eating by unsteadiness, you sometimes see it if a ghost is following you... it falls back by a pixel and then catches up again. I think what actually happens is this:

I built some test code in my version to check how long the routines are really running. The pinball part is normally finished before the visible part of the screen begins, only if the ball touches something and gets deflected, the routines take until the beam reaches about the upper third of the screen. In the maze part, the routines sometimes run up to a bit below the middle of the screen. And they never start before the visible part ends (including the border). I guess what really happens is this:

 

I guess you rewrite the monster parts of the display list after all processing has been finished, which may be before or after the monsters get displayed, or even in the middle of a monster being displayed. If there's one frame where the routines take long, the display part may get executedl after the displaying of a monster which in most cases gets displayed after the routines finish. This causes the monster to lag for a frame on such long frames and then catch up on short frames, which looks as if the monster is a bit unsteady. And it may lead to sprite corruption if the monster is being drawn while the display list gets changed, so there's some inconsistency in what's being displayed. I think I was such a corruption once as well for a frame, but only on one of the monsters, not at all of them at once. I think it was the blue monster, and it was at a line which roughly corresponds to the end of processing on those long frames.

[PacManPlus]

Hi guys:

 

So I believe I resolved the issue that happened in the screenshot I posted in my last post. It looks like it was indeed happening in one of the other routines that get run after the one that changes back to the maze.

 

Kurt - I see what you are saying now. what you are seeing is the frequency in which the monsters move each frame. I have changed that:

(replace your 'SPEEDSM' table with this one):

SPEEDSM
	; BLU,TUN,RED,GRN,AQU,YEL (MONSTER SPEEDS)
	.byte $24,$22,$55,$55,$55,$45
	.byte $92,$22,$55,$55,$55,$55
	.byte $24,$22,$57,$55,$55,$55
	.byte $92,$22,$55,$55,$55,$55

I also moved the 'Loader' routine in front of the 'tunes' routine in the bottom DLI. Nothing changed. So I don't think it's actually running out of time, I believe it's something else... Still looking

 

BTW, Thanks to Trebor, he actually caught the single frame corruption:

 

 

...so here's the thing:

I know that each set of two monsters use the same bitmap. So this is some weird corruption, as none of the 'shapes' are the same. I would think that two of the corrupt shapes would be the same, as they use the same bitmap.

There's something VERY weird happening here...

 

BTW, it happens on the real thing too.

Edited December 11, 2018 by PacManPlus

[RevEng]

A picture is worth a thousand words. That's not a missed frame update, since it's evenly affecting each sprite at the same time, despite varying vertical positions.

 

Sprite width and X appear correct, so if it was DL corruption it would have to affect only specific bytes, which isn't likely. To me it looks like the variable you use for sprite frame animation is out of range, causing other sprite memory to be accessed.

[PacManPlus]

That's what I was thinking... but the 'high' byte of the graphics block is basically hard-coded, and the 'low' graphics byte for the monsters is only EORed with $02 every other frame... So I don't know how that would be happening.

 

This only started occurring recently, and nothing (graphically) changed regarding the maze portion.

You mentioned a debugger in A7800 in another thread. I've never used it before - do you think that would help?

 

Thanks, everyone

Edited December 11, 2018 by PacManPlus

[RevEng]

So ghosts don't have an animation variable, as such. Curiouser and curiouser.

 

PM sent on the debugger. It will be useful, but we have to figure out the best way to trap the bug.

[Kurt_Woloch]

Maybe it has to do with my pinball code... I reused some variables of the maze portion for the pinball portion which I supposed would be overwritten on re-entering the maze anyway... but I don't think any of those have got to do with the monsters. I've re-used PSLOW (which is the flag if the player is in the tunnel) for the number of remaining physics iterations and POINTPAUSE (which is the delay counter counting the frames while displaying the score for an eaten monster) as the delay variable for the holes. But I'm pretty sure those variables don't have to do anything with the monsters and get rewritten before their use in the maze part anyway. They also don't need to be retained after leaving the pinball part since POINTPAUSE gets re-initialized on serving the ball and PSLOW is only used throughout one frame to count the physics iterations left.

 

But actually the issue I had (which you solved by amending the table) also only crept up recently... I don't think it's in the code you publicly posted which I based my version on. And I think I only got it after scoring a higher tunnel speed and tunneling with that at least once (whatever that may mean).

[PacManPlus]

It's not your pinball code - I moved the redefined variables to their own memory address, and it still happens.

Still looking...

[PacManPlus]

I'm noticing something... Someone correct me if I'm wrong, but the issue doesn't seem to happen if you choose the video only option... There shouldn't be any difference...

 

EDIT - nevermind... it just happened.

Edited December 12, 2018 by PacManPlus

[PacManPlus]

A HUGE thanks to RevEng, he found that graphic corruption bug. The sad thing is, it was caused by omitting a 'CLD' in the DLI... It was actually there; I had just commented it out... don't remember why... Ugh.

 

Anyway, thanks again to RevEng.... I'm continuing on now...

[PacManPlus]

Hi guys-

 

Ok, a lot of the pinball scoring has been put into place. Most of the lights are working now. Bugs (that I know of) have been fixed. You can even earn an extra baby in the pinball section now.

 

Major things I know that are left:

- The game replenishes any energizers you have won on the next maze if you've already eaten them. I need to prevent that.

- Spinners

- If you drain the ball without scoring anything (up to three times) it re-launches the ball

- Pacsculator

- Sounds

- Drop Down targets

- Bonus baby after third maze

- Tilting

 

There might be a few little things other than what I've mentioned, but those are the things that come to mind.

 

Give this a shot; thanks guys.

BabyPac.A78

BabyPac.BIN

[imstarryeyed]

Bob I just tried the newest version. I think it is looking good and feels good too, I like the way the lights look especially the blue center extra baby lights.

 

I think once you put the rest of the pinball logic in there I plan to give the pinball a real good run to see how it is all working and to ensure it works ok.

 

I wanted to ask you one thing, is it still possible to request something for the maze portion?

 

If you go to a side tunnel can you get one or more ghosts to rush to the other one to try to sandwich you in?

 

In the actual machine I get deaths on this all of the time, I know the arcade will break off a ghost or two just to go to the other tunnel. This especially happens if you stall in the tunnel by jiggling the joystick left and right really fast to essentially keep you in place. A good tactic on pac, ms pac and other pac machines is to "stall" right when you go into the tunnel to lure ghosts in there since they are so slow in the tunnel.

 

If you stall on the bottom tunnels to the pinball on the arcade you will get the ghosts just circle around the tunnel area in hopes you don't go to pinball and come out again, which I have done on the arcade machine, I will use the bottom tunnels just to let a ghost pass me and jump right out again without going all of the way down, however you can only do that for a few seconds as it backfires on you as the ghosts just go in small circles in that area to lock you in..

 

If the logic is too hard for these I completely understand but I wanted to bring it up to you if it was possible without too much work.

 

I have not been focusing on the maze game as the pinball part was my priority, but this change would really make it feel more arcade.

 

Amazing work so far and really enjoying the game so far, it is very close the arcade experience in my opinion already! You and Kurt should be proud!

[Kurt_Woloch]

I've tried your newest version as well. I think I've spotted one error in your pinball logic which hasn't been adressed yet...

As far as I know, the arrows of the holes should only light up if there's at least one power pellet on that side of the maze. If you use up all the power pellets on that side and go back to the maze, the arrow below the respective hole should cease to flash.

 

In your version, however, once a power pellet has been earned on one side, the respective arrow continues to light even if all the power pellets on that side have been used up. Thus a hole can return you to a maze which has no power pellets in it. I never had that happen in the arcade version... the holes only sent me to the maze if there was a power pellet on that side.

 

Also, I actually question why the ball is being launched by pushing up in your version when it's the right flipper button which launches the ball in the arcade version.

[PacManPlus]

Hey guys!

 

@imstarryeyed: - I'll take a look at that. Believe it or not, Super Pac-Man does the same thing. If you don't open one of the locks for the side door and you go through the opposite end and get 'stuck', one of the monsters will actually go to the other side to pin you in. I haven't been able to get that to happen on the arcade of Baby PM, but you would know better than I would. I'll take a look at that at some point. The only difficulty I see is the different vertical positions of the side tunnels...

 

@kurt: - Thank you... yes I know about that. In my mind it was included in my 'energizer' point in my list above. Regarding the 'pull down' launching of the ball, that was a small change I decided to do to keep it more in line with the other 'video pinball' games on these systems. If it bothers anyone I can change it back. It just seemed more 'even' to me.

 

Thanks guys

Edited December 15, 2018 by PacManPlus

[Kurt_Woloch]

Now I noticed something else... something strange is going on in the tunnel. I reached a tunnel speed of 4 and was chasing two blue monsters that went through the tunnel. However, one of the monsters suddenly was lethal... I lost my Baby Pac-Man on eating it. At the same time, I could see its eyes going towards the pen, but much slower than usual, while the dying animation took place. Or was it actually the collision with the eyes of the other ghost I'd already eaten that was lethal? I don't know exactly...

 

On another occasion, also at this high tunnel speed I passed a non-blue ghost that was going through the tunnel in the opposite direction. I don't know if that's supposed to happen either...