so what should i do then? O_O i have no idée what’s making the low fps if its not the smoke and the explosion entities.. >.<

2nd Shot: Your tree looks fine, and has a good poly count. Matter of fact the tree looked like it had a few 100 polys, but MED shows otherwise. Good skinning!

3rd Shot: It seems that your particle function is only 2.0 ms, thats ok for particles. BUT, your functions are 10!!! It seems then that you are using explosion entities(the yellow spark models) with actions assigned to them, then you created a mass of them at run time. These actions are eating resources unneccisarily. This is not really a good idea since particles render faster than models. Even then, its not a good idea to use models in your explosion unless the animation is really beleivable. Using a spark sprite will render much quicker, plus the camera wont really know its a flat image because the explosion will be in a blink of an eye. If you insist on using models in an explosion ,use them sparingly, say about 2-4 models. We have to economize the effect until it becomes less of a power hungry brute. After we can get the effect down (which functions should be around 1.2ms(after you've see the explosion already, its a ram thing), and the ref as much as we can. What functions are you calling in your explosion entities? Traces? C_Moves? I dont see how the functions can hog 10 ms in the debug panel, because I dont see any other moving NPCs, or Player entities. We have to now disect almost all happenings in your game to pinpoint the problem. This functions lag may be more serious than your slow Refresh rate.

I see that your explosion is in the form of the Cross, or X if you want to call it. This is just like bomberman as you said, and these bombs are the bombs that go off almost ALL THE TIME when you play bomberman. Just looking at your explosions (even though they are pretty), the amount of particles and functions(forget about ref right now) are WAY too much, and these bombs will be going off left and right in your game. So if we are having problems with ONE explosion, we'll be in a world of hurt for MANY explosions, not to mention the vacation slide show we'll have when our computers lag during multiplayer. This could however, be an explosion used by a level trigger, or a single air strike, or a one time use super bomb. These circumstances force the use of the explosion to be very little, so it dosent matter if the lag is large, since its a special explosion. Its almost the same reason why many games have their main character to have thousands and thousands of polygons with fingers, wrinkles and eye lids, while the NPCs in which the camera dosent focus to much have a MUCH lower polycount. Thats because the player is a special character, just like a special explosion, just in this case, we want a special reason to see the spectacular lag bomb

Even though DOOM 3 runs on a high end computer, the developers are ALWAYS ALWAYS ALWAYS optimizing code/graphics to acheive the best performance with as little as possible. I think your going to have to:

1. Reduce the created particles WAY, WAY, WAY down.
2. Figure out whats going on in the explosion entities, and what they are running thats causing the 10 ms lag. I see that your explosions follow the shape of the terrain. Are you looping unnecissary traces in a while loop?
3. Create LODS for your tree models, and your sprite particles.
4. Reduce clip_far. I say that becuse it seems you will use an arena type enclosure like bomberman. You can reduce the clip_far WAY down. This will also decrease the distance at which your LODs will switch. This will cause your models to switch to their next LOD level at faster increments if the camera is moving at them. This ultimatly will bring a lower poly count since we dont draw unnecisary polygons from far away.

About the REF when you see many smoke sprites up close:
5. Do not use TGA sprites for your explosions. This may be a case where flared PCX sprites will actually look good with a black outline, since your game is cell-shaded.
6. Reduce the resolution of your sprites as much as you can. Dont worry about pixelation, because at run time with the particles moving, we wont have time to stare at the sprites. Lower resolution sprites will only look bad when you take still shots, but dont worry about it. Screenshots wont do any game justice, no matter how pretty the screenshot is. To see it in action is to see it as it truly is
7. As before, reduce the amount of particles as much as you can. If you want to keep that thick cloudy look, instead of using a single ball of smoke in a sprite, and putting these together to make a cloud, make a sprite that has many smoke balls in it, or make a cloud formation in the sprite. This will cause the thickness of the cloud to still be present, just with lesser sprites. Metal Gear Solid for the PS2 used this technique liberally during the game. For example in the beginning of the tanker level, it was raining heavily. So instead of making each rain drop a sprite and multiplying this to a thousand, the artists created a sprite that had MANY rain drops in it and used fewer sprites altogether. This is the kind of trickery we must do in games, since everything you see on your moniter is pure trickery, from the colors you see to the movies you watch. Its ONE BIG TRICK :P

8. try setting this:

d3d_entsort = 0;

"If this predefined variable (default 1) is set to 0, transparent entities are not sorted before rendering in D3D mode. This can produce visible sorting faults of transparent entities with high alpha values or alpha channels, but increases the frame rate when a lot of transparent entities are on the screen. Single polygons of transparent entities, as well as transparent particles are generally unsorted for speed reasons. Therefore they can wrongly overlap each other, which normally is not noticeable on the screen."

In our terms, it means that when d3d_entsort is ZERO, transparent entities are not sorted during runtime. That means a transparent sprite that is 100 miles away from you, will overlap a transparent sprite that is 2 feet in front of you on screen. It may look funny, and somtimes downright creepy(especially on TGA tree models), but for our cases this wont be noticable since we have a thick cloud of explosions.

I will never use the excuse of you not having a super fast computer, because this is a foolish copout. Dont worry about your system specs hindering your FPS or other stats, because I'm sure the best developers are the ones who can make great looking/running games on very shallow system specs.

We'll keep digging and fighting, tooth and nail, until we get your level to bow to your feet.

The only thing that I can think of is to simplify your explosion and don't use a lot of entities. Around April or so, I ran an experiment. I had over 600 entities shown on the screen at once which had a tiny skin size and only 4 polies. The frame rate was 18 fps. The best thing to do is just cut down on the number of entities. For something like your explosion, you could do that in just one entity, although it might be rather difficult.

My worst-case scenario. Think 38 ms is bad for the screen refresh time? Try 171 ms. This is with level geometry (blocks) only in my old project that I've almost abandoned. 171 is crazy! I can kick that up even higher too and it's easy to do.

Edit: come to think of it, I should check to see if the high entity count/low frame rate issue is due to a massive screen refresh time. I'll run that experiment again using the small skin, low-poly object.

^^... that is good to hear.. but how can my lod inflict on the tree?... i can not really reduce any polygons without extreme changes.. and a 2sprite is a little to big lode for a arena game?..


hmm.. ok.. i just realised that my explosion is a bit to big function for just one frame in a moment there... i goes thru a while lop that creates a explosion model in all for directions with 10 in distance between and as many as needed to get up in the bombs range. That is maybe okay. but all explosions are tracing the floor ones and having roll and pan randomised 360 and then creates a read sprite that will make the read light from the explosions ((otherwises it feels emty >.<) and this one is scaling up a bit and so on.) and the explo model is set to the same player id(skill4) as the bomb (be able to determine witch player killing witch) then creates 6 smoke particles and scans 360 degrees around and damages everything within 50. all that is happening in one frame. That would make the frame extremely slow?.. >.< especially if there is big explosions with long range.
after that is it staying and randomising the pan in a while lop until its skill9 has retched 100 and then removes itself. (And has the skill9 goes up with a 30*time so it has about the same time independent from the fps).

///////////(the function that creates the explo)/////

while(my.it < (my.fp*10)){ // FP = firepower and it = timer skill

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));
create(<explo.mdl>,ran.x,explo);
ran.x = my.x + (my.it * COS(my.pan + 90 - 180));
ran.y = my.y + (my.it * sin(my.pan + 90 - 180));
ran.z = my.z; //+ (my.it * tan(-my.tilt + 90));
create(<explo.mdl>,ran.x,explo);
ran.x = my.x + (my.it * COS(my.pan + 180 - 180));
ran.y = my.y + (my.it * sin(my.pan + 180 - 180));
ran.z = my.z;// + (my.it * tan(-my.tilt + 0));
create(<explo.mdl>,ran.x,explo);
ran.x = my.x + (my.it * COS(my.pan + 270 - 180));
ran.y = my.y + (my.it * sin(my.pan + 270 - 180));
ran.z = my.z;// + (my.it * tan(-my.tilt + 270));
create(<explo.mdl>,ran.x,explo);
my.it += 10;
}


