ddraw: load OpenGL at runtime
lionel.ulmer at free.fr
Thu May 15 13:44:25 CDT 2003
> How long is it going to be before d3dcore is a reality?
Well, this is the problem. The work on it is barely starting for D3D8 and
after we will need to rewrite D3D7 based on this common core (at the same
time doing regressions, porting the D3D7 code missing over, ...).
So it's not something that it's likely to be in Wine before at least 2
months (we are currently too busy adding features to get finally games
working to work on this :-) ).
> I think it is a good idea, but I'd like to have dlopen functionality
> sooner rather than later. Additionally, I don't see how my patch is a
> step backwards...
Well, I mostly only looked at the first one (did not see until later the
second one) and I saw a huge patch changing a lot of our code (i.e. all the
GL calls) - all this for something we would plan to throw away sometime in
the future (not to mention a patch that would have added a LOT of conflicts
to my own Wine tree :-) ).
Now the second patch is a bit better (as it changes a lot less files) but
may still have a (minimal I think) performance penalty due to the indirect
calling of all the GL functions.
And for the patch to be comitted :
- no 'diff -u' please, it kills indentation in all the code where you added
the 'if (opengl_initialized)' tests
- configure creates a 'SONAME_LIBGL' for you (instead of hard-coding to
- what is this 'WINE_MESSAGE' stuff ? Why not use the 'ddraw' channel ?
> btw. I had no idea a wine-d3d list even exists.
Sorry for that, I mixed you up with another Mike (who should have known
about this list :-) ).
Lionel Ulmer - http://www.bbrox.org/
More information about the wine-devel