Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
FooAtari

Converting save files

Recommended Posts

Is it possible to convert save files from one format to another?

I want to use a save file from GZDoom (.zds) to GLBoom+, which seems to use the original format (.dsg).

Or is there a way to save games in GZDoom as .dsg? I have looked in the options but can't see anything so far.

Share this post


Link to post

No.

Also, you'll certainly find that despite the filename extension, GLboom+ does not use Vanilla savegames.

Share this post


Link to post

This may interest you.

The thing to keep in mind is that Doom's saves must contain the state of everything in the entire level. (In fact, there are a few bugs caused by the fact that in vanilla Doom, they failed to save and load absolutely everything needed.)

If saves worked like in Dark Forces, for example, where they only record which levels you have unlocked and your inventory at the start of each, then backward compatibility could have been kept across all ports, maybe.

Here, though? It's not possible at all. Suppose you add a new property to monsters, that makes one more value that must be recorded for each monster on the map, so the size of the record structure for monsters change, etc. And it's not just monsters, but also sectors, flickering or pulsing lights, scripts, etc.

Share this post


Link to post
fraggle said:

Also, you'll certainly find that despite the filename extension, GLboom+ does not use Vanilla savegames.

I thought it did when using a vanilla complevel.

At least, I recall that being implemented some years ago. I don't use saves though, so haven't really tested.

Share this post


Link to post

What about someone code-monkeying a converter of savegames from GZDoom to vanilla, as long as the loaded WAD is such-compatible...

Share this post


Link to post

It would be interesting if a bare-bones "weapons, inventory counts, and map position" conversion could be performed, maybe decreasing the monster count accordingly, and placing monsters at the right places seems simple (yet probably not).

Not that I'd ever use it. Save games in general are less and less important, beginning-of-level saves are almost all I use anymore.

Share this post


Link to post

I tested a couple of savegames with Ultimate DOOM and prB+ v2.5.0.9-test with -complevel 3 and neither can load the other's savegames.

Vanilla shows an appropriately renamed prB+ savegame in its savegame list but attempting to load that savegame does nothing. prB+ also can show an appropriately renamed vanilla savegame in its savegame list but attempting to load it leads to a "Unrecognized savegame version" warning followed by (if the user chooses to proceed with Y) a crash with a "Corrupt savegame" error.

The savegame formats appear quite different between the two, with prB+ savegames being much larger.

edit: explanation expanded.

Share this post


Link to post

Not surprisingly. Since savegames contain the entire game state and Boom added quite a bit of data there (not to mention fixing some serious issues with Doom's sloppy saving code) it's no surprise that they are incompatible.

We should be honest about one thing:

Doom's original savegame code is a piece of utter shit. It omits critical data for saving (like monster targets for example) and truncates other values (like a sector's floor and ceiling heights) - and completely misses out on the flickering light effect that was added in 1.666 or the boss brain state in MAP30. No self-respecting port that isn't out for total compatibility could afford to keep this code unaltered. I'm sometimes surprised that it worked at all.

Share this post


Link to post
Grazza said:

I thought in did when using a vanilla complevel.

I'm pretty sure Chocolate Doom is the only port that bothers with Vanilla savegame compatibility. I might be wrong though.

Share this post


Link to post
phi108 said:

Not that I'd ever use it. Save games in general are less and less important, beginning-of-level saves are almost all I use anymore.

They're still VERY important if you're playing something else than Doom or Heretic, i.e. a hub megawad.

Share this post


Link to post
printz said:

They're still VERY important if you're playing something else than Doom or Heretic, i.e. a hub megawad.


When you die in Vanilla HeXen it restarts you at the start of the map you died on with the equipment you entered it with.

Share this post


Link to post
Vermil said:

When you die in Vanilla HeXen it restarts you at the start of the map you died on with the equipment you entered it with.

Via creating an autosave when you enter the level. Strife works the same way.

Maybe we should have an IDSF - Interchangeable Doom Save Format ;) Actually that's pretty much infeasible, but I *do* intend on making a very open save format for EE to replace the current wonky one. It will be largely text-based, and each form of data will be contained inside a separate file inside a standard zip directory, with support for compression ^_^

Share this post


Link to post

^^^ I hope you're joking.

Vermil said:

When you die in Vanilla HeXen it restarts you at the start of the map you died on with the equipment you entered it with.

When you quit vanilla Hexen that autosave is lost; THAT is the point I was trying to make.

Share this post


Link to post
printz said:

^^^ I hope you're joking.

With regard to what? ISDF or the zip-based save format? The former was a joke, the latter has been a plan for over a year now, and has been accelerated toward its goal by the work already done for the C++ conversion. By basing the save format on an open archive format and putting some of the data (whatever practical) into text, the format will become much more easily examined externally, be it for bugs or because somebody would like to edit their save (say, give themselves more health because they accidentally saved with 1% or something :P).

