IntersectsPoint peculiarity

Discussion in 'Bug Reports' started by enonod, May 28, 2008.

  1. enonod

    enonod Well-Known Member Licensed User

    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.

    Can you do anything about this please Erel? I need it.

    [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: May 28, 2008
  2. agraham

    agraham Expert Licensed User

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

    enonod Well-Known Member Licensed User

    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?
  4. agraham

    agraham Expert Licensed User

    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.
  5. enonod

    enonod Well-Known Member Licensed User

    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.
  6. agraham

    agraham Expert Licensed User

    The code could be changed as the original author, Andy Beaulieo, has made the source code freely available as acknowledged by Erel here. We will have to see what Erel's take on the matter is as it is one of his official libraries.
  7. enonod

    enonod Well-Known Member Licensed User

    Thank you very much agraham.
  8. Erel

    Erel Administrator Staff Member Licensed User

    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.
  9. agraham

    agraham Expert Licensed User

    Agreed. Unusually I was not pedantic enough in describing them as squares :) !

    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: May 28, 2008
  10. enonod

    enonod Well-Known Member Licensed User

    Sorry to post before Erel has replied agraham, I must say I do agree regarding speed etc. and the difficulty of testing pixels of an arrowhead i.e. different x,y for each pixel (horrendous)

    Under the rectangular circumstance the one pixel line is rectangular and cannot be detected when travelling along its axis, so broken seems apt.
  11. Erel

    Erel Administrator Staff Member Licensed User

    From my previous experience you are probably correct.
    I will check it although the difference is not so significant.
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.
    Dismiss Notice