Jump to content
Eternal Lands Official Forums
Entropy

Special effects

Recommended Posts

Blowing objects, as effects that need a bounding range, will require changes to the map editor first. It'll be a week or two before I get that taken care of, assuming that feature freeze doesn't hit me first.

 

I can certainly change the wind code so that it trusts the server's chosen windspeed and direction, and only determines the local, position-dependent wind. Of course, doing that before leaf/petal effects are hooked in for good (the one hooked in right now is really just for testing; it's not region-dependent) probably wouldn't be worth it.

 

In short: you're about two weeks ahead of me :) I'll catch up, just not yet.

Share this post


Link to post
Share on other sites

Running CVS from march 23rd checkout:

 

Ran this all night without a problem traveling C2, fighting, harvesting. I try to start up the client this morning and I get a segfault.

 

Starting program: /usr/local/games/el/el.x86.linux.bin
[Thread debugging using libthread_db enabled]
[New Thread -1225124128 (LWP 27400)]
[New Thread -1225532496 (LWP 27415)]
[New Thread -1376146512 (LWP 27418)]
[New Thread -1384535120 (LWP 27419)]
[New Thread -1337070672 (LWP 27420)]
[Thread -1384535120 (zombie) exited]
[New Thread -1345459280 (LWP 27421)]
[Thread -1345459280 (zombie) exited]
FountainEffect (0xedd3708) created.
LampEffect (0xed7df90) created.
LampEffect (0xee8ba50) created.
FountainEffect (0xee8bd30) created.
FountainEffect (0xee8bda8) created.
LampEffect (0xee8be20) created.
LampEffect (0xee8c100) created.
LampEffect (0xee8c3e0) created.
LampEffect (0xee8c6c0) created.
LampEffect (0xee8caa8) created.
LampEffect (0xee8cd88) created.
LampEffect (0xee8d068) created.
LampEffect (0xee8d348) created.
WindEffect (0xedcb910) created.
WindEffect (0xee8e7b0) created.
Deactivating effect 0xedd3708(23852.7 > 700)
Deactivating effect 0xed7df90(5779.45 > 700)
Deactivating effect 0xee8ba50(6024.82 > 700)
Deactivating effect 0xee8bd30(16892.9 > 700)
Deactivating effect 0xee8bda8(15834.6 > 700)
Deactivating effect 0xee8be20(31928.8 > 700)
Deactivating effect 0xee8c100(30821.4 > 700)
Deactivating effect 0xee8c3e0(29911.9 > 700)
Deactivating effect 0xee8c6c0(31007.3 > 700)
Deactivating effect 0xee8caa8(22258.5 > 700)
Deactivating effect 0xee8cd88(22238.7 > 700)
Deactivating effect 0xee8d068(21460.6 > 700)
Deactivating effect 0xee8d348(34528.1 > 700)
Deactivating effect 0xedcb910(8375.03 > 700)
Deactivating effect 0xee8e7b0(9424.67 > 700)

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1225124128 (LWP 27400)]
0xb7f22090 in ?? ()

 

I start up the current official client and I am in PV 267, 128: camera facing north and it is raining.

 

System info:

AMD Athol XP 3000+

Nvidia Geforce 6600

Slackware 10.2

GCC: 3.3.6

NV drivers: 1.0-9631

 

make.conf:

FEATURES=PNG_SCREENSHOT NEW_FRUSTUM BUG_FIX_3D_OBJECTS_MIN_MAX NEW_TEX OPTIONS_I18N ATI_9200_FIX 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
XDIR=-L/usr/X11R6/lib
CWARN=-Wall
#-Wdeclaration-after-statement -Wall -Werror
CXXWARN=-Wall
#-Wall -Werror

#EXTRA_LIBS=-lalut
#EXTRA_STATICLIBS=libs/libalut.a

CC=gcc
CXX=g++
LINK=gcc

 

Let me know if you need any more info

Share this post


Link to post
Share on other sites

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 :wub:
    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 :hug: 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.

Edited by Lachesis

Share this post


Link to post
Share on other sites

