RC 2

[Entropy]

Oh, ok, I didn't know it was that severe...

I guess someone should contact Apple about it, because this behaviour is their fault (even if the bug is in our code, it should not freeze the whole machine).

[CelticLady]

I just checked Idaloran 269, 149. When rotating to certain angles (one being similar to yours facing the whole water) I get a brighter screen with more light rather than darker. But this is at 3:37, so maybe it gets lighter on night and darker on day?

 

But I have had this effect on other places to where it can go from dark to light in an instant so are you sure this is coord dependant? Tried to find any other spot with similar effect?

 

 

 

As I said, "Now, with that said, it was night time when I had the issue of the screen mostly going black."

 

When I checked this with the previous RC I walked around Idaloran and large portions of it had this blackout effect depending on the direction you were facing. Near all the tele portals and some exits. It wasn't on just one specific coord, but huge areas that i could wander around in in the dark. I asked Sundulana to come to a spot I was sitting at to make sure it wasn't just my pc or w/e. She remarked that it was very dark before she even got to the location I asked her to come to. So it wasn't just a couple specific sets of coordinates, but large areas.

 

As for trying to find any other spots...As Icy stated, Iscalrith storage was black as well, basically all of it(I had seen and mentioned about that on my post for the previous RC as well). Sundulana had told me that the spot reported previously in VOTD sort of near Molgor was also black and that a portion of KF near the entrance to VOTD as well.

[Florian]

Can't test right now, night on game and test server ...

[ttlanhil]

There is an OpenGL debugger supplied by Apple, but I can't see the trace it collects, because all output is frozen. You see the problem there ...

indeed, but it may not be completely un-debuggable... if you can get a remote login, you can probably use gdb or similar to find out where the code is at (assuming elc is locked up, and it isn't continuing on while the screen is gone)... to attach gdb to a running process, it's 'gdb appname process-id' (get the preocess id using ps or similar, if that's what's on osx)

 

however... perhaps the ability to turn on these shadows should be disabled by -DOSX if it's that severe? (I wonder what the volumetric shadows karen was thinking about would end up doing. maybe they would be a happy replacement)

 

ed: oh, and those who want to test stuff, compile CVS themselves, and need it to be daytime to test it... contact me... I don't want to discuss this with everyone, though, so it'll depend on who you are, what you've done for ELC, and what you're fixing

Edited May 20, 2007 by ttlanhil

[Florian]

OK, I'm running el_osx now in a putty gdb session, works fine.

 

One of the debug flags makes the client clock tick way faster than usual, but I don't know which it is (that's also what I mean by documentation for the -D flags ...).

Edited May 20, 2007 by Florian

[CelticLady]

Just went back to test server and yup, I get a blackout in Idaloran when mapwalking from 193,72 all the way to 269, 148. Another screenie for your viewing pleasure.

RC 2 blackout Idaloran

 

I had tried previously to change some of my settings and nothing helped other than changing the direction my view was facing. I just now tried turning poor man off and turning back on some of the shadows etc. That didn't help either.

[Florian]

Well, the sun is up and here is your stack trace

#0  0x9000a457 in mach_msg_trap ()
#1  0x9000a3b8 in mach_msg ()
#2  0x90be5a09 in io_connect_method_structureI_structureO ()
#3  0x109c286f in gldInitDispatch ()
#4  0x108819b1 in glReadPixels_Exec ()
#5  0x92b1dc87 in glReadPixels ()
#6  0x0009aaaf in anything_under_the_mouse (object_id=259, object_type=3) at misc.c:136
#7  0x0000b93c in draw_3d_objects (object_type=11) at 3d_objects.c:654
#8  0x0000be95 in display_ground_objects () at 3d_objects.c:1203
#9  0x000c4a61 in draw_sun_shadowed_scene (any_reflection=2) at shadows.c:1118
#10 0x0006cdc0 in display_game_handler (win=0x5192400) at gamewin.c:653
#11 0x0005c89d in draw_window (win=0x5192400) at elwindows.c:1054
#12 0x0005cfc3 in display_windows (level=1) at elwindows.c:1202
#13 0x0004f7e1 in draw_scene () at draw_scene.c:98
#14 0x00091fbe in start_rendering () at main.c:127
#15 0x0009202e in SDL_main (argc=1, argv=0x5906e20) at main.c:239
...

 

OSX output is completely frozen, gdb still works from remote. There goes my uptime ...

[KarenRei]

Florian: Well, if you wanted, you could try making this whole section conditional on OSX. We could just assume that it fails the if statement on misc.c line 137 if you're in OSX, so it will run that code every time. To whit, try commenting out lines 135 to 137 and 139-141. If this prevents your crash and doesn't introduce new bugs, then I'll wrap that in an #ifdef for OSX and commit it.

 