It will also become more portable. Currently the save format does not support transplant of files between hosts of different CPU bit widths or endianness.

It will also feature enhanced versioning, so that you don't get crashes on trying to load expired saves, and forward compatibility, so that at the least you will start on the same level even if the save is of an expired version that cannot be loaded in full any longer.

It will also be much more careful with vetting the data that's being read in - ie., it won't be possible to try to spawn non-existent things because an EDF has changed, etc - stuff that could lead to crashes currently.

Share this post


Link to post
Quasar said:

It will also become more portable. Currently the save format does not support transplant of files between hosts of different CPU bit widths or endianness.

I think ZDoom solved that problem by using PNG chunks.

Share this post


Link to post

No. You can still write raw binary data into a PNG chunk. ZDoom's integer archiving functions perform swapping if necessary.

However, the PNG format is still sub-optimal because it's all one big binary blob. And the way object references are resolved at the moment sure doesn't make it easier.

If it wasn't for the convenience of having a PNG of the screenshot I would have already put some work into an XML-based save format (stored in a Zip, of course with the screenshot stored as a PNG in it.)

Share this post


Link to post

EE's current binary buffered IO classes *have* facilities to do endianness swapping, however the set of routines is not complete enough to support it in savegames - this is due largely to the presence of float, double, and int64_t values in some structures.

Share this post


Link to post

DoomLegacy got a new savegame header that includes:

- DoomLegacy savegame ID line.
- Savegame description string, supplied by player.
- Map level
- Level elapsed time
- Wad name from command line
- Game name (Doom, Final Doom, FreeDoom, etc.)
- command line (switches etc.)
- Endian flag
- INT byte size
- alignment padding flag (for SGI)

This is written in a human readable header format, "Langid", that I
developed some years ago. This allows the player to browse their savegame directories and identify the savegames, for sorting, deleting, etc..

Saving the command line is important because a savegame only works if the player uses the same wad and switches on the command line. If the player has forgotten, they can look in the savegame header.

The last fields were included so that savegames from one target machine would be detected and rejected by incompatible machines.
They also get rejected if they are playing a different game or wad.

The description string, level, and time, get displayed in the savegame menu.

I wrote a DoomLegacy savegame converter to convert Legacy 1.43 savegames to DoomLegacy 1.44 format, but even that is so hard that I do not trust it, and it has not been released. I am not yet sure it works completely. The plan was to add future DoomLegacy savegame formats to it, but had no plans to add other port savegames.

There are some fields where values had to be translated (such as a different ENUM). Handling fields that were added or removed is more difficult. Every place a struct was written has to have a field by field copy to the new struct format.

Share this post


Link to post
wesleyjohnson said:

Saving the command line is important because a savegame only works if the player uses the same wad and switches on the command line. If the player has forgotten, they can look in the savegame header.

While it works, this is actually far too strict. For example, the load order of PWADs may not need to be the same for mods that come in multiple files. Also, for EE, a factor that has to be considered are mods like Arctic Wolf, which requires saving mid-game, stopping, and then reloading the save with a new DEH file and a different sprite wad because of the fact it defines too many distinct "actors" to have them all defined at once using only DeHackEd.

wesleyjohnson said:

The last fields were included so that savegames from one target machine would be detected and rejected by incompatible machines.
They also get rejected if they are playing a different game or wad.

It'd be a lot better to use endian- and bitwidth-independent writing and reading routines so that saves are universal ;)

Share this post


Link to post

Tangential question, if EE gets zip support, does it mean .pk3 packaging will be possible too? Or loading embedded .wad without extracting them first?

Share this post


Link to post

@Gez: I believe it's planned, though a different extension from pk3 may be considered preferred (though both will be supported) to better differentiate and to allow for more appropriate Explorer file-associations to each port.

Share this post


Link to post
esselfortium said:

@Gez: I believe it's planned, though a different extension from pk3 may be considered preferred (though both will be supported) to better differentiate and to allow for more appropriate Explorer file-associations to each port.

Open a save game just by double-clicking it? Now that would be cool.

If only port-specific WADs had different extensions too...

Share this post


Link to post
printz said:

Open a save game just by double-clicking it? Now that would be cool.

If only port-specific WADs had different extensions too...

Huh? I'm talking about pk3-style archive support, since Gez asked about it.

Share this post


Link to post
esselfortium said:

Huh? I'm talking about pk3-style archive support, since Gez asked about it.

I meant starting a game directly by double-clicking the savegame file.

Share this post


Link to post

You pretty much can already do that, you just need to configure your OS for it.

Share this post


Link to post
printz said:

I meant starting a game directly by double-clicking the savegame file.

Suppose it could be done by loading it automatically when it appears as a loose file on the command line. Eternity savegames will have a distinct extension from any other file type the engine uses.

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
×