Pac_Man Eat n Run

[+Random Terrain]

Having no pfpixel makes it almost impossible for me to figure anything out with that kernel. It's way over my head.

[+Lewis2907]

Having no pfpixel makes it almost impossible for me to figure anything out with that kernel. It's way over my head.

RT,

 

I agree, but it's interesting to play with Bogax code. Making me think (for what I know in Bb) and just try stuff here and there. I was hoping to get this to work so you can make a Multisprite Maze for the page that you maintain. That would make a complete collection of your "Mazes" and then allow me to convert the DPC+ Pac_Man_Eat n Run.

 

http://atariage.com/forums/index.php?app=core&module=attach&section=attach&attach_id=473911

 

Since it won't play on the AFB I decided to stay with Standard and Multisprite. If they fix the AFB to work with DPC+ that would be great. Thanks again for trying to help. I will continue to play with the code and see what I can do with the plug and play method.

[+Lewis2907]

I'm not sure if anyone can explain it better or if I am wrong. I'm guessing here.

 

;***************************************************************
; Below I think is where you make changes to adjust the pixel decection
; I assume dim __Temp1 = e : dim __Temp2 = f (replace temp1 / temp2)

;
; Then make adjustments by guessing and plug this into the down and right
; movement of the code. Should work I guess.
;
temp1 = player0x
temp2 = player0y

temp1 = (player0x - 16)/4
temp2 = (player0y-3)/2
temp1 = msk_pf_rd(temp1, temp2)

 

 

;***************************************************************
;
; Controls the pfread portion of the playfield.
; maybe adjust pfheight=1
; correlation maybe difficult (if someone wanted a different pfhieght)
;

temp1 = temp1 & 7
temp1 = bits[temp1] & temp2
if temp1 then temp1 = 255
return

 

data bits
$80,$40,$20,$10,8,4,2,1
end

[+Lewis2907]

Here is another update. I am stuck with Bogax's code, but I am using code from Gemintronic "SLost001.zip". It looks more promising.

 

The collsigion is working (almost there). Mainly in Batari Basic form vice ASM. Also will bank switch.

 

Is it possible to get the below use fixed point math? I have tried the formulas I am use to and no luck. If the below could have .1 instead of 1. Then the sprite would glide more precisely along the walls.

 

if joy0left then global_temp1 = global_temp1 - 1
if joy0left && !pfread(global_temp1, global_temp2) then player_x = player_xprevious + 1
if joy0left then player_x = player_x - 1
if player0x < 20 then player_x = player_x + 1

 

 

I think I'm a lot closer to getting this to work. Any help or ideas would be appreciated, thanks.

 

***Edited***

 

Cleaned up the code and put remarks in the program. Still one pixel off for a clean 8*8 sprite. Could shrink the sprite some to make it "look" cleaner.

 

I also attached the Standard Kernel Collision Detection as well. The two are similar, but I am missing something on how to make it work for the Multisprite. I think I know why and will try that option next.

MultiSprite_pfread_Alt.bas.bin

201724 -Alternate Multisprite Collision Detection.txt

MultiSprite_pfread_Alt.bas.bin

201725 -Alternate Multisprite Collision Detection.txt

20171213_Collision_Detection.bas.bin

20171213 - Standard Kernel.txt

Edited December 25, 2017 by Lewis2907

[+Lewis2907]

Managed to get the sprite to look very smooth for movements. The issue still one pixel for a reference point, but I can live with this. Hopefully someone can make it a true 8*8 sprite. I have an idea to maybe flip the reference point of the pixel to allow for better detection, but that is still a WIP. Fixed point math works now for player speed control. Will bank switch 32k or 32kSC.

 

Maybe RT can now work his magic and make a "multisprite maze". I plan to try and insert his code to see what I can do and then continue to work on Pac_Man Eat n Run (Multisprite) and Standard Kernel Versions to play on the AFP. I have stopped with the DPC Verison as I am wanting to make games for the AFP.

MultiSprite_pfread_Alt.bas.bin

201726 -Alternate Multisprite Collision Detection.txt

[+Random Terrain]

Since a little time has gone by and my frustration with it has faded, I'll look at that maze program that I was trying to convert to multisprite and see if I can get it working.

[+Lewis2907]

Since a little time has gone by and my frustration with it has faded, I'll look at that maze program that I was trying to convert to multisprite and see if I can get it working.

