Urban Terror Forums: Optimized .exe; builds of ioq3 engine - Urban Terror Forums

SubJunk, on 21 July 2010 - 11:33 PM, said:

For me it works on 800x600 with Razer D3g 1800dpi on UrT 0.8 sens with windows default driver.
there is no sensitivity difference in the main menu.

Quote

I think you are used to the positive acceleration better you test it with a ruler (raw input is not affected from windows pointer ballistics or software simulated acceleration).

Quote

iKALiZER is better for positional sound when your system can run it be happy. :-)
dmaEX is a improved version of the default sound engine with good performance.

This post has been edited by ObScUrE: 22 July 2010 - 02:28 AM

ObScUrE, on 22 July 2010 - 12:57 AM, said:

Yeah, you're right. That was it. So I have gone back to using the normal mouse system since I like acceleration.

This post has been edited by SubJunk: 22 July 2010 - 02:45 AM

So far so good.
On my rig latest 190710 (both) are working much better then previous version.
But.
Game looses smoothness directly proportional to intense of gameplace.
At the first go it was terrible. Now is muuuch better.
So the first approach i can treat as accident and computer depended issues.
During fast gameplay its like loosing fps (fps-meter doesnt confirm my feeling).

And there is something wrong with changing weapon animation.
Sometimes it looks like it doesnt work at all and I dont see weapon after changing.
Im not sure if changing was performed.
But its very early observation and im not sure. It can be razer issue maybe.

This post has been edited by Juno: 22 July 2010 - 09:52 AM

update with r_windowPosition. It mostly aids in case one uses r_noborder.

r_windowPosition    "0,0"   // comma separated window position when r_centerWindow 0. It's mostly usefull when
                            // r_noborder is 1 since in that case taskbars can be accommodated. It's ignored when
                            // r_noborder is 0 + it's on "0,0" to not be messing with 'draggability'.

[it uses an SDL env var as r_centerWindow did]

--

also that previous 'tweak' is removed since it did nothing.
--

new var takes some tweaking, e.g. working even with r_noborder 1 (weird crash occurs currently if I attempt it (via a method that still ignores it if it's on the default value, a 0,0 border window can't be dragged necessarily) that doesn't happen on a debug binary (weirder)) and perhaps being able to be overwritten by ENV but that's probably not the "convention" since r_centerWindow (which also uses ENV) doesn't do it.
--
Oh silly me, the fix was easy. hm.
[done]
--

OK fix,

now r_windowPosition does get to work on r_noborder 0 too; it only gets ignored on 0,0 when r_noborder is 0 since in that case it'd be losing the ability to be dragged in many window managers (mainly because the value is the default) (plus it's an easy way to retain the 'random window positioning' behavior).

--
oops, misuploaded; fixed.

This post has been edited by mitsubishi: 23 July 2010 - 01:52 AM

After some time I decided to update to latest version, everything was OK until server loaded ut4_paris.
Serious rendering problems on this map, completely unplayable with jagged triangles everywhere...


... back to ioq3-1778-urt-020310.exe for me

root could you test if it happens with the vanilla renderer build or test r_simpleshaders 1 & 0 setting on the regular optimized build?

Yes, I have in gold letters 'bumpy is relatively unstable check vanilla renderer too'.

Thanks for this report though, very useful at this stage. See if it is the same on TwentySeven's client and report it there. It might be important for 4.2.
--
(it appears ok here)
--
yes, r_simpleshaders might be important to be checked on 0 and 1 (/vid_restart or restart needed) since it's different from the upstream default.

This post has been edited by mitsubishi: 23 July 2010 - 01:26 AM

yes, the bug is present in TwentySeven's client. And yes, tested vanilla version and it's still there.
Tried turning different options on/off, but still get this problem.
This is only map I have this problem, so far I have played ~20 other maps without any problems.

Will report it in the other thread...

Edit: This is some driver or GFX card issue, I now have same problem in all 3D applications (be it DX or OGL)

This post has been edited by R00t: 23 July 2010 - 02:08 AM

R00t, on 23 July 2010 - 01:58 AM, said:

overheating

ok this update took way more time to do than it deserves due to its relative uselessness unless you're testing something one-off but here it is anyway (I was almost ready to delete it:P)



as usually,
/cl_drawmouse 1 //see it (it requires a map loaded)
/cl_drawmouseinterval 0.08 //interval it waits to calculate
/cl_drawmouseposx //pos x on screem
/cl_drawmouseposy //
/cl_drawmousesize 7 //font size

(updates/sec, dots/sec, total dots for an interval and max dots)

--

It's basically a 'mouse stats meter'. It works on raw as source or if on non-raw whatever sdl sends (something particular on unix, either mousemove or directx on windows depended on in_mouse).

--

also, cleaner console, safer and more informative rawmouse, fixed stats meters to work properly on timescale (unlike cg_drawfps:P).

This post has been edited by mitsubishi: 23 July 2010 - 06:22 PM