Jump to content
Eternal Lands Official Forums
Entropy

Special effects

Recommended Posts

New commit.

 

Kindar Naar: I had to make some changes to your patch to make it work in Linux and for a few other reasons. Hopefully, it still works in Windows. Thanks!

 

Bluap: Heh, didn't think about trying it in different windows. I moved the particle effect idle call from gamewin to elwindows so that it will be called in all windows. draw is only called in gamewin.

 

I wasn't able to reproduce your crash, however -- and I idled for a long time. The backtrace isn't helping, unfortunately, either -- the destructor that it fails in is empty, so that delete statement can only be deleting the object itself -- which implies some sort of memory leak or something. And a memory leak could be anywhere in Eternal Lands. :P Without being able to reproduce it, my only chance will be to try running it through a mem checker. I'll try valgrind, but last I tried, EL was too intense of a program for valgrind to deal with on this slow computer.

 

I managed to get a very low, but tolerable, framerate through valgrind. The only things I can see that could possibly be suspicious is:

 

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

==9527== at 0x9D6E9B: (within /lib/libc-2.5.so)

==9527== by 0x978884: new_do_write (in /lib/libc-2.5.so)

==9527== by 0x978B5E: _IO_do_write@@GLIBC_2.1 (in /lib/libc-2.5.so)

==9527== by 0x979EF5: _IO_file_close_it@@GLIBC_2.1 (in /lib/libc-2.5.so)

==9527== by 0x96E1FB: fclose@@GLIBC_2.1 (in /lib/libc-2.5.so)

==9527== by 0x80C6E67: save_quickspells (spells.c:718)

==9527== by 0x807040A: save_local_data (console.c:927)

==9527== by 0x809EF44: start_rendering (main.c:152)

==9527== by 0x809F122: main (main.c:237)

==9527== Address 0x5B4E001 is not stack'd, malloc'd or (recently) free'd

 

Of course, I'm not getting a crash. I'd get a lot more useful data if I could get one.

Edited by KarenRei

Share this post


Link to post
Share on other sites

Great. The changes work. :w00t: BTW, did you check my implementation of round(). I'm not sure it's how the original function is implemented.

 

Here is a new patch:

 

Index: eye_candy/effect_breath.h
===================================================================
RCS file: /cvsroot/elc/elc/eye_candy/effect_breath.h,v
retrieving revision 1.3
diff -u -r1.3 effect_breath.h
--- eye_candy/effect_breath.h	11 Mar 2007 01:59:26 -0000	1.3
+++ eye_candy/effect_breath.h	11 Mar 2007 20:12:41 -0000
@@ -37,7 +37,7 @@
 else
   LOD = desired_LOD;
 count_scalar = 3000 / LOD;
-	size_scalar = scale * fastsqrt(LOD) / sqrt(10);
+	size_scalar = scale * fastsqrt(LOD) / sqrt(10.0);
  };
  static Uint64 get_max_end_time() { return 5000000; };
  virtual Uint64 get_expire_time() { return 5000000 + born; };
Index: eye_candy/eye_candy.cpp
===================================================================
RCS file: /cvsroot/elc/elc/eye_candy/eye_candy.cpp,v
retrieving revision 1.4
diff -u -r1.4 eye_candy.cpp
--- eye_candy/eye_candy.cpp	11 Mar 2007 20:01:15 -0000	1.4
+++ eye_candy/eye_candy.cpp	11 Mar 2007 20:30:50 -0000
@@ -866,9 +866,9 @@
Vec3 IFSHorseshoeElement::get_new_coords(const Vec3& pos)
{
  const coord_t r = pos.magnitude();
-  const angle_t theta_x = atan2(pos.z, pos.y + 0.0000001);
-  const angle_t theta_y = atan2(pos.x, pos.z + 0.0000001);
-  const angle_t theta_z = atan2(pos.y, pos.x + 0.0000001);
+  const angle_t theta_x = atan2(pos.z, pos.y + 0.0000001f);
+  const angle_t theta_y = atan2(pos.x, pos.z + 0.0000001f);
+  const angle_t theta_z = atan2(pos.y, pos.x + 0.0000001f);
  const Vec3 result(r * cos(2 * theta_x), r * cos(2 * theta_y), r * cos(2 * theta_z));
  return (pos * inv_scale) + (result * scale);
}
@@ -1855,7 +1855,7 @@
}

