Reply 20 of 227, by ZenJu
- 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.
> 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.
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
> 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).
You do know DOSBox is GPL, right? Binaries released to the wild without source is a no no.
I hope you feel important for mentioning this. Do you happen to have anything constructive you can contribute?
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.
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 😀
>> 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 😉
Couldn't some of the DOSBox settings just be saved by adapting -writeconf ?
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.
One more beta before going to bed: v5 - Fixed a problem that occassionally caused the video card to hang after loading a state.
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.
Addict: "I hope you feel important for mentioning this. Do you happen to have anything constructive you can contribute?"
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
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.
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
If you only need it for finishing Shadow Knights, try cheating by pressing C + T + Enter and C + T + Spacebar 😀.
well yeah, it works and technically it's not cheating since I've already reached those levels
But what about other dos games like volfied?
>screen becomes static
Did you try with Beta 5? This is exactly the problem that is supposed to be fixed.
> 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.