GoldQuake : Improved WinQuake

[Sajt]

I was thinking that I would start an improved WinQuake engine. This would be software-only, of course, since there's no point starting a new GL engine. And it would be 8-bit colour only.

I took out the source today for the first time in six or seven years and had a go. I managed to fix the chase camera as well as implement the viewmodelforclient extension.

Some other simple ideas to start with:
- Console command completion.
- Scale the console text up at high resolutions.
- Better video menu.
- Model animation interpolation.
- Gun bobbing that doesn't make me want to puke.
- Other basic QC extensions (like the trig functions, FRIK_FILE).
- An extremely important modding extension: extra +buttons.
- Bugfixes. What bugs are there?

Later on:
- Transparency & additive blending.
- CSQC.

All the protocol extensions and stuff (e.g. viewmodelforclient) are compatible with DarkPlaces, so for example a demo recorded in this engine using the extensions should be playable in DarkPlaces.

I'll make sure to maintain the exact Quake look & behaviour by default.

Some precedents are ToChris and Makaqu. I've managed to get the source to Makaqu, although I haven't found ToChris. I'll use these for reference if I ever need to. But I'm not interested in starting with them as a base, because I have no idea how buggy they might be (I recall ToChris to be a bit crashy).

I figure that if I developed this in a public SVN repository, and give anyone else who wants to contribute SVN write access, this would be a bit of a better idea. Kind of the ioquake3 of WinQuake, or something.