RT, thanks. I know this is probably a daunting task. From what I have learned so far this code can be adapted to make other multisprite games. The "Maze" examples are difficult in themselves. It seems I make some progress then I get stuck. This is what I have tried so to "trick" the one pixel by moving and or triggering it to "simulate" the 8*8 sprite.

 

of note player0x = 81, 82, 83, 71, 70, 69 seems not to work unless the playfield is drawn completely to keep player0 from crossing the playfield. I assume it's because of the mirrored playfield.

 

;***************************************************************

;

; Don't move up if pfpixel is in the way. (Works somewhat, 1 pixel off)

; Don't move up off screen. Boundry set.

; Player speed control .5 + .5 must equal a whole number to work

;

; if joy0up && !_Bit6_Flip_P0{6} controls sprite facing right and up

; if joy0up && _Bit6_Flip_P0{6} controls sprite facing left and up

;

if joy0up && !_Bit6_Flip_P0{6} then global_temp2=((player0y-4)/2)+1 : global_temp1=(player0x - 16)/4

if joy0up && !_Bit6_Flip_P0{6} && !pfread(global_temp1, global_temp2) then _P0_U_D= _P0_U_D - .5

 

if joy0up && _Bit6_Flip_P0{6} then global_temp2=((player0y-4)/2)+1 : global_temp1=(((player0x - 5)/4)-1)

if joy0up && _Bit6_Flip_P0{6} && !pfread(global_temp1, global_temp2) then _P0_U_D= _P0_U_D - .5

 

if joy0up then _P0_U_D = _P0_U_D + .5

if player0y > 84 then _P0_U_D = _P0_U_D - 1

 

;***************************************************************

;

; Don't move down if pfpixel is in the way. (Works for 8*8 sprite)

; Don't move up off screen. Boundry set.

; Player speed control .5 + .5 must equal a whole number to work

;

; if joy0up && !_Bit6_Flip_P0{6} controls sprite facing right and down

; if joy0up && _Bit6_Flip_P0{6} controls sprite facing left and down

;

if joy0down && !_Bit6_Flip_P0{6} then global_temp2=global_temp2-4 : global_temp1=(player0x - 16)/4

if joy0down && !_Bit6_Flip_P0{6} && !pfread(global_temp1, global_temp2) then _P0_U_D= _P0_U_D + .5

 

if joy0down && _Bit6_Flip_P0{6} then global_temp2=global_temp2-4 : global_temp1=(((player0x - 5)/4)-1)

if joy0down && _Bit6_Flip_P0{6} && !pfread(global_temp1, global_temp2) then _P0_U_D= _P0_U_D + .5

 

if joy0down then _P0_U_D = _P0_U_D - .5

if player0y < 4 then _P0_U_D = _P0_U_D + 1

201726v1 -Alternate Multisprite Collision Detection.txt

MultiSprite_pfread_Alt.bas.bin

Edited December 27, 2017 by Lewis2907

[+Lewis2907]

Attached is the Multisprite Version I am working on. Since there is no pfpixel or exact pfread that I know of I did the calculation based up "X" and "Y" points. So far it's working. My issue so far is that when moving up and down the edges and you push right you stop and move right. I have been trying to find a way to make player0 move and up and down and by pass the "right" or "left" getting stuck. It will work later on as I have plans to move to next screen as in the DPC Version (I will work that once AFP can support it). I also have a few more ideas for the game as well that should make it more interested than the DPC Version.

 

I think my issue is below and through out the code. Once I complete this I am going to move on to making player1-4 move about the maze. This will be interesting as I am running low on variables, but I have an idea to use Constants since Batari Basic had a limit of 50 constants, but that limit was later increased to 500. As always thanks to everyone for helping me improve my programming of Bb, thanks.

 

;***************************************************************
;
; Allows player0 to move down to a level 6
;
if player0x = 19 && player0y <= 30 then gosub __Down
if player0x = 40 && player0y <=30 then gosub __Down
if player0x = 57 && player0y <= 30 then gosub __Down
if player0x = 95 && player0y <= 30 then gosub __Down
if player0x = 112 && player0y <=30 then gosub __Down
if player0x = 133 && player0y <= 30 then gosub __Down
if player0y = 18 then _Bit0_P0_Floor = 6 : return
if player0y < 30 then return

