Brecht Van Lommel
brechtvanlommel at pandora.be
Wed Apr 30 01:01:47 CEST 2008
I understand the glext.h problems, and know that simply adding it back will of course not solve them. This is why I'm proposing to use GLEW, so that we can a) always have all options compiled in and b) check for them at runtime, since this library provides all the platform dependent code and a simple way to check on the availability of the extensionss at runtime.
In the meantime for this release, the old glext.h can be used by platform maintainers, if it makes the extensions work on that platform without crashing blender.
>----- Oorspronkelijk bericht -----
>Van: Giuseppe Ghib? [mailto:ghibo at mandriva.com]
>Verzonden: dinsdag, april 29, 2008 11:59 PM
>Aan: 'bf-blender developers'
>Onderwerp: Re: [Bf-committers] WITH_BF_GLEXT
>Brecht Van Lommel wrote:
>> 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, 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
>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
>>> ----- 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
>>> 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)
>>> mein at cs.umn.edu
>>> Bf-committers mailing list
>>> Bf-committers at blender.org
>> Bf-committers mailing list
>> Bf-committers at blender.org
>Bf-committers mailing list
>Bf-committers at blender.org
More information about the Bf-committers