Lachesis

Dear EL member, if you find spelling, grammar, content or layout errors in any of the Encyclopedia / Help / Skills / Rules windows, please file them here. And here goes the first one: Fur gloves are not stackable ;-) Important: Please check whether the error has not been corrected yet in the latest encyclopedia version. Please see the Accessing the Freepository for information how to retrieve the latest version. With Regards Lachesis

If you check-in others' code, in prinicple you're responsible for it, so if in doubt, talk to the people that suggested it. The potential for presence of the above problems is easy to determine even if you don't know anything about Windows or MSVC at all. Whether code is OS- or compiler-specific, either code suggester or the public should know, and if not so, be minimal, that is, only change it for the specific compiler and wait for users of other compilers to complain as well. Yes, the correct check for MSVC is #ifdef _MSC_VER. You can also test for particular versions, _MSC_VER is an integer that reflects the compiler's version in some slightly mangled form. IIRC MSVC has predefined versions of min/max, so defining macros or inline functions for them does no good. In contrast, GCC does not define such IIRC, however we have already inline functions for min/max in misc.c. Note they're only an example, there're also some other functions, not only mathematical ones, that this applies to. I know you only use macros for Windows code, but they're no safer on Windows than on any other Operating system #includes: that is a delicate question, and needs to be judged on a case-by-case basis. A very rough rule of thumb is that when you need a different header (typically because they're OS-specific headers like unistd.h or windows.h), they have to be masked by platform keyword. If it's only the paths that differ, then it's harder to tell. Usually on windows headers are not in subdirectories, so if it's just about things like SDL/sdl.h vs. sdl.h then that's usually ok do set for all compilers. By the way, most of preprocessor magic is already done in global.h, it may be a good idea to use that one and extend it if necessary (some day someone needs to make global.h more minimal). Sorry Karen I don't have Win available either and I need to be careful about it too, usually I ask people and when in doubt, I'm conservative up to rejecting the change.

Hi Karen, Iagain have a plea for you: For compiler-specific code, please use compiler-specific #if's, NOT #ifdef WINDOWS. We have compile guides for MSVC++ and BS Dev-C++, so both compilers should be respected in the code. I'm particularily aiming at #pragma's and #defines for missing functions here. In most cases GCC builtins will be available in Dev-C++. Edit: see global.h for examples. Don't use macros where inline functions are possible and more appropriate. For one, functions are easier to debug than macros, and second, macros that substitute the same parameter multiple times result in double-evaluation of that parameter, or even worse when using nested macros. This not only has performance issues but also can introduce subtle bugs because users may not be aware it's a macro. Consider the following code: #define min(a,b) ((a) < (b) ? (a) : (b)) #define max(a,b) ((a) > (b) ? (a) : (b)) ... while (...) { *clamped++ = min(max(*raw++, 0.0f), 1.0f); } The line *clamped++ = min(max(*raw++, 0.0f), 1.0f); will expand to *clamped++ = (*raw++ > 0.0f ? *raw++ : 0.0f) < 1.0f ? (*raw++ > 0.0f ? *raw++ : 0.0f) : 1.0f; which will incremement raw four times instead of once (this example will also produce a warning in GCC, but not every expression with side-effects does). With Regards Lachesis

@fool: You may have forgotton to tell Dev-C++ to use Makefile.win instead of creating its own one, or you may have forgotten to copy make.defaults to make.conf.

Hint: use CWARN=-Wall -Wno-sign-compare -Wno-pointer-sign CXXWARN=-Wall -Wno-sign-compare in your make.conf in order to get all warnings but sign problems.

Hi Karen, the patch already is closed (status:accepted) And you need to be patch admin in order to close a patch, dunno if you are.

The eye candy otion patch [1] is now on BerliOS. I must say it doesn't have any perceivable effect on performance on my system, though. Btw, the extremely low framerates were attributed to enabled profiling, I had it enabled somewhen in the past and forgot about it when I got back to the client >_< Still there's something blocking the renderer thread periodically (about 2/s), surprisingly without using any noticeable CPU resources, O_o but that's off topic here. The patch is safe to check-in but I left it as a patch for now just in case. I'd recommend checking it in soon though, so that eye candy can be disabled in the release client. Btw, there's a couple of patches open on BerliOS, if someone can tell me which have been checked in, I can mark them as accepted. I'd also recommend making ttlanhil a patch admin, he's been most active patch reviewing, so he can do this himself. I needed to fix the bugs so I could work on the patch, Karen But I have serious doubts that I catched em all. Someone needs to take a closer look at all the sane_snprintf's and the sane_strncpy's but uni will have me back tomorrow so I'm afraid I'll be indisposed. [1] http://developer.berlios.de/patch/index.ph...p;group_id=1256

