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