The RMQ engine renderer is getting near to completion now. It's actually on it's third rewrite, but this was all a valuable process and allowed me to experiment with and test out various rendering techniques that both perform and behave differently in OpenGL to what my most recent experience with D3D had me believe.
There is possibly a fourth rewrite in the pipeline, and the reason for this is the difference between how vertex arrays (and vertex buffers) work in OpenGL and D3D.
The D3D method is clearly superior. It involves far less code and gives much more flexibility in what you can do, primarily because it decouples layout specification from data specification. As a specific example, in D3D setting up to render a complex vertex layout (something involving position, colour, normals, lots of multitextured texcoords and maybe some blending factors to go into a vertex shader) requires just two lines of code (SetVertexDeclaration and SetStreamSource); in OpenGL it's multiple pages of glEnableClientState/gl*Pointer (and possibly some glClientActiveTextures for the texcoords).
The example I quoted above isn't really relevant to the RMQ engine, although a hypothetical similar scenario could be for MDLs, so it's not too far off being realistic.
Now, say you're in a position where you have a layout that contains a position and may also contain either of two colours (each stored as a byte[4]) or a texcoord. The vertexes are all stored in a single data array, and you can switch back and forth between each layout at arbitrary points in that array. This one isn't at all far-fetched - the second rewrite of RMQ did just that. You can either add redundant data to the layout or go through a mess of glEnable/glDisable each time you need to change. Yuck.
So hence the third rewrite and hence the fact that performance had started to suffer somewhat recently.
As an experiment I have maybe half of a D3D-like interface to OpenGL's vertex arrays API written; I'm uncertain if I'll continue with it but it's interesting to see the code needed and how API calls that accomplish much the same thing differ between the two. I don't however think that there's going to be much practical advantage to completing it, but if a requirement does come up I'll probably investigate further.
Performance-wise, particles are now a massive bottleneck. I'm not really understanding why at the moment, but when even something as simple as the lava ball trail in the hard hall of start.bsp goes off I lose about a third of my framerate, whereas DirectQ doesn't even bat an eyelid at it. This is on recent NVIDIA hardware, which one would reasonably expect to be in a different class where OpenGL is concerned.
Speaking of DirectQ, I've been thinking further about the roadmap, and while the eventual objective remains unchanged, there will most likely be an interim D3D9 release that raises the hardware requirements to D3D9 class hardware, removes all of the legacy rendering paths, and adds some features to the renderer that I flat out have not been able to do owing to having kept the legacy paths. So that's going to be 1.9, with the D3D11 version being 2.0 (which will line up that jump nicely with a new major version number).
The D3D9 interim version will do everything through shaders, which will prep things nicely for the eventual move up. In fact, r_hlsl 1 in DirectQ will right now already do everything through shaders, so there's no work involved here aside from removing the old code paths. There will however likely be some restructuring where I may have had to do some things in a certain way to support both paths as options, but that may be suboptimal for HLSL-only, and there will be other features added to take advantage of being HLSL-only.
I have some ideas for the kind of stuff I want to add, but I'm not going to make any premature announcements, so you'll just have to wait.
Before then I also intend putting out 1.8.666b, which contains some more bugfixes (no, I haven't had the chance to test out the other ones I mentioned yet) and will likely end up being the last DirectQ for older hardware. This is important for anyone who wants or needs to use it in preference, although there are other D3D engines available here, and the mighty Baker from QuakeOne.com is doing some impressive work with both ProQuake and EngineX, both of which have D3D builds available.
With those kind of alternatives there is no longer a requirement for DirectQ to remain a legacy engine, so it's a nice time to be moving forward and good that I can do so with no regrets and no looking back.
Till next time!
0 comments:
Post a Comment