Visual preview of statesave

[GoogleCodeExporter]

Would be nice to have a graphical preview of a statesave before loading it
(using the load statesave from file menu option). This can probably be
implemented simply by capturing a screenshot right before taking the statesave.

Original issue reported on code.google.com by ebenbl...@gmail.com on 17 Apr 2008 at 9:46

[GoogleCodeExporter]

Original comment by ebenbl...@gmail.com on 17 Apr 2008 at 9:47

[GoogleCodeExporter]

I think this should be an option as this would make savestates approximately 1mb
bigger, however we what WE can do... is

cat screenshot.jpg savestate.st >> new_savestate.st

should work, and would work well

Original comment by sgorman07@gmail.com on 18 Apr 2008 at 4:37

[GoogleCodeExporter]

If you don't mind modifying the save state format (no reason not to I guess), I 
would
downscale the screenshot (I can give you code for a good filter in C which I 
wrote)
and store a reduced resolution version.  Maybe 80x60 or 160x120 depending upon 
the
size which will be displayed in the GUI.  The save file already contains the 
entire
RAM dump of the machine, which is 8MB.  An extra 50kb won't be much.

The most user-friendly way that I can see to implement this would be to do the
following:  the file format probably contains a major/minor version number, so 
for
the state saving code, increment the major version number (to signify 
mupen64plus and
leave room for the original mupen64 to advance at some future time).  Then in 
the
loading code, re-write it to handle either the old mupen64 state files or the 
newer
mupen64plus state files with the embedded image.

Original comment by richard...@gmail.com on 19 Apr 2008 at 2:47

[GoogleCodeExporter]

Isn't the N64 framebuffer already part of the state due to the UMA? If so, we 
just 
need to extract some data that's already in the file to the GUI.

Original comment by sknau...@wesleyan.edu on 19 Apr 2008 at 4:49

[GoogleCodeExporter]

The frame buffer is not written back to the N64's memory space; the video data 
is not
present in the 8MB ram image.  Getting the video data back to the core for 
saving
with the state is not as simple as I had previously imagined though.  There is
currently no path in the plugin API to transport the image data back to the 
core; it
can only command the plugin to save a screenshot.  In order to make this work 
without
extending the API, the core will have to be able to read the saved screenshot 
file
off of disk..  This will require adding a libpng dependency.  And proper error
handling for the cases where the screenshot wasn't written correctly.

Original comment by richard...@gmail.com on 19 Apr 2008 at 5:07

[GoogleCodeExporter]

If this feature will be included, I think the screenshot could be in a separate 
file
with the same name as the savestate file and coded in a png file.

Original comment by vini.ips...@gmail.com on 5 Mar 2009 at 9:58

[GoogleCodeExporter]

This enhancement request is invalid given the new architecture of Mupen64Plus.  
This
would be a good feature for a GUI front-end to implement, but on this issue 
tracker I
only want issue reports for the 6 new modules.

Original comment by richard...@gmail.com on 10 Jan 2010 at 7:21

• Changed state: WontFix