proquake *optional* replacement textures support

[Baker]

baker swears that vsync off and getting the most fps you can get it = better gameplay, especially improved shaft aim.

Probably anything above 160 fps is unnecessary and definitely above 250. Above a certain fps, an uncapped NetQuake client like ProQuake will network lag itself (like pq_maxfps 9999 and connect to a server).

Just pointing out there is a limit to that.

The *only* reason this is true (high fps = better LG aim) in a traditional NetQuake client (ProQuake, GLQuake) is that the code has mouse input and network and client-side physics (single player) all tied together ... which ideally it shouldn't be.

[FTEQW and DarkPlaces and modern Quakeworld don't have them tied together. DirectQ as far as I know untied the link between input polling and frames per second. This means DirectQ will poll your mouse the same (like as in fast, fast ...) no matter your frames per second. MH could confirm this, I'm only about 85% certain of this.]

[killingtime187]

spike -

i see the following:

Maximum pre-rendered frameslimits the number of frames in DirectX games that the CPU can prepare before the GPU processes them. During gameplay, a higher number can provide smoother gameplay at lower frame rates, while a lower number can remedy slow responses of input devices such as mouse or keyboard.

you said reduce the number, but to what ? 2 to match gl ?

i also heard that setting vsync on might help stabilize things and produce consistent results. but i've also read a post somewhere else where baker swears that vsync off and getting the most fps you can get it = better gameplay, especially improved shaft aim.

i would really like to put this particular issue to bed and post here once and for all that if you do "this and this and this", you're guaranteed consistent results input-wise -- i.e. assuming the engine does its job correctly, your input should be always sitting there for it to pass along to the server ... no missed input. of course, there are other things in play such as net, gfx, snd, etc ... but if we can say ... "this is the best you can do to ensure consistent input", then i think this would be fine. everyone here knows that dumbing down the gfx, snd, etc can improve performance and speed of the game, but having the fastest system on the planet is useless if your input does not get through.

[Spike]

@killingtime
regarding your directq input latency, try reducing the number of backbuffers used in your graphics drivers settings or whereever it is.
glquake has a limit of 2, while d3d tends to use 3 or more.
this is the cause of my personal hatred of d3d (in general, not directq), in that it'll quite happily buffer up a second's worth of video before actually displaying any of the frames. makes it really hard to play like that!
I really don't remember where that setting is either, sorry.
anyway, end rant.

[Baker]

FitzQuake only supports replacement textures for maps.

[Mark V also supports replacement textures for .mdl models. It does support locs.]

[killingtime187]

Ok, fired up fitz and a couple of things ...

1. texture replacement works

2. hud/font does not or i dont know how to get them to -- i've tried putting the files in both gfx and textures folders

3. pq team binds not working ? %l %a and so on

i've been trying dq, but noticed some input lag on the mouse side -- movement and firing, that is not present in pq, or at least not as much. i play at my monitor's max/native res -- 1920x1200 - and my vid card (gtx 460) can more than handle things. i have this fancy gaming mouse that polls at 1000 (can set to lower values like 500, 250, etc). im not sure what's the right balance here ... i read a comment by MH suggesting that fps should be some multiple of mouse rate, which i need to try ... in my case, at a 1000 rate, my maxfps should be 1000+, or i can drop the rate down to 500 and set fps to 1000. again, the goal is to ensure that i never lose any mouse input op while all the other stuff is going on.

[killingtime187]

Baker -

Interesting! I'll fire it up and see how it goes.

Thanks

[Baker]

if FitzQuake mark V had pq features......

@ Killingtime.

Actually ...

FitzQuake Mark V has virtually *EVERY* ProQuake feature. And external texture support. Ping in scoreboard, mostly fixed networking code, demo record at any time, loc support (I think). http://www.celephais.net/board/view_thread.php?id=60831 Also has several features no other engine has. You'll have to read the readme, I did like 75 modifications to the engine in 3 weeks and I really don't remember too much except it was damn thorough work and seems to be used by a fair chunk of Func_Msgboard.

Something to consider ... (!!!)

/I engine code so much I forget about that kind of thing.

[killingtime187]

rook - yea, i think it's 20 frames/sec right ? what's the client side setting for this ? cl_maxfps ? anyway, if i get my 20 frames per second faster than the other guy, i do have an advantage right ?

