I haven't updated much recently because once again there hasn't been much to provide updates about. Progress on the RMQ engine is coming along nicely, together with the (expected) frustrations of differences between OpenGL and D3D, as well as problems with migrating an already established codebase to something new. I've ranted often enough about these things in the past (and no doubt will again in the future) so there's no need to go into further details right now.
Every day things are getting a little closer to where I want them to be, and as an overall package it's starting to hang together well now. Of course the initial rewrite of the renderer went very fast, but the current phase of bringing on all the little weird extra things that are needed is dreadfully slow. This is always the case with a radical rewrite of anything, so nothing dreadful about that.
Generally when I do any kind of rewrite like this I also use a Quake II engine as an experimental platform, and this is no different. The resulting Quake II build is normally not fit for release - that only happened once - so don't be expecting to see anything there. Of course it's also OpenGL this time, and with the whole point of the "DirectQ" exercise being to provide D3D as an alternative there doesn't seem to be any reason to release this one. If you want a Quake II engine there are plenty of other options.
Roundabout now I'm reasonably fed up with the renderer code and itching to work on something different in it, so thankfully things are coming near the end with that. Expect more regular updates when I start on that.
Regarding DirectQ itself, I have a Release 1.8.666b almost ready to roll. This fixes a few more outstanding bugs, but there is one other that I want to take the time to have a closer look at before I put it out.
The future of DirectQ is looking like D3D11. I know I did an April Fool post about it earlier on this year, but further thought (and time away from it) is starting to steer me in that direction.
There are a number of reasons for this.
Firstly I feel as though I've taken the current D3D9 implementation as far as I really want to go with it. Any future evolutions will be just that - evolutions. There's not much moving forward in that and I want to move forward.
Secondly, there are a number of bugs and Bad Things behind the scenes in DirectQ that I've pasted over in the current codebase, but that really need a gutting and rewriting for to fix properly. D3D11 just handles the specific areas that these cause problems in a lot better.
Thirdly D3D9 itself is an old, old API, and it shows. Of course it's still viable, but there has been a lot of progress since then and it seems right to take advantage of that.
Fourthly, there is a lot of cruddy old code that I've retained in DirectQ for compatibility with more downlevel hardware, and that is preventing me from moving some things forward the way I want to; by moving up to D3D11 where a certain minimum hardware requirement exists (this can be the D3D9-level requirement) I can have a cleaner, more stable and more bug-free codebase.
Fifthly, preliminary tests of D3D11 (using some SDK samples - which admittedly may be biased) indicate that it runs at about twice the speed of D3D9.
Now, all of this means that some day DirectQ is going to be a Vista/Windows 7 only app (D3D11 itself can run on downlevel hardware, but still needs to more recent OS). I believe that my D3D8 porting project engines are a suitable replacement for it on XP and below, and that they will still have a reason to exist as a result of this. In that sense DirectQ will become the "Rolls Royce" engine that I do to please myself, and one of the others will be the general workhorse instead.
Interesting times ahead there.
Tuesday, August 31, 2010
Current Status Update
Posted by
mhquake
at
5:34 PM
4
comments
Thursday, August 19, 2010
Alpha sorting for brushmodels
Just a quick heads up. If your engine supports brush model alpha, and if you depth-sort by model, you're going to need to switch to depth-sorting by surface instead if you want RMQ to look right in it.
I appreciate that this is potentially a pain, but ultimately it's more correct. Not my decision, and in fairness nobody probably knew that it would become a requirement.
And yes, I'll also need to fix DirectQ to do this.
Posted by
mhquake
at
11:27 PM
0
comments
Wednesday, August 18, 2010
More old code!
I've just found the last version of the OpenGL engine that I was working on in 2008, and abandoned right at the point when I started working on DirectQ. This isn't as interesting as the other really really old stuff, as pretty much everything in it eventually made it into DirectQ (a lot of the code was actually a straight copy and paste) and it was also full of hacks that were intended to get it working on the Intel driver I was using at the time.
That never really worked out well, and in the end I made the decision to finally bite the bullet and switch to D3D.
The original objective at the time was that I would port stock ID Quake to D3D as both a proof-of-concept exercise and a learning experience, and based on that I would then go back to the GL engine and port that. However things worked out differently and I ended up using the stock ID Quake port as the baseline for future work; the GL engine has been languishing since then.
As I said, there is nothing of any serious interest in it, but (and it's a big but) there is another piece of code that I haven't yet been able to find, but if I ever do I will probably package the two of them up and release them. This is the first D3D test I ever wrote that went all the way to rendering a Quake level, and was intended to establish that performance was going to be good and that the problems I had encountered in OpenGL were not going to happen with D3D.
It was just a handful of source files with the textures embedded as resource bitmaps and the vertex data embedded as a binary resource, and the chosen map was DM1. There was no gameplay, no physics, no world interaction, no nothing aside from a barely functional renderer and some crude movement code. I consider that one interesting enough to release, and someone doing an OpenGL to D3D port might even find it useful from the perspective of being able to home in on the specific changes needed without being distracted by other stuff.
If it ever turns up I'll let you know.
Posted by
mhquake
at
1:15 AM
0
comments
Tuesday, August 17, 2010
Old Code Alert!
I was just going through the contents of an old USB HD (to which I had archived a LOT of my older stuff many years ago) when I came across a whole batch of MHQuake engine sources dating back almost to year 1. I haven't gone through these and cataloged them in any way yet, but there is definitely some historically interesting stuff in there. Among the more interesting ones is an unreleased version from - I think - 2004 or perhaps even earlier that did real time per-pixel lighting.
Right now I'm wondering what to do with them. Should I just zip them all up and put them on QuakeTastic or something similar? Or should I let sleeping dogs lie (or die, as the case may be)? Enquiring minds want to know.
If there are enough interested people (and bear in mind that 1 person might be "enough" here) I'll probably just upload them somewhere without any major fanfare. There won't be any support or assistance from myself with these, I won't bother even compiling them to make sure that they still compile OK. Hell, I quite likely don't even remember most of what I was up to back then! So it would just be a pure code dump, and some of it may be embarrassingly bad so it will be up to each individual to pick through the piles of dung looking for nuggets of gold themselves.
So - anyone interested?
Update
Glance to the right and up a little...
Posted by
mhquake
at
11:05 PM
3
comments
Monday, August 9, 2010
DirectQ Bugfix Release
Release 1.8.666a can be obtained from here: http://directq.codeplex.com/releases/view/50335.
This is an emergency bugfix release which fixes a problem where the user-selectable depth buffer format may occasionally cause an invalid device to be created, which may in turn cause texture creation to fail and/or DirectQ to start up without any depth buffer at all. Attempts to issue vid_restart commands while in this situation may send DirectQ into an infinite loop.
Now, back to RMQ...!
Posted by
mhquake
at
10:13 PM
6
comments
Pushing for new standards
One of the really cool things about working with a bunch of crazy-assed talented content creators is the feedback and interaction that goes on between all parties as part of the ongoing quest to establish what features RMQ is going to have. There has been a lot of talk elsewhere about standards for moving Quake forward, and this is our chance to propose - and show off working examples of - some of the items we think should be included in these standards.
My own remit starts and ends with the engine, but even as part of that I do get to have input into some decisions regarding content. One recent one that we've just cracked is "fence textures", or - because pictures speak louder than words - things like this (not an RMQ map, by the way...):
I'm going to stick my neck out a little here and say that this is a feature that Quake should have had from the outset. Doom had it, Q3A had it, it's only poor little Quake (and Q2, of course, but that's to all intents and purposes the same engine) stuck in the middle that didn't have it.
Final decisions haven't yet been made, but what we're doing for now is using any texture who's name begins with "{" as such a "fence texture". The reason for selecting "{" is that it's what Half Life uses, and if there is prior art that has already established a standard naming convention, it makes sense to follow that example.
Next up - a dastardly disasterous DirectQ bug destroyed. Stay tuned.
Posted by
mhquake
at
9:55 PM
7
comments
Sunday, August 8, 2010
Been a while since the last update
Mostly because I've been off pursuing some Real Life stuff, so there hasn't been much to say. Never fear, it was the good kind of Real Life stuff, but it does take it's toll and some comedown is needed.
RMQ is starting to come together in the final push for the renderer. It's a good substantial way along the path towards how I want it structured, with most of what you see on-screen now having been moved across. I did make that other attempt at dynamic VBOs which I was talking about, but once again had no real luck with them. Some further info has since come to light, so I think a third attempt (this time after everything has moved across) might be worthwhile, but overall VBOs in OpenGL are just annoying, unclear and lack some important functionality.
This "final push" just relates to getting the basic Q1 renderer up and running; there will of course be more renderer features added as time goes on. Some ideas are starting to percolate through as to what they will be, but I'm holding fire on saying anything myself until code is in place.
Working on an already established code base is an interesting thing. On the one hand, a lot of the problems with GLQuake have already been resolved so it's quite pleasing to be able to go in knowing that you don't have an intensive round of bugfixing ahead of you before you can even start getting things done. On the other hand however - especially for a content-heavy production like RMQ - there is a lot of code restructuring already done that you basically have to undo again, then redo in a format that's going to run better. When you're not 100% familiar with the code it increases the chances of making mistakes.
Overall though I would say that it's a positive learning experience, and that it gives you insights into an alternative perspective on how to do things that you might not have had otherwise. I'd recommend it to everyone.
That's all for now. Till next time!
Posted by
mhquake
at
4:09 PM
0
comments
Sunday, August 1, 2010
Currently Researching...
Dynamic Vertex Buffers in OpenGL. This is what DirectQ uses and it can handle my 400 knights test map at over 40 FPS. RMQ is still using plain old vertex arrays however and the performance is just not there - less than half.
So why would I want to draw 400 knights anyway? Performance efficiency is the reason. There are going to be ambitious things planned for RMQ and the faster it can handle MDL drawing (which is the current major bottleneck) the more headroom will be available for other things to happen.
With D3D correct use of a dynamic VBO is clear and easy. Create it with D3DUSAGE_DYNAMIC, lock it with D3DLOCK_DISCARD, write in your data, unlock when done, and draw away to your heart's content. DirectQ pulls a few more tricks to keep the number of lock/unlock operations to a minimum, such as saving out state changes to a replayable list so that we can write in objects with different states without needing to unlock/render/lock; the only thing that actually causes an unlock/render is a change in vertex format (happens a LOT less often than you might think) or the end of the current frame. These are all viable techniques for RMQ too.
With OpenGL the situation is a little more muddy, and this comes back to my theory about somebody in OpenGL land panicking and leaving us with VBOs as a half thought through first draft API. There are operations that seem like they should do much the same as in D3D, but there are also subtle little differences in important parts. The fact that anything could be going through software emulation at any point in time, and you never quite know, is another negative point against OpenGL. My initial attempt at bringing on VBOs in RMQ went down in flames as a result of these, but now that I have almost everything in vertex arrays it's getting near time to try again.
I'm thinking a two-step process will be best here. Step 1 will involve moving the renderer to the same final structure as DirectQ uses, meaning the replayable list of state changes, but keep it using standard vertex arrays. This won't be too painful and can be done on an even more modular basis, such as taking brush models across first. Step 2 will involve bringing on VBOs on top of that.
Step 2 is the one that concerns me, as another point about OpenGL VBOs I haven't yet mentioned is that every time I experimented with them in the past I observed zero performance gain (hardware platform is irrelevant here as all of my prior tests were on NVIDIA). The possibility that I was doing something wrong can't be discounted, of course, but there is still an element of reluctance in me to undertake the work required for Step 1 (even though it's not much at all) without knowing for certain that Step 2 will give the improvement that it should. Without Step 2 doing it's thing, Step 1 amounts to little more than code aesthetics, which are nice but unnecessary.
Fortunately the amount of work for Step 1 is quite small so it's getting near time to dive in. I'll report back on progress. Till then!
Posted by
mhquake
at
2:10 PM
0
comments