fabian

Yes, that's probably it.

Couldn't reproduce the crash so far. Do you guys have any fancy features enabled?

That's a pretty explicit "no" for sure. Skipping the intermission screen, which requires a button press, will very sure lead to desyncing demos, which record all the button presses.

The next release will have a Crispy automap color scheme.

Edit: I was wrong.

That'd be my nightmare.

It's literally three lines of code and already unconditionally enabled in Crispy, so would anybody mind if we add this to Woof?

And yet you call yourself vanilla_d00m?

That's a fair suggestion! I tend to think too complicated sometimes.

Also dsda-doom: Sorry, but I don't think there is anything like this in Doom. How is a port supposed to know if a text replacement has been created with the expectation that it is drawn to screen with widescreen rendering enabled?

Nope, this doesn't have anything to do with compatibility. Crispy is *always* 100% compatible to any version of Chocolate Doom, for the exact reasons I outlined above. It doesn't make a difference how *old* code is a long as it maintains demo compatibility. Also, Crispy is currently only two commits behind Chocolate Doom master branch anyway.

This change alone increases my FPS from 9 to 28 in the opening scene of comatose, and I can't even spot any difference. --- a/src/r_things.c +++ b/src/r_things.c @@ -47,6 +47,7 @@ #include "z_zone.h" #define MINZ (FRACUNIT*4) +#define MAXZ (FRACUNIT*8192) #define BASEYCENTER 100 typedef struct { @@ -539,7 +540,7 @@ void R_ProjectSprite (mobj_t* thing) tz = gxt-gyt; // thing is behind view plane? - if (tz < MINZ) + if (tz < MINZ || tz > MAXZ) return; xscale = FixedDiv(projection, tz);

@rfomin we could make the max vis sprite distance dynamic just as we do for voxels, what do you think?

Very good question, thank you! In fact, network compatibility is closely bound to demo compatibility. That is, during a network game, the ports exchange packages which contain game tics, whereas when playing back a demo, these game tics are read from the demo lump file. So, if two ports are able to play back the same demos without getting out of sync, they should be able to maintain a network game without getting out of sync as well. I can say with highest confidence that this will be the case with Chocolate Doom and Crispy Doom and Woof on vanilla complevel.

Oh, maybe I should better revert that commit and explicitly check for sprite distance instead.