;***************************************************************
;
; Sets player0 right side limits based off of playfiield
;
if player0x > 18 && player0x < 70 then gosub __Left_Right
if player0x = 18 then gosub __Right
if player0x = 70 then gosub __Left

;***************************************************************
;
; Sets player0 left side limits based off of playfiield
;
if player0x > 82 && player0x < 134 then gosub __Left_Right
if player0x = 82 then gosub __Right
if player0x = 134 then gosub __Left

return

 

 

20180607 - PacMan_Eat_N_Run_(Multisprite).txt

20180605_Multisprite_Pac_Man.bas.bin

20180605_Multisprite_Pac_Man.bas

[+Lewis2907]

Another update. I fixed it where it won't get stuck on the outer walls. Next update will have the ability to move through the exits either to another Level or just a Warp. That was one idea I plan incorporate into this Version. Along with the Ghost Moving about. That will be a challenge in itself to accomplish.

20180608_Multisprite_Pac_Man.bas.bin

20180605_Multisprite_Pac_Man.bas

20180608 - PacMan_Eat_N_Run_(Multisprite).txt

[+Lewis2907]

I would post the code like I normally do, but it very messy with notes and different versions based on different ways i'm trying to go. If I can get some ideas / help below I can try to work it in.

 

Is there a way to make this work or easier way? Basically if I can pin point the exact coordinates like below and have a "Random Number" based off of "Select" then player2 has no choice but to follow the maze until the next opening and pick randomly. The issue I see thus far is that the pattern might be very predictable.

 

;****************************************************************
;
; Blue Ghost / Player2 moves right at start of level
;

 

__Blue_Ghost_Move

if Blue_Ghost = 0 then _P2_L_R = _P2_L_R + .5

if player2x = 77 && player2y = 64 then Blue_Ghost = (rand&3)+1 : gosub __All_Blue_Moves ; Select 2
if player2x = 28 && player2y = 78 then Blue_Ghost = (rand&3)+1 : gosub __All_Blue_Moves ; Select 1, 4
if player2x = 28 && player2y = 64 then Blue_Ghost = (rand&3)+1 : gosub __All_Blue_Moves ; Select 1, 3, 4
if player2x = 28 && player2y = 16 then Blue_Ghost = (rand&3)+1 : gosub __All_Blue_Moves ; Select 1, 3
if player2x = 141 && player2y = 16 then Blue_Ghost = (rand&3)+1 : gosub __All_Blue_Moves ; Select 3, 2
if player2x = 141 && player2y = 78 then Blue_Ghost = (rand&3)+1 : gosub __All_Blue_Moves ; Select 2, 4
return

 

__All_Blue_Moves
if Blue_Ghost = 1 then _P2_L_R = _P2_L_R + .5 ; go right
if Blue_Ghost = 2 then _P2_U_D = _P2_U_D - .5 ; go left
if Blue_Ghost = 3 then _P2_U_D = _P2_U_D + .5 ; go up
if Blue_Ghost = 4 then _P2_U_D = _P2_U_D - .5 ; do down
return

 

 

My other question is there a way to reduce my "bloated code" it works, but takes up a lot of space. Currently this only leave 907 in bank 2. I used return otherbank to gain 10 bytes per use. At this rate I would be able to make maybe 5-6 levels which is no where like the DPC version with 25 levels.

 

__3F_L1
;***************************************************************
;
; Allows player0 to move up to a level 2
;
if player0x = 19 && player0y >=54 then gosub __Up bank6
if player0x = 40 && player0y >=54 then gosub __Up bank6
if player0x = 112 && player0y >=54 then gosub __Up bank6
if player0x = 133 && player0y >=54 then gosub __Up bank6
if player0y = 66 then _Bit0_P0_Floor = 2 : return otherbank
if player0y > 54 then return otherbank

 

;***************************************************************
;
; Allows player0 to move down to a level 4
;
if player0x = 19 && player0y <= 54 then gosub __Down bank6
if player0x = 52 && player0y <= 54 then gosub __Down bank6
if player0x = 100 && player0y <= 54 then gosub __Down bank6
if player0x = 133 && player0y <= 54 then gosub __Down bank6
if player0y = 42 then _Bit0_P0_Floor = 4 : return otherbank
if player0y < 54 then return otherbank

 

;***************************************************************
;
; Sets player0 left and rights limits based off of playfiield
;
if player0x > 30 && player0x < 122 then gosub __Left_Right bank6
if player0x = 30 then gosub __Right bank6
if player0x = 122 then gosub __Left bank6

 