Thanks, Larry. Is it reproducible? If so, try building the client without EYE_CANDY and see if it still crashes (don't do this until you've verified that the crash is consistant). If it only crashes with EYE_CANDY on, and it is reproducible, could you then get me a stack trace?

 

Thanks!

Share this post


Link to post
Share on other sites

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.

Edited by Lachesis

Share this post


Link to post
Share on other sites

Yeay, reproducibility!

 

I'll have a look at it today. Thanks again -- I couldn't do this without playtesters. :)

 

Doxygen: I'll probably do that once we hit feature freeze. Sounds like as good a time as any. Until then, I'm spending all my time on getting what I can finished, tested, and hooked in. :wub:

Share this post


Link to post
Share on other sites

As far as my previous report, I moved my position using the release client and have not been able to reproduce it (Disclaimer: I am NOT a programmer, just a linux user that likes to break things :D)

 

I did encounter a new problem though using the cvs. I entered trassian using the teleporter and I immediately dropped to 1 FPS. I killed the client, restarted and the same result, 1 FPS. I started the client in gdb and here is what I have

 

(gdb) run
Starting program: /usr/local/games/el/el.x86.linux.bin
[Thread debugging using libthread_db enabled]
[New Thread -1225206048 (LWP 7234)]
[New Thread -1225614416 (LWP 7249)]
[New Thread -1372030032 (LWP 7252)]
[New Thread -1380418640 (LWP 7253)]
[Thread -1380418640 (zombie) exited]
[New Thread -1339249744 (LWP 7254)]
SmokeEffect (0xdfa6c18) created (<11.7115, 4.2, -92.5066>, 1.1)
SmokeEffect (0xdfbf8b0) created (<88.0787, 3.7, -92.879>, 1.1)
FountainEffect (0xdfbf920) created.
SmokeEffect (0xdfbf998) created (<92.1424, 2.4, -46.8103>, 0.6)
SmokeEffect (0xdfbfa08) created (<92.6975, 2.6, -46.1701>, 1.1)
SmokeEffect (0xdfbfa78) created (<92.6354, 2.1, -47.2937>, 1.1)
SmokeEffect (0xdfbfae8) created (<93.1193, 3, -46.576>, 0.3)
WindEffect (0xdfc0260) created.
WindEffect (0xdfc0318) created.
Deactivating effect 0xdfa6c18(9967.07 > 700)
Deactivating effect 0xdfbf8b0(16920.8 > 700)
Deactivating effect 0xdfbf920(4665.12 > 700)
Deactivating effect 0xdfbf998(10542.6 > 700)
Deactivating effect 0xdfbfa08(10574.7 > 700)
Deactivating effect 0xdfbfa78(10676.7 > 700)
Deactivating effect 0xdfbfae8(10698.1 > 700)
Deactivating effect 0xdfc0260(7857.87 > 700)
Deactivating effect 0xdfc0318(8841.97 > 700)
Activating effect 0xdfbf8b0(545.52 < 700)
Activating effect 0xdfc0318(482.87 < 700)
quit


Program received signal SIGINT, Interrupt.
[Switching to Thread -1225206048 (LWP 7234)]
0xb7a70d87 in sched_yield () from /lib/tls/libc.so.6
(gdb) backtrace
#0  0xb7a70d87 in sched_yield () from /lib/tls/libc.so.6
#1  0xb7ca9e3d in _nv000007gl () from /usr/lib/libGL.so.1
#2  0xb735a987 in _nv000078gl () from /usr/lib/libGLcore.so.1
#3  0x00000003 in ?? ()
Previous frame inner to this frame (corrupt stack?)

 

Hopefully this will help out in some way.

Share this post


Link to post
Share on other sites

GDB helps with crashes, not performance.

 

I lost almost all of yesterday due to housework and a guest who ended up staying over until 1:00 AM. So, I'm still working on finishing up obstructions. I'll get to this other stuff as soon as I finish, though.

Share this post


Link to post
Share on other sites

Reported crash: Cannot reproduce. I've been sitting at those precise coordinates for an hour now, and nothing. Furthermore, as I noticed from your output, it said that all effects were deactivated, so none would have been running. That's no guarantee that it wasn't the fault of eye candy, but it's suggestive that it wasn't. This is why I wanted you to try and reproduce it without eye candy built in.

 

