Re: [Mesa3d-dev] Tiny fix for Mesa-Win32

[Sukender <suk...@fr...>]

[This is a repost because I didn't sent it to the mailing list :) ]

José Fonseca wrote:
> On Thu, 2009-04-30 at 06:06 -0700, Sukender wrote:
>> Hi all,
>>
>> First of all: hello to everyone!
>>
>> I'm new here, and I won't be involved much in Mesa development, but I'd like to post a tiny improvement. Sorry if it has been discussed before... (I had a quick look into the archive and it seems not).
>>
>> Actually, I noticed a problem when compiling the OpenSceneGraph toolkit against Mesa 7.4.1, under Win32/MSVC8:
>> In mesa_wgl.h, it reads (line 47):
>>
>> #if defined(__MINGW32__)
>> #  ifndef WIN32_LEAN_AND_MEAN
>> #    define WIN32_LEAN_AND_MEAN 1
>> #  endif
>> #  include <windows.h>
>> #endif
>>
>> And I think there should be three little changes:
>> 1. Include windows.h for all Windows builds (not only MinGW).
>> 2. Define NOMINMAX, since we don't need these two stupid macros.
>> 3. _WIN32_WINNT is sometimes not defined, and that can be a source of problem.
> 
> Sukender, 
> 
> These are actually application shortcomings. We should not define these
> in GL.h. Truth is that:
> 
> 1. Windows applications should include windows.h before GL/gl.h (because
> Microsoft's GL/gl.h does not include it automatically)
> 2. Some windows applications out there which use GL might rely on the
> min/max macros, and they would break if we defined NOMINMAX in Gl/gl.h
> 3. _WIN32_WINNT has nothing to do with GL.
> 
> To be honest, mesa_wgl.h should be removed. It seems to have been made
> in a time where MinGW wingdi.h headers didn't define the WGL API, but
> that is long gone. My experience is that it gets in the way more than it
> helps.
> 
>> So my proposition is to write:
>>
>> #if defined(__MINGW32__) || defined(WIN32)
>> #  ifndef WIN32_LEAN_AND_MEAN
>> #    define WIN32_LEAN_AND_MEAN 1
>> #  endif
>> #  ifndef NOMINMAX
>> #    define NOMINMAX 1
>> #  endif
>> #  ifndef _WIN32_WINNT
>> #    define _WIN32_WINNT    0x0400
>> #  endif
>> #  include <windows.h>
>> #endif
>>
>> What do you think about it?
>> I tried it and successfully compiled OpenSceneGraph 2.9 (partially : osg, osgDB, osgUtil, osgViewer), and tested an example.
> 
> Doesn't OpenSceneGraph include windows.h?


Hi again Jose,

I found a few interesting things about the OSG compilation: OpenSceneGraph *does* define APIENTRY manually. So in gl.h (line 82):
#if defined(_WIN32) && !defined(APIENTRY) && !defined(__CYGWIN__)
#define WIN32_LEAN_AND_MEAN 1
#include <windows.h>
#endif

This code thus does NOT include windows.h. Then the lines after:

#if defined(_WIN32) && !defined(_WINGDI_) && !defined(_GNU_H_WINDOWS32_DEFINES) \
    && !defined(OPENSTEP) && !defined(__CYGWIN__) || defined(__MINGW32__)
#include <GL/mesa_wgl.h>
#endif

These *do* include mesa_wgl.h... This is why I had problems. My simple workaround was to comment out the "#include <GL/mesa_wgl.h>" line. Any idea to make it a bit cleaner?

Thanks.



[For reference, here is the copy of the previous mail]

Hi Jose,

Thanks for your answer...


>> Actually, I noticed a problem when compiling the OpenSceneGraph toolkit against Mesa 7.4.1, under Win32/MSVC8:
>> In mesa_wgl.h, it reads (line 47):
>>
>> #if defined(__MINGW32__)
>> #  ifndef WIN32_LEAN_AND_MEAN
>> #    define WIN32_LEAN_AND_MEAN 1
>> #  endif
>> #  include <windows.h>
>> #endif
>>
>> And I think there should be three little changes:
>> 1. Include windows.h for all Windows builds (not only MinGW).
>> 2. Define NOMINMAX, since we don't need these two stupid macros.
>> 3. _WIN32_WINNT is sometimes not defined, and that can be a source of problem.
>
> Sukender,
>
> These are actually application shortcomings. We should not define these
> in GL.h. Truth is that:
>
> 1. Windows applications should include windows.h before GL/gl.h (because
> Microsoft's GL/gl.h does not include it automatically)
> 2. Some windows applications out there which use GL might rely on the
> min/max macros, and they would break if we defined NOMINMAX in Gl/gl.h
> 3. _WIN32_WINNT has nothing to do with GL.


Ah... I didn't know, sorry.
Strange thing that some file can't compile when against Mesa then... I'll have a look into it.


> To be honest, mesa_wgl.h should be removed. It seems to have been made
> in a time where MinGW wingdi.h headers didn't define the WGL API, but
> that is long gone. My experience is that it gets in the way more than it
> helps.

Hmmm... Can I easily get rid of that file?



>> I tried it and successfully compiled OpenSceneGraph 2.9 (partially : osg, osgDB, osgUtil, osgViewer), and tested an example.
>
> Doesn't OpenSceneGraph include windows.h?

Yes and no... As said before, some files (that usually compile) don't compile when against Mesa. I suspect some Windows' GL headers to inlcude windows.h somewhere...



>> And finally, I know this is not the good mailing list for that, but is there a way to do:
>> 1. Pure software OpenGL with Mesa-Win32?
>
> Yes, there is. Install download mesa master, install scons,
> 
>   scons -j %NUMBER_OF_PROCESSORS% platform=windows debug=yes statetrackers=mesa drivers=softpipe,trace winsys=gdi
>
> It will generate a
> mesa/build/windows-x86-debug/gallium/winsys/gdi/opengl32.dll which is a
> drop-in replacement for Microsoft's opengl32.dll. Copy it to the
> directory where your application is and run it.


Great! Thanks. But... err...
1. What and where is mesa master? :D
2. Can you confirm I will get all OpenGL 2.1 functionality, including shaders and other features, whatever the hardware?


>> 2. Hardware/Software mixed OpenGL (= Hardware when supported, Software when not)?
>
> I don't know what you mean here. This is already what you get when you
> use an Opengl driver from a hardware vendor.

Well, the post by Tom Fogal is more explicit than my sentence! For example I tried an OSG shaders example. Using my standard OpenGL driver, I got something like "shaders not supported". Using Mesa, I also get the same result. What I would like is that such operations (that can't be run with my integrated graphics chipset) are emulated and computed on the CPU.

-- 
Sukender
PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/