Jump to content
Eternal Lands Official Forums
Entropy

Special effects

Recommended Posts

Latest fixes in:

 

* Fixed the shadow map crash (not eye candy, but yeay!)

* Fixed some special effect centering issues

* Fixed a newly discovered special effect bug, wherein special effects

assumed the actor was at height zero because that's what the actor's z_pos always said.

* MSVC warning fixes

Edited by KarenRei

Share this post


Link to post
Share on other sites

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

Edited by Lachesis

Share this post


Link to post
Share on other sites

Lachesis,

 

Remember that I don't have a windows box to test on. Everything that you see for windows compilers was done based on suggestions by other people, if not outright written by other people, except the pragmas (which I stuck inside an existing WINDOWS block, assuming that it was correct, to try and help a windows user with their warnings). I simply cannot test windows code on my own.

 

If you would like the ifdefs changed, please tell me exactly what you would like them changed to. Otherwise, I may be checking in broken code.

 

You'll note that in the non-windows code (99.9% of the code -- the stuff that I wrote), I don't use macros. I'm well aware of their danger, and I'm not fond of them.

 

To sum up -- if you have some alternative code for me to put in there that's more correct for windows, please supply it. Otherwise, I'd just be shooting in the dark. I mean, I could take a go at it and hope for the best, based on the info that you just provided, but I don't like coding blind. Should I just assume that only MSC needs the new defines, and that the appropriate check is #ifdef _MSC_VER? What about the WINDOWS block around the #include -- should that be changed to _MSC_VER, or stay as WINDOWS? Would MSC have a problem with inline functions for min/max? I'm rather surprised that there is no native MSC min/max function -- or is there? Same with fmax, round, remainderf, and usleep -- are there equivalents? Can I assume that all of these exist in Dev-C?

Edited by KarenRei

Share this post


Link to post
Share on other sites

I saw an ice s2e sword, and the subtle effect was very nice. Sorry if someone has already mentioned it, but I want to mention a problem. I was walking along and did a regular heal. The effect stayed at the position of casting rather than following with my actor. I imagine this will happen with other "self" spells. In my original SFX code I was able to get around this problem by tracking the actor position.

Share this post


Link to post
Share on other sites

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 :P

 

#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.

Share this post


Link to post
Share on other sites

0ctane:

 

Nope, nobody has mentioned that yet, although I did know about it. It's only "kind of" that way. Each particle has a "mover" function, whether it's just a basic "position += velocity" type mover or something as complex as a literal simulation of 3d gravity with error correction. Most movers do care about where their "center" is in some way or another. For example, something with a gravity mover will be attracted to where the person walked to (although, as with gravity, the further away you are, the less the attraction). A spiral mover will spiral around the new position instead of the old one. And so on.

 

I could make self magic follow the actor if so desired. Target magic does, but I did that because target magic "homes in" on its target. Once it hits, like self magic, it doesn't care what the actor does. Again, this could be changed if desired. I kind of liked how it looks when a spell reacts to a moving actor (it gives some variety in appearence), so I left it that way.

 

Lachesis:

 

Well, I can try making some windows changes and hope that they don't break things for windows users. I'm always more than a bit uncomfortable checking in things that I can't test, though -- but, since everything I've put in for windows has effectively been this way, I guess it's not that different.

 

Ed: Code committed. Hopefully nothing will break.

Edited by KarenRei

Share this post


Link to post
Share on other sites

I have a new core dump for you. CVS just a few minutes ago (but there's been another window warnings fix since). Been playing for a few minutes, client crashed as I left TG storage. Here's the core trace:

 

Core was generated by `./el.x86.linux.bin'.
Program terminated with signal 11, Segmentation fault.
#0  0xb7a415bf in mallopt () from /lib/tls/libc.so.6
(gdb) bt
#0  0xb7a415bf in mallopt () from /lib/tls/libc.so.6
#1  0xb7a419f2 in free () from /lib/tls/libc.so.6
#2  0xb78ba3b1 in operator delete () from /usr/lib/libstdc++.so.6
#3  0x080f0090 in ec_remove_obstruction_by_object3d (obj3d=0xeb8c668) at eye_candy_wrapper.cpp:511
#4  0x080a0424 in destroy_map () at map_io.c:74
#5  0x080a0725 in load_map (file_name=0xbf818360 "./maps/map11.elm") at map_io.c:255
#6  0x080a0591 in change_map (mapname=0xbf818360 "./maps/map11.elm") at map_io.c:152
#7  0x080a67b7 in process_message_from_server (in_data=0xb3b006f0 "\a\022", data_length=20)
at multiplayer.c:843
#8  0x0809e793 in start_rendering () at main.c:111
#9  0x0809ea70 in main (argc=1, argv=0xbf81a884) at main.c:236
(gdb) up
#1  0xb7a419f2 in free () from /lib/tls/libc.so.6
(gdb) up
#2  0xb78ba3b1 in operator delete () from /usr/lib/libstdc++.so.6
(gdb) up
#3  0x080f0090 in ec_remove_obstruction_by_object3d (obj3d=0xeb8c668) at eye_candy_wrapper.cpp:511
511		   delete *iter;
Current language:  auto; currently c++

 

I'll update and recompile with debug enabled.

 

edit:

 

Somehow managed to remove the standard out log while writing this, here are the last few lines:

ImpactEffect (0xf4e4ee8) created.
ImpactEffect (0xf4e4ee8) destroyed.
TargetMagicEffect (0xe7bf0a8, 0) created(1).
ImpactEffect (0xe8ac4b8) created.
ImpactEffect (0xe8ac4b8) destroyed.
TargetMagicEffect (0xb6a78f0, 0) created(1).
ImpactEffect (0xf3d99f0) created.
ImpactEffect (0xf3d99f0) destroyed.
ImpactEffect (0xf08e488) created.
ImpactEffect (0xf08e488) destroyed.
ImpactEffect (0xe3e4bb8) created.
ImpactEffect (0xe3e4bb8) destroyed.
ImpactEffect (0xf2b57c8) created.
ImpactEffect (0xf2b57c8) destroyed.
ImpactEffect (0xf514430) created.
ImpactEffect (0xf514430) destroyed.
ImpactEffect (0xf8c2f70) created.
ImpactEffect (0xf8c2f70) destroyed.
ImpactEffect (0xf6a7fe8) created.
ImpactEffect (0xf6a7fe8) destroyed.
ImpactEffect (0xe39b6e0) created.
ImpactEffect (0xe39b6e0) destroyed.
Segmentation fault (core dumped)

Edited by bluap

Share this post


Link to post
Share on other sites

another one for you, seems to be the blood option (which I since turned off in config, not fond of crashes :)

there seem to be a number of floats with very small/large values

(gdb) r
Starting program: el.x86.linux.bin
[Thread debugging using libthread_db enabled]
[New Thread 47884485881040 (LWP 21879)]
[New Thread 1082677600 (LWP 21883)]
[New Thread 1091070304 (LWP 21884)]
[New Thread 1099463008 (LWP 21885)]
[Thread 1091070304 (zombie) exited]
[New Thread 1107855712 (LWP 21886)]
[Thread 1107855712 (zombie) exited]
SwordEffect (0x78f1520) created.
Deactivating effect 0x78f1520(8662.08 > 700)
Activating effect 0x78f1520(39.1484 < 700)
ImpactEffect (0x7997cc0) created.
ImpactEffect (0x7997cc0) destroyed.
ImpactEffect (0x79964a0) created.
SelfMagicEffect (0x79f0bb0) created.
ImpactEffect (0x79964a0) destroyed.
SelfMagicEffect (0x79f0bb0) destroyed.
SelfMagicEffect (0x79964a0) created.
SelfMagicEffect (0x79964a0) destroyed.
ImpactEffect (0x79c9e10) created.
ImpactEffect (0x79c9e10) destroyed.
ImpactEffect (0x7993530) created.
ImpactEffect (0x7993530) destroyed.
ImpactEffect (0x7993000) created.
ImpactEffect (0x7993000) destroyed.
ImpactEffect (0x79976d0) created.
ImpactEffect (0x79976d0) destroyed.
ImpactEffect (0x79e5f10) created.
ImpactEffect (0x79e5f10) destroyed.
SelfMagicEffect (0x7993530) created.
ImpactEffect (0x2aaaabf057a0) created.
ImpactEffect (0x2aaaabf057a0) destroyed.
SelfMagicEffect (0x7993530) destroyed.
SwordEffect (0x78f1520) destroyed.

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 47884485881040 (LWP 21879)]
0x0000000000412cc9 in get_actor_damage (actor_id=358, damage=18) at actor_scripts.c:1171
1171					blood_level=(int)powf(damage / powf(act->max_health, 0.5), 0.75) + 0.5;
(gdb) bt full
#0  0x0000000000412cc9 in get_actor_damage (actor_id=358, damage=18) at actor_scripts.c:1171
	act = (actor *) 0x0
	blood_level = -7.16203147e-07
	bone_list = {{-0.005407569, 0.0474412031, -0.0665755048}, {-0.030444365, 0.0482287295, 0.0775823221}, {
-0.162811026, 0.00194341317, 0.0951229036}, {-0.331641287, -0.256424844, 0.187488168}, {0.0806319118,
-0.201128691, 0.0458961725}, {0.187872425, -0.228021815, 0.0444641486}, {-0.00389305456, 0.0495318808,
0.0846828446}, {0.117366187, -0.0126638971, 0.136238575}, {0.273487002, -0.293416619, 0.191113979}, {
-0.135671169, -0.228183672, 0.0523113459}, {-0.242242008, -0.256121665, 0.0429320857}, {-0.0084892083,
0.0474894159, 0.0813959166}, {-0.00780818099, 0.0559395738, 0.249471992}, {-0.00278958632, 0.047691185,
0.403601766}, {-0.00884878077, 0.0560990088, 0.532945514}, {-0.00922563765, 0.242735729, -0.026951313}, {
-0.0412982479, -0.134731159, -0.000871181488}, {-0.00945370365, 0.0534447022, 0.524652362}, {0.206399307,
0.0506201833, 0.505973697}, {0.2344096, -0.0294789523, 0.256208897}, {0.199199438, -0.233811766, 0.228717536},
 {0.1903456, -0.299189568, 0.208566383}, {-0.0116625614, 0.0531620905, 0.527843058}, {-0.23207587, 0.0577777773,
0.507607579}, {-0.266563058, 0.0127503425, 0.245390117}, {-0.289102733, -0.19487296, 0.239523813}, {
-0.286156952, -0.260427266, 0.212472767}, {-0.286156952, -0.260427237, 0.212472767}, {0.250627697,
-0.269083172, 0.3291713}, {-0.0064736614, 0.0505228303, 0.556843519}, {1.33123354e-43, 0, 0}, {0,
-7.16528348e-07, 4.59163468e-41}, {5.60519386e-45, 0, -2.73106409e+34}, {1.56216753e-41, 0, 0}, {0,
7.62306365e-43, 1.40129846e-45}, {0, 0, 0}, {0, 0, 0}, {0, 8.82818033e-44, 0}, {1.40129846e-45, 0, 0}, {0, 0,
0}, {0, 0, 0}, {0, 0, 0}, {0, 0, 1.40129846e-45}, {0, 2.80259693e-45, 0}, {4.20389539e-45, 0, 0}, {0,
2.80259693e-45, 0}, {0, 0, 0}, {0, 0, 0}, {1.40129846e-45, 0, 2.80259693e-45}, {0, 4.20389539e-45, 0}, {0, 0,
2.80259693e-45}, {0, 0, 0}, {0, 0, 0}, {0, 1.40129846e-45, 0}, {2.80259693e-45, 0, 4.20389539e-45}, {0, 0, 0},
 {4.20389539e-45, 0, 0}, {0, 4.20389539e-45, 0}, {9.80908925e-45, 0, 0}, {0, 4.20389539e-45, 0}, {2.80259693e-45,
0, 1.40129846e-45}, {0, 0, 0}, {9.80908925e-45, 0, 0}, {0, 0, 0}, {8.82818033e-44, 0, 0}, {0, 0, 0}, {0, 0,
0}, {0, 0, 0}, {0, 0, 0}, {0, 1.40129846e-45, 0}, {0, 0, 0}, {0, -7.16474233e-07, 4.59163468e-41}, {
-7.15966962e-07, 4.59163468e-41, 7.00649232e-45}, {0, 0, 0}, {-7.1647446e-07, 4.59163468e-41, 5.60519386e-45},
 {0, -2.73106409e+34, 1.56216753e-41}, {-7.15695933e-07, 4.59163468e-41, -1.80659383e+33}, {7.62306365e-43,
2.87266185e-42, 0}, {-nan(0x7fffff), 0, 1.40129846e-45}, {0, 4.65062934e-41, 0}, {0, 0, 0}, {0,
1.38027899e-42, 0}, {-2.10715716e+33, 1.56216753e-41, 0}, {0, 9492.60352, 0}, {0, 0, -7.15695933e-07}, {
4.59163468e-41, 1.1479437e-41, 0}, {1.61891653e-34, 0, -7.15690476e-07}, {4.59163468e-41, -1.80563582e+33,
1.56216753e-41}, {2.24207754e-44, 6.72623263e-44, -7.1562954e-07}, {4.59163468e-41, -7.15618626e-07,
4.59163468e-41}, {1.61891653e-34, 0, 0}, {0, -1.81306934e+33, 1.56216753e-41}, {1.40129846e-43, 0,
-1.79852308e+33}, {1.56216753e-41, 0, 0}, {4.48415509e-44, 4.59163468e-41, -7.15695933e-07}, {4.59163468e-41,
1.61891653e-34, 0}, {1.40129846e-44, 0, -1.80765536e+33}, {1.56216753e-41, 0, 0}, {-7.15681381e-07,
4.59163468e-41, -7.15695933e-07}, {4.59163468e-41, 1.61891653e-34, 1.40129846e-45}, {-nan(0x7fffff),
1.40129846e-45, -2.10759292e+33}, {1.56216753e-41, -2.10620147e+33, 1.56216753e-41}, {0, 4.59163468e-41,
1.40129846e-44}, {1.40129846e-45, -1.92497386e+33, 1.56216753e-41}, {0, 0, 0}, {0, 0, 0}, {0, 0, 0}, {0, 0,
1.40129846e-45}, {0, 0, 0}, {0, 0, 0}, {0, 0, 0}, {0, 0, 0}, {0, 0, 0}, {0, 0, 0}, {0, 0, 3.50324616e-44}, {0,
9.80908925e-45, 0}, {0, 0, 0}, {0, 0, 0}, {0, 0, 0}, {0, -7.15561328e-07, 4.59163468e-41}, {-7.15561328e-07,
4.59163468e-41, 3.58732407e-43}, {0, 3.58732407e-43, 0}, {0, 0, -1.92502988e+33}, {1.56216753e-41, 0, 0}, {0,
0, 0} <repeats 13 times>, {0, -1.80614461e+33, 1.56216753e-41}, {-7.1566501e-07, 4.59163468e-41, 0}, {0, 0,
0}, {0, 0, 0}, {0, 0, 0}, {0, 0, 3.36311631e-44}, {6.72623263e-44, -7.15694114e-07, 4.59163468e-41}, {
-7.156832e-07, 4.59163468e-41, 0}, {0, 0, 0}, {0, 0, 0}, {0, 0, 0}, {0, 0, 0}, {0, 0, 0}, {0, 0,
-7.1566501e-07}, {4.59163468e-41, -7.15561725e-07, 4.59163468e-41}, {0, 0, -7.15697411e-07}, {4.59163468e-41,
0, 0}, {1.61891653e-34, 0, -7.15695933e-07}, {4.59163468e-41, -7.15681381e-07, 4.59163468e-41}, {
-1.9250274e+33, 1.56216753e-41, 6.92462566e-39}, {0, -7.16164323e-07, 4.59163468e-41}, {-1.80844548e+33,
1.56216753e-41, -1.80172717e+36}, {0, -7.15697354e-07, 4.59163468e-41}, {-7.15697411e-07, 4.59163468e-41,
-7.15695933e-07}, {4.59163468e-41, -7.15695933e-07, 4.59163468e-41}, {-7.15695933e-07, 4.59163468e-41,
-7.15695933e-07}, {4.59163468e-41, -7.15695933e-07, 4.59163468e-41}, {-7.15697411e-07, 4.59163468e-41, 0}, {0,
0, 0}, {0, 0, 0}, {0, 0, 0}, {0, 0, 1.43492963e-42}, {0, 1.61748023e-34, 0}, {0, 0, -7.15695933e-07}, {
4.59163468e-41, -1.80659383e+33, 1.56216753e-41}, {4.20389539e-45, 0, -nan(0x7fffff)}, {0, 1.40129846e-45, 0},
 {4.63269272e-41, 0, 0}, {0, 0, 0}, {0, 0, -2.10715716e+33}, {1.56216753e-41, 0, 0}, {8133.97412, 0,
7.72819838e-16}, {0, 1.61891653e-34, 0}, {-7.16162049e-07, 4.59163468e-41, -7.15695933e-07}, {4.59163468e-41,
-1.9250274e+33, 1.56216753e-41}, {-1.80563582e+33, 1.56216753e-41, 2.24207754e-44}, {6.72623263e-44,
-7.15694114e-07, 4.59163468e-41}, {-7.156832e-07, 4.59163468e-41, 1.61891653e-34}, {0, 0, 0}, {
-1.81306934e+33, 1.56216753e-41, -7.16162049e-07}, {4.59163468e-41, 0, 0}, {9.2205439e-43, 0,
-8.21344403e-13}, {1.53049818e-41, -7.1569599e-07, 4.59163468e-41}, {-1.81474814e+33, 1.56216753e-41,
1.40129846e-44}, {0, -1.83236898e+33, 1.56216753e-41}, {1.61891653e-34, 0, -7.16162049e-07}, {4.59163468e-41,
0, 0}, {0, 0, 0}, {0, -1.81662718e+33, 1.56216753e-41}, {1.61891653e-34, 0, -1.80666347e+33}, {1.56216753e-41,
6.92462566e-39, 1.40129846e-45}, {1.61891653e-34, 0, 2.87266185e-42}, {0, -1.83236898e+33, 1.56216753e-41}, {
1.40129846e-45, 0, 4.65062934e-41}, {0, 0, 0}, {0, 0, 0}...}
	total_bones = 130
	bone = 122952543
	bone_x = 0
	bone_y = -7.16203715e-07
	bone_z = 1.40129846e-45
#1  0x000000000047030e in process_message_from_server (in_data=0x754f7e0 "/\005", data_length=7)
at multiplayer.c:1465
	text_buf = "\205[freeone3000]: \201Hi ttl.\000ses 4k pm me\000e for 11gc each, pm me with inv for more or wanted to see what I am buing\000gs(95.00).\000ocation.\000. If you would rather learn by doing, talk to the Tutorial NPC, whic"...
#2  0x0000000000465a29 in start_rendering () at main.c:110
	message = (message_t *) 0x754f7c0
	event = {type = 24 '\030', active = {type = 24 '\030', gain = 81 'Q', state = 136 '\210'}, key = {
type = 24 '\030', which = 81 'Q', state = 136 '\210', keysym = {scancode = 2 '\002', sym = 4118889662,
  mod = 11148, unicode = 21185}}, motion = {type = 24 '\030', which = 81 'Q', state = 136 '\210', x = 2,
y = 0, xrel = 17598, yrel = -2687}, button = {type = 24 '\030', which = 81 'Q', button = 136 '\210',
state = 64 '@', x = 2, y = 0}, jaxis = {type = 24 '\030', which = 81 'Q', axis = 136 '\210', value = 2},
 jball = {type = 24 '\030', which = 81 'Q', ball = 136 '\210', xrel = 2, yrel = 0}, jhat = {type = 24 '\030',
which = 81 'Q', hat = 136 '\210', value = 64 '@'}, jbutton = {type = 24 '\030', which = 81 'Q',
button = 136 '\210', state = 64 '@'}, resize = {type = 24 '\030', w = 2, h = -176077634}, expose = {
type = 24 '\030'}, quit = {type = 24 '\030'}, user = {type = 24 '\030', code = 2, data1 = 0x2b8cf58144be,
data2 = 0x461452c1}, syswm = {type = 24 '\030', msg = 0x2b8cf58144be}}
	network_thread = (SDL_Thread *) 0x75717f0
	message_queue = (queue_t *) 0x7453720
	done = 0
	network_thread_data = {0x7453720, 0x824e40}
#3  0x0000000000465d8b in main (argc=1, argv=0x7fffb5406ae8) at main.c:235
No locals.

ed:yay, another one :P

SelfMagicEffect (0x79fc930) created.
SelfMagicEffect (0x7a81f40) created.

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 47574670265552 (LWP 22877)]
0x00000000004fa41d in ec::MathCache::powf_0_1_rough_close (this=0x826c40, base=nan(0x400000), power=0.100000001)
at eye_candy/math_cache.cpp:2179
2179	  return (powf_map[index1][index2] * (1.0 - percent2)) + (powf_map[index1][index2 + 1] * percent2);
Current language:  auto; currently c++
(gdb) bt full
#0  0x00000000004fa41d in ec::MathCache::powf_0_1_rough_close (this=0x826c40, base=nan(0x400000),
power=0.100000001) at eye_candy/math_cache.cpp:2179
	index1 = -2147483648
	percent2 = 0.600000024
	index2 = 28
#1  0x00000000004decd0 in ec::Particle::flare (this=0x77621e0) at eye_candy/eye_candy.cpp:700
	offset = 8724
	flare_val = 0
	__PRETTY_FUNCTION__ = "virtual coord_t ec::Particle::flare() const"
#2  0x00000000004deecc in ec::Particle::draw (this=0x77621e0, usec=43110) at eye_candy/eye_candy.cpp:608
	tempsize = -nan(0x400000)
#3  0x00000000004ddbc2 in ec::EyeCandy::draw (this=0x8264e0) at eye_candy/eye_candy.cpp:1404
	p = (class ec::Particle *) 0x77621e0
	iter2 = {_M_node = 0x77622a0}
	e = (class ec::Effect *) 0x79fc930
	iter = {_M_current = 0x399e800}
#4  0x00000000004cafb5 in ec_draw () at eye_candy_wrapper.cpp:258
No locals.
#5  0x000000000044c0c1 in display_game_handler (win=0x39a4f30) at gamewin.c:691
	str = "\220\217�\177\000\000�C\000\000\000\000\000\002", '\0' <repeats 15 times>, "\037\000\000\000\001\000\000\000\a\000\000\000�217�\177\000\000R\036C\000\000\000\000\000\006\000\000\000D+\000\000\003\000\000\000\000\000\000\000\000\000\000o\000\000\000=\031\005�+\000\000\000 \000@\000\000\000\000`U\000\000\000\000\000\020\222�\177", '\0' <repeats 19 times>, " \000@\000\000\000\000@\220�000\000\000\0000O\232\003\000\000\000\000\000 \000@\000\000\000\000=\000\000\000\000>"
	i = 0
	any_reflection = 2
	mouse_rate = 2
	main_count = 5163
	times_FPS_below_3 = 0
	fps = {26, 26, 26, 26, 26}
	shadows_were_disabled = 0
	__FUNCTION__ = "display_game_handler"
#6  0x000000000043ec76 in draw_window (win=0x39a4f30) at elwindows.c:1059
	ret_val = 0
	W = (widget_list *) 0x39a3670
#7  0x000000000043f2a6 in display_window (win_id=0) at elwindows.c:1207
No locals.
#8  0x000000000043c556 in display_windows (level=1) at elwindows.c:57
	id = -1
	next_id = -9999
	i = 0
#9  0x0000000000435c17 in draw_scene () at draw_scene.c:101
	__FUNCTION__ = "draw_scene"
#10 0x0000000000465aab in start_rendering () at main.c:123
	event = {type = 4 '\004', active = {type = 4 '\004', gain = 0 '\0', state = 0 '\0'}, key = {
type = 4 '\004', which = 0 '\0', state = 0 '\0', keysym = {scancode = 43 '+', sym = 458744, mod = KMOD_NONE,
  unicode = 0}}, motion = {type = 4 '\004', which = 0 '\0', state = 0 '\0', x = 555, y = 351, xrel = -8,
yrel = 6}, button = {type = 4 '\004', which = 0 '\0', button = 0 '\0', state = 0 '\0', x = 555, y = 351},
 jaxis = {type = 4 '\004', which = 0 '\0', axis = 0 '\0', value = 555}, jball = {type = 4 '\004', which = 0 '\0',
ball = 0 '\0', xrel = 555, yrel = 351}, jhat = {type = 4 '\004', which = 0 '\0', hat = 0 '\0',
value = 0 '\0'}, jbutton = {type = 4 '\004', which = 0 '\0', button = 0 '\0', state = 0 '\0'}, resize = {
type = 4 '\004', w = 23003691, h = 458744}, expose = {type = 4 '\004'}, quit = {type = 4 '\004'}, user = {
type = 4 '\004', code = 23003691, data1 = 0x6fff8, data2 = 0x0}, syswm = {type = 4 '\004', msg = 0x6fff8}}
	network_thread = (SDL_Thread *) 0x757cb20
	message_queue = (queue_t *) 0x757cac0
	done = 0
	network_thread_data = {0x757cac0, 0x824e40}
#11 0x0000000000465d8b in main (argc=1, argv=0x7fffd7b39218) at main.c:235

Edited by ttlanhil

Share this post


Link to post
Share on other sites

Bluap, can you reproduce this? I can't. I also looked over the code, and didn't see anything out of the ordinary. May well be a memory leak, but it's too soon to say.

 

Ttlanhil: I'll check into that.

Edited by KarenRei

Share this post


Link to post
Share on other sites

Checked in:

 

* Fix for blood crash (check for null actor)

* Extra debugging info to detect NaNs, report them, and exit, in order to

help track down the source.

Share this post


Link to post
Share on other sites

got it at last :wub: (shield again)

HarvestingEffect (0x7ebb100) destroyed.
SelfMagicEffect (0x8346880) created.
BagEffect (0x77be3a0) created.
SelfMagicEffect (0x7880d40) created.
BagEffect (0x77be3a0) destroyed.
SelfMagicEffect (0x8346880) destroyed.
SelfMagicEffect (0x7eaee20) created.
SelfMagicEffect (0x7880d40) destroyed.
SelfMagicEffect (0x7846b60) created.
SelfMagicEffect (0x7eaee20) destroyed.
SelfMagicEffect (0x7846b60) destroyed.
SelfMagicEffect (0x7846b60) created.
ERROR (5, Report Me!): 0x7846b60: 0x7846c50: <-0.448073, 0.2, nan>, <0.21845, 0.324203, 0.0122582>
SelfMagicEffect (0x7846b60) destroyed.

Program exited with code 01.

ed: ooh, another one!

SelfMagicEffect (0x83943b0) created.
SelfMagicEffect (0x83943b0) destroyed.
BagEffect (0x7ea8f00) created.
BagEffect (0x7ea8f00) destroyed.
BagEffect (0x7ea8f00) created.
BagEffect (0x7ea8f00) destroyed.
SelfMagicEffect (0x783bcc0) created.
ERROR (5, Report Me!): 0x783bcc0: 0x76613b0: <nan, nan, nan>, <nan, nan, nan>
SelfMagicEffect (0x783bcc0) destroyed.

Program exited with code 01.

Edited by ttlanhil

Share this post


Link to post
Share on other sites

Thanks, ttlanhil :wub: Let's try another iteration, now. I just committed in a few more debugging statements and made a few tweaks that could eliminate a few NaN possibilities in rare special cases. Let's see how this goes.

Edited by KarenRei

Share this post


Link to post
Share on other sites
Nope, nobody has mentioned that yet, although I did know about it. It's only "kind of" that way. ... For example, something with a gravity mover will be attracted to where the person walked to (although, as with gravity, the further away you are, the less the attraction). A spiral mover will spiral around the new position instead of the old one. And so on.

 

I could make self magic follow the actor if so desired. Target magic does, but I did that because target magic "homes in" on its target. Once it hits, like self magic, it doesn't care what the actor does. Again, this could be changed if desired. I kind of liked how it looks when a spell reacts to a moving actor (it gives some variety in appearence), so I left it that way.

Well, in my opinion, having a healing effect left behind just looks strange. If someone was walking behind you, they might think you farted. :wub: Maybe the gravity can be much stronger so that it sticks more to the actor?

 

I think making the healing effect a little more subtile might be advantagous too, then lower level players will think, "oh, that is neat...I can't wait to see what a higher level spell looks like". Right now, the heal effect (which only gives back a few health) is about as big as a radon pouch (which can take away a lot of health). Long ago in this thread we had a discussion about effects being somewhat proportional to casting level.

Share this post


Link to post
Share on other sites

Certainly can do, on both counts. I may or may not get to that tonight, depending on how debugging the NaN bug goes (wouldn't want to work on this in the middle of that).

Share this post


Link to post
Share on other sites

Hi Karen,

 

Could you please patch the current codes for MSVC:

 

Index: eye_candy/eye_candy.h
===================================================================
RCS file: /cvsroot/elc/elc/eye_candy/eye_candy.h,v
retrieving revision 1.22
diff -u -r1.22 eye_candy.h
--- eye_candy/eye_candy.h	5 Apr 2007 15:26:46 -0000	1.22
+++ eye_candy/eye_candy.h	5 Apr 2007 15:55:48 -0000
@@ -7,6 +7,7 @@

#if defined(_WIN32) || defined(_WIN64)
 #include <windows.h>	 
+ #include <float.h>
#else
 #include <sys/time.h>
 #include <time.h>
@@ -76,6 +77,8 @@

#ifdef _MSC_VER
 #define copysign _copysign
+ #define isnan _isnan
+ #define isinf !_finite
 inline float fmax(const float a, const float b) { return ((a < b) ? b : a); };
 inline float round(const float a) { return (a - floor(a) < 0.5f ? floor(a) : ceil(a)); };
 inline float remainderf(const float a, const float b) { return (a - (float)round(a / b) * b); };

Share this post


Link to post
Share on other sites

Bluap, can you reproduce this? I can't. I also looked over the code, and didn't see anything out of the ordinary. May well be a memory leak, but it's too soon to say.

Doing the same actions, I did once, but got no debug at all that time. I just ran though valgrind, trying the same actions. Nothing was reported. I had been playing for a hour or so the first time so anything could have caused it. I'll keep you posted.

Share this post


Link to post
Share on other sites

Kindar: Now that's what I like to see -- Windows code by someone who can actually test it! :confused: Committed.

 

 

So -- open bugs for me to clean up. All but the first will probably need outside help in reproducing them:

 

1) Octane would like self magic to follow you as you walk instead of just being attracted to you, and for heal to be scaled down (anything else? Now's the time.).

2) Bluap's hard to reproduce (obstruction crash? Memory leak? Too soon to say).

3) Ttlanhil's random NaNs (in progress).

