Ermabwed Report post Posted April 20, 2007 FPS: I've offered several times to help anyone who has FPS problems; nobody's taken me up on it in a long time . However, it sounds like almost all eye candy is really slowing you down, which sounds like your video card is at fault here (I can't do anything if your video card can't draw translucent polys at an acceptable rate). Still, I'll verify that eye candy is lowering its level of detail as much as it can. In eye_candy.cpp, around like 1632, you'll see a debugging statement. Uncomment it. Wait, are you a windows user? If you are, you won't be able to see stdout. Let me know if you are, and we can write that debugging output in a different way. Also, try toggling point sprites; your video card may be lousy at drawing one type but have acceptable performance with the other. Well, it used to be fine or at least not so extreme (when I reported the huge fires due to point particles, I had no performance problem)... I'll try that line 1632/point sprites thing and let you know, I'm a follower of the penguin, so stdout works for me Mana drain segfault: Interesting; first report of this. Will you be on this evening? I'd be glad to help debug it. Note that I can't cast spells, so I'll need you to cast them. Well, I segfault when I am mana drained but I'm sure I can get a friend or guildie to help And define 'this evening', I'm UTC+1 (or maybe +2 with DST now) but I can stay up late or get up early to meet you, it's the weekend after all \o/ Share this post Link to post Share on other sites
KarenRei Report post Posted April 20, 2007 Okay, here's when I'll be available: Friday: ~7:30 PM CST to ~1:30 AM CST Saturday: ~5:00 PM CST to ~1:30 AM CST Sunday: ~12:00 PM CST to ~1:30 AM CST Obviously, I won't be *on* during all of that time, but those are the times that I *could* be on My test char's username is hyekyet. Share this post Link to post Share on other sites
Ermabwed Report post Posted April 20, 2007 Okay, here's when I'll be available: Friday: ~7:30 PM CST to ~1:30 AM CST Saturday: ~5:00 PM CST to ~1:30 AM CST Sunday: ~12:00 PM CST to ~1:30 AM CST Obviously, I won't be *on* during all of that time, but those are the times that I *could* be on My test char's username is hyekyet. Ok, did the debugging run, I can send you the output if you want me to. And I'll get up early and should be able to catch you at your late evening then Oh and by the way, turning point particles off didn't change the fps drop at all for me (or did you mean something else? ) PS: I just was crashed by a remote heal ... actually survived first spell but crashed on second, thanks to ladynienna for pointing that out Is it possible that something else is causing this? I'll re-emerge the game and copy the eye_candy textures to the appropriate game directory again just to make sure that that's not the problem. PPS: Testchar... you want to meet on testserver? Share this post Link to post Share on other sites
ttlanhil Report post Posted April 20, 2007 I was seeing occasionally FPS drops with EC on, just realised I had the debugging stuff... is this what you were waiting for? glBegin(GL_TRIANGLES) V1: F=0: N=<0, 0, -0.999881>; V=<0, 5.1282, -0.368143> V2: F=15: N=<0.207887, 0, -0.978031>; V=<0.0765413, -5.1282, -0.360099> V3: F=16: N=<-0.207887, 0, -0.978031>; V=<-0.0765413, -5.1282, -0.360099> V1: F=16: N=<-0.207887, 0, -0.978031>; V=<-0.0765413, -5.1282, -0.360099> V2: F=1: N=<-0.406688, 0, -0.913437>; V=<-0.149737, 5.1282, -0.336316> V3: F=0: N=<0, 0, -0.999881>; V=<0, 5.1282, -0.368143> V1: F=1: N=<-0.406688, 0, -0.913437>; V=<-0.149737, 5.1282, -0.336316> V2: F=16: N=<-0.207887, 0, -0.978031>; V=<-0.0765413, -5.1282, -0.360099> V3: F=17: N=<-0.587715, 0, -0.808921>; V=<-0.216389, -5.1282, -0.297834> V1: F=17: N=<-0.587715, 0, -0.808921>; V=<-0.216389, -5.1282, -0.297834> V2: F=2: N=<-0.743056, 0, -0.669051>; V=<-0.273584, 5.1282, -0.246336> V3: F=1: N=<-0.406688, 0, -0.913437>; V=<-0.149737, 5.1282, -0.336316> V1: F=2: N=<-0.743056, 0, -0.669051>; V=<-0.273584, 5.1282, -0.246336> V2: F=17: N=<-0.587715, 0, -0.808921>; V=<-0.216389, -5.1282, -0.297834> V3: F=18: N=<-0.865922, 0, -0.49994>; V=<-0.318822, -5.1282, -0.184072> V1: F=18: N=<-0.865922, 0, -0.49994>; V=<-0.318822, -5.1282, -0.184072> V2: F=3: N=<-0.950943, 0, -0.30898>; V=<-0.350125, 5.1282, -0.113763> V3: F=2: N=<-0.743056, 0, -0.669051>; V=<-0.273584, 5.1282, -0.246336> V1: F=3: N=<-0.950943, 0, -0.30898>; V=<-0.350125, 5.1282, -0.113763> V2: F=18: N=<-0.865922, 0, -0.49994>; V=<-0.318822, -5.1282, -0.184072> V3: F=19: N=<-0.994404, 0, -0.104516>; V=<-0.366127, -5.1282, -0.0384815> V1: F=19: N=<-0.994404, 0, -0.104516>; V=<-0.366127, -5.1282, -0.0384815> V2: F=4: N=<-0.994404, 0, 0.104516>; V=<-0.366127, 5.1282, 0.0384815> V3: F=3: N=<-0.950943, 0, -0.30898>; V=<-0.350125, 5.1282, -0.113763> V1: F=4: N=<-0.994404, 0, 0.104516>; V=<-0.366127, 5.1282, 0.0384815> V2: F=19: N=<-0.994404, 0, -0.104516>; V=<-0.366127, -5.1282, -0.0384815> V3: F=20: N=<-0.950943, 0, 0.30898>; V=<-0.350125, -5.1282, 0.113763> V1: F=20: N=<-0.950943, 0, 0.30898>; V=<-0.350125, -5.1282, 0.113763> V2: F=5: N=<-0.865922, 0, 0.499941>; V=<-0.318822, 5.1282, 0.184072> V3: F=4: N=<-0.994404, 0, 0.104516>; V=<-0.366127, 5.1282, 0.0384815> V1: F=5: N=<-0.865922, 0, 0.499941>; V=<-0.318822, 5.1282, 0.184072> V2: F=20: N=<-0.950943, 0, 0.30898>; V=<-0.350125, -5.1282, 0.113763> V3: F=21: N=<-0.743056, 0, 0.669051>; V=<-0.273584, -5.1282, 0.246336> V1: F=21: N=<-0.743056, 0, 0.669051>; V=<-0.273584, -5.1282, 0.246336> V2: F=6: N=<-0.587715, 0, 0.808921>; V=<-0.216389, 5.1282, 0.297834> V3: F=5: N=<-0.865922, 0, 0.499941>; V=<-0.318822, 5.1282, 0.184072> V1: F=6: N=<-0.587715, 0, 0.808921>; V=<-0.216389, 5.1282, 0.297834> V2: F=21: N=<-0.743056, 0, 0.669051>; V=<-0.273584, -5.1282, 0.246336> V3: F=22: N=<-0.406688, 0, 0.913437>; V=<-0.149737, -5.1282, 0.336316> V1: F=22: N=<-0.406688, 0, 0.913437>; V=<-0.149737, -5.1282, 0.336316> V2: F=7: N=<-0.207887, 0, 0.978031>; V=<-0.0765413, 5.1282, 0.360099> V3: F=6: N=<-0.587715, 0, 0.808921>; V=<-0.216389, 5.1282, 0.297834> V1: F=7: N=<-0.207887, 0, 0.978031>; V=<-0.0765413, 5.1282, 0.360099> V2: F=22: N=<-0.406688, 0, 0.913437>; V=<-0.149737, -5.1282, 0.336316> V3: F=23: N=<8.74124e-08, -0, 0.999881>; V=<3.21841e-08, -5.1282, 0.368143> V1: F=23: N=<8.74124e-08, -0, 0.999881>; V=<3.21841e-08, -5.1282, 0.368143> V2: F=8: N=<0.207887, -0, 0.978031>; V=<0.0765414, 5.1282, 0.360099> V3: F=7: N=<-0.207887, 0, 0.978031>; V=<-0.0765413, 5.1282, 0.360099> V1: F=8: N=<0.207887, -0, 0.978031>; V=<0.0765414, 5.1282, 0.360099> V2: F=23: N=<8.74124e-08, -0, 0.999881>; V=<3.21841e-08, -5.1282, 0.368143> V3: F=24: N=<0.406688, -0, 0.913437>; V=<0.149737, -5.1282, 0.336316> V1: F=24: N=<0.406688, -0, 0.913437>; V=<0.149737, -5.1282, 0.336316> V2: F=9: N=<0.587715, -0, 0.808921>; V=<0.216389, 5.1282, 0.297834> V3: F=8: N=<0.207887, -0, 0.978031>; V=<0.0765414, 5.1282, 0.360099> V1: F=9: N=<0.587715, -0, 0.808921>; V=<0.216389, 5.1282, 0.297834> V2: F=24: N=<0.406688, -0, 0.913437>; V=<0.149737, -5.1282, 0.336316> V3: F=25: N=<0.743056, -0, 0.669051>; V=<0.273584, -5.1282, 0.246336> V1: F=25: N=<0.743056, -0, 0.669051>; V=<0.273584, -5.1282, 0.246336> V2: F=10: N=<0.865922, -0, 0.49994>; V=<0.318822, 5.1282, 0.184072> V3: F=9: N=<0.587715, -0, 0.808921>; V=<0.216389, 5.1282, 0.297834> V1: F=10: N=<0.865922, -0, 0.49994>; V=<0.318822, 5.1282, 0.184072> V2: F=25: N=<0.743056, -0, 0.669051>; V=<0.273584, -5.1282, 0.246336> V3: F=26: N=<0.950943, -0, 0.30898>; V=<0.350125, -5.1282, 0.113763> V1: F=26: N=<0.950943, -0, 0.30898>; V=<0.350125, -5.1282, 0.113763> V2: F=11: N=<0.994404, -0, 0.104516>; V=<0.366127, 5.1282, 0.0384814> V3: F=10: N=<0.865922, -0, 0.49994>; V=<0.318822, 5.1282, 0.184072> V1: F=11: N=<0.994404, -0, 0.104516>; V=<0.366127, 5.1282, 0.0384814> V2: F=26: N=<0.950943, -0, 0.30898>; V=<0.350125, -5.1282, 0.113763> V3: F=27: N=<0.994404, 0, -0.104516>; V=<0.366127, -5.1282, -0.0384816> V1: F=27: N=<0.994404, 0, -0.104516>; V=<0.366127, -5.1282, -0.0384816> V2: F=12: N=<0.950943, 0, -0.30898>; V=<0.350125, 5.1282, -0.113763> V3: F=11: N=<0.994404, -0, 0.104516>; V=<0.366127, 5.1282, 0.0384814> V1: F=12: N=<0.950943, 0, -0.30898>; V=<0.350125, 5.1282, -0.113763> V2: F=27: N=<0.994404, 0, -0.104516>; V=<0.366127, -5.1282, -0.0384816> V3: F=28: N=<0.865922, 0, -0.49994>; V=<0.318822, -5.1282, -0.184072> V1: F=28: N=<0.865922, 0, -0.49994>; V=<0.318822, -5.1282, -0.184072> V2: F=13: N=<0.743056, 0, -0.669051>; V=<0.273584, 5.1282, -0.246336> V3: F=12: N=<0.950943, 0, -0.30898>; V=<0.350125, 5.1282, -0.113763> V1: F=13: N=<0.743056, 0, -0.669051>; V=<0.273584, 5.1282, -0.246336> V2: F=28: N=<0.865922, 0, -0.49994>; V=<0.318822, -5.1282, -0.184072> V3: F=29: N=<0.587715, 0, -0.808921>; V=<0.216389, -5.1282, -0.297834> V1: F=29: N=<0.587715, 0, -0.808921>; V=<0.216389, -5.1282, -0.297834> V2: F=14: N=<0.406688, 0, -0.913437>; V=<0.149737, 5.1282, -0.336316> V3: F=13: N=<0.743056, 0, -0.669051>; V=<0.273584, 5.1282, -0.246336> V1: F=14: N=<0.406688, 0, -0.913437>; V=<0.149737, 5.1282, -0.336316> V2: F=29: N=<0.587715, 0, -0.808921>; V=<0.216389, -5.1282, -0.297834> V3: F=15: N=<0.207887, 0, -0.978031>; V=<0.0765413, -5.1282, -0.360099> V1: F=15: N=<0.207887, 0, -0.978031>; V=<0.0765413, -5.1282, -0.360099> V2: F=0: N=<0, 0, -0.999881>; V=<0, 5.1282, -0.368143> V3: F=14: N=<0.406688, 0, -0.913437>; V=<0.149737, 5.1282, -0.336316> glEnd() I have a couple of cycles of that in a row in stdout atm... this one is from just before I entered crystal caves from the south Share this post Link to post Share on other sites
KarenRei Report post Posted April 20, 2007 (edited) Yes, ttlanhil, that's what I was wanting. Also, I wanted to know whether, when you view people teleporting at the IP docks, whether the chain of polygons that stretches inland is still white, like it used to be, or only effects saturation, like the teleportation columns do. Ermabwed: Normal server is fine. Probably better, since it's busier. Of course, if you'd rather meet on the test server, that's fine too. Edited April 20, 2007 by KarenRei Share this post Link to post Share on other sites
bluap Report post Posted April 20, 2007 (edited) FPS: I've offered several times to help anyone who has FPS problems; nobody's taken me up on it in a long time . However, it sounds like almost all eye candy is really slowing you down, which sounds like your video card is at fault here.... I'm having problems with some effects causing major FPS loss. For example, the rather nice fountain effect is particularly bad for this. I just tried some testing using the fountain in TG [193,249]. With Eye Candy disabled from the config GUI and my FPS unlimited I get ~45 FPS. Enabling eye candy, FPS drops to ~25. I normally limit FPS to 35. Other effects don't seam that bad though, lately, the remote heal does appear to cause a FPS drop giving stilted animations. Let me know if you want further information or testing. I'm not sure what you mean by the "point sprites" toggle. I'm on Linux using a an Nvidia GeForce4 Ti 4200 graphics card. Edited April 20, 2007 by bluap Share this post Link to post Share on other sites
KarenRei Report post Posted April 20, 2007 (edited) Enable the same debugging statement I recommended for Ermabwed and give me the output when things are slowing down. Before I do anything else, I need to determine what LOD eye candy is using for you, and that's what that debugging statement will do. Also, it would be nice if you two could give me an idea whether the slowdown is from the video card or from CPU usage; printing get_time() at the start and end of EyeCandy::idle (or better yet, the difference between a get_time() run at the start and a get_time() run at the end) should reveal that unless your system has some drawing threads running in the background. Note that I'm not concerned at all with eye candy bringing people down to framerates in the 30s of FPS. If the tradeoff is between quality versus framerate, and the framerates are in the 30s or higher, I'd weigh in on the side of quality (wouldn't you?). Once it gets below 37 fps, it slowly starts cutting down the LOD down, lower and lower the lower the fps gets. It *should* be dragging it low enough that your framerate settles out at a reasonable balance between framerate and visual quality. Obviously, it's not doing that currently, so I need to figure out why. Is it going down to LOD 1, but even LOD 1 has too much of a visual demand? Is it not cutting down the LOD properly? If the former case, is the bottleneck on the CPU or the video card? These are the things that I need to know. Edited April 20, 2007 by KarenRei Share this post Link to post Share on other sites
KarenRei Report post Posted April 20, 2007 Jowwow: When did your friend compile that for you, out of curiosity? I need to know how old that code is. Share this post Link to post Share on other sites
Ermabwed Report post Posted April 20, 2007 Enable the same debugging statement I recommended for Ermabwed and give me the output when things are slowing down. Before I do anything else, I need to determine what LOD eye candy is using for you, and that's what that debugging statement will do. Also, it would be nice if you two could give me an idea whether the slowdown is from the video card or from CPU usage; printing get_time() at the start and end of EyeCandy::idle (or better yet, the difference between a get_time() run at the start and a get_time() run at the end) should reveal that unless your system has some drawing threads running in the background. Ok, I sent you my log. If you tell me how to do the above, I'll do it And normal server will work fine Share this post Link to post Share on other sites
Cycloonx Report post Posted April 20, 2007 I had another 'bug' a little ago in PL storage, didn't see anything odd on the screen, but in the dos window there were spamming a lot of messages: (This message kept repeating like 10times/s until I left the storage) Share this post Link to post Share on other sites
bluap Report post Posted April 20, 2007 (edited) Enable the same debugging statement I recommended for Ermabwed and give me the output when things are slowing down. Before I do anything else, I need to determine what LOD eye candy is using for you, and that's what that debugging statement will do. ... I've sent you a PM with the URL of the log file. Edit: forgot to mention I put extra debug in to show when the use_eye_candy options was being toggled. Edited April 20, 2007 by bluap Share this post Link to post Share on other sites
Learner Report post Posted April 20, 2007 Enable the same debugging statement I recommended for Ermabwed and give me the output when things are slowing down. Before I do anything else, I need to determine what LOD eye candy is using for you, and that's what that debugging statement will do. Also, it would be nice if you two could give me an idea whether the slowdown is from the video card or from CPU usage; printing get_time() at the start and end of EyeCandy::idle (or better yet, the difference between a get_time() run at the start and a get_time() run at the end) should reveal that unless your system has some drawing threads running in the background. Note that I'm not concerned at all with eye candy bringing people down to framerates in the 30s of FPS. If the tradeoff is between quality versus framerate, and the framerates are in the 30s or higher, I'd weigh in on the side of quality (wouldn't you?). Once it gets below 37 fps, it slowly starts cutting down the LOD down, lower and lower the lower the fps gets. It *should* be dragging it low enough that your framerate settles out at a reasonable balance between framerate and visual quality. Obviously, it's not doing that currently, so I need to figure out why. Is it going down to LOD 1, but even LOD 1 has too much of a visual demand? Is it not cutting down the LOD properly? If the former case, is the bottleneck on the CPU or the video card? These are the things that I need to know. Not everyone wants high quality ... thats why early on I had suggested allowing the players to control the LOD! There are many different types of players in game and you cant assume what they want, myself I would normally have it totally off! Share this post Link to post Share on other sites
KarenRei Report post Posted April 20, 2007 Learner: And if you want to code that feature, you're more than welcome to. The relevant code is ec_set_draw_detail. It's only one line apart from the if/else on poor_man. Share this post Link to post Share on other sites
KarenRei Report post Posted April 21, 2007 (edited) Cycloonx: You have -DDEBUG_POINT_PARTICLES on. Slowdown: Ah, found it. It was introduced when I added a fix so that people who limit their framerate low would still get full detail unless it was actually slowing them down below what they limited to. Unfortunately, I can't check the fix in. Berlios seems to be down. Ttlanhil, you're up next. Edited April 21, 2007 by KarenRei Share this post Link to post Share on other sites
Ermabwed Report post Posted April 21, 2007 backtrace of Mana drain crash in Thelinor tavern, thanks to shamara for crashing me 0x00000000004eda19 in ec::MathCache::powf_0_1_rough_close (this=0x815de0, base=nan(0x400000), power=0.400000006) 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) backtrace #0 0x00000000004eda19 in ec::MathCache::powf_0_1_rough_close (this=0x815de0, base=nan(0x400000), power=0.400000006) at eye_candy/math_cache.cpp:2179 #1 0x00000000004d1e66 in ec::Particle::flare (this=0x78bbb50) at eye_candy/eye_candy.cpp:727 #2 0x00000000004d2008 in ec::Particle::draw (this=0x78bbb50, usec=93874) at eye_candy/eye_candy.cpp:634 #3 0x000000000051fa35 in ec::TargetMagicParticle::draw (this=0x78bbb50, usec=93874) at eye_candy/effect_targetmagic.cpp:290 #4 0x00000000004d0a5f in ec::EyeCandy::draw (this=0x8156a0) at eye_candy/eye_candy.cpp:1477 #5 0x00000000004bfdcd in ec_draw () at eye_candy_wrapper.cpp:302 #6 0x0000000000448c79 in display_game_handler (win=0x3b370f0) at gamewin.c:696 #7 0x000000000043c715 in draw_window (win=0x3b370f0) at elwindows.c:1059 #8 0x000000000043cd42 in display_window (win_id=0) at elwindows.c:1207 #9 0x000000000043a05e in display_windows (level=1) at elwindows.c:57 #10 0x0000000000433ca3 in draw_scene () at draw_scene.c:98 #11 0x0000000000460f5d in start_rendering () at main.c:123 #12 0x000000000046123b in main (argc=1, argv=0x7fff03a1e838) at main.c:235 Share this post Link to post Share on other sites
KarenRei Report post Posted April 21, 2007 * Fixed ermabwed's mana crash, with help from ermabwed and mschoolbus. Thanks, you two! The problem was with the requested "effect follows the caster and target". We weren't initializing one element that was being used for that. Also fixed a slight off-center for login/logout beam effects. As with before, I still can't commit Darned berlios... [meme@spathi elc]$ cvs update -d ssh_exchange_identification: Connection closed by remote host cvs [update aborted]: end of file from server (consult above messages if any) Ttlanhil, an updated version for your debugging (hopefully the last one?) isn't ready yet, but not like I'd be able to commit it anyways. I'll write it tomorrow. Share this post Link to post Share on other sites
ttlanhil Report post Posted April 21, 2007 Yes, ttlanhil, that's what I was wanting. Also, I wanted to know whether, when you view people teleporting at the IP docks, whether the chain of polygons that stretches inland is still white, like it used to be, or only effects saturation, like the teleportation columns do.as far as I can tell (with CVS from yesterday), they're still only a translucent white Share this post Link to post Share on other sites
0ctane Report post Posted April 21, 2007 Shadows: Anyone want to take a look at them? Is this a major issue or a rare minor one? Is there a reliable way to reproduce the problem? I'd like to see shadows overhaulled next release, so I'm not sure how much time I want to put into the current version. Well, I don't have time to figure out when the shadow code got foobarred. We have already discussed where the offending code is located. Someone with good OpenGL debugging experience needs to figure out what the problem is. As far as I am concerned, it is a major problem. This problem occurs at least in OS X and Linux...I am not sure about windows. A number of people have reported the segfault. Keep shadows activated, log in while outside during the day, and I think you need other actors present to have the crash. Crash does not occur if shadows are turned off, or if you login to a interior/cave location. There probably will not be a next release until this issue is fixed. Who doesn't want to use shadows? Do we really want a thosusand players spamming the forums with uninformative "I cannot connect" messages? Share this post Link to post Share on other sites
KarenRei Report post Posted April 21, 2007 (edited) What segfault? The shadow problem that was reported was shadows disappearing if viewed from very specific angles. Are you referring to the ancient shadow mapping segfault that was fixed weeks ago? Also -- anyone know what's up with Berlios? If it stays down, this is going to be a big problem Edited April 21, 2007 by KarenRei Share this post Link to post Share on other sites
freeone3000 Report post Posted April 21, 2007 (gdb) start Breakpoint 1 at 0x80a2077: file main.c, line 224. Starting program: /home/james/develop/elc/el.x86.linux.bin Failed to read a valid object file image from memory. [Thread debugging using libthread_db enabled] [New Thread -1229179168 (LWP 23308)] [Switching to Thread -1229179168 (LWP 23308)] main (argc=1, argv=0xbfb37a64) at main.c:224 224 gargc=argc; (gdb) continue Continuing. [New Thread -1240564816 (LWP 23311)] [New Thread -1248953424 (LWP 23312)] FountainEffect (0xedaead0) created. FountainEffect (0xeeccf50) created. FountainEffect (0xeecd018) created. SmokeEffect (0xeecd0e0) created (<281.667, 4, -56.6054>, 1.1) SmokeEffect (0xeecd198) created (<286.088, 4, -60.8911>, 1.1) SmokeEffect (0xeecd250) created (<281.038, 4, -59.9611>, 1.1) SmokeEffect (0xeecd308) created (<280.948, 4, -57.8254>, 1.1) SmokeEffect (0xeecd3c0) created (<284.189, 4, -55.5448>, 1.1) SmokeEffect (0xeecd4c0) created (<286.417, 4, -55.5801>, 1.1) SmokeEffect (0xeecd5c0) created (<285.876, 3, -71.0941>, 1.1) SmokeEffect (0xeecd678) created (<298.609, 3.3, -82.853>, 1.1) SmokeEffect (0xeecd730) created (<297.85, 6, -78.3161>, 1.1) SmokeEffect (0xef39888) created (<81.5747, 6.4, -68.7668>, 0.3) SmokeEffect (0xef39940) created (<88.4753, 3.8, -82.8559>, 0.3) SmokeEffect (0xef399f8) created (<84.105, 3.8, -90.5792>, 0.3) SmokeEffect (0xef39ab0) created (<92.974, 4.2, -90.8935>, 0.3) LampEffect (0xef39bf0) created. LampEffect (0xef39f60) created. LampEffect (0xef3a2e0) created. TeleporterEffect (0xb52d988) created. TeleporterEffect (0xef3f768) created. TeleporterEffect (0xef477e8) created. TeleporterEffect (0xef50258) created. Program received signal SIGSEGV, Segmentation fault. 0xb7fb7110 in ?? () (gdb) bt full #0 0xb7fb7110 in ?? () No symbol table info available. #1 0x00000000 in ?? () No symbol table info available. Error log, segfaults on startup. Today's CVS. Anything else you need? Share this post Link to post Share on other sites
Sayre Report post Posted April 21, 2007 (edited) Are you referring to the ancient shadow mapping segfault that was fixed weeks ago? Same one I am afraid. Aislinn was using a recent build when she got the segfault while outdoors. She would crash immediately on reconnection. I asked her to turn off shadows in el.ini before trying to log in again, and then she was able to reconnect without crashing. This is pretty much the same sort of thing that was happening when mine was crashing due to shadow borkification. S. Edit: PS she is using windows Edited April 21, 2007 by Spleenfeeder Share this post Link to post Share on other sites
Aislinn Report post Posted April 21, 2007 As far as I am concerned, it is a major problem. This problem occurs at least in OS X and Linux...I am not sure about windows. A number of people have reported the segfault. Keep shadows activated, log in while outside during the day, and I think you need other actors present to have the crash. Crash does not occur if shadows are turned off, or if you login to a interior/cave location. I use windows and reported this yesterday in this thread, with a cvs from 2 days ago. I was outside in Egratia, daytime, I walked under an open stone archway and crashed. There definitely was at least one cyclops there, but I don't think another player, altlhough I can't swear to that. Share this post Link to post Share on other sites
KarenRei Report post Posted April 22, 2007 (edited) blah. So much to do on my schedule, but if I'm the only one who's going to fix EL crashes, so be it. Still, I don't want to do this when I can't even commit my previous changes, let alone see what changes others have made. Anyone know whats up with Berlios? Anyone? Edited April 22, 2007 by KarenRei Share this post Link to post Share on other sites
Entropy Report post Posted April 22, 2007 Berlios works in misteryous ways... you can never tell when the problems are fixed, but usually it's just 1-2 days. Share this post Link to post Share on other sites
KarenRei Report post Posted April 22, 2007 (edited) Okay. I can't verify this issue (because it doesn't crash for me), and I can't verify my theory that whoever is working on NEW_E3D broke shadows again, in the exact same way that they were broken before (because Berlios is down, so I can't check revisions). However, I see this code, part of my fix from last time, modified: #ifdef NEW_E3D_FORMAT // Always supplies a texture pointer glEnableClientState(GL_COLOR_ARRAY); glEnable(GL_TEXTURE_2D); #else // Doesn't always. glDisableClientState(GL_COLOR_ARRAY); glDisable(GL_TEXTURE_2D); #endif They're turning on GL_COLOR_ARRAY. Yet, I don't see any call to glColorPointer anywhere in the code. In fact, in all of EternalLands, there's only one call to glColorPointer, and that's inside an #if 0 in particles.c. Even if this is not the problem, please people, let me once again remind people to be very, very careful with your client states. It's much better to do too many state changes (there's a real, but mostly trivial, performance cost) than to risk having the wrong state. The crashes resulting from having the wrong state are obscure and hard to track down. Anyways, to people with shadow crashes: Do you have NEW_E3D_FORMAT enabled? If so, disable it. If this fixes your crashes, let us know. Whoever added this code, I'd recommend that they check it out. If you *don't* have NEW_E3D_FORMAT enabled, I'll take another look and see if I can figure it out. Edited April 22, 2007 by KarenRei Share this post Link to post Share on other sites