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.

Program Announcements / 3D Motor Chase (DBPro version with Source Code)

Years of Service
User Offline
Joined: 1st Nov 2007
Location: NW United Kingdom
Posted: 7th Dec 2011 01:36 Edited at: 7th Dec 2011 19:56
This took me less than 36 hours to complete. (But then also read the ReadMe.txt in the archive attached)

Please find attached the Dark Basic Pro complete project source files and media for this completed game.

For DBP users. DBP runs much faster than Dark GDK. The two versions of this game I have done has confirmed this. On my old laptop, the Dark GDK version runs at 17 FPS, while the DBPro version gives me 27+ FPS.

Original GDK Screen shots:

NB: Add more comments to this post...

The original WIP -
The Dark GDK version -

My highest score on level 5 is 1625 so far...

1. If you can get away with doing your calculations using integers then do. In the source code to this game I store positions for objects as integers, I do my collision checking calculations using integers. When playing this game it has to do upto 10,000 collision checks each loop. For the speed increase, I've used integer calcs instead of floats.

Also in this game, I do not use the built in collision OR any other plugin for collision checking whatsoever. I've done it my own way which has been proven in the frame rates. Realistically though, I only need to check the X and Z coords.

2. Use "LOCAL" variables in functions. It has been confirmed that using local variables in functions in DBP does speed up execution. Maybe not by much but in this game some functions are called upto 10,000 times each update loop so it is essential for a speed up wherever possible.

3. Typos are mistakes we all make, for example, you have a variable called my_screen_width, and in your program you mis-type it as something like my_scren_width. Even in Dark Basic Pro your program will do many strange things because of a typo like this as the compiler will think of that as a new variable. How do you get around this and make your coding quicker?

The easiest way is to use the TYPE's in Dark Basic.

This now helps out immensely as if you do a typo now on a TYPE'd variable, the compiler will complain, and help you track them down quicker. Where-as before in a large section of code it would take forever of hair pulling.

More to come...

Mental arithmetic? Me? (That's for computers) I can't subtract a fart from a plate of beans!
Warning! May contain Nuts!


Login to view attachments
Chris Tate
DBPro Master
Years of Service
User Offline
Joined: 29th Aug 2008
Location: London, England
Posted: 7th Dec 2011 22:18
I played on medium and got 1652 so far. I am a bit tired after working all day.

It gets thrilling when you ride through close by trees and lakes whilst trying to avoid them. It makes me laugh when I crash lots of times in one second, my subwoofer really lets me know how much damage I am causing.

I wish I could put something like that together in 36 hours. I stopped using DarkGDK because I felt I was better off interms of stability and plugin options with DBPRO; always assumed the GDK ran faster.

I got 50 fps on my Athlon 2; Geforce GS8400 512mb system; which is faster for me than usual games I download here; and it has a large open field; some games are slow inside a room.

Joe Staff
Years of Service
User Offline
Joined: 7th Dec 2011
Location: Midsouth, USA
Posted: 8th Dec 2011 05:36
New to the forum here, but not to game developing.

I played it for quite a little while, maybe 20 minutes at 60FPS, no hassle. I'm assuming you're using randomly generated positions for your trees?

If so, you could dramatically shorten CPU usage by using a formula based on the tree's X,Y position, assuming you're using a grid system.

if XPos MOD 20 = 1
if YPos MOD 3 = 1 then AddTree
(Just an example, wouldn't be a very pretty forest)

This would mean you could determine if a tree was nearby solely by the player's position, so no distance calculations of trees outside of the player's collision radius

if PlayerXPos MOD 20 = 1
if PlayerYPos MOD 3 = 1 then Collision
//Just an example, you would have to perform this check on points surrounding player

Those "10,000" checks you spoke of on a different thread would be eliminated

Good luck and good job on the game.
Years of Service
User Offline
Joined: 1st Nov 2007
Location: NW United Kingdom
Posted: 8th Dec 2011 17:37 Edited at: 8th Dec 2011 17:56
@Chris - I've played around with PureGDK betas for some time now and I've noticed that it runs at approximately the same speed as Dark Basic with only the speed difference of C++ really. But still, you get the freedom of the rest of the API's with PureGDK where DarkGDK you're stuck within it's setup.

I still can't beat my score or yours either come to think of it...

@Joe Staff - I read what you mentioned last night and came up with a few things to speed it up just a tad. Thanks for the input, it really made me think. Here's what I come up with: (explanation first though)

On the x86 processors every instruction takes up 'x' amount of cpu clock cycles. The ADD, SUB and CMP will take up either 1 or 2 cpu cycles (faster if programmed correctly on the instruction cache pipeline). Whereas the MUL / IMUL will take approx 60 cpu cycles, and the DIV will take upto 125 cpu cycles.

Coming to making a quick speed fix to the "function TREES_FIND_CLOSEST()", already it was optimised so that it's not using the sqrt() every time which would slow it down, but it does have two multiplies in the loop, 120 cpu cycles taken there. So I thought adding more code as usual does increase speed.

As in the updated version of the function below, I've grabbed the X distance then done some nested compares, obviously if these are true then it will then grab the Y distance and do the same thing. Thus shaving the cpu cycles on thousands of trees that are not within range. Even so, the speed increase is negligible, you had made me think about it.

Here's the updated source for "function TREES_FIND_CLOSEST()" which makes a slight difference on my slow laptop.

The "function TREES_PLACE(num)" is where it will randomly add the trees to the map. It will not place trees under the water line ( < 100 ) and also it will place certain trees within height ranges.

The two slowest parts of the game currently are:

1. Loading the bikes model which I should have converted to a dbo file. DBO's are native to DBPro and do not need converting upon loading.

2. The generation of the clouds using the perlin noise. I am generating a 1024 x 1024 texture for the sky dome.

EDIT: After just reading through the Intel documents I've actually found that my cpu cycles are incorrect, IMUL has a latency or 10-14 and DIV has a latency of upto 65. Plus I hadn't considered the fact the DBPro may actually call sub-routines to do the calculations (which I doubt). Either way, the above optimisation will still increase the performance of the function with the nested compares.

Mental arithmetic? Me? (That's for computers) I can't subtract a fart from a plate of beans!
Warning! May contain Nuts!
Years of Service
User Offline
Joined: 17th Aug 2009
Location: The World
Posted: 5th Feb 2012 11:03

I was very impressed with this

the finding the nearest tree code is one I will be using

I know it can be applied to more than just tree's

thanks for making in DBP the other is beyond my skill set at this point

the seamless never ending matrix is anther peace of fine coding

to move side ways - is to move forward
Since a Strait line gets thin fast

Login to post a reply

Server time is: 2019-06-27 01:53:22
Your offset time is: 2019-06-27 01:53:22