#ifdef WINDOWS
-__declspec_noinline float invsqrt_workaround(int i)
+__declspec(noinline) float invsqrt_workaround(int i)
#else
__attribute__ ((noinline)) float invsqrt_workaround(int i)
#endif
@@ -1864,7 +1864,7 @@
}

#ifdef WINDOWS
-__declspec_noinline float invsqrt(float f)	// The famous Quake3 inverse square root function.  About 4x faster in my benchmarks!
+__declspec(noinline) float invsqrt(float f)	// The famous Quake3 inverse square root function.  About 4x faster in my benchmarks!
#else
__attribute__ ((noinline)) float invsqrt(float f)	// The famous Quake3 inverse square root function.  About 4x faster in my benchmarks!
#endif
Index: eye_candy/eye_candy.h
===================================================================
RCS file: /cvsroot/elc/elc/eye_candy/eye_candy.h,v
retrieving revision 1.4
diff -u -r1.4 eye_candy.h
--- eye_candy/eye_candy.h	11 Mar 2007 20:01:15 -0000	1.4
+++ eye_candy/eye_candy.h	11 Mar 2007 20:29:51 -0000
@@ -5,6 +5,14 @@

// I N C L U D E S ////////////////////////////////////////////////////////////

+#ifdef WINDOWS
+ #include <windows.h>	 
+#else
+ #include <sys/time.h>
+ #include <time.h>
+#endif
+
+#include <string>
#include <vector>
#include <map>
#include <iostream>
@@ -16,12 +24,7 @@
#include <stdlib.h>
#include <math.h>

-#ifdef WINDOWS
- #include <windows.h>	 
-#else
- #include <sys/time.h>
- #include <time.h>
-#endif
+

namespace ec
{

 

After applying this I get about 100 errors from eye_candy.cpp. All related to streams and vectors. I'm sure I saw these kinds of errors somewhere before and they are VS specific. I will just have to look for the solution a bit more.

 

EDIT: Updated the patch. I got the stream problems resolved #include <string> and got to the point of linking. YAY :P.. where I get unresolved externals :P

 

eye_candy_wrapper.obj : error LNK2001: unresolved external symbol "float camera_y" (?camera_y@@3MA)

eye_candy_wrapper.obj : error LNK2001: unresolved external symbol "float camera_x" (?camera_x@@3MA)

eye_candy_wrapper.obj : error LNK2001: unresolved external symbol "float camera_z" (?camera_z@@3MA)

eye_candy_wrapper.obj : error LNK2001: unresolved external symbol "int poor_man" (?poor_man@@3HA)

eye_candy_wrapper.obj : error LNK2001: unresolved external symbol "int window_width" (?window_width@@3HA)

eye_candy_wrapper.obj : error LNK2001: unresolved external symbol "int use_point_particles" (?use_point_particles@@3HA)

eye_candy_wrapper.obj : error LNK2001: unresolved external symbol "int window_height" (?window_height@@3HA)

Edited by Kindar Naar

Share this post


Link to post
Share on other sites

okay, had it running, got a segfault when changing map (leaving DP sto):

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 46958316786224 (LWP 7594)]
0x00002ab552b83bac in _int_free () from /lib/libc.so.6
(gdb) bt
#0  0x00002ab552b83bac in _int_free () from /lib/libc.so.6
#1  0x00002ab552b8421e in free () from /lib/libc.so.6
#2  0x000000000053fef8 in ~WindEffect (this=0x7df4f40) at eye_candy/effect_wind.cpp:470
#3  0x00000000004d1588 in ec::EyeCandy::idle (this=0x813580) at eye_candy/eye_candy.cpp:1387
#4  0x00000000004c4a48 in ec_idle () at eye_candy_wrapper.cpp:92
#5  0x000000000043d9a6 in draw_window (win=0x3b7b270) at elwindows.c:1055
#6  0x000000000043dffc in display_window (win_id=24) at elwindows.c:1208
#7  0x000000000046306d in update_loading_win (text=0x3973700 "Loading map", progress_increase=0) at loading_win.c:152
#8  0x000000000046579a in load_map (file_name=0x2aaaac300a33 "./maps/map3.elm") at map_io.c:294
#9  0x000000000046555d in change_map (mapname=0x2aaaac300a33 "./maps/map3.elm") at map_io.c:143
#10 0x000000000046cac4 in process_message_from_server (in_data=0x2aaaac300a30 "\a\021", data_length=19) at multiplayer.c:754
#11 0x0000000000463275 in start_rendering () at main.c:110
#12 0x00000000004635d7 in main (argc=1, argv=0x7fff593b4b08) at main.c:237

