Baby Pac-Man

[+Cafeman]

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

Not my area, but could it simply depend on speed if the ball, since a table is on a slope? Slow speed = yellow angle, medium speed = blue angle, fast speed = green angle?

[Albert]

Basically, because I'm an idiot.

 

False.

[RevEng]

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

In a system without gravity, the green looks right.

 

I think others would answer with other arrows, but they'll be compensating for gravity. You'll be applying gravitational velocity independently.

[Kurt_Woloch]

Well, it could... if the power bumper is actually powered. However, I've looked at videos from a real Baby Pac Man machine, and it seems like on this table, the power in the power bumpers is not actually very strong, so it might be a reasonably approximation to simply deflect the ball from the bumper surface without losing any momentum.

 

Your proposal, in fact, does come true since the ball's trajectory is of course no straight line, and the lower the ball speed is, the less it will travel to the right for the same distance down created by gravity. However, I purposely ignored this and only tried to give the starting angle of the deflected ball on my arrows. And without power, I don't think that shouldn't be affected by the incoming speed of the ball. Look at billards... there you actually count on the deflected ball going away from the wall at the same angle it hits it... no matter what its speed is. OK, the pool table is of course not sloped.

 

Not my area, but could it simply depend on speed if the ball, since a table is on a slope? Slow speed = yellow angle, medium speed = blue angle, fast speed = green angle?

[Andromeda Stardust]

 

False.

Quoted for truth. Bob is a phenominal programmer.

[Andromeda Stardust]

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.

Disassembly of NES games (6502 derivative) might prove helpful. Has anyone disassembled NES Pinball? It's a simple 16kb PRG Blackbox era game without bank switching.

[RevEng]

Disassembly of NES games (6502 derivative) might prove helpful. Has anyone disassembled NES Pinball? It's a simple 16kb PRG Blackbox era game without bank switching.

It's not like it's unknown how to proceed to add the physics to the sim. Kurt understands the high level. I understand the high level. But there are various trade-offs to be made for any particular implementation, and the devil is in the details. Until you've dabble a bit in the problem space, you don't even necessarily know what all those trade-offs are; I was thinking about the pinball sim speed and granularity the other day, and stumbled across a few that weren't apparent from the high level.

 

When reading the NES disassembly, once you manage to get the deeper story behind it (which will take a long while if you don't have a good understanding of the problem space) you still only get a snapshot of one possible set of trade-offs. The same is true even with the high quality source code to C64 Pinball Dreams, shared by NRV. It's instructive in an overview sense, and it might give you some good ideas, but it's not the direct path to your own implementation you might think it would be.

 

Kurt has this. No need to crib. We all just need be patient while he puts in the time.

[TrekMD]

Quoted for truth. Bob is a phenominal programmer.

I agree 1000%!

[Andromeda Stardust]

It's not like it's unknown how to proceed to add the physics to the sim. Kurt understands the high level. I understand the high level. But there are various trade-offs to be made for any particular implementation, and the devil is in the details. Until you've dabble a bit in the problem space, you don't even necessarily know what all those trade-offs are; I was thinking about the pinball sim speed and granularity the other day, and stumbled across a few that weren't apparent from the high level.When reading the NES disassembly, once you manage to get the deeper story behind it (which will take a long while if you don't have a good understanding of the problem space) you still only get a snapshot of one possible set of trade-offs. The same is true even with the high quality source code to C64 Pinball Dreams, shared by NRV. It's instructive in an overview sense, and it might give you some good ideas, but it's not the direct path to your own implementation you might think it would be.Kurt has this. No need to crib. We all just need be patient while he puts in the time.

Sorry, it's just that I'm such a fan of pinball sims, that any homebrew project is exciting to me. A lot of vintage games were really well designed, but they had teams working on them rather than typical solo homebrew programmers or ie homebrews labor division rarely being more complex than one guy does graphics, one guy does music, one guy does physics, and possibly in late stages of development, host a level design contest to utilize the community as a think tank. Guy doing actual coding and stitching assets together is like 90% of the workload.

 

It's more complex than just looking at codebase from comparable platforms, and perhaps you are right, what works on one game engine won't work for another. I'll admit I know dick about programming games in assembly, though I did make a "hello world" 2600 program in Batari Basic. Never moved past the title screen. Still that's more than most Atari 2600 fans will likely ever make (most gamers have never programmed anything)...

http://atariage.com/forums/topic/218359-troll-face-my-first-atari-2600-rom/

 

I do need to work on stop trying to be an "armchair quarterback" though...

[NRV]

From the things I have done with trajectories and different angles, I always assume that the pixel ratio is 2:1.

Sure, is not going to look perfect in NTSC or PAL (probably no one would notice), but then there are optimizations

