Jump to content
Eternal Lands Official Forums


  • Content count

  • Joined

  • Last visited

About Lachesis

  • Rank
    Not a troll
  • Birthday 10/21/1982

Contact Methods

  • MSN
  • Website URL
  • ICQ
  • Yahoo

Profile Information

  • Location
  1. Special effects

    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.
  2. Special effects

    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
  3. Windows Compilation Guide

    @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.
  4. strncpy and the like

    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.
  5. Special effects

    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.
  6. Special effects

    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
  7. Special effects

    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.
  8. Special effects

    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.
  9. Windows Compilation Guide

    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?
  10. Special effects

    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
  11. Special effects

    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.
  12. Special effects

    _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.
  13. Special effects

    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:
  14. Special effects

    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/
  15. Special effects

    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.