Jump to content
Eternal Lands Official Forums
Entropy

Special effects

Recommended Posts

Karen, your way of solving flikering portal doesn't help as LOD can change in big steps (>1,5).

Moreover it might cause problems, beacuse request_LOD code may be skipped when it must be executed.

 

This works better for me

/*
if (fabs(_LOD - (float)LOD) < 1.5)
return;
 const Uint16 rounded_LOD = (Uint16)round(_LOD);
 if (rounded_LOD <= desired_LOD)
LOD = rounded_LOD;
 else
LOD = desired_LOD;
*/
if (_LOD < LOD - 1.5) LOD--;
else if (_LOD > LOD + 1.5) LOD++;

 

I still dont like how it works. I'll try to make it better if i can :)

 

Edit: and this is better way, that i suggested in my first post about it

 

average_LOD = (average_LOD * 499 + _LOD) / 500;
 const Uint16 rounded_LOD = (Uint16)round(average_LOD);
 if (rounded_LOD <= desired_LOD)
LOD = rounded_LOD;
 else
LOD = desired_LOD;

Edited by Alia

Share this post


Link to post
Share on other sites

Ttlanhil: Thanks for linking that screenshot -- it made my day :) Mental note: if we ever want to add "hallucination" to EL (drinking a messed up potion mix, eating wormwood, or whatnot), we've got a winner of a strategy here :icon13:

 

I can't put in your patch yet because I'm at work and can't test it, but I'll check it out this evening. Thanks!

 

 

Alia: There's already framerate averaging code in eye_candy_wrapper. Also, by forcing the LOD to change only one at a time, you're going to make it do more work (it takes CPU time to create and destroy the columns of light). Lastly, by using such a long-running average (versus the short average currently used in the wrapper), you make it unresponsive. LOD changes exist for a reason; without them, system performance will plummet to unacceptable levels when the load becomes high (say, some people show up and start casting a bunch of spells, or whatnot). If it takes ten seconds for an effect to change level of detail, it'll never respond to sudden loads. I'm already a bit apprehensive about the current framerate averaging (average framerate = 70% of old average framerate + 30% of current framerate)

 

The key for eliminating flicker is to make it not respond to minor perturbances.

 

Are you actually still experiencing real flicker problems? Because I'm not. And if you are, what are you doing that's causing your framerate to be so unstable?

Edited by KarenRei

Share this post


