Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
Sign in to follow this  
Grazza

GWA files can cause desyncs with Prboom

Recommended Posts

I've just spent quite a while tracking down the cause of a puzzling desync I had been getting, and was very surprised by the cause.

The demo is in the cchest2 demopack - it's Vile's demo on map28 (Ling's map). The desync occurs just under 12 minutes in: he falls from a walkway and ends up dead a little while later. However, with a fresh install in a separate directory and with just the essential files present, it worked OK.

After eliminating all the likely possibilities (something in the cfg), I discovered that the presence of the cchest2.gwa file was causing the problem. This is a supplementary file used or required by some OpenGL ports - some of them make these files when you load the wad. My understanding was that these files didn't affect behaviour (that's still deteremined using the normal nodes), and are just needed for the visual appearance. Indeed, I have these files for many wads in my Doom directory, and have hardly any unexplained desyncs. Perhaps it is because there is an error in the generation of the GL nodes for this map.

Even more oddly, the desync occurs whether using glboom.exe (OpenGL renderer) or prboom.exe (software renderer) if the gwa file is present. This is with version 2.2.6 and using a gwa file created by GLBSP 2.10. The demo is -complevel -1.

OK, well the brief summary of this is that you might very occasionally get some desyncs unless you make sure prboom doesn't find a gwa file for a wad. It would be nice to know exactly what the problem is though.

Share this post


Link to post

GL nodes will contain a different BSP tree than normal nodes, and since many bits of code use the BSP (especially sight checking), it is probably inevitable that slightly different behavior will result and lead to desyncs.

Looking at the 2.2.6 code, it seems the -forceoldbsp option will disable loading GWA files, and it is also disabled when the compatibility level is less than prboom_2 (i.e. for doom, boom 201/2, and MBF). And users can always delete it.

I don't know if glBoom will run without GL nodes though.

Share this post


Link to post

Thanks for the explanation. The conclusion is that for demos with a complevel of -1 (or higher than 7), one must stop the program finding the gwa file, either by hiding/removing it or with -forceoldbsp as you suggest.

I suppose the reason this problem hadn't been raised before is that there are few complevel -1 demos, and also because it doesn't seem to cause desyncs as readily as a rebuild of the standard nodes does.

Yes, GLBoom runs quite happily if it doesn't find a gwa file.

Share this post


Link to post

Update...

-forceoldbsp doesn't solve the problem with the demo I mentioned - the same desync occurs if the gwa file is present.

I notice in the documentation that -forceoldbsp can be used when recording, and is saved in the demo format. Perhaps this (i.e. the information about whether it was used or not used when recording) overrides what you put in the command line for playback.

BTW, Kristian: I notice that the textfile for the Cchest2 demopack doesn't identify Vile's demos as -complevel -1. Perhaps a few others in this pack are also the default complevel. Marco's c211-947 is, for instance.

Share this post


Link to post

Grazza said:
BTW, Kristian: I notice that the textfile for the Cchest2 demopack doesn't identify Vile's demos as -complevel -1. Perhaps a few others in this pack are also the default complevel. Marco's c211-947 is, for instance.


Whoops. I tried to check the text-files for info on complevels, but I guess some textfiles didn't list them (or I otherwise missed/misinterpreted the info), so I got some of the demos wrong. Sorry :-/

Share this post


Link to post
Grazza said:

I notice in the documentation that -forceoldbsp can be used when recording, and is saved in the demo format. Perhaps this (i.e. the information about whether it was used or not used when recording) overrides what you put in the command line for playback.

I just noticed this in the source code that -forceoldbsp is indeed saved (and overrides the command line), but not in all demos -- something like when compatibility is >= MBF (I don't fully understand the code).

EDIT: this must mean that if someone records a demo with a GWA file, you need the same GWA file to ensure proper playback (as the demo itself will disable -forceoldbsp i.e. implying GL nodes may have used).

Share this post


Link to post

It makes sense for it to ignore any gwa files when it is trying to record a demo that will play back with doom(2).exe (complevel 0 or 1), boom (complevel 3, 4 or 5) or mbf (complevel 7), as these exes don't have an OpenGL renderer.

My suspicion is that very few, if any, complevel -1 demos have been recorded with a gwa file used (fortunately, it appears). The possibility you describe of demos being recorded that require an identical gwa file to play back correctly is certainly an unappealing one. IMO it would make more sense for prboom to have -forceoldbsp as the default setting when recording, and an option to use the gwa file if you wish.

Thanks again for looking into this.

Share this post


Link to post

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
Sign in to follow this  
×