ZDoom

by **Coon** » Sun Feb 22, 2009 1:23 pm

SoulPriestess wrote:
Coon wrote:Random blackscreens/freezing remain an issue, but I can't even tell if the buffer thing has anything to do with them.
Most likely not the same problem. I would dare say this is a technical issue (driver, maybe?) and not a bug, but I'd have to test it myself. I could be wrong, though, and I have been before on a few occasions.

It happens only with ÆoD, so if in fact a technical issue, must be most unfortunate.

by **Rachael** » Sun Feb 22, 2009 7:48 am

Coon wrote:Random blackscreens/freezing remain an issue, but I can't even tell if the buffer thing has anything to do with them.

Most likely not the same problem. I would dare say this is a technical issue (driver, maybe?) and not a bug, but I'd have to test it myself. I could be wrong, though, and I have been before on a few occasions.

by **Coon** » Sun Feb 22, 2009 3:08 am

Graf Zahl wrote:Not really

Actually the behavior I reported no longer occurs with the new build, that's why I said it fixed for me, though I largely ignore the details and implications of everything else.

Random blackscreens/freezing remain an issue, but I can't even tell if the buffer thing has anything to do with them.

by **Karate Chris** » Sun Feb 22, 2009 2:51 am

It appears the write buffer has been bumped from 1400 to 14000 in r1438.

by **Graf Zahl** » Sun Feb 22, 2009 2:41 am

Not really.

I did some more tests. With AEoD's insane amount of weapons the entire network traffic for the weapons amounts to 1433 bytes - which slightly overflows the buffer. But seeing Randy's latest change gave me an idea: Why not collect the entire weapon setup in one buffer and compress it before sending it to the network code? That way a lot more data should fit into 1400 bytes - and I honestly can't think of any real life mod having such a large amount of weapons all at once. Anything with even semi-decent design goals with a large amount of weapons would possibly split them up between different player classes.

EDIT: Forget that. Randy also increased the message buffer to 14000 which should be more than enough. I míssed that part.

by **Coon** » Sat Feb 21, 2009 11:25 pm

r1438M fixed it for me

by **Graf Zahl** » Sat Feb 21, 2009 6:38 pm

Would it be possible to fill the buffer with some commands until it is full, then have the network code handle it and filling the buffer again without having to return to the main program loop?

Then it would be possible to just put as many weapons into the buffer as fit, send it and continue until all weapon info has been transmitted. But to be honest, when I look at that code I only understand half of it. That's why I only found the 1400 bytes limitation here after some extended searching. I was somehow assuming that the code would be able to split up larger buffers, considering that the FDynamicBuffer class has no size restrictions whatsoever.

If it wouldn't just help avoiding some awkward problems I would never have bothered making this change...

by **randi** » Sat Feb 21, 2009 6:21 pm

Graf Zahl wrote:the data is copied into a 1400 byte buffer

Yes, that's exactly what I thought of when I found out you were sending weapon data across the network again. There's really no provision at all for splitting up data and sending it in multiple packets, so the easiest thing to do would be to change what gets sent.

by **Coon** » Sat Feb 21, 2009 5:33 pm

Yeah, that was it, just like I thought

by **Graf Zahl** » Sat Feb 21, 2009 5:17 pm

Argh!

And I thought the networking code had enough intelligence to handle large buffers. But all the nice work with dynamically growing buffers is rendered useless in the end when the data is copied into a 1400 byte buffer without actually checking.

I have no idea how to fix this so there's 2 options:

1. Randy finds a solution
2. My weapon slot change which transmits the contents is reverted.

I'd much prefer solution 1, of course.

Nevertheless, this also pointed me to another problem: Weapons slots were recreated each time a player was spawned - for each voodoo doll and each temporary player actor. At least that could be fixed. It's enough for AEoD to run but it doesn't solve the problem.

by **Coon** » Sat Feb 21, 2009 4:05 pm

There you go.

by **Graf Zahl** » Sat Feb 21, 2009 3:52 pm

Please only post crash logs for versions obtained from an official source which for SVN builds means DRDTeam. I can't use this.

by **Coon** » Sat Feb 21, 2009 3:43 pm

It crashes when entering the second level of whatever I'm playing. This should probably be posted on the ÆoD thread rather than here because the project is a total disaster so it might not be ZDoom's fault afteralls.

Anyways, here's a crash report, for what it's worth.

ZDoom

Crash with ÆoD v4.21 (r1433M)

Post a reply

Expand view Topic review: Crash with ÆoD v4.21 (r1433M)

Re: Crash with ÆoD v4.21 (r1433M)

Re: Crash with ÆoD v4.21 (r1433M)

Re: Crash with ÆoD v4.21 (r1433M)

Re: Crash with ÆoD v4.21 (r1433M)

Re: Crash with ÆoD v4.21 (r1433M)

Re: Crash with ÆoD v4.21 (r1433M)

Re: Crash with ÆoD v4.21 (r1433M)

Re: Crash with ÆoD v4.21 (r1433M)

Re: Crash with ÆoD v4.21 (r1433M)

Re: Crash with ÆoD v4.21 (r1433M)

Re: Crash with ÆoD v4.21 (r1433M)

Re: Crash with ÆoD v4.21 (r1433M)

Crash with ÆoD v4.21 (r1433M)