VOGONS

Common searches


Save States - Proof of concept

Topic actions

First post, by ZenJu

User metadata
Rank Newbie
Rank
Newbie

Hi,

general support for save states would be an awesome feature. Currently there doesn't seem to be a timeline when this feature will be in the official release. As I can't wait that long (there are a couple of die-hard dosgames without ingame save support I need to finish since the 90s) I gave it a shot at my own solution: Yesterday evening I downloaded the sources and made it compile. I'll spare you the details of my little "compiling adventure", but just present you a first "working" version in the attachment.

It's based on the latest official Dosbox sources 0.74.

Default Keyboard bindings: (I suggest using the keyboard mapper CTRL+F1 to reassign them to something more convenient)

Left ALT + F5 -> Save state
Left ALT + F9 -> Load state

I've tested with a couple of games and my success rate surprisingly already was about 70%! (Doom, Keen, Bio Menace were working fine.)

Note however that I have no detailed knowledge about Dosbox in general. Actually I know the sourcecode for one day by now. Therefore it is possible that I have missed something. This first version should be seen as a proof of concept for now. I mean: don't blame me if it's not working for every game 😉 I'm going to further revise it.

PS: If someone is interested I'll release the sourcecode at some time. My implementation strategy can be easily expanded. In the hands of a *real* dosbox developer, this save state feature may turn out to be easier than expected.

Best regards, ZenJu

Update 2012-12-15: PPS: Here's a link to a further enhanced version of DOSBox with save states and xBRZ high quality image filter:
link

Last edited by ZenJu on 2015-01-11, 20:24. Edited 14 times in total.

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

Reply 1 of 227, by Calvero

User metadata
Rank Member
Rank
Member

Thanks, I finally made it past the swinging rope in level 2 of The Jetsons: By George, in Trouble Again. It's a game without ingame save support and I just need to finish it since the 90s 😀.

Reply 2 of 227, by ripsaw8080

User metadata
Rank DOSBox Author
Rank
DOSBox Author
ZenJu wrote:

without ingame save support I need to finish since the 90s

Calvero wrote:

without ingame save support and I just need to finish it since the 90s

Just a coincidence that both use the same turn of phrase?

Reply 3 of 227, by ripa

User metadata
Rank Oldbie
Rank
Oldbie

