123
-=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- (c) WidthPadding Industries 1987 0|113|0 -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=-
Socoder -> Blitz -> Non-Image Collisions

Tue, 28 Aug 2007, 09:11
mike_g
Do you mean when the point hits the line, or when the point passes one side of it?

For both you will probably be best off starting with a line drawing function. You can make one yourself fairly easily if you know the formula of a straight line.

Then you just check each pixel along the line to see if it overlaps any of the 'point's.
Tue, 28 Aug 2007, 09:25
JL235
I can't remember how exactly (I was doing this over a year ago) but you can find the formula to the line and then input the points co-ordinates to find out if it is on the line or not.

Why do you need to do this?
Tue, 28 Aug 2007, 10:26
mike_g
You could have a 2d array that for the screen that will hold a 1 or 0 dependant on if that point is on a line or not, then for each 'point' you and 1 with the co-ords on the array to see if its a hit or not.

It would take a bit of time to draw the array each loop, but the collision detection would be way faster as you only need to check each 'point' once as opposed to checking each 'point' against each pixel of each line.

This could be made better in a language (like C++ or something) where you could use a 1 byte int, instead of Blitz where all integers are 4 Bytes.

to make it even faster you could build the array 1/4 of the screen size. EG: 640*480 resolution would have a 320*240 array. It would be a little innacurate, but probably unnoticable to whoever is watching it.

I hope this doesnt sound too confusing. If you want I could try make a little demo prog of what I mean.


Tue, 28 Aug 2007, 10:40
Jayenkai
For invisible munky I did the following..
1. Static 1 pixel image.. "CollisionCheck"
2. Copyrect the area directly around the point you're checking.. In this case a 32x32 area, x-15,y-15, "AreaCheck"
3. Check collision between CollisionCheck and AreaCheck.
So long as you have a black background (or use an imagebuffer for floors, then draw that onto the actual background), you can check the pixel against anything..

Unless you move too fast..
In which case, check between "WasHere X,Y" and "AmHere X,Y"


-=-=-
''Load, Next List!''
Tue, 28 Aug 2007, 12:03
shroom_monk
Depending on how you eventually plan to do this, just a word of caution (I hope this makes sense!)...
When you're doing physics simulations, objects tend to move in decimals, and at speeds not equal to 1 pixel per update. Therefore, the object may actually cross the line, but not be detected. That's something to be wary of.

-=-=-
A mushroom a day keeps the doctor away...

Keep It Simple, Shroom!
Tue, 28 Aug 2007, 12:29
JL235
Ok, my suggestion is to use a Linear Equation. First, this could probably be easier used in languages such as Haskell and Ruby where you can create anonymous functions. That means you could find the equation of your line and wrap all the calculations into it's own function just for that line. I also had several problems with Blitz, like can you check for infinity? I had to trick the Blitz compiler into allowing me to create my own infinity constant (although it's actually a global because you cannot use variables when setting constants). Just crazy.

Anywho, here it is. It uses some very basic maths, but it doesn't work very well on lines at an angle. I'm thinking it's a rounding error. Maybe if I could use doubles instead it'd have worked better, but this is the general idea I had.

If you want to look further at my solution I'd recommend you practice your maths skills with linear equations. It's pretty basic stuff so it should be pretty easy to learn through the internet.
Tue, 28 Aug 2007, 15:44
mike_g
Diablo: I'm a little skeptical about the effectiveness of your code. First off in you program it dosent seem to detect collisions correctly on the second line:


Also for each point it needs to run through all the lines checking each point against it for a collision. I still think would be much faster to check an array for each point only, or even use ReadPixel if the boundaries are actually drawn to the screen.
Tue, 28 Aug 2007, 15:54
JL235
That's why I said it didn't work with lines at angles. I'm sure the maths is right, I've got my A-level book next to me. Plus it might be better to put a range on the result, so if y is within 1 or 2 pixels it is a collision. I also think rounding errors are causing it to be off!
Tue, 28 Aug 2007, 16:07
mike_g
Yeah Blitz rounding errors suck. Badly. It would be so much better if you could use double precision floats.
Tue, 28 Aug 2007, 16:08
JL235
Yes bear in mind my code is more of an idea rather then a solution. A fast idea, but still only an idea.
Tue, 28 Aug 2007, 17:45
mike_g
Tikihead: Your VX and VY variables indicate that you plan on moving your points at angles. I hope you are aware that by doing this they will be able to seep through the boundaries via the diagonals.

Using a rough matrix like I suggested before, or checking a range like diablo said should fix this tho. But you wont have pixel-perfect collision detection.
Tue, 28 Aug 2007, 19:21
Jayenkai
Lay in bed with pen and paper.

Then tested it.

Wasn't perfect.

So played "Trial and Error" with it for a little while.



WOOOOOHOOOOOOOOO!!!!!
Now that's gonna come in handy!


Oh yeah, um..
1,2,3,4 to select a point..
Move point with mouse.

|edit| Slight bugfix! Feel free to stresstest |edit|

-=-=-
''Load, Next List!''
Wed, 05 Sep 2007, 16:14
Dabz
Could you check the rgb value of the pixels that form the line

e.g.



Or something similar?

Dabz


-=-=-
Intel Core i5 6400 2.7GHz, NVIDIA GeForce GTX 1070 (8GB), 8Gig DDR4 RAM, 256GB SSD, 1TB HDD, Windows 10 64bit
Wed, 05 Sep 2007, 16:23
Jayenkai
If you're checking a collision between 2 known lines, wouldn't you already know what color both those lines are?

-=-=-
''Load, Next List!''
Wed, 05 Sep 2007, 16:28
Dabz
Here is a better example (working)



Dabz


-=-=-
Intel Core i5 6400 2.7GHz, NVIDIA GeForce GTX 1070 (8GB), 8Gig DDR4 RAM, 256GB SSD, 1TB HDD, Windows 10 64bit
Wed, 05 Sep 2007, 16:40
mike_g
I was always of the impression that the lines were not drawn. Also you would also need to draw more than one line to make sure the pixels don't leak through the diagonals.
Wed, 05 Sep 2007, 23:48
Dabz

Also you would also need to draw more than one line to make sure the pixels don't leak through the diagonals


That is true, but the concept is there.

Dabz


-=-=-
Intel Core i5 6400 2.7GHz, NVIDIA GeForce GTX 1070 (8GB), 8Gig DDR4 RAM, 256GB SSD, 1TB HDD, Windows 10 64bit
Wed, 05 Sep 2007, 23:58
JL235
Another alternative, you could make the lines out of a string of points. Like a string of pearls. Going through each point in turn, you do a very approximate check if there is a point between the point your checking and the next point. If points are really close to each other then the check only has to be very approximate.

That's how I did the collision detection on Space Snake.

|edit| Although it should be noted I only check the head of the snake against the rest of the body. But I doubt it would be slow to check more points and Blitz would be faster at that sort of thing then Ruby. |edit|
Thu, 06 Sep 2007, 01:47
Jayenkai
My code works just fine!