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.

Code Snippets / Sliding Collision Function, DBPro

Author
Message
the Last Programmer
19
Years of Service
User Offline
Joined: 14th Jul 2005
Location: Abilene, TX
Posted: 10th Sep 2005 19:12
Hey, I see a bunch of posts out there that have sliding collision with two .x files and so I thought I would make my own.

This function is called objectCollisionHandler(objectNum, mapNum, radius#, floor#, ceiling#). This function takes in these five arguments and automatically processes sliding collision data for an object against another .x object. THUS, you can have your character run around a map without him running through walls or floors.

Here is the function:



Now, I made it a function so everybody could adopt it in their video game. Now I'll explain how to use the function.

You first have an object, let's say a cube: make object cube 1, 100. Then you move that cube through 3-D space with this function:



Easy, right? Now you would apply gravity to your object (that is, if you want gravity in your game). So let's create another function that does that:



Are you still following? Now that we have moved our object in 3-D space we can now use the almighty objectCollisionHandler() function. What the function does is take an object and then checks the collision is has with the map (another .x object), then it repositions the object to produce sliding collision.

Here are the arguments you would pass to objectCollisionHandler():
objectNum : This is the number of the object you wish to have collision data applied to.
mapNum: This is the number of the object that is the map, this is used to test against the object's position.
radius#: This is the number that says how far away your object will be from the walls of the map.
floor#: This is the number that says how high your object will be from the ground.
ceiling#: This is the number that says how far away your object will be from the ceiling.

Now we need to re-position the camera to be in first person view. That is, in the same position of the object:



Now that we have moved our object, applied gravity to it, re-positioned it using objectCollisionHandler(), and have moved the camera to be in the same area of the object, we can now use sync to draw everything on the screen.

Here is the mainLoop() function that brings it all together:



As you can see, I have typed out each function twice, the first time with the arguments in them, then the second time as a remark that shows what each argument is.

I hope everyone is with me on this so far.

Now here is the entire source code:



It took me two days to create this code. The trick I use is the command: "INTERSECT OBJECT()" This shoots a vector out from any position TO any other position. Therefore I use it to detect any collision with an object to any other .x object (the map) and then re-position the object based on that vector data given to me by the command "INTERSECT OBJECT()"

Pretty cool, huh?

Now I don't have any attached media because I tried attaching some last time but it didn't work. So what you'll have to do is copy/paste my source code into your dbpro and use your own map. The map file is loaded in the mainLoop() function:

function mainLoop()
sync on : sync rate 30 : color backdrop 0 : autocam off
make object cube 1, 20
load object "colltest.x", 2

Right here, load object "colltest.x" is where you would type in whatever .x object you have to use as a map.

Alright everybody, thanks for your time in parsing through this post.

bye

help support me by clicking ads on my website:
www.lazyoaks.net
Turoid
21
Years of Service
User Offline
Joined: 1st Nov 2003
Location: The Netherlands
Posted: 13th Sep 2005 10:47
I haven't read your post completely, but i have to say that this is one of the best collision codes made entirely only with the darkbasic commands. I tested it with several level objects, great job!


changed my old name "jopie dopie" to my real name
Phaelax
DBPro Master
21
Years of Service
User Offline
Joined: 16th Apr 2003
Location: Metropia
Posted: 13th Sep 2005 10:56
You call intersect object 10 times, I can't image how you'd get any decent frame rates.


Deadly Night Assassins
Turoid
21
Years of Service
User Offline
Joined: 1st Nov 2003
Location: The Netherlands
Posted: 13th Sep 2005 11:10 Edited at: 13th Sep 2005 11:12
Look, I just made a simple map and i programmed a new cube with your collisoin code. I made it controllable with the mouse so i can move it around. And WOOOW the collision works also perfect!

Check the screen, you can see the cube walking up the slope.

Phaelax: hmm i don't have any problems with the framerate, i get about 650 - 700 fps.


changed my old name "jopie dopie" to my real name

Attachments

Login to view attachments
Kohaku
20
Years of Service
User Offline
Joined: 3rd May 2004
Location: The not very United Kingdom
Posted: 13th Sep 2005 13:29
It's quite good. I've added it to the AGE framework I'm working on as the old collision method was admitedly crap. The speed of this isn't fantastic for me, but hey, it works, so who's complaining.
Cheers for that the Last Programmer.


You are not alone.
Lost in Thought
20
Years of Service
User Offline
Joined: 4th Feb 2004
Location: U.S.A. : Douglas, Georgia
Posted: 13th Sep 2005 18:05
That is pretty cool and fast here. And even faster with Sparky's ray casting instead of DBP's intersect object. It is not preftect sliding collision (you can see the object moving through parts of complex levels from 3rd person mode) but should work very well for 1st person shooters and primitive based levels for 3rd person. Also the smaller the radius the more accurate it seems. I guess it is easier to pick up collisions when close to objects when casting 10 rays.

Phaelax
DBPro Master
21
Years of Service
User Offline
Joined: 16th Apr 2003
Location: Metropia
Posted: 13th Sep 2005 22:18
Quote: "Phaelax: hmm i don't have any problems with the framerate, i get about 650 - 700 fps."


maybe 5.8 changed somethings. Cause I remember using intersect object on a level just once each loop would cut my frame rates drastically.


Deadly Night Assassins
Xenocythe
19
Years of Service
User Offline
Joined: 26th May 2005
Location: You Essay.
Posted: 13th Sep 2005 23:47
That's good and all, but you know what would be amazing? If you made one for DBC

That would really help everyone who struggles to try and have good collision for DBC, including myself.
RiiDii
19
Years of Service
User Offline
Joined: 20th Jan 2005
Location: Inatincan
Posted: 14th Sep 2005 04:08
Quote: "Cause I remember using intersect object on a level just once each loop would cut my frame rates drastically."


This may have been caused by a very complex .x level. The more polygons, the slower it takes intersect object to work. I've found one solution to this is to use DBPro's built in box collision to simply check if the first object is even close enough to another object to even bother checking with collision. Then slice and dice your terrain up into several smaller pieces and check for collisions only with the terrain object(s) that the player object is close enough to possibly collide with.

My pinball game in the 20 line codign challenge uses quite a lot of intersect objects (and a method very similar to the one posted here) and runs quite fast.


Open MMORPG: It's your game!
Phaelax
DBPro Master
21
Years of Service
User Offline
Joined: 16th Apr 2003
Location: Metropia
Posted: 14th Sep 2005 07:23
so you're saying I wrote my own intersect object routine for nothing?


Deadly Night Assassins
Vues3d on Kalimee
20
Years of Service
User Offline
Joined: 12th May 2004
Location: NYON (SWITZERLAND)
Posted: 15th Sep 2005 15:16
Hi there!!
Would just like to say that i've tryied your collision routine & was working really good to me. I had a faster framerate so, I was thinking about to adopt your functions but...
I tryied to change some commands for the camera movements & I get a bad result. I explain...

in your example, you use the arrow keys to move & in my game, I use the mouse as below:

Mouse 1+2(toghether) to move
Mouse 2 to rotate camera up-down-left-right.

I passed around 1 hour to change parameters in the moverment routine & had no luck & I was really disappointed!
If a day you have the time, could you check 6 tell me if it's possible to use your functions with mouse commands???

THANX!!!!!!

the Last Programmer
19
Years of Service
User Offline
Joined: 14th Jul 2005
Location: Abilene, TX
Posted: 15th Sep 2005 20:56
Hi everybody, thanks for the positive feedback.

Phaelax>>> I don't have dbpro 5.8 and I get hellagood frame rates. The manual for dbpro says that intersect object() is used for "extremely fast bullet calculations", so that's why I chose to use it in my routine. If the frame rate isn't working for you then post an example and I'll test it out. If it works fine for me then it must be your computer. Thanks for telling me about possible slowdowns, however.

Kalimee>>> I'm not sure what to tell you. My function, objectCollisionHandler(), only works with an object, not the camera. So if you're changing parameters for the camera, the function won't care. What I did was create a cube and move the cube using my functions. Then I position the camera in the same spot as the object. I hope that explanation works for you.

ALSO, I'm going to post a revised function later today that takes in the camera, instead of an object, as the argument. Therefore, y'all can move the camera around and perform the function for sliding collision.

ALSO, I'm going to revise both functions so that there are only 5 object intersects, instead of ten. This would be easy, considering how the whole thing works.

PLUS, I'll post some tutorials for those of you out there that want to know how it works.

bye

help support me by clicking ads on my website:
www.lazyoaks.net
headcrab 53
19
Years of Service
User Offline
Joined: 14th Jul 2005
Location:
Posted: 12th Oct 2005 02:55
It works great except for one problem. If the object moves further between each collision check than its diameter, it'll go through a wall. This wouldn't normally be a problem, but I have my game set up so that the lower the frame rate, the faster everything moves, so that the game will move at the same speed nomatter what the frame rate. (Down to 20 fps. Anything lower than that is unplayable anyway.) At 20 fps, you run at 30 units per frame while holding the sprint key, and the characters diameter is 18, making you run through any walls that are 12 units or thinner. Do you have a fix, or will I have to move the object no more than it's diameter every frame and preform the collision detection more than once?

If you can read this, you are over qualified.
Lost in Thought
20
Years of Service
User Offline
Joined: 4th Feb 2004
Location: U.S.A. : Douglas, Georgia
Posted: 12th Oct 2005 04:51
Quote: "It works great except for one problem. If the object moves further between each collision check than its diameter, it'll go through a wall."


Thats easy enough to fix. In all the intersect object commands where it says +radius# or -radius# add an offset for the extra movement distance.

Kohaku
20
Years of Service
User Offline
Joined: 3rd May 2004
Location: The not very United Kingdom
Posted: 12th Oct 2005 09:00 Edited at: 16th Oct 2005 06:21
You could split the number of calls to intersect object by using one for two exact opposite directions. A bit like this:



You are not alone.
headcrab 53
19
Years of Service
User Offline
Joined: 14th Jul 2005
Location:
Posted: 12th Oct 2005 22:50
Quote: "Thats easy enough to fix. In all the intersect object commands where it says +radius# or -radius# add an offset for the extra movement distance."


Wouldn't that make the character's collision wider, stopping you from going into smaller areas?

If you can read this, you are over qualified.
headcrab 53
19
Years of Service
User Offline
Joined: 14th Jul 2005
Location:
Posted: 15th Oct 2005 18:29
To solve the collision problem, I just divided everything into 2. The character moves half the distance, checks for collision, moves half the distance and checks for collision again.

If you can read this, you are over qualified.
headcrab 53
19
Years of Service
User Offline
Joined: 14th Jul 2005
Location:
Posted: 15th Oct 2005 22:37
I found another problem. I have bars on a jail cell set up like this:



The problem is that you can walk right between the bars. The collision diameter is 18 and the bars are only 8 apart. You can't walk through them if you look at the bar, but if you look inbetween them you can walk right through.

If you can read this, you are over qualified.
Lost in Thought
20
Years of Service
User Offline
Joined: 4th Feb 2004
Location: U.S.A. : Douglas, Georgia
Posted: 16th Oct 2005 01:00 Edited at: 16th Oct 2005 01:00
Quote: "The problem is that you can walk right between the bars. The collision diameter is 18 and the bars are only 8 apart. You can't walk through them if you look at the bar, but if you look inbetween them you can walk right through."


That is the problem with ray casting collision instead of true poly collision. You can place a hidden box in the same location as the bars yet covering them all and it should work.

FITZ
19
Years of Service
User Offline
Joined: 8th Apr 2005
Location: United Kingdom
Posted: 18th Oct 2005 05:19
Can this code be used for 3rd Person view, with camera collision aswell?

If not i'll have to try the new EDO.dll physic's and collision system!

(Resistance is futile!)
headcrab 53
19
Years of Service
User Offline
Joined: 14th Jul 2005
Location:
Posted: 22nd Oct 2005 01:11
Quote: "Can this code be used for 3rd Person view, with camera collision aswell?

If not i'll have to try the new EDO.dll physic's and collision system!
"


This is for objects only, but if you wanted to use it for the camera, make an invisible object for the camera collision and put the camera where the object is.

If you can read this, you are over qualified.
headcrab 53
19
Years of Service
User Offline
Joined: 14th Jul 2005
Location:
Posted: 22nd Oct 2005 01:14
Another problem. If you jump into the ceiling or walk into the bottom of a ramp, you end up on top. This is a problem, because if you jump into the ceiling you'll end up on top of the ceiling outside the level. How do I fix this?

If you can read this, you are over qualified.
Turoid
21
Years of Service
User Offline
Joined: 1st Nov 2003
Location: The Netherlands
Posted: 22nd Oct 2005 15:09
Quote: "If not i'll have to try the new EDO.dll physic's and collision system!"


Where can i find that collision system?

.::Studying game design at the moment::.
RiiDii
19
Years of Service
User Offline
Joined: 20th Jan 2005
Location: Inatincan
Posted: 25th Oct 2005 02:37
Quote: "If you jump into the ceiling or walk into the bottom of a ramp, you end up on top. This is a problem, because if you jump into the ceiling you'll end up on top of the ceiling outside the level. How do I fix this?"


One way I handle this is to have the collision system calculate the new location the object should be placed after a collision occurs. This location calculation returns the closest point to the object collided with in which all collision checks would return false. So, if the source object collides with a cornered target object, the source object will position itself in the corner (assuming that's where it hits). All calculations are from the center of the object, so if the source object "lands" on the target object, it rests on the target object. If the source object hits a ceiling, the source object is moved down.

The remaining problem now is when the center of the object moves beyond the edge of the target object, and the collision checks are now "behind" instead of in front. I controlled this two ways:
1) Split the source object movement up into 3 moves per frame. Not redrawing the scene, this can happen pretty fast for a single object. But in a game like an RTS where there are hundreds of objects, this would not be a good strategy. Then simply limit the maximum speed of the object to 3 times 1/2 the object's size; or 1.5*Object Size.
2) Use box collisions (very innaccurate, which is good here). If there is a collision detected using the built in box collision (and this can be scaled as needed), then simply move the source object backwards about half the move (the actual calculation will depend on object size and speed). Basically what you are trying to do is to move the source object back far enough so that the center of the source object is back "outside" the target object. Then apply the detailed sliding collision.

