The short answer is "I don't know". I could probably release it now, but there is a small list of things I want to either tighten up or finish off, and I haven't really done as much testing as I would like. The current code just doesn't feel ready yet.
One concern is that I have subjected some parts of the engine to quite significant reworkings, and that normally means that there is a possibility that there may be some edge cases in mods that I need to account for.
Overall though I think I'm getting there with it, but it will be a while yet before I start getting the feeling that it's close to done. Best guess at the moment is a week or two still.
Feature Update
The "gl_texturemode" command is back. I've tried to make it operate the same as in GLQuake, but there are subtle differences between how OpenGL and Direct3D handle texture filtering, so there may be some consequent differences in the end result. For the most part it should be quite similar though.
I'm toying with the idea of bringing back sRGB colour space correction. A previous release had it but I had removed it as it didn't play nice with 64 bit lightmaps. As I removed 64 bit lightmaps a while ago it's now an option that's back on the table, and in fact I had added in the code for most of it a short while ago, before removing it again. Right now it's not playing nice with 4 x overbrighting, but as this option is (a) unreleased as of yet, and (b) not present in software Quake, I think I can safely drop it.
Two problems with sRGB. Firstly it requires a 4 x modulate blend in overbright mode, and 2 x in GLQuake mode. Not too difficult, but it does mean more code. Secondly it requires some adjustment of cases where a modulation by colour (rather than by texture) is done. Overall I'm not sure if the gain is worth the pain, but I'll think on it.
"r_overbright" has been renamed "gl_overbright" for consistency with FitzQuake and possibly others. Some other cvar names have been renamed a little. Right now my change log is in slight disarray, with some out of date info in the earlier entries, and some more minor changes not added to it at all.
I really must dump a cvar and cmd list and document what each one does.
Running with white light
For the past few weeks I've been running DirectQ with coloured light disabled, and it has been an interesting experience. What kicked it off was the desire to get the lighting ranges back to proper Quake, and since then I've just stuck with it. It's odd, but I'm actually starting to feel that I prefer it to coloured light. There's something about the stark simplicity and purity of it that's quite attractive, and Quakes lighting effects just seem to look so much nicer without any eye-candy to distract from them.
I recommend giving it a try.
DirectQ design goals
I indicated a while back that I wanted to write a little on what the design goals for DirectQ are. This is something that can probably be gleaned from previous blog posts over the past year or so, but I've never actually summarised them in a single place. I know deep inside my head what I want and where I want it to go, but getting it out in the written word is trickier.
I suppose the primary goal was to have a version of Quake that would run well on my laptop. GLQuake just ran slowly, and occasionally sent the graphics driver into an infinite loop (or at least what it thought was an infinite loop), thus requiring a hard reset of my machine. I had spent most of 2008 working on a new OpenGL engine that was never released, and finally - in frustration at OpenGL - I switched over to D3D. That this was a good and right decision is supported by how far DirectQ has come.
Secondly I wanted any engine I released to have a reason to exist. I didn't see my abandoned OpenGL engine as having such a reason; it did much the same things as QRack and others did, only not as well. By being D3D I automatically fill a gap in the market for engines that can run well on a wide variety of laptops and business-class PCs.
Thirdly I wanted it to be a player-friendly engine. There are plenty of engines that are designed to be useful to mappers, or to give a wide variety of options to modders, but I wanted this engine to be aimed at people who actually played Quake. In many ways this is a much more difficult goal, and I'm still learning.
Fourthly I wanted it to be flexible. This meant going down the huge capacity route, and it meant coding for a certain lowest common denominator of hardware. I'm not sure how close to the ideal it is in either of those, but I hope it gets better all the time.
There are probably other important things I haven't touched on here, and probably places where the ones I have described could have been described better, but for now I guess it will have to do.
1 comments:
Thanks for the ETA :)
I'm willing to wait, its definately nice to know about how long though.
As far as usability, its definately high on usability. I think menus still need some work (as of 1.7.3) but its not a pressing issue, Everything the average user needs is there. With all the new features and work under the hood, I'm anxiously awaiting the next release, sounds like its gonna be huge.
Post a Comment