I would like to discuss an old chestnut from Oct 2007 http://www.b4x.com/forum/bug-reports/2416-intersectspoint-peculiarity.html#post13197
The last post on the issue suggested that it would be looked at but that it was felt not to be of great significance. At that point I left Basic4PPC until the latest version was released. There has been no change.
In my view, once a programmer has to 'tweak' a number to make what should have been predictable work, there is a problem that is significant.
I hope that on this occasion my explanation is clearer and more understandable than my last attempt, where agraham seemed to agree that there was something in it.
I attach my 'proof'? in the form of a demo program, complete with a (png file) illustrative diagram and a text file which is a copy of the text below the line, for ease of reading in Notepad off line.
The purpose of the program is to detect the corner of the rectangular pixel (in the direction of travel) arriving at the corner pixel of a square in a grid. The sprite must travel 'between' the lines. One of the 4 works the other 3 that are different are not consistent.
I am not infallible obviously and welcome any suggestions as to where I may have gone wrong.
One might be tempted to suggest that I use the pixel one removed from the sprite corner both x & y, however...
The outcome of this suggests that certain sprites cannot use intersect because they will never be detected at all (not tested but derived from the proof) and they include, a single pixel and a single pixel high straight line of x pixels.
----------------------------------------------------------------
Intersect suggests overlap not simply touching. If a sprite pixel lands on another pixel it could be said to be overlapped and therefore intersecting.
It follows therefore that if the corner pixel of a rectangular sprite lands on a designated pixel, it has intersected.
The Intersect function of the game engine allows the user to select the surface pixel that the sprite will be tested against, but not the pixel in the sprite that will be used.
It follows therefore that any pixel in the sprite that lands on the designated pixel will suffice.
It further follows then, that any corner pixel (an obvious choice) should work.
However it does not!
The attached program illustrates this and the diagram provided as gridtest.png shows the nearest to the corner pixel that can be achieved.
My conclusion is that there is a flaw in the game engine which prevents predictable algorithms to be used to determine the intersect point and the user must 'adjust'the figures (which defeats the purpose of programming).
I believe that this is serious enough to be fixed or please tell me where I am wrong.
The Diagram:
The explanatory Gridtest.png can be viewed by double click which should start Windows picture viewer or set the folder view to Filmstrip.
The image represents the enlarged view of the 4 positions in the main program where the sprite intersects and thus changes direction.
The blue represents the leading edge pixels of the travelling sprite.
The white pixel represents the nearest pixel to the corners that will work as a detection of intersection of the sprite and the grid pixels.
The main program:
It seems after much study and changing of numbers that those in the Array on line 25 are the nearest that can be used, else the sprite does not get detected.
Those numbers are represented by the white pixels in the diagram.
The last post on the issue suggested that it would be looked at but that it was felt not to be of great significance. At that point I left Basic4PPC until the latest version was released. There has been no change.
In my view, once a programmer has to 'tweak' a number to make what should have been predictable work, there is a problem that is significant.
I hope that on this occasion my explanation is clearer and more understandable than my last attempt, where agraham seemed to agree that there was something in it.
I attach my 'proof'? in the form of a demo program, complete with a (png file) illustrative diagram and a text file which is a copy of the text below the line, for ease of reading in Notepad off line.
The purpose of the program is to detect the corner of the rectangular pixel (in the direction of travel) arriving at the corner pixel of a square in a grid. The sprite must travel 'between' the lines. One of the 4 works the other 3 that are different are not consistent.
I am not infallible obviously and welcome any suggestions as to where I may have gone wrong.
One might be tempted to suggest that I use the pixel one removed from the sprite corner both x & y, however...
The outcome of this suggests that certain sprites cannot use intersect because they will never be detected at all (not tested but derived from the proof) and they include, a single pixel and a single pixel high straight line of x pixels.
----------------------------------------------------------------
Intersect suggests overlap not simply touching. If a sprite pixel lands on another pixel it could be said to be overlapped and therefore intersecting.
It follows therefore that if the corner pixel of a rectangular sprite lands on a designated pixel, it has intersected.
The Intersect function of the game engine allows the user to select the surface pixel that the sprite will be tested against, but not the pixel in the sprite that will be used.
It follows therefore that any pixel in the sprite that lands on the designated pixel will suffice.
It further follows then, that any corner pixel (an obvious choice) should work.
However it does not!
The attached program illustrates this and the diagram provided as gridtest.png shows the nearest to the corner pixel that can be achieved.
My conclusion is that there is a flaw in the game engine which prevents predictable algorithms to be used to determine the intersect point and the user must 'adjust'the figures (which defeats the purpose of programming).
I believe that this is serious enough to be fixed or please tell me where I am wrong.
The Diagram:
The explanatory Gridtest.png can be viewed by double click which should start Windows picture viewer or set the folder view to Filmstrip.
The image represents the enlarged view of the 4 positions in the main program where the sprite intersects and thus changes direction.
The blue represents the leading edge pixels of the travelling sprite.
The white pixel represents the nearest pixel to the corners that will work as a detection of intersection of the sprite and the grid pixels.
The main program:
It seems after much study and changing of numbers that those in the Array on line 25 are the nearest that can be used, else the sprite does not get detected.
Those numbers are represented by the white pixels in the diagram.
