Sorry your browser is not supported!

Ive been stupidly programming with an athlon 2800 not thinking how the program would run on other computers. On a 1300mhz it drops 20 frames per second. Ive been reorganising the code having my main loop filled with only if....then gosub... so that it does only what need be but it still runs too slow.

I have already figured out most of the obvious things that determine how fast it runs like matrix size, display mode, texture sizes, camera view etc...

But...
I was thinking that maybe there are some commands within dbpro which I should avoid using which would drop frames per second significantly?


btw
I remember that Unreal Tournament would run smoothly on a 450mhz computer but as you attempt to reconstruct something similar with dbpro you realise that this is impossible. Is it fair to say that the frames per second on programs made with dbpro is generally lower that it should be and why is this? maybe its just me.

Messing with bitmaps is slow. This includes the Point, Circle etc commands, as well as GET IMAGE.

You can always set the SYNC RATE to something more reasonable for the game you are programming, and readjust your code to suit.

gsd:

Avoid using matrices using the MATRIX commands if you´re looking for speed, they can be really slow if you use a 100*100 tiles matrix. Use 3D models as terrains instead and use commands like INTERSECT OBJECT to get objects "standing" over it. A bit trickier to work whit but i have found it to be a lot faster.

Watch out the "SET OBJECT COLLISOIN TO POLYGONS" it is very slow when using detailed objects.

btw
Due to the way DarkBasic is constructed, its slower than the more common languages like C and C++ used in most games that goes commercial. Its a simple tradeoff, you can quickly create an 3D-enviroment and have objects moving at the cost of a slower program when using program like DarkBASIC. If you use C++ you have to code this for yourself but you´ll get a better control on things and can tell the program what exacly it should do.

It´s not impossible to create a game like UT (think you´re talking about the first UT) but it requires time, dedication, good knowledge in optimizing computer programs in general and obviously good skills in the langauge itself.

- Tywald

Right now the neatest and fastest terrains possible are memblock matrices, these use Interpolation for ground collision (very fast) and build the mesh inside the engine (neat) AND! - you can avoid the usual matrice bugs (tile edges being too visible for instance) with code and can treat the terrain just like an object. Perhaps the nicest feature though is vertice colouring, you can colour and vertice in a memblock matrice, so lightmaps can be created really easily and they make a huge impact on the look of your terrain. Personally I like to use matrices in level editors because they're not buggy and are fairly easy to use - but taking the matrice data and making a memblock mesh from it is definately a good way to develop your engine.
For a great example of memblock matrices, check out the codebase for Kevils snippets (Kevin Verbeek).

I've never used DB/DBPro's built in collision system for objects, and if I can help it I never will, polygonal collision detection is intensely slow for a real game. I actually used a hybrid interpolated grid system the last time, and it could handle something like 200 collision checks per loop without affecting the frame rate too much - there are much faster alternatives for collision, you just gotta spend time on it.


Van-B

Looked at the codebase..I have no clue whatsoever what the code is doing!