One other word of warning about using Intersect Object: It doesn't seem to work on culled or hidden objects/surfaces.


Open MMORPG: It's your game!
headcrab 53
19
Years of Service
User Offline
Joined: 14th Jul 2005
Location:
Posted: 29th Oct 2005 03:10
I'm not sure if that's the problem.

If you can read this, you are over qualified.
headcrab 53
19
Years of Service
User Offline
Joined: 14th Jul 2005
Location:
Posted: 30th Oct 2005 22:58 Edited at: 30th Oct 2005 22:59
I fixed my problem. For anybody who has the same problem, here's what I did:

Ok, the playergrav# variable holds the speed that you jump or fall. This is done by: posy#=posy#+playergrav#

I have a seperate object with the same width and depth, but smaller height. The object is positioned above you and below you and checks for a collision with the map, which is stored in floor and ceiling. if floor=1 (you're on the ground) or ceiling=1 (the ceiling is above you) then playergrav#=0 which makes you stay on the floor if you're standing on it and fall back down if the floor is above you. This prevents you from jumping through the ceiling.

Windows XP Service Pack 2 -- Pentium 4 HT 3.0 ghz
1 GB DUAL DDR RAM -- NVIDIA GeForce 6600 GT 128 MB (PCI Express)
the Last Programmer
19
Years of Service
User Offline
Joined: 14th Jul 2005
Location: Abilene, TX
Posted: 9th Nov 2005 04:38 Edited at: 1st Dec 2005 05:06
Hi everyone,

Thanks for all the replies and bug information. Basically, you cannot have bars in your level because the collision function will move right through them, because of the "thin" nature of vectors. The only solution to this is to call intersect object more times, but that would slow down frame rate.

Here is an update to the function that only uses five intersect object commands instead of ten:



That function is for the camera, not for an object. Just switch the camera commands to object commands for the function to work on an object.

Currently, I've been working on a video game with creature animation. I've revised the collision function to work with the creature's animation frames. It works so far. Maybe I'll post an executable later on.



www.fishbrosentertainment.com
Acolyte Entertainment
19
Years of Service
User Offline
Joined: 28th Dec 2004
Location: Oregon, US
Posted: 31st Dec 2005 20:17 Edited at: 31st Dec 2005 20:17
the last programmer. is there a way to make this 3rd person unstead of first person?
like make it so the camera follows a object?

the Last Programmer
19
Years of Service
User Offline
Joined: 14th Jul 2005
Location: Abilene, TX
Posted: 1st Jan 2006 07:19 Edited at: 1st Jan 2006 07:22
Hi there,

Quote: "is there a way to make this 3rd person unstead of first person?
like make it so the camera follows a object?
"


Just program the camera to follow the object using something like the SET CAMERA TO FOLLOW command, then call the objectCollisionHandler() function on the object so the object doesn't go through anything.

Unless you mean you want to have the camera follow the object and have itself not go through the level? Like something where the camera does not go through objects, but around them, like in almost all professional games today. Then I'd have to say I haven't figured out any algorithm for that yet.

But if you're just interested in having a camera set up as third person then go with the SET CAMERA TO FOLLOW command. It never failed me yet. Or you can go with my own function, setCamera():



It works with the other function, setFakeVehicle(). I'm sure you'll see how they both work. The latter function sets up an object based on another object's position, then the former function sets up the camera based on the position of the set up object. You'll get the idea.


Good luck.

[edit] Hey everybody. I've discovered this really annoying bug with my function: I go through corners. Everytime I line up my camera or my object, I can manage to go right through a corner. I've tried fixing this problem but I just can't seem to get it right. I was just wondering if any of you people could help out. Thanks.


www.fishbrosentertainment.com
statusquo
18
Years of Service
User Offline
Joined: 7th Dec 2005
Location:
Posted: 1st Jan 2006 19:05


That was awesome. I've been learning about collision too. I bet you must of taking some great pains drinking tons of coffee and thinking about those variables.

Currently, I've been stressing on giving enemies believable AI. Collision to an animated object, or entity is something that takes serious paper and pen work that I've also be praticing. I still read the journals of Lee Bamber, and I study his code for principles. He's not human. The stuff his does with his language makes me scratch my head, laughing.


One thing though, is that you must of spent hours figuring a good algorithm out.

From having seen all types of code from fellow programmers, there's so much to learn interms of collision.

I'm glad I have so much theory and concept to look and and practice. Thanks for your contribution. It has saved me time.


I don't even program in C++ anymore. DarkBasic Professional is awesome. ^_^

One thing that bothers me, besides the collision, is the illusion of a light source illuminating a texture. In the Chronicals of Riddick, I've being trying figure out some sort of way I could give a bump-mapped texture the illusion of it glimming with a sort of brillance. I might have to buy some new books explain that principle. Figuring that stuff out hurts my head, as does many programmers.
FROGGIE!
21
Years of Service
User Offline
Joined: 4th Oct 2003
Location: in front of my computer
Posted: 15th Feb 2006 19:53 Edited at: 15th Feb 2006 20:05
@The last programmer:

Ive not managed to fix the bug youve just ben talking about - i hadnt actually noticed it. But what i have don is reduce it to only 2 intersect object commands (for my code anyway, if you want up and down collision then you will need 3):



Basically, rather than get an intersect value for left and right, it will get one of the enire x axis (up to the radius limit), and then use some simple maths to work out the left and right values. Likewise it does the same for the forwards and backwards intersections.

Ive also changed it to a subroutine, and removed the Y axis collision (this is just to suit my game), so you may need to replace them.

*The variables used are exactly the same as with the function version of this code, the only difference is that they have to be defined/filled with data before calling the subroutine.
Essence
22
Years of Service
User Offline
Joined: 12th Oct 2002
Location: The Netherlands
Posted: 21st Feb 2006 20:03
This one isn't that perfect.

I'm creating a descend kinda-game.
Collision does not work on: Spheres/Cylinder and Ceilings

The ceiling is at different heights, so there isn't a static value bound to the ceiling-height value.


Im searching for a collision function, thats quite simple to implant, and that will work for every angle. So, collision on walls, floors, ceilings, cylinders, spheres and all of it.
Anyone?


First DifNiX -> now EvaX.

Login to post a reply

Server time is: 2024-11-23 06:58:20
Your offset time is: 2024-11-23 06:58:20