Jump to content
Eternal Lands Official Forums
Entropy

Special effects

Recommended Posts

Larry: I can't see where most of that is, but what I can see isn't in eye candy.

I think he's seeing other symptoms of something mangling memory. Who knows if it's related to eye condy or not. This might even be the same problem Bluap's been having.

Share this post


Link to post
Share on other sites

Kindar: The email isn't showing up. Did it bounce or something?

 

Learner: That's what I suspect. I'd recommend that anyone who is having trouble with crashes, for now, run without shadow mapping. Bluap and others have said that disabling it seems to work.

Edited by KarenRei

Share this post


Link to post
Share on other sites

Larry: Well, it's too soon to say. However, I would try disabling shadow mapping. If that fixes it, then it's a known bug, and there's no need to start a new thread.

Share this post


Link to post
Share on other sites

Compiler error on debug statement: whoops, my bad. That should be "base->camera", not "camera".

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 47635601011712 (LWP 19141)]
0x00000000004ac651 in check_sub_nodes (bbox_tree=0x3e9bdf0, sub_node=0, in_mask=63) at bbox_tree.c:258
258					 result = check_aabb_in_frustum(bbox_tree->nodes[sub_node].bbox, bbox_tree->intersect[idx].frustum, in_mask, &out_mask);
(gdb) backtrace
#0  0x00000000004ac651 in check_sub_nodes (bbox_tree=0x3e9bdf0, sub_node=0, in_mask=63) at bbox_tree.c:258
#1  0x00000000004ac578 in check_bbox_tree (bbox_tree=0x3e9bdf0) at bbox_tree.c:440
#2  0x0000000000447d88 in CalculateFrustum () at frustum.c:586
#3  0x0000000000448da2 in display_game_handler (win=0x3b792c0) at gamewin.c:574
#4  0x000000000043caa5 in draw_window (win=0x3b792c0) at elwindows.c:1059
#5  0x000000000043d0d2 in display_window (win_id=0) at elwindows.c:1207
#6  0x000000000043a3ee in display_windows (level=1) at elwindows.c:57
#7  0x0000000000434057 in draw_scene () at draw_scene.c:98
#8  0x000000000046132d in start_rendering () at main.c:123
#9  0x000000000046160b in main (argc=1, argv=0x7fffa5b16988) at main.c:235

Segfault occurs right after login, tried with point particles on and off... so, no output yet :D

(I'm close to one of the fires here btw.)

 

edit: just saw the shadow mapping thing, I'll try again without that and edit this post.

edit2: no change :(

edit3: I hope the output above is helpful, if not, I'll make Larry help me ;) (I'm new at debugging :huh:)

Edited by Ermabwed

Share this post


Link to post
Share on other sites

None of that is eye candy code. Could be a mem leak, as previously mentioned. Try building without the option EYE_CANDY.

That still gives segfault, output is different though:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 47024108673344 (LWP 20350)]
0x00000000004acba9 in add_dynamic_aabb_to_abt_node (bbox_tree=0x38644d0, node=0, bbox=
	{bbmin = {70.3627014, 111.362701, -13.1000004}, bbmax = {71.1372986, 112.137299, 14.8999996}}, ID=0, type=18,
texture_id=97, md5=0x4c20d0 "") at bbox_tree.c:971
971					 if (check_aabb_aabb(bbox_tree->nodes[node].orig_bbox, bbox, 1.1f))
(gdb) backtrace
#0  0x00000000004acba9 in add_dynamic_aabb_to_abt_node (bbox_tree=0x38644d0, node=0, bbox=
	{bbmin = {70.3627014, 111.362701, -13.1000004}, bbmax = {71.1372986, 112.137299, 14.8999996}}, ID=0, type=18,
texture_id=97, md5=0x4c20d0 "") at bbox_tree.c:971
#1  0x00000000004acae7 in add_aabb_to_abt (bbox_tree=0x38644d0, bbox=
	{bbmin = {70.3627014, 111.362701, -13.1000004}, bbmax = {71.1372986, 112.137299, 14.8999996}}, ID=0, type=18,
