error doing image collision detection with _MemGet

[Herve]

Yes, my prog first checks for boundary overlap, then if those intersect, it compared the bitmask arrays of the overlapping areas for overlapping pixels, comparing 2 precalculated 2D boolean (_BYTE) arrays. It's fast enough on my PC but @Herve was citing some low FPS performance testing on their machine (not sure what hardware Herve is running or how they're measuring FPS, plus they're on Linux & I'm on Windows. How fast or slow is my prog on your computer?)

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

Regarding the FPS measurement, here is how I implemented it.
For information, this does not take into account the midnight correction mentioned in the TIMER(function) documentation.

before the main loop

Code: (Select All)

t = timer(.001)
fps% = 0
frames% = 0

in the main loop

Code: (Select All)

frames% = frames% + 1
if timer(.001) >= t + 1 then
fps% = frames%
frames% = 0
t = timer(.001)
end if

color &HFFFFFFFF, &H00000000
_printstring (1,1), "fps:" + right("000"+_tostr$(fps%), 3)

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.

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!

And thanks to Steve about _ORELSE and _ANDALSO which I missed. I’ll update my code right away to improve performance a bit more.

[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).

[bplus]

@madscijr

inquiring minds gots to know,

did reply #41: https://qb64phoenix.com/forum/showthread...9#pid36229

help your understanding of my code any better or did i waste my time?

You are probably as eager to dig into my code as I am into yours. Your screen shots look good, like they are detecting pixel collisions.

I am thinking of rewriting spiders with way longer legs and demo-ing pixels collisions at exact points detected.

More of a challenge, get the whole collision shape mapped into an array or image. What do ya think?

[madscijr]

@bplus definitely not wasting time, I have your message pasted in my code right below my boundary test to compare the  logic, I'm also doing some refactoring & simplifying, when I have it working and digested your wisdom you'll be the first to know!    

[bplus]

@bplus definitely not wasting time, I have your message pasted in my code right below my boundary test to compare the  logic, I'm also doing some refactoring & simplifying, when I have it working and digested your wisdom you'll be the first to know!    

Thanks to your encouragement I have been revisiting that code and found some curious problems, so maybe not so wise, maybe don't try to digest. I am trying to pinpoint the exact pixel that is output and sometimes its not on an intersecting part. I think its because the spiders are redrawn to make separate images, the bodies are in same place and orientation is same but the legs move on each call to drawing sub. So I have to make images of all the spiders first, saved to array then do the image collision test.

[bplus]

+1 to Steve for the _Andalso and also _Orelse advice

My updated Pixel Collision demo is here:
https://qb64phoenix.com/forum/showthread...3#pid36273