you can do with angles and speed tables, where changing an X component to Y just means multiplying by 2 or dividing by 2.

[Inky]

Basically, because I'm an idiot.

Number of PacManPlus games in the Atariage store: Lots and lots.

 

Number of Inky games in the Atariage store: 0

 

Who's the idiot here?

[Albert]

Number of PacManPlus games in the Atariage store: Lots and lots.

 

Number of Inky games in the Atariage store: 0

 

Who's the idiot here?

 

It's not too late to learn!

 

..Al

[Inky]

 

It's not too late to learn!

 

..Al

 

I have ideas, but my ADD doesn't have the patience. Which is weird, because I used to do a lot of stuff in Game Maker.

 

I want to see Two Tigers on the 7800. One of my favorite games, and if I ever learn to program, that will be my second project. (Canyon Bomber would be first, as I see an overlap between the games)

 

 

[PacManPlus]

Sorry guys, didn't mean to start anything. (But again thank you for the too-kind words) I just hate it when I have trouble grasping a simple concept like that. It doesn't make me feel too good... and I'm very critical of myself anyway, so... It scares me when I have trouble learning something.

 

But anyway - I like what Kurt sent to me yesterday; it had the ball being served at an angle, and it bounced off the left bumper quite nicely aleady. He also put quite a few comments in it, so this should help me. He broke the screen up in quadrants (which I believe someone else mentioned as well). So it's much easier to deal with the screen collisions that way. He also employed gravity.

 

The big ones, however, are going to be the curves at the top of the screen. I can't wait to see how that's done.

 

What I need to do first, is take the graphics for the ball from the area they are in now, and somehow place them in another graphics block (the Attract Mode graphics block to be exact). I will need the ROM space, and I can't waste all of that space just for the ball. The fun part will be to figure out how to encode a 160A graphic in a 320B graphic block... But I think I can figure that one out...

 

*also, the disassembly of NES pinball was inadvertently left in my source code zip file. I disassembled the ROM and was trying to read it, but I think the disassembler left some large parts of code as data.

Edited September 11, 2018 by PacManPlus

[tschak909]

Why do we make this stuff?

 

Because we want to see it run.

 

That want is hella strong.

 

-Thom

[Kurt_Woloch]

OK... I think I got a clear answer to my question. There were basically two votes for the 1:2 aspect ratio (the green arrow) and none for any other possibility, so 1:2 it will be. Just considering how to do this. The first possibility would be to actually keep the ball coordinates in 320P (which would be possible because the screen is actually only 128 pixels wide) and then converting them down for display. The other one would be to keep the coordinates in 160P as they are now, convert the speeds to 320P before each direction change involving angles and then converting them back.

 

Another question is: Do you think I should post some intermediate binaries even if they still aren't playable yet? (The maze part is playable however... Bob even made some minor improvements before posting his source code which I picked up)

[NRV]

I just hate it when I have trouble grasping a simple concept like that.

And.. who told you this one is "simple"?

I mean, I was part of a team doing a comercial Arkanoid-like game once and the "physics" for that (well, mostly collision detection and reactions) were easier, because you can search for known equations and algorithms, and you can use a good math library.

But doing something similar in a 6502 with limited memory is a lot more difficult, because you normally start from zero, and need to get very creative with the limited resources.

 

It doesn't make me feel too good... and I'm very critical of myself anyway, so... It scares me when I have trouble learning something.

I would say that is the real problem here, but now that you know you can start working on that

Probably nobody here wants you to do this in a fixed frame of time, so take the time you need and have fun.

And ask for help when you need it

 

 

 

The first possibility would be to actually keep the ball coordinates in 320P (which would be possible because the screen is actually only 128 pixels wide)and then converting them down for display.

The other one would be to keep the coordinates in 160P as they are now, convert the speeds to 320P before each direction change involving angles and then converting them back.

Working with coordinates in one byte is easier than working with two, but in the end it will depend on how many times you need to convert from one "side" to the other.

What are you going to prioritize, memory or processing time..

Are you also going to use sub pixel precision (more bytes) for the positions and speeds?

 

Inclusive if you choose one option now, you may want to change it later, but I would vote for one byte positions for now (for the "integer" part at least).

[Kurt_Woloch]

This is not a question about how many bytes the coordinates have... there are already pixel and sub-pixel coordinates as well as pixel/frame and subpixel/frame speeds, and I'm going to stick with that. The pixel coordinates will also always have only one byte because the playfield in 160 mode is 128 bytes wide, so if I double that it would still fit in a byte. It helps that the ball never wraps around.

 

Memory or processing time? Hmmm... the 7800 has 2K of RAM as far as I know, and I don't know how much of that already gets used for the tile map and display list. As for now. I'm trying to stick with the temp variables and the pinball variables reserved by Bob. The pinball variables are 32 bytes for game objects + 32 bytes for balls (out of which 5 are still free), and the temporary ones 16 bytes. I'm trying to keep within this frame, though it might get tricky during some of the calculations that need to be done.

