boxcoll - sprcoll.

[Lazarus]

Hello.

I'm working on a program with a two dimensional maze.
The background is a single image with blue lines marking out where the walls are.

Now I have the keyboard controlled sprite - another image.  
My problem is, I don't know how I would detect collisions between the sprite and the blue parts of the maze.  

Imagine this:

---------
|    o      |
|     ---   |
|---------|

| is walls of maze, -- in the middle is a wall, and o is the sprite.
How could I detect collision between o and --- when moving o?  

boxcoll is a weird command - what good is it to check for the collision of two rectangles?  rectangles of what?

sprcoll - why must I provide these four x and y values when I just want to check for collision between sprite one and sprite two?

[Kitty Hello]

Because a "Sprite" is just a shape. It has no position. You can draw it to some position, and that's about it. You can draw it again on another position.
For your maze, a boxcoll with all maze-parts would be good. You can also build the map as a DIM map

• [y], and then simply check where in that map the player is.

[Lazarus]

Hello.

I have another problem, unfortunately.  I have two sprites - one tall and thin, the other wide and thin.

------------------------  

|
|
|
|
|
|

Like so.  I'm using sprcoll to detect collisions between my moving sprite and these two.  But - it only detects collisions when the moving sprite touches the other two on the right or the left.  

In other words - if the moving sprite hits the -------------- sprite - it goes right through.  No collision is detected.  Collisions between the moving sprite and the other sprite are detected just fine.

I'll post the code if needed - any reason for this not being detected?

[Lazarus]

Nvm -  I figured out the problem.

[Lazarus]

Gernot, will sprcoll detect a collision if the sprite intersects with another sprite at a transparent position?

[Kitty Hello]

no. Transparent pixels are left out. Thats the advantage of sprcol

[Lazarus]

I wrote up a small example project here:

http://lazprogrammingfiles.googlepages.com/project4.zip

If you run it, you'll see that sprcoll detects a collision even if on a transparent pixel, due to sprcoll's internal use of boxcoll.

Can this be fixed somehow?  Otherwise I have to split up my sprites into many different pieces for collision to work properly.

[Kitty Hello]

Uh-oh! That was a bug. The images were upside down internally. :s I fixed it and will upload an update tonight. Sorry for that.

[Lazarus]

Great.  I look forward to the update.

[Lazarus]

If you use rotosprite to turn a sprite, sprcoll seems to use the original sprite for collision detection.

Also, could there be an option to turn on collision detection for the transparent parts of a sprite?  There are times where you want a part of it to be invisible but still solid.

Oh - and how accurate is sprcoll?

[Kitty Hello]

SPRCOLL is pixel accurate. It just compares the non-transparent pixels of 2 bitmaps. A sprite is not image plus position. A sprite is just an image. SPRITE just draws the image at x,y to the back buffer.
It's so much confusing everyone. I guess I'll better rename it to BLIT or something in a new version. *sigh*