[Bf-committers] Error in GE files while compiling with scons + mingw

[Christian Monfort]

Kent Mein a écrit :
> In reply to Christian Monfort (monfort.c at gmail.com):
>
>   
>> Stephen Swaney a ?crit :
>>     
>>> On Fri, Apr 18, 2008 at 04:02:52PM +0200, Christian Monfort wrote:
>>>   
>>>       
>>>> In my MinGW directory (MinGW 5.1.3), glext.h is at version 11 (2002/03/22)
>>>> and blDeleteObjectARB is not defined.
>>>>
>>>> Downloading latest glext.h from www.opengl.org shows latest version is 40
>>>> (20080324), and there is a definition for blDeleteObjectARB...
>>>>
>>>> So this was introduced somewhere between V11 and V40; from there I see only
>>>> 2 solutions:
>>>>
>>>> 1) get latest MinGW and check if blDeleteObjectARB is defined in glext.h
>>>> 2) downlad openGL headers from www.opengl.org and put the new ones in MinGW
>>>>
>>>> Now another question: what happens if graphic card driver does not support
>>>> the openGL extensions used here?
>>>>     
>>>>         
>>> 3)  set WITH_BF_GLEXT = 'false'
>>>   
>>>       
>> Yes, of course, but not exactly what I had in mind... So I rephrase:
>>
>> What happens if Blender is compiled using openGL extensions (ie. 
>> WITH_BF_GLEXT='true') and you graphic card does not support such extension?
>> Is there some fall back mechanism (Blender detecting extensions are not 
>> implemented, and so does not use them), or does it crash...
>>
>> If there is nothing in the code to prevent using extensions when they're 
>> not implemented, I guess final release will be compiled with them turned 
>> off, and you'll have to make your own build if you want to use them...
>>     
>
> It's suppose to auto detect, there may be things that need tweaking
> though since there are some values that have been hard coded.
>
> Once this is done theres still more to do....
> If you look at 
> source/gameengine/Rasterizer/RAS_OpenGLRasterizer/RAS_GLExtensionManager.h
> You'll see that it has this line in there:
> #  undef GL_ARB_multitexture // (ubuntu)
> This is a workaround that disables chunks of code, it would be better
> to remove this and tell people with problems to disable it at runtime, and or
> find out what the problem was/is...
>
> Kent
>   

Maybe there is other solution, somewhere in the openGL initialisation
code (I don't remember where for now, I have to search for it...), there
is a lot of function pointer initialization depending on the abilities
of the openGL libraries. It maybe possible to test if funtions were
found in library, and skip the code for those  that are not supported
(or assume openGL extensions are not supported if one function is not
found).

I think I made something like that in a V2.43 custom build I made for
displaying a mix of 2 textures in 3D view textured mode.
I'll look in my code and post here what I found.