Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

DarkBASIC Discussion / Sparky's Collision DLL Snippets

Author
Message
Brick Break
User Banned
Posted: 20th Jun 2009 00:19 Edited at: 28th Jun 2009 03:09
This thread is for code snippets using Sparky's DLL in DarkBASIC Classic only. The intention is to help newcomers to this plugin fully understand how to implement sliding collision and raycasting into their projects, myself included. Sparky's DLL can be found here:
http://forum.thegamecreators.com/?m=forum_view&b=5&t=31051&p=0

If you have ever used Sparky's, or have found a snippet or function somewhere that might help, please post it here. I will be sure to update the main post to include any working code snippets you provide.

Snippets:

Latch's raycasting demo:


My sliding collision function:


Permanoobs are awesome.
Brick Break
User Banned
Posted: 21st Jun 2009 03:20
Sorry to bump this thread, but this is an act of desperation. In truth, I started this thread in hopes of some help developing my game engine, but I'm fairly new to Sparky's and I need some help.

Latch
17
Years of Service
User Offline
Joined: 23rd Jul 2006
Location:
Posted: 21st Jun 2009 09:08
Take a look at

Terrain tilt

It talks about figuring out ground height and tilt using collision. It uses both DBC collision and Sparky's Collision DLL. If you look at the code examples that use Sparky's DLL, you should get a basic idea how to use it.

The quick and dirty is:

1. INCLUDE the collision library at the beginning of your program
2. Create or load your object
3. Setup you object for collision using 1 of two Spraky's functions (detailed in the collision library DBA)
4. Run your program and if the object changes rotation or position call the Sparkys update function
5. Call Sparkys IntersectObjecct function to determine if collision has occurred. The collision works by casting an imaginary line from a 3d start point to a 3d end point. If the line passes through an object setup for collision then it will return a TRUE or the Object Number (I think) depending on the settings.
6. Use the GetStaticCollisionX y and z (i don't have the functions in front of me so you'll have to look them up) to return the point of collision
7. repeat the process from step 4

Enjoy your day.
Brick Break
User Banned
Posted: 22nd Jun 2009 04:41
Thanks, Latch! I at first didn't realize you wrote that thread yourself, nice! The idea of feeler objects made me a little queasy, though. It sounds kind of hacked up, while there's a perfectly good DLL to use, which I'm very glad you explained.
Anyways, after reading your post and debugging my test game a little, I found the problem lies in my lack of understanding of IntersectObjectDBC(). Here's what I have for that:

Think you can help?

Latch
17
Years of Service
User Offline
Joined: 23rd Jul 2006
Location:
Posted: 22nd Jun 2009 06:01
Sparky's collision for DBC is based on projecting a ray from a start point to an end point and checking for when the ray intersects a plane (when the ray passes through a mesh). Every iteration, whenever you reposition, scale, or rotate your objects, the objects are made into a mesh, loaded into a memblock, a pointer from the memblock is sent to the dll, and the intersection calculation is performed.

So the important things are that:
1. you are calling the update function from sparky's library regularly whenever your objects are changing position/rotation
2. you are using an approriate collision method = sphere/box/poly
3. you have groups and individual items set up properly for detection
4. And you are casting the ray from the right place to the right place.

For number 4
The following example shows a ray using sparkys dll being cast from inside a cube. The goal of the example is to detect collision with the cube. The spheres are only there to show you the start and end points of the ray I'll cast using sparkys DLL. If you move the arrow keys, left or right, you will change the start position and length of the ray. Whether there is collision or not will be displayed. If your game has objects that would end up in between where this ray is cast or if one object is made of two object on top of or next to each other and the ray passes through one of them, the collision detection will flag positive.

Note that the ray originating from inside the cube WILL NOT return collision. This is because I am trying to detect collision with the cube itself. It starts to get a little complicated here, but the reason is the cube's normals, imaginary perpedicular lines that point away from the faces of the cube, point outward. If the cube was "inside out" the normals would point inward and we could get a collision.

If you move the sphere outside of the cube and allow the ray to pass through it, then you will get collision detection.

I put the example together just so you can get a visual. Sometimes it helps just to see the process.



Enjoy your day.
Brick Break
User Banned
Posted: 22nd Jun 2009 06:16
What if I wanted the sphere to be involved? What if a ray were cast from the sphere in order to check if the polygons of the sphere were colliding with stuff? I know about normals and the imaginary line and everything, but I'm not sure how the actual moving player object is involved.

