error doing image collision detection with _MemGet

[madscijr]

About my setup: Raspberry Pi 500
Operating System: Debian GNU/Linux 12 (bookworm)
Kernel: Linux 6.12.34+rpt-rpi-2712
Architecture: arm64
Window manager: X11

It's very cool that you have QB64PE running on a Pi - have you tried controlling relays or other electronic components from a QB64PE program? 
I don't expect QB64* would have any native commands for that, however you can call native API functions with it (at least in Windows you can).

Anyway, I'm developing for Windows using i7 CPU (11th gen) with 32 GB RAM running Windows 11 Pro 24H2.
So that explains the performance gap! 

Regarding the FPS measurement, here is how I implemented it.

That might come in handy later on - thanks for sharing.

Hmm, so _button doesn't work in Linux for the keyboard? I wonder if that's the case for Mac as well?

About the _BUTTON function that does not work with my X11 setup: I don’t know whether it also fails under Wayland or with any other Linux configuration.

I'm not a Linux user and am not familiar with Wayland, all I know is that _BUTTON has worked since at least QB64 1.4 (the version I started with) and is a core function for reading general input devices such as game controllers and keyboards. I'll defer to the developers on Linux compatability & configuration, but I use it for my Windows programs because it's responsive and handles multi-keypresses well, at least on my system. But if it doesn't work with Linux, or some Linux, systems, I might look into adding additional support for other keyboard methods like _KEYHIT.

They work for these vector shapes - even irregular shapes, in Herve's case - but how would you use these to detect collisions between the raster characters my program is using? Would each characters need to mapped to an equivalent vector shape?

Indeed, converting a bitmap image to a vector shape is not simple; what we care about is obtaining the shape’s contour. That should be achievable using simplified contour-detection and vectorization techniques. It’s probably a topic I’ll look into; my TODO list keeps growing!

Let's hear it for growing TODO lists! 

I found the code where I experimented with converting to vector - see attached. Search in the code for "Sub GetVectorTiles" for that, and "Sub GetTileText" to see the tile definitions. It analyzes a raster tileset to find the minimum rectangles to draw each character (using the Line command) and could be modified a little further to find the contour. Run the program to see it compare performance of different drawing methods (I haven't tried adding the custom font method yet, I'm curious how that would perform).

I don't see needing vector conversion for the smaller 8x8 or 16x16 shapes, it's the bigger shapes like 32x32 and 64x64 that would need that help. But even then, calculating the boundary overlap should result in a small area of pixels to test (unless the sprites are jumping a large distance, which you wouldn't want to do because the motion would look jerky).