I need input on a possible bug in v3.5.0

[bplus]

starRed and starBlue collision demo:

Code: (Select All)

SCREEN _NEWIMAGE(1280, 720, 32)
DIM AS _UNSIGNED LONG target
DIM SHARED Backdrop AS LONG: Backdrop = _COPYIMAGE(0)
blueStar = _LOADIMAGE("Z:\starBlue.png", 32)
redStar = _LOADIMAGE("z:\starRed.png", 32)

bs = MBI(blueStar)
rs = MBI(redStar)



DO
    ClearScreens
    k = _KEYHIT
    SELECT CASE k
        CASE 18432: yPos = yPos - 1
        CASE 20480: yPos = yPos + 1
        CASE 19200: xPos = xPos - 1
        CASE 19712: xPos = xPos + 1
        CASE 32: xPos = 0: yPos = 0 'reset
        CASE 27: SYSTEM
    END SELECT
    PlaceImage 100, 100, bs, bs
    PlaceImage xPos, yPos, rs, rs
    IF checkCollision(x&, y&) THEN PRINT "COLLISON AT: "; x&, x&
    _LIMIT 60
    _DISPLAY
LOOP



SUB ClearScreens
    D = _DEST: CLS , 0: _DEST Backdrop: CLS , 0: _DEST D
END SUB


SUB PlaceImage (x AS LONG, y AS LONG, image AS LONG, imagebackdrop AS LONG)
    _PUTIMAGE (x, y), image, _DISPLAY
    _PUTIMAGE (x, y), imagebackdrop, Backdrop
END SUB

FUNCTION checkCollision (x AS LONG, y AS LONG) 'check for our target color
    STATIC m AS _MEM
    m = _MEMIMAGE(Backdrop)
    DIM AS _OFFSET o, l
    DIM AS _UNSIGNED LONG p
    o = m.OFFSET: l = m.OFFSET + m.SIZE
    FOR y = 0 TO _HEIGHT - 1
        FOR x = 0 TO _WIDTH - 1
            _MEMGET m, o, p
            IF p = &HC07F003F THEN
                checkCollision = -1
                EXIT FUNCTION
            END IF
            o = o + 4
        NEXT
    NEXT
END FUNCTION


FUNCTION MBI (image AS LONG) 'make backdrop image
    DIM temp AS LONG: temp = _COPYIMAGE(image)
    DIM m AS _MEM: m = _MEMIMAGE(temp)
    DIM AS _OFFSET o, l
    DIM AS _UNSIGNED LONG p
    o = m.OFFSET: l = m.OFFSET + m.SIZE
    DO UNTIL o >= l
        _MEMGET m, o, p
        SELECT CASE p
            CASE &HFFFF0000: _MEMPUT m, o, &H80FF0000 AS _UNSIGNED LONG
            CASE &HFF0000FF: _MEMPUT m, o, &H800000FF AS _UNSIGNED LONG
            CASE ELSE: _MEMPUT m, o, &H00000000 AS _UNSIGNED LONG
        END SELECT
        o = o + 4
    LOOP
    MBI = temp
END FUNCTION

I tweaked your stars to get rid of the black backgrounds.  See how the above works for you. 

Man that appears to be much better, I will check it out with a couple other images too.

Man you guys are fast, I was just gone a few minutes!

[TempodiBasic]

@TempodiBasic My solution was simple -- I just filtered out anything that wasn't read or blue and turned them all transparent 0. 

IMHO simple and strong!

[SMcNeill]

@Steve SMcNeill
hi boy
very good your MOD  
1 you set one color for background of images
2 you use keyboard to move image, so it is possible to evaluate with more precision the sensibility of detection of collision
3 you speed up the operations of working and comparing the area of graphic images using _MEM functions

one neo
I must cancel  "Z:\" from the path of images to be loaded  :-P

Aye.  Sorry. Z: is my ram drive on all my PCs, so it's where I tend to put temporary things that I don't mind disappearing after a reboot, such as samples and images and all taken from the forums and discord and such.  Just change that to the path where your images are, and you should be good to go.  

[bplus]

Can we do this for multicolor images colliding with multicolor images?

Maybe an outline of one shape outline collides with the outline of the other object shape.