Latch
17
Years of Service
User Offline
Joined: 23rd Jul 2006
Location:
Posted: 22nd Jun 2009 09:49
Sparky's for DBC is not object to object collision detection. A ray is cast from one point to another. If the ray passes through an object setup for collision then detection will be flagged. It's just a line projected in a direction. If the line intersects a plane (face, polygon), then there is collision.

The collision type setup, is for the area around the object that the ray can collide with. A sphere doesn't collide with a cube or anything else.

The ray can come from anywhere. You may cast from an object position to see if the ray strikes anything in the direction you are casting it.

You can cast multiple rays using multiple occurances of intersectObjectDBC().

If you move an object, you have to adjust the ray's start and end positions if your intention is to use the object's position as a starting point for the cast ray.

In my example above, the ray's start position is changed as the "start sphere" is moved left or right.

Ray casting is great for bullets, or even ground height, or checking the distance from one point to a collision point. For object to object collision, it's not ideal. To try and mimick the behavior of object to object collision, you would have to cast multiple rays from different locations on the object in different directions. The simplest version being a plus sign where 4 rays are cast north south east and west so you could detect collision in any of those 4 directions but only where the rays collide with other polygons. But then you'd still have to worry about above and below the rays and the 90 degree gaps in between each ray. So you may cast more rays, or move the positions of the rays each iteration.

So you can't check if the polygons of the sphere are colliding with the polygons of something else. You can only detect if a ray being cast from one location to another is passing through the polygons of an object that was set up for collision.

If you wanted to check if the sphere was colliding with a ray, you'd have to set up the sphere for collision, then you'd have to cast a ray from somewhere other than the sphere's location and move the sphere into the ray's path.

Make any sense?

Enjoy your day.
Brick Break
User Banned
Posted: 23rd Jun 2009 00:36 Edited at: 23rd Jun 2009 00:37
Yeah, it does make sense, and I don't like it one bit. First of all, my code can't seem to detect the intersection of the ray through any objects at all. Secondly, how would I use spherecasting? I know there isn't a command for it in V1, but how might I implement something like that? If you look at SoulHunter, it's all sphere-to-polygon collision in DBC.

EDIT: Why can't I use cool commands like in this example?

Brick Break
User Banned
Posted: 23rd Jun 2009 01:31
Latch
17
Years of Service
User Offline
Joined: 23rd Jul 2006
Location:
Posted: 23rd Jun 2009 01:55
Post a complete code example where you are trying to move an object and test it for collision with another object.

And there is no sphere casting in the DBC version of Sparky's DLL.

I'm sure the DBPro version can be adapted but I've never taken the time to look at it.

And can you accomplish your goals using the DBC built in collision?

Enjoy your day.
Brick Break
User Banned
Posted: 23rd Jun 2009 04:09
Quote: "Post a complete code example where you are trying to move an object and test it for collision with another object."

I'll work on putting my measly little collision test game into one file- expect it shortly.
Quote: "And there is no sphere casting in the DBC version of Sparky's DLL."

I know. Could a function be made?
Quote: "I'm sure the DBPro version can be adapted but I've never taken the time to look at it."

Could you? That would be awesome! You would become an instant celebrity!
Quote: "And can you accomplish your goals using the DBC built in collision?"

Fast sliding polygonal collision? No. I want to be able to load in objects as levels, bsp-style.

Brick Break
User Banned
Posted: 23rd Jun 2009 04:23 Edited at: 23rd Jun 2009 21:05
OK, here is my complete code example. Put it in the folder with Sparky's and watch it not work.

EDIT: Code updated to meet standards.

Brick Break
User Banned
Posted: 23rd Jun 2009 06:29
Bump: Latch? Help? Please?

Latch
17
Years of Service
User Offline
Joined: 23rd Jul 2006
Location:
Posted: 23rd Jun 2009 06:36
Try not to double post, let alone triple post. People will respond to your post when they can or are willing to. Have patience and respect others' time. I'll look at the code when I get a chance, and if someone else can help I'm sure they will post as well.

Enjoy your day.
Brick Break
User Banned
Posted: 23rd Jun 2009 07:04
Lol sorry for triple posting, but I didn't need the lecture. It's very kind of you to help, Latch. I hope there is something I can help you with in return. BTW I'll add your snippet to the top post. I really hope you "get a chance" soon.

