Thursday, July 2, 2009

Next Release

As is customary by now, I'm giving advance notice of my intentions regarding the next release shortly after the previous. :)

I've pretty much decided that it's definitely going to be 1.7; 1.6.3 certainly had enough going on behind the scenes to justify a full version number bump, but I want to have something more substantial than behind the scenes changes for it.

Of course, with a new full version number we get new features, and I'm going to follow the model of using rapid incremental releases to fine tune them. As to what those new features will be: once again I've left particles outstanding, and I see that a sample CSQC implementation on top of a vanilla Quake codebase is now available. No promises though, I'm definitely not going to bring CSQC into my main codebase until I'm satisfied that it's going to integrate cleanly, and these days I just seem to be rubbish at particles (4 aborted attempts in DirectQ speak for themselves).

One thing that's almost certainly on is a fine tuning of the standard QC interpreter. I've already done some work on it in previous releases, but it's time to really get stuck in.

Otherwise, I think that in terms of the renderer, the engine is "done". I still want to add in a fixed function path, but the HLSL path is about as feature-complete as I want to make it.

I've toyed with the idea of going back to my Release 1.0 code for the fixed path, but some issues with it occurred to me. The 1.0 code worked fine, and gave me lots of pleasure in writing it, but looking back with the benefit of what I know now, there are a lot of things I would have done different (and better).

I was then going to port ProQuake (which I thought would be a nice present for Baker) and use the end result as a base, as it's already set up for a D3D renderer, but doing so would involve some major gutting of it's D3D code as it's structured very differently to what I would use. The temptation to bring some of that structure across to the port would be too much. I wanted a clean, fresh, but broadly compatible codebase to work from.

Where this is all leading is that I'm going to port Quake II to D3D. The render is almost identical to classic Quake (although with a fair bit of "second system effect" in), and it'll be a valuable exercise in providing a good codebase to bring forward to the DirectQ fixed path. Who knows, the end result might even be releasable in it's own right. ;)

It will be a classic pure port, just the baseline rendering stuff, and nothing fancy in effects, no changes elsewhere in the engine. One time only, one version only. No Vertex or Index Buffers, no HLSL, no particle effects, nothing beyond what Quake II already does. I did the original Quake 1 port in a single weekend, but I don't expect to do the same here. About a month seems a reasonable upper limit.

This also gives me a time window should any last-minute unexpected bugfixes be required in DirectQ 1.6.3; not really starting on 1.7 until after this port is done will mean that any such fixes can be brought directly into the unchanged 1.6.3 codebase.

0 comments: