I noticed microGranularity makes FPS indeed more stable when I try it on baseq3's cg_drawfps (urt's cg_ meter is a bit 'blunt' since it appears to be using server's time which is a bad idea according to latest baseq3 code comments since it doesn't compensate for server correction on timings, and this is about a client benchmark; it also makes /timescale not work on it properly).
cl_drawfps on ioq3-urt is a bit finer since it calculates each frame separately (cg_ ones use a short buffer) and now uses microseconds when micro granularity is on.
I now try to understand fully why it shows [throttling at] slightly lower fps on micro granularity, but that might be normal since also cg_ meter from baseq3 does the same occasionally.
--
blizakster, on 05 August 2010 - 05:03 AM, said:
It's very basic. "The way /sysexec works on Windows is with some acrobatics using CreateProcess() to avoid the new program stealing focus. For non-Windows it assumes system() will be enough by letting the user use some userland magic to avoid such stealing of focus. It is generally a raw method - especially on Unix - that may need proper care on what is being fed to it. e.g. Winamp (initial launching) or even ioq3 itself (a new instance of it) will steal focus from it by force even if they are instructed not to. This can be considered 'normal'. On non-windows it may require a shell method that exits right after execution, since system() itself halts the program until exit. Theoretically, even windows can be left requiring a userland program doing any focusing/unfocusing business but it allowed some handholding."
It executes what can be executed normally if it's given something in the path of the client or using full path on the command.
This post has been edited by mitsubishi: 06 August 2010 - 03:38 PM