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

BTSX Savegame Buffer Overrun!?

Recommended Posts

I was at a lost of words when I saw the error playing BTSX Ep1 (was going through another playthrough of both episodes, this time on Chocolate Doom, I've already played them in advanced sourceports). I understand the significance of the error in vanilla/chocolate doom but what I don't understand is why it happened in a wad that was being broadcasted as being vanilla tested/compatible but then flings these out.

Ep2 seems to crash when starting Map01.

Share this post


Link to post

Chocolate Doom has an option to disable this. With that in mind and also the fact that many players play in Chocolate Doom for vanilla compatibility rather than vanilla itself, savegame buffers overflows are generally overlooked in vanilla projects now

Share this post


Link to post

Well, a lot of "vanilla compatible" maps in 1994 also caused buffer overruns when saving. In fact, any large enough level with too much "state" to keep track of, would. And at least Chocolate Doom is supposed NOT to "fix" this behaviour.

Savegame "friendliness" is often an overlooked factor when mapping, but AFAIK it's not considered a compatibility requirement.

Share this post


Link to post

It dramatically defeats the point of saving the game, however.

Has anyone made any limit-removing map that even Doom+ has trouble running?

Share this post


Link to post

[quote="printz" post="1420248"]
It dramatically defeats the point of saving the game, however.

printz said:

Has anyone made any limit-removing map that even Doom+ has trouble running?


Considering that Doom+ still uses signed shorts internally for a lot of things like linedef lists, even assuming that rendering limits are not exceeded at any point, other, subtler internal limits might "break" way before that happens. FWIW, I recall Europe.wad did at least load in Doom+, though it would almost certainly break or bug out afterwards due to some Boomisms like using flats for textures.

I'm curious how the savegame size was simply statically increased in Doom+ though, as I was under the impression (from the source code) that the screen/video memory was used for it. To begin with, it was a kinda dumb design choice to buffer everything before saving it to disk: at least saving could be done with straight serialization ("fwrite"), and since C buffers disk I/O anyway, it wouldn't have made much of a difference saving.

Identically, loading could also be done without a buffer (FFS, you're loading stuff to memory...just to place it somewhere else in memory afterwards. You might as well do it as you unmarshall them).

Share this post


Link to post

I remember I had to add a fix to Mocha Doom especially for Europe WAD, because in the graveyard area the tombstones were textured using a flat (or at least, there was a texture and a flat with the same name, which caused ugly consequences if interpreted incorrectly).Boom has namespaces to disambiguate between such occurences, Vanilla Doom doesn't (in fact, that prompted me to add Boom-like namespace support).

BTW, Europe.wad is ambiguously listed with "non-sourceport specific" (aka regular) mapsets, and the text file itself is ambiguous. It says it runs with "Doom2.exe" at the beginning, but in the end it says that it will not run with vanilla Doom. Also, no mentions of needing an advanced source port due to Boomisms.

Share this post


Link to post
Maes said:

(or at least, there was a texture and a flat with the same name, which caused ugly consequences if interpreted incorrectly)

I assume you mean a patch? Stock texture sets have some identical texture and flat names.

Share this post


Link to post
Da Werecat said:

I assume you mean a patch? Stock texture sets have some identical texture and flat names.


I only vaguely remember the actual incident, but yeah, it boiled down to a patch being used in place of a flat or viceversa (because of identical names). I don't know about the stock texture sets though, I'd expect the same problem to pop up if that were the case, unless the WAD file structure/priority (placing patches after flats, maybe?) normally prevents it.

Share this post


Link to post
Da Werecat said:

I meant textures as TEXTUREx entries. STEP1 and STEP2, to be precise. I don't know any patches named as flats.


The TEXTURE generation and access mechanism does normally prevent requesting a lump with the same exact name as a texture entry (it will be looked up in the texture table instead), but it's still possible for a patch and flat name to clash. In that case, only actual lump priority, additional checks or the use of namespaces can avoid unpleasant situations.

Share this post


Link to post

The savegame buffer limit is ignored for vanilla compatibility purposes because you don't actually need to save and reload during a level.

Share this post


Link to post

http://www.chocolate-doom.org/wiki/index.php/Setup/Compatibility

If you put a lot of work into your game before the crash you'll be pleased to hear that the savegame is still saved - it's written to a temporary file that you just need to rename.

Plucky said:

I understand the significance of the error in vanilla/chocolate doom but what I don't understand is why it happened in a wad that was being broadcasted as being vanilla tested/compatible but then flings these out.

Well, technically you can play it in Vanilla just fine so long as you never save the game.

Share this post


Link to post

The savegame buffer limit is often ignored for vanilla wads because there's no reliable way to even test for it. The savegame has to keep track of all things in a map, including monster projectiles and dropped pickups, as well as the states of moving sectors, so it can fluctuate significantly and a map thought to be within the limit could end up overflowing it if, say, an archvile keeps resurrecting hitscanners and they keep dropping more pickups where the player can't grab them.

It's practically impossible to test for and I'm pretty sure the only way it could be truly avoided is to only make much smaller maps with much fewer monsters in them, and that's not really a tenable solution IMO. Breaking the savegame buffer has been established tradition for a long time now -- I know Suspended in Dusk does so on its largest map, and I believe Alien Vendetta does it a bunch too, if I'm not mistaken. It's not ideal, obviously, but there's not much that can be done to get around it.

I recommend using Chocolate Doom's savegame buffer extender option, or one of the patched Doom2.exe versions in existence, if you want to save while playing.

Share this post


Link to post
esselfortium said:

The savegame buffer limit is often ignored for vanilla wads because there's no reliable way to even test for it. The savegame has to keep track of all things in a map, including monster projectiles and dropped pickups, as well as the states of moving sectors, so it can fluctuate significantly and a map thought to be within the limit could end up overflowing it if, say, an archvile keeps resurrecting hitscanners and they keep dropping more pickups where the player can't grab them.

How about playing a demo (or blazing with godmode) and using a utility that plots the savegame buffer size for each tic? You'll then have a time-based graph and might be able to see if it overruns the buffer.

Does chocorenderlimits calculate that on the HUD?

I seriously have to start working on a choco-doom branch that does all manner of vanilla-compatible stuff...

Share this post


Link to post
Plucky said:

Ep2 seems to crash when starting Map01.

Do you mean that it crashes as soon as you start the game? Did you load both "btsx_e2a.wad" and "btsx_e2b.wad" together? Like this:

chocolate-doom -file btsx_e2a.wad btsx_e2b.wad -deh btsx_e2.deh

Share this post


Link to post

Yeah I loaded all the necessary files for Episode 2.

EDIT: Turns out "btsx_e2a.wad" and "btsx_e2b.wad" both have a 2nd part as well (although I don't need to load btsx_e2a_b2.wad and/or btsx_e2b_b2.wad on advanced sourceports)

Share this post


Link to post
printz said:

How about playing a demo (or blazing with godmode) and using a utility that plots the savegame buffer size for each tic? You'll then have a time-based graph and might be able to see if it overruns the buffer.

Isn't it possible to make even select Doom2 maps overrun? Even if such a tool was available, complying with this limit would severely cripple maximum map complexity.

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  
×