DirectDraw over Direct3D

[Aric Cyr]

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