[RandomTiger]

Some if you may have seen something like this before.
If you have take a look at the code because I know I havent got it entirely right yet.



Basically the bars represent the amount of progessing time spent on everything that needs to be done to prepare and render each frame. Using carefully placed code you can use different coloured bars to measure different bits in the code.

I believe in the above pic green is graphics code and red is everything else.

To activate it you have to put TIMEBAR_ACTIVE in the main project and dependancy code settings.

[phreak]

is that in DX8?

[RandomTiger]

Good question. No, its just in the main branch.
I should have mad ehtat clear.

[Fry_Day]

so that's basically integrated timing code like Good ol' Zen Timer for DOS?

[Bobboau]

so what is this?

[Fry_Day]

Bobbau, by using that code, you can measure how long each bit of code takes during runtime, and know what needs the most optimizing (If input takes 4% of the processing time per frame, it's not worth optimizing, since the gains would be marginal, yet if it takes 20%of the processing time, it's a totally different story)

[RandomTiger]

When you see it running you'll get it.
Its soo much better than numbers.

Also the code is quite cool because its not DX specific, it takes a function pointer to the draw code so you can set it up to run in OGL or even Glide.

If you want to optimise you will want to use this feature.
Also its useful for checking new stuff you are putting in itsnt bringing hte framerate down too much.

Theres lots of things that could be done to provide more functionality. An averaging mode would be good for identifing 'spikes'. Spikes are large amounts of processing in a very small time, usually a sign your engine is doing something at run time that should be done at load.

This tool seems to be standard practice for most games and real time graphical systems. NASA guy used to have one for his stuff apparently.