[Bf-committers] WITH_BF_GLEXT

[Giuseppe Ghibò]

Brecht Van Lommel wrote:
> Hi,
>
> I think it is not a good idea to rely on the platform glext.h (should have commented on this earlier but overlooked the discussion). The build shouldn't be limited to the OpenGL version of the computer that is was built on. Windows comes with version 1.1 by default for example. And extensions checks should not be done with #ifdef's anyway, but with runtime checks only ..
>
> It would be better to use something like GLEW. I'd prefer everything to use GLEW, and I've committed it in the apricot branch and will investigate how to use it for the game engine, though it's too big a change to do before the release now. Regardless, I think the current situation is not good and should be improved maybe after the release, but I think it's still important to get release builds with extensions enabled.
>
> There's a bug in the tracker now about GL extensions not being supported in unofficial windows builds. I'm not sure what the situation will be in the official builds, but I guess they might not have the extensions either without making changes. I suppose this is something all platform maintainers should test for when they make the next RC.
>
> Brecht.
>   
Brecht, note that actually the problems are of different kind (for which
the bug #7113 was an example):

a) messing up with old and new include files which overrides the
system-wide one (and for instance the old one might not have full 64bit
support), or #defining and #undefing the system things on the fly as 
hacks in a few
lines of code, which might have side effects on different platforms.

b) use obsolete glext.h (AFAIK newer one is
http://www.opengl.org/registry/api/glext.h and not
http://oss.sgi.com/projects/ogl-sample/ABI/glext.h)

c) despite of having GL extensions supported, you get for instance
crashes on 64bit platform, and the same doesn't happen on exactly the same
platform|compiler|processor|OS and the same same video card when ran on
32bit (e.g. into a 32bit chroot of a 64bit installation)
but this doesn't mean it's just a fault of the nvidia driver or that the 
driver it's bugged.
This is for instance the case of GL_ARB_multitexture, which is
supported by nvidia driver since a lot of time, but (at
least inside blender code) had problems on 64bit.

So, IMHO it's not just a matter of testing whether a GL function or an
extension is supported or not, but also whether use such extension or not,
and why when it is used it crashes.

IMHO the testing of GL extensions on the at runtime level could be maybe
done using the dlsym() function
(as alternative the OpenArena game code has also somethings about this).
But that also means to use the shared version of the library anyway,
while AFAIK (though probably not much used) using the static version
could be still an option.

Couldn't be instead a bit standardized the usage of the extensions in a 
clean way, so
that they can be:

a) enabled|disabled at compilation time
b) if made with a) have them autodected also at runtime level
c) have a subset of functions autodetected at point b) enabled/disabled
according to user choices (e.g. by some prefs or config file or env var
or both).

Bye
Giuseppe.

>   
>> ----- Oorspronkelijk bericht -----
>> Van: Kent Mein [mailto:mein at cs.umn.edu]
>> Verzonden: maandag, april 28, 2008 10:39 PM
>> Aan: 'bf-blender developers'
>> Onderwerp: Re: [Bf-committers] WITH_BF_GLEXT
>>
>> In reply to Jean-Luc Peuri?re (jlp at nerim.net):
>>
>>     
>>>    (We may need to work on this stuff to get it fully functioning properly)
>>>
>>>    I consider this a very bad regression. it worked really fine previously.
>>>    If the card did not really support the GLSL it was checked at runtime
>>>    and did not crash and simply did not display it.
>>>    I'm not sure how many people used that, it is GE specific and probably
>>>    little known, but still.
>>>
>>>       
>> Hi Jean-Luc,
>>
>> I appreciate where your comming from, the problem was though that it
>> wasn't working for everyone, was actually crashing the game engine on some 
>> machines.
>>
>> Note: I did not change any of the tests, I simply removed the header
>> because it was old and did not work with some hardware.  Its also
>> something I believe that we shouldn't have in the code.  We don't include GL.h
>> Its a header that should be done at the platform level not the software.
>>
>> I'm sorry its not working for you,  I'm willing to try and help
>> you get it working.  I haven't had a chance to test things on my
>> macbook, will do that tonight.  On my linux machine with an NVIDIA
>> card I have no problems with the gameengine demos, I can also,
>> setenv WITHOUT_GLEXT 1 and turn it off if I want to.
>> (The other thing the patch does)
>>
>> Kent
>> -- 
>> mein at cs.umn.edu
>> http://www.cs.umn.edu/~mein
>> _______________________________________________
>> Bf-committers mailing list
>> Bf-committers at blender.org
>> http://lists.blender.org/mailman/listinfo/bf-committers
>>
>>
>>     
>
>
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>