I have 2 Big questions about “time for screen refresh and monitor sync” (ref on the debug/statistics panel)
What is really “time for screen refresh and monitor sync”?
How can I make it go faster? And what makes it go slow?

The reason why I asking this is because I have a game and everything on the
”ms/frame” part of the panel is about 1.5 to 0.0 .. and that sounds to me pretty low.. but my REF is on 45 O_O…
And as far as I know all on this list affects my fps allot?

One more question but this is little of topic but I did not want to create a new thread for this question I think is a very small one…
How mush does the reserved videomemory that is not used affect my FPS?.. because my game is sometimes using allot of models and allot of particles but often very few… and is there some way to get around this problem? (if it now any way affects my fps that mush that it is a problem)

"time for screen refresh and monitor sync" is how long in milliseconds that the cpu has to draw a single frame. After that frame is drawn then shown, the refresh will "refresh" or restart the drawing process again. This is also in conjunction with syncronizing these "frames" to the refresh rate of your moniter, 60 mhz, 80 mhz etc. Im sure theres a better explanation from the more knowledgable members of the forum.

First, try to stick to the "under 10" rule for any statistic in the debug panel. If the number reaches 10, then the drop in FPS becomes more noticable. You also have to weigh the worth of what is running and if its really worth it. Say for example the execution time for entity actions is 2.3ms in the debug panel. But say the only things that are running is the player action, and say 600 grass sprites using the "vec_dist" function every frame. If only the player and 600 actions are causing the 2.3 ms delay, youre going to have to cut down on the amount of grass sprites running the script, or produce a more efficient way of coding the sprites. This also applies to every other variable in the panel like the refresh time. (use smaller textures,lower polycounts, use PCX or DDS coming soon)

In reguards to the refresh being 45,

1. do you have alot of sprites or models with transparency (espesially tga images) on screen at once? Especially close to the camera?
2. Do you have alot of hi-poly models being visible at once?
3. Are you using Mip-Maps for your terrain?
4. Are the sizes of your textures for both models and blocks in the power of 2?
5. How many panels are visible, and what image format are they?
6. Are you running in window mode?(I think window mode produces a slower refresh rate than fullscreen)

There are ALOT of different factors that can increment the refresh rate, but we dont have enough to work with. Run your level and move the camera to the place(s) where you get the ref 45 in the stats panel. Tell us exactly what you see and we can help you more.

1. do you have alot of sprites or models with transparency (especially tga images) on screen at once? Especially close to the camera?

sometimes i have allot of smoke in the level coming from explosions. The smoke doesn’t infect any noticeable when i am at a distance... but when i come close the time goes up allot. (inside the smoke field) This is one of 2 problems it seems. But how can i solve it? i rely need to be able to have a smoke that the camera can enter. if the player is running away from the attacker and get allot of explosions around hem the camera WILL be inside the smoke O_O

and the time is often below 4.5 now... but there is one area it goes up to 15. And that area is felt with trees. To be more exact 8 trees. it seems like the time rises 1 to 1.5 for every tree visible in the screen. the tree has 64 faces and 512x512 skin.. Is it posible to ett that big difference in the refresh rate buy using trees like that? O_O

2. Do you have alot of hi-poly models being visible at once?

My game is cellshaded so the most entities have very small skin maps but often plenty of faces. a box in my game has 92 faces >.< but they don’t seems to make any big difference on the refresh time.

3. Are you using Mip-Maps for your terrain?

my terrain uses no mip-map because i don’t need any details on my terrain except al edges between different materials so the terrain skin is the only skin in my level that is big (2048x2048) >.< everything else except the tree has a skin size of 128x128 or lower like 32x32...


4. Are the sizes of your textures for both models and blocks in the power of 2?

yes... and i am using no textures...

5. How many panels are visible, and what image format are they?

no visible panels for the moment. but when the game is finished there will be 4 numbers visible counting different kills.

6. Are you running in window mode?(I think window mode produces a slower refresh rate than fullscreen)

Fullscreen...


and now when i use 1024x768 res and is right in the middle of an explosion the refresh time is about 150 for about one second and then goes down to 80 for one half second and then down to about 50 while the smoke is left... >.< this sounds extremely awful... =/ i probably need a complete new way o making explosions? =/

And thanks for the respond!

I've had the refresh time get up much higher than 150. It's also easy to reproduce as well. I had it at 180. When the camera is close to something, it really hurts this, don't know why. I was right next to a large chunk of intersecting, criss-crossing blocks off fairly odd sizes (96x96 block size using a 16x16 texture). I could sort of replicate this and make it more severe (like 400). It might be a bug in the engine (since 6.22), but can't say for sure.

"sometimes i have allot of smoke in the level coming from explosions. The smoke doesn’t infect any noticeable when i am at a distance... but when i come close the time goes up allot."

This definitly happens ALOT, especially when the camera is close to the particles and theres a GREAT mass of them. You dont have to right a new explosion effect, but probobly just tweak it to be more camera friendly. Well, lets see what we can do.

An idea that came to mind is to switch between 2 slightly different particle functions. Say for instance, if the camera is close to the smoke grenade or tear canister, you can switch to a particle effect that spews out fewer particles, but particles that are larger than the original particle effect. That way the particles can cover the screen just like your original particle effect, but if fewer particles since they are much bigger:

run a code like this in your grenade action:

my.skill54=vec_dist(my.x,camera);

if(my.skill54>=1000) // if the emitter is farther than 1000,
{
effect(Far_Tear_Gas,1000,my.x,normal); // use a particle function that spews out alot of particles. Its ok because the camera is far away and not in the cloud volume//
}

else // If not farther than 1000, we use the larger sprite particle effect

