@Hangar18
Hello,
Well, a major slow down in any program are nested loops. If you are running through separate loops to handle all of your updates (planet, ship positions, whether an object is hidden or not, etc.) this will definately eat processing time. If you can find a way to update one thing at a time with each iteration of the main loop, or stagger some of the updates for say, every third iteration of the main loop, your game speed should increase.
If you have a lot of bitmap screen active where you are drawing things in the background, that will sap speed.
Quote: "Then I texture the object with the different explosion frames. I wonder if because the texture has to "contort" itself to fit into the plain, does this cause a huge performance hit?"
In general, once you make an object of a particluar size and shape, it is set up with UV coordiates that basically describe how to stretch a texture over it. The texture's properties don't change, it stays as it is. The object UV coords will handle whether the texture is painted oblong or not. Depending on the size of your textures, cycling them will slow performance.
Are your explosion images predefined or are you capturing the images or loading them each time you are using them? I wonder if you could just create a small avi of the explosion and position it. I don't know how that would affect performance.
There's a bit of a misconception in regards to polygon count and frames per second. While there is a correlation: as the polygon count goes up, the frame rate goes down - it doesn't describe the whole picture. If you are to create a single cube, you have 12 polygons. If you create six planes, you have 12 polygons, but a lower frame rate. The reason being is each object is "indexed" in memory. To draw 6 separate planes, the processor has to cycle through memory addresses and render each plane. With the cube, it only has to check one index. Also, in general, you will have 24 different vertices for the 6 plains and possibly only 8 for the cube - the faces will be reusing vertices.
I ran a series of tests on matrices versus directx object grids, vs plains, vs triangles - (this being only a brief recap of the data) that more objects with relative polygon counts affect the frame rate more than single objects with higher polygon counts. Matrices and grid objects perform almost identically as the number of grid squares increase.
Quote: "if so is there a way to import .x files into another modelling program (to clean them up from Direc 9x support) so I can re-export them as .x files that DBC will like 100% of the time?"
If the directx file is causing a severe exception, (I'm not sure what you mean by crashing) in DBC - I've usually seen this as a result of inconsistant frame handling in the directx file itself. When I created my DBC exporter for Blender and also one for Anim8or, I found DBC was very particular about how the frames were set up and handled (A Frame in a directx file is like a box that holds all of the mesh information and also is referenced by any animation - it's basically the definition of a limb.) Depending on how DOGA creates it's export, there may be issues.
If your models aren't animated, I've always had great success in importing directx models into Deled 3d and then exporting them back out with Deleds X exporter. They seem to work flawlessly with DBC. But I haven't updated Deled 3d in about 8 months.
Quote: "Next I do a test to see if any of the 10 other NPC ships (polys are about 500-600 per ship which I dont think is a problem but let me know if you disagree) are on screen, if not then I hide them (same with planets). "
Perhaps hide the 10 ships from the get go and don't do any tests to update them. Create a random routine that positions the ships at some planet. Also have another routine that randomly selects 2 or three of the ships to attack or whatever when your ship is a certain distance from somewhere or something. Keep the whereabouts and what ships will attack in an array(s) and only make them appear or update their popsition when your ship has entered a "danger zone". This way, your program never has manage the enemy ships until your ship's position triggers something to happen. And when it does, the program will only deal with the two or three ships you have stored in the attack array - instead of cycling through all 10.
The bullet thing, well if the bullets are objects, their position is already stored in OBJECT POSITION. I created a rain function and it ran through a loop of all the rain drops (if they weren't onscreen they weren't visible). When the rain drop reached a certain ground height, it's position was reset to somewhere up above. A variation of this would be to have the function triggered by a trigger pull (mouse click or whatever), one of the parameters being the start number of a bullet, and then increasing the bullet number (up to 16) as long as the the trigger is pulled (thus going through the loop). At 16, the function always returns so it doesn't stay in an infinite loops and returns the last bullet fired (so you could actually leave the function after say 5 shots were fired). You could reseed the function with the last shot so you can get the correct position updates. This probably doesn't make sense as I'm getting very sleepy. Anyway, that's it for now... can't type anymore.
Enjoy your day.