So would anyone be interested in this? (By the way, the real reason I'm doing it is because my GPU or something is messed up and any hardware graphics has a chance of freezing my computer.)

[Baker]

http://www.quake-1.com/files/engine-sou ... is1_67.zip

- Bugfixes. What bugs are there?

FOV > 90 doesn't display weapon
Chase_active 1 weirdness
Typing on keyboard triggers -aliases bound to keys
System clock precision issue (Sys_FloatTime instead of Sys_DoubleTime)

[Sajt]

http://www.quake-1.com/files/engine-sources/tochris1_67.zip

- Bugfixes. What bugs are there?

FOV > 90 doesn't display weapon
Chase_active 1 weirdness
Typing on keyboard triggers -aliases bound to keys
System clock precision issue (Sys_FloatTime instead of Sys_DoubleTime)

Thanks for the ToChris download!

I've already fixed the first two bugs noted. (The first apparently was a "feature".) I remember having fixed the third one in a previous lifetime, so that shouldn't be difficult, and I'll definitely look into this timer thing I've heard about alot.

I think I will try to get this onto SVN tomorrow so the diffs will go all the way back for your viewing pleasure.

edit: Actually, could you explain to me what this timer precision issue is and how to "see" the problem? I remember time sometimes running too fast in jerks in DOSQuake, but I don't know if I've seen it in WinQuake...

[frag.machine]

Very nice idea, Sajt. I'd suggest you to apply the tutorial series that MH wrote about memory management. This will turn your engine into a really good and solid base to apply bigger changes. Unless, of course, you're aiming to a cross-platform code base, but even in this case I think you can adapt the tutorials.

[Baker]

edit: Actually, could you explain to me what this timer precision issue is and how to "see" the problem? I remember time sometimes running too fast in jerks in DOSQuake, but I don't know if I've seen it in WinQuake...

Quake can run terribly jerky (too fast, too slow) on some computers, it seems like dual core and quad core ones in particular and overclocked gpus.

I've never experienced it firsthand, but I've fixed the problem second hand.

Only affect Windows, check sys_win.c in JoeQuake or FuhQuake or ezQuake or DarkPlaces and look at Sys_DoubleTime.

[mh]

The timing issue is caused by multiple cores not necessarily running at the same speed, and WinQuake using QueryPerformanceFrequency and QueryPerformanceCounter for it's timers. The OS may move an exe from one core to another, so that the initial performance frequency is no longer valid. Power saving modes (like Intel speedstep) may also affect it, and I've also seen rumours that it doesn't play nice on 64-bit.

Best option is to do what ID did for QuakeWorld and later engines and switch to integer millisecond timing using timeBeginPeriod and timeGetTime instead. These are pretty much guaranteed reliable and give 1 millisecond resolution, which is adequate for Quake.

It may also be a good idea to remove a lot of the compatibility hacks that were added to WinQuake (stuff like vid_nopageflip, vid_stretchby2, and so on). 14 years on drivers have matured and standardised enough that they should be no longer needed - what was valid in 1996 is not necessarily still valid in 2010.

I'm not certain how achievable it is, but getting rid of SciTech's MGL library might be another idea here. MGL is totally obsolete software, will never be updated (or bugfixed), and is overdue being replaced by a modern, faster and more compatible 2D graphics library (or even going native DirectDraw).

[c0burn]

This is a great idea.

What about the "technicolour" bug? I think when I run WinQuake all the colours are psychedelic.

Win 7 x64, ATI HD 4890

[dreadlorde]

I have a git repository for a linux client that I was planning on doing this same thing to. If anyone is interested I'll host it on github and give people access.

[Spike]

I agree with mh - the first sizable change should be the guilt free stripping and unhesitant deletion of scitech's MGL library.
Blue start buttons are not good. Die already.
Replacement code can be sourced from Quake2, or perhaps FTE's svn history.

QueryPerformanceCounter issues are presumably worse with longer uptimes. AMD released a util which keeps AMD cores more closely in sync which can be used to mitigate the issue in other computers. Alternatively task manager should permit you to assign cpu affinity to a specific core. Or you can run a sane operating system that doesn't keep switching your threads over to other cores on a whim.
QueryPerformanceCounter precision bugs in win9x cause time to pass faster than it should, accelerating with up time. This is the primary reason for timeGetTime in QuakeWorld.

[Baker]

Ideas:

- Make it so the WinQuake window doesn't do the silly default positioning of 0,0 on the screen and centers like GLQuake
- Cause -window to do the same thing as -startwindowed
- Support -mem xxxx in the command line
- 5 mouse button support
- Touchlinks fix

Either way I look forward your work.

/I'm still going to port 24-bit color from FTE

[Dr. Shadowborg]

Okay, this is just plain awesome.

One suggestion I have is that you might want to extend some engine limits like in agurequake / (Bengt Jardrup's win/glquake).

MenuQC should be in there for later along with the CSQC if it isn't already.

Also, make sure you can turn off the model interpolation via a cvar and menu. (so that mods which prefer to use older style muzzleflashes don't do the visual ugh.)

Oh and try to keep the lowres 320x240 into 640x480 windowed mode if at all feasable. (Yes, I know this is a wierd request)

Heck, if this turns out as awesome as it sounds, I'll even recommend this engine as THE engine to use when playing hellsmash. (not to mention use all the nice features you've mentioned)

[c0burn]

Also, make sure you can turn off the model interpolation via a cvar and menu. (so that mods which prefer to use older style muzzleflashes don't do the visual ugh.)

This should be done the way MH/DirectQ does it. If self.effects & EF_MUZZLEFLASH, don't interpolate the viewmodel. With a cvar to override if you're using v_models that don't have butt ugly flashes.

[mh]

The way DirectQ does it is actually by checking for movement of triangles between frame 0 and frame 1; if they move beyond a certain threshold value then those triangles only are not interpolated (other triangles in the model are). It's called from R_DrawViewModel so we can be certain that the model checked actually is a viewmodel (using models beginning with v_ is not valid as even an ID1 model that ain't a viewmodel begins with v_), and is set up so that it only gets called once per model.

Overall a little hacky but it works fine in every test case so far.

[c0burn]

Oh that's cool, I didn't realise that. Works very well in any case.

[mh]

Replacement code can be sourced from Quake2, or perhaps FTE's svn history.

Yeah, it should be possible to put together something from Q2 (I hadn't thought of that), and - at least at the start - should be quite compatible with what's already there. There will be differences but the basic concept of copying pixels to a buffer which is then written to video RAM (or equivalent) should be solid.