Latch
17
Years of Service
User Offline
Joined: 23rd Jul 2006
Location:
Posted: 23rd Jun 2009 10:20
Quote: "Quote: "I'm sure the DBPro version can be adapted but I've never taken the time to look at it."
Could you? That would be awesome! You would become an instant celebrity!"

It's not really on my to do list. Sorry.

Anyway, here is another demo. It's fairly well commented so you can see what is going on and how things are setup. Move forward and backward with the W and S keys and steer with the mouse. I project a ray far ahead of a sphere and draw it with a 2d line so you can see the ray as the sphere is moving around. If the ray intersects a cube it will tell you the object number of the cube. You'll have to save the code in the same folder where the dll and the DBCcollisions.dba library live.




I wrote a demo because I had trouble figuring out your code. Try and structure your code so there's a little less run on: include indentation, spacing, grouping of like code blocks, remarks/comments . Stuff like that. There's many code structuring tutorials on the forums and on the net. Mkes things a little easier to get through and find errors.

Enjoy your day.
Brick Break
User Banned
Posted: 23rd Jun 2009 21:04
OK Latch, thanks for the snippet, but it was pretty much the same as the other one (no offense).
Quote: "Try and structure your code so there's a little less run on: include indentation, spacing, grouping of like code blocks, remarks/comments."

Done. Check the code snippet in my earlier post (I edited it). Think you can figure it out now?

Latch
17
Years of Service
User Offline
Joined: 23rd Jul 2006
Location:
Posted: 24th Jun 2009 02:20
Quote: "OK Latch, thanks for the snippet, but it was pretty much the same as the other one (no offense)."

None taken. So I'm not sure what you are asking. Wasn't it collision detection with intesectObject?

