-
Notifications
You must be signed in to change notification settings - Fork 80
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
State save #71
base: master
Are you sure you want to change the base?
State save #71
Conversation
I'm going to try a slightly simpler approach today (on the kc85 emulator), basically just copying out the nested state struct. Any pointers to external data would be patched in after loading back such a snapshot. Basically:
Of course this has a couple of downsides, the snapshots will be fairly useless for 'distribution', because they're very 'volatile' (depending on the exact struct memory layout and endianess), but I'm seeing them mainly as a debug aid (to capture a state and later rewind to it). As for compression and attaching additional meta data (like a screenshot), I'm planning to do this outside the system emulation in the wrapper application, and using a small zip library (like https://github.com/richgel999/miniz) to compress/decompress (because some snapshots, like the KC85 with its expansion system) can get pretty big, but when not used, will mostly be zeroed). I'm currently also doing a little API overhaul, and I have added a new way how emulators write their video output (instead of RGBA8 pixels, they provide a fixed RGBA8 palette with up to 256 entries, and the video output is one byte per pixel as index into the palette, this reduces memory accesses, memory bandwidth, and allows to move the 'palette resolution' to a pixel shader (while still being trivial to resolve on the CPU). The only current emulator that can't use this solution is Bombjack, because that uses a variable palette of RGB4 colors - but Bombjack will simply continue to use the current approach of writing out RGBA8 pixels. This stuff is all in a branch currently ('code-cleanup-1'). |
You could add a simple version number to the snapshot, but that makes deserialization a bit more complicated ofc. I thought about just reading and writing the structures contents as I don't really need If you decide not to merge this PR in the end it's ok, I'll just use your implementation :) |
Ah right, I missed the part that this is a standard snapshot format. Yep that definitely makes sense (in addition to the 'non-standard' snapshot format I'm currently implementing which will only be useful for debugging, but has the advantage that it captures the entire chips-emulator specific state down to the last bit) |
Now that you put it that way, I believe I'll be using your snapshot instead of I still believe |
This PR implements state saving, both compressed and uncompressed, and implements loading of uncompressed states.