doing some tank-pong like logic for ball/missile. help!

[tschak909]

Am currently trying to work through some logic to do TANK-PONG like logic to a ball, for my Dodgeball game.

 

P0Velocity is arranged as thus: RLDU 0000 where the lower nibble is a delay in frames.

The rest should be pretty straightforward, (and the S variables are being persisted outside this routine), am trying to do something like this description;

 

 

; Immediately after a collision, it tries a vertical reflection,
; jiggering the result so that it won't be exactly vertical or
; exactly horizontal.
;
; If this is the next frame (MxPFcount=$01) that failed, so
; we reverse direction 180 degrees to turn it into a horizontal
; reflection.
;
; On MxPfcount=$02 we take no action, since the missile may need
; the cycle to re-emerge from a wall.
;
; On MxPFcount=$03 or higher, we retrieve the original heading and
; turn it 180 degrees, assuming a corner reflection.  And we keep
; applying this same bearing until it's out of the #*%@ wall.

[+SpiceWare]

Using RLDU means you're limited to just 8 directions, and a number of them are duplicates (if R and L are both 0 or both 1 then there's no left/right movement). Using 4 bits you can encode 16 directions instead of 8.

 

In Medieval Mayhem I use a single byte to denote speed and direction, SSSDDDDD. Direction value of 0 is up, 8 is right, etc:

     0
     ^	
     |
24<--+-->8
     |
     v
    16

To prevent the fireballs from getting stuck in a loop I would "add some english" by randomly adding (or perhaps that was subtracting) 1 from the D value during a bounce.

[tschak909]

After 15 different attempts, including the last one working on paper, and another subsequent failure, I am now burnt out of ideas. shit.

 

-Thom

[gauauu]

In Medieval Mayhem I use a single byte to denote speed and direction, SSSDDDDD. Direction value of 0 is up, 8 is right, etc:

 

 

To clarify: it counts clockwise around the directions? ie you then have 7 diagonal up-and-right values?

 

It seems like this nicely encodes direction, but requires more code to translate the direction byte into actual movement? (which is a reasonable tradeoff, just making sure I understand)

[+SpiceWare]

To clarify: it counts clockwise around the directions? ie you then have 7 diagonal up-and-right values?

Yep - there's 32 different directions the fireballs can travel, much better than the 4 diagonals in Warlords. Yes in Warlords you can release a horizontal or vertical shot, but it'll change to one of the 4 diagonals after it hits something.

 

It seems like this nicely encodes direction, but requires more code to translate the direction byte into actual movement? (which is a reasonable tradeoff, just making sure I understand)

No need to decode DirSpeed, it's used to index values in movement tables. The code is basically Y = Y + MoveTableY[DirSpeed] and X = X + MoveTableX[DirSpeed] for 16 bit values, or this in 6507 code:

MoveFireball:
  clc
  ldy FireballDirSpeed  ; the SSSDDDDD value
  lda FireballYPosLow
  adc MoveTableYlow,y
  sta FireballYPosLow
  lda FireballYPosHigh
  adc MoveTableYhigh,y
  sta FireballYPosHigh

  clc
  lda FireballXPosLow
  adc MoveTableXlow,y
  sta FireballXPosLow
  lda FireballXPosHigh
  adc MoveTableXhigh,y
  sta FireballXPosHigh

---

plus some additional checks for boundaries and adding english to bounces.

 

Due to the use of 16 bit values there's 4 tables with 256 bytes in each table, so 1K of data in a 32K game.