Mwahaha sorry XD missed one hunk. I had more changes in that file so it was a little tricky to commit. Will be fixed in a blink.

That warning should already have been fixed, try to update your source. Edit: Seems fix wasn't checked-in yet, now it's in CVS. Karen:working at the eye candy option; what about instead of forcing the idle loop, always calling it, but when it iterates over the effects and eye candy is disabled, it only calls those effects that are recalled but not dead? Since the effects list is relatively short, I think that little extra work won't hurt much. What do you think? Edit: Had a closer look at EyeCandy::Idle and the only thing that could be skipped is distance calculation and distance-based effect [de]activation. Yawn. I only deactivate effect creation, drawing, heart beat, and bone updating now (is it safe to do that last one?). If you think I should deactivate more (or less), just bark What should I do about obstructions? Add? Don't add? Remove? I think it's best to add them, they won't utilize any CPU when no effects are drawn it seems. Btw, Karen, are you sure vectors are the right containers for you? It seems to me that lists would be a much better choice, since you only iterate over the full container, remove and insert elements. If you use lists the performance won't increase significantly but your iterators (except for the items deleted) will remain validate regardless how many objects you insert or delete.

That error basicly means that the executable needs to be linked against OpenGL. What compiler/linker are you using? If you are not using Makefile.win, did you make sure to specify all the ncessary libraries in the project options?

That's right, I was rather thinking of an extra bone or something like that. I don't know much about skinning, maybe that'd be a lot of unnecessary work, maybe it's the only way to make the effect look right with all animations. Just encouraging communication

Oh, didnt know that, I had a staff equipped and it lined up just fine. Maybe it's better asking roja to fix the lineup on thelong run. I know it's not the wind effect, but usually you have it combined with one. Instead of wind direction, any arbitrarily chosen direction would do as well, and you can set it to the wind direction when combining the effects. Trollson what do you mean by "shaping the noise using a radial function" ? Why is FFT faster than Perlin? Perlin computes a 5th-degree polynomial in 8 variables for one sample (only a few samples are needed, not a whole texture). I can't think of a way to get an individual sample within a Fourier transform quickly, the FFT as I know it only can be faster than trivial DFT because of somewhat simultaneous computation of all the values.

_MSC_VER should NEVER be defined manually. It's is only there to check for a specific compiler, namely MSVC, which defines it implicitly. If you want to test for windows, please use -D WINDOWS. Note that there is no maintainer for ELC with compilers other than MSVC and Bloodshed Dev-C++, so it most probably won't work there. Also note you need to use Makefile.win for Dev-C++ now, not the Dev-C++ project file. Larry's obviously using Makefile.linux, so either he's compiling for Linux, or trying to use Makefile.linux in Dev-C++. In neither case _MSC_Ver should be defined. Error logging now uses STDC types char and unsigned instead of SDL types. This should fix the above compile errors. About the noise: I'm aware you're using a different phase for each particle and that looks nice, the problem arises when you change wind direction. The more it differs from +-(1, 1, 1), the smaller the frequency of your sine becomes, reaching zero when direction is perpendicular to that specific vector. A fix with minimal change would be to use dot(wind_direction, (x,y,z)) instead of x + y + z. For some complex but periodic and pattern, a periodic and smooth pertubation function is necessary. It is possible to use polynomials instead of sines for this, I just used sines because it's quick and simple. I didn't mean to really work-out a noise function myself, but if you want I can look into it whenI have a little more time. About the sword: Do you know there is a bone for the sword? It doesn't provide any hint for length of the sword but it doesgive a good idea for its direction (Use -DDEBUG and activate the render skeleton option in order to see the bones). Karen, about minimap: apparently you're using the default configuration for linux, and it changed recently to include the minimap. It has been broken before, but disabled so nobody noticed it.