texture_id=97, md5=0x4c20d0 "", dynamic=1) at bbox_tree.c:994
#2  0x00000000004ad295 in add_particle_to_abt (bbox_tree=0x38644d0, ID=0, bbox=
	{bbmin = {70.3627014, 111.362701, -13.1000004}, bbmax = {71.1372986, 112.137299, 14.8999996}}, sblend=770, dblend=1,
dynamic=1) at bbox_tree.c:1018
#3  0x000000000047588d in create_particle_sys (def=0x39c2e60, x=70.75, y=111.75, z=-0.600000024, dynamic=1) at particles.c:843
#4  0x000000000047435f in add_particle_sys (file_name=0x4baf40 "./particles/teleport_in.part", x_pos=70.75, y_pos=111.75,
z_pos=-0.600000024, dynamic=1) at particles.c:664
#5  0x000000000047457d in add_particle_sys_at_tile (file_name=0x4baf40 "./particles/teleport_in.part", x_tile=141, y_tile=223,
dynamic=1) at particles.c:717
#6  0x00000000004694a6 in process_message_from_server (in_data=0x71fbcb0 "\f\005", data_length=7) at multiplayer.c:933
#7  0x000000000045fc4b in start_rendering () at main.c:110
#8  0x000000000045ffab in main (argc=1, argv=0x7fff056834e8) at main.c:235

Should I post that in bug forum?

Share this post


Link to post
Share on other sites

The eye candy otion patch [1] is now on BerliOS. I must say it doesn't have any perceivable effect on performance on my system, though. Btw, the extremely low framerates were attributed to enabled profiling, I had it enabled somewhen in the past and forgot about it when I got back to the client >_< Still there's something blocking the renderer thread periodically (about 2/s), surprisingly without using any noticeable CPU resources, O_o but that's off topic here. The patch is safe to check-in but I left it as a patch for now just in case. I'd recommend checking it in soon though, so that eye candy can be disabled in the release client.

 

Btw, there's a couple of patches open on BerliOS, if someone can tell me which have been checked in, I can mark them as accepted. I'd also recommend making ttlanhil a patch admin, he's been most active patch reviewing, so he can do this himself.

 

I needed to fix the bugs so I could work on the patch, Karen :huh: But I have serious doubts that I catched em all. Someone needs to take a closer look at all the sane_snprintf's and the sane_strncpy's but uni will have me back tomorrow so I'm afraid I'll be indisposed.

 

[1] http://developer.berlios.de/patch/index.ph...p;group_id=1256

Share this post


Link to post
Share on other sites

Thanks, Lachesis. I appreciate all of your help. I'll look over your patch this evening, make any changes necessary, and get it in. I agree -- the sooner, the better.

Share this post


Link to post
Share on other sites

Kindar Naar, Ermabwed: I haven't gotten an email from either of you. Hindar, you had warnings that you wanted me to take care of; Ermabwed, you had a more serious issue (point particle drawing causing inconsistent behavior).

 

If you have sent, consider resending, or posting it somewhere. I'd like to take care of these ASAP. :blush:

Share this post


Link to post
Share on other sites

Kindar Naar, Ermabwed: I haven't gotten an email from either of you. Hindar, you had warnings that you wanted me to take care of; Ermabwed, you had a more serious issue (point particle drawing causing inconsistent behavior).

 

If you have sent, consider resending, or posting it somewhere. I'd like to take care of these ASAP. :)

sent. :)

edit: about 4MB of bzipped2 logfile attached :blush:

Edited by Ermabwed

Share this post


Link to post
Share on other sites

Hi Karen, the patch already is closed (status:accepted) :D And you need to be patch admin in order to close a patch, dunno if you are.

Share this post


Link to post
Share on other sites

Ermabwed:

 

I just noticed something about your screenshots. Where's the rest of your client window?

 

Also, I just committed some minor changes to the algorithm that may or may not help you. Unfortunately, the logs were too cluttered to be able to make much out of them. If this doesn't do the trick, I'll probably create a custom effect that has one particle of a fixed size, in a fixed position.

Edited by KarenRei

Share this post


Link to post
Share on other sites
Kindar Naar: MSVC warning fixes in place. Let me know if I missed any.

 

Just a few more left. Here is the log.

 

