# IntersectsPoint peculiarity

#### enonod

##### Well-Known Member
I have re-posted here from questions because I 'believe' there to be something that needs looking into more deeply.

Two programs are attached...
1. shows a 5x5 sprite moving around a grid in a spiral, keeping between the grid lines.

2. shows a single (Y direction) pixel line moving around the grid as above.

I attach a diagram...
this shows the intersect points in Red that one would normally expect to use (with the knowledge from the help file only) to travel in a simple square keeping between the grid lines.
It also shows in Blue the actual minimum intersect points that must be used.

Observations from the array in the programs...
It is consistent in that the first turn requires X,Y+1, the second X,Y, the third X+1,Y and the fourth X+1,Y+1. Odd?

It follows from this that if a single pixel line is sent (in X direction) toward the first turn it should physically not touch at Y+1 or any other value of Y. This prevents it working. To test, use square program & change Line 18 second number 15 to a 1.

It may well be that a consistancy can be programmed for and in the spiral instance this is what I have done. However, in the case of the line, this is not so obvious (in advance). Further, it becomes almost impossible when the sprite is moving at angles other than multiples of 90 degrees.

The 'apparent' solution would be to have B4PPC test for the Reds i.e. the exact pixel overlap. That does give choices of numbers for most sprites but I believe the proper test is that it must work for any sprite (i.e. single pixel) crossing any point.
A single pixel cannot be sensibly tested as intersecting at X+1 or Y+1.
As you can see I have tested this extensively.

[EDIT] As an afterthought but not tested, I would think that unless very lucky, the same array data could not be used to reverse the path of the sprite (I don't have time to test) and so same data with the +1's in different places would be needed.

Last edited:

#### agraham

##### Expert
This is the hit test for a sprite Width and Height at X and Y for a point xp and yp
B4X:
``hit=((((xp>X) & (xp<(X+Width))) & (yp>Y)) & (yp< Height+Y)))``
And this is how I think it ought to be
B4X:
`` hit=((((xp>=X) & (xp<(X+Width))) & (yp>=Y)) & (yp< Height+Y)))``

#### enonod

##### Well-Known Member
I think that is what I have been saying in a long wided way, but which was needed in order to demonstrate with the program.

However, I haven't thought this through properly, but...
I think you are allowing a big sprite to test any of its pixels to cross anywhere in its path??? so what would happen if the sprite was like an arrow rather than a flat fronted one? I think this might have the same problem as my single line.
The height of the sprite is at its largest part.
Surely what is required is that a particular pixel in the sprite is tested against a particular pixel outside it. You may have done that, but as I say I haven't thought it through, I believe the expression is brain dead after all the work put in so far.

Please re-read the post, in the centre where I edited and watch the line sail by.
If your formula is accurate for all cases, is it likely to be implementable or is it an external engine?

#### agraham

##### Expert
What I posted above is what the present test actually is - I looked inside the code! The test presently assumes a square sprite. My amendment would make it work correctly - for a square sprite. Issues of whether assuming that sprites are not square is a matter for a separate discussion.

#### enonod

##### Well-Known Member
Yes it would work as you say for a square sprite (I still haven't thought through for a single pixel square sprite, perhaps you can say).

Do you know if this code could be changed or whether it is provided by another author?

This is not a theory exercise for me, my problem is that of trying to detect the single line sprite and I can't unless I pretend it is two pixels high when it isn't.

#### enonod

##### Well-Known Member
Thank you very much agraham.

#### Erel

Staff member
Sprites are treated as rectangles.
You must remember that the collision test is calculated for each sprite every tick.
Handling general non-squared shapes will be too slow.
You will need to implement your own collision test.

#### agraham

##### Expert
Sprites are treated as rectangles.
Agreed. Unusually I was not pedantic enough in describing them as squares !

Handling general non-squared shapes will be too slow. You will need to implement your own collision test.
Also agreed, I wouldn't have suggested that, but the existing rectangular collision test seems to be broken - or don't you agree?

Last edited: