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)

Sounds good, Torg! (Unfortunately I just saw that uberlord, who IIRC maintained the EL ebuild, has retired as a gentoo developer.) See you all in EL after the update...

There seems to have been source releases up until 1.1.2 (see ftp://ftp.berlios.de/pub/elc), but you're right that there has been none for the more resent releases. The gentoo maintainer has rolled his own source package from cvs since then. The last one was a problem since cvs was never tagged (there are tags up to 1.3.3 only). So please consider doing "cvs tag ELC_15" at least...

Seeing all the nice additions to EL I consider starting to play again after the update. Since I use gentoo linux I'd like to install though an ebuild as is the usual way in gentoo. This requires a source package because ebuilds compile from sources rather than install binaries if possible. Since the last release was missing a source package I now post this reminder to whoever does the release. Please provide a source .tar.gz or .zip or something with the sources the official client was built from, and/or tag the cvs repository on the revision that was used. Thank you in advance and thanks for EL!

I'm no expert at blender by I have it installed so I did a quick test. I made one triangle, duplicated it and flipped the normals on the copy. Then I exported to wavefront .obj format (including normals): # Blender3D v243 OBJ File: normaltest.blend # www.blender3d.org o Plane_Plane.001 v 1.000000 -0.000000 -1.000000 v -1.000000 0.000000 1.000000 v -1.000000 -0.000000 -1.000000 v 4.000000 -0.000000 -1.000000 v 2.000000 0.000000 1.000000 v 2.000000 -0.000000 -1.000000 vn 0.000000 -1.000000 0.000000 vn 0.000000 1.000000 0.000000 usemtl (null) usemtl (null) s 1 f 1//1 2//1 3//1 s 1 f 4//2 6//2 5//2 As you can see the normals are flipped and the order of the vertices are reversed. So there should be no problem.

Shadows due to overlapping windows is there in eternal-lands-1.3.3 installed through gentoo portage too, so it is old. It's only visible in daylight with shadow mapping on and outside a rectangle centered on the character (the shadow map texture?). But this is off topic in this thread since it's clearly not introduced by eyecandy.

Right, start an F9 fire and zoom, alternating between hitting page-up/page-down seems best. You may need to walk a few steps away in some direction and turn around until you get the biggest effect. If you haven't done so already save my screen shots and flip though them in an image viewer that change pictures fast (I used "feh").

I don't have any program installed for capturing video, sorry, but I managed to get some stills. If you flip though them fast you'll see the flickering I'm talking about. There is a F9 fire just to the right, in front of my character, the particles don't pass in front of him. Not zooming: Zooming out: Zooming in: In particular notice the left (in the picture) of the chest in the out-picture and the crotch area in the in-picture. PS. I noticed another funny effect: If you move a (small) window infront of the EL window it causes strange shadows in the EL world Something with the stencil buffer I guess.

I get the exact same flickering however I set the point particle option in advanced video settings (point particle extension is reported as found and used when I start el). Now it was daytime and I only saw the flickering on my own character not the ground. It flickers in orange on the side facing the fire while zooming.

I have another bug/glitch for you KarenRei: It may have to be night (only tested at night near the beam). Create a F9 fire, stand near it and zoom in/out. The light from the fire flickers. What I mean is that while you zoom in the ground looks darker and your character is lit more from below as if the light source had moved down with the camera and while you zoom out the ground looks brighter and your character is lit more from above as if the light source has moved up with the camera. Directly after you stop zooming (the frame after?) the lighting is correct again. My guess is that the light position is somehow specified relative to the camera and not to the world and its position is adjusted too late. My sysinfo: Gentoo Linux x86 stable on an Athlon XP 2400+ GeForce4 Ti 4200 with nvidia-drivers-1.0.8776 CVS update less than 1 hour ago Default FEATURES minus AUTO_UPDATE

If I remember correctly since I last did windows programming there are some functions called QueryPerformanceCounter and QueryPerformanceTimer or something like that.

Compile with $ gcc invsqrt.c -S -O2 -fno-strict-aliasing and look at the generated code. The difference between invsqrt and invsqrt2 is not that big. A quick look and I think there may be two additional stores to the stack in my version. The stack is in cache memory so that is not a big impact I think. Is it worth the extra complication of having a separate file compiled with different options, I don't know? Oh, I'm typing too slow, I see you already answered this yourself, well...

Adding -fno-strict-aliasing is just a workaround. The solution is to use the invsqrt2 function in my example code. The compiler can make better optimizations if you fix the code to follow the strict aliasing rule and compile with -fstrict-aliasing (the default with -O).

I have some information about the invsqrt problem. The problem is that optimization passes in the compiler assumes the strict aliasing rule. E.g. it assumes that a pointer to an int can't point to the same memory location as a pointer to a float. Therefore it can reorder the reads and writes to generate faster code. In the invsqrt function the strict aliasing rule is broken by the pointer casting and therefore invalid code may be generated. For more info see http://www.cellperformance.com/mike_acton/...t_aliasing.html I made the following test program, save it as invsqrt.c #include <stdio.h> #include <math.h> /* This one breakes strict aliasing rule */ __attribute__ ((noinline)) float invsqrt(float f) { float half = 0.5f * f; int i = *(int*)((void*)&f); i = 0x5f3759df - (i >> 1); f = *(float*)((void*)&i); f = f * (1.5f - half * f * f); return f; } /* This one is ok */ __attribute__ ((noinline)) float invsqrt2(float f) { union { int i; float f; } tmp; float half = 0.5f * f; tmp.f = f; tmp.i = 0x5f3759df - (tmp.i >> 1); f = tmp.f; f = f * (1.5f - half * f * f); return f; } int main(int argc, char **argv) { float f = 0.1; int i; for(i = 0; i < 100; i++) { printf("%f = %f, %f, %f\n", f, invsqrt(f), invsqrt2(f), (float) (1/sqrt(f))); f += 0.1; } return 0; } Try the following compilation commands: $ gcc invsqrt.c -lm $ gcc invsqrt.c -lm -O2 $ gcc invsqrt.c -lm -O2 -fno-strict-aliasing Running ./a.out after each and check the result. The middle one is bad for me but the first and last give good results. This is my version of gcc: gcc (GCC) 4.1.1 (Gentoo 4.1.1-r3) Edit: Try compiling with -S to get the assembler output. In the -O2 case gcc figured it could remove the whole line that calculates i (because the result "can't be used"), resulting in a float load from an uninitialized stack position. Edit2: Try removing the casts to void* and add -Wall to the compilation command. Now you get the following warnings: invsqrt.c: In function ‘invsqrt’: invsqrt.c:7: warning: dereferencing type-punned pointer will break strict-aliasing rules invsqrt.c:9: warning: dereferencing type-punned pointer will break strict-aliasing rules The void* casts hid this warnings. Maybe the casts where put there to get rid of the warnings, but that was the wrong fix. I've been bitten by this "bug" before and I hope the info I have given here will help others avoid it in the future. Keep up the good work, I like the look of the new features in EL. I am looking forward to start playing a bit again after the next update.

Whoever moved the discussion moved a bit to much, posts #9, #10 and #12 in this thread should probably be moved back to Bug under Linux/UNIX. Sorry for messing up that thread in the first place. Edit: I see this is fixed now, thank you!