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?
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.
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?
Nvm - I figured out the problem.
Gernot, will sprcoll detect a collision if the sprite intersects with another sprite at a transparent position?
no. Transparent pixels are left out. Thats the advantage of sprcol
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.
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.
Great. :) I look forward to the update.
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?
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*