1. using Lods for your trees may or may not give a performance boost, depending on the polygon amount, skin size, and the potential for the camera to see many trees at once. To do a test to see if you can refine some FPS, place all the trees that you want in your level, or place the amount of trees that you want in the final game. Make sure these trees dont have any lods, just the main tree model. Then run the level and put the camera where you will generally be playing the game, such as a low third person camera, or a top down view. Then try to get the camera in a place where you see the most trees at once, but still playing within the confines of the game(no developer free move camera). This is because the person who plays the game will most likely find a place where too many trees are visible, and notice the FPS drop. Try to note down the REF, FPS, and Kilopolygons in the Statistics panel.
After you run the test, now its time to run the level with the LODS available on the trees. First you have to go into the tree action, and put this:
ent_morph(me,tree_0); // this morphs the tree to a file that has LOD activated, so you dont have to replace all the models in WED.
Just make sure you made 1 or 2 LOD stages in MED. Then run the level and try to find the place where you see all the trees again (you can even create an area where you have MANY trees in a block formation. This way you can tweak to the fullest to get a resonable refresh rate, even though the player wont see that many trees. This forces you to tweak things even more). If the REF, FPS and Kilopolygons, dont have any noticable decrease in numbers, or say the drop in say the REF was originally 3.8, then 3.7, then LODS wont really help, and now you will just clutter up your game folder with unneccisary lod stages. Just test everything you can, sometimes even making "stress-test" levels where you have say 400 trees, and tweak all skins, poly counts as much as you can. This way you pinpoint every object type and refine them.
I have 2-3 test levels that have only a large terrain and environmental entities such as trees and grass running script. In one level I am tweaking the code and skins so the engine can handle say 200 visible trees at once, each running code and using lods. I know there are many variables that can differ in my tests, but atm I can have 100 visible trees, each running code using a trace(for culling behind blocks) and a vec_dist(these 2 are not run on every frame, only when their turn is up). I have a 1.0-1.3 ms for code execution, and 1.6-1.8 for refresh. Im trying to make a goal to reach 200 visible trees, under a 2.0 refresh rate. I know Im going to have to shrink my skin sizes, lower poly counts, and use some un-conventional culling tricks to work into 200 visible trees. This is just an example of what you should be doing in my opinion, because things like trees, grass, birds and the like arent too pivotal in the game, and shouldnt hamper the FPS. Let your AI and effects eat the resources.
2. In the function that creates your explosion, try placing a "wait(1)" before you create the next explosion entity. The way your code is running, the engine technically has to create all those enitities in one frame(some times over 2 frames depending on the speed). You shouldnt really notice the wait when you launch the explosion, but waits definitly help:
ran.x = my.x + (my.it * COS(my.pan + 0 - 180));
ran.y = my.y + (my.it * sin(my.pan + 0 - 180));
ran.z = my.z; //+ (my.it * tan(-my.tilt + 0));
wait(1);
create(<explo.mdl>,ran.x,explo);
This goes also for your explosion entity's own script, since I see one create function. Place a wait before that, it lets the engine take a breather. Yes, since using wait, you will cause the creation of the entities to happen at different frames. This should help.
Using scan and trace in my experience isnt as much as a hog as c_move is, but also places waits before these, or bunch the trace and scan right next to each other, and place a wait before doing both.
3. Try using PCX format for your sprites, since BMP isnt as compressed as PCX. As for your sprite size, it depends. Its up to you to shrink and test, and evaluate the look of it. For example shink it to 32x32 then run the level. If the explosion looks too pixelated even though its for a moment, then go back to using 64x64 and tweak something else in the explosion such as the amount of sprites being thrown out at once. We have many avenues to getting the FPS and REF up so dont worry. If we cant sacrifice the look of something, we should sacrifice something else. Even the top of line developers using the latest computer technology, do things like this. If an unoptimized RTS game has 3200 soldiers on screen at once, then how many soldiers will we have if we optimized the game even further? Maybe 8200, or even 10,000 soldiers. Its milking the engine for all its worth.
4. I dont think YOU will have a problem using overlay, and a PCX image. Since in your case you have black outlines as your game style, the well known problem of black outlines using flare can be overlooked, even welcomed, because of the cartoony style you have. Take it and run with it.
Well, making a game on a low-end computer is a blessing and a curse, and I know this first hand from working on a slow system with A6 before getting a new computer. When I worked on the slower one, it was IMPERATIVE that I tweaked all graphics and code to the fullest to get my head above the FPS, and its a habit that sticks with me till now. You have to dig and scratch for every scrap to make the game run smoothly on a lower end system, since we dont have raw power like a better system. On the other hand it was a curse, especially in my case, since it had an integrated graphics chip with no shader capability, and a slower cpu. These are more luxuries than necessities, but frustrations with things you have no power over (changing CPU, or having to work with an irreplacable graphics card) can take a toll on your patience.
Working with a better system has its obvious quirks, but for me I feel I have left out the lower end systems, mainly because of the great looking games that ran great with their non-shader graphics card. Well I guess you win some and you lose some right? (hey this quote can be used for the tweaking in your game!)
