VOGONS

Common searches


Save States - Proof of concept

Topic actions

Reply 20 of 227, by ZenJu

User metadata
Rank Newbie
Rank
Newbie

> store everything that's currently in DOSBox's emulated memory
Guess what I'm doing 😉 But RAM alone isn't enough. Other computer parts have state as well, like CPU, video, keyboard, etc.

https://sourceforge.net/projects/xbrz
https://freefilesync.org

Reply 21 of 227, by frobme

User metadata
Rank Member
Rank
Member

Regarding my earlier questions - I wrote the save state for the Atari800 emulator, and a couple of others. Basically you are interested in saving everything that may be read in any form later - while I'm not aware of any DOS programs reading the sound card buffer, if it ever happens, that game will fail obviously if you aren't committing it as part of the state. Obviously many games depend on the cumulative state of the video frame buffer (although they may not read it, just not update it in areas that haven't changed), but I haven't picked apart DOSBox's approach on that, it may just be part of video ram as it was in real DOS.

For files, what I did previously was save some meta data related to what the emulator had open, namely the CRC of each loaded file (and the file pointers, which may be important!). It's not your responsibility (imo) to bundle up all the files for the next state load - think of the case where the game has 5 CDROMs loaded - but you do need to be able to determine if the files loaded are the right ones. File pointers are easy; after you have them you just seek to the point in the file you were previously on load, and you're set.

The older (and much less complex) emulators I did this on had an interesting wrinkle I'm not sure you've had time to consider because you aren't writing out to files - when you are saving meta-data, particularly configuration information, you have to write out fundamental data types (ints, etc) in a platform-neutral way if players are ever going to be able to share them. Of course the int representation of an x86 and PPC are reversed, and bit widths differ for native ints, that kind of thing. There's an easy way to do this (shift each byte via >> one at a time, which is guaranteed to get the most significant byte correctly). It's a pain the ass, but at least you don't have to worry about the emulated data set, that can be just saved out in blobs. Or you could just say save states are not cross platform and not worry about it =)

-Frob

Reply 22 of 227, by ZenJu

User metadata
Rank Newbie
Rank
Newbie

> Or you could just say save states are not cross platform and not worry about it
Not only do I plan to not save across platform, I neither plan support accross dosbox sessions 😀 This saves me a lot of hassle. Cross-platform compliance probably is the least problem here. The main problem is that all the state I conveniently consider "const" (for one session) would need to be handled additonally. Luckily I don't need this feature anyway. Phew.

> For files, what I did previously was save some meta data related
Surprisingly in all my tests, the current total lack of handling open files, had no negative impact. This is nice, because I can focus on other things for now. But even if it causes problems (likely sooner or later) it shouldn't be too difficult to handle, especially with the great simplification of not supporting save states accross sessions.

> but I haven't picked apart DOSBox's approach on that
Neither have I (yet) 😉 If you have, drop me a note. But I have systematically analized big portions of the source code. Just uploaded my newest Beta version. It already satisfies all my needs I have for this feature. But I will still improve it further supporting people like me 2 years ago, desperately looking for such a feature when beating Prince of Persia 2 and Metal Mutant (in a cumbersome Dosbox VirtualPC combo).

https://sourceforge.net/projects/xbrz
https://freefilesync.org

Reply 25 of 227, by Neville

User metadata
Rank Oldbie
Rank
Oldbie

I have a small request for ZenJu. I've noticed you removed some of the options in the mapper to insert the load state / save state options. Could you put "Save screenshot" back? I use it all the time.

Reply 26 of 227, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator

Not only do I plan to not save across platform, I neither plan support accross dosbox sessions

I understand the reason for this but IMHO that limits the usefullness of this approach to save states, at least support across dosbox sessions is, for me, part of the reason to have save states. Games that have no save games at all and force you to play a game in one session are one reason 😀

Windows 3.1x guide for DOSBox
60 seconds guide to DOSBox
DOSBox SVN snapshot for macOS (10.4-11.x ppc/intel 32/64bit) notarized for gatekeeper

Reply 27 of 227, by ZenJu

User metadata
Rank Newbie
Rank
Newbie

>> Could you put "Save screenshot" back?
The dosbox build process isn't exactly simple. Therefore I did myself a favor and compiled without image/video capturing support. For the next version I'll include it again. Meanwhile I've learned about zlib/libpng craziness. I just say "ZLIB_WINAPI"

