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.
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:
!