Florian Report post Posted December 10, 2007 I wonder if we could have a configure script to check these and use individual #ifdefs on each API entry. The C preprocessor sorts that out: http://www.superfloh.dyndns.org/el/osxglext.h Share this post Link to post Share on other sites
Jetchko Report post Posted December 10, 2007 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. The points is that large number linux users use nvidia/ati binary drivers which have opengl 2.1 support but system installed glext.h usualy is outdated and does not have these defines. Result of compiling elc with your changes is that you will miss what actually graphics driver supports. If i dont get error using system included glext.h i will never know that there is some problem. So let leave users that know how to deal with that issue resolve it in correct way, for others leave FEATURE in make.defaults and that is. In your current ways u hide problem, not resolve it. Share this post Link to post Share on other sites
alvieboy Report post Posted December 10, 2007 I wonder if we could have a configure script to check these and use individual #ifdefs on each API entry. The C preprocessor sorts that out: http://www.superfloh.dyndns.org/el/osxglext.h So you're saying that, if we #include the original #define's there, we can wrap them around our checks? like (its just an example - don't even bug me about this one): #if defined(MACOS) && defined (PFNGLMULTTRANSPOSEMATRIXFPROC) extern PFNGLMULTTRANSPOSEMATRIXFPROC ELglMultTransposeMatrixf; #else (void *ELglMultTransposeMatrixf)(void) = NULL; #endif Álvaro Share this post Link to post Share on other sites
Florian Report post Posted December 10, 2007 (edited) So you're saying that, if we #include the original #define's there, we can wrap them around our checks? Too complicated. I have a small perl script which greps all those PDF* defines from the latest glext.h and creates this: #ifndef PFNGLCOPYTEXSUBIMAGE3DPROC typedef void (* PFNGLCOPYTEXSUBIMAGE3DPROC) (GLenum target, GLint level, GLint xoffset, GLint yoffset, GLint zoffset, GLint x, GLint y, GLsizei width, GLsizei height); #endif /EDIT bluap's changes work perfectly for my 6.06 ubuntu linux Edited December 10, 2007 by Florian Share this post Link to post Share on other sites
bluap Report post Posted December 10, 2007 (edited) The points is that large number linux users use nvidia/ati binary drivers which have opengl 2.1 support but system installed glext.h usually is outdated and does not have these defines. Result of compiling elc with your changes is that you will miss what actually graphics driver supports. If i dont get error using system included glext.h i will never know that there is some problem. So let leave users that know how to deal with that issue resolve it in correct way, for others leave FEATURE in make.defaults and that is. In your current ways u hide problem, not resolve it. The point actually is that people who know what they are doing can do the right thing - what ever that is. With the code broken as it was, casual compilers could not compile the the CVS client at all and soon gave up. I use Linux (Debian etch) with the nvidia binary drivers. My gext.h was fine with the mesa-dev version in place. I deliberately removed that and installed the broken nvidia version to reproduce (or so I assumed) the problem. Apple's gl*.h are crap. So Florian, I guess your compile is broken on more that just 2.1 additions. When I regressed my packages to reproduce the problem, it was just the 2.1 stuff that was missing. I hadn't realised the depth of crappiness of the Apple stuff. So where do we go from here? Edited December 10, 2007 by bluap Share this post Link to post Share on other sites
Entropy Report post Posted December 10, 2007 @Jetchko Can't the Linux users just download the new glext.h? I don't really understand the problem. Share this post Link to post Share on other sites
Jetchko Report post Posted December 11, 2007 @Jetchko Can't the Linux users just download the new glext.h? I don't really understand the problem. Yes linux users can download new glext.h (btw, that is not good idea for source based linux distro as this can lead to other problems) but why? Imagine that i'm not running recent enought linux distro and have glext.h without these defines, but have recent graphics card with recent driver for that card. Now, I make fresh checkout from cvs and compile elc and I dont get any error. From where i can know that i need other (new) glext.h? And while goal of this part of code is to collect information for graphics cards that are used to play game, with example above u will miss information for opengl-2.1 extensions of my card. On other side depending of installed glext.h to see which features are available on the users machines is wrong in case of binary only drivers anyway. And I think that alvieboy's idea to ship with own glext.h is good (maybe best?) idea. Windows users do that already, Mac users do some additional magic too, and i think that will solve problem in better way for linux/*bsd users. Share this post Link to post Share on other sites
Entropy Report post Posted December 11, 2007 Ok, I guess that shipping our own glext.h is not a bad idea. Can someone add the code to include that file from our path, rather than the system path? And it should be done only for Linux/*BSD for now. Share this post Link to post Share on other sites
Florian Report post Posted December 11, 2007 Can someone add the code to include that file from our path, rather than the system path? And it should be done only for Linux/*BSD for now. First draft: http://el.beplacid.net/bugs/view.php?id=42 Share this post Link to post Share on other sites
0ctane Report post Posted December 12, 2007 Since many people are requesting an EL client for older Mac OSX systems (specifically OS X 10.3), I have been attempting to do the build. Note, building on 10.4+ is fine for me, and the problems below only occur (for me) on a 10.3.9 system. Anyhow, I grabbed the latest glext.h and replaced my system copies with it. Without Florian's patches, I get errors: load_gl_extensions.h:60: data definition has no type or storage class load_gl_extensions.h:60: type defaults to `int' in declaration of `ELglCopyTexSubImage3D' load_gl_extensions.h:60: error: parse error before "ELglCopyTexSubImage3D" load_gl_extensions.h:61: data definition has no type or storage class load_gl_extensions.h:61: type defaults to `int' in declaration of `ELglDrawRangeElements' load_gl_extensions.h:61: error: parse error before "ELglDrawRangeElements" ... So, this replicates Florian's problem from post 369. I tried Florian's patches, but they just give me: glext.h:3762: error: `PFNGLGENQUERIESPROC' previously declared here glext.h:3762: error: `PFNGLGENQUERIESPROC' previously declared here glext.h:3763: error: `PFNGLDELETEQUERIESPROC' previously declared here ... This basically happens for all the PFNGL calls. I am not sure the whole "#ifndef PFNGL*" setup is appropriate since there is never really a "#define PFNGL*", right? There are only typedefs. Or am I thinking about this wrong? Florian, does your elglext.h necessitate an original OS X glext.h file? Another thought, the latest SDL_opengl.h has what is esentially a glext version 29 in it. Couldn't we just use this, or are there PFNGL* calls not covered by GL_GLEXT_VERSION 29? Share this post Link to post Share on other sites
rmiles Report post Posted December 12, 2007 I attempted to build on a mac (leopard osx 10.5.1 according to the instructions given by octane but I get bad formed function definitions and of GL related format issues. I put the gltext.h file inplace of the one on the system and used the data from octane's client. Is there some new instructions on how to get this to build? Share this post Link to post Share on other sites
Florian Report post Posted December 12, 2007 (edited) Florian, does your elglext.h necessitate an original OS X glext.h file? Yes, I still have OSX's glext.h which I include by -isysroot /Developer/SDKs/MacOSX10.4u.sdk . That's why I added #ifndef to all those PFN* things, although IIRC OSX's glext.h doesn't define/typedef any of them. I gave up to build EL or my 10.3.9 system. /EDIT another thing: APIENTRY is not defined on OSX ... Edited December 12, 2007 by Florian Share this post Link to post Share on other sites
0ctane Report post Posted December 14, 2007 I attempted to build on a mac (leopard osx 10.5.1 according to the instructions given by octane but I get bad formed function definitions and of GL related format issues. I put the gltext.h file inplace of the one on the system and used the data from octane's client. Is there some new instructions on how to get this to build? This is not really a CVS issue. Contact me via PM so that we can hopefully figure out how to get my instructions working for you (I only posted them a week ago, so there might be little details missing). Share this post Link to post Share on other sites
Florian Report post Posted December 23, 2007 I created a patch https://developer.berlios.de/patch/?func=de...p;group_id=1256 to print different warnings for sunset/sunrise. Share this post Link to post Share on other sites
Florian Report post Posted December 29, 2007 (edited) error: threads.h: No such file or directory The only "threads.h" I have on OSX is libxml2's threads.h. Is that the right one? Edited December 29, 2007 by Florian Share this post Link to post Share on other sites
bluap Report post Posted December 29, 2007 (edited) error: threads.h: No such file or directory The only "threads.h" I have on OSX is libxml2's threads.h. Is that the right one? Same on Linux. As it's in "", was it a new file missed from the cvs commit? Edited December 29, 2007 by bluap Share this post Link to post Share on other sites
Florian Report post Posted December 29, 2007 Same on Linux. As it's in "", was it a new file missed from the cvs commit? After looking at the changes in CVS I guess we miss a file. CHECK_AND_LOCK_MUTEX is not in our code and google can't find it either, so I guess Xaphier forgot to add threads.h ... Share this post Link to post Share on other sites
bluap Report post Posted December 29, 2007 Same on Linux. As it's in "", was it a new file missed from the cvs commit? After looking at the changes in CVS I guess we miss a file. CHECK_AND_LOCK_MUTEX is not in our code and google can't find it either, so I guess Xaphier forgot to add threads.h ... I've just send Xaphier a forum pm in case he's not checking this thread Share this post Link to post Share on other sites
Drakos7 Report post Posted December 29, 2007 Grrrr... Share this post Link to post Share on other sites
Xaphier Report post Posted December 29, 2007 Sorry, now the file is in cvs. Share this post Link to post Share on other sites
bluap Report post Posted January 3, 2008 (edited) Xaphier's latest changes to fix frame buffer problem now, repeatably segv my client while loading the game. It's probably because my graphics card does not support using the frame buffer. But that depth_bits value looks a bit bad too. nVidia Corporation NV28 [GeForce4 Ti 4200 AGP 8x] (rev a1) Driver version 1.0.8776 under Debian Linux Default compile options. I'll have a look but Xaphier is probably a better bet to fix it. Here's the back trace: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1225992480 (LWP 3012)] 0x00000000 in ?? () (gdb) bt full #0 0x00000000 in ?? () No symbol table info available. #1 0x08095088 in make_depth_framebuffer (width=512, height=512, fbo=0x8372984, fbo_texture=0x8372980) at framebuffer.c:422 depth_bits = -1213488812 depth_format = 0 #2 0x08095291 in change_depth_framebuffer_size (width=512, height=512, fbo=0x8372984, fbo_texture=0x8372980) at framebuffer.c:460 No locals. #3 0x080decb6 in change_shadow_framebuffer_size () at shadows.c:74 No locals. #4 0x080dec87 in make_shadow_framebuffer () at shadows.c:69 No locals. #5 0x080842d0 in change_shadow_map_size (pointer=0x836f078, value=1) at elconfig.c:726 index = 1 size = 512 i = 3 max_size = 720 error = 0 error_str = ",���� \217��\000&\fг,\f,��\v� \217�,x���\000&\f�\217��@���h�!\f\b!\217�p�\235�@���h�!\f����\000\000 \000\000X!\217�`�!\f�\000&\f,!\217�\004\000\000\000��\207�����\000\000\000 \000\030!\217�A�\204�h�!\f��\207�(!\217�M�\202�h�!\f��\207�X!\217��� \202�h�!\fS!\217�X!\217���\202�\024\230\035\b>\230\035\b3%\217�\024�\t\b� \000&\f�\217��8%\217��i\024\b3%\217�,%\217�3%\217�"... array = {256, 512, 768, 1024, 1280, 1536, 1792, 2048, 3072, 4096} #6 0x08084eaa in check_option_var (name=0x81c7f60 "shadow_map_size") at elconfig.c:1192 i = 3 value_i = 1 value_f = -2.04518219e-05 value_s = 0xb7f3fce0 "" #7 0x08083b08 in build_fbos () at elconfig.c:241 No locals. #8 0x08083a2e in update_fbos () at elconfig.c:248 No locals. #9 0x08084cd4 in change_frame_buffer (fb=0x8371144) at elconfig.c:1065 No locals. #10 0x08084f0e in check_option_var (name=0x81c80b4 "use_frame_buffer") at elconfig.c:1199 i = 85 value_i = 0 value_f = 3 value_s = 0x0 #11 0x08084fe8 in check_options () at elconfig.c:1221 No locals. #12 0x080a4911 in init_stuff () at init.c:783 seed = 136094906 file_name = "\034\bu�\235��@�\v�'\217��\212\017\bx��\vU�\034\b\034A�\vA� \034\b��\034\b\000\000\000\000H(\217�,Z\b\bU�\034\b\034A�\vA�\034\b�� \034\b�\000\000\000\t\000\000\000\000\000\000\000\177\f\177\003\000\000\200? \001V\001\000�\210�\v@���\204(\217�\214�6\b\214�6\ba\000\000\000\000 \000\000\000x.�\v�&�\v�\211�\v\210+�\v�\217���(\217��{\b\b\t\000\000 \000U�\034\bQ�\034\b\214�6\bT7\b\b\000\000\000\000A�\034\b��\034\b\005 \000\000\000A7\b\b\203�\v\b\000\000\000\000\000\000�?\232\231"... i = 136094893 config_location = "�\vOA�\vOA�\vOA�\v�A�\vIB�\vOA�\vIB�\v", '\0' <repeats 20 times>, "\031\234\000\000\000\000\000\000 \b��\000\000\000\001\000\000\000\000�\001\000\000h\006���@�\v�\a�� \000\000\000\000�\217���\217������`B�\vP'\217�R�\235�@���Vͩ� \004\000\000\000p���\210���I\000\000\000@\211��\000\000\000\000\001 \000\000\000\210\001\000\000\210\001\000\000���\vA\203k�Vͩ�0��\v� \217��p?�\v@����'\217���\235�@��� /�\vp���"... cfgdir = 0x0 #13 0x080bc5d2 in main (argc=2, argv=0xbf8f2984) at main.c:305 No locals. edit: added that I'm usiing default compile options Edited January 3, 2008 by bluap Share this post Link to post Share on other sites
bluap Report post Posted January 3, 2008 Xaphier's latest changes to fix frame buffer problem now, repeatably segv my client while loading the game. It's probably because my graphics card does not support using the frame buffer. Adding the following check fixes things, is that the correct solution Xaphier? Index: elconfig.c =================================================================== RCS file: /cvsroot/elc/elc/elconfig.c,v retrieving revision 1.246 diff -a -u -r1.246 elconfig.c --- elconfig.c 3 Jan 2008 09:42:48 -0000 1.246 +++ elconfig.c 3 Jan 2008 14:22:22 -0000 @@ -722,8 +722,11 @@ } shadow_map_size = size; - destroy_shadow_mapping(); - make_shadow_framebuffer(); + if (have_extension(ext_framebuffer_object)) + { + destroy_shadow_mapping(); + make_shadow_framebuffer(); + } } else { Share this post Link to post Share on other sites
Drakos7 Report post Posted January 3, 2008 That patch works for me on my Intel Corporation 82945G/GZ Integrated Graphics Controller Share this post Link to post Share on other sites
ago Report post Posted January 3, 2008 shader/noise.c links directly to glTexImage3d which is not exported in windows openlg32.dll. The patch uses the dynamicly resolved function instead. Index: shader/noise.c =================================================================== RCS file: /cvsroot/elc/elc/shader/noise.c,v retrieving revision 1.6 diff -u -r1.6 noise.c --- shader/noise.c 16 Oct 2007 23:56:53 -0000 1.6 +++ shader/noise.c 30 Nov 2007 13:17:39 -0000 @@ -257,7 +257,7 @@ glTexParameterf(GL_TEXTURE_3D, GL_TEXTURE_WRAP_R, GL_REPEAT); glTexParameterf(GL_TEXTURE_3D, GL_TEXTURE_MAG_FILTER, GL_LINEAR); glTexParameterf(GL_TEXTURE_3D, GL_TEXTURE_MIN_FILTER, GL_LINEAR); - glTexImage3D(GL_TEXTURE_3D, 0, texture_format, size, size, size, 0, input_format, GL_UNSIGNED_BYTE, data); + ELglTexImage3D(GL_TEXTURE_3D, 0, texture_format, size, size, size, 0, input_format, GL_UNSIGNED_BYTE, data); glBindTexture(GL_TEXTURE_3D, 0); free(data); The NULL check might not be required as gltexImage3d is OpenGL 1.2 and every shader enabled OpenGL should be at least Version 1.2. Anyway, here is the check in the shader init. Index: shader/shader.c =================================================================== RCS file: /cvsroot/elc/elc/shader/shader.c,v retrieving revision 1.8 diff -u -r1.8 shader.c --- shader/shader.c 7 Sep 2007 01:08:15 -0000 1.8 +++ shader/shader.c 30 Nov 2007 13:35:32 -0000 @@ -7,6 +7,8 @@ #include "../load_gl_extensions.h" #include "../misc.h" #include "../io/elfilewrapper.h" +#include "../text.h" +#include "../client_serv.h" GLuint noise_tex; @@ -244,6 +246,9 @@ int is_shader_supported() { + if (ELglTexImage3D == NULL) + return 0; + if (have_extension(arb_fragment_program) && have_extension(arb_vertex_program) && have_extension(arb_fragment_shader) && have_extension(arb_vertex_shader) && have_extension(arb_shader_objects) && have_extension(arb_shading_language_100)) Share this post Link to post Share on other sites
Xaphier Report post Posted January 3, 2008 Xaphier's latest changes to fix frame buffer problem now, repeatably segv my client while loading the game. It's probably because my graphics card does not support using the frame buffer. Adding the following check fixes things, is that the correct solution Xaphier? Index: elconfig.c =================================================================== RCS file: /cvsroot/elc/elc/elconfig.c,v retrieving revision 1.246 diff -a -u -r1.246 elconfig.c --- elconfig.c 3 Jan 2008 09:42:48 -0000 1.246 +++ elconfig.c 3 Jan 2008 14:22:22 -0000 @@ -722,8 +722,11 @@ } shadow_map_size = size; - destroy_shadow_mapping(); - make_shadow_framebuffer(); + if (have_extension(ext_framebuffer_object)) + { + destroy_shadow_mapping(); + make_shadow_framebuffer(); + } } else { I will fix it. The mistake I made is not checking for FBO befor calling make_shadow_framebuffer. destroy_shadow_mapping should work, but must get called allways, because it do different things if we have FBO support or not. Share this post Link to post Share on other sites