>> DOSBox is GPL
I'll release the code for the next version if this make people feel "more comfortable".

>> that limits the usefullness of this approach to save states
I think save states within a session are way better than no save states 😀 Save states across sessions is difficult for two reasons: 1. There is no guarantee that the virtual PC configuration did not change (e.g less ram, different sound/video card...) 2. There are a lot of pointer variables that represent "the state". Luckily most of them are stable for one session, but they are dynamically generated, so they cannot simply be copied. Latter would require some medium dosbox redesign. But anyway I'd argue that most games that do not offer ingame save game support are short 😉

https://sourceforge.net/projects/xbrz
https://freefilesync.org

Reply 28 of 227, by collector

User metadata
Rank l33t
Rank
l33t

Couldn't some of the DOSBox settings just be saved by adapting -writeconf ?

The Sierra Help Pages -- New Sierra Game Installers -- Sierra Game Patches -- New Non-Sierra Game Installers

Reply 29 of 227, by ZenJu

User metadata
Rank Newbie
Rank
Newbie

Just uploaded Beta 4 including sources. Biggest issue remaining is restoring Video mode: Video and frontend renderer are tightly coupled which makes former difficult to restore.

https://sourceforge.net/projects/xbrz
https://freefilesync.org

Reply 31 of 227, by canadacow

User metadata
Rank Member
Rank
Member
wd wrote:

Also would have preferred if the OP had contacted somebody before making
something like that public.

A little late to the party but wd, welcome to open source. The OP could have just as easily forked DOSBox while releasing the source code and (s)he'd be well within their rights. The GPL says nothing about being required to contact the original owners when making significant contributions to the codebase.

Reply 33 of 227, by frobme

User metadata
Rank Member
Rank
Member

The OP could have just as easily forked DOSBox while releasing the source code and (s)he'd be well within their rights.

Well...sure, but that doesn't mean you should. I can wear a t-shirt around with swastika on it (well, except in Germany) legally but that doesn't really make it a sensible thing to do.

I think it's great that Zenju is taking a pass at this, I really do. But as implemented it probably falls short of Dosbox's service goals - it's only usable in session, it isn't cross platform friendly, and it's apparently not working consistently. I'm pretty sure those are the sort of things that wd would like to talk to somebody about on something like this - not required, just like.

Now people will ask even more for save states "since it works", but in truth some of the really tough problems of it aren't being solved here. So wd and crew get that to deal with in addition to all their other refinements.

Anyway, again I'm not trying to detract from what Zenju is up to - I applaud his effort and thank him for sharing it (in source code, eventually =) ). But any time you are working in a code base that somebody else has years into and you are just starting to touch it, open source or not it makes sense to try to understand the whys and hows of a feature not being already present, and to do your best not to present any new problems to the folks who carry the ultimate publishing responsibility. It's just common sense.

-Frob

Reply 34 of 227, by wd

User metadata
Rank DOSBox Author
Rank
DOSBox Author

The GPL says nothing about being required to contact the original owners when making significant contributions to the codebase.

So re-read what i wrote. I said it would have been NICE if he had done
that to talk to him about what he did/is going to do. But yes of course
everybody can spread source forks as well as (if nobody is sueing him)
binary forks, great idea.

Reply 35 of 227, by al3xmeister

User metadata
Rank Newbie
Rank
Newbie

great project and everything, congrats on it, just one tiny problem that's causing me a huge headache:
whenever I save/load, everything works fine, but at some points the screen becomes static and there is nothing I can do to continue the game. It's pretty frustrating, because you can't go this point, or beyond, or anything for that matter, except to restart. Isn't there anything that can be done to save multiple times, not just quick save/quick load?
or if the final release is due to come these days/weeks, please tell, it would be really nice

P.S., the game I was talking about is shadow knights, pretty annoying, I need to finish it soon

Reply 39 of 227, by ZenJu

User metadata
Rank Newbie
Rank
Newbie

> it's apparently not working consistently
My goal is to offer save and load at least within a game (I am not yet sure how to handle changing video modes). And I'm positive I can provide a consistent implementation on this 😉 At least for me this fulfills everything I need from such a feature.

https://sourceforge.net/projects/xbrz
https://freefilesync.org