(gdb) bt full
#0  0x00002ab552b83bac in _int_free () from /lib/libc.so.6
No symbol table info available.
#1  0x00002ab552b8421e in free () from /lib/libc.so.6
No symbol table info available.
#2  0x000000000053fef8 in ~WindEffect (this=0x7df4f40) at eye_candy/effect_wind.cpp:470
No locals.
#3  0x00000000004d1588 in ec::EyeCandy::idle (this=0x813580) at eye_candy/eye_candy.cpp:1387
	iter = {_M_current = 0x7e49700}
	e = (class ec::Effect *) 0x7df4f40
	distance_squared = 2.09366942e+23
	ret = false
	i = 0
	cur_time = 1173647534213732
	change_LOD = 8928
	change_LOD2 = 22843
	particle_cleanout_rate = 4.59163468e-41
	counter = 0
#4  0x00000000004c4a48 in ec_idle () at eye_candy_wrapper.cpp:92
	new_time = 1173647534213731
<snip>

before that, I had cast shield a few times without ill (or any extra, that I saw) effect, and hadn't previously changed map

ed: also, the campfiles seem to be rather large and green, is that intentional?

ed2: going from DP to DP coal cave caused a crash in the same place... guess I'll go back to old client for a while :P

Edited by ttlanhil

Share this post


Link to post
Share on other sites

-DEYE_CANDY is now required for people trying to trouble shoot this change, this is seperaqte from needing -DSFX since that had been fairly stable.

Share this post


Link to post
Share on other sites

It has been a while since I spoke up around here. Someone goofed on get_sigils_we_have. The function takes 1 argument, but the call in multiplayer.c has two arguments. I assume it was done by someone working with the special effects, but maybe not. I cannot find out who made the changes.

 

[edit] sorry, yeah, it was a change that Learner made recently for EYE_CANDY. I will PM him.

Edited by 0ctane

Share this post


Link to post
Share on other sites

It has been a while since I spoke up around here. Someone goofed on get_sigils_we_have. The function takes 1 argument, but the call in multiplayer.c has two arguments. I assume it was done by someone working with the special effects, but maybe not. I cannot find out who made the changes.

 

[edit] sorry, yeah, it was a change that Learner made recently for EYE_CANDY. I will PM him.

That was checked in by accident while fixing something else. It's works now.

Share this post


Link to post
Share on other sites

Heh, yeah -- I'm not the only person making changes to the client around here -- far from it. Every time I do a cvs update, I get changes from others, and only some are in my code.

 

Kindar Naar: I hooked in your changes, and they work fine in Linux. Unfortunately, I have no clue what's causing your linker errors. The external symbols are defined in existing EL code. My only guess is that it's due to the fact that my code is C++, while the variables are defined in C code. I'm trying wrapping the extern variable declarations in "extern C"; let's see if that helps. Also, if I could see your link statement, that might be of some use.

 

Ttlanhil: Once again, your crashes have me stumped -- as do your addendums. Large, green fire? So, it doesn't look like the screenshots I posted? That makes no sense. CampfireParticle's color is:

 

Red: 1.0

Green: 0.4 to 0.9

Blue: 0.2.

 

There's also a couple CamfireBigParticles, but they're not dominant, and their colors are similar. There are glowing particles (accumulative drawing) and matte particles (non-accumulative drawing). The non-accumulative ones add some red, while the accumulative ones make yellow and white. Particles create smoke when they die; smoke is R=0.07, G=0.05, B=0.05. Perhaps you could get me a screenshot so I can see what you're talking about?

 

As for the crash, once again, your trace is bewildering, and once again, I can't reproduce it. Crashing in WindEffect's destructor? The only things that it deletes are created in the constructor, and those are freed nowhere else. Once again, your errors say "memory leak" to me, but, as I mentioned, I ran valgrind, and I only got that one case that looked suspicious (something about saving sigils), and I'd be very surprised if that caused your errors. Not that I would know anything about that code, either.

 