// what the explosions entity is going thru that same frame it is created///

my.pan = random(360);
my.roll = random(360);
create(<exp.bmp>,my.x,explo2);
my.scale_x = 0.2 + random( 0.3);
my.scale_y = my.scale_x;
my.scale_z = my.scale_x;
my.passable = on;
my.id = you.id;
my.z += 100;
my.fp = you.fp;
vec_set (temp, my.x);
temp.z -= 10000;
trace_mode = ignore_me + ignore_models + ignore_passable + ignore_sprites +use_box;
my.z += -trace (my.x, temp) + 1;
my.unlit = on;
my.bright = on;
my.albedo = 101;
my.nofog = on;
effect(smok,6,my.x,nullvector);
temp.pan = 360;
temp.tilt = 360;
temp.z = 50;
scan_entity (my.x, temp);





1. how many on an explo then?... half?... i love smoke... >.<

2. no... not in loop... but bad any way... i must probably split those actions up in some different frames?..

3. I am not using any other lod.. and i don’t know how to make lod for my sprites because the only sprites i use is the prickles.. and the tree can not have any les triangles?

4. I use morph and it does not change if it is without a certain present of the clip fare.. And i don’t know how to change that...


5. I use 64x64x16 bmps for the smoke....
6. how low can i have them then you think?...
7. I already has two round cloud dots on one sprite... and i seen that Zelda wind waker ex: uses 7 on one to make there effect of slashing water. but the smoke that follows the burning parts flying thru the air cant use to many on one sprite because that would look weird and when the size is increasing it looks a little weird when its not being a big could of them... but how many more times should i have them on the same image does you think? ^^
8. ...i will have problem with the trees using overlay then or am i not?..
and explosions that is on a little distance will be visible thru the one being near... it can look ok in many views but really bad in some. but maybe i will be making it as an option on the game menu so players with good computer can use it and them who don’t have the power uses the zero value? ... if it is possible?..


