SedrynTyros wrote:

I took a shot at updating the bruenor patch with work with 4168, but had to give up after several hours of fiddling with it. The merging of the MAMEsound branch into the trunk in r4075 made massive changes to the way the sound is setup. Reworking the save state patch to work with the new design is well beyond my capabilities.

Recently I came out of the music phase I was in for the past 6 months or so.

Give me some time to recall and jump into the phase I was...when I left.

BTW, nice to see that there is still interest.

Edit (20/10/18): Thanks for your efforts, SedrynTyros. Glad to know about your possible success so far and if you upload your patch for SVN r4074, that would definitely give me a good head start. Just seeing the SVN Log History of 6 pages of commits was daunting by itself. Also, requesting to not expect much due to the usual reason mentioned countless times in this thread. Ok, one small step at a time...

Kerr Avon wrote:

The brilliant Spectrum emulator for the PSP, FUSE PSP, saves it's save states with a screenshot included, and when you go to the load/save screenshot page, it shows you the ten save slots, with each slot showing the screen shot if there is a save state in that slot, as two rows of five, and then you move to the slot you wish to load or save to, and press the correct button to load or to delete or to save the save state into the selected slot (you can of course save over an existing save-game if you choose).

Also, slot ten is special, in that it's an auto-load slot, so that if you load the game then if there's a saved snapshot in slot 10 then it's automatically loaded after the game is loaded. You can disable this if you like, but this might be a nice addition to DOSBOx, I think. Maybe with a "There is a save-state in the autoload slot for this game, would you like to load it now [Y]es/[N]o" message appearing after the game is first loaded.

I started this originally as a study project which later turned into a hobby. My knowledge of coding is very limited. Since the priority is to adapt this patch w.r.t updates in the main code branch, please allow me to put your 'Need for Feature' into the pending list.

Thanks.

gandhig wrote:

Recently I came out of the music phase I was in for the past 6 months or so. […]
Show full quote

SedrynTyros wrote:

I took a shot at updating the bruenor patch with work with 4168, but had to give up after several hours of fiddling with it. The merging of the MAMEsound branch into the trunk in r4075 made massive changes to the way the sound is setup. Reworking the save state patch to work with the new design is well beyond my capabilities.

Recently I came out of the music phase I was in for the past 6 months or so.

Give me some time to recall and jump into the phase I was...when I left.

BTW, nice to see that there is still interest.

Oh yeah, definitely still interested in having a save states patch compatible with current DOSBox builds! I have a feeling the DOSBox devs are done with making major changes to the code pending the upcoming 0.75 release, so if you or bruenor can figure out how to modify the save state code to be compatible with the Gameblaster and Tandy changes and produce a patch we're probably be good to go for the foreseeable future. And thanks again for all the work you guys have done on this!

EDIT:

I was able to clean up the r4019 patch to work with r4074. I'll do some more testing to see if it actually works with games, but initial results look good. If I can find the time to confirm it works I'll upload the patch here.

I've attached the modified patch that applies cleanly to DOSBox r4074 named "bruenor41_savestate_r4074_win32_mingw_v2_st-update.patch". The patch is based on "bruenor41_savestate_r4019_win32_mingw.patch" but also includes the fix for raiden that bruenor41 posted here:

Dosbox SVN r4019 + savestates Build (Alpha)

I've tested a few games and Save States seem to work correctly. I don't really have time for extensive testing right now, but I've attached "DOSBox-SVN-r4074-with-Save-States.rar" which is the basic DOSBox build I compiled for testing if somebody else wants to play around with it.

SedrynTyros wrote:

I've attached the modified patch that applies cleanly to DOSBox r4074 named "bruenor41_savestate_r4074_win32_mingw_v2_st-update.patch". The patch is based on "bruenor41_savestate_r4019_win32_mingw.patch" but also includes the fix for raiden that bruenor41 posted here:

Dosbox SVN r4019 + savestates Build (Alpha)

I've tested a few games and Save States seem to work correctly. I don't really have time for extensive testing right now, but I've attached "DOSBox-SVN-r4074-with-Save-States.rar" which is the basic DOSBox build I compiled for testing if somebody else wants to play around with it.

Yep, works fine at my end too 😎 .

I will be able to work on this during the weekends only and since there is quite a lot to catch up, please bear with me. Also, I will be intermittently switching between this and DOSBox compilation guides(if DosFreak becomes active on that).

That's the plan, I'm just slow. Trying to debug this xorg mouse issue right now. I'm sure it's something small I'm just ignorant. 😀