;***************************************************************
;
; Sets player0 left and rights warp location "Middle of Screen"
;
if player0x = 133 && joy0right then _Bit6_Flip_P0{6} = 0 : _BitO_P0_Direction = 5 : gosub __Right_Warp bank6
if _BitO_P0_Direction = 5 then gosub __Right_Warp bank6

if player0x = 19 && joy0left then _Bit6_Flip_P0{6} = 1 : _BitO_P0_Direction = 6 : gosub __Left_Warp bank6
if _BitO_P0_Direction = 6 then gosub __Left_Warp bank6

 

;***************************************************************
;
; Sets player0 left and rights correct direction after warp
; location "Middle of Screen"
;
if c{3} && player0x = 133 then gosub __Static_Player bank6
if c{4} && player0x = 19 then gosub __Static_Player bank6
return otherbank

[bogax]

Get rid of the redundancy

166 bytes

 

   if player0x = 19 && player0y >=54 then gosub __Up bank6

   if player0x = 40 && player0y >=54 then gosub __Up bank6

   if player0x = 112 && player0y >=54 then gosub __Up bank6

   if player0x = 133 && player0y >=54 then gosub __Up bank6

   if player0y = 66 then _Bit0_P0_Floor = 2 : return otherbank

   if player0y > 54 then return otherbank

 

148 bytes

 

   if player0y < 54 then skip 

 

   if player0x = 19 then gosub __Up bank6

   if player0x = 40 then gosub __Up bank6

   if player0x = 112 then gosub __Up bank6

   if player0x = 133 then gosub __Up bank6

 

   if player0y = 66 then _Bit0_P0_Floor = 2 : return otherbank

   if player0y > 54 then return otherbank

skip

 

82 bytes

 

   if player0y < 54 then skip 

 

   if player0x =  19 then gosub gsUp

   if player0x =  40 then gosub gsUp

   if player0x = 112 then gosub gsUp

   if player0x = 133 then gosub gsUp

 

   if player0y = 66 then _Bit0_P0_Floor = 2 : return otherbank

   if player0y > 54 then return otherbank

 

skip

 

 

gsUp

   goto  __Up bank6

 

77 bytes

 

  if player0y < 54 then skip

  temp1 = 4

loop

  if player0x = p0xUpdat[temp1] then gosub __Up bank6 : goto skip

  temp1 = temp1 - 1 ; if temp1 then loop

   if player0y = 66 then _Bit0_P0_Floor = 2 : return otherbank

   if player0y > 54 then return otherbank

skip

 

  const p0xUpdat = dat1 - 1

 

  data dat1

  19, 40, 112, 133

end

 

[bogax]

Oops

I goofed the loop

It will miss the player0y > 54 test

So I guess it should be something like this

 

 

  if player0y < 54 then skip

  temp1 = 4

loop

  if player0x = p0xUpdat[temp1] then gosub __Up bank6 : goto p0yGt54test

  temp1 = temp1 - 1 ; if temp1 then loop

 

  if player0y = 66 then _Bit0_P0_Floor = 2 : return otherbank

 

p0yGt54test

  if player0y > 54 then return otherbank

 

skip

 

  const p0xUpdat = dat1 - 1

 

  data dat1

  19, 40, 112, 133

end

 

[+Lewis2907]

Bogax,

 

Thanks. I will use this Monday.

[+Lewis2907]

I was able to use Bogax Code to save several bytes. Is there a way to save bytes in the code below and revamp the AI Code to work properly. I think it can be done in a table like what Bogax did, but the random numbers / pick a correct path may be a challenge.

 

 

;***************************************************************
;
; Sets player0 right side limits based off of playfiield
;
if player0x > 18 && player0x < 70 then gosub __Left_Right bank6
if player0x = 18 then gosub __Right bank6
if player0x = 70 then gosub __Left bank6

;***************************************************************
;
; Sets player0 left side limits based off of playfiield
;
if player0x > 82 && player0x < 134 then gosub __Left_Right bank6
if player0x = 82 then gosub __Right bank6
if player0x = 134 then gosub __Left bank6
return otherbank

 

 

 

 

