In what situation does it exactly crash for you? Is it crashing because there is no libGL around? I'm not sure what the right thing to do is. Due to it our wglGetProcAddress won't function because it relies on glXGetProcAddress.
Our use of wglGetProcAddress isn't correct (but it works on WINE :)) in the sense that officially an OpenGL context must be around. Perhaps I should fix this behavior in gdi32 and in wined3d. It would allow for a nicer fix than adjusting the USE_GL_FUNC macro.
I'm not sure about the shader backend part of the patch (I don't know that code well), so I'm leaving that to Henri and Stefan.
Roderick
On Tue, Mar 2, 2010 at 5:51 PM, Kusanagi Kouichi slash@ac.auone-net.jp wrote:
Signed-off-by: Kusanagi Kouichi slash@ac.auone-net.jp
dlls/wined3d/directx.c | 5 ++++- 1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/dlls/wined3d/directx.c b/dlls/wined3d/directx.c index 457cb85..cb64319 100644 --- a/dlls/wined3d/directx.c +++ b/dlls/wined3d/directx.c @@ -4677,7 +4677,7 @@ BOOL InitAdapters(IWineD3DImpl *This) goto nogl_adapter; } #else -#define USE_GL_FUNC(pfn) pfn = (void*)pwglGetProcAddress(#pfn); +#define USE_GL_FUNC(pfn) pfn = (void*)pwglGetProcAddress(#pfn); if (!pfn) goto nogl_adapter; /* To bypass the opengl32 thunks load wglGetProcAddress from gdi32 (glXGetProcAddress wrapper) instead of opengl32's */ mod_gl = GetModuleHandleA("gdi32.dll"); #endif @@ -4950,6 +4950,9 @@ nogl_adapter:
initPixelFormatsNoGL(&This->adapters[0].gl_info);
- This->adapters[0].shader_backend = &none_shader_backend;
- This->adapters[0].fragment_pipe = &ffp_fragment_pipeline;
This->adapter_count = 1; return FALSE; } -- 1.7.0
On 2 March 2010 18:06, Roderick Colenbrander thunderbird2k@gmail.com wrote:
I'm not sure about the shader backend part of the patch (I don't know that code well), so I'm leaving that to Henri and Stefan.
You shouldn't be calling those if there's no GL.
(I also still haven't seen anyone make a *convincing* argument for why we'd want to have a "somewhat working, but not quite" wined3d if we don't have OpenGL in the first place.)
Am 02.03.2010 um 18:39 schrieb Henri Verbeet:
(I also still haven't seen anyone make a *convincing* argument for why we'd want to have a "somewhat working, but not quite" wined3d if we don't have OpenGL in the first place.)
In the past there have been two reasons:
*) Gentoo users "OMG I don't want the opengl use flag!!!!11!1" *) XVnc
Since our dynamic libGL loading basically allows for 2D ddraw operation without libGL we implemented this, but since barely any wine developer has such a system this functionality breaks every other week. I am not disinclined to kill it and refuse to load the DLL entirely when GL is not available.
On Wed, Mar 3, 2010 at 4:55 AM, Stefan Dösinger stefandoesinger@gmx.at wrote:
Am 02.03.2010 um 18:39 schrieb Henri Verbeet:
(I also still haven't seen anyone make a *convincing* argument for why we'd want to have a "somewhat working, but not quite" wined3d if we don't have OpenGL in the first place.)
In the past there have been two reasons:
*) Gentoo users "OMG I don't want the opengl use flag!!!!11!1" *) XVnc
Since our dynamic libGL loading basically allows for 2D ddraw operation without libGL we implemented this, but since barely any wine developer has such a system this functionality breaks every other week. I am not disinclined to kill it and refuse to load the DLL entirely when GL is not available.
If you want it tested, I'd be happy to add a vnc test run to my test scripts.
On 2010-03-02 18:06:00 +0100, Roderick Colenbrander wrote:
In what situation does it exactly crash for you? Is it crashing because there is no libGL around? I'm not sure what the right thing to do is. Due to it our wglGetProcAddress won't function because it relies on glXGetProcAddress.
Our use of wglGetProcAddress isn't correct (but it works on WINE :)) in the sense that officially an OpenGL context must be around. Perhaps I should fix this behavior in gdi32 and in wined3d. It would allow for a nicer fix than adjusting the USE_GL_FUNC macro.
I'm not sure about the shader backend part of the patch (I don't know that code well), so I'm leaving that to Henri and Stefan.
Roderick
The attached code crashes if libGL is not installed. It doesn't crash if installed. I don't expect wined3d works without opengl. But it shouldn't crash, should it?
#include <windows.h> #include <ddraw.h>
int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR CmdLine, int CmdShow) { LPDIRECTDRAW dd;
if (DirectDrawCreate(NULL, &dd, NULL) == DD_OK) IDirectDraw_Release(dd);
return 0; }
On Wed, Mar 3, 2010 at 8:14 AM, Kusanagi Kouichi slash@ac.auone-net.jp wrote:
On 2010-03-02 18:06:00 +0100, Roderick Colenbrander wrote:
In what situation does it exactly crash for you? Is it crashing because there is no libGL around? I'm not sure what the right thing to do is. Due to it our wglGetProcAddress won't function because it relies on glXGetProcAddress.
Our use of wglGetProcAddress isn't correct (but it works on WINE :)) in the sense that officially an OpenGL context must be around. Perhaps I should fix this behavior in gdi32 and in wined3d. It would allow for a nicer fix than adjusting the USE_GL_FUNC macro.
I'm not sure about the shader backend part of the patch (I don't know that code well), so I'm leaving that to Henri and Stefan.
Roderick
The attached code crashes if libGL is not installed. It doesn't crash if installed. I don't expect wined3d works without opengl. But it shouldn't crash, should it?
#include <windows.h> #include <ddraw.h>
int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR CmdLine, int CmdShow) { LPDIRECTDRAW dd;
if (DirectDrawCreate(NULL, &dd, NULL) == DD_OK) IDirectDraw_Release(dd);
return 0; }
Correct, we should not crash. I'll see if I can fix the wglGetProcAddress part in a cleaner way.
Roderick
-
Austin English -
Henri Verbeet -
Kusanagi Kouichi -
Roderick Colenbrander -
Stefan Dösinger