i really want to make a game that can look really good on a good computer.. but still look fine on a not that good also ^^... so using a bad computer creating it can be really good in the beginning... then creating the finishing touch using a grater computer to make good effects to be used on good computers? ^^

and thanks.. that sounds good.. ^^ really good

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!)

Quote:

---

The smoke doesn’t effect any noticeable when i am at a distance... but when i come close the time goes up a lot.

---

yes this a is a common and well understood problem with transparent polygons like sprites.. the closer or bigger they are the more pixels that need to be overdrawn by the engine. In other words, due to z-testing, the engine will always reject pixels behind a solid object..thus keeping your number of pixels actually drawn fairly low and consistent. However, with transparent polygons, the engine will need to draw over the already existing pixels with a new data..blending them. For each overlay of sprites the engine has to draw more pixels.. this can become remarkably slow if the engine must draw many large alpha blended sprites.

There is really not much to be done about this problem, except to try to always limit the number of sprites you needs to draw in any particalr areas(such as having a larger interval of time between smoke emmissions), and using lower res texture for your smoke sprites(often the quality is not affected at all.. use a 64*64 pixel texture instead 256*256 or whatever). I suppose on an engine level, there could be some way to limit the overdraw to a few sprite layers.

But fortunately, with modern cards this is becoming much less of an issue, and one easily avoided by smart level design.

ok ^^
i will try some changes and report back soon... thanks for all help! ^^

ok.. i really appreciate all help i got.. it maid me think.. the only real problem right now is that my mip-map don’t work at all.. O.O ...please help me with this.. because i just find out that my trees does not have anything with the high fps to do.. it is my terrain... -_- and i already thought that it was low resolution on closeup... =/ so i really thought of increasing its skin size.. but then i really need a mip-map that quickly makes it low resolution at distance... please help me... can any one list all script things you can change or add or remove to edit the mip-map?
and sorry that i did never respond until now. my computer has been broaken

how did you get the fps and all those other numbers on the screen?

simply press "f11" ^^