Calculate 4 point collision...

[Thelen]

Hi all,

Before I spent a lot of minutes (or hours) of thinking about how to calculate a 4 point collision in assembly, I'm hoping maybe somebody has some sort of out-of-the box standard code to do the following (like in Basic or Python):

 

if (player_x+player_width)>enemy_x AND player_x<(enemy_x+enemy_width)

 

AND

 

if (player_y+player_height)>enemy_y and player_y<(enemy_y+enemy_height)

 

Then...

The x axis is from 0-319 pixels, so in assembly there is a low X byte end a High x byte ?

The y axis is just 0-192.
 

 

Thanks!!

 

 

[tebe]

https://github.com/tebe6502/Mad-Pascal/blob/master/samples/a8/graph/rect_overlap.pas

 

PtInRect , PtInEllipse

https://github.com/tebe6502/Mad-Pascal/blob/master/lib/types.pas

rect_overlap.obx

[Eagle]

 

[Thelen]

Thanks both, I will check it out!

 

[shanti77]

By the way, the second "clc" in the above code is unnecessary because there is a "bcs" command earlier and the "c" tag must be 0.

[Thelen]

Thanks. How would I add the X axis high byte to the example as shown in the Youtube by Eagle?

[phaeron]

It'd be tricky. The code essentially computes -s2 < x1 - x2 < s1, and the analogous check on the Y axis. The trick is that biasing the values by s2-1 gives -1 < x1-x2+s2-1 < s1+s2-1 in signed arithmetic, which can then be converted to x1-x2+s2-1 < s1+s2-1 in unsigned arithmetic. It's more annoying to do this in 16-bit due to the 6502's weakness at it and needing to compute A+B-C on one side.

 

However, the implementation is as short as it is because it assumes that both object sizes are constants. Otherwise, both sides of the comparison would need to be computed. If you can assume that, then you can also check -s2 < x1 - x2 or x1 - x2 < s1 directly, based on the sign of the x1 - x2 difference (in the carry flag). Which should be something like SEC/LDA/SBC/TAX/LDA/SBC for the subtraction, then BCC/BCS to choose the side to check, then CPX+SBC+BCC/BCS for each branch.

 

If it's also the case that you have a lot of asymmetric checks -- one player vs. many objects -- then you can also precompute u1=x1+s2-1, and then only check u1-x2 < s1+s2-1.

 

[Thelen]

17 hours ago, phaeron said:

It'd be tricky.

 

Thanks for the extended explanation ? Hmmm, this is somehow getting to difficult to oversee (for me )

[Ecernosoft]

On 7/21/2022 at 12:53 PM, Thelen said:

Thanks for the extended explanation ? Hmmm, this is somehow getting to difficult to oversee (for me )

And me.... 

I want to use this code in ICT3 7800 so I can have not terrible collison!

[Rybags]

<deleted> - someone already posted.

Edited November 26, 2022 by Rybags

[Zolaerla]

If you want to make this easier, my recommendation to make this only an 8-bit operation would be to just use half the X coordinate in the comparisons for both sides. This depends if being off by a pixel matters much to you, but assuming none of the actors in the game are more than 64px in side (so 192+64 overflows 8-bit), then it'd greatly speed things up. If you're storing a 16-bit X, you'd have to adjust each by something like copying the 16-bit value then using LSR/ROR to divide by 2:
LDA PlayerX + 1
LSR A ; We don't care about A anymore since this just sets carry
LDA PlayerX
ROR A
STA PlayerX8Bit