4) Ttlanhil's oddities -- video card? Too soon to say. Has anyone else seen anything like a green teleport effect? I certainly haven't; seems weird, although I do have an idea that I can try this evening. What was the other oddity you had?

Edited by KarenRei

Share this post


Link to post
Share on other sites
Kindar: Now that's what I like to see -- Windows code by someone who can actually test it! :confused: Committed.

 

:D Thanks. Please remember that this is only for MSVC. I don't build with gcc (DevC++).

Share this post


Link to post
Share on other sites

Just had another crash while changing maps. Had been playing for a while. This time, the crash was not in eye candy but I post here as the crash was very similar to may last report when it was. Someone is corrupting memory leading to problems elsewhere I suspect....

 

... hundreds of lines snipped but I have many more saved.....
ImpactEffect (0xe3e42e8) created.
ImpactEffect (0xea221e8) created.
ImpactEffect (0xe287e98) destroyed.
ImpactEffect (0xe3e42e8) destroyed.
ImpactEffect (0xe477780) created.
ImpactEffect (0xea221e8) destroyed.
ImpactEffect (0xea3b590) created.
BagEffect (0xe8cac58) created.
ImpactEffect (0xe477780) destroyed.
ImpactEffect (0xea3b590) destroyed.
BagEffect (0xe8cac58) destroyed.
BagEffect (0xe7a80a8) created.
BagEffect (0xe7a80a8) destroyed.
SelfMagicEffect (0xea45d28) created.
Segmentation fault (core dumped)

 