__Ghost_Direction
;***************************************************************
;
; Select the correct floor based on player1y positions
; y position is in crements of
; player1y = 76 (1st floor)
; player1y = 64 (2nd floor)
; player1y = 54 (3rd floor)
; player1y = ** (4th floor)
; player1y = ** (5th floor)
; player1y = 16 (6th floor)
; left and right limits for "X" are 28 / 141
;
;***************************************************************
;
; Allows player1 to move based off of Level 1
; (1 = Up) (2 = Down) (3 = Left) (4 = Right)
;
if Red_Ghost = 0 then _P1_L_R = _P1_L_R - .5
if player1x = 77 && player1y = 64 then gosub __Ghost_L
if player1x = 28 && player1y = 78 then Red_Ghost = (rand&3)+1 : gosub __Ghost_D_R ; Select 2, 4
if player1x = 28 && player1y = 64 then Red_Ghost = (rand&3)+1 : gosub __Ghost_U_D_R ; Select 1, 2, 4
if player1x = 28 && player1y = 16 then Red_Ghost = (rand&3)+1 : gosub __Ghost_U_R ; Select 1, 4
if player1x = 141 && player1y = 16 then Red_Ghost = (rand&3)+1 : gosub __Ghost_U_L ; Select 1, 3
if player1x = 141 && player1y = 78 then Red_Ghost = (rand&3)+1 : gosub __Ghost_D_L ; Select 2, 3

if player1y < 78 && player1y > 16 then gosub __All_U_D
if player1x > 28 && player0x < 141 then gosub __All_L_R
return

20180618- PacMan_Eat_N_Run_(Multisprite).txt

20180618_Multisprite_Pac_Man.bas.bin

[+Lewis2907]

Attached is a version with 9 levels / screens. Sometimes you will move to the next screen sometimes you won't. I am still trying to figure out a way to reduce the redundancy that Bogax had pointed out. If I can do that maybe I can increase this to 12 or 15 levels / screens. The level A or B will allow for use of the map or not make to make it harder. That should be in the next update and then duplicate the intro scene from the DPC+ version and work on the AI.

 

The AI is also another issue I am running into. I think with some tables or something and using "const" below is what I would like to use, but this will eat away the space I have left. I will continue to work with this and see what I can come up with. It maybe hard as my coding style is the 80's basic that I learned in school and what I am picking up on here in the forum. If you find glitches with the movements and screens please let me know so I can fix it. I am open to suggestions as well, thanks.

 

__Ghost_Direction
;***************************************************************
;
; Select the correct floor based on player1y positions
; y position is in crements of
; player1y = 76 (1st floor)
; player1y = 64 (2nd floor)
; player1y = 54 (3rd floor)
; player1y = ** (4th floor)
; player1y = ** (5th floor)
; player1y = 16 (6th floor)
; left and right limits for "X" are 28 / 141
;
;***************************************************************
;
; Allows player1 to move based off of Level 1
; (1 = Up) (2 = Down) (3 = Left) (4 = Right)
;
if Red_Ghost = 0 then _P1_L_R = _P1_L_R - .5
if player1x = 77 && player1y = 64 then gosub __Ghost_L
if player1x = 28 && player1y = 78 then Red_Ghost = (rand&3)+1 : gosub __Ghost_D_R ; Select 2, 4
if player1x = 28 && player1y = 64 then Red_Ghost = (rand&3)+1 : gosub __Ghost_U_D_R ; Select 1, 2, 4
if player1x = 28 && player1y = 16 then Red_Ghost = (rand&3)+1 : gosub __Ghost_U_R ; Select 1, 4
if player1x = 141 && player1y = 16 then Red_Ghost = (rand&3)+1 : gosub __Ghost_U_L ; Select 1, 3
if player1x = 141 && player1y = 78 then Red_Ghost = (rand&3)+1 : gosub __Ghost_D_L ; Select 2, 3

if player1y < 78 && player1y > 16 then gosub __All_U_D
if player1x > 28 && player0x < 141 then gosub __All_L_R
return

20180702 - PacMan_Eat_N_Run_(Multisprite).txt

20180702_Multisprite_Pac_Man.bas.bin

Edited July 3, 2018 by Lewis2907

[+Lewis2907]

.I did go and clean up the code to save space. I have another idea to save more space by reusing some of the Data Statements as they have the same number. I think it work, unless there is another way to save more space.

 

