Can you please post the source code for this build?

Yes, please give us the source/diff 😉 (you know gpl etc... 😉)

Ringding wrote:

Can you please post the source code for this build?

Dominus wrote:

Yes, please give us the source/diff 😉 (you know gpl etc... 😉)

Cornered 🤣 .

Seriously, just wanted to be sure of the stability before uploading the source as it was mostly a copy-paste job with pattern recognition and a teensy bit of coding knowledge.

Just remember that you asked for it, so don't hold me responsible for anything 🤣 that happens by downloading the thing that is attached below.

Futher a half-baked attempt on the win32 build using Visual Studio 2017(Windows SDK 10) resulted in a executable that threw a 'compression failure' error while the various components were getting saved (in the 'savestate.cpp' code of daum) when you hit Alt-F5. Weird that there was no problem with the linux build. Fortunately the ZenJu/tikalat 'savestate.cpp' code worked just fine, but the size of save files were in MB's 😳 whereas daum's save files were in KB's. You can't have everything. So this upload contains the latter savestate code only.

Win32 Build Summary:

11) Platform Toolset : Visual Studio 2017 (v141)
2
32) Target Platform(SDK Version): Windows 10 (10.0.14393.0)
4
53) Dependencies compiled: 
6   a) SDL (1.2.15)
7   b) libpng (1.6.29) & its dependency zlib( 1.2.8 )
8   c) SDL_net (1.2.7), 1.2.8 version failed to cooperate

Above Win32 Build attached in first post. Visual C++ Redistributable for Visual Studio 2015 install required, if not done already.

Maybe later, it will be worth a try to compile the source with daum savestate code in MinGW environment.

Compilation of daum savestate code was successful in MinGW environment. Modified Source attached below. Build attached in first post.

Win32 Build Summary:

11) Followed Building DOSBox wiki
2
32) Works in both WinXP and Win7 unlike the previous VS2017 build(WinXP - not a valid win32 application error)
4
53) Dependencies compiled: 
6   a) SDL (1.2.15) - library directly added
7   b) Direct Draw - libraries directly added
8   c) libpng (1.6.29) & its dependency zlib( 1.2.8 )
9   d) SDL_net (1.2.8)
10   e) libogg (1.3.2)
11   f) libvorbis (1.3.5)
12   g) SDL_sound (1.0.3)

I'd always recommend the Mingw environment, at least with autotool projects. Most of the time, it seems these built much better than with abandoned Visual Project files...

Started with MinGW only, but got stuck up at compiling libpng 1.6.29. Then switched to Visual Studio, which seemed easy initially, but ended up in a partially botched build. Had to learn it the hard way, my personal preference really, so that it gets properly latched as a first-hand memory. Later got libpng to compile under MinGW, after googling as usual, culprit being 'tabbed spaces/new line between certain 'define' parameters and its values'.

Dominus wrote:

abandoned Visual Project files...

Didn't know that, being new to the environment and all that.

Doing this as more of a time-pass only, so everyone please overlook, if any target is not set or met. A lack of confidence too, on my part, in fixing any bugs that might have resulted in the migration of the savestate patch from r3782 to r4007. Doesn't mean any lack of effort, however.

Now, leisurely, trying to zero in on the random segmentation fault on GP2 savestate loads in r4007 which is not there in r3782.

gandhig wrote:

culprit being 'tabbed spaces/new line between certain 'define' parameters and its values'.

The infamous pnglibconf.h error. 😀 I don't know why they didn't fix that already, this bug was already in the last 3 version, iirc.

I made myself a patch especially for this bug, so I can fix it quickly everytime a new version of libpng is released:

1--- pnglibconf.h
2+++ pnglibconf.h
3@@ -196,17 +196,17 @@
4 #define PNG_QUANTIZE_BLUE_BITS 5
5 #define PNG_QUANTIZE_GREEN_BITS 5
6 #define PNG_QUANTIZE_RED_BITS 5
7-#define PNG_TEXT_Z_DEFAULT_COMPRESSION 
8                                                    (-1) 
9-#define PNG_TEXT_Z_DEFAULT_STRATEGY 
10                                                 0 
11+#define PNG_TEXT_Z_DEFAULT_COMPRESSION (-1) 
12+#define PNG_TEXT_Z_DEFAULT_STRATEGY 0 
13 #define PNG_USER_CHUNK_CACHE_MAX 1000
14 #define PNG_USER_CHUNK_MALLOC_MAX 8000000
15 #define PNG_USER_HEIGHT_MAX 1000000
16 #define PNG_USER_WIDTH_MAX 1000000
17 #define PNG_ZBUF_SIZE 8192
18-#define PNG_ZLIB_VERNUM 
19                                     0x1280 
20-#define PNG_Z_DEFAULT_COMPRESSION 
21                                               (-1) 
22-#define PNG_Z_DEFAULT_NOFILTER_STRATEGY 
23                                                     0 
24-#define PNG_Z_DEFAULT_STRATEGY 
25                                            1 
26+#define PNG_ZLIB_VERNUM 0x1280 
27+#define PNG_Z_DEFAULT_COMPRESSION (-1) 
28+#define PNG_Z_DEFAULT_NOFILTER_STRATEGY 0 
29+#define PNG_Z_DEFAULT_STRATEGY 1 
30 #define PNG_sCAL_PRECISION 5
31 #define PNG_sRGB_PROFILE_CHECKS 2
32 /* end of settings */