Program terminated with signal 11, Segmentation fault.
#0  0xb7a535bf in mallopt () from /lib/tls/libc.so.6
(gdb) bt
#0  0xb7a535bf in mallopt () from /lib/tls/libc.so.6
#1  0xb7a539f2 in free () from /lib/tls/libc.so.6
#2  0x080a020a in destroy_map () at map_io.c:77
#3  0x080a04f9 in load_map (file_name=0xbfa475a0 "./maps/map2.elm")
at map_io.c:255
#4  0x080a0365 in change_map (mapname=0xbfa475a0 "./maps/map2.elm")
at map_io.c:152
#5  0x080a659f in process_message_from_server (in_data=0xb3c006a8 "\a\021",
data_length=19) at multiplayer.c:843
#6  0x0809e56a in start_rendering () at main.c:110
#7  0x0809e847 in main (argc=1, argv=0xbfa49ac4) at main.c:235
(gdb) up
#1  0xb7a539f2 in free () from /lib/tls/libc.so.6
(gdb) up
#2  0x080a020a in destroy_map () at map_io.c:77
77											  free(objects_list[i]);
(gdb) print i
$1 = 318
(gdb) print (objects_list[i])
$2 = (object3d *) 0xf712840
(gdb) print *objects_list[i]
$3 = {file_name = "./3dobjects/ruins/rubble5.e3d", '\0' <repeats 50 times>,
 id = 318, x_pos = 26.1950264, y_pos = 16.2572212, z_pos = 0, x_rot = 0,
 y_rot = 0, z_rot = 50, matrix = {0.642787635, 0.766044438, 0, 0,
-0.766044438, 0.642787635, 0, 0, 0, 0, 1, 0, 26.1950264, 16.2572212, 0,
1}, self_lit = 0 '\0', blended = 0 '\0', display = 1 '\001',
 state = 0 '\0', r = 0, g = 0, b = 0, clouds_uv = 0x0, cloud_vbo = 0,
 e3d_data = 0xf66b070, last_acessed_time = 2463035, flags = 0}
