Linux build. Please report if it crashes or loads incorrectly.

thaks for this wonderfull feature
and all the time and coffee you guys put in there
(and all the stress with your ladies. complaining that she feels so lonely and why the heck is no coffee left??...)

in case there is a "comatibility list", i tested the windows version with prince of persia without any problems so far

Where is DOSBox configuration for this version? My game requires a memory size of 32

bruenor41 wrote:

Linux build. Please report if it crashes or loads incorrectly.

It loads fine. There is no libpng12:i368 on ubuntu 18.10 so I had to search for it and install it manually from Ubuntu 16.04 packages.

One simple (I hope) request. Could you make a text appear on the screen when changing the saveslot so I know which one is active?

Btw: Works fine on Ubuntu 18.04 LTS.
Works fine with Syndicate and Mortal Kombat 2 so far.

Crap .... "save_states_4176_diff.patch" explodes when I try to apply it to SVN r4334. *sigh*

Has anyone by any chance updated the patch to a more current dosbox?

fr500 wrote on 2020-08-02, 02:22:

Has anyone by any chance updated the patch to a more current dosbox?

I'm thinking the people who know how to manage this have moved on.

Fairly mechanical update of the mentioned patch to current SVN. Only build-tested (on Linux). Specifically I did not check if additional machine state items were added that would also require saving and restoring.

EDIT: Also pushed here because all this shuffling of huge subversion diffs is really annoying: https://github.com/Ringdingcoder/dosbox-stagi … mits/savestates

Ringding wrote on 2021-10-21, 21:56:

Fairly mechanical update of the mentioned patch to current SVN. Only build-tested (on Linux). Specifically I did not check if additional machine state items were added that would also require saving and restoring.

EDIT: Also pushed here because all this shuffling of huge subversion diffs is really annoying: https://github.com/Ringdingcoder/dosbox-stagi … mits/savestates

Awesome! I'll have to make some time to compile a build for Windows and see how goes.

I was not even aware of the MAME stuff that you mentioned earlier in the thread. I’ll take a look if I find time. This is exactly what I meant with "additional state".

But before that, I will definitely split up the patch a bit in order to make any sense of the individual parts.

bruenor41 wrote on 2018-12-09, 07:22:

Linux build. Please report if it crashes or loads incorrectly.

Is there a static build of 4176 or later with saves states? Because of the missing shared libraries, when trying to execute the binary, I receive the following:

1dosbox: error while loading shared libraries: libSDL-1.2.so.0: cannot open shared object file: No such file or directory

even though the file exists and I have libSDL-1.2 installed:

1/usr/lib/x86_64-linux-gnu/libSDL-1.2.so.0
2/usr/lib/x86_64-linux-gnu/libSDL-1.2.so.0.11.4

Executing dosbox_r4019_SAV_Linux_Static_bruenor or the latest dosbox release has no such error.

It's probably a 32-bit build, install the 32-bit SDL libraries.

jmarsh wrote on 2022-05-04, 20:51:

It's probably a 32-bit build, install the 32-bit SDL libraries.

Of course. That was easily installed:

1apt install libsdl1.2debian:i386

However, further dependencies are required from Debian distributions no longer supported.
libpng12.so.0 is the next dependency required, and that hasn't been supported since Jessie.

Given current distributions are on 1.6 and have been for some time, I'm not willing to bring in a deprecated package, no longer supported into a current distribution.
I've tried out r4019 and that seems to work for my situation, so I'll stick with that.

Attached a few patch files. I wasn't able to get the save state patches for r4176 or r4467 to compile in MinGW without adding back iowin32.h and iowin32.c to the patches from an earlier version. So those adjusted patches that worked for me are attached. I also attached a modified version of the patch that should apply cleanly to r4481.

Tested only very basic functionality; I'm not sure how well they work yet.

I'm going to go ahead and attach my DOSBox builds I created with the patches in my previous post. The testing I did was very limited so I have no idea how well the Save State function will work in practice with these builds.

Since moving to Debian 12, somehow, even the statically-linked r4019 (incl. Bruenor) binaries have stopped working. I'm now running into segmentation faults with the following in dmesg:

1dosbox[904419]: segfault at 15 ip 00000000f77a72b6 sp 00000000ffaeadd0 error 4 in libX11.so.6.4.0[f7791000+8f000] likely on CPU 2 (core 0, socket 0)

It doesn't seem to want to play nice with libX11, even though it really shouldn't be interacting with it as it's statically-linked.

Given that the r4481 patches are 2 years old, are they still relevant?

I'd like to build one of the more recent SVN versions that is still compatible with the latest diff for save states.

Apparently, this patch would be all that is required to diff against the SVN build. However, this post/paste is from 2020 so I'm not sure how relevant this is any more..

Is there a later version of the source including the saves states (the last I could find in this thread is was r4019 from October 2017) or, the latest diff against the latest compatible SVN version?

EDIT: I could try the r4487 patch against the r4487 source, but I suspect @SedrynTyros is only building with MiniGW for Windows. If so, I could try the r4467 patch against the same version source and start from there.

UPDATE: Could be pure coincidence but I see @Ringding has been adding @SedrynTyros' iowin32 fixes into his branch today.

BUILD UPDATE: I took build 4481 and used only what was in the /dosbox/trunk directory (for those not familiar with SVN structure). I was able to patch r4481 cleanly with @SedrynTyros' r4481 patch, `make` and `make install` it. The build runs fine without any issue. I would attach a copy of the r4481 linux binary here but the compressed size is 5.3MB even with 7z.

A small caveat, but I noticed that, using the default key mappings, save state (ALT+F5) and previous slot (ALT+F6) were not working, but load state (ALT+F9) and previous slot (ALT+F7) were. I checked the keymapper, and they all were set correctly by default, and with the second modifier (MOD2). I tested the keys with other modifiers (CTRL(MOD1)+F5 for screenshot works). Once I changed the key mappings not to use any modifier, the save state and previous slot mappings worked.