Jump to content

Photo

Pac_Man Eat n Run


56 replies to this topic

#51 Random Terrain OFFLINE  

Random Terrain

    Visual batari Basic User

  • 28,450 posts
  • Controlled Randomness
    Replay Value
    Nonlinear
  • Location:North Carolina (USA)

Posted Wed Dec 20, 2017 3:44 PM

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



#52 Lewis2907 OFFLINE  

Lewis2907

    Chopper Commander

  • Topic Starter
  • 167 posts
  • Location:Senatobia, MS

Posted Wed Dec 20, 2017 3:58 PM

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/...ttach_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. 



#53 Lewis2907 OFFLINE  

Lewis2907

    Chopper Commander

  • Topic Starter
  • 167 posts
  • Location:Senatobia, MS

Posted Thu Dec 21, 2017 1:49 PM

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



#54 Lewis2907 OFFLINE  

Lewis2907

    Chopper Commander

  • Topic Starter
  • 167 posts
  • Location:Senatobia, MS

Posted Sun Dec 24, 2017 9:05 PM

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.

Attached Files


Edited by Lewis2907, Mon Dec 25, 2017 12:40 AM.


#55 Lewis2907 OFFLINE  

Lewis2907

    Chopper Commander

  • Topic Starter
  • 167 posts
  • Location:Senatobia, MS

Posted Tue Dec 26, 2017 1:12 PM

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. 

Attached Files



#56 Random Terrain OFFLINE  

Random Terrain

    Visual batari Basic User

  • 28,450 posts
  • Controlled Randomness
    Replay Value
    Nonlinear
  • Location:North Carolina (USA)

Posted Tue Dec 26, 2017 3:05 PM

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.



#57 Lewis2907 OFFLINE  

Lewis2907

    Chopper Commander

  • Topic Starter
  • 167 posts
  • Location:Senatobia, MS

Posted Tue Dec 26, 2017 8:23 PM

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 

Attached Files


Edited by Lewis2907, Tue Dec 26, 2017 8:26 PM.





0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users