Link to post
Share on other sites
Thanks for linking that screenshot -- it made my day :) Mental note: if we ever want to add "hallucination" to EL (drinking a messed up potion mix, eating wormwood, or whatnot), we've got a winner of a strategy here :icon13:
eh, nah, that looks more like some post-modern kitchen more than psychadelica... messing with colour keys and mis-matching opengl graphics state calls gives you really interesting colours... but I digress (on the other hand, knowing you, you may feel the desire to add something like that, and it'd probably get added at least partly in the eye-candy code)
I can't put in your patch yet because I'm at work and can't test it, but I'll check it out this evening. Thanks!
it's the same as what I did for the maps, except that now I know why it works (since a resolution change involves tearing down parts of opengl, no-one should be surprised that things like opengl textures are no longer valid)

the way I did it actually includes (I'm pretty sure) a delete() of all the textures... you may want to improve it a bit as part of cleaning up eye-candy (as in removing from memory. if you don't load textures until eye-candy is enabled in options (and clean up stuff from memory when un-selected), etc)

Share this post


Link to post
Share on other sites

There are actually a number of neat effects I've been considering for later releases. How many of them I'll ever have time to get to is a good question, of course. Most of them hinge around the fact that you can render to a texture instead of a screen, so you can then map the screen image texture to a mesh of quads. You could tweak the texture (manually or with a pixel shader) to do things like fogging or color mapping, you could bend/stretch the mesh, shake it around, rotate it, whirl it, ripple it, etc.

 

In other words, there are a lot of neat things that you can do (earthquakes, areas with visual distortions, drunkenness, hallucination, etc). But, it's a topic for later :) I still have work to do here (cosmetic changes for Roja, your problem with columns of light, etc) before I can even go back to hooking eye candy into the map editor (about half done on that one). And there's a lot of things to do after that, including some biggies that I haven't even started on (shadow volumes and normal maps)...

Edited by KarenRei

Share this post


Link to post
Share on other sites

Alia: There's already framerate averaging code in eye_candy_wrapper. Also, by forcing the LOD to change only one at a time, you're going to make it do more work (it takes CPU time to create and destroy the columns of light). Lastly, by using such a long-running average (versus the short average currently used in the wrapper), you make it unresponsive. LOD changes exist for a reason; without them, system performance will plummet to unacceptable levels when the load becomes high (say, some people show up and start casting a bunch of spells, or whatnot). If it takes ten seconds for an effect to change level of detail, it'll never respond to sudden loads. I'm already a bit apprehensive about the current framerate averaging (average framerate = 70% of old average framerate + 30% of current framerate)

 

The key for eliminating flicker is to make it not respond to minor perturbances.

 

Are you actually still experiencing real flicker problems? Because I'm not. And if you are, what are you doing that's causing your framerate to be so unstable?

 

I agree, that for short-living effects, such as spells we should keep small average, but for effects such as teleportal beams,

which are constant we may have long averages, what i mean is different average times for different effects.

This average for portals is enough responsive.

 

Beams begin to flicker when i put "min eye candy frame rate" to be bigger than my video card can support on max LOD.

 

PS

Forgot to ask, when i open EL window (from minimized state) i can see beams of all teleports in and out, that happend while window was minimized. Is it supposed to be so?

Edited by Alia

Share this post


Link to post
Share on other sites
Forgot to ask, when i open EL window (from minimized state) i can see beams of all teleports in and out, that happend while window was minimized. Is it supposed to be so?

 

I've seen that happen when changing desktops in Linux, as well as my floating EXP number counting up the times it's missed, and scrolling thru a map quickly from the spot I was in before I swtched to whatever position I currently am at. It's like the graphics are playing a fast forward to play catch up.

 

Note: This has always happened, even with the official clients.

Share this post


Link to post
Share on other sites

Ttlanhil, you're not going to like this. ;) I'm still getting funkiness (particles flicker) when it changes vid modes (most visible, for me, at the redmoon smoke firepit), and I've verified that your code is being called. I went and got you valgrind info:

 

==25025== Syscall param write(buf) points to uninitialised byte(s)

==25025== at 0x25FC03: __write_nocancel (in /lib/libpthread-2.5.90.so)

==25025== by 0x2CA76E: _X11TransWrite (in /usr/lib/libX11.so.6.2.0)

==25025== by 0x2D0676: (within /usr/lib/libX11.so.6.2.0)

==25025== by 0x2D074A: _XReply (in /usr/lib/libX11.so.6.2.0)

==25025== by 0x2B6621: XInternAtom (in /usr/lib/libX11.so.6.2.0)

==25025== by 0x74C562B: (within /usr/lib/libSDL-1.2.so.0.7.3)

==25025== by 0x74D80C5: (within /usr/lib/libSDL-1.2.so.0.7.3)

==25025== by 0x74D6723: (within /usr/lib/libSDL-1.2.so.0.7.3)

==25025== by 0x74D7809: (within /usr/lib/libSDL-1.2.so.0.7.3)

==25025== by 0x74BD28D: SDL_VideoInit (in /usr/lib/libSDL-1.2.so.0.7.3)

==25025== by 0x748D020: SDL_InitSubSystem (in /usr/lib/libSDL-1.2.so.0.7.3)

==25025== by 0x748D066: SDL_Init (in /usr/lib/libSDL-1.2.so.0.7.3)

==25025== Address 0x436337E is 14 bytes inside a block of size 16,384 alloc'd

==25025== at 0x4004705: calloc (vg_replace_malloc.c:279)

==25025== by 0x2BB456: XOpenDisplay (in /usr/lib/libX11.so.6.2.0)

==25025== by 0x74C589D: (within /usr/lib/libSDL-1.2.so.0.7.3)

==25025== by 0x74D75C7: (within /usr/lib/libSDL-1.2.so.0.7.3)

==25025== by 0x74BD28D: SDL_VideoInit (in /usr/lib/libSDL-1.2.so.0.7.3)

==25025== by 0x748D020: SDL_InitSubSystem (in /usr/lib/libSDL-1.2.so.0.7.3)

==25025== by 0x748D066: SDL_Init (in /usr/lib/libSDL-1.2.so.0.7.3)

==25025== by 0x808B6E5: init_video (gl_init.c:378)

==25025== by 0x8094F2E: init_stuff (init.c:571)

==25025== by 0x80A1AA1: main (main.c:233)

==25025==

==25025== Invalid read of size 4

==25025== at 0x756A9E6: (within /usr/lib/libGL.so.1.0.9629)

==25025== Address 0x45674A8 is 3,008 bytes inside a block of size 3,010 alloc'd

==25025== at 0x40053C6: malloc (vg_replace_malloc.c:149)

==25025== by 0x7569529: (within /usr/lib/libGL.so.1.0.9629)

==25025==

==25025== Invalid read of size 4

==25025== at 0x756AA4E: (within /usr/lib/libGL.so.1.0.9629)

==25025== Address 0x45674A8 is 3,008 bytes inside a block of size 3,010 alloc'd

==25025== at 0x40053C6: malloc (vg_replace_malloc.c:149)

==25025== by 0x7569529: (within /usr/lib/libGL.so.1.0.9629)

==25025==

==25025== Invalid read of size 4

==25025== at 0x756AB4B: (within /usr/lib/libGL.so.1.0.9629)

==25025== Address 0x45680A0 is 3,008 bytes inside a block of size 3,010 alloc'd

==25025== at 0x40053C6: malloc (vg_replace_malloc.c:149)

==25025== by 0x7569529: (within /usr/lib/libGL.so.1.0.9629)

==25025==

==25025== Invalid read of size 4

==25025== at 0x7579BDF: (within /usr/lib/libGL.so.1.0.9629)

==25025== Address 0x473F6B0 is 208 bytes inside a block of size 209 alloc'd

==25025== at 0x40053C6: malloc (vg_replace_malloc.c:149)

==25025== by 0x7579F21: (within /usr/lib/libGL.so.1.0.9629)

==25025== by 0x74D6CB4: (within /usr/lib/libSDL-1.2.so.0.7.3)

==25025== by 0x74BC1C1: SDL_SetVideoMode (in /usr/lib/libSDL-1.2.so.0.7.3)

==25025== by 0x808B90E: init_video (gl_init.c:445)

==25025== by 0x8094F2E: init_stuff (init.c:571)

==25025== by 0x80A1AA1: main (main.c:233)

==25025==

==25025== Conditional jump or move depends on uninitialised value(s)

==25025== at 0xDB7FE6: _dl_relocate_object (in /lib/ld-2.5.90.so)

==25025== by 0xDBEAA7: dl_open_worker (in /lib/ld-2.5.90.so)

==25025== by 0xDBAEE5: _dl_catch_error (in /lib/ld-2.5.90.so)

==25025== by 0xDBE4A1: _dl_open (in /lib/ld-2.5.90.so)

==25025== by 0xDF7C4C: dlopen_doit (in /lib/libdl-2.5.90.so)

==25025== by 0xDBAEE5: _dl_catch_error (in /lib/ld-2.5.90.so)

==25025== by 0xDF82CB: _dlerror_run (in /lib/libdl-2.5.90.so)

==25025== by 0xDF7B83: dlopen@@GLIBC_2.1 (in /lib/libdl-2.5.90.so)

==25025== by 0x74C090C: SDL_LoadObject (in /usr/lib/libSDL-1.2.so.0.7.3)

==25025== by 0x434548: IMG_InitPNG (in /usr/lib/libSDL_image-1.2.so.0.1.4)

==25025== by 0x434D4E: IMG_isPNG (in /usr/lib/libSDL_image-1.2.so.0.1.4)

==25025== by 0x430877: IMG_LoadTyped_RW (in /usr/lib/libSDL_image-1.2.so.0.1.

4)

==25025==

==25025== Syscall param write(buf) points to uninitialised byte(s)

==25025== at 0x25FC2B: (within /lib/libpthread-2.5.90.so)

==25025== by 0x2CA76E: _X11TransWrite (in /usr/lib/libX11.so.6.2.0)

==25025== by 0x2D0676: (within /usr/lib/libX11.so.6.2.0)

==25025== by 0x2D074A: _XReply (in /usr/lib/libX11.so.6.2.0)

==25025== by 0x2C7639: XSync (in /usr/lib/libX11.so.6.2.0)

==25025== by 0x74C5F04: (within /usr/lib/libSDL-1.2.so.0.7.3)

==25025== by 0x74D5176: (within /usr/lib/libSDL-1.2.so.0.7.3)

==25025== by 0x74B6C85: SDL_SetGammaRamp (in /usr/lib/libSDL-1.2.so.0.7.3)

==25025== by 0x74B6FB5: SDL_SetGamma (in /usr/lib/libSDL-1.2.so.0.7.3)

==25025== by 0x8095645: init_stuff (init.c:778)

==25025== by 0x80A1AA1: main (main.c:233)

==25025== Address 0x453386B is 19 bytes inside a block of size 16,384 alloc'd

==25025== at 0x4004705: calloc (vg_replace_malloc.c:279)

==25025== by 0x2BB456: XOpenDisplay (in /usr/lib/libX11.so.6.2.0)

==25025== by 0x74C589D: (within /usr/lib/libSDL-1.2.so.0.7.3)

==25025== by 0x74D75EA: (within /usr/lib/libSDL-1.2.so.0.7.3)

==25025== by 0x74BD28D: SDL_VideoInit (in /usr/lib/libSDL-1.2.so.0.7.3)

==25025== by 0x748D020: SDL_InitSubSystem (in /usr/lib/libSDL-1.2.so.0.7.3)

==25025== by 0x748D066: SDL_Init (in /usr/lib/libSDL-1.2.so.0.7.3)

==25025== by 0x808B6E5: init_video (gl_init.c:378)

==25025== by 0x8094F2E: init_stuff (init.c:571)

==25025== by 0x80A1AA1: main (main.c:233)

==25025==

 

Make of it what you will. :(

Share this post


Link to post
Share on other sites

well, I suggest you try completely tearing down eye-candy's opengl stuff (textures, co-ords, anything like that) before the opengl teardown in gl_init.c, and then rebuild everything after... I can't think of anything else to try

Share this post


Link to post
Share on other sites

Eye candy doesn't do much special with opengl stuff on init apart from load textures. It's very untrusting of the gl states that will be set when it runs.

 

I hear from asgnny that your fix helped her, so that's probably good enough for now. There's still a memory leak in this SDL stuff, as you'll notice from the valgrind errors, but perhaps it's an SDL bug.

Share this post


Link to post
Share on other sites

The blood impact effect is probably the most often created one. But it's mostly not visible except on skellies, where you can always see it. That suggests that it's created within objects and therefore invisible. I know, it would again require some knowledge about the geometry of the creature that attacks and, even worse, the exact point on the surface of the monster. But the amount of effects that are wasted would make an effort worthwhile...

Share this post


Link to post
Share on other sites

The scale of the effect depends on a two factors.

 

1) How many max HP the creature has.

2) What percent of its max HP were taken with that hit.

 

