Sorry your browser is not supported!

What tasks will slow down dbpro project the most and what can be done to make it greatly faster....my project which doesnt actually have alot going on is slowing down allot and im just wondering what tasks maybe doing this.

You mean other running programs ? Any busy program will slow down any other program (not just DBPro). Very heavy disk I/O doesn't help either.

With all due respect, and not reviewing your code

Poorly written rouines are the biggest culprit in all programming efforts. This statement can be easily proven by the fact that many of the examples run very well.

Look over you code, avoid any redundant functions.

Can you jump past routines by testing before wasting cycles.
re-arrange tests to make sure the most likly to fail condition is tested 1st

find ways to reduce repetitive tasks per game loop

a simple for / loop in you main game loop can be reduced with methods like creating a timer, having check the loop in question every other timer check.

This can reduce a loops performance hit but is just one solution to reduce the constant checks and the amount of checks performed each gameloop of your main games do/loop or while/endwhile etc..

And don't forget the obvious, already well know issues:

-Too many polygons in your models.
-Too many animating 3D characters (slows down a lot)
-Too many high-res textures
-Too many models (DB handles these better now, but its still faster to use 1 model for a house than a different model for each wall and item of furniture etc)

too many polygons
most people when they start using dbpro overlook this.
unless you have a really really really good graphics card

i find that infinite loops tend to hamper fps.

do a maths check to see if two objects are close before doing a collision check - especialy sliding collision.

distancebetween2objects#=sqrt((ob1x#-ob2x#)^2+(ob1y#-ob2y#)^2+(ob1z#-ob2z#)^2)

Besides heavy polygons, I would like to add "lights" to the list.

if you're using native 2d like text, line, dot, box, your program will really slow down like you've a giant stone on your shoulders.

And Lee refused to improve this when i asked for.

Optimisation is the true art of programming. Pretty much anyone can make a game that looks good in DBPro if they have the artistic talent, but making it run fast enough to play is an art form.

Two key DB engine issues you can apply are replacing the main do...loop with a for...next loop as thus:

for next loops have no break check in DB and consequently run faster. I think this might have been done to speed up the debugger but I dont really know as I dont use that.

However the most significant speed gain that is easy to achieve is reducing the number of texture files per object. An object which has 7 or 8 texture files rather than 1 composite image with all the textures on runs very slowly by comparison within DB.

Obviously in most cases it is impossible to do this with the world/level object, but it is possible to reduce the quantity of texture images.

The principle optimisation in my own games is born from two methodologies. Firstly exclusive statements:

If...else...endIf

Much code does not need testing if another condition is true.



In the above example the down key is only tested when the up key is not pressed, lets explore the concept a little further.



Now you will notice that the maximum speed is only tested when the speed is increased because it is part of the if upkey() structure, likewise the stationary speed check is also only tested when the player is decelerating.

The use of if...else...endif is a critical key to developing optimised code. My own code is heavily structured in this way and often results in large sections of massively indented code.

Another trick is to learn the speeds of various commands. Do you know which method of clearing the screen is faster?

ink 0,0
box 0,0,screen width(),screen height()

or

cls 0

You might be suprised Try it at a few resolutions. Understanding how long it takes to perform given tasks will help you to know when to include a prefixing structured if test to determine whether a task should be completed, or whether it is faster to just perform the task.

Learn the speed of commands with a simple timed loop test.



When positioning an object often the object number we require is calculated, ie:

position object enemy+100,object position x(enemy+100),object position y(enemy+100),object position (enemy+100)+1

In this instance it would be faster to precalculate the enemy object number

enemyObj=enemy+100
position object enemyObj,object position x(enemyObj),object position y(enemyObj),object position (enemyObj)+1

One final point in reading above, I saw this range test:

distancebetween2objects#=sqrt((ob1x#-ob2x#)^2+(ob1y#-ob2y#)^2+(ob1z#-ob2z#)^2)

The technique the poster mentions is very wise also and a good one, but it can be further optimised because square route mathematics are very slow for 3D range testing.

If you would care to look at my Programmers Resource on my web page (http://www.bansheestudios.com) there you will find a method for range testing using vector mathematics. This is nearly twice the speed and equally accurate.

I hope these help.

Just a little note...

'distancebetween2objects#=sqrt((ob1x#-ob2x#)^2+(ob1y#-ob2y#)^2+(ob1z#-ob2z#)^2) '

Although it'd take more code, wouldn't it be fasted to just do 'if PX>OX-50', and then the same for Z and Y... because if you were too far away on the X, which in most cases you will be, you'll be skipping the more detailed math of the above calculation.

Although it's a really small difference .

You make a very valid point mouse but one that needs careful consideration whenever making a range check, particularly one that is made several times within the same game loop such as bullet collision etc.

Let's expand it fully so we can see what we are talking about. This code will make a cuboid collision area of 100x100x100 size.



Now if our game is played predominantly on the horizontal axis then we would find that x and z test true on a more or less 50/50 basis (dependant upon level layout) but y will almost always test true, in such a circumstance it is faster to test y last of all (if indeed it is even necessary).

Likewise a game played along a certain path, for instance a game I am working on now moves the player constantly along the z axis, then it is faster to test z first. In my game the bullets frequently line up with the target on the x and y axis but do not hit because of range, making x and y common true tests.

Ultimately I chose a vectorered 3D range test because I wanted a spherical collision zone, but I first filtered out many results with a quick z check.



Where range3D is a function returning the result of a 3D range check. The z check is stripping off the majority of the range3D tests because due to the game mechanics the condition tests false most of the time.

The faster 1D range test "abs(x-x)" is much faster than testing range in 3D, and consequently improves performance of the routine overall by a significant factor, emphasised all the more so because it is a bullet firing routine handling dozens of bullets at once as part of a for..next loop.