[R00k]

the server reads client input based onthe ticrate so its standard for all players

[killingtime187]

mindz - not sure if a variable will make any difference. looking through the code some more, it looks like it's all single threaded with the engine doing a bunch of stuff "per frame" including submitting data to the server. i think the speed of this "per frame" execution and how many it sends to the server affects responsiveness. again, a question for the engine guys. i think the ideal setting is determining what is this optimal number of frames to send to the server for perfect netquake play and, i assume, most clients and machines today can easily meet this number. but naturally, whichever client gets their data to the server first wins -- eg. i fire, you fire, at say, the exact same instant, but your engine processes the frame faster and delivered it first to the server ... you win (assuming our network conn to the server is pretty much the same). so, setting aside network latency, ideally, ensuring that my per frame execution including net send is the best it can be since i can't do squat about my isp connect and route to the server is the goal. having faster gfx, sound, input (mouse,kb) naturally all help to improve how fast my per frame processing completes ... so any type of processing on this side that would help ... ex. raw input and so on can only help in addition to providing more precise aiming.

[Mindf!3ldzX]

all of these mouse variables, who knows maybe there is a diamond in the rough waiting to be set free, through better mouse support :F

[R00k]

ok, i played like 2hrs of tdm last night with directq and i noticed the following, which is the *same* for all clients *except* proquake -- there is definitely an input lag when it comes to the mouse. as mentioned, i move and aim better with pq and hence, do better in games. i did do alright last night, but it could have been better in fights where getting off a critical shot is a matter of winning or losing the match. anyway, with this suspicion in mind, i decided to look at the pq code for mouse handling and i found this:

// create thread
thread = CreateThread (
NULL, // pointer to security attributes
0, // initial thread stack size
IN_SMouseProc, // pointer to thread function
NULL, // argument for new thread
CREATE_SUSPENDED, // creation flags
&threadid // pointer to receive thread ID
);
if (!thread)
return;

SetThreadPriority (thread, THREAD_PRIORITY_HIGHEST);

i'm not an engine coder, but it looks like mouse handling in pq takes the highest priority over everthing else in the game -- drawing, sound ... all second fiddle to the mighty mouse input! indeed, for a fast paced fps dm game, this is definitely very critical.

engine coders out there ... feel free to comment

This is also in Qrack, its internal mouse acceleration via software.
It requires directinput to work. (m_directinput 1;m_smooth 1)
I dont recommend using this. It makes the mouse feel delayed.
unless proquake uses that by default, then this might be why pq feels different to you.

[Mindf!3ldzX]

a quick question about your controller:

did you get one specificaly for pc, or did you have a normal one that you adapted. just curious.

Sure, I use a basic "Neo Joytech" Xbox360 controller for PC, and it requires 1 or 2 drivers to get it working. That help?

[killingtime187]

ok, i played like 2hrs of tdm last night with directq and i noticed the following, which is the *same* for all clients *except* proquake -- there is definitely an input lag when it comes to the mouse. as mentioned, i move and aim better with pq and hence, do better in games. i did do alright last night, but it could have been better in fights where getting off a critical shot is a matter of winning or losing the match. anyway, with this suspicion in mind, i decided to look at the pq code for mouse handling and i found this:

// create thread
thread = CreateThread (
NULL, // pointer to security attributes
0, // initial thread stack size
IN_SMouseProc, // pointer to thread function
NULL, // argument for new thread
CREATE_SUSPENDED, // creation flags
&threadid // pointer to receive thread ID
);
if (!thread)
return;

SetThreadPriority (thread, THREAD_PRIORITY_HIGHEST);

i'm not an engine coder, but it looks like mouse handling in pq takes the highest priority over everthing else in the game -- drawing, sound ... all second fiddle to the mighty mouse input! indeed, for a fast paced fps dm game, this is definitely very critical.

engine coders out there ... feel free to comment

[Syluxguy28O3]

haha, quake on a xbox 360 controller. BLASPHEMY!! I save the 360 controller for racing games or fighting games.

Glad to hear DirectQ is getting mouse enhancements :FFFFFFFFFFFFFFFF

a quick question about your controller:

did you get one specificaly for pc, or did you have a normal one that you adapted. just curious.