Perlin noise is about the fastest (real) noise function out there, particularily because it can be implemented using shaders. Most of the multiplications can be reduced to additions and subtractions, too (because one factor is a small integer number). I's basicly just interpolating between precalculated random gradients. Some speed can be gained by using a third- instead of a fifth-degree polynomial for interpolation. Some multiplications cannot be avoided because with additions & subtractions you only get linear combinations. If you look for something simpler, you could try using a nonlinear function on each of the coordinates, and combine them afterwards, which can already give fairly complex results with some fiddling. Here's something I got by a little experimenting, not sure whether it's faster than perlin, though: Note the relatively complex shape and arrangement of the isolevel contours at the bottom. The formula is sin(x + cos(y)) + sin(y + cos(x)) It's relatively easy to extend this formula to 3D, but I cant plot a 3D version in gnuplot For comparison, here's your current noise function:

Apparently something went wrong when evaluating the formula in eye_candy.cpp:700 (it returned NAN) and the powf approximation isn't prepared for that. Btw, it seems to me that you use sin(b*(x + y + z +a)) as a 3D noise function, is that correct? If so it may not work as intended, because it will be constant in all directions perpendicular to (1,1,1), that is all linear combinations of (1, 0, -1) and (0,1,-1). If you want a simple formula, you can avoid the linear constantness using a nonlinear combination of x, y, z, however, every smooth such function f will be constant over smooth (topologically) two-dimensional manifolds, given by the equations f(x,y,z) = const., you can only tweak the complexity of their shape. P.S. A popular simple and fast 3D/4D noise function is the perlin noise [1]. There's probably lots of ready-to-use implementations out there. [1] http://mrl.nyu.edu/~perlin/noise/

Yes thanks Karen, that's exactly the info I needed. Learner: I talked to kl4Uz and the client really closes, it doesn't seem to be a real crash. He told me he had all the textures. May it be due to the fact that the eye candy textures are in subdirectories and slashes are not properly converted to backslashes for windows? P.S. kl4Uz will be abroad next week so we may need to defer this problem if we can't spot its origin.

You are probably missing some necessary files. Make sure el.ini is in the working directory, and data_dir points to the correct location of the EL data files. Also make sure syou installed the additional eye candy textures under textures/eye_candy/ in that location.

Hmm I did it the outside way and I also fell back to non-eye-candy-sfx, but that may be nonsense, since the user might want to disable SFX entirely using that option. I chose the method outside the ec_* functions because that's the way it's also done with the other functions. It's more "visible" that way that the code is conditionally exectued, but of course it's also more repeated code. Additionally, it's much less error-prone putting it into eye_candy_wrapper.c, and it's also easier to get an overview what is still called if eye candy is disabled. Since you're opting for that method I think I'll reroll the code, branching inside eye_candy_wrapper. About the recalling problem: do you have any documentation what that mechanism actually does? I don't understand what you mean by "recalling", why it is necessary and when it needs to be ensured.

I did the first method. However, I cant do it all alone. I the end, there needs to be a way to "disable" effects instead of just deleting them, so they can be restored when eye candy is re-enabled (important for ongoing effects)

All devs please read: I would like to add an eye candy runtime option, but the config window is already full. I would like to add a new tab "Details" (Or LOD?) and redistribute the options as follows: Video Video mode Limit FPS Gamma Show FPS Full Screen Isometric Mouse bug ATI Bug Details Poor man Don't adjust shadows Anti-alias Special effects Normal Mapping (use less techy name? It's actually only used for terrain) Enable blood Particles Percentage Clouds Shadows Show reflections Shadows Eye candy Render mesh Render skeleton Adv Video Perspective Near Plane Use Framebuffer Compiled Vertex Array Point particles Mipmaps 3D alpha blending Shadow mapping Shadow map size Is it OK to do so?

Reproducible on my system with the above compile flags. Seems it's calling a NULL callback. Didn't get to do a singlestep run in order to find out where as of yet.