I'll go check out the Trassian teleporter now.

Share this post


Link to post
Share on other sites

I've tried the portals room teleporter (both to and from) and the mine teleporter, and noticed nothing unusual.

 

Could you get me coordinates, and possibly a screenshot and a gprof (assuming you use some unix variant) run? If you're not familiar with gprof, it's a profiler. You build with -pg, then run the program, and then in the same directory, run gprof programname. It'll give you a bunch of output; give that to me and I'll be able to tell what's using up your CPU. Now, it may not be a CPU limitation (in unix, check "top"). It could be a video card limitation. In that case, we can recognize that based on your CPU not being at 100%.

 

 

 

Also, as mentioned with the crash, try it with and without EYE_CANDY.

 

Sorry I can't help more, but when I can't reproduce it...

 

 

Checked in:

 

* Obstructions: Round 1. This is fairly complex code and the first time

it's been hooked in, so be warned.

Share this post


Link to post
Share on other sites

Ran valgrind with "--smc-check=all" option on latest code, here's a few bits from a very large log file:

 


<snip larger number of SDL stuff>

WindEffect (0x534a4e0) created.
WindEffect (0x5629960) created.
==14497== 
==14497== Use of uninitialised value of size 4
==14497==	at 0x44A8519: (within /lib/tls/libc-2.3.6.so)
==14497==	by 0x44AC6EA: vfprintf (in /lib/tls/libc-2.3.6.so)
==14497==	by 0x44CB210: vsnprintf (in /lib/tls/libc-2.3.6.so)
==14497==	by 0x44B2364: snprintf (in /lib/tls/libc-2.3.6.so)
==14497==	by 0x80A8976: add_enhanced_actor_from_server (new_actors.c:641)
==14497==	by 0x80A5772: process_message_from_server (multiplayer.c:468)
==14497==	by 0x809DD95: start_rendering (main.c:110)
==14497==	by 0x809E072: main (main.c:235)
==14497== 
==14497== Conditional jump or move depends on uninitialised value(s)
==14497==	at 0x44A8521: (within /lib/tls/libc-2.3.6.so)
==14497==	by 0x44AC6EA: vfprintf (in /lib/tls/libc-2.3.6.so)
==14497==	by 0x44CB210: vsnprintf (in /lib/tls/libc-2.3.6.so)
==14497==	by 0x44B2364: snprintf (in /lib/tls/libc-2.3.6.so)
==14497==	by 0x80A8976: add_enhanced_actor_from_server (new_actors.c:641)
==14497==	by 0x80A5772: process_message_from_server (multiplayer.c:468)
==14497==	by 0x809DD95: start_rendering (main.c:110)
==14497==	by 0x809E072: main (main.c:235)
==14497== 
==14497== Conditional jump or move depends on uninitialised value(s)
==14497==	at 0x44AA116: vfprintf (in /lib/tls/libc-2.3.6.so)
==14497==	by 0x44CB210: vsnprintf (in /lib/tls/libc-2.3.6.so)
==14497==	by 0x44B2364: snprintf (in /lib/tls/libc-2.3.6.so)
==14497==	by 0x80A8976: add_enhanced_actor_from_server (new_actors.c:641)
==14497==	by 0x80A5772: process_message_from_server (multiplayer.c:468)
==14497==	by 0x809DD95: start_rendering (main.c:110)
==14497==	by 0x809E072: main (main.c:235)
Deactivating effect 0x534a4e0(8229.87 > 700)
Deactivating effect 0x5629960(9290.87 > 700)
Activating effect 0x534a4e0(143.116 < 700)
Activating effect 0x5629960(269.123 < 700)
SelfMagicEffect (0x5b893c8) created.
SelfMagicEffect (0xfb0e618) created.
SelfMagicEffect (0xbc89978) created.
WindEffect (0xf387ed0) created.
WindEffect (0xf3880f8) created.
==14497== 
==14497== Invalid read of size 4
==14497==	at 0x80EA9D7: ec_heartbeat (eye_candy_wrapper.cpp:134)
==14497==	by 0x80EA944: ec_idle (eye_candy_wrapper.cpp:120)
==14497==	by 0x8086C47: display_game_handler (gamewin.c:679)
==14497==	by 0x807C8D6: draw_window (elwindows.c:1059)
==14497==	by 0x807CE15: display_window (elwindows.c:1207)
==14497==	by 0x807A2F5: display_windows (elwindows.c:57)
==14497==	by 0x807441C: draw_scene (draw_scene.c:98)
==14497==	by 0x809DDFF: start_rendering (main.c:123)
==14497==	by 0x809E072: main (main.c:235)
==14497==  Address 0x720698C is 84 bytes inside a block of size 240 free'd
==14497==	at 0x401D487: realloc (vg_replace_malloc.c:306)
==14497==	by 0x8071AF0: load_counters (counters.c:172)
==14497==	by 0x80A5866: process_message_from_server (multiplayer.c:609)
==14497==	by 0x809DD95: start_rendering (main.c:110)
==14497==	by 0x809E072: main (main.c:235)

