Wine 0.9 TODO v0.1

Lionel Ulmer lionel.ulmer at free.fr
Sat Nov 9 05:32:59 CST 2002


> Also it would be nice if opengl could similarly be loaded on the fly.

I am working on this right now... It's relatively easy for the OpenGL parts
of the X11DRV (I will do as XRender), but I have two other problems :

 1) what about opengl32.dll.so itself ? In that case, can I let direct
    OpenGL calls in there ? Thus if an application ever tries to load
    opengl32.dll on a non-libGL.so enabled system, the Wine library load
    will just fail due to a link failure and Wine will try to load the
    native (if any) OpenGL32.DLL.

    This is much more easy than doing a complete 'dlsym'ing of all the
    various OpenGL calls that are thunked (although it could be done as I
    would have just to rework my thunk-generator Perl script)

    But well, considering that the result will be anyway 'DLL cannot be
    loaded', I think that the 'ugly' solution is enough.
    
    Comments :-) ?

 2) the other bigger problem is the current DDraw code. There are a whole
    lot of OpenGL code directly called into it. This means that this Wine
    package won't have DDraw work on a non-libGL.so enabled box (even if the
    game is only a 2D game).

    I am somehow reluctant to fix this as the Direct3D code is bound to have
    some rework soon (at least I hope :-) ) and I do not want to have thinks
    conflict uselessly or do a hacky solution now to replace it by something
    nicer later. One solution would be to completely remove the D3D code
    behind compilation flags (as it's non-functionnal anyway) and people
    wanting to play with it could always set them to 'ON' somewhere in a .h
    file.

    For stuff like D3D8, it's the same as for OpenGL32.DLL as without
    libGL.so we will never support it anyway.

              Lionel

-- 
		 Lionel Ulmer - http://www.bbrox.org/



More information about the wine-devel mailing list