Save State Support For DDPDFK and other "cv1k" games

[neurodiverseEsoteric]

Hi, What would it take to write in code to allow games that run thanks to https://github.com/mamedev/mame/blob/59f6afab3f0379ef71868b16086162bbc5e654a4/src/mame/drivers/cv1k.cpp to have save states? I'm willing to take a stab at it on my own, but my programming experience is mostly making plug-ins for Autodesk Maya and SideFX's Houdini, mostly by copy-pasting their templates and other samples of code from the internet, and I'm hoping a project such as the one I'm proposing will be no different...

[MooglyGuy]

For openers, you'll need to at least somewhat familiarize yourself with C++. Not too much of the nitty-gritty stuff, but it'll be necessary to at least browse the source tree without wincing.

What you'll need to do is ensure that all of the state affecting the CV1K games is saved via a call to save_item or save_pointer, for all of the devices associated with that driver. The best thing you can do to learn how to do this is to look at other drivers that have the MACHINE_SUPPORTS_SAVE flag set in their driver instantiations at the bottom of a given file in src/mame/drivers/*.

The relevant calls to save_item or save_pointer must be placed in the relevant machine_start(), driver_start() or device_start() calls, depending on the situation.

It's a relatively straightforward task, but one that will require care in order to ensure that all of the necessary bits of data are saved, so that things don't go awry when a given save state is loaded.

[neurodiverseEsoteric]

Thanks! I was looking at the pmg driver already, and it did look straightforward, but that got me suspicious...I'm not sure what the directory structure of the source tree has to do with C++, unless you mean the hierarchy of the code itself, in which case I saw a lot of that from the SDK manuals of Maya, Houdini, and source code with Doxygen support added. That just means there's a particular order of inheritance and associations between the code ("#include all the things; namespace whatever; class this: public that"), right? It is the data part itself, that's the most concerning for me, as that involves the scary world of memory addresses and directly using them. I still haven't found out how one can tell, whenever a memory error presents itself, whether or not the cause is from the code, or the actual hardware itself (and mine is pretty old—and was bought that way via Craigslist—and taken a few hits and scratches through the years, but so far the only failures have been limited to certain usb and other ports, which I just taped over theose and connected things via pci cards instead)...

[ghost]

the blit delay code / threading code probably isn't really compatible with save states (as it isn't even threadsafe, and IIRC is the main reason I don't claim to support states) so that might need to be removed

[neurodiverseEsoteric]

Oooh...there isn't a way to write a threadsafe blittner delay? Or did you mean that save sates aren't thread safe? And does thread safety matter? Could an unsafe thread destroy an entire hard drive, or motherboard?