<snip repeats for line 135 136 143 to 154>

==14497== 
==14497== Conditional jump or move depends on uninitialised value(s)
==14497==	at 0x80EAADF: ec_heartbeat (eye_candy_wrapper.cpp:138)
==14497==	by 0x80EA944: ec_idle (eye_candy_wrapper.cpp:120)
==14497==	by 0x8086C47: display_game_handler (gamewin.c:679)
==14497==	by 0x807C8D6: draw_window (elwindows.c:1059)
==14497==	by 0x807CE15: display_window (elwindows.c:1207)
==14497==	by 0x807A2F5: display_windows (elwindows.c:57)
==14497==	by 0x807441C: draw_scene (draw_scene.c:98)
==14497==	by 0x809DDFF: start_rendering (main.c:123)
==14497==	by 0x809E072: main (main.c:235)
SelfMagicEffect (0xdeed780) created.
SelfMagicEffect (0x5112810) created.
SelfMagicEffect (0x108ee7f8) created.
==14497== 
==14497== Syscall param write(buf) points to uninitialised byte(s)
==14497==	at 0x452AE11: write (in /lib/tls/libc-2.3.6.so)
==14497==	by 0x44CD614: (within /lib/tls/libc-2.3.6.so)
==14497==	by 0x44CD8CE: _IO_do_write (in /lib/tls/libc-2.3.6.so)
==14497==	by 0x44CECB9: _IO_file_close_it (in /lib/tls/libc-2.3.6.so)
==14497==	by 0x44C318B: fclose (in /lib/tls/libc-2.3.6.so)
==14497==	by 0x80C5D1E: save_quickspells (spells.c:730)
==14497==	by 0x807026F: save_local_data (console.c:927)
==14497==	by 0x809DE9B: start_rendering (main.c:152)
==14497==	by 0x809E072: main (main.c:235)
==14497==  Address 0x8009229 is not stack'd, malloc'd or (recently) free'd
WindEffect (0x534a4e0) destroyed.
WindEffect (0x5629960) destroyed.
SelfMagicEffect (0x5b893c8) destroyed.
SelfMagicEffect (0xfb0e618) destroyed.
SelfMagicEffect (0xbc89978) destroyed.
WindEffect (0xf387ed0) destroyed.
WindEffect (0xf3880f8) destroyed.
SelfMagicEffect (0xdeed780) destroyed.
SelfMagicEffect (0x5112810) destroyed.
SelfMagicEffect (0x108ee7f8) destroyed.

 

OK, some bits are outside your code but I keep them here in case its important. Before the last cvs update, valgrind was clean for you code. This is with a clean compile, default makefile options + EYE_CANDY. Hope it's of use, I could not make head nor tails of it :hehe:

Share this post


Link to post
Share on other sites

I can -- thanks :hehe: This is a bit bizarre. This is part of the new obstruction code. It's claiming that an obstructing obj3d's x_pos, y_pos, and z_pos are invalid reads. Perhaps some part of EL is freeing that obj3d which I'm not aware of? I'll look into it.

 