So, if you're comparing fighting skellies to fighting rabbits, yes, you'll get more blood. Want to see a lot of blood, though, watch a high level person fight a yeti or something :(

 

Hmm, actually. I just realized that it *should* be possible to make skellies not bleed -- we have the actor pointer of what's being hit, so we have the skin_name and actor_name, which should be trivial to check. I'll put that on my todo list. Let's see... both varieties of skellies, all three gargoyles, and phantom warriors shouldn't bleed. Anything else?

 

Got some crashes to work on first, though, plus a cosmetic change on request from Roja. All of the crashes reported may be from the same source, and I think I have a fix -- I'll try it out tonight.

Edited by KarenRei

Share this post


Link to post
Share on other sites

Might be some fix you made that isn't complete but:

eye_candy.h(394) : error C3861: 'finitef': identifier not found

 

That function is not defined anywhere so I assume it's compiler specific, and mine isn't that specific on that matter:p

 

Update:

Searched for it and it's suppose to be in math.h but well something is still wrong then:P

Edited by Beaverhunter

Share this post


Link to post
Share on other sites

finitef() is present in MSVC++ 2005 (8.0) math.h as _finitef() (note the leading underscore -- MS is keen on this to stop all that "portability" nonsence).

 

For comparison, it does not seem to be in MSVC++ 98 (6.0).

 

It is of course present in GCC on Windows (Cygwin, and presumably mingw32).

 

If necessary the function could substituted or worked around (isnormal(), isnan(), isinf(), isnormalf(), isnanf(), isinff() ).

Edited by trollson

Share this post


Link to post
Share on other sites

_finitef() doesn't exist as a defined function in math.h, I opened the file and searched, nothing even similar. Also some of your other mentions doesn't seem to exist either, but isnan(), isnormal() (only for files though) and isinf() exists and works.

I currently changed it to,

if (isinf(x) || isinf(z) || isinf(y))

return false;

else

return true;

 

Is this right or does it matter that the isinf takes double ? What errors can I look for, what is this really good for as it's obviously a new block of code?

Share this post


Link to post
Share on other sites

What is it good for? Preventing crashes. Good enough? :)

 

