Sorry your browser is not supported!

No offense to anyone. I'm actually seeking advice rather than a pity party. First off, I have a Gateway 2.6 Gigahertz PC that can run Starwraith 2 rather well...

I'm making a small mini-game in DBClassic as a learning experience. The project is coming to a close, but I'm running into alot of speed bumps - literally.

As some of you are aware, I'm a really large cheapsk... I mean poor (that's why I went DBC). When I load a common pool of objects, the game always slows down big time.

The game I'm making has a hidden pool of enemies that are shown and then summoned to float down the cave constantly - getting shot at or firing plasma orbs themselves. because of how badly the game slowed down with 3D models of the enemies, I resorted to making these opponents textured plains.

That worked out until I made some bullets for them out of DB objects - red spheres. with a handy number (around 8) this cut off more that 10 of the 30 FPS that I was trying so desperately to maintain. Even with only two bullets for the many enemies, the FPS rating drops to the lower 20s .

One question: how much faster are .x files than DB objects?

Question 2: do matrixes contribute alot of slowdown to the framerate.

Question 3: What do you recomend I do about the enemy bullets, make more textured plains? How about more .x files?

Question 4: Any tricks for managing so many objects without the slowdown (ie, weapon bullets, enemies, particles, level objects, powerups, etc.)?

Sorry about the rant, I think my next game will be a one-on-one fighting game just to keep the <bleep>-ing object numbers down (wowwie, one fighter, another fighter and an arena, and a dozen collision points! TOTAL = 15 objects, FPS = hopefully 60).
vs.

I'm sorry, I guess I'm just starting to get a bit frustrated.

i thought you had tough problems

1 - X objects are faster than primative objects of the same type. IE a cube primative is slower than a cube "X file". This does become more complex with complex models. At that time, polycount becomes important. Another concideration is texturing. Small 64x64 textures are better than 256x256. Unless you have a model using multiple texture files. Then, its better to combine the smaller files into one larger one....... confused now?

2 - matrixes do contribute polygons that need to be rendered. Again, size is the issue. Each tile is 4 triangles, so a 20x20 matrix uses 1600 polygons. Also, the textures used in the matrix take up space on the 3D card that your models might want to use.
A large matrix (dementions) with few tiles will run faster and look better than a small matrix with many tiles. Also, tinker with camera range and fog range.

3 - Bullets. Are these like gunshots that move instantly or missiles or arrows that move slowly? Instant bullets are the cheapest method as far as frame rates go. You either hit or miss the target and there are no objects to move (except bullet holes). For others, do not use a primative sphere. It is very hi polycount. Use an X object. DBC has several untextured objects that work very well and use very little 3D space. They are colored and not textured.

4 - managing objects. Lots of tricks for this.
Hide objects not in view.
Make do with fewer creatures per wave, but have more waves.
Don't load all creatures and textures at one time.
Use smaller textures for your objects
Try to load new creatures/textures when the game is slow (not much action, so maybe the player won't notice the load time)

Thanks alot! You also cleared-up some of the suspicious I had about primitives. You're comments about managing objects are also well appreciated.

I started using Wings3D to model the bullets instead of make them using sphere primitives in DB. The frame rate has improved drastically.

On bullets...

1.. No spheres!!! use a textured ghosted plain pointed at the camera with a sphere texture on it all on black. It looks better and it's got 2 poligons instead of a ton that a sphere has.

2.. Try to check the distance a bullet has to travel before it hits the side of the cave once at the beginning when it's first fired. In db classic that's a matter of making a mini-loop the instant it's fired, then record that distance as the bullet's range. Now you know when it's going to hit the side of the matrix and don't have to check for it ever again.

3.. make sure you hide objects you aren't using.

Collision

1.. Don't use db classic's built in collision. Just don't. I've never had any luck with it and it slows down your game like crazy. Try to use math collision with your objects.

2.. for collision if you don't need it to be pixel perfect use distance = dx + dy + dz (or if it's dudes basically walking around on a flat surfact just use distance = dx+dz. It's a lot faster and usually it's close enough for government work.

The two things that slow down dbc the most as far as i can tell are dbc inbuilt collision and matrixes. I was going to use matrixes in combination with my regular level, i scratched that when i found it droped my fps from 80 to like 45-35 (its been a while so it might be slightly less but roughly the same) Good luck though

Dont use DBC Collisions and dont use color object! Just texture it with a flat color if you need to or do what ZomBfied said and use plains! DBC is really slow and innacurate if you use color object!

Thanks guys!

@ EthanSBored
Does it cause problems if you are not using Color Object in the main loop?

As long as the object has been colored at any time, it will cause problems. A colored object must be diffused, unlike a texture, but rendering a diffused color in DBC is terribly slow.