(BTW -- testing out the new obstruction code makes me really eager to get the dragon breath effect hooked in, although I'll need a server message or something for that (not sure). In my tests, when it hits you, now, it diverges into streams that flow around you. Quite nice. :hehe: )

Edited by KarenRei

Share this post


Link to post
Share on other sites

Quick question for any people who've been coding here longer than me: given a pointer to an actor, how can I find the start and end positions of their weapon (if they have one)? I know how to get their hand, which I suppose I could use as the start of the weapon (bone 25), but how would I get the end of it?

Share this post


Link to post
Share on other sites

Here is crash info:

 

With EYE_CANDY:

Starting program: /usr/local/games/el/el.x86.linux.bin
[Thread debugging using libthread_db enabled]
[New Thread -1225079072 (LWP 23769)]
[New Thread -1225487440 (LWP 23782)]
[New Thread -1280463952 (LWP 23785)]
[New Thread -1288852560 (LWP 23786)]
[New Thread -1297470544 (LWP 23787)]
[Thread -1288852560 (zombie) exited]
[New Thread -1305859152 (LWP 23788)]
[Thread -1305859152 (zombie) exited]
FountainEffect (0xedcef60) created.
LampEffect (0xed797e8) created.
LampEffect (0xee87310) created.
FountainEffect (0xee875f0) created.
FountainEffect (0xee87668) created.
LampEffect (0xee876e0) created.
LampEffect (0xee879c0) created.
LampEffect (0xee87ca0) created.
LampEffect (0xee87f80) created.
LampEffect (0xee88368) created.
LampEffect (0xee88648) created.
LampEffect (0xee88928) created.
LampEffect (0xee88c08) created.
WindEffect (0xee89c00) created.
WindEffect (0xee89cb8) created.
Deactivating effect 0xedcef60(23188.2 > 700)
Deactivating effect 0xed797e8(5312.58 > 700)
Deactivating effect 0xee87310(5548.3 > 700)
Deactivating effect 0xee875f0(16231.8 > 700)
Deactivating effect 0xee87668(15210.4 > 700)
Deactivating effect 0xee876e0(31022.7 > 700)
Deactivating effect 0xee879c0(29920.6 > 700)
Deactivating effect 0xee87ca0(29033.5 > 700)
Deactivating effect 0xee87f80(30123.4 > 700)
Deactivating effect 0xee88368(21393.4 > 700)
Deactivating effect 0xee88648(21379.8 > 700)
Deactivating effect 0xee88928(20610 > 700)
Deactivating effect 0xee88c08(33393 > 700)
Deactivating effect 0xee89c00(7849.19 > 700)
Deactivating effect 0xee89cb8(8886.96 > 700)

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1225079072 (LWP 23769)]
0xb7f2d090 in ?? ()
(gdb) backtrace
#0  0xb7f2d090 in ?? ()
#1  0x00000000 in ?? ()
#2  0xb5ee5000 in ?? ()
#3  0xb7f2d040 in ?? ()
#4  0x00000057 in ?? ()
Previous frame inner to this frame (corrupt stack?)
(gdb) up
#1  0x00000000 in ?? ()
(gdb) up
#2  0xb5ee5000 in ?? ()
(gdb) up
#3  0xb7f2d040 in ?? ()
(gdb) up
#4  0x00000057 in ?? ()
(gdb) up
Initial frame selected; you cannot go up.

 

Without EYE_CANDY is working good so far

 

Location PV 178,144

Edited by larrystorch

Share this post


Link to post
Share on other sites

Larry: Thanks for your help. :icon13: Unfortunately... see all of those "?? ()"s? You must be built without debugging info. A stack trace without function names/error lines is of no use to me.

Edited by KarenRei

Share this post


Link to post
Share on other sites

Debugging can be annoying, eh? I'd gladly take care of it all myself if I only could reproduce it, but I spent several hours trying to reproduce both your slowdown and your reported crash, with no success. So, I need something to work with here.

Share this post


Link to post
Share on other sites

Latest patch committed:

 

* Some potential fixes for obstructions that may potentially fix the valgrind errors. Unfortunately, valgrinding EL is just too taxing for my laptop, so I can't be sure.

