I've noticed that r_drawflame 0 (used in some engines) will give me over 1400 fps on the start map using timerefresh, with flames on it cuts down just below 900. There are only 4 flames drawn in that room!
Are all the flames on the map being drawn thru the efrag drawing code or am i missing why 4 models kill 500fps?!
drawflame and timerefresh
Re: drawflame and timerefresh
it probably includes a 5th in the easy skill selection.
any engine that still uses fans/strips instead of drawing the lot in one go is transforming/interpolating/lighting each vertex up to 3 times, and messes up its cpu cache on every api call.
also if there are particle effects attached, then yeah, framerates will plummet.
]/r_drawflame 1
]timerefresh
0.024622 seconds (5198.631454 fps)
]/r_drawflame 0
]timerefresh
0.024011 seconds (5330.949493 fps)
fte still interpolates verticies on the cpu, but only once (yay for vertex arrays). lighting is done in a vertex shader. fte's model/backend separation is basically like q3, just the backend knows about glsl and model lighting is one of the things that is offloaded onto the gpu.
fte doesn't use vbos for models still. it really should be fixed to do so though as platforms like nacl would really benefit from it, as would 10k vertex skeletal models (though those are already positioned on the gpu).
any engine that still uses fans/strips instead of drawing the lot in one go is transforming/interpolating/lighting each vertex up to 3 times, and messes up its cpu cache on every api call.
also if there are particle effects attached, then yeah, framerates will plummet.
]/r_drawflame 1
]timerefresh
0.024622 seconds (5198.631454 fps)
]/r_drawflame 0
]timerefresh
0.024011 seconds (5330.949493 fps)
fte still interpolates verticies on the cpu, but only once (yay for vertex arrays). lighting is done in a vertex shader. fte's model/backend separation is basically like q3, just the backend knows about glsl and model lighting is one of the things that is offloaded onto the gpu.
fte doesn't use vbos for models still. it really should be fixed to do so though as platforms like nacl would really benefit from it, as would 10k vertex skeletal models (though those are already positioned on the gpu).
Re: drawflame and timerefresh
I must add r_drawflame to DirectQ and restore timerefresh (no front-buffer drawing in D3D tho... 
)
Some other possible causes come to mind here. Flames are static entities rather than dynamic, so depending on how you handle adding static entities to the visible edicts list you could find that you're adding each entity multiple times as frames build up. That would certainly hurt performance.
The cause here is that static entities get added during R_RecursiveWorldNode, which will get called multiple times during a timerefresh, but the visible edicts list is only cleared in CL_RelinkEntities. So if you have 5 torches in your scene, each frame will add an extra 5 torches in addition to those that have already gone before. By the time the final frame comes around you could have thousands of torches in your scene, but looking like there are only 5 as they'll all occupy the same 5 positions.
This is a slightly insidious problem because it doesn't show up so badly in normal gameplay, so you may not even be aware that you have it.
Putting a sexy particle effect on the model could be a bad idea here; depending on how efficiently you draw particles, of course. But my bet is on the static entity adding being the cause.
)Some other possible causes come to mind here. Flames are static entities rather than dynamic, so depending on how you handle adding static entities to the visible edicts list you could find that you're adding each entity multiple times as frames build up. That would certainly hurt performance.
The cause here is that static entities get added during R_RecursiveWorldNode, which will get called multiple times during a timerefresh, but the visible edicts list is only cleared in CL_RelinkEntities. So if you have 5 torches in your scene, each frame will add an extra 5 torches in addition to those that have already gone before. By the time the final frame comes around you could have thousands of torches in your scene, but looking like there are only 5 as they'll all occupy the same 5 positions.
This is a slightly insidious problem because it doesn't show up so badly in normal gameplay, so you may not even be aware that you have it.
Putting a sexy particle effect on the model could be a bad idea here; depending on how efficiently you draw particles, of course. But my bet is on the static entity adding being the cause.
We had the power, we had the space, we had a sense of time and place
We knew the words, we knew the score, we knew what we were fighting for
We knew the words, we knew the score, we knew what we were fighting for
Re: drawflame and timerefresh
Ok I got ya. If i just record a simple 30 second demo of me walking around the start map, and then timedemo that demo once with flames once without, im only losing about 10-20 fps with torches on.The cause here is that static entities get added during R_RecursiveWorldNode, which will get called multiple times during a timerefresh...
Phew!
Re: drawflame and timerefresh
Just got to test this more fully with DirectQ. timerefresh numbers are a bit different here because D3D won't let you draw to the front buffer, but they're consistently different so that makes them valid for comparisons within DirectQ.
Standard behaviour is:
r_drawflame 1 - 1175 fps
r_drawflame 0 - 1178 fps
If I remove the guard I have against entities being added more than once in each rendered frame I get:
r_drawflame 1 - 832 fps
r_drawflame 0 - 1178 fps (unchanged)
Standard behaviour is:
r_drawflame 1 - 1175 fps
r_drawflame 0 - 1178 fps
If I remove the guard I have against entities being added more than once in each rendered frame I get:
r_drawflame 1 - 832 fps
r_drawflame 0 - 1178 fps (unchanged)
We had the power, we had the space, we had a sense of time and place
We knew the words, we knew the score, we knew what we were fighting for
We knew the words, we knew the score, we knew what we were fighting for