Did 2 Asteroids ever collide with each other in that game?

[Kernelpanic]

@TempodiBasic My solution was simple -- I just filtered out anything that wasn't read or blue and turned them all transparent 0. 

Well, it looks good! 

[Jack]

@bplus
here's an interesting video on convolutions and how it can be applied to graphics https://youtu.be/KuXjwB4LzSA?t=513

[SMcNeill]

Can we do this for multicolor images colliding with multicolor images?

Maybe an outline of one shape outline collides with the outline of the other object shape.

Did 2 Asteroids ever collide with each other in that game?

That's usually how I mask all my collisions, when I'm using color collisions like these.  If you notice, I'm actually working and detecting color collision on a backdrop screen, rather than the visible display.  So, let's say I had a red, white, and blue starship, and a green, yellow, and purple enemy ship.  Those would be the images that display on the user's screen, but for my backdrop, I'd have a simple set of faded alpha blue (hero) pixels and faded alpha red (enemy) pixels, which I could then quickly check for blending in the backdrop using mem comparisons.  If necessary, I could assign a palette of various colors for different things (faded green for health, faded yellow for power-ups, ect), but all I'd have to do is check for those blended values (blue for hero + green for health = collision with a health object), to know how to interpret them. 

[TempodiBasic]

@Bplus

It does look like you want x and y radius of object to minimize scanning though pixels. And isolating an object in an image is interesting problem in itself.

This issue let me remember the solution of progressive decreasing hitbox used in some game engine.
Here an example using the red star



As we can observer, there are many squares each of one different color. They are the visual view of a hitbox.
there are 5 special hitboxes that are very close to the edge of image and their color is purple.
In the code we test if the other object is in the first hitbox (yellow in this image) if so, we scan for collision in the areas delimited by purple hitboxes and with the X and Y range between the triggered hitbox and the following hitbox (in this example between Y of yellow square and  Y of green square and using as X the range of X of the purple rectangle surrounding the upper and lower spike of the star), 
and mutatis mutandis we do the same operation on the X dimension: checking if the object to evaluate is between X of yellow square and X of green square we test pixel by pixel collision in the purple area of the right spike and of the left spike limiting to the area between yello square and green square of the 2 (right and left) purple squares. 
If no collision detected the code goes on to evaluate the area between green square and blue square. If again no detection the code goes on to evaluate the area between blue square and orange square and so on until the last square, whose color is light gray in the example. In this square the collision is sure.)
That is an idea to decrease the number of pixels to test.

PS:
moreover if we must reduce drastically the number of tests pixel by pixel , it is very important to use the direction of the movement, that is another tecnique, that joined to this of decreasing hitboxes , powers up the tool of collision detection.

[TempodiBasic]

Can we do this for multicolor images colliding with multicolor images?

Maybe an outline of one shape outline collides with the outline of the other object shape.

Did 2 Asteroids ever collide with each other in that game?

That's usually how I mask all my collisions, when I'm using color collisions like these.  If you notice, I'm actually working and detecting color collision on a backdrop screen, rather than the visible display.  So, let's say I had a red, white, and blue starship, and a green, yellow, and purple enemy ship.  Those would be the images that display on the user's screen, but for my backdrop, I'd have a simple set of faded alpha blue (hero) pixels and faded alpha red (enemy) pixels, which I could then quickly check for blending in the backdrop using mem comparisons.  If necessary, I could assign a palette of various colors for different things (faded green for health, faded yellow for power-ups, ect), but all I'd have to do is check for those blended values (blue for hero + green for health = collision with a health object), to know how to interpret them. 

very interesting the faded Color Collision!  The alpha channel gives many gift to the BASIC coders!

[SMcNeill]

Another solution here is to simply check the 8 points of the star for collisions.  Since they protrude out beyond the base by such a large degree, chances are that no matter what direction you're traveling in, they're going to be the first point for a collision.  Sure, there may be some oddish occurrences where an oddly shaped object would perfectly miss that point and hit the image anyway (such as a straight line from a laser beam), but those unique objects are going to fall outside the norm in most cases.  Unless you just absolutely need pixel perfect collision detection, protruding point collision may be much faster and easier to check for, and still hold true in most cases for you.