ProQuake 3.82 (Unofficial)

[=peg=]

I myself use a standard qwerty (dutch/usa) layout keyboard, but the keypad (numpad) does not work correctly.. that is: with automatic keymapping [off] it does not work at all (cl_keypad [0/1] does not make any difference) and with automatic keymapping [on] it maps the wrong keys in chatmode.. it does work correctly in console tho.. using latest build (3.85)

i think the azerty layout did work fine in console too but not in chatmode..

[Baker]

I myself use a standard qwerty (dutch/usa) layout keyboard, but the keypad (numpad) does not work correctly.. that is: with automatic keymapping [off] it does not work at all (cl_keypad [0/1] does not make any difference) and with automatic keymapping [on] it maps the wrong keys in chatmode.. it does work correctly in console tho.. using latest build (3.85)

Let me check that, there is some special code to make the keypad always type numbers in the console, etc. and I didn't think of checking that out in my testing. Nice catch!

i think the azerty layout did work fine in console too but not in chatmode..

When I emulated the azerty keyboard, the console worked fine but keybinds didn't nor did it work in options. Not just for this, it didn't work in DarkPlaces or Quake 3 either.

I should be able to address that. But not easily. The international keyboard support relies on codes mapped to the physical keys AND their translation, but stores keybinds in a single array (based on the physical keys). I'm sure some system for translating the keybinds can be done, but the difficulty lies in that some keys (Enter, up, down, left, right, shift, etc.) are determined by their physical keycode and others by the translation, so it isn't very straightword to change it to a 2 code system.

Thanks for the feedback on this, the international keyboard support is awkward for me to test firsthand. I have to put a screenshot of a foreign keyboard on the screen so I can tell what keys are supposed to be what.

[=peg=]

Thanks for the feedback on this, the international keyboard support is awkward for me to test firsthand. I have to put a screenshot of a foreign keyboard on the screen so I can tell what keys are supposed to be what.

No problem, glad i can help out.. and yeah i can see how it must be awkward to test this.. good luck on that! you do great work on this project tho, keep it up!

[golden_boy]

@ Baker

% ldd proquake.x11
linux-gate.so.1 => (0xffffe000)
libX11.so.6 => /usr/lib/libX11.so.6 (0xb7e82000)
libXext.so.6 => /usr/lib/libXext.so.6 (0xb7e73000)
libXxf86dga.so.1 => /usr/lib/libXxf86dga.so.1 (0xb7e6d000)
libm.so.6 => /lib/libm.so.6 (0xb7e48000)
libdl.so.2 => /lib/libdl.so.2 (0xb7e44000)
libc.so.6 => /lib/libc.so.6 (0xb7d25000)
libXau.so.6 => /usr/lib/libXau.so.6 (0xb7d21000)
libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0xb7d1c000)
/lib/ld-linux.so.2 (0xb7f79000)

Nothing out of the ordinary, basically libc and some X libraries. Can't hurt to Google them. For those you'll probably have to install gcc and the X11/X.org developer stuff (dependent on your specific Linux.) GL client will need libGL installed.

Basically, you need to install the gcc and make packages if you haven't already. They will pull in all needed dependencies. Then you need a Makefile, which contains all directions for the compiler on which files to process etc. Doesn't proquake have one? It should be interesting to study those a bit.

You run make, which reads the makefile and runs gcc and that stuff according to what it finds there. It will tell you when something's missing.

I run gentoo, so the compiler stuff comes with the system. I compile all my quake clients manually. Takes like 5 minutes on an old machine.

