[fda| ObScUrE]

Ultradie, on 06 November 2009 - 12:47 AM, said:

For some odd reason, When I alt-tab out, it freezes my mouse out-of-game (and I have no control over it), Then when I get back ingame, I get an error that spams my console all the way: Com_QueueEvent: overflow

yes the mouse cursor moves to the upper left corner.

[Maj]

ObScUrE, on 06 November 2009 - 01:17 AM, said:

yes the mouse cursor moves to the upper left corner.

For me, this build has several issues that don't exist in ioq3 or ioUrT.
Sound continues while minimized (ioq3 has a cvar to fix this in the trunk)
The mouse gets locked into the corner with in_mouse -1
OpenAL errors get continually dumped to console.
fs_homepath is located differently from ioUrT


If you want to make an optimized build I'd really recommend grabbing 27's source (as messy as he says it is) and build with your optimizations in it.....maybe with a few patches like the the new quakelive mouse acceleration that was checked into ioq3 and possibly ikalizer. This way people get to play with 27's glsl stuff too particularly r_vbo to eliminate those pesky vertex arrays.

[mitsubishi]

Updated to SVN1735, an error produced was commended out, SDL and OpenAL DLLs changed to official versions (reverted, apparently they have issues with latest versions found on ioq3's site being more stable).

It doesn't fix the mouse stuck on screen on minimize etc. problems.

latest SVN patches are a bit of a mess as someone in their irc channel admits.

some issues could be related to optimization options but not sure. i may investigate.

If you can't handle the new ioquake3 config path better stay away from ioquake3. cba'ed changing everything or returning to iourt for it when it offers a codebase of patches more than 2 years younger.

as for 27's patches, I don't think it'd be that decent according to their apparent intentions to make them easily public, and the source - in a latest version - is probably not even available to begin with.



ok the mouse stuck on screen and a console spam after returning from minimize aren't fixed by a debug non-optimized version. i may try gcc or intel compiler. but i guess i shouldn't ba'ed if performance is lower.


the gcc builds retain the mouse and spam issues with no optimization options. but i may try some benchmarking to see what wins, if any.

so far gcc slightly slower - as expected. i may try some more optimization options in case.

whatever I try, fps is about 2% lower, I don't see much future in this (gcc).



ok whatever, my gameplay is very smooth with it (what is available) and i cba'ed if it's slightly spammed (in console) or if mouse isn't perfect on minimize. for the moment. hope it gets fixed soon.

This post has been edited by mitsubishi: 26 November 2009 - 03:56 AM

[mitsubishi]

Ok I tracked down the problem to windows lib built-in-SDL (used on -1) to be creating [the stuck on top left screen corner] so I reverted to the most recent version of SDL DLL in zip. I also commended out the warning spamming the console.

zip updated (in original post) to SVN1737 (latest) + the above changes.



btw - and I updated the original post about it - autodownloading's var can't be directly defaulted to 1 since it is returned to 0 - in an initial install only - by the pk3's of UrT (because the mod had tried to disable the old version of autodownloading which had the same var name). It can be hacked to use another var but it's probably minor and it may be a source of a mess. but I could try it next update if there's anything decent to update with additionally, if there's next update.

This post has been edited by mitsubishi: 07 November 2009 - 05:05 PM

[fda| ObScUrE]

Now you get the typical console problem.

source ioquake3

Quote

I can’t bring down the console with the ` or the ~!

This is due to a yet to be resolved issue for which we have a funky solution. Press Shift+Escape at the same time, this will bring down the console on any system.

Here my results with /timedemo 1 (same config).
Original UrT = 55,8fps
SVN1737 = 63fps

[mitsubishi]

ye, that's about 13% increase. It generally shouldn't be expected to be 80% increase or something - unless one heavily alters the game code itself related to rendering and perhaps other operations.
In fact, 13% sounds a lot, even 5% should be generally a good outcome.

the main point for me of using a recent code base and recent building tools is not only FPS, I also trust them more for having stability and smoothness in operation (plus perhaps speed ups in FPS-unrelated parts of the program, e.g. map loading); recent versions also work on bug fixing (not only on features; well, depending on the people or project the ratio may change) and new systems in hardware may require new software. Sure a very new version of a tool or code base could have its problems but I think the alterations are probably worth the risk - and one could revert to a recent version working or tweak it to work anyway. In the case of ioquake3 this is very prominent because - regardless of using latest building tools - the edits on the source code since ioUrT was released are immense in quantity; and they are generally good coders in my opinion there - though granted they don't work on it 24/7 apparently. it takes its time. (Plus they seem to be - and officially - more inclined to bug fixing and careful - non mod-interrupting - feature adding than to blindly feature addition.)

This post has been edited by mitsubishi: 07 November 2009 - 06:01 PM

[mitsubishi]

zip file updated.

- All occurrences of allowdownload are replaced with autodownload so no var has to be newly set for autodownloading.
- Reverted a fix to 'dir not being made' error since they fixed it on ioq3.
- SVN to 1738

This is a very minor edit to anyone that has it working already.






update: they entered a serious bug in ioq3 current code for urt's everyday functionality (demos aren't found) so no new update. but it wouldn't be that important to begin with anyway (and it probably wouldn't warrant an update at all) so no worries.
update2: oh it's fixed now after a bug report.

This post has been edited by mitsubishi: 11 November 2009 - 12:17 PM

[mitsubishi]

ok that's an interesting update for me:



cl_drawping 1 draws Ping (dah), average Ping for the last 4 seconds, average ping for the last 20 seconds, max fluctuation of ping for the last 4 sec, max fluctuation for last 20sec. "Last" is a bit loose here since it's not really last, it just zeroes/resets every 4 or 20 seconds accordingly.

also included here is cl_drawclock like in iourt but without seconds this time, I find them distracting.

The reason of using cl_drawping is for troubleshooting/investigation of stability of ping, I always wanted to see the fluctuation directly in a number. It could also be included in the cl_drawnet vars but I find them nerdy and I wanted something more friendly to use:p

zip updated (in original post)

also SVN updated to 1751
a warning spam fix was reverted since it is overcome by the change in DLL.

[mitsubishi]

added cl_drawpingfontsize to adjust font size of drawping (in same zip, updated)

it now draws from the very top left and goes on to the right, I hope it doesn't distract anything there, I didn't find any. also it trembles a lot if ping fluctuates from 90 to 100 (from 2 digids to 3 digits) but whatever. I guess I'll have to read com_sprintf a bit



edit: small update (on zip), it now doesn't 'shake' if ping jumps from 2 digits to 3 digits. yes, i read sprintf's documentation

This post has been edited by mitsubishi: 12 November 2009 - 01:17 AM

[Merkymerc]

mitsubishi, on 11 November 2009 - 06:43 PM, said:

added cl_drawpingfontsize to adjust font size of drawping

Thank you

[mitsubishi]

you're welcome.



I now wonder whether I should remove it checking the 'low side of spikes'. I mean, isn't that a good thing? and in fact it probably won't have 'low spikes' since the checking is done against the mean values. It's probably a waste of resources and it probably doesn't change the outcome 98% of the time. That also brings to mind it may not be a completely reliable procedure since a very large spike may create many "low spikes" but those won't be really spikes 'cause it's only checked against the mean value but what can you do. It should be more reliable on the 20second mean value anyway.


edit: ok, changed on zip with that commended out. I now wonder whether I should have vars that define the "4 second" and "20 second" parts to be user defined but I worry that that may create a flood of new vars so I think I'll leave at it now.


some unreliability comes in the form of TS where a very large spike comes by default every round change so the means may change rapidly but it shouldn't be a big problem since 4s cycle refreshes fast and 20s isn't affected a lot.

This post has been edited by mitsubishi: 12 November 2009 - 12:50 PM

[Merkymerc]

mitsubishi, on 12 November 2009 - 06:27 AM, said:

edit: ok, changed on zip with that commended out. I now wonder whether I should have vars that define the "4 second" and "20 second" parts to be user defined but I worry that that may create a flood of new vars so I think I'll leave at it now.

Sounds like a good idea to me. But that's all up to you If you did change it so users can define the seconds, would it be foolish of me to set 20 seconds for the short part and maybe 5 minutes for large part, would that use too many resources?


My aim is better today. I've continued testing with ut_timenudge set to compensate for flux (average is 10 for me) and haven't thought "hits!!" yet It hasn't seemed sluggish while using timenudge either; sometimes using timenudge makes my movement feel slightly delayed (maybe had it set too high?).. I wish there was a more consistent way to test if this helps or not :\

This post has been edited by Merky: 13 November 2009 - 07:23 PM

[mitsubishi]

done. It now has cl_drawpingfirstinterval cl_drawpingsecondinterval to set the 1st and 2nd intervals in seconds respectively.

(zip updated on 1st post)

Merky, on 14 November 2009 - 12:53 AM, said:

maybe 5 minutes for large part, would that use too many resources?

well, that's good point, it may overflow the integer.

but I set sums now to "unsigned long long int" so it should take a while before it fills:)



edit: btw, any computational resources (in the interest of increasing FPS) this uses are completely eliminated if the var is set to 0; its calcs simply don't occur if it's not shown. btw, this is a similar behavior with other 2d resources so e.g. theoretically performance is increased if lag meter isn't shown.


the line isn't shown on window mode, it's simply covered by the window bar on top for some reason, I may have to fix it at some point, it only worries me that below clock is demo recording and it'd have to go even lower.

I guess I have to update the source at some point; or ask if you need it. I suppose it's not that important to most that's why I don't update it each time (it takes way longer to upload).


btw I use now 1 and 2 intervals, it's pretty good.

This post has been edited by mitsubishi: 13 November 2009 - 09:55 PM

[mitsubishi]

I thought about it a lot and realized this could use standard deviation of ping.



Standard Deviation is a common statistical result to show "How far most of the samples are from the mean value". So if standard deviation of ping is 10 this means "most pings are 10 msec apart from the mean" (assuming a normal distribution of results (most cases of results in nature)).

So, this may be a more secure way to set ut_timenudge from, though that may be open to debate.




forgot to say, zip updated (in 1st post) to SVN 1752 with that change in drawping in it.

("funny" story: I spent hours trying to figure out how to collect data (for standard deviation) with "dynamic arrays" (actually pointers) in C, had to go through a HELL of malloc and realloc checks (to avoid memory leaks) (and were convinced C is a stupendously deficient language compared to newer ones when it gets to dynamically enlarging array-type elements) and then I realized it wasn't needed! I could just sum up like making a mean value . Sometimes stupidity takes hours to manifest )

This post has been edited by mitsubishi: 14 November 2009 - 07:39 PM

[QA RS| SubJunk]

Thanks for making this. Gonna try it out later