OH NO!!!.... LAG-BOMBS!!! Well at least thats what they called them during my old counterstrike days. The smoke bombs almost always caused some sort of lag, especially when the host had a mediocre connection speed.
1. With the change in emission speed if the player ran towards the smoke cloud, you may have to make the distance very large in which the explosion would switch effects. Take the player's speed into account, so if the player is running at full speed, make the distance very large since the player will traverse a large distance while running.
I dont have any idea as to tackle the split screen issue, let alone the multiplayer aspect of trying to tackle this effect. Maybe you can look into "effect_local" in the manual for making different effect clouds for different systems. This way you can run a different effect than the other computers (this saves the computer from having to send particle positions to the servers/computers. This slims down the size of data packets, which is good for speed)
2. With your cell shading problem, I think you have more control over the effect since you arent using shaders. Programming a shader, let alone changing the shader during runtime isn't for newer users. Well what you can do is seperate the "black outline" model from the original model. Make the animations in your original model, then save, copy the model file, and color the new model black(flip all normals so it faces inside, you probobly know that already). This will be the outline part. Make sure it has the same animations as the original model file. Then you can attach the outline model with your main player model by script. Make a script for the "outline" entity like this:
action Player_CellOutline
{
my.passable=on;
while(1)
{
proc_late();
vec_set(my.x,player.x); // place the outline exactly where the player is
my.frame=player.frame; // sync the player animation to the outline
my.pan=player.pan; // copy the same angles
my.tilt=player.tilt;
my.roll=player.roll;
////// This chunk of code should be used for non-player characters(NPCs)
////// since they will be moving away/towards the camera. We dont have to draw
///// their outline all the time.
my.alpha=50000 / (vec_dist(my.x,camera.x)); // this code adjusts the outline's
// transparency by distance. Change the 50000 to adjust for your level size.
if(my.alpha<=1) // if the outline's transparency is under 1
{
my.invisible=on; // Remember to turn invisible on, because this is one of the
//ONLY ways to keep the entity from being rendered. This frees resources.
}
else{
my.invisible=off; // the alpha is greater than 1 so draw the outline
}
////////////////////////////////////////
wait(1);
}
}
3. Well yes, technically everything is ready once you add mip maps. Once you do, run the level and you'll see that the farthest parts of the terrain are blurry, because the MIP MAP system is substituting the lower res textures (I especially like this system, and hope to have more control once DDS arrives). This definitly does free some refresh I'm sure, but I dont think its friendly for memory used because your model now has extra skins in its model file. But the payoff is good, and the visuals help.
Yea sure, post some pictures, and make sure to detail almost everything about the image, such as:
listing things from the Statistics menu. Some important ones are:
1. how many entities are being seen by the camera
2. How many kilo-polygons are being drawn
3. Memory used by entities/sprites/video
Detail if you have an FPS_MAX in your main function. This can cause some slower refresh time from some tests I've done. Tell us the amount of polygons for each model visible, the size of each model's skin.
But just remember theres always going to be give and take when it comes to getting one statistic better. For example, Ive been working on a grass system that spawns grass in realtime, but at certain places. Its a mix of the random generated grass, and placed grass, so I get best of both worlds. However I have to give up the ability to see grass from a great distance, in exchange for fading in the grass at closer distances. Its great for an FPS game, but its not good for a racing game since the camera moves very fast(objects will fade in too late, and the car may hit the object. GTA anyone?)
My trees use almost the same system, however they take turns in tracing towards the camera. If the tree hits a "cull box", the tree wont be visible. This saves resources when a mass of trees are behind a wall. Normally the current BSP system wont cull entities that are behind walls, so this removes trees from sight if the camera stays in once place a little longer than usual. Great for on-foot games.
Since we dont have any access to the source of the engine or rendering DLLs, we wouldnt really know how to tweak the engine to suit our game. Many professional companies will change/adjust their supplied engine, or even write an engine from scratch to suit their needs. If we needed a large open air game, we would discard the BSP system for OCT tree, and if we needed a close quarter game such as DOOM, we would use BSP.
