well basically, i've been hearing overrr and overr that A7 is slow, i've also been hearing that it can accomplish alot, i know it can.. the problem isnt what it can accomplish, its the amount of work that needs to be done to accomplish this which is the problem.. so anyways, i just made this thread so people can post hints/tips and pointers on what can be done to optimize and improve performance...

i also wanted to note a few things:

- in games like cod4.. the framerate ranges from 20-80 on my pc yet, theres never a bump.. its always smooth, what could they have done to achieve that

- battlefield 2142 runs less that 15 fps on my pc and once again, still smooth

- why does gs take so long to compile levels? what can increase that?

- i mean, if commercial doesnt have BSP, why does the compilation take so long

- scene optimizations

questions like these, basically, if you have an idea or know a common mistake that people make, just take a sec to write it down... it would help alot of users who compain about speed

which is faster, tracing from my weapon an detecting the texture/model type so i can do my effect or having an event function in each model that detects when its shot and runs the effect function?

This is a big question and if you really want a big answer, than you'll certainly get "it depends".

Optimization is another big thing. Optimizing a PC game heavily depends on the used technolpgy, the language and your expertise in it, your software engineering skills and game programming experience, the user's hardware, scaleability and especially the game and it requirements itself.

To hit the nail: you could even do a Pong game that is hungrier than Crysis, has more bugs than Gothic 3 and runs only on specific systems, has no performance improvement on high end systems with e.g. quadcores and SLI etc.pp.

I am sorry that I am generalizing here but optimization is such an abstract concept that you can't really satisfy anyone without knowing more. Better open new threads...

To answer your question about the tracing thing: it depends Both concepts are absolutely fine and will work but are you asking which one is faster - or from an engineering perspective better? I would prefer the second method, because every entity in a world should claim its own behaviours and needs. If a barrel for instance knows that it gets destructed on weapon or heavy velocity impact, than you design such an event (including effects) and let it triggered. So, if you drive with a car into that barrel or you make a sniper shot on the barrel, you just generally send a message to each hitted entity (the barrel) and the barrel will react.

For texture events I would group textures together and define events for this group, like for the barrel model.

I am not sure which method would outperform the other. You need in both cases a trace, so that isnt important. But evaluating a string (modelfile, texture) against a big table could be quiet a hassle (use hashes for this, in C++: std::map). Triggering the event is immediate without evaluation (maybe from the model's point of view... which trigger to take when you have abstract event concepts rather than just a single trace-hit trigger event), so.. should be slightly faster.

Nevertheless... such examples are not slowing down your game!!! Rendering, shaders, scene complexity and code execution are the most nasty bottlenecks. Don't get lost on easy things which doesn't make the difference.

thanks for the response heelx, i made this thread because sometimes i hear alot of people stating mistakes that people make alot and thought it'd be cool if people could repost them here...

also, in games like cod4.. the framerate ranges from 20-80 on my pc yet, theres never a bump.. its always smooth, any dieas on how to achieve this?

In general, for smooth movements/rotations, be sure to always include the system-variable "time_step"
into any calculation of distance-to-travel or change-in-rotation TO DO within this "frame".

And also be sure to always include the system-variable "time_frame" into any
calculation of distance-travelled or change-of-rotation THAT WAS DONE within the "last frame".


I cant be more specific that that, as actual usage varys widely depending on the formula that you have created.
This is a tricky part, but get it right, and things will move smooth regardless of "twitchy" FPS...

ok.. i have an idea but am not entirely sure what you meant with the time_frame usage

Simple.
"time_step" is a system-generated variable that gives the "expected" time to process this frame.
"time_frame" is a system-generated variable that gives the "actual" time to process the last frame.

My usage for time_frame was it you were trying to work out how far or fast something is travelling per frame,
then you should include "time_frame" in the equation to "smooth" out the differences between fast and slow frames.

Also, time_step is affected by a slow motion setting of time_factor, but time_frame isnt.

some general optimisation rules:

lock your framerate to max 60FPS. its the basic full screen monitor refresh rate. if a monitor is faster, good for you but 60fps are enough. you dont need to go faster than that.

use the right clipping. why do you have a clip range of 15 000 if youre doung a game with ingame corridors? you wont see anything anyway?

make sure you make unseen entitie pasued while not on the screen. the less functions, the better.

dont use hundrets of entities at once. group some in med if tehy are close together like a set of boxes for example.

dont use a model with hundrets of frames. A7 can interpolate. use that

use LOD. alot!

texture unseen surface sides in wed with the default texture. set it to scale 25 on x and y and to rendering flag none.

use wed only for rough level geometry. do all details with models.

dont use huge texture sizes if you dont need them. your enemy looks okay with a 512*512 texture if he doesnt stay close to your view all the time...

use good and clean code. bad code can slow you down alot...

same goes for shaders.

reduce the use of post processing effects. they are slower...

use LOD for stencil shadows.

only cast a stencil shadow on important things, like your player (if 3rd person). use the basic decals for everything else.

use pcx, dds or png instead of bmp and tga.

those are some general rules. they dont apply to all games. some of you will probably think im talking shit. or that 120fps are important. or that a models needs to have 3k polies but 400 frames and a 2048 skin. thats riddiculous. you dont need that shit. optimisation goes beyond reducing polies. its hard work.

im doing a few wrng things in my games aswell. like unoptimized code. or too huge models. im doing that mistakes. but im working on that too. you can get much more out of the engine if you know the weaknesses. like lightning building. the longer the compiling of the level takes, the better the framerate. its simple. just know your stuff and youre fine...

sPlKe very good explanation, looks like you have good experience
I also will try give useful info.

Do not use sprites for grass(there lot of grass), use single model. In some cases this trick do not work.

Models(mesh) rendered faster if has less number subsets (parts of the mesh with different skins).

Reset DYNAMIC flag for static models.

Configure some ODE(physics) value for good framerate. ph_fps_max_lock,ph_check_distance,ph_iterations

Set preload_mode to 3 if you do not want sudden 'jerks'. (In slow PC)

In manual not much info about rendering of level geometry, so I want to share my observations.
A7 commercial version render main level geometry without using portals so all level geometry that hidden behind the wall also will be drawn , so with this features you can not do big indoor level or use complicate pixel shader because you will get overdraw