As for speed, the 6502 in the 7800 is running at 1.79 MHz, but much of that is being taken away during screen display by the Maria DMA. Bob was always afraid of something not fitting into one frame, so I'm cautious how many cycles I use for one collision.

Oh, and currently there's about 1379 bytes free for code in the block I'm using. So far I seem to have used up about 308 bytes, so I might scratch that limit sooner or later.

 

As for Bob claiming to be an idiot... I don't think so at all. Each man has got its strengths and weaknesses. For instance, I'm generally weak socially, and I'm having a hard time starting conversations, always afraid I might annoy someone. And at work, even though I do work as a programmer, I must admit I often have a hard time grasping everything I need because there's a lot of domain knowledge we're supposed to keep in our heads, which is where I often fail, unfortunately. To compensate for this, I'm good at math and trigonometry. But I do admit that it actually seems to me that I have a talent for making other people look like an idiot without even trying to do so, and it's actually depressing for me if I see that again I seem to have discouraged someone to the point that he/she gives up what he/she was doing. This I actually consider a weak or mean side of me.

 

Working with coordinates in one byte is easier than working with two, but in the end it will depend on how many times you need to convert from one "side" to the other.
What are you going to prioritize, memory or processing time..
Are you also going to use sub pixel precision (more bytes) for the positions and speeds?

Inclusive if you choose one option now, you may want to change it later, but I would vote for one byte positions for now (for the "integer" part at least).

[PacManPlus]

 

Another question is: Do you think I should post some intermediate binaries even if they still aren't playable yet? (The maze part is playable however... Bob even made some minor improvements before posting his source code which I picked up)

 

I think we should wait until we have something to show.

I've made some other changes, like moving the "current fruit" indicator and the "tunnel speed" indicator all the way down to just above Pac's and Ms. Pac's heads. This was done to be able to show the indicators more clearly, and to be able to move them out of the area I'm trying to clear out.

 

All that's left are the two 'ball' bitmaps. I'm currently trying to re-work the 160A graphics for this in a 320B area, so that above and below the bitmaps are blank (the only place I can put them is in the $4000-$7FFF area, and 'holey DMA' doesn't apply to that area of memory). Doing so will give me an extra 4K of space for code.

[TrekMD]

Thank you for continuing to work on the game! Here's to team effort!

[+swlovinist]

Bob, your games are amazing. We support you and thank you for continuing on this project.

[PacManPlus]

Thanks, guys.

 

OK, I figured out how to encode a 160A graphic inside a 320B graphics block. It was a pain, but worth it. We can now use $A000-$AFFF for code / tables.

 

The two seemingly garbage characters just to the right of the two yo-yos, are the two ball animations. They actually translate correctly in 160 mode:

 

Now on to add Kurt's changes...

Edited September 13, 2018 by PacManPlus

[+DrVenkman]

Bob, your games are amazing. We support you and thank you for continuing on this project.

 

Let me just add:

 

Bob, we've never met but I've fooled/dabbled with a number of your titles in emulation and have always been very impressed. Just this past week, I received my boxed copy of BBCQ. It is sublimely wonderful. It will most certainly not be the last of your titles I buy.

[PacManPlus]

Thank you.

 

Done for the night. Added:

- Ball serve, movement, gravity (currently hard-coded, but I might make it a configurable value - not sure yet)

- Left table edge and Right table edge boundary check (the easy part) - made the ball reverse direction and lose half it's horizontal momentum.

- 'Special Thanks' screen which replaced the 'Point Value' screen

- Moved the Tunnel Speed and Fruit indicators to the bottom of the table, and made them tiles instead of sprites.

- Fixed PAL colors

- Fixed garbage that appeared when 'bumping' the table in PAL mode

- Moved ball bitmap to Attract Mode graphics block, to free up $A000 to $AFFF

 

I guess I just needed a kick start to get me going again. Still need Kurt for the curves at the top of the screen though... Those are the other things I am having a problem understanding.

Will post a binary soon.

Edited September 14, 2018 by PacManPlus

[imstarryeyed]

Hey Bob this game is really looking amazing!! It just might be my most favorite 7800 homebrew of all time.. , but I am a bit jaded as I love Baby Pac Man.

 

I don't know if you or Albert were considering doing anything special for this game in regards to packaging, limited edition boxes or swag like key chains or T shirts, but if you were thinking of doing anything special, I am on board for any of it. Owning the real game, I consistently am blown away about how console pushing this game will be...

 

I mean hey.. it shouldn't exist, but there it is.. defying all logic..

 

Keep up the great work guys, this is one to write home about.