[mitsubishi]

Here's an interesting feature,

Microsecond Definition support; it potentially increases efficiency of the engine and makes it possible to use any integer on com_maxfps; /sysMicroGranularity.

It's a rather experimental feature that might potentially do little to be usually noticeable. The theory is that better granularity of timing, microseconds instead of milliseconds, might increase efficiency of the engine. An interesting outcome is that currently it's used to throttle FPS with com_maxfps in finer granularity. As a byproduct, that makes it able to throttle on any integer since it's not restricted by 1000/integer anymore. It's also used scaled on milliseconds calculations though that was already what was being done for UNIX.

UNIX support of it is also in.

The var can be changed 'live'.

This post has been edited by mitsubishi: 06 August 2010 - 02:41 PM

[SubJunk]

Sounds interesting, Mitsu. What's an example of its use?

[Mod ObScUrE]

From Mitsu's networking guide.

Quote

The limitation when setting max FPS with com_maxfps
Now, when setting com_maxfps to presumably take advantage of the above information, keep in mind that FPS (visual and internal, same thing) is limited to values of 1000msec divided by an integer; this is because the engine measures frametimes using millisecond integers. So you can either set 125 FPS (1000/8), 111.11 (1000/9), 100, 90.9, 83.3, 76.9, 71.4, 66.6, 62.5, 58.82, etc. (without any rounding up.)

Quote

An unintuitive internal rounding up
Notice that the ceiling of the var is being rounded up internally in an unintuitive fashion: com_maxfps 84 goes to 90.090.. while 83 stays to 83.333...
i.e. com_maxfps 84 gives effectively 30.30.. packets per second since it puts effective max fps to 90.91.. while the correct value would be 83 to get 41.666.. since that is the com_maxfps value that will give an effective max fps of 83.333 which we'd want for lowering networking latency with the cl_maxpackets ceiling available.

So with the microsecond support it would be possible to use 84fps without the rounding up on 42pps.
sysMicroGranularity 1 or 0 to test it, as mitsu said it works on the fly.

Quote

The theory is that better granularity of timing, microseconds instead of milliseconds, might increase efficiency of the engine.

hopefully. :-)

[mitsubishi]

Yeah, that's an interesting observation; it does make cl_maxpackets more manageable too (it could potentially make it able to use any cl_maxpackets (below threashold) too but that might be a wider undertaking since time for the packets themselves may have to be kept by the engine in microseconds).

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:

Is there a guide on the /sysexec function ? If not, Is it possible to run a php script from within the q3ut4 folder with the /sysexec function ?

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

[Banned onemoar]

can you change it so cl_packetdup can be set to 0

as its just resending whats already sent the server should not care if its enable at all and would cut down on network spam

[mitsubishi]

That's forced by the mod/game (UrT). I don't override what the mod/game does even if it's possible as a 'polite policy' [*].

The client itself does not have the limitation (e.g. it can be set to 0 on baseq3).

[*] In cases, it unlevels the playground aggressively, e.g. UrT's max packets/s limitation.

This post has been edited by mitsubishi: 07 August 2010 - 06:59 AM

[mitsubishi]

ah look at that,



silly me, the integers were rounded up too bluntly; floats are much more precise.

coupled with microsecond precision, this makes extremely fine results.

files updated.
--
now also with floating point interval.

This post has been edited by mitsubishi: 07 August 2010 - 03:47 PM

[mitsubishi]

Motion Blur.

/r_motionblur 1
/r_motionblurStrength to tune the strength of the effect (up to 0.99)

It's relatively basic but it works.

--

It doesn't seem to be very applicable on low frames/s but hopefully, a trick might come up.
nah, it's good on low FPS, well, not as good as on 125FPS of course.
--
It's so basic that it even applies on UI.
--
simple example.mp4 [4.3M] ('Strength' 0.9, 25FPS; it feels much better when playing on high FPS though probably not very good for 'competitiveness')
--
It can be tuned on the fly.

This post has been edited by mitsubishi: 08 August 2010 - 12:34 AM

[<PWC>YAY5637]

omg xDD motion blur feels like drugs O.o HAHA :o ;P xD

thats why you shouldnt drive a car with drugs...

[mitsubishi]

Ye it's like 'simulate being drunk':P