Engine X 4.61 Beta

[Magnus]

Any chance this flavor will fix the dinput for Windows 7?

I've tried a few other engines that manuall disable maccel, but after exiting the game the mouse isn't the same as before I went in. The only fix was to reboot the system, which sucks when I have like 5 Visual Studios open.

[Wolv]

I have the same problem as Magnus. With most engines that aren't ProQuake, actually.

[Baker]

I know about all of the above issues. All will be resolved in upcoming releases.

I might need more info on the Win 7 mouse stuff when I get there as I don't have Win 7.

[R00k]

This is mainly for Baker, so dont let all this tech talk frustrate the rest.

I know engineX trips my enhanced pointer precision on/off when it loads up, and leaves it on until I 'quit' and manually un-check it in the control panel.
I had this issue as well in Qrack 1.90. Grr!
This is only effected when NOT using DirectX.

This seemed to help me in Qrack:

static	int	originalmouseparms[3], newmouseparms[3] = {0, 0, 0};//MH: acceleration level set to zero!

Explanation:

In void AppActivate (BOOL fActive, BOOL minimize)
this part deactivates the mouse, when one ALT-TABS out.

	if (!fActive)
	{
		if (modestate == MS_FULLDIB)
		{
			IN_DeactivateMouse ();

when they switch back in..

	if (fActive)
	{
		if (modestate == MS_FULLDIB)
		{
			IN_ActivateMouse ();

it reactivates the mouse, calling this:

	restore_spi = SystemParametersInfo (SPI_SETMOUSE, 0, newmouseparms, 0);

BUT, in EngineX, newmouseparms is defined as:

static	int	originalmouseparms[3], newmouseparms[3] = {0, 0, 1};

That latter 1 is mouse acceleration.
So, if one alt-tabs out (or unfocused in windowed mode) it will flip it over to ON, when they return. Phew!
__________________________________________________ ____________
For DirectX to not lose half its sens when I alt-tab, and feel normal for both on or off, I just make sure to reset the whole interface,

		case WM_ACTIVATE:
			fActive = LOWORD(wParam);
			fMinimized = (BOOL) HIWORD(wParam);
			AppActivate(!(fActive == WA_INACTIVE), fMinimized);
		
			Key_ClearAllStates();// fix the leftover Key_Alt from any Alt-Tab or the like that switched us away

			//R00k re-init the mouse after losing focus
			if ((!mouseactive)&&(fActive))
			{	
				IN_Shutdown ();
				IN_StartupMouse();
				IN_ActivateMouse ();
				IN_HideMouse ();
			}
			break;

#define RESETMOUSE\
	IN_Shutdown ();\
	IN_StartupMouse();\
	IN_ActivateMouse ();\
	IN_HideMouse ();

qboolean OnChange_mouse (cvar_t *var, char *string)
{
	float update;
	update = atof(string);

	if (update == var->value)
		return false;	

	Cvar_SetValue(var->name,atof(string));

	RESETMOUSE;
	return true;
}

cvar_t	m_dinput			= {"m_directinput", "1",true,false,OnChange_mouse};//R00k keep cvar name compatible with pq3.85

[Magnus]

fyi, even disabling the pointer precision in win7, using glpro, the mouse just doesn't feel the same. At low mouse movements it doesn't always register in quake. Its like I have to give the mouse a kick start for it to start working. Never happened in XP with proquake.

[Baker]

@R00k

Engine X hasn't fully digested ProQuake's mouse code yet. Like you, I have walked through the mouse code carefully to study it.

/ProQuake's mouse code restores on exit but not on ALT-TAB, which I do know is a flaw and is on my "improvements/bugs list."

Something that would be killer is implementation of MH's DirectInput 8 .dll code (dinput8.dll if I recall) as an option (m_directinput 2?). This might solve all dinput issues on Win7 as ppl say Win 7 + dinput = awkward on Win 7 and everyone says DirectQ does not have issue.

Anyway, my mouse code (on Windows) in Engine X has the ProQuake 4.00 flaws and the mouse code in current ProQuake doesn't have proper ALT-TAB restore yet. Both will be fixed.

[MH]

I'd just use DirectInput 8 by default anyway, there's no reason not to. It's almost 10 years old so it's not like it's some radical new untested technology that you need to be wary of.

The trouble I've found though is that certain (quite vocal) elements of the Quake community can be ultra-conservative to what seems like ridiculous extremes. Not updating software, not updating hardware, not updating drivers, and deliberately making the decision to do so, for years and years on end.

Case in point: I've an experimental build of GLQuake that I've been playing with on and off for a while. Performance-wise it totally smokes everything else out there; nothing can touch it. And it has ample headroom to get faster. Trouble is that it's unreleasable as it totally drops all legacy support. Consider it an experiment in what things would be like if you made the decision to go down the route of using modern rendering techniques.

No multitexture, no shaders, no vertex buffers, no 64-bit textures, low video RAM, out of date drivers? Tough shit amigo, you're not joining this party.

(It also contains some non-GPL code which makes things even more difficult but is a subject for another rant).

Sigh...

[Mindf!3ldzX]

Thats the 2nd time I've heard of this GL build. I'm awaiting an invitation to that particular party. I've been testing other clients lately,mostly tweaking settings and observing frames per sec

[dfsp_spirit]

bugs?

Sometimes eX crashes when maps are changed at euroquake and I don't have the map. Maybe it's my fault (config) or the server's but you judge that Baker:

screenie1
screenie2


(The message is the usual Windows blabla: Application whatever has stopped working, ...)

[Baker]

Sometimes eX crashes when maps are changed at euroquake and I don't have the map. Maybe it's my fault (config) or the server's but you judge that Baker:

screenie1
screenie2


(The message is the usual Windows blabla: Application whatever has stopped working, ...)

It is the client's fault. There are some pieces of Engine X which only partially use ProQuake's code and I need to finish the map download implementation, which is disabled in Engine X anyway.

I know all the bugs but with my time constraints I have to update when I can.

Fortunately, I have been very good at taking a few hours here and a few hours there and getting productivity out of them.

I expect the rate of updates to accelerate within a few weeks.

[Baker]

I'd just use DirectInput 8 by default anyway, there's no reason not to. It's almost 10 years old so it's not like it's some radical new untested technology that you need to be wary of.

The trouble I've found though is that certain (quite vocal) elements of the Quake community can be ultra-conservative to what seems like ridiculous extremes. Not updating software, not updating hardware, not updating drivers, and deliberately making the decision to do so, for years and years on end.

Case in point: I've an experimental build of GLQuake that I've been playing with on and off for a while. Performance-wise it totally smokes everything else out there; nothing can touch it. And it has ample headroom to get faster. Trouble is that it's unreleasable as it totally drops all legacy support. Consider it an experiment in what things would be like if you made the decision to go down the route of using modern rendering techniques.

No multitexture, no shaders, no vertex buffers, no 64-bit textures, low video RAM, out of date drivers? Tough shit amigo, you're not joining this party.

(It also contains some non-GPL code which makes things even more difficult but is a subject for another rant).

Sigh...

I don't think anyone objects to progress. I have no issues with using, say, DirectInput 8. I have no issues if an engine won't run on Windows ME or the guy trying to use some 1998 video card or some guy who still uses dialup.

And the idea of having, say, mouselook off by default by original Quake did it seems way unreasonable. From that aspect, ProQuake 4 is very evil.

You can't please everyone.

For myself, I personally define an ideal Quake engine that runs on every platform all the time with no bugs and plays Quake correctly [that's my end goal, some bugs do remain and I know it. I don't accept them; I accept have haven't had time to get rid of them yet.]

So you can tell anyone "Use this engine. It will work."

I myself got into engine modding when faced with the difficult reality that DarkPlaces doesn't work well enough on most people's hardware combinations and when it does work you have health boxes suspended in the air, monsters shooting from the void in Travail, 5 frames per second in Warpspasm, broken mods ... and at the end of the day an engine incompatible with Quake can't really fill the void.

For ProQuake in my head my motto would be ... "If your computer can run NotePad, it can run ProQuake!". I don't see anything wrong with that as a goal. And the dx8 wrapper has made that statement almost universally true. I can't even say that there is anyone who has posted in the last year that said they can't run ProQuake

[Neil]

Very nice work baker, I actually downloaded this on the weekend and gave it a good run over.

Rook may need to watch out, this may replace Qrack for me soon.

[R00k]

There's no competition but with one's self when Quake coding is involved.

[Baker]

R00k can take any code he wants. One interest I have in this, is by unifying ProQuake and Engine X into a single source code is that a highly similar engine like Qrack could easily absorb new features and the reverse.

As it is, R00k could probably add the FitzQuake protocol off my engine in 3 hours or so and the code was made easy to borrow by clearly labeling changes with #ifdef blocks.

I'm more interested in all engines having better features and advancements.

[dfsp_spirit]

I just wanted to mention that I also have that strange RJ behaviour that someone (Phenom?) mentioned in another thread that I can't find atm:

When I look down and do a RJ, my view gets messed up in a weird way (it just goes straight instantly I think).