Black screen: I'm going to go ahead and work on this, see if I can figure it out.

[ttlanhil]

-DDEBUG_TIME. I added it for precisely that reason -- so that you can debug things like shadows when gametime is night. I was actually rather surprised that the feature wasn't in there already when I wrote it.

there's a similar option, quite old AFAIK, to be able to adjust the time by 5 minutes forwards or backwards, on demand (although right now it seems to need a slight code edit, but that's easy to do)

 

 

as for the OSX stuff... I've googled a while and the only thing I can see is that maybe it doesn't like using RGB... if you are willing to go through the lockups, you could try changing to RGBA, which (if I didn't misread the code) would require no other changes... or BGR or BGRA (which would, but not much)

 

this for in the glreadpixels call in anything_under_the_mouse() misc.c:136

 

I don't really expect it to work... but... it might, and voodoo like this may just work around a bug in apple's libs (though contacting apple may be a better bet)

Edited May 20, 2007 by ttlanhil

[Florian]

To whit, try commenting out lines 135 to 137 and 139-141.

I suppose you mean lines 135,136,139,140,141?

[KarenRei]

Map note: I drop below the surface at Iscalrith 195,231. Also, 185,131.

 

 

Florian: You forgot 137. You need to comment out the if statement, too.

Edited May 20, 2007 by KarenRei

[Florian]

as for the OSX stuff... I've googled a while and the only thing I can see is that maybe it doesn't like using RGB... if you are willing to go through the lockups, you could try changing to RGBA, which (if I didn't misread the code) would require no other changes... or BGR or BGRA (which would, but not much)

 

changed line 136 RBG to RGBA

 

#0  0x9000a457 in mach_msg_trap ()
#1  0x9000a3b8 in mach_msg ()
#2  0x90be5a09 in io_connect_method_structureI_structureO ()
#3  0x109c286f in gldInitDispatch ()
#4  0x108819b1 in glReadPixels_Exec ()
#5  0x92b1dc87 in glReadPixels ()
#6  0x0009aaaf in anything_under_the_mouse (object_id=86, object_type=3) at misc.c:136
#7  0x0000b844 in draw_3d_objects (object_type=13) at 3d_objects.c:654
#8  0x0000c04c in display_objects () at 3d_objects.c:1163
#9  0x000c4a5c in draw_sun_shadowed_scene (any_reflection=2) at shadows.c:1117
#10 0x0006cdc0 in display_game_handler (win=0x5192400) at gamewin.c:653
#11 0x0005c89d in draw_window (win=0x5192400) at elwindows.c:1054
#12 0x0005cfc3 in display_windows (level=1) at elwindows.c:1202
#13 0x0004f7e1 in draw_scene () at draw_scene.c:98
#14 0x00091fbe in start_rendering () at main.c:127
#15 0x0009202e in SDL_main (argc=1, argv=0x5906e20) at main.c:239

 

Walking around in PV. Shadow maps there and moving. After ~15 secs screen turned darker (like everything was covered in shadow) and the mac froze.

Edited May 20, 2007 by Florian

[KarenRei]

Update: I can't reproduce the blackout problem. Can any of you with the blackout compile from CVS? I could probably come up with some debugging statements

[Florian]

To whit, try commenting out lines 135 to 137 and 139-141.

W/o lines 135,136,139,140,141 my mac freezes right when the first screen should be rendered. Login works, map loads, then freeze.

 

Different stack trace:

#0  0x9000a457 in mach_msg_trap ()
#1  0x9000a3b8 in mach_msg ()
#2  0x90be52db in io_connect_map_memory ()
#3  0x109b25f9 in gldDestroyVertexArray ()
#4  0x109c0145 in gldInitDispatch ()
#5  0x1093dc5d in gleBeginPrimitiveTCLFunc ()
#6  0x1085812f in gleDrawArraysOrElements_Core ()
#7  0x108dceef in gleDrawArraysOrElements_VBO_Exec ()
#8  0x92b20468 in glDrawElements ()
#9  0x00038a2b in cal_render_actor (act=0x150cd000) at cal.c:199
#10 0x000a0d0f in draw_enhanced_actor (actor_id=0x150cd000, banner=1) at new_actors.c:169
#11 0x0001a38d in display_actors (banner=1, reflections=0) at actors.c:641
#12 0x000c4539 in draw_sun_shadowed_scene (any_reflection=2) at shadows.c:1120
#13 0x0006cdc0 in display_game_handler (win=0x5191a00) at gamewin.c:653
#14 0x0005c89d in draw_window (win=0x5191a00) at elwindows.c:1054
#15 0x0005cfc3 in display_windows (level=1) at elwindows.c:1202
#16 0x0004f7e1 in draw_scene () at draw_scene.c:98
#17 0x00091b6e in start_rendering () at main.c:127
#18 0x00091bde in SDL_main (argc=1, argv=0x5906e20) at main.c:239

[KarenRei]

I've said several times that you need to comment out line 137 as well.

 

Of course, those posts got censored.

[Florian]

I've said several times that you need to comment out line 137 as well.

 

135-137 & 139-141 out --> immediate crash, same as above

[KarenRei]

Looking at your stacktrace... when did you last CVS update? Does your shadows.c still have glEnableClientState(GL_COLOR_ARRAY)?

[Florian]

Looking at your stacktrace... when did you last CVS update? Does your shadows.c still have glEnableClientState(GL_COLOR_ARRAY)?

cvs up was 5 secs before make clean && make. Your changes to map_io.c and elconfig.c are in, as well as the shadow.c patch 6 hours ago.

[CelticLady]

Update: I can't reproduce the blackout problem. Can any of you with the blackout compile from CVS? I could probably come up with some debugging statements

 

No, I can't compile CVS. And just to make sure, you did check those areas in Idaloran when it was night, correct? Everything is normal during the day for me, it only does that during the night time, like 4-5 (possibly a bit before and after that as well)

[KarenRei]

Okay, back.

 

Can anyone with CVS access reproduce this problem? If not, I'd have to put in debugging statements either a custom release, and nobody wants to have to do that. Or, if there's some other (reproducible) ways to cause this problem to occur, let me know and I'll give them a shot.

 

Quick question for Ent/Roja: what compile options was this built with? NEW_WEATHER and NEW_ALPHA aren't included, correct? I've seen darkness bugs with NEW_WEATHER from time to time before, so I want to rule that one out.

Edited May 21, 2007 by KarenRei

[Roja]

These are all the compile options I'm using for the client:

 

-Wall -DELC -DNEW_FRUSTUM -DAUTO_UPDATE -DBUG_FIX_3D_OBJECTS_MIN_MAX -DCOUNTERS -DNEW_TEX -DNEW_ACTOR_ANIMATION -DOPTIONS_I18N -DALUT_WAV -DSFX -DUSE_ACTOR_DEFAULTS -DDYNAMIC_ANIMATIONS -DEYE_CANDY -DMASKING -DALPHA_ACTORS -DCUSTOM_UPDATE -DCUSTOM_LOOK -DIDLE_FIX -DNEW_E3D_FORMAT -DPNG_SCREENSHOT

 

 

alpha & weather are not included.

[Beaverhunter]

KarenRei:

Yup, I'm familiar with those darkness bugs from NEW_WEATHER=) But if it was the same case now I would have goten them too with RC client, and I'm not=) Must be something weird going on, custom releases sounds like a pain though=S

 

Roja:

I'm pretty sure that it was said that AUTO_UPDATE and CUSTOM_UPDATE was suppose to be excluded to prevent any updates that overwrite the new files and cause trouble while testing. (The tables disappearing might have been about that, also some ppl don't see the new creatures because they let auto update be on so they have to reinstall and make sure auto_update = 0)