If you need any help compiling DOSBox in MinGW, I'll gladly help wherever I can. I'm no pro or coder neither, but so far I had very few problems (except building it statically with Fluidsynth) using MinGW for my DOSBox ECE.

Yesterplay80 wrote:

If you need any help compiling DOSBox in MinGW, I'll gladly help wherever I can. I'm no pro or coder neither, but so far I had very few problems (except building it statically with Fluidsynth) using MinGW for my DOSBox ECE.

Thanks for the kind words and offered help, will remember that. Just started the first lap in this and judging by DOSBox ECE, you would be way ahead in the curve, pro definitely.

Maybe if you permit, once the savestate patch is stable enough(possible???), it can be merged with DOSBox ECE to benefit the community if there is any demand for it.

Join forces 🤣 and you are welcome to take the lead.

gandhig wrote:

Maybe if you permit, once the savestate patch is stable enough(possible???), it can be merged with DOSBox ECE to benefit the community if there is any demand for it.

You can, of course, download the source code of DOSBox ECE and try to apply the patch there as well. You'd have to expand it for Fluidsynth, MT32, OPL3 and whatever else I added to it.

Nice job. 😀

Old bug: save states don't work with Alien Carnage (Halloween Harry is fine, though).

Yesterplay80 wrote:

You can, of course, download the source code of DOSBox ECE and try to apply the patch there as well. You'd have to expand it for Fluidsynth, MT32, OPL3 and whatever else I added to it.

On a lighter note, during my school days, our English teacher used to quote an incident for registering the difference between the use of 'can' and 'may' in a sentence. Point is, 'may' being more of an approval than 'can' can ever be, i.e. it may or may not be an approval. Native English speakers may please correct, if wrong. So, is there a permission lurking in that sentence 🤣 ? Either way is fine really, as the patch has to be stable first, before it can be put to good use in addition to adding support for the patches included in your ECE build.

Firtasik wrote:

Nice job. 😀

Old bug: save states don't work with Alien Carnage (Halloween Harry is fine, though).

Thank you as well for reporting the bug.

Sorry but the save command is also failing in the tikalat's savestate patch applied r3782 build. Suppose my knowledge levels up to that level in the future, definitely will look into it. Maybe the authors can throw some light as some of this forum's posts and readme of Alien Carnage mentioned the bug fixes by those authors.

Firtasik wrote:

Old bug: save states don't work with Alien Carnage (Halloween Harry is fine, though).

Can you please try the attached build? Just a temporary fix for this game only. Not 100% sure, however. As a safety precaution just use the save/load feature within the same level and please use the game's save feature for saves between levels. Also please don't try to save in the menu or loading screen or anything else.

BTW, which OS? Both win and linux builds attached. Permanent fix may need getting to the bottom of the issue(now isolated only), can't say now if it is possible.

Thanks! It's working. I'm using Windows. 😀

Hey Gandhig,
Great job on the savestate build. I just wanted to report a minor idiosyncrasy to you. In Turrican II, using the VS 2017 build, savestates do not work, giving me the, "Decompression Failed" error. However, strangely enough, the MinGW seems to work just fine, loading and saving every state I created. I am using Windows 10 64 bit. Just figured you'd want to know.

PumpkinPaladin wrote:

Hey Gandhig,
Great job on the savestate build.

Full credit goes to the patch authors and dosbox authors. My contribution is very minimal, really.

PumpkinPaladin wrote:

I just wanted to report a minor idiosyncrasy to you. In Turrican II, using the VS 2017 build, savestates do not work, giving me the, "Decompression Failed" error. However, strangely enough, the MinGW seems to work just fine, loading and saving every state I created. I am using Windows 10 64 bit. Just figured you'd want to know.

Seems to be some issue pertaining to the update of the dosbox solution from VS2015 to VS2017(Please see 4th post from the top). If you can scroll down further, it can be seen that MinGW being the better option for building the dosbox. Sorry, can't help much with the botched VS2017 build.

Hey, any chance for a diff file that would cleanly apply to SVN r4019?

Gimme a day or two. Let me first check whether the rewritten mixer code automagically fixes the crash during the loading of savestate in GP2.

Edit: Yep it fixed it.

SedrynTyros wrote:

Hey, any chance for a diff file that would cleanly apply to SVN r4019?

Diff againt plain SVN r4019 is attached. And the usual disclaimer, 'USE IT AT YOUR OWN RISK'.

Win32 build compiled under MinGW is also attached. Again, 'USE IT AT YOUR OWN RISK'.

Once the other builds are ready, the original post shall be updated to reflect the new ones, probably in a day or two.

Edit: Win 32 Build moved to first post and updated. Diff files for both Linux and Windows attached.

Awesome! Thank you very much. 😀

EDIT:

Patch seems to work for me in the few tests I ran. This is great! I've been hoping for this for a long time.