KarenRei Report post Posted April 1, 2007 Larry: I can't see where most of that is, but what I can see isn't in eye candy. Share this post Link to post Share on other sites
Learner Report post Posted April 1, 2007 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
KarenRei Report post Posted April 1, 2007 (edited) 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 April 1, 2007 by KarenRei Share this post Link to post Share on other sites
larrystorch Report post Posted April 1, 2007 If my problems aren't eye candy problems but a differnet problem, please move to another thread so it doesn't get lost. Thanks Share this post Link to post Share on other sites
KarenRei Report post Posted April 1, 2007 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
Ermabwed Report post Posted April 1, 2007 (edited) 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 (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 ) Edited April 1, 2007 by Ermabwed Share this post Link to post Share on other sites
KarenRei Report post Posted April 1, 2007 None of that is eye candy code. Could be a mem leak, as previously mentioned. Try building without the option EYE_CANDY. Share this post Link to post Share on other sites
Ermabwed Report post Posted April 1, 2007 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
KarenRei Report post Posted April 1, 2007 Yes -- that would be advisable. If it happens without EYE_CANDY enabled, then it's not related to EYE_CANDY's code. Share this post Link to post Share on other sites
Lachesis Report post Posted April 1, 2007 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 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
KarenRei Report post Posted April 1, 2007 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
KarenRei Report post Posted April 2, 2007 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. Share this post Link to post Share on other sites
Ermabwed Report post Posted April 2, 2007 (edited) 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 Edited April 2, 2007 by Ermabwed Share this post Link to post Share on other sites
KarenRei Report post Posted April 2, 2007 Got it. I'll tackle it this evening. Share this post Link to post Share on other sites
Kindar_Naar Report post Posted April 2, 2007 I posted my log here Have fun Share this post Link to post Share on other sites
KarenRei Report post Posted April 2, 2007 Kindar: Got it. I'll take care of that tonight as well. Share this post Link to post Share on other sites
Lachesis Report post Posted April 3, 2007 Hi Karen, the patch already is closed (status:accepted) 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
KarenRei Report post Posted April 3, 2007 (edited) 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 April 3, 2007 by KarenRei Share this post Link to post Share on other sites
KarenRei Report post Posted April 3, 2007 Kindar Naar: MSVC warning fixes in place. Let me know if I missed any. Share this post Link to post Share on other sites
Kindar_Naar Report post Posted April 3, 2007 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
KarenRei Report post Posted April 3, 2007 (edited) 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. 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 April 3, 2007 by KarenRei Share this post Link to post Share on other sites
Kindar_Naar Report post Posted April 3, 2007 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
KarenRei Report post Posted April 3, 2007 (edited) 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 April 3, 2007 by KarenRei Share this post Link to post Share on other sites
Kindar_Naar Report post Posted April 3, 2007 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 for it, there is no such thing as a number.. there is only a type Share this post Link to post Share on other sites
KarenRei Report post Posted April 3, 2007 Heh, sorry. I keep inviting your compiler to debate the issue, but it won't even take my calls. Can you imagine? The nerve! Share this post Link to post Share on other sites