Index | FAQ | Search | Memberlist | Usergroups | Profile | Log in to check your private messages | Log in | Register

GoldQuake : Improved WinQuake Goto page 1, 2, 3, 4 Next

| Inside3d Forums Forum Index -> Engine Programming

View previous topic :: View next topic
Author | Message
--- | ---
Sajt Joined: 16 Oct 2004 Posts: 1026 |

Posted: Thu Jan 28, 2010 12:52 pm Post subject: GoldQuake : Improved WinQuake |

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.)
_________________
F. A. Špork, an enlightened nobleman and a great patron of art, had a stately Baroque spa complex built on the banks of the River Labe.
Last edited by Sajt on Fri Jan 29, 2010 5:23 am; edited 1 time in total

Back to top |

Baker Joined: 14 Mar 2006 Posts: 1538 |

Posted: Thu Jan 28, 2010 12:59 pm Post subject: |

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

Sajt wrote:
- 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)
_________________
Tomorrow Never Dies. I feel this Tomorrow knocking on the door ...
Last edited by Baker on Thu Jan 28, 2010 1:02 pm; edited 1 time in total

Back to top |

Sajt Joined: 16 Oct 2004 Posts: 1026 |

Posted: Thu Jan 28, 2010 1:08 pm Post subject: |

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

Sajt wrote:
- 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...
_________________
F. A. Špork, an enlightened nobleman and a great patron of art, had a stately Baroque spa complex built on the banks of the River Labe.

Back to top |

frag.machine Joined: 25 Nov 2006 Posts: 728 |

Posted: Thu Jan 28, 2010 1:32 pm Post subject: |

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.
_________________
frag.machine - Q2K4 Project
http://fragmachine.quakedev.com/

Back to top |

Baker Joined: 14 Mar 2006 Posts: 1538 |

Posted: Thu Jan 28, 2010 1:47 pm Post subject: |

Sajt wrote:
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.
_________________
Tomorrow Never Dies. I feel this Tomorrow knocking on the door ...

Back to top |

mh Joined: 12 Jan 2008 Posts: 910 |

Posted: Thu Jan 28, 2010 1:59 pm Post subject: |

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).
_________________
DirectQ Engine - New release 1.8.666a, 9th August 2010
MHQuake Blog (General)
Direct3D 8 Quake Engines

Back to top |

c0burn Joined: 05 Nov 2004 Posts: 158 Location: Liverpool, England |

Posted: Thu Jan 28, 2010 3:46 pm Post subject: |

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

Back to top |

dreadlorde Joined: 24 Nov 2009 Posts: 86 |

Posted: Thu Jan 28, 2010 4:26 pm Post subject: |

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

Ken Thompson wrote:
One of my most productive days was throwing away 1000 lines of code.

Get off my lawn!

Back to top |

Spike Joined: 05 Nov 2004 Posts: 944 Location: UK |

Posted: Thu Jan 28, 2010 4:43 pm Post subject: |

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.
_________________
What's a signature?

Back to top |

Baker Joined: 14 Mar 2006 Posts: 1538 |

Posted: Thu Jan 28, 2010 4:52 pm Post subject: |

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
_________________
Tomorrow Never Dies. I feel this Tomorrow knocking on the door ...

Back to top |

Dr. Shadowborg Inside3D Staff Joined: 16 Oct 2004 Posts: 726 |

Posted: Thu Jan 28, 2010 5:08 pm Post subject: |

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)
_________________
"Roboto suggests Plasma Bazooka."

Back to top |

c0burn Joined: 05 Nov 2004 Posts: 158 Location: Liverpool, England |

Posted: Thu Jan 28, 2010 5:32 pm Post subject: |

Dr. Shadowborg wrote:
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.

Back to top |

mh Joined: 12 Jan 2008 Posts: 910 |

Posted: Thu Jan 28, 2010 5:57 pm Post subject: |

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.
_________________
DirectQ Engine - New release 1.8.666a, 9th August 2010
MHQuake Blog (General)
Direct3D 8 Quake Engines

Back to top |

c0burn Joined: 05 Nov 2004 Posts: 158 Location: Liverpool, England |

Posted: Thu Jan 28, 2010 6:01 pm Post subject: |

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

Back to top |

mh Joined: 12 Jan 2008 Posts: 910 |

Posted: Thu Jan 28, 2010 6:17 pm Post subject: |

Spike wrote:
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.
_________________
DirectQ Engine - New release 1.8.666a, 9th August 2010
MHQuake Blog (General)
Direct3D 8 Quake Engines

Back to top |

Display posts from previous:

| Inside3d Forums Forum Index -> Engine Programming | All times are GMT Goto page 1, 2, 3, 4 Next
Page 1 of 4

Jump to:

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

Powered by phpBB © 2004 phpBB Group