I have no problem with it. So here is the thought:
The main prerequisite is that any images you create with a program like NEWIMAGE or uploaded through LOADIMAGE will have the same resolution on the screen. When it works in this ratio 1 to 1 then we can try sadomasochistic games with different ratios. But to the point. I originally thought that storing all points of the body circuit into the fields and comparing them would not be such a big problem for speed. It fugues for a small resolution, even for static pictures like snowfall on the body, but for games it will not be the right one. So now I want to take each picture, I will find out which RGB32 color is not used (I already have this feature) and I will paint the background with this color. Then, during the game, using the MEM command, I want to check the body penetration through this color. That should be faster. If you look closely, and this is perhaps one of the ways, you can make the body circumference so that only every N - rd point is written (because fire or enemy picture is not only one pixel big, you then need not every one pixel use in array) This significantly reduces the field and increases the speed. It occurred to me if I would introduce this array do with the MEMNEW, if it would not be much faster than a common field created through DIM? I have to explore this. If it is in unemulted memory, it should be fast.
Collision detection, as I want to do it, as if you were putting two cut out pictures. If you venture at the same step in both, it should work. Another option is to modify the program so that it only reads outside boundaries and not internal ones.
In the program when it moves a picture, it has a size. I can expect a collision from the top or bottom, then I do not need to control collisions from the hips - I get smaller fields and higher speed. And so on. It's a lot of experiments and mistakes, but I'm working on it. Of course every suggestion how to do it better is very welcome.
This source code is not commented, because i think, that developers, that is something. That is big programmer, which look in it and know :-D Because this is one part from bigger program, is not commented. But in this source is it used and there it is commented:
https://www.qb64.org/forum/index.php?topic=261.msg1500#msg1500if you search how it works, goto lines 122, 131 for 256 colors and 147, 158 for 32 bit.
Maybe you ask - why coloring background? It is for use with SETALPHA, is unvisible so do not problems in use, image is loaded in memory, so then can be used for reading enemy coordinates for collision detection. Let say, picture conains body and eye. Eye use rgb255,255,255 but background also. if I leave it, the eye will take the program as a collision border. But for program and real cool detect i need borders, if i use none array, and reading image using MEM, that is 1D array, none pixel in picture can not use background color, because background color enable colision, other color disable collision - function return 1 = is collision.
