Xaphier

Disable use animation program, that should fix it

what happens if you disable use animation program?

New alpha test for the OpenGL 2 client, this time with many improvements: Dual quaternion used for animation Some shadow improvements Support for materials so we can use normal mapping, specular mapping etc. Terrain that uses a height map as input (optimized part for OpenGL 3 missing atm) Relaxed uv's to increase quality of planar projected texture coordinates Basic lod system that will work with instanced objects, not finish, only terrain use it atm ctrl+shift+alt+r to toggle wireframe mode, ctrl+shift+alt+q for night time, ctrl+shift+alt+m for day Many bug fixes There are some shader options at settings, troubleshoot, hopefully they can fix some problems you might have. Git tag is: alpha-with-terrain Special thanks at Sir_Odie for all the testing he has done Enjoy testing PS: Data files for all those who want to compile it: http://www.gm.fh-koeln.de/~linke/EL-Downloads/EL-GL2-data-only.zip For testing, IP uses a terrain atm, should look like this:

Looks nice bluap!

Well, your driver doesn't say why it fails to link, so I can only guess. Can be that the shader is just too much for it and it doesn't fully implement OpenGL 2.1

The biggest missing part for the new OpenGL 2+ el client is the particle system. The goals for the new particle system are: Faster More effects using modern OpenGL features (OpenGL 2/3) and not fixed function The problem of the eye-candy system is that it works on individual particles. This makes it nearly impossible to use the power of OpenGL and OpenCL to accelerate the particles. Any ideas are welcome

General design ideas about the particle system To be able to design a fast and efficient particle system, it is important to understand that the hardware used to accelerate the animation and rendering is different from the normal cpu. For particles, that means we should group them so similar effects can be animated together, but also limiting the interaction between the individual particles. Particle animation: There are mainly two types of particle animations we need. Type one is the simple type where animation and rendering can be merged, because only simple calculations are needed to get the data for rendering them. The animation calculations only depends on the starting data and the time. Type two is the complex type, where the animation calculations are iterative. That means, we need to update the animation data and than can use these data for rendering. Implementing the type two of the particles is the more challenging case, but thanks to modern OpenGL (2.1 & 3+) there are two different ways to implement the animation acceleration. For OpenGL 2.1, we can use "Render to vertex buffer"(R2VB) using "Pixel Buffer Objects" (PBO) and "Vertex Buffer Objects" (VBO). The idea is to use a "Frame Buffer Object" (FBO) to render the updated particle data into a texture and than using these texture data as input for the rendering. This is possible thanks to PBO & VBO. For OpenGL 3+, the thing is easier, because we can use "Transform Feedback". That way, we can animate the data and directly getting them into a VBO after the vertex shader. This is a nice example for the OpenGL 3 way. Particle blending: There are two different blending types used for particles, additive blending and interpolation blending. Thanks to fragment shaders, we can merge these two blend modes into just one multiplying the particle color with the wanted alpha in the fragment shader and outputting only the alpha for the background as alpha value. glBlendFunc(GL_ONE, GL_SRC_ALPHA); Particle animation & rendering functions: Those functions don't need to be coded in the client/engine, because we use OpenGL (and later perhaps OpenCL). That means we can read the source code of those functions and than the driver will compile them. That means a lot of freedom. Particle data formats: For the particles, every vertex format will work, but it never hurts to try to use the smallest memory usage that fits the need. The best is to stick with four values per attribute to avoid shortcomings in the driver of some OpenGL 2.1 implementation.

Thanks for trying the client! Hopefully I was able to fix all the bugs mentioned here. If not, please let me know

After a lot of RL trouble and no Internet at home, I had now enough time to push a newer version of the OpenGL 2 client to github. Lots of code changes, many new features and hopefully less bugs. The main improvements are: Supported are the plain old depth shadow maps using GL_EXT_framebuffer_object Exponential Shadow Maps (ESM), because they can be filtered. OpenGL 3 hardware is needed for that. Parallel Split Shadow Maps (PSSM), splitting the view range and using a shadow map for every split. Only used for ESM and also needs OpenGL 3 hardware, because texture arrays are used. Filtering of the Shadow Maps to reduce noise and make the shadows smoother. Works only with ESM Anti aliasing Shadow Maps, works only with ESM shadow maps and uses the hardware MSAA to make the shadows smoother. Using a "shader builder" to generate the needed shaders at runtime. The shader source is than optimized using glsl-optimizer, because without that, too many driver crash, produce bad code or find some other excuse to not work Improved static instancing, running much faster now and using multiple treads when compiled with OpenMP support Improved state tracking to reduce OpenGL state changes Support for Vertex Array Objects (VAO) Hopefully you have fun trying it Source is at: https://github.com/xaphier/Eternal-Lands

