Jump to content
Eternal Lands Official Forums
Entropy

Special effects

Recommended Posts

FPS: I've offered several times to help anyone who has FPS problems; nobody's taken me up on it in a long time :D. 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 :D

 

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

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 :D My test char's username is hyekyet.

Share this post


Link to post
Share on other sites

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? :D)

 

PS: I just was crashed by a remote heal ... actually survived first spell but crashed on second, thanks to ladynienna for pointing that out :D 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

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

Yes, ttlanhil, that's what I was wanting. :D 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 by KarenRei

Share this post


Link to post
Share on other sites

FPS: I've offered several times to help anyone who has FPS problems; nobody's taken me up on it in a long time :D. 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 by bluap

Share this post


Link to post
Share on other sites

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 by KarenRei

Share this post


Link to post
Share on other sites

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

And normal server will work fine :D

Share this post


Link to post
Share on other sites

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:

 

bugym1.jpg

 

(This message kept repeating like 10times/s until I left the storage)

Share this post


Link to post
Share on other sites

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 by bluap

Share this post


Link to post
Share on other sites

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

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

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 by KarenRei

Share this post


Link to post
Share on other sites

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

* 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 :o 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
Yes, ttlanhil, that's what I was wanting. :o 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
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

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 by KarenRei

Share this post


Link to post
Share on other sites

(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

 

 

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 by Spleenfeeder

Share this post


Link to post
Share on other sites

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

blah. :P

 

So much to do on my schedule, but if I'm the only one who's going to fix EL crashes, so be it. :P 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 by KarenRei

Share this post


Link to post
Share on other sites

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

×