Could you please run this through a memory checker? Without that, I really cannot help you. I just can't reproduce it.

Share this post


Link to post
Share on other sites

okay, I 'cvs up'ed again, did the same run between dp coal mine and dp sto (as well as other places), mostly under valgrind, and it didn't segfault... maybe latest CVS fixed it somehow, or the result of upgrading my system (usually there's a few new packages a day)

 

valgrind does have stuff about eye candy, however; here's a sample:

==27001== Invalid read of size 4
==27001==	at 0x4DC982: ec::Texture::push_texture(std::string) (eye_candy.cpp:85)
==27001==	by 0x4DCA36: ec::EyeCandy::load_textures(std::string) (eye_candy.cpp:1081)
==27001==	by 0x4C4B89: ec_init (eye_candy_wrapper.cpp:29)
==27001==	by 0x456B93: init_stuff (init.c:608)
==27001==	by 0x4635CC: main (main.c:235)
==27001==  Address 0x9062718 is 16 bytes inside a block of size 88 free'd
==27001==	at 0x4A1B46D: free (vg_replace_malloc.c:233)
==27001==	by 0x4DC97D: ec::Texture::push_texture(std::string) (eye_candy.cpp:83)
==27001==	by 0x4DCA36: ec::EyeCandy::load_textures(std::string) (eye_candy.cpp:1081)
==27001==	by 0x4C4B89: ec_init (eye_candy_wrapper.cpp:29)
==27001==	by 0x456B93: init_stuff (init.c:608)
==27001==	by 0x4635CC: main (main.c:235)

the entire log is available here ... as a .gz it's under 10Kb, but gunzipped it's almost half a meg (mostly the above stuff repeated with different memory addresses, a few other notices)

this is the first time I've used valgrind, so if there's anything else you need, walk me through it :blink:

 

for the campfile, there's a screenie here, it's over half a meg in size... it's not quite as green as the campfire in DP (I took this one first... later, trying to take one in DP, is where the valgrind log abruptly ended... the colours aren't much different, though)

 

debian etch amd64 on intel core2 duo

nvidia geforce 6600 gt binary driver version 9746

gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)

 

anything else I can test/check for this?

 

ed: okay, it's still segfaulting... had a bit of a look, there are Vec3's in WindEffect, and there were Vec3's in the valgrind report, could this be the reason?

Edited by ttlanhil

Share this post


Link to post
Share on other sites

Got the latest CVS and with one last change:

 

Index: eye_candy/effect_breath.h
===================================================================
RCS file: /cvsroot/elc/elc/eye_candy/effect_breath.h,v
retrieving revision 1.3
diff -u -r1.3 effect_breath.h
--- eye_candy/effect_breath.h	11 Mar 2007 01:59:26 -0000	1.3
+++ eye_candy/effect_breath.h	12 Mar 2007 05:53:47 -0000
@@ -37,7 +37,7 @@
 else
   LOD = desired_LOD;
 count_scalar = 3000 / LOD;
-	size_scalar = scale * fastsqrt(LOD) / sqrt(10);
+	size_scalar = scale * fastsqrt(LOD) / sqrt(10.0);
  };
  static Uint64 get_max_end_time() { return 5000000; };
  virtual Uint64 get_expire_time() { return 5000000 + born; };

 

the code compiles and links!!

 