* Sword effects. Primitive, but functional. I had to make a compromise because nobody knew a good way to determine the location of the tip of the sword. Instead, it uses the direction that the arm is pointing and projects it outward 0.4 units from the hand. For those testing sword effects: they only are in place on powerful swords, don't cover serp, rapier, and bronze swords, and only are prominent when the sword is moving. Standing still, the sword just sparkles a bit.

 

Now, given that there seems to be a sort of unofficial feature freeze (last I was told, one would be coming up soon; appears that it's already here), I won't be adding any more features until after release (unless told otherwise). Instead, I'm going to do some more testing of obstructions, since that's the most complex recent addition.

 

Quick question, to anyone who knows more about the freeze (if present) than me: does it also apply to the map editor, or may I work on that after I finish my additional testing?

Share this post


Link to post
Share on other sites

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?

Edited by Lachesis

Share this post


Link to post
Share on other sites

This is something that I had been wanting to do (an option to enable/disable eye candy), but hadn't gotten around to. Thanks, Lachesis!

 

Looking at things, it'd probably be wisest to disable all ec_ calls. Without ec_idle running, certain effects it creates will only end when either the effect is recalled or the player leaves a map. One-off effects that are created and forgotten about (bag dropping/picking up, spells, summons, etc) would simply accumulate (effects that get recalled -- say, a fire going out or a sword getting unwielded -- would still be removed). So, I see two ways you could attack this. You could either grep for all ec_ function calls in *.c and conditionally call them there, or you could put the conditional check in each of the ec_ functions in eye_candy_wrapper.cpp.

Share this post


Link to post
Share on other sites

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)

Share this post


Link to post
Share on other sites

Hmm. In that case, the wisest method would be to do on an effect-by-effect basis -- either in eye_candy_wrapper.cpp or not (it'd probably be cleaner to all be inside eye_candy_wrapper.cpp). If you create an effect, but you don't call ec_idle or ec_draw, it'll use no cpu and not appear; it'll be disabled.

 

If it's an effect that will expire on its own (like dropping a bag), you should simply return so that effect will never be created at all. If it's an effect that wouldn't expire on its own (like a fountain), you'd let it go through; it would just get no cpu after creation and would not be drawn since ec_idle and ec_draw won't be called. If ec_idle isn't being called, having effects in the queue won't hurt anything, and they can still be recalled.

 

Hmm -- one minor change would be needed to eye_candy_wrapper.cpp in order to allow effects to be recalled properly. You'd need ec_idle to be called in order for the effect to see that it has been recalled. Everywhere you see something like "(*iter)->effect->recall = true;" you'd want to flag a global boolean -- say, "force_idle = true;", with, at the top of eye_candy_wrapper.cpp, the line "bool force_idle = false;" So, the recalls would be like changing:

 

if (((*iter)->caster == _actor) || ((*iter)->target == _actor))
{
  (*iter)->effect->recall = true;
  (*iter)->caster = NULL;
  (*iter)->target = NULL;
  continue;
}

 

to:

 

if (((*iter)->caster == _actor) || ((*iter)->target == _actor))
{
  (*iter)->effect->recall = true;
  (*iter)->caster = NULL;
  (*iter)->target = NULL;
  force_idle = true;
  continue;
}

 

At the top of ec_idle, you would add something like the following code.

 

if (!force_idle && !eye_candy_enabled) // Or whatever your enable var is
 return;
force_idle = false;

 

You would always call ec_idle, even if eye candy was disabled, but it would only run if force_idle was set, and only run once. ec_draw would not be called if eye candy was disabled.

 

Note that one run of ec_idle isn't enough to guarantee the complete recalling of an effect. Effects are allowed to make their own decisions on what needs to be done when. In the general case, an effect and all of the particles associated with it will be deleted the first time ec_idle is called, and the reference to that effect will be deleted the second time around. However, I don't think it's worth calling ec_idle twice every time you recall an effect. The vast majority of the memory used by an effect will be freed the first time around, and as soon as another effect is recalled at a later date (causing another run of ec_idle), the remaining memory will be freed.

 

PS: If this is too much for you, just let me know and I'll do it myself. Again, no problem -- I understand how busy everyone is, and I appreciate the effort you've already put in.

Edited by KarenRei

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

×