Isinf isn't enough; you need a nan check too. That's why finite() is preferred.

 

Hmm oki=) Well, will you commit some #def msvc on this or shall I run on a "custom ride" till you got more time?

 

May I also ask when can coordinates possibly go towards infinity or become a non number?=S Sounds rather crazy actually unless you use some kind of pointer that can pick up random memory (leaks) on occations or something.

If the infinity is reached by the "engine"/particles coordinates can they not be prevented on creation then?

Why not just kill any particles or what ever this is when they reach too high speeds or positions? No real game objects have coordinates like (1000102, 102232, -22222) right?

Edited by Beaverhunter

Share this post


Link to post
Share on other sites
May I also ask when can coordinates possibly go towards infinity or become a non number?=S Sounds rather crazy actually unless you use some kind of pointer that can pick up random memory (leaks) on occations or something.

 

There are a few cases. For example, particles that spiral outwards. The further out they go, the faster they go. The faster they go, the further out they go. It's possible for them to get high enough that they become inf. Inf ends up turning into NaN. Another example is certain types of IFS spawners, which too can increase in magnitude if they make a bad selection of routes to take, thus going to inf, thus going to nan. Nan causes a crash in flare().

 

Does msvc support isfinite()?

Share this post


Link to post
Share on other sites

...

 

