Saturday, April 3, 2010

More fun with Software Quake

Every now and then I like to go off and do some experimental work. This generally happens after a release milestone and when I need to try out new code in a build that won't pollute my main codebase, or that is sufficiently distant from my main codebase that I can forget about assumptions made in it. Sometimes I do it because I need to, other times I do it because it's fun. Sometimes the end result gets released (the original DirectQ was actually one such experiment) and other times it doesn't.

I mentioned a while back that I was doing some work on a native DirectDraw backend for software Quake but that I was seeing pretty abysmal performance. It did however tickle my fancy to see if I could do the same with a Direct3D backend. There's really nothing much in the difference and the core concepts are the same: you create a device, set up your surfaces, lock your backbuffer, write to it, unlock it, and present your scene. Only the terminology is different. (Note that this is not the way a real DirectDraw app works, but it's the way you need to work for Quake).

So I dug out my test application (that just writes random garbage to screen) and ported it to D3D9; a few optimizations later I was running at almost 200 FPS; a big increase from the 6 FPS I got with DirectDraw.

The neat thing is that now - in the more familiar environment of D3D9 - I've identified a few bottlenecks that really made the DirectDraw version suffer, and they are easily portable. So the next step is - of course - to port them and see what happens.

None of this has any bearing on DirectQ itself of course, but where that stands at the moment is that I'm still adding a few layers of polish in preparation for a 1.8.3 release. I'm off gallivanting around the world for a short while in about 2 weeks time so I intend having something out before then.

The latest change there is that I've implemented the ID3DXRenderToSurface interface to handle my render to texture requirements for the underwater warp. I had always had some concerns that while the code I had written certainly worked, I had no idea how correct it actually was. Some study of an SDK sample and now I've got something that's more in tune with the way the runtime expects things to be done, which is all to the good in the longer term.

2 comments:

Coranth said...

Off gallivanting around the world for two weeks, eh? I hope you have a great time, and get inspired to do more awesome work on DirectQ. It's odd... I imagine that one day, you will turn DirectQ into a 'universal engine' able to run any 'Quake' with a simple change of the Game Dir.

There will be no differences with or between the games, to DirectQ, Quake will be Quake; no matter WHAT Quake you choose to run, your engine will run them all!

"Three Quakes from the ID kings,
Blessed is their Code. One from the Ravens, in the darkened sky. Many for the Players, via Open
Source. And one from MHQuake, that he wrote on his own. DirectQ will run them all. DirectQ will bind them. Should they be installed at all, DirectQ will find them. In the world of Quake, where the Demons lie."

gnounc said...

I worry sometimes about what people expect from your code lol.

Thanks for posting what you are doing on the side, its just as interesting.