Is there a way to clean the up and save space. Also the issue I have so far is that the ghost will go back the same way it came. I'm trying to figure out a way to make it choose another direction and not go in reverse. Currently I am only using the top 2 rows / floors for testing. Once I get this work I can apply it to the rest of the rows / floors. Additionally I will need to figure out a way for player1-4 to share the same coordinates to save space and cycles. Any ideas or help is greatly appreciated, thanks.

 

__Ghost_Direction

;***************************************************************
;
; Select the correct floor based on player1y positions
; y position is in crements of 14
; player1y = 76 (1st floor)
; player1y = 64 (2nd floor)
; player1y = 52 (3rd floor)
; player1y = 40 (4th floor)
; player1y = 28 (5th floor)
; player1y = 16 (6th floor)
; left and right limits for "X" are 28 / 141
;
;***************************************************************
;
; Allows player1 to move based off of Level 1
; (1 = Up) (2 = Down) (3 = Right) (4 = Left)
;
if Red_Ghost_FL = 1 then gosub __GH_FL1_LV1
if Red_Ghost_FL = 2 then gosub __GH_FL1_LV2
if Red_Ghost_FL = 3 then gosub __GH_FL1_LV3
if Red_Ghost_FL = 4 then gosub __GH_FL1_LV4
if Red_Ghost_FL = 5 then gosub __GH_FL1_LV5
if Red_Ghost_FL = 6 then gosub __GH_FL1_LV6
gosub __Red_Movement
return otherbank

__GH_FL1_LV1
;***************************************************************
;
; Allows player0 to down up to a level 2
;
if player1y = 64 then Red_Ghost_FL = 2 : return otherbank
if player1y < 76 then return otherbank

if player1x = 69 || player1x = 101 then gosub __Red_D_L_R
if player1x = 28 then gosub __Red_D_R
if player1x = 141 then gosub __Red_D_L

return otherbank

__GH_FL1_LV2

;***************************************************************
;
; Allows player0 to move up to a level 1
;
if player0y = 76 || player1y > 64 then Red_Ghost_FL = 1 : return otherbank
if player1x = 69 || player1x = 101 then gosub __Red_U_L_R

if player1x = 28 then gosub __Red_U_R
if player1x = 141 then gosub __Red_U_L
if player1x = 77 then Red_Ghost = 4
if player1x = 92 then Red_Ghost = 3

return otherbank

__GH_FL1_LV3
return otherbank

__GH_FL1_LV4
return otherbank

__GH_FL1_LV5
return otherbank

__GH_FL1_LV6
return otherbank

;***************************************************************
;
; player1 calculations using rand
;
__Red_D_L_R
Red_Ghost = (rand&2) + 2 ; numbers 2 to 4
return otherbank

__Red_D_R
Red_Ghost = (rand&2) + 2 ; numbers 2 to 4
if Red_Ghost = 4 then Red_Ghost = 3
return otherbank

__Red_D_L
Red_Ghost = (rand&2) + 2 ; numbers 2 to 4
if Red_Ghost = 3 then Red_Ghost = 4
return otherbank

__Red_U_R
Red_Ghost = (rand&3) + 1 ; numbers 1 to 4
if Red_Ghost = 2 then Red_Ghost = 1
if Red_Ghost = 4 then Red_Ghost = 3
return otherbank

__Red_U_L
Red_Ghost = (rand&3) + 1 ; numbers 1 to 4
if Red_Ghost = 2 then Red_Ghost = 4
if Red_Ghost = 3 then Red_Ghost = 1
return otherbank

__Red_U_L_R
Red_Ghost = (rand&3) + 1 ; numbers 1 to 4
if Red_Ghost = 2 then Red_Ghost = 4
return otherbank

;***************************************************************
;
; Movement to have player1 continously move
;
__Red_Movement
if Red_Ghost = 1 then _P1_U_D = _P1_U_D + .5 ; go up
if Red_Ghost = 2 then _P1_U_D = _P1_U_D - .5 ; do down
if Red_Ghost = 3 then _P1_L_R = _P1_L_R + .5 ; go right
if Red_Ghost = 4 then _P1_L_R = _P1_L_R - .5 ; go left
return otherbank

20180706_Multisprite_Pac_Man.bas.bin

20180706 - PacMan_Eat_N_Run_(Multisprite).txt

[Clay B. Hammock]

Great game as it is, when you gave it 25 levels on page 2 of forum. Don't change colorful mazes.

 

I turn my controller direction against the walls, until it blinks. going back to blink, I go into the

