proquake *optional* replacement textures support

[R00k]

I remember up until maybe 5 years ago Frenzy always used 320x240x8 with wqpro.

On a similar note, i think ProQuake should use the square particles found in DosQuake. The circles of original GLQuake look kinda odd.

[killingtime187]

baker -

note that i emphasized "optional" in both the topic and throughout the thread. i don't think the original quake shipped with a mp3 player, but you're fine adding that in as an "optional" feature. as i said, proquake, out of the box default can look like "and" sound like original quake. but ... if you want the same quake play feel but with enhanced sound and textures, you can, again, optionally, add those. but anyway, as the other guys are saying ... it's your ship ... just asking ...

[Syluxguy28O3]

i think i might make a poll relating to this.

[R00k]

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

[Mindf!3ldzX]

Fitzquake MACH 5 could be what it gets called r00k

[R00k]

Oh you mean This?

mach 5 = 1 701.45 m / s

not this?


Mark 5 - Wikipedia, the free encyclopedia

So this version goes fast not "drives the demons out of" Fitzquake....


OH that damn filename lied! fitzquake_mark_v.zip

[killingtime187]

lol. rook - mh msg'd me that raw input is coming, so i guess it's not there now. dinput is ancient apparently and even msft doesn't recommend using it any longer:

While DirectInput forms a part of the DirectX library, it has not been significantly revised since DirectX 8 (2001–2002). Microsoft recommends that new applications make use of the Windows message loop for keyboard and mouse input instead of DirectInput (as indicated in the Meltdown 2005 slideshow[1]), and to use XInput instead of DirectInput for Xbox 360 controllers.

so, either xinput for xbox or raw input for pc's is the way to go ...

[Mindf!3ldzX]

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

[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.

[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

[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?

[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]

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

[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.

[R00k]

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