{
effect(Close_Tear_Gas,100,my.x,normal); // use a particle function that uses Larger sprites and a slower emission rate //
}

The larger sprites will substitute for many smaller sprites than the original mass particle effect. Of course the ref will be affected but not as bad as the original effect function.

2. You said your game is cell-shaded, so despite your GPU handling the load, your cpu still has to draw the extra black outline polygons, which to my understanding is no different than a polygon in the original model. The polygons will still need resources to sustain themselves.

I dont know how the cell-shader will handle LODs for your model if you decide to make LOD stages. I dont know if the shader will use the first LOD model, while the main model is using a lower poly version due to distance. Make a few LOD versions of your model, each with a LARGER drop in polycount than the last one.

You can also use trusty old vec_dist to remove the material when the entity gets past a certain distance, and reapply the material when he gets close.

my.material=null; // just make sure to change the lighting after

3. What you said about Mip Maps is totally opposite to what Mip Maps really are. What you said is called a "detail map", its a tiling texture that supposedly makes the texture look more detailed (never wanted to use it). A MIP MAP however is different sizes for your texture, each in decreasing detail, which is swapped in and out in run time. So you said that your terrain size was 1024x768. If you go into MED and into the skin editor of your terrain, go to "edit", then "convert skin". Then go to "add mip-maps". Now Med will generate 3 skins in decreasing size. So the first skin you have is 2048x2048, and MED will generate these next skin sizes:

1024x1024 then,
512x512 then,
256x256

After saving and running it in WED, your terrain wont run the full 2048x2048 skin, but use the smaller mip maps for the parts of the terrain that is farthest from the camera. What this does is ease up the burden off the cpu, which would normally draw the texture full at 2048x2048, but now is drawing it at smaller sizes, which should free up the refresh stat. Plus it gets rid of contrsted noise from complicated textures that are far from the camera, since they are blurred.

1: it is a really good idée... but probably there will be some times you as an player will notice this (for example if hw is moving towards to explosion.. the first explode and gets the distance to 1001 and the other to 900. and the smoke from the first is still left... then the player will se the difference.. but that does not matter that much.. but my game is going to be a multiplayer based game... is it possible to do this so different cameras have different emitters? because some times there will be network game and then the problem is not quiet that big.. but when you run split screen you have a grate problem with this technique >.<...


2: I have no shadier for my game because i want it to be able to run as good on a computer without a shadier. Or is there a shadier that can help me on a cellshading graphic without any kind of shadows in the level ore on the models.
And the multiplayer levels have no load because they are not quiet that big that it is necessary.
And yes the black line is handled as a normal polygon entity... so a cellshaiede model must have nearly twice the amount of polygons as the same models without black lines. but a normal cellshaded model just need total coloured surfaces and no details on many of the polygons so the skin can be rely small and then leave some videomemory instead ^^


3: ok .. really cool... I thought that mip-map was a repeating kind of transparent texture that was loped over the terrain. But what script should i change to get everything right.. Because i have seen some variables in the display wdl file about mip-maping.. O_O
And all i have to do is to create the terrain and a really large skin (like 2084x2084) and then press the mip-maping and then everything is ready? O_O

maybe it would get easier for you to see if any part of my graphic looks weird/ un necessary if you have a screenshot?... because i rely want to have a frame-ratio as high as possible with a graphic that looks kind of like that one i have...

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.

hmm.. i think i don’t need to send that mush information thru the network it is maybe time for me to tell you how my game is thought to become... it will be kind like bomberman in the main thoughts that you have one HP and can put out some bombs and get some powerups.. then i added the 3d plane to the level and the hole game with bombs gliding in tilting ground and added super weapons... that is the main thought of the game.. there is more to it but that is very simply described. The things i need to send thru the network is the player pan and posision and frame and if he is dead or not.. the bombs range and position and pan.. all boxes pos and HP.. and the powerups.. that is all i think^^ i expect to come up with more information needed when i create it.. but is it possible to send just a part of the information about a entity? Instead of sending the whole entity?

again to the explosion. i will probably not be able to have any changeing in the explosion depending on the distance... but it is hard for you to tell and help me without screen as i said before.. but i have no screen yet.. Because i have no place to host it... and i have a movie that probably would be better because you easier can se how the explosion is moving...

i did not really have any problem with the cellshading.. just with the trees... i don’t under stand how they can be that power expensive >.<... i can show a screen of the model when i fins some host
but any way thanks for the good ideas and you grate arrangement ^^
^^

The mip-maping sounds really good ... how big can i have the biggest texture if i use mip-maping? I realised that 2048 was the biggest I had afford to use before…

and yah.. if i could change the system i would have removed everything dealing with shadows and the BSP.. because i just use only models and terrain because of the bad flat shading and hard edges...


and one thing about the grass in the distance... it is not needed.. if you create a system that create grass just where object come to contact with the ground and on and beside all shadows you will have this feeling.. not perfect.. but the human eye easy hinds sharp edges.. so if all edges where there should be grass is grassy then you will have a hard time finding out its not gras everywhere.. but this is a bit hard.. i have tried it.. but just bringing it up.. you would probably succeed better then me .. you seems to be a better scripter then me ^^

it is not the finished graphic.. but it will be something like this... ^^

Wow! 48!? That is awefully high. ... and 10 ms for functions? That seems a little high for script execution. I've had mine clear up to 180, nearly four times that and no where near as complicated as yours. I think it might be a bug with the engine, but can't say for sure. Screen refresh should never get above 16.6 ms for 60 fps. The numbers could be misleading. That is, a calculation involves the wrong variable. I think the calculation should be made toward either the ent, or fnc items, most likely the ent.