I'm afraid I don't have time to dig into it further, so just some short notes: I'm perfectly aware of the performance. It can be shown that if the keys are sufficiently dense, the worst case performance is also obtained in the average case (note that constant factors are neglected). Your example fulfills the denseness property because of the matching start of the strings (directory, numbered files like rockn.e3d). However in this specific case, it doesn't matter at all what algorithm is used because of the small value of N. The shadow array is only used for speeding up insertion. It doesn't contain any data, it's only kept in order to avoid malloc() and free() calls. So here goes an example for using the symbol table. See how simple it is bp_attributes = st_create(BPA_COUNT); st_addnum(bp_attributes, "colspan", BPA_COLSPAN); st_addnum(bp_attributes, "rowspan", BPA_ROWSPAN); st_addnum(bp_attributes, "name", BPA_NAME); st_addnum(bp_attributes, "type", BPA_TYPE); st_addnum(bp_attributes, "to", BPA_TO); st_addnum(bp_attributes, "align", BPA_ALIGN); ... st_addnum(bp_attributes, "rotate", BPA_ROTATE); st_addnum(bp_attributes, "mirror", BPA_MIRROR); st_addnum(bp_attributes, "tex-left", BPA_TEX_LEFT); st_addnum(bp_attributes, "tex-right", BPA_TEX_RIGHT); st_addnum(bp_attributes, "tex-top", BPA_TEX_TOP); st_addnum(bp_attributes, "tex-bottom", BPA_TEX_BOTTOM); st_addnum(bp_attributes, "tex-file", BPA_TEX_FILE); st_commit(bp_attributes); ... st_data * tmp = st_lookup(bp_attributes, node->name); if (tmp == NULL) { /* default */ } else switch (tmp->num) { case BPA_COLSPAN: ... break; case BPA_ROWSPAN: ... break; ... } st_destroy(bp_attributes); Hashing is always an option, but it has no non-trivial performance guarantee and is best-suited for sparse key domains. The symbol table is designed for dense key domains, however it's never worse than a binary search tree (neglecting constant factors) if insertion and lookup are separated. The data structure is not as tested as std::map, but it's been tested very thoroughly and it's definitely bug-free. That's enough derail for now But if you can aid me in improving the doxygen documentation, I'd be happy. Btw, it would be nice if you could put your eye candy documentation into doxygen comments, as well. I'm sorry you weren't told we're using that kind of documentation earlier, but you didn't ask either These things have little priority so please don't waste too much time on them right now.

I'm afraid I couldn't address the FPS drop to any particular event. If so, I gladly had posted it. There's no direct relationship to blending, either, I'm afraid. But I wouldn't focuse too much on that, EL already wastes a huge amount of resources (I can play Planeshift at 60 FPS for instance) because of the countless superfluous state changes.

C++ was not allowed in client when I was writing that code Ok, the docs assume you know what a symbol table is. It's basicly something like std::map<const char *, PVoidOrInt>, where PVoidOrInt is a union of void * and int. However it's way faster when many strings start with the same characters and when many strings are inserted at once. The former is attributed to the fact that it uses multi key search instead of binary search, guaranteeing O(log N + L) time where N is the number of items and L is the length of the searched string, whereas std::map only guarantees O(L*log N) time. The second is attributed to the fact that it's optimized for inserting a large number of strings at first, and looking them up later, so instead of using a dynamical data structure just a sorted array is used. The term symbol table stems from compiler development, where this kind of data structure is used in order to keep track of identifiers, or more precisely, so-called symbols. A symbol is simply a string, and the symbol table associates it with arbitrary data, just like an associative array or a PairAssociativeContainer does. Or just like a simple array associates integers with arbitrary data.