next maze. If I didn't crash into a ghost, on some mazes, when I enter a maze would be nice.

Hidden level, that could possibly be ending Maze. There would have to be hints to find this maze.

 

Until you do anymore, it would be much more playable to just have a sound when he eats

bonus Items. I would love to play that download, Like I'm playing the one without sound for

bonus items. You already show the score and that's nice. It's like you said, some of the doors to

next maze could be visible would be nice, but not as necessary as sound for eating bonus items.

 

Just love colorful mazes on page two. Don't change that.

 

I don't think you have to change ghost movement. It's challenging enough. There's nothing

wrong with the front and backward movement, It's just fine and makes it different than other pacman

games. Well thanks for a good game so far

 

Best of wishes for your game - Clay Hammock - Retrolux

[+Lewis2907]

Thanks for the feedback. The main reason I stopped was because the AFB won't play the game. I may continue it now since my grandson can play it on a cell phone. Plus I wanted to take a break and learn more from the forum and the more experienced programmers. I still a novice. I plan to work on it and clean it up some as well.

[+Lewis2907]

I have started to redo this game using the Text the Karl G provided. So far no issues with text. My issue is the graphics for DPC. I'm not sure if it's an error with my computer or if i'm running the correct Batari with updates. I'm using Build_568. Any ideas would be helpful. Thanks

 

edit: It was my settings. Had to reinstall everything on my laptop after it crashed.

 

playfield:
...................................
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
X..............................X
X..............................X
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
X..............................X
X..............................X
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
X..............................X
X..............................X
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
X.............X..X.............X
X.............X..X.............X
XXXXXXXXXXXXXXX..XXXXXXXXXXXXXXXX
X..............................X
X..............................X
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
X..............................X
X..............................X
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
end

 

Basically I have to off center the above to make the below.

Edited March 10, 2019 by Lewis2907

[+Lewis2907]

Bb Team,

 

It's been a while since I was online and even worked on programs. I plan to revisit this game soon and maybe scale it down to have more memory to improve game play. Hopefully I will have time since I'm always deployed, but my time is coming up soon to retire as well then I can go back to making this one of my main hobbies. 

[Prizrak]

Looking forward to you picking this back up again. 

[+Lewis2907]

On 3/11/2021 at 7:20 PM, Prizrak said:

Looking forward to you picking this back up again. 

I started back about two weeks ago. Trying to port it over to multisprite. I'm making progress. Hopefully it can get something working in a few weeks. 

[Materion]

I'm crossing my fingers for this project. Keep up and don't give up . I'm sure You will handle this .

 

[+Lewis2907]

Bb Team,

 

I think my eyes are tired. So I went back to the basics on a lot of this program and I have some variations. For some reason when I start the program to move my ghosts disappear. I'm not sure why. Otherwise I'm using exact coordinates to simulate pfread for Multisprite. Probably could be better. I think it was Bogax who gave me a code using temp and data as a solution, but after a while the program got kind of large. I'm still playing with that code as well. 

 

For now can someone figure out why the ghost disappear. I'm thinking too many gosubs or something easy that I'm overlooking, thanks. 

20210323_Multisprite_Pac_Man.bas.bin 20210323 -Multisprite_Pac_Man.txt 20210323_Multisprite_Pac_Man.bas

[+Gemintronic]

I'd take out the fancy decimal point math   "   _P0_L_R = _P0_L_R + .2"

 

and using variables this way too:  "   dim _P0_L_R = player0x.a"

 

For me it's much more stable to use the modulus operator to do things every so many frames.

 

Here is some code that slows the character down by moving him every 4th frame using "counter&3"

 

main
 if switchreset then reboot
 counter = counter + 1

 if counter&3 > 0 then goto after_input

input
 if joy0left then  player4x = player4x - 1
 if joy0right then player4x = player4x + 1
 if joy0up then    player4y = player4y + 1
 if joy0down then  player4y = player4y - 1

after_input

 

This technique may not directly solve your problem.  Maybe it will.  But, the code will be easier to read using less complicated variables and math - leading to better tracking down where the ghosts get displaced.  Also realize bB programmers have no control over the flicker mitigation technique.  So, the ghosts may be told not to draw by the bB flicker mitigation routines.  I'd start their Y coordinates separate from eachother on screen.  In my experience virtual sprites need around three pixels worth of padding between them (i.e. 3 pixels below or above displayed part of sprite).