You mentioned in the other thread that after the release you would like ot run with -Werror to clean all the warning. Do you plan to correct MSVC warnings as well (becuase as I saw the latest changes, right now you just disabled them with #pragma)?

Share this post


Link to post
Share on other sites

Only a few types of errors are disabled with pragma -- ones that I feel are irrelevant and that MSVC shouldn't be complaining about in the first place :). In fact, I pretty much had to pragma certain ones to get rid of them. For example, complaining about expressions that always evaluate to true or false (and thus will be compiled out). It came up in cases like "if (sizeof(some_var_type) == 4)". In my opinion, sizeof should be able to be used in #if statements since it's known at compile time, but since it can't be, I have to use it in if() statements that the compiler will optimize out.

 

As for the MSVC warnings that weren't pragma'ed out, I fixed them. This included the formatting of a #if conditional and one use of an uninitialized variable (I was rather upset that g++ didn't catch that!). But, for example, if I state "float f = 1.0;" I mean "set the floating point value of "1.0" in the variable f", not "take 1.0, convert it to a double, then downcast that double to a float and warn me about it". Those sorts of warnings I just pragma'ed out. They're useless. I'd rather be warned about "you put two spaces after your equals sign instead of one" than things like that. :P

 

Yes, I would like to see MSVC compiled with Werror as well.

 

I'll take a look at your new log and fix those as well. Thanks!

 

Ed: I'm having trouble with that rapidshare thing, and it's an annoying interface anyways. Since there's only a few warnings left, could you just post them here?

Edited by KarenRei

Share this post


Link to post
Share on other sites

Ok,

 

Here are the last warnings:

 

e:\cpp\elc\eye_candy\math_cache.h(104) : warning C4201: nonstandard extension used : nameless struct/union
e:\cpp\elc\eye_candy\math_cache.h(221) : warning C4127: conditional expression is constant
e:\cpp\elc\eye_candy\math_cache.h(234) : warning C4127: conditional expression is constant
e:\cpp\elc\eye_candy\math_cache.h(247) : warning C4127: conditional expression is constant
e:\cpp\elc\eye_candy\math_cache.h(260) : warning C4127: conditional expression is constant
e:\cpp\elc\eye_candy\math_cache.h(273) : warning C4127: conditional expression is constant
e:\cpp\elc\eye_candy\math_cache.h(286) : warning C4127: conditional expression is constant
e:\cpp\elc\eye_candy\math_cache.h(299) : warning C4127: conditional expression is constante:\cpp\elc\eye_candy_wrapper.cpp(922) : warning C4800: 'int' : forcing value to bool 'true' or 'false' (performance warning)

 

PS.

 

As I remember 1.0 is not converted to double - it is double. If you want a float, you put a literal of 1.0f.

Share this post


Link to post
Share on other sites

I meant to imply that 1.0, the number, is not double. Or float, or anything -- it's a number, base-10. Besides, these conversions are irrelevant. I could type:

 

float f = (float)(double)(float)(double)(float)(double)(float)(double)1.76829;

 

or

 

float f = 1.76829f;

 

They'd assign the same value to f. Double is just float with more decimal precision bits and more bits for the exponent.

 

From a more general standpoint, you'll notice that I use a lot of "types" in here -- coord_t, color_t, etc. There's no guarantee that these are floats (although they currently are). Someone could, some day, decide that they want more precision and change the types to doubles. Declaring the constants as float actually *would* cause precision problems in such a case.

 

Warnings: I've made those fixes, and hopefully this will be the end of them. :) Silly me -- I forgot that math cache doesn't include eye_candy.h, so it didn't get the pragma to ignore the constant expression comparisons. The code has been modified to fix the union and bool warnings. I'll test it and check it in this evening.

Edited by KarenRei

Share this post


Link to post
Share on other sites
I meant to imply that 1.0, the number, is not double. Or float, or anything -- it's a number, base-10. Besides, these conversions are irrelevant. I could type:

 

float f = (float)(double)(float)(double)(float)(double)(float)(double)1.76829;

 

or

 

float f = 1.76829f;

 

 

You don't have to explain this to me. I perfectly understand what your are saying... Just please explain this to my compiler :P for it, there is no such thing as a number.. there is only a type :P

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.

×