Baby Pac-Man

[iesposta]

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.

 

 

There is:

include div_mul16.asm

which allows 16-bit division and multiplication using " ** ", however RT's website says it hasn't been fully tested, and I don't know if it works or does not work in the bB1.1 DPC+ Kernel. (I've had the other one in my DPC+ Kernel code: "include div_mul.asm" and bB doesn't complain, but commenting it out everything still compiles and works.)

 

Maybe Bob will share his 7800 assembly code for ball physics?

Just that writing my own routines for gravity, momentum, force, etc. I will know what values to experiment with to get different gameplay movement.

[Kurt_Woloch]

 

There is:

include div_mul16.asm

which allows 16-bit division and multiplication using " ** ", however RT's website says it hasn't been fully tested, and I don't know if it works or does not work in the bB1.1 DPC+ Kernel. (I've had the other one in my DPC+ Kernel code: "include div_mul.asm" and bB doesn't complain, but commenting it out everything still compiles and works.)

 

Yes, there is, but as far as I've seen, it only supports multiplication of two 8-bit variables, giving a 16-bit result, so 8.0 * 8.0 = 16.0. What we'd need for my formulas is 8.8 * 0.8 = 8.8 and 8.8 + 8.8 = 8.8 routines. You could maybe get around that by limiting the motion to 16 pixels per frame (so essentially 4.4), then you have one byte that you can multiply with that 0.8 (converted to a 8.0) giving a 16-bit result (16.0) which would actually be 12.4 and should then be converted back to 4.12 (out of which the lower 4 or 8 bits could be discarded). I don't have experience with the different kernels available because I've never programmed in Bb.

[Kurt_Woloch]

Well, I was looking for a multiplication routine that might do what's necessary for the formulas given above, and I've found one... theoretically. The problem is that it doesn't quite work out, but anyway, look here:

 

http://codebase64.org/doku.php?id=base:8bit_multiplication_16bit_product

 