Cool! Worked in Duke Nukem 2, Keen 5, Supaplex (woohoo!), Prince 1 and Prince 2. Some observations: in Nukem2, it got stuck when loading a savestace once. Also, the graphics palette isn't restored, so for example in Supaplex if you save in a level and load when in the blue "you failed" screen, the graphics are corrupted. Also, the bottom menu is corrupted if you load when you're in the main menu (but it's easy to restore by pressing enter twice).

In Prince 1 and 2 sometimes after loading the game speed is changed. For example, I saved in Prince1 during the level and loaded when the prince goes up the stairs to the next level. The game speed was very fast until I drank a potion. In Prince 2 on the other hand, the game played very slow after loading (didn't happen very often though and game speed restored after the music looped from end to beginning). Also, in Prince2 after I'd loaded a game and I finished a level, it didn't advance to the cutscene until I paused the game and resumed it (esc is pause). Also, palette bug in Prince2 also (palette gets fixed when you advance to the next screen).

Thumbs up for this patch regardless!

Reply 5 of 227, by ADDiCT

User metadata
Rank Oldbie
Rank
Oldbie

Very interesting. Keep up the good work, I'm pretty sure lots of people will find this patch useful. Maybe you can even convince Mr. "No Savestates, Ever!" wd that savestates are feasible for mainline DOSBox (; .

Reply 6 of 227, by ZenJu

User metadata
Rank Newbie
Rank
Newbie

> game speed is changed
Yes I've noticed that too (on Arkanoid)

Currently I'm saving complete RAM, CPU Register, Segment pointer, Video Ram, Flags and Paging. I haven't yet systematically analyzed the sourcecode, but merely saved the minimum parts I figured that represent a "state". So there definitively is room for improvement.
I guess one part which makes an official save state feature harder is that there is potentially quite a lot that can go wrong, most notably if persistent state is not in sync with the save state. This is a problem that doesn't occur e.g. with ZSNES where there is no such dependency.
Luckily this isn't a problem with "small and simple games".

PS: Just finished Arkanoid 😉 I remember never going further than level 8. Now I beat all 32 ones.

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

Reply 7 of 227, by frobme

User metadata
Rank Member
Rank
Member

Currently I'm saving complete RAM, CPU Register, Segment pointer, Video Ram, Flags and Paging.

Awesome, great to see somebody talking this.

Are you saving the framebuffer along with video RAM?

You would probably need to save some meta data associated with Dosbox itself, for instance the CPU emulation type.

Various sound cards have some small buffers as well...I imagine for some games that might be important.

-Frob

Reply 8 of 227, by Kippesoep

User metadata
Rank Oldbie
Rank
Oldbie

Another biggie is open files. This is also one of the toughest, since you must maintain a list of mountings, current directory, names of files that are open, with the correct file handle, I/O buffer and file pointer. To do it right, there should even be a check whether any open file has not been altered since saving state (and basically refuse to restore state in case it was altered).

My site: Ramblings on mostly tech stuff.

Reply 10 of 227, by Xelasarg

User metadata
Rank Member
Rank
Member

Amazing 😁

I can confirm this feature working in Wing Commander, Links386 and Strike Commander.

Still buggy in some games, but after all, it's a beta version.

Great work!

"What's a paladin?!"

Reply 11 of 227, by ADDiCT

User metadata
Rank Oldbie
Rank
Oldbie

Ah, glad this has been reopened.

wd: my mistake. I had a vague memory of someone writing that savestates would be impossible to do in DOSBox and i thought it was you. I've searched through the relevant posts but couldn't find a comment like that from you, so my memory probably failed me. I would've appreciated a different wording in your reply though. "Silly" maybe. (;

Anyway, I hope this patch gets the attention it deserves. The feature has been asked for many times (actually so many times that threads about it got closed immediately in the past), so I guess a fully working implementation of this functionality would be a great step forwards for DOSBox.

Reply 12 of 227, by wd

User metadata
Rank DOSBox Author
Rank
DOSBox Author

wd: my mistake. I had a vague memory of someone writing that savestates would be impossible to do in DOSBox and i thought it was you. I've searched through the relevant posts but couldn't find a comment like that from you, so my memory probably failed me. I would've appreciated a different wording in your reply though. "Silly" maybe. (;

I doubt anybody said it was impossible, there has already been done a lot
of work to make things more straightforward (which the OP possibly benefits of)
but the main points like reentrant machine calls and general file handling are
still open.
Also would have preferred if the OP had contacted somebody before making
something like that public.

Reply 13 of 227, by eL_PuSHeR

User metadata
Rank l33t++
Rank
l33t++

Someone suggested to move this thread to the DOSBox Development Section. Is it publicly accessable?

Intel i7 5960X
Gigabye GA-X99-Gaming 5
8 GB DDR4 (2100)
8 GB GeForce GTX 1070 G1 Gaming (Gigabyte)

Reply 14 of 227, by ZenJu

User metadata
Rank Newbie
Rank
Newbie

> stuck when loading a savestace
I had the same issue with Turrican 2. After I added the keyboard state it worked fine. Maybe this was the issue in this case too. Problems in Tyrian2k were fixed by adding IRQ and PIC states.

> sometimes after loading the game speed is changed
Added the timer to the save state. Didn't face this issue anymore. Hopefully fixed.

> graphics palette isn't restored
Still open. But doesn't seem to be a big problem (=crash) as long as video mode isn't changed.

> Are you saving the framebuffer along with video RAM?
I'm just saving the RAM currently. There is a lot of state related to Video. I'm not entirely sure what is really needed.

> Another biggie is open files.
> You would probably need to save some meta data associated with Dosbox itself, for instance the CPU emulation type.
Hm, my approach is to restrict saving state only to parts that belong to the emulated computer. My naive(?) expectation is that the Dosbox framework does not depend on the current state (whatever that exactly is, I'm still finding out...) of the virtual computer. If this is true, I needn't worry about open files or other issues external to the virt. computer. This is probably where you tell me that my assumption is not correct 😉

> Various sound cards have some small buffers as well...I imagine for some games that might be important.
Not sure if it's important to include this into the save state. Worst that can happen is a short sound distortion???

I've uploaded Beta 2: It is much more stable now. I think it already is a quite useful tool to finish some of the really hard games. But it is no 100% solution. But this isn't exactly what I'm after. Although I'm usually the perfectionist type, in this case my approach is VERY pragmatic 😉 It's fun.

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

Reply 16 of 227, by IIGS_User

User metadata
Rank Oldbie
Rank
Oldbie
ZenJu wrote:

> graphics palette isn't restored
Still open. But doesn't seem to be a big problem (=crash) as long as video mode isn't changed.

May save the video mode setting along, overwriting the current setting (at start of db) or displaying a warning msg if not match with current setting, if the save state will be opened while db is already running.

ZenJu wrote:

> Are you saving the framebuffer along with video RAM?
I'm just saving the RAM currently. There is a lot of state related to Video. I'm not entirely sure what is really needed.

All what possible. 😉

Klimawandel.

Reply 17 of 227, by VisitntX

User metadata
Rank Member
Rank
Member

I have a question, I made a savestate using the game "Avoid the noid" and it worked perfectly, but when I closed the dosbox and reopen it, when I wanted to load the savestate would not let me.
What is the problem?

Reply 18 of 227, by Xelasarg

User metadata
Rank Member
Rank
Member

As far as I see (by looking to all directories that seem relevant to me), no image/savestate file is actually stored on the hard drive. I guess all the saved data is stored in memory and therefore lost when you quit DOSBox.

@ZenJu:
Another (probably dumb) question: wouldn't it be possible to just store everything that's currently in DOSBox's emulated memory? So that if you set memsize=8, the save file would have exactly that size, i.e. 8 MB.

"What's a paladin?!"

Reply 19 of 227, by ZenJu

User metadata
Rank Newbie
Rank
Newbie

> I closed the dosbox and reopened[...] load the savestate would not let me.
The save state is not written to disk, therefore it is lost when you exit dosbox. Implementing this feature would be trivial. But it seems kind of risky to keep a state over a longer period of time. Right now I do not yet save everything that "represents" the emulated computer, most importantly the (complete) video state. Therefore it think it's too early to allow saving and loading across dosbox sessions.
But perhaps I should be brave and give it a try 😀

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