Quote: "I found the problem lies in my lack of understanding of IntersectObjectDBC(). Here's what I have for that:
+ Code Snippet
col=intersectObjectDBC(0,1,x#,y#,z#,object position x(1),object position y(1),object position z(1),1)
Think you can help?"


Or are you asking for a complete sliding collision routine using Sparky's? Here's a complete interior sliding collision example that should get you on the right track:

X-Level

Enjoy your day.
Brick Break
User Banned
Posted: 24th Jun 2009 03:41
Quote: "Here's a complete interior sliding collision example that should get you on the right track"

Well, it didn't. The code doesn't work correctly, is overly complicated, and is very inefficient and inaccurate. Furthermore, it's not sliding collision because you can't slide along the walls. Honestly, I couldn't make sense of half of the code, not that it worked right anyways. Oh, if only I could achieve Bytegrove's level of greatness...

Latch
17
Years of Service
User Offline
Joined: 23rd Jul 2006
Location:
Posted: 24th Jun 2009 05:07
What happened? Those are all different files... I don't get it. Those aren't the files from the original. I thought the link was the old one I had archived...

If you can find the original link in the code base, it has two different examples with sliding collision.

All sliding collision is at it's simplest, a measurement from your current position to a a distance in the +x -x +z and -z directions. If you took the code I showed you with the ray casting and pointed the ray around the main player, if the ray collides, get the static x y and z position and move your player away from the collision in the opposite direction. So if you cast a ray to the right or left (in the x direction) and it hit something, you reposition the object to it's old x. If you cast it to the front or back (the z axis) you reposition the object to it's last z. That way you are always moving in either the x or z direction so you appear to slide along the wall.

Hopefully you can find the old post in the codebase, sorry my descriptions don't help.

Enjoy your day.
Brick Break
User Banned
Posted: 24th Jun 2009 06:44
Sorry Latch, I looked through the codebase and the only sliding collision demos using Sparky's DLL are in DBPro. What now?

Latch
17
Years of Service
User Offline
Joined: 23rd Jul 2006
Location:
Posted: 25th Jun 2009 11:10
I found a version of the old X-level (the link I thought I was giving you). It's a complete sliding collision example using ray casting from Sparkys DLL. It basically spins a series of rays around the camera position and checks if any hit a wall or the ground. Go through the code in the two examples so you can get a better understanding of the method.

[attached]

Enjoy your day.

Attachments

Login to view attachments
Brick Break
User Banned
Posted: 25th Jun 2009 20:59
I didn't bother going through the code because of how severely the code was bugged. I might later. It's too bad there aren't any fully working sliding collision demos using Sparky's DLL. A spherecasting function would be nice.

Latch
17
Years of Service
User Offline
Joined: 23rd Jul 2006
Location:
Posted: 25th Jun 2009 21:56
Quote: "I didn't bother going through the code because of how severely the code was bugged. I might later. It's too bad there aren't any fully working sliding collision demos using Sparky's DLL"


Not quite sure what you are talking about. Those are fully functional demos that work. You could be the Sparkys sliding collision master if you take the time to take apart that code and fix what you think doesn't work. You'll become a hero for all those that follow!

I'm just not sure what you are after. What don't you understand about the process? I'll list the steps. Which step doesn't make sense?

1. Set up your object for collision.
2. Start you main loop
3. If an object that is set up for collision changes position scale or rotation, use the odate collision function for that object
4. Cast a ray or a series of rays from a start point to and end point or from a series of start points to a series of end points using the intersectobject command
5. If the intersectobject command returns a non-zero value, the current ray that you are casting has collided with an object that has been set up for collision. Depending on the return value, whether you are checking for specific objects or for any object, write code to determine how to behave after collision has been detected.
6. If the collision test was intended to be from a moving object, i.e. the rays were cast outward from the object's position then you have to write code to make the object behave how you want.
7. If the behavior is sliding collision, then you test multiple rays, 1 at a time, and reposition the object in the opposite direction to where the ray collided. For example, if the object was strafing to the right and you cast a ray in that direction, if there was collision detected, then you move the object back to where it came from in the opposite direction. If you do that on multiple axes, 1 at a time, then the object will slide in the direction that it is not being collided with.

Enjoy your day.
Brick Break
User Banned
Posted: 25th Jun 2009 22:23 Edited at: 25th Jun 2009 23:04
What I'm worried about is stuff like this:

Of course, I could just use 4 rays instead of 1, but then it gets really complicated. Right now, I'm just trying to get vertical collisions right, like on a matrix, but even that's hard.

EDIT: I finished the function for vertical sliding collision, so you can have platforms and ceilings and walk around on terrain, but still no walls.


Latch
17
Years of Service
User Offline
Joined: 23rd Jul 2006
Location:
Posted: 25th Jun 2009 23:44
So to pull it off, you need rays cast in many directions. And the rays shouldn't rotate, only the object. For example, the plus configuration I mentioned earlier:



The arrow is the direction the sphere is moving. The little lines around the sphere are the rays. The red square is the wall. The view is looking down. The sphere is colliding with the wall on the East but since there is no collision at the North side of the sphere so the sphere continues to move along in the nroth direction thus sliding along the east wall.

When the sphere reaches the corner, it rolls around the corner because the user is still trying to move it east. Once it's around the corner, if there is only an attempt to move it east, it will now slide along the south wall because the east ray is no longer hitting anything but the south ray is.

Enjoy your day.
Brick Break
User Banned
Posted: 26th Jun 2009 00:01
Don't you see the problem?


TheComet
16
Years of Service
User Offline
Joined: 18th Oct 2007
Location: I`m under ur bridge eating ur goatz.
Posted: 26th Jun 2009 00:26
You could send the rays in 8 directions...


Make the path of your enemies easier with Waypoint Pro!
Latch
17
Years of Service
User Offline
Joined: 23rd Jul 2006
Location:
Posted: 26th Jun 2009 00:31
Yup. That's one of the reasons ray casting isn't so great for object to object collision. This is where you have to get creative. You could add more rays. You could sweep the ray around in a circle like the demos. Decrease the angle for a finer sweep but also longer processing time. You could use the same 4 rays but change their angle:



Enjoy your day.
Brick Break
User Banned
Posted: 26th Jun 2009 01:10 Edited at: 27th Jun 2009 03:59
OK, you need to figure out how to use the DBPro version with DBC. Wait, now that I think about it... After eating some pie, I realized that as long as the angles in the level aren't too small, it wouldn't be a big issue. Initially you would clip the wall, but there would be no passing through anything because the rays emit from the origin like a 3D plus sign.

EDIT: But, because of culling, players might exploit this to see through walls.

Login to post a reply

Server time is: 2024-05-19 07:03:21
Your offset time is: 2024-05-19 07:03:21