Be aware that MS development environments sometimes use Windows-specific functions etc that you might need to Google and substitute the standard C versions for. I've had a problem where gcc stubbornly told me it didn't know what "strnicmp" was or something like that. You might want to disable all Microsoft specific extensions (or whatever they're called) when coding, otherwise you might unintentionally produce platform-specific code... this is OF COURSE not a way to push their own operating system...

quote from an open-source project (Abiword):

As Sam mentioned in "Release Practices", I've been working on patches to
eliminate non-ANSI string functions from the source tree (even the
xp-parts). To this end, this patch contains updates to and new parts added
to the ut_string files:

UT_strdup(..) like strdup, but uses only ANSI features (strdup is not ANSI)

UT_stricmp(..) like strcmp, but case insensitive. (stricmp is Microsoft,
strcasecmp appears to be gnu)

UT_strnicmp(..) (surprise surprise) like strncmp, but case insensitive.
(strnicmp is Microsoft, strncasecmp appears to be GNU)

so I'm not making this up - although people tend to laugh at me for those things. :-/

[Baker]

@ Baker

% ldd proquake.x11
linux-gate.so.1 => (0xffffe000)
libX11.so.6 => /usr/lib/libX11.so.6 (0xb7e82000)
libXext.so.6 => /usr/lib/libXext.so.6 (0xb7e73000)
libXxf86dga.so.1 => /usr/lib/libXxf86dga.so.1 (0xb7e6d000)
libm.so.6 => /lib/libm.so.6 (0xb7e48000)
libdl.so.2 => /lib/libdl.so.2 (0xb7e44000)
libc.so.6 => /lib/libc.so.6 (0xb7d25000)
libXau.so.6 => /usr/lib/libXau.so.6 (0xb7d21000)
libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0xb7d1c000)
/lib/ld-linux.so.2 (0xb7f79000)

Nothing out of the ordinary, basically libc and some X libraries. Can't hurt to Google them. For those you'll probably have to install gcc and the X11/X.org developer stuff (dependent on your specific Linux.) GL client will need libGL installed.

Basically, you need to install the gcc and make packages if you haven't already. They will pull in all needed dependencies. Then you need a Makefile, which contains all directions for the compiler on which files to process etc. Doesn't proquake have one? It should be interesting to study those a bit.

You run make, which reads the makefile and runs gcc and that stuff according to what it finds there. It will tell you when something's missing.

I run gentoo, so the compiler stuff comes with the system. I compile all my quake clients manually. Takes like 5 minutes on an old machine.

