Very fast indeed. Even with the overhead of locking the backbuffer and expanding pixels from 8 bit to 32 bit it still manages to come in faster than anything else I've tried so far (aside from the Null driver, which doesn't draw to screen so it doesn't count).
This isn't traditional D3D as in vertexes, textures, matrixes, etc; oh no. The scene is still fully composed in software and D3D is only used for the very last step, which is putting the composed scene from a memory buffer onto the screen. Same as using D3D to display a bitmap in an image viewing program, really.
I'm going to do an OpenGL driver too just to see how things compare up, but I honestly have no idea whatsoever if the code I write here is going to be in any way suitable for this job. But I think nonetheless for completeness sake it needs to be done.
So far the pecking order is D3D > GDI > DDraw > GDI+. It will be interesting to see where OpenGL fits in here.
Update: I unwound some loops in the DirectDraw driver and it shot ahead. Just goes to show that an API is not enough, and sometimes you do have to do dirty work yourself.
The prototype OpenGL driver turned out to be hellishly slow. The lack of direct backbuffer access totally went against it, strategy #1 using glDrawPixels got 50 FPS (expect that to drop to 30 when/if it goes in the engine), strategy #2 using a texture fared no better. OpenGL is just far too high level and abstract for this kind of work.
OK, experiments over, the way it looks is this. 2 drivers will be included; DirectDraw and GDI. DirectDraw will only be available in 32 BPP modes but will be available both windowed and fullscreen. It's going to be preference number 1, and WinQuake will attempt to start up DirectDraw. If that fails, or if the mode is not supported (16 BPP) we'll use GDI instead. There will be a vid_ddraw cvar, defaulting to 1, which is the behaviour described above. A value of 0 will just skip the attempt to use DirectDraw and go straight to GDI.
If GDI fails then something on your machine is terminally f--ked and a crash will be in order.
The other video drivers I wrote will be removed. There's no need for the D3D driver as DirectDraw is now faster, and the GDI+ driver is just a joke.
Tuesday, April 6, 2010
The Direct3D driver is very fast
Posted by
mhquake
at
6:06 PM
Subscribe to:
Post Comments (Atom)
0 comments:
Post a Comment