Well, I recently upgraded to Ubuntu 18.04 LTS, but the Xorg version is 1.19.6. I'm probably more ignorant than you 😵 , still, I will check out this weekend,

18.04 w/ Xorg 1.19.6 is fine. Xorg 1.20.x exhibits the issue: (comes with Ubuntu 18.10): Mouse capture not working in Linux with Xorg 1.20.x

gandhig wrote:

SedrynTyros wrote:

I've attached the modified patch that applies cleanly to DOSBox r4074 named "bruenor41_savestate_r4074_win32_mingw_v2_st-update.patch". The patch is based on "bruenor41_savestate_r4019_win32_mingw.patch" but also includes the fix for raiden that bruenor41 posted here:

Dosbox SVN r4019 + savestates Build (Alpha)

I've tested a few games and Save States seem to work correctly. I don't really have time for extensive testing right now, but I've attached "DOSBox-SVN-r4074-with-Save-States.rar" which is the basic DOSBox build I compiled for testing if somebody else wants to play around with it.

Yep, works fine at my end too 😎 .

I will be able to work on this during the weekends only and since there is quite a lot to catch up, please bear with me. Also, I will be intermittently switching between this and DOSBox compilation guides(if DosFreak becomes active on that).

Hey, no worries. I really appreciate the work you and bruenor41 have done so far.

If I remember well, when mame core appeared in dosbox branch, there was code for save/load states, but was removed during implementation. Find it would be useful, or maybe save states can be updated to latest svn without support for mame core. I want look at this later, just now I am very busy at work.

Welcome bruenor41! Take your time, no hurry. Meanwhile, warm-up process is underway at this end due to a rusty feel w.r.t dosbox and coding. Hoping to start from this weekend.

Last two days I was working on save state patch to get it up to date with svn 4175. I fixed gameblaster and adlib incompatibility due mame core. I tested it on monkey island 1. Seems it works even is not perfect, problem is if someone creates save state file with opl2 and then changes config to opl3. Load state is corrupted, ideally should be opl changed during load state, but for now it is enough. Will try make patch soon

I don't know how feasible this is but it seems to me as if the savestate needs to save also the current conf somehow so you can look up what it was so a corruption does not happen or that you can look up up with which configuration it was saved.

bruenor41 wrote:

Last two days I was working on save state patch to get it up to date with svn 4175. I fixed gameblaster and adlib incompatibility due mame core. I tested it on monkey island 1. Seems it works even is not perfect, problem is if someone creates save state file with opl2 and then changes config to opl3. Load state is corrupted, ideally should be opl changed during load state, but for now it is enough. Will try make patch soon

I maybe able to join by this weekend. The debugging task I'm working on has taken me deep down the rabbit hole. But that knowledge could turn out to be useful later.

Dominus wrote:

I don't know how feasible this is but it seems to me as if the savestate needs to save also the current conf somehow so you can look up what it was so a corruption does not happen or that you can look up up with which configuration it was saved.

Save state remembers current configuration, I know which opl was used and it's actual state. But if someone quits dosbox and sets another opl in config, save state loads old opl and tries apply it to new opl. This makes corruption. Maybe I can switch new opl to opl saved in state file during state load, will try it tomorrow.

I created patch file for sn 4176, hope correctly

In hardware.cpp I faced issue with variable std::string capturedir; Newly it was defined as static which makes compilation errors in save_state.cpp :

save_state.o: In function `SaveState::save(unsigned int)':
save_state.cpp:(.text+0x7b4): undefined reference to `capturedir[abi:cxx11]'
save_state.cpp:(.text+0x7de): undefined reference to `capturedir[abi:cxx11]'
save_state.o: In function `SaveState::load(unsigned int) const':
save_state.cpp:(.text+0x165a): undefined reference to `capturedir[abi:cxx11]'
save_state.cpp:(.text+0x1684): undefined reference to `capturedir[abi:cxx11]'
collect2: error: ld returned 1 exit status

changing it back to non static solved the error, how it should be fixed correctly ?

Afraid this is not possible, as it is a contradiction...unless one includes the hardware.cpp file itself in the savestate source file, which is totally demeaning 🤣 .

More importantly, there was no crash when I 'Save-Loaded' my usual test case with this build 😀 .

Thank you, could you upload please binaries? I dont compile on windows

Windows binary is attached. My Linux build environment is probably messed up, some new errors were observed during the build attempt(probably due to my tampering(s) or new SDL version or both)...will check it out later.

Till that time, if possible, could you please upload your linux binary?

Once satisfactory testing is completed, both the binaries shall be added to the first post.

Thanks for keeping it alive, guys! 😀