There are a few cases. For example, particles that spiral outwards. The further out they go, the faster they go. The faster they go, the further out they go. It's possible for them to get high enough that they become inf. Inf ends up turning into NaN. Another example is certain types of IFS spawners, which too can increase in magnitude if they make a bad selection of routes to take, thus going to inf, thus going to nan. Nan causes a crash in flare().

 

Does msvc support isfinite()?

 

Hmm oki, but why you let them live that long so that they can reach those big numbers?

But well I guess this is a much easier way.

Yes, isfinite() works.

Share this post


Link to post
Share on other sites

Remember that there is a difference between 'isfinite()' and 'finite()'; in latter, zeros and subnormals are considered finite, whereas in the former they are not.

 

So 'isfinite(0.0)' will fail where 'finite(0.0)' passed. This may have consequences for particles at the origin for example.

 

If this would have a significant effect then you may need another workaround.

 

Misread 7.12.3.2; isfinite should be the same as finite.

Edited by trollson

Share this post


Link to post
Share on other sites

Remember that there is a difference between 'isfinite()' and 'finite()'; in latter, zeros and subnormals are considered finite, whereas in the former they are not.

 

So 'isfinite(0.0)' will fail where 'finite(0.0)' passed. This may have consequences for particles at the origin for example.

 

If this would have a significant effect then you may need another workaround.

 

When you make such statement please tell what architecture you mean, because GNU claims they are equivalent

and in libc6 they actually are.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Recently Browsing   0 members

    No registered users viewing this page.

×