Game Client Crashes

[Z-Man]

Ok, that one has a tail length of 1mm, the bulk trail rendering code never gets called. Let's assume the problem lies there. I'll prepare special versions for you where you can toggle the trail rendering so we can see what happens. In the meantime, can you check whether the crash also appears when you just watch other games? It's going to be difficult to play with the test version

[Soapy]

Yeah sure I'll go spectate some other gametypes and see if I still crash. Doesn't matter to me if itll be hard to play as long as it helps the problem get fixed.

EDIT: I just sat in spectator mode in my DF server for a little bit and it crashed still.

[Z-Man]

Test build:
armagetronad-0.2.8_soapy20110801.win32.exe (Yeah, slow download, sorry.)
I rearranged trail rendering a bit there. It's simpler and gives about a 1% speed boost, too, at least with display lists enabled. With any luck, it won't crash for you at all. It's wishful thinking, but on odd unexplainable crashes that glitches in the driver may be responsible for, just shuffling stuff around sometimes helps.
If it still crashes, add this to your configuration (like autoexec.cfg, it won't persist in user.cfg):

Code: Select all

RENDER_BEGIN_LINES 1
RENDER_BEGIN_QUADS 1
RENDER_BULK_LINES 0
RENDER_BULK_QUADS 1

And try again. If that still crashes, try

Code: Select all

RENDER_BEGIN_LINES 1
RENDER_BEGIN_QUADS 1
RENDER_BULK_LINES 1
RENDER_BULK_QUADS 0

And if that still crashes, just to check we're remotely on the right track,

Code: Select all

RENDER_BEGIN_LINES 0
RENDER_BEGIN_QUADS 0
RENDER_BULK_LINES 0
RENDER_BULK_QUADS 0

You can also set the variables to 0 in the console, but you should do so before entering a game.

[Soapy]

Ok so results:

Test 1: Just the client you made - Crashed (almost seemed to crash faster)
Test 2: first bit of code - Crashed (about a normal time)
Test 3: second bit of code - No Crashing, ran it for about 45min

Another not as dire thing is I was unable to find my autoexec.cfg file which is strange cause Ive seen it before

[Z-Man]

Ok, that's something. How about:

Code: Select all

RENDER_BEGIN_LINES 0
RENDER_BEGIN_QUADS 0
RENDER_BULK_LINES 1
RENDER_BULK_QUADS 1

[Soapy]

Well I just used that code and it worked as well.
Been playing for about 45min with no crash.

And that last bit of code made it quite difficult to play i must say

[Z-Man]

And that last bit of code made it quite difficult to play i must say

Harder than all zeroes?

Right, found two anomalies, one in each _BEGIN_ code path. Nothing illegal AFAIK (wasteful, though), but sadly, OpenGL drivers aren't used to unusual call patterns. This new build removes both: armagetronad-0.2.8_soapy20110803.win32.exe

Again, first try

Code: Select all

RENDER_BEGIN_LINES 1
RENDER_BEGIN_QUADS 1
RENDER_BULK_LINES 1
RENDER_BULK_QUADS 1

This time, if it still crashes, try these two combinations

Code: Select all

RENDER_BEGIN_LINES 0
RENDER_BEGIN_QUADS 1
RENDER_BULK_LINES 1
RENDER_BULK_QUADS 1

Code: Select all

RENDER_BEGIN_LINES 1
RENDER_BEGIN_QUADS 0
RENDER_BULK_LINES 1
RENDER_BULK_QUADS 1

And see if at least one of them works.

(Should this work, the code changes relative to the first test build are tiny and could enter 0.2.8.3.2 no problem.)

[Soapy]

Results:
No code/all 1's - Crash
First bit of code - Crash
Second bit of code - No Crash

[Z-Man]

Wait, wasn't this one with the earlier build ok?

Code: Select all

RENDER_BEGIN_LINES 0
RENDER_BEGIN_QUADS 0
RENDER_BULK_LINES 1
RENDER_BULK_QUADS 1

Can you try that here with the new build?

(If it's still problematic, it's probably not the way we pass the data, it's the data itself, which is dynamically generated in those functions. That's something I can scan the OpenGL call log from earlier for, I guess.)

[Soapy]

That one worked, ran it for awhile without a crash.

[Z-Man]

Even with all this information, scanning the GL logs for suspicious calls is still a nightmare. So: I scanned the code generating the geometry instead. Found two possible divisions by zero and one very real one, resulting in NAN colors. Definitely something I expect drivers to stumble over. You don't see them because they happen only on zero length walls. Fixed all three issues, put them into this new build: armagetronad-0.2.8_soapy20110804.win32.exe
Just test the stock settings. It either works now or doesn't.

If it doesn't, can I ask another thing? Were you successful in enabling vsync to get FPS down to 60? If so, could you make a new crashing debug recording, I'm hoping it'll produce shorter logs.

[Soapy]

Ok well I've tested that build and to no avail, it crashed.
I will get another debug recording to you later tonight.

Thought you had solved it!

[Z-Man]

No worries, so far, every time I looked closer, new stuff popped up, there are going to be a couple of more obvious-once-spotted problems.

[Soapy]

Here you go another debug, but weird thing... my game didn't crash when I enabled that... I was able to get my fps down to 60 and below and unfortunately it is a longer recording.. I dunno why it made a difference, but it did. I would prefer not to play with it enabled though. I may make another recording with it disabled again so you can compare if you want.

EDIT: The second one is without VSYNC Enabled once more. I am going to enable it again just to make sure I'm not going crazy.

EDIT2: Yeah it is very strange (at least to me), that it works without crashing when VSYNC is enabled but crashes when it isn't..

[Soapy]

Ok unfortunately I have been online playing for awhile now and my game just crashed even though I had vsync enabled.. it just took 2x the time it usually does.
I'll get a recording..

Ok got a recording of it crashing with vsync