Current CVS errors

[Ermabwed]

Outdated glext.h *sigh*

EL is so futuristic we need the absolutely latest glext.h, you can get it here: http://www.opengl.org/registry/api/glext.h

You want to tell me this project relies on a file that was published 2 days ago? I have no desire to become an ~arch tester for my distro just because the one program I use that is not in portage uses a two days old file... (and I'm not going to mess with my source based distro by adding random files to it)

Anyways, I do have a working client and if Learner is willing to provide a bugfixed linux client it will stay this way

[Learner]

Outdated glext.h *sigh*

EL is so futuristic we need the absolutely latest glext.h, you can get it here: http://www.opengl.org/registry/api/glext.h

You want to tell me this project relies on a file that was published 2 days ago? I have no desire to become an ~arch tester for my distro just because the one program I use that is not in portage uses a two days old file... (and I'm not going to mess with my source based distro by adding random files to it)

Anyways, I do have a working client and if Learner is willing to provide a bugfixed linux client it will stay this way

If the file is that new, then we shouldn't be using anything form it yet because the video drives either wont have that feture, or it may be too buggy.

[Xaphier]

Just a short comment: The file is older than 2 days. It was generated at the 12. February 2007.

[Ermabwed]

Just a short comment: The file is older than 2 days. It was generated at the 12. February 2007.

Oops, sorry my bad, got confused with the date. Anyways, I am running gentoo amd64 stable branch (actually using latest available video drivers), my system is up to date. I dare say that with gentoo I get updates of software in general at least as fast as a package based distro. Is it common practice to download random files and build your software against an arbitrary jumble of files? Not here. So, glext.h is owned by media-libs/mesa on my system, I do have the latest stable version (6.5.2-r1) installed, the next versions (7.0.1 and 7.0.2) are both masked on all platforms (7.0.1 was added to portage tree on August, 11th, by the way). As I said, I have no desire to become an ~arch tester, I'll rejoin the bug-reporting forces once my distro says it safe for the rest of my system

[bluap]

On my debian etch system, these are defined when I use mesa-common-dev 6.5.1-0.6 but not if I switch to nvidia-glx-dev 1.0.8776-4 for my GL stuff. Weird that you have a later mesa versions but not the new definitions.

[Florian]

OK, I can't update my system's glext.h because that causes other errors ...

 

this script helped me

use strict;

open IN, "<load_gl_extensions.h";

while (<IN>) {
if (m/extern (PF.+?) EL/) {
 my $ext = $1;
 if (`grep $ext glext.h` =~ m/(typedef .+;)/) {
  my $type = $1;
  $type =~ s/APIENTRYP/\*/;
  print "#ifndef $ext\n"; 
  print " $type\n";
  print "#endif\n";
 }
}
}

 

It outputs all needed typedefs. I piped them into an "osxglext.h" file which I included in load_gl_extensions.h and now it compiles and runs without problems.

 

this helped ...

[Jetchko]

@Ermabwed

I doubt glext.h is owned by media-libs/mesa on ur stable system, actually its owned by app-admin/eselect-opengl. media-libs/mesa-6.5.2-r1 and x11-drivers/nvidia-drivers-100.14.23 come with recent enought glext.h to be able compile elc (i tested both).

You must use "eselect opengl xorg-x11 --impl-headers" to force using glext.h that comes with mesa. Same option with nvidia if u use it.

[Ermabwed]

@Ermabwed

I doubt glext.h is owned by media-libs/mesa on ur stable system, actually its owned by app-admin/eselect-opengl. media-libs/mesa-6.5.2-r1 and x11-drivers/nvidia-drivers-100.14.23 come with recent enought glext.h to be able compile elc (i tested both).

You must use "eselect opengl xorg-x11 --impl-headers" to force using glext.h that comes with mesa. Same option with nvidia if u use it.

equery belongs glext.h

tells me that both eselect-opengl and mesa own the file...

I have an ati card but ati-drivers doesn't own the file. I have to use ati-drivers to be able to play... So, where does this lead me? I ran your command (it's missing "set" by the way) with ati and I'm ending up at the same error...

So, who wants to step up and say ATI crappy linux drivers support? My question is: what does this version of glext.h provide that wasn't in previous versions, i.e. why is it needed?

[Troca]

Couldn't the relevant parts of the extension checking code be surrounded by "#ifdef GL_EXT_foo" to disable it if the extension is missing from the headers. If I understand correctly this code is only for reporting supported extensions to the server. So, if the extension isn't available at compile time it's unlikely to be available at runtime and can be reported missing (assuming the code is compiled on the machine it is executed on). The official client can of course be compile with a new enough GL header.

 

Just my two cents as someone who haven't played for a long time. Still waiting for a gentoo ebuild and some spare time. (Thanks for tagging CVS btw)

[Entropy]

Ok, maybe I am wrong here, but isn't that file totally unrelated to your OpenGL implementation?

 

I mean, the video drivers are usually binary, provided by Nvidia and Ati (not sure about the Intel stuff). So that file is just for the program, not for the video drivers themselves.

 

Even so, the reason why we want tot est cards for those extensions is so that we can see if enough people have them to use them in a later version, so a new header would be eventually needed.

[Ermabwed]

Well, with some help by Jetchko, I got it to compile by switching to xorg opengl, compiling, switching back to ati opengl. The client runs without problems and I don't see more or less messages about missing GL extensions than with the official client (which are GL_ARB_texture_non_power_of_two and GL_EXT_texture_compression_latc; before the update I used to miss the shader extension as well with the CVS client... ). I guess I can only hope a new version of the drivers will include that file (again?).

As for ATI/NVIDIA drivers in general, I compile my own (well, it's just "emerge ati-drivers"); not sure how ATI users in general go about it but for NVIDIA you download a script that compiles the driver against your kernel or possibly (I know opensuse does that) you can get an rpm with the module built against your (generic) kernel.

[KarenRei]

There's no program called "eselect" on my system. And this is a pretty stock Fedora 7 using no special video drivers, and I still get:

 

gcc -march=i686 -Wall -Wdeclaration-after-statement -O0 -ggdb -pipe -DLINUX -DELC -DAFK_FIX -DALPHA_ACTORS -DATI_9200_FIX -DAUTO_UPDATE -DCLICKABLE_CONTINENT_MAP -DCLUSTER_INSIDES -DCOUNTERS -DCUSTOM_LOOK -DCUSTOM_UPDATE -DCXX_MISC -DDEBUG_TIME -DEYE_CANDY -DFONTS_FIX -DFUZZY_PATHS -DIDLE_FIX -DMASKING -DMINES -DMINIMAP -DNEW_ACTOR_ANIMATION -DNEW_ACTOR_SCALE -DNEW_ALPHA -DNEW_FILE_IO -DNEW_LIGHTING -DNEW_SOUND -DNEW_TEX -DNOTEPAD -DOGG_VORBIS -DOPTIONS_I18N -DPNG_SCREENSHOT -DPOPUP -DSFX -DSIMPLE_LOD -DUSE_INLINE -DUSE_SEND_VIDEO_INFO -DZLIB -I/usr/include/SDL -D_GNU_SOURCE=1 -D_REENTRANT -I/usr/include/libxml2 -fno-strict-aliasing -c -o 2d_objects.o 2d_objects.c

In file included from 2d_objects.c:9:

load_gl_extensions.h:281: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘ELglUniformMatrix2x3fv’

load_gl_extensions.h:282: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘ELglUniformMatrix2x4fv’

load_gl_extensions.h:283: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘ELglUniformMatrix3x2fv’

load_gl_extensions.h:284: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘ELglUniformMatrix3x4fv’

load_gl_extensions.h:285: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘ELglUniformMatrix4x2fv’

load_gl_extensions.h:286: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘ELglUniformMatrix4x3fv’

make: *** [2d_objects.o] Error 1

You have mail in /var/spool/mail/meme

 

Can't we just make this code optional? Or declare the decls itself if they're not defined?

[Florian]

There's no program called "eselect" on my system. And this is a pretty stock Fedora 7 using no special video drivers, and I still get:

 

gcc -march=i686 -Wall -Wdeclaration-after-statement -O0 -ggdb -pipe -DLINUX -DELC -DAFK_FIX -DALPHA_ACTORS -DATI_9200_FIX -DAUTO_UPDATE -DCLICKABLE_CONTINENT_MAP -DCLUSTER_INSIDES -DCOUNTERS -DCUSTOM_LOOK -DCUSTOM_UPDATE -DCXX_MISC -DDEBUG_TIME -DEYE_CANDY -DFONTS_FIX -DFUZZY_PATHS -DIDLE_FIX -DMASKING -DMINES -DMINIMAP -DNEW_ACTOR_ANIMATION -DNEW_ACTOR_SCALE -DNEW_ALPHA -DNEW_FILE_IO -DNEW_LIGHTING -DNEW_SOUND -DNEW_TEX -DNOTEPAD -DOGG_VORBIS -DOPTIONS_I18N -DPNG_SCREENSHOT -DPOPUP -DSFX -DSIMPLE_LOD -DUSE_INLINE -DUSE_SEND_VIDEO_INFO -DZLIB -I/usr/include/SDL -D_GNU_SOURCE=1 -D_REENTRANT -I/usr/include/libxml2 -fno-strict-aliasing -c -o 2d_objects.o 2d_objects.c

In file included from 2d_objects.c:9:

load_gl_extensions.h:281: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘ELglUniformMatrix2x3fv’

load_gl_extensions.h:282: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘ELglUniformMatrix2x4fv’

load_gl_extensions.h:283: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘ELglUniformMatrix3x2fv’

load_gl_extensions.h:284: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘ELglUniformMatrix3x4fv’

load_gl_extensions.h:285: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘ELglUniformMatrix4x2fv’

load_gl_extensions.h:286: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘ELglUniformMatrix4x3fv’

make: *** [2d_objects.o] Error 1

You have mail in /var/spool/mail/meme

 

Can't we just make this code optional? Or declare the decls itself if they're not defined?

 

Get the latest glext.h here

http://www.opengl.org/registry/api/glext.h

 

or add the missing defines yourself like I do because I can't just update my system's glext.h.

 

I #include "osxglext.h" in load_gl_extensions.h.

Get it here:

http://www.superfloh.dyndns.org/el/osxglext.h

It has #ifdef guards for all the PFNGL... things in load_gl_extensions.h.

[alvieboy]

What if we ship "glext.h" in EL ?

 

I'm not sure if license permits it, but it can solve some problems if we do.

 

Álvaro

[Florian]

What if we ship "glext.h" in EL ?

 

I'm not sure if license permits it, but it can solve some problems if we do.

Creates new problems, at least on Mac OS X. You can't just exchange the system's glext.h with the official file. Apple always changes something ...

 

I'd prefer to add the needed defines guarded by #ifdef so that system's defines overrule EL's defines and EL only adds missing types.

[Entropy]

Yes, I think that using the #define to add those things directly in EL is a better idea, if the license permits.

[Florian]

License from glext.h

 

/*

** Copyright © 2007 The Khronos Group Inc.

**

** Permission is hereby granted, free of charge, to any person obtaining a

** copy of this software and/or associated documentation files (the

** "Materials"), to deal in the Materials without restriction, including

** without limitation the rights to use, copy, modify, merge, publish,

** distribute, sublicense, and/or sell copies of the Materials, and to

** permit persons to whom the Materials are furnished to do so, subject to

** the following conditions:

**

** The above copyright notice and this permission notice shall be included

** in all copies or substantial portions of the Materials.

**

** THE MATERIALS ARE PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,

** EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF

** MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.

** IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY

** CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT,

** TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE

** MATERIALS OR THE USE OR OTHER DEALINGS IN THE MATERIALS.

*/

 

Legal foobar is nor really my domain, so I'll let some native English speaker decide if we can copy from glext.h.

Edited December 9, 2007 by Florian

[bluap]

Yes, I think that using the #define to add those things directly in EL is a better idea, if the license permits.

As an alternative. Why not #ifdef the 2_1 checking code using the #define provided in glext.h i.e. GL_VERSION_2_1. In the actual el_init_GL_VERSION_2_1() function, the if GL_VERSION_2_1 is not defined just return false as the extension is really not available. I have a working patch for this....

[Entropy]

Yeah, good idea. So long as only the GL_VERSION_2_1 dependent extensions are ifdefed out in case GL_VERSION_2_1 is not defined.

That is, take care not to invalidate all the extensions

[bluap]

Yeah, good idea. So long as only the GL_VERSION_2_1 dependent extensions are ifdefed out in case GL_VERSION_2_1 is not defined.

That is, take care not to invalidate all the extensions

OK, committed to CVS and logged in mantis.

[Jetchko]

Ok, i lost the point on that topic. Why to use #define in system provided glext.h? I think that is not good idea.

Seem in most of linux distros system provided glext.h is outdated and does not connected in any way to what is provided from driver u are using to play el, so in that case u will miss 2.1 extension even in case driver have it. Also that can be easily overlooked later and deploy officialy compiled client without that extension if u use old glext.h. If u want to wrap it in some define better add another FEATURE in make.defaults.

 

That are just my thoughts, ignore them if i'm wrong.

[Florian]

Does not help for OSX.

 

Apple is *very* lazy to keep the files up to date. And I can't just replace the system's glext.h.

 

So I still have to create my own extra include file with #ifndef guards.

[bluap]

Does not help for OSX.

Apple is *very* lazy to keep the files up to date. And I can't just replace the system's glext.h.

So I still have to create my own extra include file with #ifndef guards.

Why exactly does this not help? I have not changed the glext.h, I've made use of #defines in glext.h to enable the extra checking. The only way this would not help is if your glext.h contained the GL_VERSION_2_1 #define but not the actual GL_VERSION_2_1 typedefs etc. That would be particularly slack of Apple.

 

Ok, i lost the point on that topic. ....That are just my thoughts, ignore them if i'm wrong.

I'm sorry but I don't understand what you are suggesting. The point of the checks is to see which features are available on the users machines. If you use a #define in make.conf and the users machine does not contain the GL_VERSION_2_1 stuff, then they will have to remove the make.conf #define and so manually achieve the same as can now be done automatically. Of course, a release binary will have to be build on a machine with GL_VERSION_2_1 available, that would be true even if the #define was in make.conf.

[Florian]

Apple's gl*.h are crap.

 

In file included from 2d_objects.c:9:
load_gl_extensions.h:63: error: parse error before 'ELglCopyTexSubImage3D'
load_gl_extensions.h:63: warning: data definition has no type or storage class
load_gl_extensions.h:64: error: parse error before 'ELglDrawRangeElements'
load_gl_extensions.h:64: warning: data definition has no type or storage class
load_gl_extensions.h:65: error: parse error before 'ELglTexImage3D'
load_gl_extensions.h:65: warning: data definition has no type or storage class
load_gl_extensions.h:66: error: parse error before 'ELglTexSubImage3D'
load_gl_extensions.h:66: warning: data definition has no type or storage class
load_gl_extensions.h:70: error: parse error before 'ELglActiveTexture'
load_gl_extensions.h:70: warning: data definition has no type or storage class
load_gl_extensions.h:71: error: parse error before 'ELglClientActiveTexture'
load_gl_extensions.h:71: warning: data definition has no type or storage class
load_gl_extensions.h:72: error: parse error before 'ELglCompressedTexImage1D'
load_gl_extensions.h:72: warning: data definition has no type or storage class
load_gl_extensions.h:73: error: parse error before 'ELglCompressedTexImage2D'
load_gl_extensions.h:73: warning: data definition has no type or storage class

...

load_gl_extensions.h:516: warning: data definition has no type or storage class
load_gl_extensions.h:517: error: parse error before 'ELglFogCoorddvEXT'
load_gl_extensions.h:517: warning: data definition has no type or storage class
load_gl_extensions.h:518: error: parse error before 'ELglFogCoordfEXT'
load_gl_extensions.h:518: warning: data definition has no type or storage class
load_gl_extensions.h:519: error: parse error before 'ELglFogCoordfvEXT'
load_gl_extensions.h:519: warning: data definition has no type or storage class
2d_objects.c: In function 'draw_2d_object':
2d_objects.c:125: error: called object 'ELglMultiTexCoord2fARB' is not a function
2d_objects.c:128: error: called object 'ELglMultiTexCoord2fARB' is not a function
2d_objects.c:138: error: called object 'ELglMultiTexCoord2fARB' is not a function
2d_objects.c:141: error: called object 'ELglMultiTexCoord2fARB' is not a function
2d_objects.c:151: error: called object 'ELglMultiTexCoord2fARB' is not a function
2d_objects.c:154: error: called object 'ELglMultiTexCoord2fARB' is not a function
2d_objects.c:165: error: called object 'ELglMultiTexCoord2fARB' is not a function
2d_objects.c:168: error: called object 'ELglMultiTexCoord2fARB' is not a function
2d_objects.c: In function 'display_2d_objects':
2d_objects.c:665: error: called object 'ELglActiveTextureARB' is not a function
2d_objects.c:670: error: called object 'ELglActiveTextureARB' is not a function
2d_objects.c:708: error: called object 'ELglActiveTextureARB' is not a function
2d_objects.c:710: error: called object 'ELglActiveTextureARB' is not a function
make: *** [2d_objects.o] Error 1

 

gl.h:#define GL_VERSION_2_0 1

 

None of the PFN... things are defined on OSX.

[alvieboy]

Apple's gl*.h are crap.

None of the PFN... things are defined on OSX.

 

I wonder if we could have a configure script to check these and use individual #ifdefs on each API entry.

 

Could solve the problem, but it would be painfully slow.

 

Álvaro