Also ent mentioned that with the NEW_E3D_FORMAT, you don't need the BUG_FIX_3D_OBJECTS_MIN_MAX.

[Entropy]

The autoupdate options don't have to be undefined so long as you don't use your EL folder.

The el.ini has them disabled in the RC.

[KarenRei]

Let's see.

 

* Happens only at night

* Happens only in certain places

* Scene is being rendered, but not lit

* Shadow settings are irrelevant (not that they should be used at all at night)

* Setting is outside *or* inside (so it doesn't have to do with is_dungeon).

* We're not even getting ambient light; we're getting *no* light. Only effects (both old style and new style), emissive surfaces, dimmed reflections, and screen decorations draw.

 

Hmm. Actually, wait a minute. Has there been a new release since my crash fix went in? There hasn't, has there? That right there could be the cause of this. If you had shadows on back when it was daytime, that problematic glEnableClientState(GL_COLOR_ARRAY) call would have been made. render_rain will disable that state, but if it hadn't rained since then, it still would be enabled.

 

With the state GL_COLOR_ARRAY enabled, but no glColorPointer set, it may be trying to read color data from an arbitrary point in memory and getting all black. As for why it only happens in certain places and at certain angles -- buffer overflows can be unpredictable and all.

 

Even if it's not that, I still suspect it's an issue with an array client state.

[The_Piper]

Ok, i dont feel like reading this whole thread again, but im sure, i read this somewhere (and i cant search for "bag")

 

(using CVS client from yesterday with KarenRei's bugfix)

 

I killed 2 ogres in a row, so there were 2 bags to pick up.

 

I clicked on the bag of ogre #2 to open it, the one i was standing on. The char moved to the bag of ogre #1 and opens it instead of the bag of ogre #2.

 

Looks somehow strange for me..

 

 

Piper

Edited May 21, 2007 by The_Piper