Second the required 3d functionality is VERY limited. Basicly the
only
thing the videocard needs support is texturing which all cards do.
But that's obviously wrong - the video *driver* also needs to support
it.
And the current 3D video driver situation in Linux is horrible.
Yeah linux drivers are crap for videocards from companies like S3/Via, XGI/Sis and also Intel. Most cards have some basic 3d driver support (the newer S3 ones not yet) but this basic support is enough. Texturing is something that is supported by all those basic drivers and cards. If your card can play Quake I it can also be used for the ddraw over direct3d renderer. A simple voodoo1 would even be fast enough (although this card can't do more than 16bit). The card also doesn't have to be fast. For instance your 2d game works at 800x600 and you use double buffering. You need to process half a million pixels for a single frame. That voodoo1 about which I talked already has a fillrate of 60MPixels so it can already do it fast enough. (one of the bottlenecks is the uploading of textures which happens through PCI / AGP / PCI-Express but this bottleneck appears for all drawing operations)
Roderick
Roderick Colenbrander <thunderbird2k <at> gmx.net> writes:
Second the required 3d functionality is VERY limited. Basicly the
only
thing the videocard needs support is texturing which all cards do.
But that's obviously wrong - the video *driver* also needs to support
it.
And the current 3D video driver situation in Linux is horrible.
about which I talked already has a fillrate of 60MPixels so it can already do it fast enough. (one of the bottlenecks is the uploading of textures which happens through PCI / AGP / PCI-Express but this bottleneck appears for all drawing operations)
Textures might even be faster than a direct DGA mode since textures are sent over the bus at AGP/PCIe speeds, where DGA is (I believe) limited to PCI memory mapped I/O speeds. Granted there is a bit more configuration overhead for using OpenGL but all that state can (and should) be set up front and then never touched again. I haven't checked out this patch in much detail yet, but I hope it is implemented in such a way to avoid changing OpenGL states once the program has started.
I think the code would reduce to something like:
one_time_init: <create and setup the texture object to be compatible with framebuffer> <set up vertex and texture coordinate arrays (only 4 unchangin vertices)>
render_frame: glTexSubImage2D(...) // update texture object from the 'framebuffer' glDrawArrays(...); // uses the currently active vertex and texture coords
There should be no reason that ddraw needs to change any state or vertex info between render operations. The only thing that changes should be the pixel data for used for the texture. We could go even one better and replace my example glDrawArrays with a display list so then the only data we are sending to the GPU on a render is the pixel data and a glCallList(). Also, for memory savings, we don't need a depth buffer, an accum buffer or stencil buffer for ddraw. A straight framebuffer-only visual would be cheapest in terms of video card memory and glClear costs.
Of course, since ddraw is going to eventually end up using wined3d, we should make sure that this fast-path is possible, or create a ddraw inside wined3d, as some have mentioned.
- Aric
-
Aric Cyr -
Roderick Colenbrander