Help a newbie out - Save files between iwads

[Cipher]

So I've finally purchased the other three iwads after starting out with Ultimate Doom the other month, and I have a question on how saving is supposed to work with source ports (bear with; I'm not normally a PC gamer and am new to the Doom/source port experience, so things that might seem obvious aren't to me).

When I launched Doom II through Crispy Doom, I was surprised to see it loaded all my Ultimate Doom saves (though obviously it wouldn't be able to play them). Does that mean I'm limited to Crispy Doom's eight or so save slots between all for iwads? Is there a way to fix this?

Here is my current structure for Doom stuff:

I'm using RocketLauncher2 as a front-end:



I have source ports and iwads sitting a directory setup like so:



And here's the inside of the Crispy Doom folder, with some previous saves from playing Ultimate Doom:



When I play Doom II through the launcher, I get my old saves from Ultimate Doom:



How do I fix? Is this normal?

Help what do.

EDIT -- Now when I launch the Crispy Doom application out of the folder, it starts playing Doom II as well, so I'm also confused about what determines that. I'm assuming whatever I learn for this will apply generally to playing different iwads with the same source port.

[chungy]

On Windows and the present (3.5) version of Crispy Doom, this is just how it is. All save files go into that directory.

This will change in the next release, supporting a "-savedir" command line argument to change the path of the save file directory, which can enable you to have multiple directories per IWAD, per PWAD, and so forth. You can get this functionality before the next release by downloading a development build

[Cipher]

chungy said:

On Windows and the present (3.5) version of Crispy Doom, this is just how it is. All save files go into that directory.

This will change in the next release, supporting a "-savedir" command line argument to change the path of the save file directory, which can enable you to have multiple directories per IWAD, per PWAD, and so forth. You can get this functionality before the next release by downloading a development build

Ah, thanks for the reply! I was this close to just copying Crispy Doom four times and pre-loading frontend configurations to launch it from a different directory for each iwad, which I'm guessing would have gotten around this, but been much more cumbersome than that fix.

[Edward850]

Cipher said:

Is this normal?

Yes. As far as anything that uses vanilla's save system as is, your saves are all kept in the same location with the same file names, so the saves themselves will appear regardless of whatever content is loaded. Crispy and Chocolate will both follow these rules, due to the nature of such ports.

Other vanilla compatible ports, such as PRBoom+ or Eternity, changes these rules slightly. PRBoom+ keeps them all in the same location, but with validation (so it's much harder to get crashes). Eternity splits them up per IWAD as each "game" is a different user folder.

Cipher said:

EDIT -- Now when I launch the Crispy Doom application out of the folder, it starts playing Doom II as well, so I'm also confused about what determines that. I'm assuming whatever I learn for this will apply generally to playing different iwads with the same source port.

Again with Crispy and Chocolate, they are based on vanilla specs exactly and thus the same rules. Neither of them had a proper IWAD picker so they launch based on first found (and the engine always looked for Doom2.wad first), unless you supply a launcher of some kind, but with a twist: They can find IWADs almost anywhere in your system. Most standard install locations, including Steam and GOG registry locations, are mapped out in all modern source ports for finding IWADs.

[Cipher]

Edward850 said:

Again with Crispy and Chocolate, they are based on vanilla specs exactly and thus the same rules. Neither of them had a proper IWAD picker so they launch based on first found (and the engine always looked for Doom2.wad first), unless you supply a launcher of some kind, but with a twist: They can find IWADs almost anywhere in your system. Most standard install locations, including Steam and GOG registry locations, are mapped out in all modern source ports for finding IWADs.

This is edifying. Thanks for clarifying the mechanics for iwad selection. Would the original DOS versions of the games have made this simpler just by virtue of each release having its own executable?

Would old DOS setups similarly have avoided the inconvenience of save overlaps by keeping the executables in their own directories? I guess that's what I'm looking to mirror in a modern (but not too modern, as I still prefer Chocolate and Crispy for their ease and slightly better performance over DosBox) source port.

Sorry if this all seems super basic; I come from a console background, so having to fiddle around with game setup this much at all is brand new to me. Just trying to get things running in as organized a fashion as I can. Everyone's patience and input so far is very appreciated.

[Edward850]

That is pretty much how the DOS versions worked. You weren't supposed to put all the IWADs into one folder, but rather each game was kept in their own independent ones. The idea that doom.exe could load both Doom and Doom2 was purely an incidental component to how the engine was designed.
For Final Doom, that was even a requirement, as they were just slightly modified versions of Doom2, and as such didn't even have their own independent string lists.

[Cipher]

Well, that was a bit of a saga. I wound up actually doing the crazy thing I mentioned earlier and copying all the Crispy Doom files into a few separate folders labeled "Crispy Ultimate Doom saves," "Crispy Doom II saves," and "Crispy Final Doom saves" (which should be enough), to mimic having separate executables, and set up some custom loads in RocketLauncher to just call up the application from the appropriate directory. A bit of an awkward workaround, but the result is having separate saves while still being able to launch each game with a click of a button.

I did check out the new Crispy Build, though having to switch save directories with a command line argument in the setup (each time you switch games, right? Is there a way I missed to more or less automate this based on the iwad?) is a bit inconvenient. More disconcertingly, I immediately caught the return of the tinny sound effects that bothered me in Chocolate Doom, but which never seemed to crop up in Crispy for me. Maybe because of all the sound extensions the last full build came with?

I also checked out Eternity earlier, and it honestly seemed wonderful -- no-frills vanilla compatibility with a few extra conveniences for organization and resolution, which is all I've been looking for, but I wound up having the same choppy framerate issues I had with Crispy before switching the video driver in the config to directx (which Eternity seemed to have no option for), and for whatever reason I could never get music to play in it. It doesn't seem to have ever been fully updated for Windows 10, so figuring out what the incompatibilities were there is probably beyond my level of expertise. I tried to figure it out for a good while.

Phew. If anyone cares to weigh in on the issues above with solutions or explanations, that'd be awesome, but in the meantime, at least I have a simple working system, even if the backend is a little obtuse.

Any future no-frills port with a few resolutions options and a simple branching save system would be an absolute godsend. Of course beggars can't be choosers and I appreciate all the hard work source port creators have put into these for no other reason than wanting to provide something to the community.

[Edward850]

Cipher said:

I also checked out Eternity earlier, and it honestly seemed wonderful -- no-frills vanilla compatibility with a few extra conveniences for organization and resolution, which is all I've been looking for, but I wound up having the same choppy framerate issues I had with Crispy before switching the video driver in the config to directx (which Eternity seemed to have no option for), and for whatever reason I could never get music to play in it. It doesn't seem to have ever been fully updated for Windows 10, so figuring out what the incompatibilities were there is probably beyond my level of expertise. I tried to figure it out for a good while.

Eternity is absolutely a Windows 10 compatible and intended port. It's even developed on it.

You can't find "directx" for two reasons: It's not based on Chocolate Doom, rather a thing called SMMU (Eternity<-SMMU<-MBF<-Boom), as such the same backend and config options wont exist at all. Eternity also doesn't use DirectX, rather SDL and SDLGL, so what you're looking for is GL2D.
You can configure the video backend in the last page in the video options, and running under GL2D should alleviate display related performance issues.

As for music not working, can't explain that. the MIDI works on Windows 10 demonstrably fine in Eternity, so something else is wrong, like if you've uninstalled something system critical for playing back MIDI.
Having absolutely no idea what you've done to your own computer, the fast solution to this would just be to replace your MIDI driver with something like VirtualMIDISynth.

[Cipher]

Edward850 said:

Eternity is absolutely a Windows 10 compatible and intended port. It's even developed on it.

You can't find "directx" for two reasons: It's not based on Chocolate Doom, rather a thing called SMMU (Eternity<-SMMU<-MBF<-Boom), as such the same backend and config options wont exist at all. Eternity also doesn't use DirectX, rather SDL and SDLGL, so what you're looking for is GL2D.
You can configure the video backend in the last page in the video options, and running under GL2D should alleviate display related performance issues.

As for music not working, can't explain that. the MIDI works on Windows 10 demonstrably fine in Eternity, so something else is wrong, like if you've uninstalled something system critical for playing back MIDI.
Having absolutely no idea what you've done to your own computer, the fast solution to this would just be to replace your MIDI driver with something like VirtualMIDISynth.

Thanks for all this. Pulled up Eternity again to have another look around. Got it running smoothly in capped framerate mode with GL2D.

The issue I was having, now that I've looked at it again, is actually that it reports a conflict with Virtual Midi Synth with itself after I close it, and won't play music after that. Every time I close and restart it, I get "Virtual Midi Synth is already in use by [path to Eternty Engine]."

Edit - Restarted Virtual Midi Synth and the problem seems to have stopped. Not sure what caused. Anyway, thanks for making me check out Eternity Engine again, as it's a great port, as well as for clarifying the video issues as well, as I have absolutely no background in that and have only been learning about them while looking for source ports.