Hi @_WeirdCat_,

yep, I should add some epsilon testing code, numerical noise is bad! For now, for your second comment, all my numbers are already within a range of 0-128 so there should be minimal accuracy issues there hopefully.

Attached is the use-case for the collisions

Note that before doing the line-segment interactions, I do a macroscopic bounding box test to avoid the calculations in the majority of cases. I might try to be a bit more detailed in the collision shapes (to reflect the non-pure rectangular nature of the tractor beams) but that can be later if it's necessary!

I know I already said this, but I just want to reiterate that you don't have to handle vertical lines as a special case. Looking over your function I can see that doing so adds a lot of code, which of course means additional opportunity for bugs or errant behavior. My own feeling is that especially with respect to functionality like intersection testing, the less code the better due to how easy it is to get details wrong.

Of course you may have what you need at this point and not want to change anything, but I just thought I'd mention it again (even if only for future readers of the thread who might be looking for information on this topic).

Looks good by the way

10 hours ago, Zakwayda said:

I know I already said this, but I just want to reiterate that you don't have to handle vertical lines as a special case. Looking over your function I can see that doing so adds a lot of code, which of course means additional opportunity for bugs or errant behavior. My own feeling is that especially with respect to functionality like intersection testing, the less code the better due to how easy it is to get details wrong.

Of course you may have what you need at this point and not want to change anything, but I just thought I'd mention it again (even if only for future readers of the thread who might be looking for information on this topic).

Yep - although given the amount of time that I've already spent on that particular function rather than actually doing anything more useful / interesting on the game, I'm inclined to leave it as it is for now. I need to do a similar sort of exercise for identifying the following collisions:

• line -> circle intersections (for weapons hitting semi-circular ground turrets - the other part of the circle is within a wall so I don't need to worry that much.
• moving circle - line intersections (for the ship hitting walls / game objects)
• moving circle - fixed circle intersection (for the ship hitting the aforementioned semi-circular ground turret)

Once I've done that, then I'll do a little blog post with a summary of the discussions.

In terms of the special casing for vertical lines, as I already separate out point interactions, then the easiest way would be to simply rotate everything through 90 degrees so that I never have to handle vertical lines ? The biggest complexity in the algorithm that I can see is the need to handle the 3 possibilities when parallel lines overlap (line 1 starts in line 2, and then would hit the start and/or end).

The real fun part would be to do a SIMD implementation of the code to get a speed up in the comparison code - although given the number of comparisons that I actually need to do, then that would be completely pointless! ? Fun, but pointless ?

10 hours ago, Zakwayda said:

Looks good by the way

Dzieki. The basic idea is that you have to fly around an alien world in your space ship, there are tractor beams (which can either be destroyed or disabled by turning off the electricity supply), gates, ground turrets etc. and you have to explore the maze. The 'pick ups' will be survivors from another ship which previously crashed. 

At some stage I should probably look to convert my games from PC/X1 to Android - would get a much larger market!