Performance test on my system: FPS: 3 FPS (poor_man=1): 20, but occasionally dropping to < 5 FPS and not recovering for a at least minute or two. FPS (no eye candy): 20 CPU usage at 3 FPS: < 5 % CPU usage at 20 FPS: ca. 20 % GPU: Nvidia Geforce FX 5200 (AGP 8x, 128 MB memory) CPU: AMD Athlon XP 1800 RAM: 768 MB DDR 266 #glinfo: [21:19:05] Video card: GeForce FX 5200/AGP/SSE/3DNOW! [21:19:05] Vendor ID: NVIDIA Corporation [21:19:05] OpenGL Version: 2.0.2 NVIDIA 87.76 [21:19:05] Supported extensions: GL_ARB_depth_texture GL_ARB_fragment_program GL_ARB_fragment_program_shadow GL_ARB_fragment_shader GL_ARB_half_float_pixel GL_ARB_imaging GL_ARB_multisample GL_ARB_multitexture GL_ARB_occlusion_query GL_ARB_pixel_buffer_object GL_ARB_point_parameters GL_ARB_point_sprite GL_ARB_shadow GL_ARB_shader_objects GL_ARB_shading_language_100 GL_ARB_texture_border_clamp GL_ARB_texture_compression GL_ARB_texture_cube_map GL_ARB_texture_env_add GL_ARB_texture_env_combine GL_ARB_texture_env_dot3 GL_ARB_texture_mirrored_repeat GL_ARB_texture_rectangle GL_ARB_transpose_matrix GL_ARB_vertex_buffer_object GL_ARB_vertex_program GL_ARB_vertex_shader GL_ARB_window_pos GL_S3_s3tc GL_EXT_texture_env_add GL_EXT_abgr GL_EXT_bgra GL_EXT_blend_color GL_EXT_blend_func_separate GL_EXT_blend_minmax GL_EXT_blend_subtract GL_EXT_compiled_vertex_array GL_EXT_Cg_shader GL_EXT_draw_range_elements GL_EXT_fog_coord GL_EXT_framebuffer_object GL_EXT_multi_draw_arrays GL_EXT_packed_depth_stencil GL_EXT_packed_pixels GL_EXT_paletted_texture GL_EXT_pixel_buffer_object GL_EXT_point_parameters GL_EXT_rescale_normal GL_EXT_secondary_color GL_EXT_separate_specular_color GL_EXT_shadow_funcs GL_EXT_shared_texture_palette GL_EXT_stencil_two_side GL_EXT_stencil_wrap GL_EXT_texture3D GL_EXT_texture_compression_s3tc GL_EXT_texture_cube_map GL_EXT_texture_edge_clamp GL_EXT_texture_env_combine GL_EXT_texture_env_dot3 GL_EXT_texture_filter_anisotropic GL_EXT_texture_lod GL_EXT_texture_lod_bias GL_EXT_texture_object GL_EXT_texture_sRGB GL_EXT_timer_query GL_EXT_vertex_array GL_HP_occlusion_test GL_IBM_rasterpos_clip GL_IBM_texture_mirrored_repeat GL_KTX_buffer_region GL_NV_blend_square GL_NV_copy_depth_to_color GL_NV_depth_clamp GL_NV_fence GL_NV_float_buffer GL_NV_fog_distance GL_NV_fragment_program GL_NV_fragment_program_option GL_NV_gpu_program_parameters GL_NV_half_float GL_NV_light_max_exponent GL_NV_multisample_filter_hint GL_NV_occlusion_query GL_NV_packed_depth_stencil GL_NV_pixel_data_range GL_NV_point_sprite GL_NV_primitive_restart GL_NV_register_combiners GL_NV_register_combiners2 GL_NV_texgen_reflection GL_NV_texture_compression_vtc GL_NV_texture_env_combine4 GL_NV_texture_expand_normal GL_NV_texture_rectangle GL_NV_texture_shader GL_NV_texture_shader2 GL_NV_texture_shader3 GL_NV_vertex_array_range GL_NV_vertex_array_range2 GL_NV_vertex_program GL_NV_vertex_program1_1 GL_NV_vertex_program2 GL_NV_vertex_program2_option GL_SGIS_generate_mipmap GL_SGIS_texture_lod GL_SGIX_depth_texture GL_SGIX_shadow GL_SUN_slice make.conf (comments stripped): UPDATE_CONF=no FEATURES= \ PNG_SCREENSHOT \ NEW_TEX \ OPTIONS_I18N \ NEW_ACTOR_ANIMATION \ AUTO_UPDATE COUNTERS \ FONTS_FIX \ COMMENT_BUFFER \ AFK_FIX CUSTOM_LOOK \ CUSTOM_UPDATE \ SIMPLE_LOD SFX \ USE_ACTOR_DEFAULTS \ NOTEPAD \ USE_INLINE \ EYE_CANDY PLATFORM=-march=athlon-xp -mfpmath=sse -O2 -ggdb -pg XDIR=-L/usr/lib CWARN=-Wall -Wno-sign-compare -Wno-pointer-sign CXXWARN=-Wall -Wno-sign-compare EXTRA_LIBS=-lalut EXTRA_STATICLIBS=libs/libalut.a