Thanks all for trying it. I hopefully have fixed some more bugs now Don't use make -f Makefile.linux for the opengl2 client. make a folder called build outside the source tree and cd to it. run: cmake ../path/to/source/tree/ and then make (inside the build folder) Thanks for the build hint. I haven't used cmake before. I saw people refer to it in posts about Windows and thought it was a Windows thing. You may want to create a brief BUILD file explaining the simple procedure to cut down on questions later. As an FYI, using the most current (beta) version of glm ( glm-0.9.3.B ) produces the following error: In file included from /usr/include/glm/./core/func_exponential.hpp:121:0, from /usr/include/glm/glm.hpp:100, from /tmp/elsrc/Eternal-Lands/engine/prerequisites.hpp:55, from /tmp/elsrc/Eternal-Lands/engine/rstartree.hpp:15, from /tmp/elsrc/Eternal-Lands/engine/rstartree.cpp:8: /usr/include/glm/./core/func_exponential.inl: In member function 'T glm::detail::compute_log2<PATH>::operator()(const T&) const': /usr/include/glm/./core/func_exponential.inl:98:110: error: invalid application of 'sizeof' to incomplete type 'boost::STATIC_ASSERTION_FAILURE<false>' /usr/include/glm/./core/func_exponential.inl:98:111: error: template argument 1 is invalid /usr/include/glm/./core/func_exponential.inl:98:143: error: invalid type in declaration before ';' token make[2]: *** [engine/CMakeFiles/elengine.dir/rstartree.cpp.o] Error 1 make[1]: *** [engine/CMakeFiles/elengine.dir/all] Error 2 make: *** [all] Error 2 Using the most recent stable glm ( glm-0.9.2.7 ) works ok. Thought you might want to know in case the beta version goes stable at some point and breaks things in the EL code. The idea about the BUILD file is good, when I have time for it I will make it. In the meantime, any help is welcome Thanks for trying glm-0.9.3, will look at it when it's stable. Yep, as I suspected. Last time I compiled (a while ago) it was fine, Ubuntu 10.04 LTS uses libglew1.5-dev. I tried on a VM using the latest Ubuntu which has both libglew1.5-dev and libglew1.6-dev, the 1.6 version works. @Xaphier: The code now also needs libfontconfig1-dev but the cmake stage does not fail if its not installed. The need for fontconfig was a mistake, should be no longer needed.

Thanks all for trying, I hopefully fixed the bugs you found!

Was a buffer mapping error when using eye_candy, should be fixed now, thanks for testing. Ofc more stuff changed, so have fun trying

Ok, I hope I have now fixed all the windows compilation problems, some other bugs because of uninitialized vars and hopefully your crash groomsh. All in git now

Ok, Hussam had the same problem like you groomsh and he just started the build process again and than it worked. I have no idea why it failed the first time for him. seems GLAPIENTRYP is defined nowhere Hm, will look at it

It should work with MinGW & cmak. http://nuwen.net/mingw.html is a good mingw distro with most libs needed for the client. GLM is a header only library you get from here: http://glm.g-truc.net/

After a busy time and a lot of work, the branch should come now again. New features are: * Basic lua support * Shader generator to be able to build all the stuff needed for testing and different qualities (at the moment not-user friendly to change the settings) * Basic shadow suppor * Support for PCH (pre compiled shaders) to reduce build time. Currently only gcc and clang support

Ok, now the client development and bug fixing made great progress thanks to all your testing. The current git version of the OpenGL 2 client has a shader quality option (settings -> gfx). When you have problems, try changing the shader quality. The qualities from low to high only increase the rendering quality, the debug quality is something to use if no other quality worked.

Ok, thanks all for testing first. After careful checking your answers, I worked on the client and hopefully fixed the problems. Just one comment. With cmake an "out-of-source" (CMake FAQ) build is recommended. That way, you can have different builds too btw. For Linux, you do it like that: git clone git://git.berlios.de/elc cd elc git checkout feature/opengl2 cd .. mkdir release cd release cmake ../elc make if you want to build a debug build (too) mkdir debug cd debug cmake -DCMAKE_BUILD_TYPE=Debug ../elc make

I would like to hear you opinion, so please no flaming. I know that it would increase the prices for all the items that are mainly bought from npc instead of mixed.

Great! Atm, I am working at an Version of EL using OpenGL 2.0 and newer using shaders etc. Will hoepfully finish some test version today and push it into git

Should be fixed now

Now x0, x2, x4 and x8 are always shown. When a mode is selected that is not supported, no fsaa is used (this is also logged to the console and the log files)

No, I didn't disable the fsaa mode, I only disabled the checks for the supported fsaa modes (they used some glx calls)

Font rendering should be better now in git. You will see that in next rc/release

Try git now, I merge the boots branch with mainline.