(gdb) list
72
73	  #ifdef  EYE_CANDY
74											  ec_remove_obstruction_by_object3 d(objects_list[i]);
75	  #endif
76
77											  free(objects_list[i]);
78											  objects_list[i]=NULL;//kill any refference to it
79									  }
80					  }
81			  // reset the top pointer

Just as an observation, objects_list has just been passed to ec_remove_obstruction_by_object3() so may be there's a relation with my last crash report.....

Share this post


Link to post
Share on other sites

I doubt it -- the function doesn't touch the obj3d; it just compares to it. I'd have delcared it const, but I know that C's const support isn't as good as C++'s const support, and I decided it wasn't worth the risk of introducing errors that my compiler wouldn't give but others' compilers would.

 

This really looks like a memory leak. Which means that it could be anywhere in EL. Oh, what fun.

Edited by KarenRei

Share this post


Link to post
Share on other sites

okay, I have a with and without shot of the bug I talked to you about before, with the tp platform, at http://s17.photobucket.com/albums/b62/ttlanhil/other/ ... see the orange/purple in the bad version... that flickers on and off (and seems to often line up with the path behind the beam, if that helps) hopefully that shows what I mean :confused: (same thing has happened with harv effects and all, the beam not being drawn as it should)

Share this post


Link to post
Share on other sites

Ttlanhil: I'll put in some debugging statements for you this evening.

 

Update: Hmm. I'm not sure what debugging I can put in there! By all means, it looks like your columns of light are being textured by an invalid texture. Yet, the columns are drawn with glDisable(GL_TEXTURE_2D) called right before the rendering. Since neither GL_TEXTURE_1D nor GL_TEXTURE_3D are called anywhere in the code, why on earth it would use a texture is beyond my mere mortal reasoning.

 

Has anyone else seen this? Does anyone else have any ideas?

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

  • Recently Browsing   0 members

    No registered users viewing this page.

×