Kurt_Woloch

Well, I thought a bit about what a more code-based solution could look like, and it doesn't rule out tables beforehand. In my original proposal, you probably would have needed up to 4 bytes (one for each direction) to keep score, and then, temporarily, two more to keep the best value so far and which direction it belongs to. You could spare some of the bytes by doing all the checks for each possible direction at once, scoring it and then check if it's better than the previous best direction. That way you would only need 3 bytes total (one for the running total for the currently checked direction, one for the best score so far and one for the direction it belongs to... and you could probably pack the last two values into one byte since the best direction only needs 2 bits and the score only needs 4. The flicker management probably is a different beast... the question is, what do you need all that RAM for? I think you should differentiate RAM that has to be retained from frame to frame (while other logic is being done) and RAM that only gets used temporarily. In this case, the 3 bytes for doing the direction scoring only are being used temporarily... once the enemy has decided where to go, all that needs to be retained is its direction, and the other bytes can be reused as temporary storage for another enemy or a different block of logic. As a more code-based solution, you could of course also do a decision tree of sorts, but this could get HUGE... example: Current dir. right? -> CR Current dir. left? -> CL Current dir. up? -> CU Current dir. down? -> CD CR: Ladder up? -> CRLU Ladder down? -> CRLD Platform right? -> CRPR Platform left? -> move left -> move up (out of bounds) CL: Ladder up? -> CLLU Ladder down? -> CLLD Platform left? -> CLPL Platform right? -> move right -> move up (out of bounds) (The "out of bounds" code applies if the enemy has been knocked to the plates and has to return to the proper maze - this would probably move it up). The further labels not displayed here then would do more checks for the other ladders / platforms and the player position in order to come to a decision. That way you would probably use the least possible number of checks, but also much code duplication.

Well, that's different from the arcade version. I just replayed it, and there burger parts definitely fall down two additional stories for each enemy riding them. With two enemies on them, in the first level you can clear a whole burger by knocking down the uppermost burger part. And I've also checked the bonus items, and at least in the first levels, they appear after each 4 burger parts dropped onto the plate.

Or this one (I think that's about the closest I can get): LC = $F0 FFTUNE07: ; BONUS AT END OF LEVEL .byte #TT+$00,#TT+$03,#TT+$07,#TT+$0B,#TT+$08,#TT+$05,#TT+$02 .byte #TT+$00,#TT+$03,#TT+$07,#TT+$0B,#TT+$08,#TT+$05,#TT+$02 .byte #TT+$00,#TT+$03,#TT+$07,#TT+$0B,#TT+$08,#TT+$05,#TT+$02 .byte #TT+$00,#TT+$03,#TT+$07,#TT+$0B,#TT+$08,#TT+$05,#TT+$02 .byte #TT+$00,#TT+$03,#TT+$07,#TT+$0B,#TT+$08,#TT+$05,#TT+$02 .byte #TT+$00,#TT+$03,#TT+$07,#TT+$0B,#TT+$08,#TT+$05,#TT+$02 .byte #TT+$00,#TT+$03,#TT+$07,#TT+$0B,#TT+$08,#TT+$05,#TT+$02 .byte #TT+$00,#TT+$03,#TT+$07,#TT+$0B,#TT+$08,#TT+$05,#TT+$02 .byte $00 CVTUNE07: .byte #LC+$07,#LC+$07,#LC+$07,#LC+$07,#LC+$07,#LC+$07,#LC+$07 .byte #LC+$07,#LC+$07,#LC+$07,#LC+$07,#LC+$07,#LC+$07,#LC+$07 .byte #LC+$07,#LC+$07,#LC+$07,#LC+$07,#LC+$07,#LC+$07,#LC+$07 .byte #LC+$07,#LC+$07,#LC+$07,#LC+$07,#LC+$07,#LC+$07,#LC+$07 .byte #LC+$06,#LC+$06,#LC+$06,#LC+$06,#LC+$06,#LC+$06,#LC+$06 .byte #LC+$04,#LC+$04,#LC+$04,#LC+$04,#LC+$04,#LC+$04,#LC+$04 .byte #LC+$02,#LC+$02,#LC+$02,#LC+$02,#LC+$02,#LC+$02,#LC+$02 .byte #LC+$01,#LC+$01,#LC+$01,#LC+$01,#LC+$01,#LC+$01,#LC+$01 .byte $00

I think I've found a good one for the bumpers which comes close to the original texture... and it uses distortion value 15 as well because I think they are using that polyphonic "waveform" for quite a few effects... LC = $F0 LF = $05 FFTUNE07: ; BONUS AT END OF LEVEL / BUMPERS .byte #TT+$05,#TT+$04,#TT+$03,#TT+$02,#TT+$02,#TT+$03,#TT+$04 .byte #TT+$05,#TT+$04,#TT+$03,#TT+$02,#TT+$02,#TT+$03,#TT+$04 .byte #TT+$05,#TT+$04,#TT+$03,#TT+$02,#TT+$02,#TT+$03,#TT+$04 .byte #TT+$05,#TT+$04,#TT+$03,#TT+$02,#TT+$02,#TT+$03,#TT+$04 .byte #TT+$05,#TT+$04,#TT+$03,#TT+$02,#TT+$02,#TT+$03,#TT+$04 .byte #TT+$05,#TT+$04,#TT+$03,#TT+$02,#TT+$02,#TT+$03,#TT+$04 .byte #TT+$05,#TT+$04,#TT+$03,#TT+$02,#TT+$02,#TT+$03,#TT+$04 .byte #TT+$05,#TT+$04,#TT+$03,#TT+$02,#TT+$02,#TT+$03,#TT+$04 .byte #TT+$05,#TT+$04,#TT+$03,#TT+$02,#TT+$02,#TT+$03,#TT+$04 .byte #TT+$05,#TT+$04,#TT+$03,#TT+$02,#TT+$02,#TT+$03,#TT+$04 .byte #TT+$05,#TT+$04,#TT+$03,#TT+$02,#TT+$02,#TT+$03,#TT+$04 .byte $00 CVTUNE07: .byte #LC+$07,#LC+$07,#LC+$07,#LC+$07,#LC+$07,#LC+$07,#LC+$07 .byte #LC+$06,#LC+$06,#LC+$06,#LC+$06,#LC+$06,#LC+$06,#LC+$06 .byte #LC+$05,#LC+$05,#LC+$05,#LC+$05,#LC+$05,#LC+$05,#LC+$05 .byte #LC+$04,#LC+$04,#LC+$04,#LC+$04,#LC+$04,#LC+$04,#LC+$04 .byte #LC+$04,#LC+$04,#LC+$04,#LC+$04,#LC+$04,#LC+$04,#LC+$04 .byte #LC+$03,#LC+$03,#LC+$03,#LC+$03,#LC+$03,#LC+$03,#LC+$03 .byte #LC+$03,#LC+$03,#LC+$03,#LC+$03,#LC+$03,#LC+$03,#LC+$03 .byte #LC+$02,#LC+$02,#LC+$02,#LC+$02,#LC+$02,#LC+$02,#LC+$02 .byte #LC+$02,#LC+$02,#LC+$02,#LC+$02,#LC+$02,#LC+$02,#LC+$02 .byte #LC+$01,#LC+$01,#LC+$01,#LC+$01,#LC+$01,#LC+$01,#LC+$01 .byte #LC+$01,#LC+$01,#LC+$01,#LC+$01,#LC+$01,#LC+$01,#LC+$01 .byte $00 I've put it in place of Tune 07 as for now because that's what I'm playing for the bumpers in my version. You'll probably want to place it in a different slot which is unique to the bumpers.

If you finish the maze, the new maze has both tunnels open, like in the 7800 version. That part is correct (but that's not if one of them was open in the finished maze)

When playing the Visual PinMAME version of Baby Pac-Man, I noticed another difference to your version. In the original version, if you go up to the maze by placing the ball in a hole (not by losing it) and then complete the maze, the next maze only has the chute open which you came through, but the other chute closed. In addition to that, your starting position is not the normal one, but it's the starting position you would have if you went up that chute to the new maze, which is directly above the chute facing up. However, if you lose your baby while in the maze, the new baby starts with both chutes open again. This also happens if you've completed the maze and then lose your baby before making it down to the pinball table again. Another thing (I don't know if you put it in anyway) is that you can also earn two power pellets with the even-up lane if both columns of lights belonging to it already spell "Pacman". That is, if columns 1 and 2 spell "Pacman" and you go through the even-up lane, you get power pellets 1 and 2. Same thing with 3 and 4.

OK... the overlap is definitely my work, and it's true that it sometimes may occur. There's a reason for it though... basically the ball should move up at the speed the flippers are moving up. However, they are moving slightly too fast, so I've capped the speed to which they can accelerate the ball upwards to 8 pixels per frame. If they move faster than that, the ball can't keep up and appears to overlap with the flippers for one or two frames until it has reached the flipper surface. That's the reason why the overlap may sometimes occur. What was more important to me when coding this was that the direction and the speed the ball is shoot by the flippers should look convincing and realistic, and I think I've achieved that. Now for the sounds... I've got some more ideas on what could sound good there after recording and analyzing some of the sounds from Visual PinMAME myself... The bumper could maybe sound good if it plays a sound that consists of white noise (distortion # sweeping up and down (vibrato) over the course of about 7 frames, decaying over the course of about 1.25 seconds (which is 75 frames in NTSC or 62 frames in PAL). Well maybe not with this voice, but the vibrato part sounds right to me. For some sounds, I think 15 would be a good distortion value, especially for the Fruit and Tunnel rollovers. I think this distortion is closest to the "voice" actually needed for those rollovers.

Hi Splendidnut! Appreciating the hard work! The bonus items are certainly better now, but what does actually trigger them appearing? Is it a timer or something? As far as I know, in the arcade version you have to place a certain number of burger parts on the final plates in order for the bonus item to appear... if you just run around and no burger parts fall, it certainly doesn't appear. I think it was for every 3 burger parts placed or so... also, as far as I remember, on Level 4 the bonus item should be at the top of the screen, not in the middle. I also managed to accumulate 10 pepper and noticed that the peppers are counted in hexadecimal, thus after 09 peppers it counts up to 0A. Otherwise, good work!

In my opinion, many of the pinball sounds actually are polyphonic, that is, they should use both channels at once. One technique to achieve this might be to play basically the same notes on both sound channels with different voices / repeat rates. For instance, for square waves, there's one lower setting and then another higher setting which has got exactly three times the frequency of the lower one. On some effects such as the fruit and tunnel rollovers, it might work well to use both settings on the two channels playing the same period values. On other like the transition from maze to pinball, the pacscalator and actually the spinner, it seems like the two channels should exactly be an octave apart which could be achieved by using the same "voice"; but double the period. And in some which change frequency rapidly, such as the one when you're earning a power pellet, it might be a good idea to mix in some noise at least in part of the effect.

Sorry, no gaming on modern systems for me this week.

Here are my times for this past week (January 1st through 6th): Atari 2600: Chaotic Grill (WIP) - 32 min. in 2 sessions Atari 7800: Baby Pac-Man (WIP) - 333 min. in 10 sessions I tested a new update of Chaotic Grill for the Atari 2600 which is noticeably better, but still has its flaws. On the Atari 7800, I put in some longer sessiions on Baby Pac-Man due to having this week off from work, in an attempt to "roll the banana", that is, reaching the banana and then completing another fruit, but didn't manage to reach that goal. I also proposed doing a title music for it, but Bob (the main programmer) rejected that proposal.

What I actually had in mind for a long time is a different tune... a title song which plays during attract mode. But I couldn't think of a fitting tune for a long time. The most obvious one would be "Pac-Man fever" by Buckner & Garcia, but this is more about the original Pac-Man, not Baby Pac-Man. But while testing your latest build, I had this tune popping in my head which I rediscovered recently, "Baby when the lights" by David Guetta. I think that would be a good song since it starts with "Baby" like the actual game, and there are lots of lights in the pinball section. And it should be fairly easy to adapt to the TIA since it's fairly repetitive and has got a simple chord structure. However, in order to take advantage of the repetitiveness, the music routine should support some kind of patterns, so I amended it a bit in order to support some additional commands. You currently have 00 for ending the tune and $FF for repeating it. I've introduced $80 for returning and anything from $81 to $FE for "calling" another tune as a pattern. The way it works is if a "negative" value other than $FF is encountered, rather than restarting the same tune, the byte is ANDed with $7F and the result gets used as the new tune number. Before initializing it, the current positions are saved in "return address" variables. If a $80 is encountered, a "return" is performed by fetching the current positions back from the "return address" variables. Now I "just" have to put in the music data...

Yeah, actually I thought of recording the sounds off of PinMAME as well, and I thought there would have to be a sound test feature or something, but I didn't know you can activate it by pressing different keys (actually I think the keys simulate the respective contact being made rather than only triggering the sounds, right?). For some sounds you would then probably press the keys multiple times in order for them to come up (like completing the spelling of PACMAN or achieving an extra baby).

@Imstarryeyed: Just to clarify which sounds would be needed: I think at this point we would need every sound that occurs in the pinball section. This encompasses at least the following events and sounds: - Baby comes down the chute (without Pacscalator) - Background drone sound - Spinners - Fruit / Tunnel rollover - Bumpers - Ball gets trapped in hole - Outer targets (spelling PACMAN) - Power pellet earned (I think this is the same for the upper ball as for completing PACMAN, or is it?) - Fruit advance - Tunnel speed increased - Even-up lane crossed - Pacscalator - Extra baby earned - Tilt (if it has any) I don't know if this list is complete, but this is all I can hear from the video, and all that comes to mind. @Bob and Imstarryeyed: As for the even-up rollovers, aren't they supposed to also even up power pellets earned? As in, if you're earned power pellet #1, and the ball crosses the left even-up lane with the yellow light lit, shouldn't power pellet #2 be lit up as well? I think the original game does this, but I could be wrong here.

OK... just as a bit of inspiration, here's my version of the spinner sound (which sounds a bit more "grouly", and I think I hit the original frequencies pretty closely): SC = $10 SV = $03 FFTUNE10: ;Spinner .BYTE #TT+$1D,#T7+$1D,#T8+$1C,#T8+$1B,#T8+$1A,#T8+$19,$00 CVTUNE10: .BYTE #SC+#05,#SC+#SV,#SC+#SV,#SC+#SV,#SC+#SV,#SC+#SV,$00

OK, thank you for the code! Let's see... 1. I think it takes too long for the spinner to come to a stop. If the ball hits it at full speed, that would be 6 pixels per frame at least, which puts the spinner speed at 7, so it takes 64 x 7 = 448 frames to stop, which is 7.5 seconds. In the arcade version this would be at most 2 seconds, so I think the spinner needs to slow down 4 times as often, which would be every 16 frames, not every 64. 2. The frequency table looks somewhat fishy to me. Since it contains the number of frames, it's actually the inverse frequency, and going from 1 to 5 seems pretty harsh to me since this step causes the frequency to be cut to a fifth. Most ot the time the spinner will be at values between $11 and $1D which, since each spinner only is processed every other frame, only causes the animation to change once to twice per second, which looks pretty slow to me. I probably would have done this part differently by giving each spinner a speed similar to the ball, expressed in sub-revolutions per frame, and a counter which overflows, causing the animation to change on each overflow. Now... i stated above that the animation frequency should be at 3 frames for each animation cycle if the ball speed was at 6 pixels per frame. We can't do that now because the way the animation is coded now, it needs to change at a multiple of 2 frames, so it's either 2 or 4 frames. This value is divided by 2 to give the "Spinframes" value. So assuming the first entry should be a frequency of 1, the 2nd one a frequency of 2 etc., corresponding to the number of pixels per frame the ball is travelling, the SPINFRAMES table would need to be changed. A frequency of 1 would mean that the animation should change every 18 frames, so the value in SPINFRAMES for this entry should be 9. For each subsequent entry, 9 should be divided by the number (and rounded), which would give the following table:: SPINFRAMES .BYTE $09,$05,$03,$02,$02,$02,$01,$01,$01 ... However, the sound and scoring should only be triggered every 4th time the animation is changing. And this still doesn't simulate the "hanging" spinner which would always stop in the same position. This is all I can do at the moment I'm afraid since I only have my old version of the code to work with. However, I managed to successfully implement your code, but it only spins the left spinner. Thinking of which, I think it's pretty improbably that both spinners will spin at once, so the handler only needs to "activate" the spinner the ball has hit, and then that's the only one that will be spinning. So much for my theory... Update: After a bit of experimenting with my version of your code (and inserting my Spinframes table), I come to the conclusion that it doesn't make such a big difference if the implementation is "dirty" or not. However, I think it would help trying to use the table I gave above and slowing down the movement every 16 frames instead of every 64, which I think would be quite easy to do.

I just looked at the video footage of Baby Pac-Man, and it seems to me like if hit at full speed by the ball (as fast as possible if hit directly from the flippers), the spinners do about 6 revolutions over the course of a second or a bit more and then stop. This seems to be accomplished by the "hanging" spinners basically stopping as they get under a certain minimum speed as they are affected by gravity as well (they accelerate towards the "down" position and even swing out like a pendulum when they don't make a complete revolution anymore). That's also how they get the mostly continuous spinner sound even though the spinner sound only lasts for about half a second. However, even though at full speed the spinner only does 6 revolutions, I still think each time the ball goes through a spinner should result in at least one visible change to that spinner. And the correct resting position for a spinner, I think, is when only the line is visible, not the white square. (I actually meant to edit the post above, but during the edit I got a visitor and the time for editing it elapsed)

Sorry, one more thing... while playing it some more, I noticed that sometimes, when the ball goes through the outer curves the "wrong" way, the spinners don't move at all. However, the ball must have *some* speed at that point due to the gravity involved, so I think it's unrealistic if the spinners don't move at all. This could be that the speed is considered too low or that the ball coming down affecting the spinners as well just isn't implemented at all yet. I think the initial speed of the spinners (as the ball touches them) should roughly correspond to the ball's speed, so if the ball comes down at, say, 2 pixels per frame, the spinners after having been touched should move at that rate as well. But since they only have two possible positions graphically, this would translate to about 1/12.5 revolutions per frame (Pi * 4), and during one revolution the graphics of the spinners would change back and forth twice, so... the correct speed in this case would be changing the spinner shape about every 3 frames. By the way, I think the correct display of a stopped spinner would be the thin line, not the thick square, and the spinner should always stop in this position. This could be achieved by only slowing down the spinner while it's in that position. Bob, maybe I made a mistake when I didn't implement the spinner motion myself, but I didn't do it because you told me you had a plan for it, so I left that bit alone.

Well, we can always speculate what would have happened if things would have run differently... Atari might have released the 7800 in 1984, and then the question would have been which software would have been released for it. Remember, this was a time when the hardware companies actually stepped back from software a bit and made way for third-party suppliers, so maybe Activision would have put out 7800 versions of their games such as Ghostbusters... and the Atari 7800 would then have competed against the Commodore 64, the Amstrad CPC, the TI-99/8, the Magnavox Odyssey^3 and the still-active Atari XL line. The next product then would have been the Atari Amiga which would have competed against the Commodore 65 (and there wouldn't have been an Atari ST). Only heaven knows what would have happened after that...

Here's something else I noticed while playing the game some more... Sometimes when you re-enter the pinball part, strange things happen, such as the upper ball coming down from a position somewhere in the loop or the spinner still doing some revolutions (with the sound accompanying it). I think that's unrealistic because in the original version, while the player plays the maze, the upper ball and the spinners should have come to a stop. I think some things need to be re-initialized when you enter the pinball part, such as the spinners stopping and the upper ball going to the end where it was last seen.

Playing it some more, I had two ideas... 1. You once had an error where power pellets already eaten would reappear on completing a maze. How about reinstating this under certain circumstances? My idea would be that if you complete a maze with at least one chute still open, you would get some power pellets in the next maze (on the side where the chute or chutes was open), while you get none (as usual) if you complete a maze with both chutes closed. This would reward the player for forfeiting another trip to the pinball part before completing the maze. I know this is probably not in the ruleset of the original game. 2. You now slowed down the red monster as well as adding some seconds of random movements in the beginning. I think that's about the right setting for the beginning of the game, but you could make it so that as the mazes progress, the random time gets shorter and the red monster gets faster until it reaches the same speed it had before the slowdown. This would make the game get gradually harder as the mazes progress.

Thank you for the update! As usual, I tried it as well, and here are my observations... The random seconds at the start (at least for the classic setting I tried) make the game noticeably easier since it gives the player a bit of a break in which it is able to munch more dots before heading for the pinball section, and everytime the maze is re-entered. However, this also makes it harder to develop patterns since the ghosts may end up in places you don't expect them. I see you've added one sound to the pinball section, which is the spinner sound. I think the spinner sound is a bit too loud, and I also wonder if it should be more "grouly" (different waveform as in my "Waka Waka" version of the dot eat sound). it's also a bit too short and/or not retriggered often enough. In the arcade version, you basically have the spinner sound continuously from the moment the ball touches the spinner until the spinner stops, with maybe one spinner sound at the end where it is not continuous. In your version it's now incontinuous most of the time, that is, the spinner sound stops before it gets retriggered. Also I noticed it doesn't start right away as the ball touches the spinner, but with a delay, which is somewhat irritating since the ball is already somewhere else when the sound comes in.

Thank you for the update! Here's a few things I noticed... - The game currently doesn't give you any extra lives. In the original version, you get an extra life every 10,000 points (maybe dependent on DIP switch settings). - The music sounds a bit strange with both voices being the same, only played in a different register, and the level start and dying music doesn't correspond well to the original one. - There seems to be bad debouncing on the pepper... it sometimes happens to me that I want to spray pepper once, but lose two units of pepper in the process. Also, when starting the game with the fire button, one pepper usually gets wasted because it's being fired right at the start. - The enemies spawn pretty suddenly and may spawn on top of the player (which happened to me once) while in the original version they always come in from the side so you can see them before they collide with you. - There seem to be some scoring defects. If you end the round by completing all the burgers, and the last burger part has got enemies riding on it, you don't get the score for the enemies riding the burger. - The bonus items are in different positions to the original versions. On the 6th screen the bonus item is even in an unreachable position! - After completing the 6th screen, the title screen reappears and has to be ended by the fire button (wasting pepper) before the cycle repeats. - On some occasions I "squashed" an enemy being on the same platform as me which should have been resulted in the enemy riding the burger part instead.

I haven't played any modern games this week, and I doubt I'll do so tomorrow, so no times from me for this week (again). If I do play something tomorrow, I'll post it seperately.

Here are my times for this past week (December 24th through 30th)... if I play something tomorrow, I'll post it seperately, but I'm not sure if I'll get to it tomorrow, so I do it today as usual... Atari 7800: Baby Pac-Man (WIP) - 102 minutes in 4 sessions As in the last week, again Baby Pac-Man on the Atari 7800 was the only game I played due to the fact that it's still in development and I'm now helping Bob testing it. I also helped doing a routine for it which transforms the mazes into different colors so that the necessary definitions shrink greatly in size and more room is left for sound. Other than that, I'm busy catching up on my household chores which I've neglected for months while developing Baby Pac-Man, that's why even though I have two weeks off work, I'm still not playing much.