This multiplies the base numbers that are in my formula as well, one 8-bit number (actually 0.8 in my formula) and one 16-bit number (actually 8. .

The trouble is, there can be overflows if the result exceeds 16 bit, and with my numbers it would because the result should be 24-bit treated as 8.16 in my formula (with the lower 8 bits stripped away to get 8.8 again).

 

But I think I got the principle of the multiplication routine, so here I'll try to extend it to the format we need for my formulas:

;------------------------
; 16bit * 8bit = 24bit multiply
; By White Flame, extended by Kurt Woloch
; Multiplies "factor8" by "factor16" and stores result in resultL, resultM and resultH

; In this version, both inputs must be unsigned

; We need the following 1-byte variables that are not declared here:
; Source values: factor8, factor16L, factor16H (do not get changed)

; Temp values: tempfactor8, tempfactor16L, tempfactor16M, tempfactor16H

; Result value: resultL, resultM, resultH

; initialisation, leave this out if there is a number the new product should be added to
; in this case that number should be stored in resultL, resultM and resultH

 lda #$00
 sta resultL
 sta resultM
 sta resultH

; initialisation of temporary values for factors because those get shifted away

keep_result:
 lda factor8
 sta tempfactor8

 lda factor16L
 sta tempfactor16L
 lda factor16H
 sta tempfactor16M
 lda #$00
 sta tempfactor16H

 beq enterLoop

doAdd:
 clc
 lda resultL
 adc tempfactor16L
 sta resultL

 lda resultM
 adc tempfactor16M
 sta resultM

 lda resultH
 adc tempfactor16H
 sta resultH

loop:
 asl tempfactor16L
 rol tempfactor16M
 rol tempfactor16H

enterLoop:  
 lsr tempfactor8
 bcs doAdd
 bne loop

The way you would use this in my formulas is the following:

 

Assuming you have the current ball speed in each direction (x and y) as an 8.8 number (8-bit pixel, 8-bit subpixel) and the computed sin and cos values as a 0.8 number (since they can only be 0 to 1). Then the 8.8 ball speed would be used as factor16, and the sin / cos values would be factor8. The result would be put back into the ball speed by making resultH the pixel and resultM the subpixel value with resultL being discarded.

 

So since it gets discarded you can cut the sequence lda resultL / adc tempfactor16L / sta resultL, but doing so impacts the precision of resultM a bit (by up to 8 "ticks" or 1/32 pixels/frame) because adding up resultL also generates the carry which is added up to resultM.

 

I hope this is halfway clear and usable... and I didn't make any coding mistakes.

 

You could also use the registers X and Y instead of resultM and resultH as it's done in the original version (albeit a bit unclearly) which would speed up the code a bit, but you have to use those variables in the end, of course.

 

To illustrate this, here's another code example how to call this. Let's assume we did the following:

mul_16_8:

<code above>

rts

Then we can call the subroutine as follows in order to calculate one of my formulas, let's say these ones:

 

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

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

 

Let's assume we've stored the values as follows:

 

xH... ball speed x in pixels

xL... ball speed x in subpixels

yH... ball speed y in pixels

yL... ball speed y in subpixels

 

sina2... sin(a*2) (fractional) (pre-computed)

cosa2... cos(a*2) (fractional) (pre-computed)

 

Now we first calculate the part x * cos(a*2):

lda cosa2
sta factor8
lda xL
sta factor16L
lda xH
sta factor16H
jsr mul_16_8

Now we have the term x * cos(a*2) in the variables resultL, resultM and resultH. In order to subtract this from the next term, we have to negate them:

lda resultL
eor #FF
sta resultL
lda resultM
eor #FF
sta resultM
lda resultH
eor #FF
sta resultH

Now we add the term y * sin(a*2) to the result. To do this, we enter the multiplication routine at the entry point where the result doesn't get cleared:

lda sina2
sta factor8
lda yL
sta factor16L
lda yH
sta factor16H
jsr keep_result

Now we have completed calculating the new x value, but we can't store it away yet because we have to use the ORIGINAL x value to calculate the new y value, so we'll temporarily use the X and Y registers to store them (since the multiplication routine doesn't use X and Y):

ldx resultM
ldy resultH

Now we add up the new Y value according to the formula above the same way, but this time we don't have a negative term, so we don't have to do the negation part, and the code for doing this gets reduced to:

lda cosa2
sta factor8
lda yL
sta factor16L
lda yH
sta factor16H
jsr mul_16_8

lda sina2
sta factor8
lda xL
sta factor16L
lda xH
sta factor16H
jsr keep_result

Now we just need to store the new direction values in the ball direction variables:

stx xL
sty xH
lda resultM
sta yL
lda resultH
sta yH

Note that if we always use the multiplication this way, there are some things that could be optimized... for instance, we could store yL, yH, xL, xH, sina2 and cosa2 in the temporary factor variables instead of the non-temporary ones because we still have got them in their original variables where they don't get discarded by the multiplication routine.

[+DrVenkman]

Guys - are you actually discussing Bob's Baby Pac-Man WIP or have you hijacked this into a general 7800 math programming thread? Because if it's the latter rather than the fomer, there's maybe a better place for that, I think.

[iesposta]

Guys - are you actually discussing Bob's Baby Pac-Man WIP or have you hijacked this into a general 7800 math programming thread? Because if it's the latter rather than the fomer, there's maybe a better place for that, I think.

As Bob is creating a video pinball part to Baby Pac-Man; Kurt offering physics routines; and Bob replying, “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 commented that pinball movement was something I’ve had no luck finding physics code, and here it’s being discussed.

Then I say perhaps another thread with this information would be a good thing.

I ended with “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! !”

 

And not 7800 math, but 6502 pinball math - which applies to the 2600 and the 7800.

 

Isn’t game code discussion for use in Baby Pac-Man WIP a helpful thing to Bob?

Edited July 10, 2018 by iesposta

[Kurt_Woloch]

Well, if you've got your own snippets in Batari Basic for your own WIP, we could open a new thread for that one and continue the physics code discussion there.

[iesposta]

Well, if you've got your own snippets in Batari Basic for your own WIP, we could open a new thread for that one and continue the physics code discussion there.

Thanks so much for offering to help!

I havent started a pinball or even pong-ball like Video Pinball.

 

I help designers like you and others are helping Bob. Ive been helped by members because I know next to nothing about coding game logic.

 

Bob returning to 7800 coding, and a game with pinball at that, is so exciting!

 

Great achievements and games are coming out despite being able to do an entire production by yourself, but because so many talented members here share what they know and help and contribute their work for free because its a hobby we love.

[Kurt_Woloch]

OK, now... there's one caveat in the code I gave which I didn't think of yesterday, which is with negative numbers. The code I gave above actually assumes that all factors are positive; if they are negative, the multiplication won't work correctly. But actually they can be negative... both the sin and cos values and the x/y speeds. Thus, sadly, the code I gave above doesn't always work correctly. To make it work correctly, you'd have to do the following:

 

- If both factors are positive, you can add them up as described

- If one factor is negative, you have to negate that one so that it becomes positive, negate any result to which the new result should be added up, then do the multiplication and then negate the result again.

- If both factors are negative, you have to negate both factors and then do the multiplication with their positive counterparts.

- For the "-sin(a2)" part, you have to negate the result afterwards if none or both factors are positive, but not negate it if one of them is positive and one negative.

 

For the x and y velocities, you can assume they're negative if their high bit is set, and then adding them up between frames (without collision) will work the same regardless if positive or negative. However, the sin and cos values already use up the full range of one byte (for the fraction from 0 to 1), so if they're supposed to be negative, you have to note this elsewhere and then account for it.

 

Yes, I know it gets even more complicated...

[keitaro]

Hi Guys:

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

 

A few things:

• 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

 

Hi Bob, nice to see a new development from you. I tested in PAL and works fine. No glitching at bottom, colors are fine except for background is dark red (I don't tested ROM in emu to compare I guess should be black). Bump at pinball screen has a small graphic glitch when bumping up, I attached some pictures.

 

Also I played Video only mode and It's awesome!! Fast and very addictive, I finally I quit from play saying: "wait to cart release"

Regards!

 

 

 

[PacManPlus]

Thank you - I fixed the colors, and the garbage when 'bumping' up in PAL mode.

 

No other updates are done yet, so I'll wait to post a BIN... Unsure of how to start this pinball part...

[iesposta]

Thank you - I fixed the colors, and the garbage when 'bumping' up in PAL mode.

 

No other updates are done yet, so I'll wait to post a BIN... Unsure of how to start this pinball part...

Suggestions: Pinball Construction Set source code is on GitHub. Apple II uses a 6502. Learn from the source code if routines have comments?

 

2600 Midnight Magic contains ball physics. I don’t know if there is source code for this 1986 released title.

[Kurt_Woloch]

How to start it? I guess one good first step would be to make the ball move...

 

I took a deep look into Atari 7800 programming in the meantime, and I guess that right now you only have the ball in one zone, so you could start by making it so that the ball is able to move into any scanline it could possibly go to and adjust the display lists correctly...

 

then the next step could be to make it move by itself in a proper ballistic curve, starting at the bottom where the ball is shot out in the original game.

 

 

Thank you - I fixed the colors, and the garbage when 'bumping' up in PAL mode.

 

No other updates are done yet, so I'll wait to post a BIN... Unsure of how to start this pinball part...

[PacManPlus]

Thank you both for the replies... although that wasn't exactly what I meant when I said I wasn't sure how to start it...

[Kurt_Woloch]

So what is it you mean? Can we help you with it or do you have to find your way yourself?

[PacManPlus]

Thank you-

I have to find my way myself. Ive been losing interest a little because of real life issues, and im trying not to.

Edited July 14, 2018 by PacManPlus

[SlidellMan]

Mr. DeCrescenzo, I know you can do this. Hell, I bet you could make a fully-functional Lemmings clone on the 7800 given your imposing skills.

[Andromeda Stardust]

Thank you both for the replies... although that wasn't exactly what I meant when I said I wasn't sure how to start it...

It's easy. Walk up to pinball table, insert coin, pull plunger.

 

On a serious note, did you not try to contact Brian Parker of RetroUSB for programming tips? He made a fantastic pinball game for the annual 8-bit Xmas '16 Christmas cart, and documented much of the development process...

http://nintendoage.com/forum/messageview.cfm?catid=22&threadid=162942

[Jinks]

It's easy. Walk up to pinball table, insert coin, pull plunger.

 

On a serious note, did you not try to contact Brian Parker of RetroUSB for programming tips? He made a fantastic pinball game for the annual 8-bit Xmas '16 Christmas cart, and documented much of the development process...

http://nintendoage.com/forum/messageview.cfm?catid=22&threadid=162942

From what I read Bob is focusing on real life things at this time.

[DracIsBack]

Thank you-

I have to find my way myself. Ive been losing interest a little because of real life issues, and im trying not to.

 

At your leisure Bob! 100% at your leisure!

 

:-)

[+Defender_2600]

Happy Birthday PacManPlus !! :party:

 

 

[Atari PAC-MAN Fan]

Happy Birthday PacManPlus !! :party:

 

 

Happy Birthday PacManPlus.PNG

 

Looks delicious! What flavor?

[+Cafeman]

The Pittsburgh Replay FX show had Baby Pac-man there, I got to spend some real time with it for the first time ever. I found the game to be pretty hard, I only unlocked two energizes from the pinball part of the game; also, the monsters are fast and immediately home in on poor baby Pac! This 7800 port looks great, and wow I think you have your work cut out for you translating the pinball part. Make sure you include the significant board slant / gravity that makes it easy to lose your ball!

 

Keep on PAC'n...

[PacManPlus]

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 

[Kurt_Woloch]

Hmmm... I doubt if this approach will lead to realistic ball behavior... at least as long as it's free rolling.

 

Also, I'm a little confused... you talk about three variables, but there's something amiss here... if you express the ball movement as a combination of angle (direction) and speed, this would be two variables (i.e. angle from 0 to 31 and speed from 0 to 7) from which the x and y direction values (two more values) would be derived (via the sin/cos table).

 

Now if you say it's difficult to find out what the ball does when colliding with the table, I thought you had chosen this expression of speed BECAUSE it makes it easier to calculate the ball behavior when bumping into something. At least the new speed would be easier to calculate than with the scheme I gave before... you have the angle normal to the thing the ball is colliding with (if you have it) and the angle the ball is coming in at... and the new angle would be (normal angle) + (normal angle - previous ball angle). Of course, it gets much more complicated if the ball isn't supposed to bounce back with full force, but with a lighter one.

[PacManPlus]

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

Edited August 24, 2018 by PacManPlus