I haven't run the client yet, I'll do it after getting back from work. :(

 

There's also one more thing I need to mention, but this should be handled once the code is stable. Before using the eye_candy I got 650 compiler warnings, now I get 1500 :blink: Most of them are related to converting data type, for example:

 

e:\cpp\elc\eye_candy\eye_candy.h(409) : warning C4244: 'argument' : conversion from 'double' to 'const ec::coord_t', possible loss of data

Share this post


Link to post
Share on other sites

Ok, I added the new summonig defines (the server doesn't send them yet)

 

//summoning stuff
#define SPECIAL_EFFECT_SUMMON_RABBIT 25
#define SPECIAL_EFFECT_SUMMON_RAT 26
#define SPECIAL_EFFECT_SUMMON_BEAVER 27
#define SPECIAL_EFFECT_SUMMON_SKUNK 28
#define SPECIAL_EFFECT_SUMMON_RACOON 29
#define SPECIAL_EFFECT_SUMMON_DEER 30
#define SPECIAL_EFFECT_SUMMON_GREEN_SNAKE 31
#define SPECIAL_EFFECT_SUMMON_RED_SNAKE 32
#define SPECIAL_EFFECT_SUMMON_BROWN_SNAKE 33
#define SPECIAL_EFFECT_SUMMON_FOX 34
#define SPECIAL_EFFECT_SUMMON_BOAR 35
#define SPECIAL_EFFECT_SUMMON_WOLF 36
#define SPECIAL_EFFECT_SUMMON_SKELETON 37
#define SPECIAL_EFFECT_SUMMON_SMAL_GARG 38
#define SPECIAL_EFFECT_SUMMON_MEDIUM_GARG 39
#define SPECIAL_EFFECT_SUMMON_BIG_GARG 40
#define SPECIAL_EFFECT_SUMMON_PUMA 41
#define SPECIAL_EFFECT_SUMMON_FEM_GOBLIN 42
#define SPECIAL_EFFECT_SUMMON_POLAR_BEAR 43
#define SPECIAL_EFFECT_SUMMON_BEAR 44
#define SPECIAL_EFFECT_SUMMON_ARMED_MALE_GOB 45
#define SPECIAL_EFFECT_SUMMON_ARMED_SKELETON 46
#define SPECIAL_EFFECT_SUMMON_FEMALE_ORC 47
#define SPECIAL_EFFECT_SUMMON_MALE_ORC 48
#define SPECIAL_EFFECT_SUMMON_ARMED_FEM_ORC 49
#define SPECIAL_EFFECT_SUMMON_ARMED_MALE_ORC 50
#define SPECIAL_EFFECT_SUMMON_CYCLOP 51
#define SPECIAL_EFFECT_SUMMON_FLUFFY_RABBIT 52
#define SPECIAL_EFFECT_SUMMON_PHANTOM_WARRIOR 53
#define SPECIAL_EFFECT_SUMMON_MOUNTAIN_CHIM 54
#define SPECIAL_EFFECT_SUMMON_YETI 55
#define SPECIAL_EFFECT_SUMMON_ARCTIC_CHIM 56
#define SPECIAL_EFFECT_SUMMON_GIANT 57
#define SPECIAL_EFFECT_SUMMON_GIANT_SNAKE 58
#define SPECIAL_EFFECT_SUMMON_SPIDER 59
#define SPECIAL_EFFECT_SUMMON_TIGER 60

Share this post


Link to post
Share on other sites

Thanks -- I'll check more into both of these tomorrow.

 

Ttlanhil: Wow -- that is big. And green. And that smoke looks horrid. Uck. No, that's not what it looks like for me. Nor what it should look like. Perhaps if I can figure out why that's going on for you, that might fix segfault. Who knows. Also, I doubt Vec3 is the problem. It's no surprise that there are Vec3s in both segfault traces; there are Vec3s everywhere. They're used for positions, velocities, and accelerations. They do no memory allocation, so I can't imagine they're the problem. They only have three member variables (x, y, and z).

Edited by KarenRei

Share this post


Link to post
Share on other sites
Ttlanhil: Wow -- that is big. And green.
yeah, it's kinda like the particles themselves are oversized, except that it's also a lot taller than it should be... I'm thinking the greenness might just be from blending the background and the yellow-to-black-smoke; or at least, if it were normal size, the green wouldn't be so noticable.
Also, I doubt Vec3 is the problem. It's no surprise that there are Vec3s in both segfault traces; there are Vec3s everywhere. They're used for positions, velocities, and accelerations. They do no memory allocation, so I can't imagine they're the problem. They only have three member variables (x, y, and z).
true, but, the complaint is that they were already free'd... which makes me wonder if there's any pointers made as 32bit size and deleted as 64bit, etc... bit-size problems would be the ones I expect to have(other than that, it could be the graphics card/drivers, I don't think there's much else that wouldn't have shown up before).

the diff between int (32bit) and long or void pointer (64bit) was the problem I reported earlier, with the 64bit patch.

do you think there would be many cases in your code where there's the assumption of 32bit sizes?

Share this post


Link to post
Share on other sites

Ok, some additional specification for the summoning special effects.

The info is sent like this:

id of the summoner, x, y (of the summoned animal)

all of them are 16b values

Share this post


Link to post
Share on other sites

Ok, some additional specification for the summoning special effects.

The info is sent like this:

id of the summoner, x, y (of the summoned animal)

all of them are 16b values

Instead of defining a special effect for each summons, how about saying it's a summon effect and add one or two bytes to define the actor type being added? We already have the actor XML's to define information about each actor already, so any extra info the special effects needs could be added there instead of having a massic case statement.

Share this post


Link to post
Share on other sites
Heh, yeah -- I'm not the only person making changes to the client around here -- far from it. Every time I do a cvs update, I get changes from others, and only some are in my code.

Well, unfortunately, I am the only person working on the Mac port of EL, so I have a lot of bugs to address now.

 

I ran with EYE_CANDY from the command line and got the following:

WindEffect (0x1d8d2e90) created.
WindEffect (0x1d8d30c0) created.
Deactivating effect 0x1d8d2e90(7301 > 250)
Deactivating effect 0x1d8d30c0(8381 > 250)
Bus error

A gdb trace gave me the following info:

<snip>
PID:	3731
Thread: 0

Exception:  EXC_BAD_ACCESS (0x0001)
Codes:	  KERN_PROTECTION_FAILURE (0x0002) at 0x00000008

Thread 0 Crashed:
0   <<00000000>> 	0x1c3430a0 0 + 473182368
1   GLEngine				 	0x045bc01b gleDrawArraysOrElements_Core + 157
2   GLEngine				 	0x04640f65 gleDrawArraysOrElements_VBO_Exec + 853
3   libGL.dylib				  0x92b0e575 glDrawArrays + 97
4   com.yourcompany.el_osx   	0x0000598e draw_3d_object_detail + 872
5   com.yourcompany.el_osx   	0x00006c9e draw_3d_objects + 543
6   com.yourcompany.el_osx   	0x000687e8 display_3d_ground_objects + 206
7   com.yourcompany.el_osx   	0x0006944d draw_sun_shadowed_scene + 808
</snip>

This was on the test server, immediately after logging in, and while the map was being loaded. Back to the debugging.....

Share this post


Link to post
Share on other sites

I wonder if the above crash has to do with wind on the test server. I have no issues (at least in SRM) on the regular server.

[edit] fixed other problem that was right here

 

[edit2] Well, compiling with EYE_CANDY and NEW_E3D_FORMAT allowed me to get onto the test server. Are they both necessary? If not, then someone needs to fix the case when NEW_E3D_FORMAT is not used.

Edited by 0ctane

Share this post


Link to post
Share on other sites
1 GLEngine 0x045bc01b gleDrawArraysOrElements_Core + 157

2 GLEngine 0x04640f65 gleDrawArraysOrElements_VBO_Exec + 853

3 libGL.dylib 0x92b0e575 glDrawArrays + 97

4 com.yourcompany.el_osx 0x0000598e draw_3d_object_detail + 872

5 com.yourcompany.el_osx 0x00006c9e draw_3d_objects + 543

6 com.yourcompany.el_osx 0x000687e8 display_3d_ground_objects + 206

7 com.yourcompany.el_osx 0x0006944d draw_sun_shadowed_scene + 808

 

None of those are in my code, so I can't help there. That's, what, shadows?

 

Summoning: Either way will work fine for me.

 

Ttlanhil: When I get a chance to try it out (this evening), I'll put some debugging statements in the fire effect that you can enable by uncommenting one line. That should help me track down what's wrong with the fire (and if we're lucky, what's causing your segfaults as well).

 

32 bit by 64 bit? Hmm. That only affects pointers, right? The only case that I can think of where I do anything unusual with pointers is in the wind effect: to give each particle a bit of an identity of its own, I use the lower order bits of the memory address of the particle as a number. However, nothing ever gets *written* to that address; it's just used as a component in the formula for determining how the particle reacts to wind. So, if the blowing leaves were moving strangely, I'd suspect that, but apart from that, I can't picture it having an effect. The rest of my use of pointers is pretty straightforward. I tend not to use pointers for arrays, either -- std::vector and std::map are better, with their automatic management of memory and autocleanup. If you grep through the eye candy code, you'll only see four instances of "delete[]", corresponding to the only four pointer arrays. The rest are all vectors and maps.

Share this post


Link to post
Share on other sites

Ttlanhil: Actually, I think I have an idea on why the fire looks so ugly for you (not why it's so green, but that may be related). I just noticed your framerate: fps 11. The eye candy system is pretty sophisticated; it checks your framerate, and lowers the Level Of Detail (LOD) if your framerate is getting low. In this case, your framerate is well below what I set as the lowest tolerable framerate (20 fps). So, the campfire is going to be at LOD 1 (minimum), which is pretty ugly.

 

That said, I should be able to pull a prettier fire than that ugly thing out even at LOD 1. A low level of detail greatly limits the number of particles available to me (so they have to be bigger), but the alpha on that smoke, at the very least, is still way too high. Plus, I should be able to fix the green. I bet your theory is correct: we probably have one of the "greener" fire particles (say, RGB=1.0, 0.9, 0.2), and it's brightening the grass in the background. This wouldn't be noticable on a higher level of detail because of all of the other particles. I could narrow the range that the green component can fluctuate over and see if that helps.

 

Also, I think I'll lower the minimum framerate from 20 to 15. I don't think someone getting 20 fps will want LOD 1 special effects. At least 2 or 3 at that point. LOD 10 (max) occurs at double the minimum framerate. So, FPS=30 would give you full detail effects, and FPS 15 would give you LOD 1 effects. Heck, perhaps I'll even lower it down to 12, and make the max be triple the minimum instead of double (36).

 

Another option would be to make the system even more sophisticated. Instead of lowering detail simply based on framerate, it could try to assess how much of the workload it is causing. Thus, if you only had one little special effect going and the framerate dropped, it would realize that it's not it's fault and keep the detail high. Probably more work than it's worth, though (it would take auto-benchmarking and the like), so I don't think I'll bother at this point.

 

Anyways, when I get home from work this evening, I'll take care of this and also hook in summoning effects.

 

Thanks!

Edited by KarenRei

Share this post


Link to post
Share on other sites

How about just allowing the people to select what LOD they want? That way those that want pretty looks and aren't worries about FPS can crank it up as high as they dare.

Share this post


Link to post
Share on other sites
Ttlanhil: Actually, I think I have an idea on why the fire looks so ugly for you (not why it's so green, but that may be related). I just noticed your framerate: fps 11. The eye candy system is pretty sophisticated; it checks your framerate, and lowers the Level Of Detail (LOD) if your framerate is getting low. In this case, your framerate is well below what I set as the lowest tolerable framerate (20 fps). So, the campfire is going to be at LOD 1 (minimum), which is pretty ugly.

Same "ugly" fire problem with the Mac client. My framerate is 44fps.

Share this post


Link to post
Share on other sites
How about just allowing the people to select what LOD they want?

 

The problem is that wouldn't be reactive. Let's say you select LOD 10 (max). Most of the time, this will be great. However, let's say you're in an invasion, and twenty people are all casting spells around you. Suddenly, it's not so great. That's why I implemented auto-reduction of LOD.

 

0ctane: Then I'll definitely need to hook in debugging statements; there goes my theory. At 44 fps, it should be at LOD 10 and have all the particles available to it that it wants. I'll take care of this tonight.

Share this post


Link to post
Share on other sites

Okay, well, while I can't do much on it from work, I did the quick stuff: changing the LOD thresholds as described above, and adding in a debugging statement. To build it with the debugging statement, in your make.conf, add in EYE_CANDY and DEBUG_CAMPFIRE.

 

Being at work, I haven't been able to test this; however, A) I did a compile test, :) they're pretty simple changes, and C) they won't affect most people, since you need -DEYE_CANDY for any eye_candy code to be called, and -DDEBUG_CAMPFIRE for the statement. So, feel free to try this out. Expect it to be quite spammy once you start a campfire (one long line per particle created); redirecting output might not be a bad idea.

Share this post


Link to post
Share on other sites

Hi All,

 

I just got the lates CVS (a lot of changes today it seems) and made a clean build. When I run, after login is finished and the map should be displayed... I crash with access violation on

 

glDrawArrays(GL_TRIANGLES, idx, num); in shadows.c; draw_3d_object_shadow_detail

 

First I though I had some old object files, so I cleaned and rebuild but the same thing happens again and again regadless of configuration (Debug or Release).

 

I tried it both with -DSFX/-DEYE_CANDY and without them. The effect is the same. Could someone verify that the latest CVS works for him/her with effects disabled?

 

 

EDIT: It seems to only crash on the test server, however on the regular server there is night so no shadows.

Edited by Kindar Naar

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

×