stormzel Report post Posted May 28, 2009 (edited) Hi to all I Have found "GL BUG" on a maps - C1 Desert Pines/Crystal Caverns Edited May 28, 2009 by stormzel Share this post Link to post Share on other sites
bluap Report post Posted May 28, 2009 I Have found "GL BUG" on a maps - C1 Desert Pines/Crystal Caverns... I can confirm the bug: You are in Crystal Cavern [146,96] Also I note that the quartz crystals have lost some of their colours in the CVS version. The green and purple crystals look blue and pink. I have some images to post but uploads to the gallery appear to be broken. Share this post Link to post Share on other sites
rauch Report post Posted May 29, 2009 This also happens on other locations, like Glacmor school entrance, PL sapphire cave, KJ inside PK Arena and others. the lightning color (at least I guess that it's that) changes depending on your angle of view. Share this post Link to post Share on other sites
hussam Report post Posted May 29, 2009 This also happens on other locations, like Glacmor school entrance, PL sapphire cave, KJ inside PK Arena and others. the lightning color (at least I guess that it's that) changes depending on your angle of view. I get that same problem. it was working in cvs date 20090423 and broke on 20090424 Share this post Link to post Share on other sites
bluap Report post Posted May 29, 2009 I get that same problem. it was working in cvs date 20090423 and broke on 20090424 Darn, I've just been doing the same detective work and that's exactly what I found. The commits by xaphier on 24 April were commented: * Support for new e3d file format (using half floats, compressed normals & tangets, vertex colors) * Support for vertex colors (can be used e.g. for simple ambient occlusion) As shown previously in this thread, they broke some lighting things which xaphier fixed. After the fixes, this current problem existed though no one noticed until now. Hopefully xaphier can take a look... Share this post Link to post Share on other sites
stormzel Report post Posted May 30, 2009 I have noticed recently an error in the menu, have decided to tell about it . With options in make.conf: Bookmark options "Controls" do not find room in the menu The button - "Pin Minimap" and "Minimap Scale" does not work ### Other options (Experimental, unfinished, defunct or otherwise unknown) ### FEATURES += NEW_CURSOR # New coloured cursors made by Emajekral (Experimental) Extract http://users.on.net/~gingerman/sky_cursor-textures.zip into datadir/textures/ Share this post Link to post Share on other sites
bluap Report post Posted May 30, 2009 (edited) I have noticed recently an error in the menu, have decided to tell about it .With options in make.conf: Bookmark options "Controls" do not find room in the menu The button - "Pin Minimap" and "Minimap Scale" does not work ### Other options (Experimental, unfinished, defunct or otherwise unknown) ### FEATURES += NEW_CURSOR # New coloured cursors made by Emajekral (Experimental) Extract http://users.on.net/~gingerman/sky_cursor-textures.zip into datadir/textures/ Fixed: I've modified the tab to use Vegar's scrolling code if NEW_CURSOR is defined. Edited May 30, 2009 by bluap Share this post Link to post Share on other sites
ago Report post Posted August 17, 2009 (edited) I've noticed that the harvesting eyecandy sometimes continues after a harvesting event. This only happens very randomly because of a rare combination of harvest events combined with harvest exp. http://developer.berlios.de/patch/?func=de...p;group_id=1256 The code in text.c checks for a "you stopped harvesting" message and removes the effect. The code in stats.c that handles the harvest exp checks if there is no harvesting effect and decrements a counter from 1. Once the counter reaches 0 it starts a new harvesting effect. The patch resets the counter on every "you stopped harvesting" message to 1 and prevents the stats.c code from restarting the harvesting effect. The bug itself is triggered by two harvest actions which both trigger a mini event. there is no harvest exp message in between which could reset the counter. Edited August 17, 2009 by ago Share this post Link to post Share on other sites
bluap Report post Posted August 18, 2009 I've noticed that the harvesting eyecandy sometimes continues after a harvesting event. This only happens very randomly because of a rare combination of harvest events combined with harvest exp. Darn, another nasty edge case. I'll try your patch then commit it. Thanks. Share this post Link to post Share on other sites
RallosZek Report post Posted August 21, 2009 Local patchset below: "inline function declared but not defined". Also, it's so simple, I've macroed it. This only goes bad if items_text is shadowed by a less then global scope variable, which is bad practice anyway. CUSTOM_UPDATE not defined generates compiler error % cc -vUsing built-in specs.Target: i386-undermydesk-freebsdConfigured with: FreeBSD/i386 system compilerThread model: posixgcc version 4.2.1 20070719 [FreeBSD] Index: items.c =================================================================== RCS file: /cvsroot/elc/elc/items.c,v retrieving revision 1.176 diff -u -r1.176 items.c --- items.c 8 May 2009 23:51:53 -0000 1.176 +++ items.c 21 Aug 2009 07:32:36 -0000 @@ -90,10 +90,12 @@ static void drop_all_handler(); +#ifndef BSD __inline__ GLuint get_items_texture(int no) { return items_text[no]; } +#endif void set_shown_string(char colour_code, const char *the_text) { Index: items.h =================================================================== RCS file: /cvsroot/elc/elc/items.h,v retrieving revision 1.51 diff -u -r1.51 items.h --- items.h 2 Feb 2009 21:06:24 -0000 1.51 +++ items.h 21 Aug 2009 07:32:36 -0000 @@ -162,7 +162,11 @@ * \param no id of the item * \retval GLuint the texture id associated with \a no. */ +#ifndef BSD __inline__ GLuint get_items_texture(int no); +#else +#define get_items_texture(__no) (GLuint)items_text[__no] +#endif /*! * \ingroup items_window Index: new_actors.c =================================================================== RCS file: /cvsroot/elc/elc/new_actors.c,v retrieving revision 1.166 diff -u -r1.166 new_actors.c --- new_actors.c 10 May 2009 01:44:09 -0000 1.166 +++ new_actors.c 21 Aug 2009 07:32:37 -0000 @@ -261,7 +261,11 @@ char buffer[256]; // check to see if ANY processing needs to be done +#ifdef CUSTOM_UPDATE if(!path || !*path || !custom_clothing) return; +#else + if(!path || !*path ) return; +#endif /* Check if custom1 has path readable */ safe_snprintf(buffer, sizeof(buffer), "%s%s", custom1, path); Share this post Link to post Share on other sites
ago Report post Posted August 21, 2009 (edited) Darn, another nasty edge case. I'll try your patch then commit it. Thanks. Got another one. This time it was resync (effect off), 1 harvest (counter to 0), mini event Since there was no effect the counter did not get reset and the effect restarted. Doh diff --git a/text.c b/text.c index d367f1f..696108c --- a/text.c +++ b/text.c @@ -560,11 +560,11 @@ int filter_or_ignore_text (char *text_to_add, int len, int size, Uint8 channel) ((my_strncompare(text_to_add+1, "You need to have a ", 19) && strstr(text_to_add, "order to harvest") != NULL))) { harvesting = 0; + harvesting_effect_restart_count = 1; if (harvesting_effect_reference != NULL) { ec_recall_effect(harvesting_effect_reference); harvesting_effect_reference = NULL; - harvesting_effect_restart_count = 1; } } else if (is_death_message(text_to_add+1)) { Edited August 21, 2009 by ago Share this post Link to post Share on other sites
bluap Report post Posted August 21, 2009 "inline function declared but not defined". Also, it's so simple, I've macroed it. This only goes bad if items_text is shadowed by a less then global scope variable, which is bad practice anyway. CUSTOM_UPDATE not defined generates compiler error I've committed the CUSTOM_UPDATE compile fix. The inline one is curious. Most other __inline__ definitions use "static __inline__" and define function bodies in the headers. There are a few cases where this would not work but this particular function does not appear to be one of them. Does this alternative change work on your system? Index: items.c =================================================================== RCS file: /cvsroot/elc/elc/items.c,v retrieving revision 1.176 diff -a -u -r1.176 items.c --- items.c 8 May 2009 23:51:53 -0000 1.176 +++ items.c 21 Aug 2009 15:37:04 -0000 @@ -90,11 +90,6 @@ static void drop_all_handler(); -__inline__ GLuint get_items_texture(int no) -{ - return items_text[no]; -} - void set_shown_string(char colour_code, const char *the_text) { inventory_item_string[0] = to_color_char(colour_code); Index: items.h =================================================================== RCS file: /cvsroot/elc/elc/items.h,v retrieving revision 1.51 diff -a -u -r1.51 items.h --- items.h 2 Feb 2009 21:06:24 -0000 1.51 +++ items.h 21 Aug 2009 15:37:04 -0000 @@ -162,7 +162,10 @@ * \param no id of the item * \retval GLuint the texture id associated with \a no. */ -__inline__ GLuint get_items_texture(int no); +static __inline__ GLuint get_items_texture(int no) +{ + return items_text[no]; +} /*! * \ingroup items_window Got another one. OK. I committed that change too. Thanks both. Share this post Link to post Share on other sites
RallosZek Report post Posted August 22, 2009 Inline is static by default, because a compiler can't inline what it doesn't know. If you declare extern, linking final binary fails with undefined functions. Sure, providing the function definition in the header works, I'm just curious why one would do so when all this function does is return the index of a global array as a GLuint, which is the same as casting the accessed member, minus a function pointer. Share this post Link to post Share on other sites
bluap Report post Posted September 1, 2009 Inline is static by default, because a compiler can't inline what it doesn't know. If you declare extern, linking final binary fails with undefined functions. OK. Sure, providing the function definition in the header works, I'm just curious why one would do so when all this function does is return the index of a global array as a GLuint, which is the same as casting the accessed member, minus a function pointer. I wondered the same. May be the function use to do more... Anyway the function is called from many places so changing it sounds like a waste of time. Adding a platform specific macro, when defining it in the header works, sounds OTT too. So IMHO, the header definition wins. I'll make that change in CVS unless anyone objects..... Share this post Link to post Share on other sites
popeye Report post Posted September 3, 2009 ** has logged on. ** has logged on. ** has logged on. ** has logged on. ** has logged on. ** has logged on. ** has logged on. Today is the 18th day in the month of Viasia, the year 0020, Age of the Eternals Game Time: 05:53:58 None of the folks are logged on. Share this post Link to post Share on other sites
bluap Report post Posted September 3, 2009 ** has logged on.** has logged on. ... None of the folks are logged on. Are you sure you have the latest CVS? This bug should be fixed. Please see here, second paragraph. Share this post Link to post Share on other sites
hussam Report post Posted September 5, 2009 I get that same problem. it was working in cvs date 20090423 and broke on 20090424 Darn, I've just been doing the same detective work and that's exactly what I found. The commits by xaphier on 24 April were commented: * Support for new e3d file format (using half floats, compressed normals & tangets, vertex colors) * Support for vertex colors (can be used e.g. for simple ambient occlusion) As shown previously in this thread, they broke some lighting things which xaphier fixed. After the fixes, this current problem existed though no one noticed until now. Hopefully xaphier can take a look... Any news on this? Maybe while Xaphier is away, someone else can take a look at it? Share this post Link to post Share on other sites
Sir_Odie Report post Posted September 5, 2009 As these changes aren't really used/needed by the current client (I guess they are important for the new engine), i simply use the older CVS-versions of the affected files and the client works great without any color problems... Share this post Link to post Share on other sites
hussam Report post Posted September 5, 2009 As these changes aren't really used/needed by the current client (I guess they are important for the new engine), i simply use the older CVS-versions of the affected files and the client works great without any color problems... which files? all I know is the date. Share this post Link to post Share on other sites
bluap Report post Posted September 5, 2009 Any news on this? Maybe while Xaphier is away, someone else can take a look at it? I've not here from Xaphier. I did have a quick look at the code but don't really understand the way the lighting works. If you modify 3d_objects.c line 111 to remove the colour setting (that is not working anyway), the red/green/blue ground colouring stops but the self lighting of the quartz still does not happen: Index: 3d_objects.c =================================================================== RCS file: /cvsroot/elc/elc/3d_objects.c,v retrieving revision 1.185 diff -a -u -r1.185 3d_objects.c --- 3d_objects.c 26 Apr 2009 00:44:22 -0000 1.185 +++ 3d_objects.c 5 Sep 2009 17:28:20 -0000 @@ -108,7 +108,7 @@ if (object_id->self_lit && (!is_day || dungeon) && use_lightning) #endif { - glMaterialfv(GL_FRONT, GL_EMISSION, object_id->color); + glMaterialfv(GL_FRONT, GL_EMISSION, zero); } else { If you replace the glMaterialfv() calls with standard glColor() settings, you can restore the self lighting and prevent the red/green/blue ground colouring but new selection no longer works: Index: 3d_objects.c =================================================================== RCS file: /cvsroot/elc/elc/3d_objects.c,v retrieving revision 1.185 diff -a -u -r1.185 3d_objects.c --- 3d_objects.c 26 Apr 2009 00:44:22 -0000 1.185 +++ 3d_objects.c 5 Sep 2009 17:32:36 -0000 @@ -108,11 +108,11 @@ if (object_id->self_lit && (!is_day || dungeon) && use_lightning) #endif { - glMaterialfv(GL_FRONT, GL_EMISSION, object_id->color); + glColor4f(object_id->color[0], object_id->color[1], object_id->color[2], object_id->color[3]); } else { - glMaterialfv(GL_FRONT, GL_EMISSION, zero); + glColor4f(1.0f, 1.0f, 1.0f, 1.0f); } CHECK_GL_ERRORS(); One of these days I'll learn some more about openGL.... Share this post Link to post Share on other sites
Trinita Report post Posted September 29, 2009 Hello, I'm a developer on then french EL project and we meet the same problem. I succeeded in using the "glMaterialfv" command when I enabled GL_LIGHTING. Look at this : { glMaterialfv(GL_FRONT, GL_EMISSION, object_id->color ); } else { glMaterialfv(GL_FRONT, GL_EMISSION, zero ); } glEnable(GL_LIGHTING); However, when I'm enabling that code, the "NEW_SELECTION" option can't be used I also tried to use glDisable(GL_LIGHTING); on line 277... But if "NEW_SELECTION" is enabled, I'm able to see a lot of object but I'm unable to use those objets (I see the boat flags but I can't use them as teleporters) Share this post Link to post Share on other sites
hussam Report post Posted October 20, 2009 (edited) Current CVS doesn't build for me. [hussam@LARS elc]$ make -f Makefile.linux CC 2d_objects.o In file included from 2d_objects.c:10: load_gl_extensions.h:69: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘ELglClientActiveTexture’ load_gl_extensions.h:77: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘ELglLoadTransposeMatrixd’ load_gl_extensions.h:78: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘ELglLoadTransposeMatrixf’ load_gl_extensions.h:79: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘ELglMultTransposeMatrixd’ load_gl_extensions.h:80: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘ELglMultTransposeMatrixf’ load_gl_extensions.h:81: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘ELglMultiTexCoord1d’ load_gl_extensions.h:82: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘ELglMultiTexCoord1dv’ load_gl_extensions.h:83: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘ELglMultiTexCoord1f’ load_gl_extensions.h:84: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘ELglMultiTexCoord1fv’ load_gl_extensions.h:85: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘ELglMultiTexCoord1i’ load_gl_extensions.h:86: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘ELglMultiTexCoord1iv’ load_gl_extensions.h:87: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘ELglMultiTexCoord1s’ load_gl_extensions.h:88: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘ELglMultiTexCoord1sv’ load_gl_extensions.h:89: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘ELglMultiTexCoord2d’ load_gl_extensions.h:90: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘ELglMultiTexCoord2dv’ load_gl_extensions.h:91: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘ELglMultiTexCoord2f’ load_gl_extensions.h:92: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘ELglMultiTexCoord2fv’ load_gl_extensions.h:93: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘ELglMultiTexCoord2i’ load_gl_extensions.h:94: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘ELglMultiTexCoord2iv’ load_gl_extensions.h:95: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘ELglMultiTexCoord2s’ load_gl_extensions.h:96: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘ELglMultiTexCoord2sv’ load_gl_extensions.h:97: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘ELglMultiTexCoord3d’ load_gl_extensions.h:98: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘ELglMultiTexCoord3dv’ load_gl_extensions.h:99: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘ELglMultiTexCoord3f’ load_gl_extensions.h:100: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘ELglMultiTexCoord3fv’ load_gl_extensions.h:101: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘ELglMultiTexCoord3i’ load_gl_extensions.h:102: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘ELglMultiTexCoord3iv’ load_gl_extensions.h:103: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘ELglMultiTexCoord3s’ load_gl_extensions.h:104: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘ELglMultiTexCoord3sv’ load_gl_extensions.h:105: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘ELglMultiTexCoord4d’ load_gl_extensions.h:106: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘ELglMultiTexCoord4dv’ load_gl_extensions.h:107: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘ELglMultiTexCoord4f’ load_gl_extensions.h:108: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘ELglMultiTexCoord4fv’ load_gl_extensions.h:109: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘ELglMultiTexCoord4i’ load_gl_extensions.h:110: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘ELglMultiTexCoord4iv’ load_gl_extensions.h:111: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘ELglMultiTexCoord4s’ load_gl_extensions.h:112: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘ELglMultiTexCoord4sv’ make: *** [2d_objects.o] Error 1 I upgraded two days ago to GCC 4.4.2 Any compiler experts? Edited October 20, 2009 by hussam Share this post Link to post Share on other sites
bluap Report post Posted October 20, 2009 (edited) Current CVS doesn't build for me. [hussam@LARS elc]$ make -f Makefile.linux CC 2d_objects.o In file included from 2d_objects.c:10: load_gl_extensions.h:69: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘ELglClientActiveTexture’ ... make: *** [2d_objects.o] Error 1 I upgraded two days ago to GCC 4.4.2 Any compiler experts? I came across the same error when compiling for Ubuntu Karmic. I think it is due to newer version of gl.h rather than the compiler. I have not found the solution yet but the temporary work around was a rather nasty hack, apologies to all open GL experts... Index: platform.h =================================================================== RCS file: /cvsroot/elc/elc/platform.h,v retrieving revision 1.21 diff -a -u -r1.21 platform.h --- platform.h 29 Apr 2009 13:28:08 -0000 1.21 +++ platform.h 20 Oct 2009 22:38:53 -0000 @@ -78,6 +78,10 @@ #else #define GL_GLEXT_LEGACY #include <GL/gl.h> + // #undef is a temporary fix for new gl.h files + // until I find out how to do it correctly.... + #undef GL_VERSION_1_2 + #undef GL_VERSION_1_3 #include <GL/glu.h> #include "glext.h" #endif Edited October 20, 2009 by bluap Share this post Link to post Share on other sites
hussam Report post Posted October 20, 2009 it's because mesa 7.6 update then. Share this post Link to post Share on other sites
popeye Report post Posted November 1, 2009 (edited) it's because mesa 7.6 update then. I updated to Karmic also. *removed channel from photo.* Edited November 1, 2009 by popeye Share this post Link to post Share on other sites