Sorry your browser is not supported!

I pretty much have a complete GTA clone in Dark Basic Pro now. Everything is in place (City map, traffic, car jacking, pedestrians, police, weapons etc) but I've run into a bit of an obstacle with the vehicles. I'm using Sparky's DLL for collision, including vehicles. It sort of works okay but it's not perfect. Main issue is with the collision radius for the vehicles which (due to their length) doesn't work well with the collision radius. I set the radius too small and the collision only works in the centre of the vehicle. If I set the radius higher, the vehicle ends up floating above ground and there's invisible collision on the sides. I can't figure out how to just extend the collision check along the vehicle's Z axis without adjusting its X and Y.

So, I thought about scrapping Sparky's DLL and using Dark Physics but it has its limitations. Dark Physics would be perfect since it allows me to quickly add a vehicle but you see, my system relies on spawning vehicles near the player and then deleting them when they're a certain distance away and behind. The Dark Physics command "phy delete rigid body" doesn't seem to want to work with vehicles. It just crashes the program. This pretty much makes Dark Physics unsuitable for my requirements. I then looked at using the Open Dynamics Engine but the lack of Dark Basic Pro specific documentation makes this very hard to implement.

Basically, I'm wondering how to manually program basic vehicle physics in Dark Basic Pro. I'm not looking for super realistic physics. Ideally, I want to be able to work out when a vehicle's wheel (Each wheel is a separate limb on the vehicle model) mounts a kerb and the vehicle rotation changes slightly to represent what would happen in real life. Is this possible without a physics plugin, using just Dark Basic commands and Sparky's DLL? I thought it would be nice to start a discussion because I can't find anything on the forum.

Congratulations for your progress. I 'd understand why a basic vehicle physics system would suit. I am not sure if it would have been worth using not one sparky's collision radius, but two; one for the length and the other for the width and height; but I cannot see the code and cannot know if it would be feasible as it would if optimized.

To that end I would recommend Dark Dynamix, the physics engine I am using for my driving physics; its vehicle engine requires a bit of effort to set up, but is light-years ahead of Dark Physics in terms of car driving gameplay. It is the first DarkBASIC Professional plugin in the plugin menu for a good reason. Whilst Dark Physics does have its benefits, I'd recommend Dark Dynamix for the driving aspect of the game.

But to reiterate; I am not sure why you could not just use an additional radius for the Z axis, and use the directional normal (that is a coefficient range between 0.0 and 1.0) along the side angle multiplied by that radius to reducing its influence of on the X axis, a bit like a oval shaped raycast rather than an equidistant one of a circle.

Hey Chris, thanks for the reply! It seems I've missed a lot of new stuff in the TGC community over the past few years. Just checked out Dark Dynamix and it looks pretty awesome. Would definitely consider purchasing it some time soon because the vehicle physics aspect looks really interesting. What you suggested about having a second collision radius sounds like a good concept and I might have a go at trying to implement that. It'd be a good start for what I require. The code for vehicle collision check I'm using is straight from the Sparky Demo with a few minor changes.



"V" refers to all vehicle models and right now I have the collision radius at 7.5 since that keeps the vehicle model exactly on the ground, where I need it. However, it doesn't take into account the front and back of the vehicle. I've attached a screenshot showing what happens (forgive the crude graphics, many of the models are place-holders while I focus on programming). The boundary box shows that the length of the vehicle is taken into account by the player's collision check (When on foot, you can't walk through the front of a static vehicle). It's only when you control a vehicle that you get the problem with the collision check as you can see in the bottom image.

No worries about the graphics; what's quite ironic is that I am more into the graphics side of game programming, yet could care less about graphics in video games vs gameplay; and we all need placeholders for a reason.

I can see your point; I think building your own vehicle physics with Sparky's collision gives you more control over the experience, but requires lots of work getting right. Dark Dynamix makes it easier to get the ball rolling, but requires alot of effort setting up the wheels for the vehicles; it features something more of a wheel physics engine than something specifically for driving a standard vehicle. So you can also use it to make motorbikes if you wanted.

I think an even easier short term fix is to place a collision radius at the front of the vehicle, that might be easier to set up than the oval shaped raycast; but it's all down to you.

Check out the anisotropic filtering plugin, its quite a nice fix for blurry textures in the distance due to the default linear texture filtering on objects with no advanced settings.

Ah, that sounds like a good idea with the extra collision radius. I'll have a go at implementing that. And thanks for the link for the anisotropic plugin, that should come in useful.