Be aware that MS development environments sometimes use Windows-specific functions etc that you might need to Google and substitute the standard C versions for. I've had a problem where gcc stubbornly told me it didn't know what "strnicmp" was or something like that. You might want to disable all Microsoft specific extensions (or whatever they're called) when coding, otherwise you might unintentionally produce platform-specific code... this is OF COURSE not a way to push their own operating system...

quote from an open-source project (Abiword):



so I'm not making this up - although people tend to laugh at me for those things. :-/

I'll try to install gcc and start from there and try to compile the existing ProQuake Linux build as it is. I'm not intimidated by having to make adjustments to code and not really intimidated by having to edit make files, but rather I'm not sure what I need to begin with.

I'll try to load up gcc and start from that.

[=peg=]

I took a look at the source code and i think that in order to change the behavior of the "ping +N" command to "ping =N" this is what needs to be changed (changes highlighted in yellow):

in host.cmd.c:

/*
==================
Host_Ping_f

==================
*/
void Host_Ping_f (void)
{
	int		i, j;
	float	total;
	client_t	*client;
	char *n;	// JPG - for ping +N

	if (cmd_source == src_command)
	{
		// JPG - check for ping +N
		if (Cmd_Argc() == 2)
		{
			if (cls.state != ca_connected)
				return;

			n = Cmd_Argv(1);
			if (*n == '+')
[COLOR="Yellow"]//			if (*n == '=')[/COLOR]
			{
				Cvar_Set("pq_lag", n+1);
				return;
			}
		}
		cl.console_ping = true;		// JPG 1.05 - added this

		Cmd_ForwardToServer ();
		return;
	}

	SV_ClientPrintf ("Client ping times:\n");
	for (i=0, client = svs.clients ; i<svs.maxclients ; i++, client++)
	{
		if (!client->active)
			continue;
		total = 0;
		for (j=0 ; j<NUM_PING_TIMES ; j++)
			total+=client->ping_times[j];
		total /= NUM_PING_TIMES;
		SV_ClientPrintf ("%4i %s\n", (int)(total*1000), client->name);
	}
}

in cl_input.c:

sizebuf_t lag_buff[32]; // JPG - support for synthetic lag
byte lag_data[32][128];  // JPG - support for synthetic lag
unsigned int lag_head, lag_tail; // JPG - support for synthetic lag
double lag_sendtime[32]; // JPG - support for synthetic lag


/* JPG - this function sends delayed move messages
==============
CL_SendLagMove
==============
*/
void CL_SendLagMove (void)
{
	if (cls.demoplayback || (cls.state != ca_connected) || (cls.signon != SIGNONS))
		return;

	while ((lag_tail < lag_head) && (lag_sendtime[lag_tail & 31] <= realtime))
	{
		lag_tail++;
		if (++cl.movemessages <= 2)
		{
			lag_head = lag_tail = 0;  // JPG - hack: if cl.movemessages has been reset, we should reset these too
			continue;	// return -> continue
		}
		
		if (NET_SendUnreliableMessage (cls.netcon, &lag_buff[(lag_tail-1)&31]) == -1)
		{
			Con_Printf ("CL_SendMove: lost server connection\n");
			CL_Disconnect ();
		}
	}
}

/*
==============
CL_SendMove
==============
*/
void CL_SendMove (usercmd_t *cmd)
{
	int		i;
	int		bits;
	sizebuf_t *buf;	// JPG - turned into a pointer (made corresponding changes below)
	static byte	data[128]; // JPG - replaced with lag_data

	buf = &lag_buff[lag_head & 31];
	buf->maxsize = 128;
	buf->cursize = 0;
	buf->data = lag_data[lag_head & 31]; // JPG - added head index
	lag_sendtime[lag_head++ & 31] = realtime + (pq_lag.value / 1000.0);
[COLOR="Yellow"]// 	lag_sendtime[lag_head++ & 31] = realtime + ((pq_lag.value / 1000.0) - realtime);[/COLOR]
	
	cl.cmd = *cmd;

//
// send the movement message
//
    MSG_WriteByte (buf, clc_move);

	MSG_WriteFloat (buf, cl.mtime[0]);	// so server can get ping times

	if (!cls.demoplayback && (cls.netcon->mod == MOD_PROQUAKE)) // JPG - precise aim for ProQuake!
	{
		for (i=0 ; i<3 ; i++)
			MSG_WritePreciseAngle (buf, cl.viewangles[i]);
	}
	else
	{
		for (i=0 ; i<3 ; i++)
			MSG_WriteAngle (buf, cl.viewangles[i]);
	}
	
    MSG_WriteShort (buf, cmd->forwardmove);
    MSG_WriteShort (buf, cmd->sidemove);
    MSG_WriteShort (buf, cmd->upmove);

//
// send button bits
//
	bits = 0;
	
	if ( in_attack.state & 3 )
		bits |= 1;
	in_attack.state &= ~2;
	
	if (in_jump.state & 3)
		bits |= 2;
	in_jump.state &= ~2;
	
    MSG_WriteByte (buf, bits);

    MSG_WriteByte (buf, in_impulse);
	in_impulse = 0;

#ifdef QUAKE2
//
// light level
//
	MSG_WriteByte (buf, cmd->lightlevel);
#endif

//
// deliver the message
//
	if (cls.demoplayback)
		return;

//
// allways dump the first two message, because it may contain leftover inputs
// from the last level
//

	// JPG - replaced this with a call to CL_SendLagMove
	/*
	if (++cl.movemessages <= 2)
		return;
	
	if (NET_SendUnreliableMessage (cls.netcon, &buf) == -1)
	{
		Con_Printf ("CL_SendMove: lost server connection\n");
		CL_Disconnect ();
	}
	*/
	CL_SendLagMove();
}

This changes the behavior to:
typing "ping =100" in console will result in (synthetic) ping 100
(instead of adding 100)

IMO this should work better because:
- easier to equalize to your opponents ping
- if you have unstable ping (say 30-100) you will now have stable ping 100

maybe the buffer size can be increased as well to prevent movement locking up if you try to set the synthetic lag too high..
My guess is that frame rate (FPS) plays a part in this happening..

I am a complete coding noob so i might have overlooked something and i did not test in any way if this actually works.. but on first sight i don't see any reason why it shouldn't.

[Baker]

Nice idea and supporting code example.

I will try it out and see if it works.

Btw, I have a feeling it may not work all that well since ProQuake's ping parsing sometimes makes mistakes, but it is worth a try.

[Baker]

I have lite version of video mode changing working perfectly and probably tomorrow I'll release it.

I just have a couple of things I need to double check first.

[=peg=]

cool!

[foq]

Nice.
(ping =230)
(pwnz Bam at RA anyway)

[Baker]

Download: Unofficial ProQuake 3.87 - 0.5 MB

Source code is here

- Switch video mode in-game via Video Options.
- Fixed situation where ctrl/shift/alt state wasn't reset on ALT-TAB switching in and out of window (thanks for telling me about this Peg).
- AVI capturing in GL build from JoeQuake 1862.
- Change console width in-game via vid_conwidth | vid_conheight (from Qrack).

I'm going to call 3.87 beta just because a small handful of things I should have done, I didn't do. If you use -window, Video Options should be disabled because right now it can't change color depth (yet!) because this requires all of the textures to be flushed and reloaded and I haven't been able implement that yet.

I also didn't correct the keypad mapping when international keyboard mapping is off. Easy enough to do, but I didn't do it.

Those are to my knowledge the only bugs in 3.87 and I consider this beta because I should have eliminated them, but I don't have time to do that right now. Plus this build uses FitzQuake-style video initialization, which basically means it initiates the video twice, which I don't like. I prefer the Qrack method where it waits before initializing the video.

I will probably enable video capturing for the wqpro build next time. Right now it only works in glpro.

Anyway, that will all be done next time.

[Baker]

AVI example:

[=peg=]

With this version (3.87 beta) i get some weird "artifact" (see screen shots) right below the fps meter (where in SP mode the skill level is displayed, top right corner of screen).

This only seems to happen for me in 16 bpp mode (even when not using any command line parameters whatsoever), not in 32 bpp mode.

Btw, the screen shots look all black because i was looking at a dark wall in dm2, so no worries there

On another note, when i set -bpp 32 in command line, i could not switch video mode in-game at all.. also it defaulted to 60 Hz refreshrate and i could not find any way to change it without resorting back to 16 bpp mode..

the CTRL+ESC bronzing bug seems to be fixed tho (yay!)

keep up the good work!

[Baker]

In next version (maybe later today), I have an omission corrected. The sound capture during AVI capture was wrong, so the above video doesn't have sound, but it will in the next release as in the following:

GLPro AVI capture:



WQPro AVI capture:



Plus the software version, wqpro, will also support AVI capture.

With this version (3.87 beta) i get some weird "artifact" (see screen shots) right below the fps meter (where in SP mode the skill level is displayed, top right corner of screen).

I'll look into it and fix that. Is this a new problem that occurred in 3.87 or is it also present in 3.80?

I have idea on how this is happening so I think I should be able to resolve this quickly.

This only seems to happen for me in 16 bpp mode (even when not using any command line parameters whatsoever), not in 32 bpp mode.

Right now, I think if any command line parameters for video mode are indicated that any in-game mode change attempts are ignored.

My recommendation for this version would be not to use -bpp if you want the video mode switching, but I had intended this to work if bpp was specified so maybe I'll address that in the next one.

the CTRL+ESC bronzing bug seems to be fixed tho (yay!)

keep up the good work!

Thanks, especially for the testing and bug reporting. The problems should be few and far between because I am being very conservative/cautious in the changes, but I definitely still need to think through the video mode and console switching issues.

[Baker]

Ok.

I think the weird print on the scoreboard is fixed (but since I don't have the problem myself, I can't verify this). I also think the keypad should now work as expected with international keyboard mapping off. Need verification on both of these, the latter worked fine for me in testing.

AVI capturing sound issue resolved; wqpro now has AVI capturing.

Download: Unofficial ProQuake 3.88 - 0.5 MB

Source code is here