* Retarget BizHawk.Emulation.* to .NET Standard 2.0
* Retarget BizHawk.Bizware.BizwareGL to .NET Standard 2.0
In practice this mostly involves moving classes to BizHawk.Client.EmuHawk.
* create StateSerializer, an ITextStatable implementation using the Serializer class, and wire it up to the TI83 core
* wire StateSerializer to A2600 core
* wire up StateSerializer to AmstradCPC, C64, and ZXS
* wire up StateSerializer to MSX, A27800, and Coleco
* wire up state serializer to ChannelF, Vectrex, Intellivision
* fix GambatteLink to implement ITextStatable, implement TextSerializer in O2
* StateSerializer - wire up a loadstate callback and implement StateSerializer for NesHawk, a bit of rework to subNesHawk as a result
* fix subneshawk text savestates
* StateSerializer - implement byte[] buffer storing (optionally), wire up to PCE
* implement StateSerializer to SMS, tweak GGLink accordingly
* implement StateSerializer in GBHawk, fix link cores accordingly
* StateSerializer - use Serializer static methods to create serializers
* Rewind & State config - remove the default option
* remove the savestate type of default, not that this is a breaking config change for anyone that had specifically set savestates to text
* remove BinaryStatesPreferred from IStatable and use config setting when starting movies from "Now" in record movie dialog
* remove BinaryStatesPreferred from cores
* make text savestates an extension method off of IStatable and an inteface ITextStatable it uses if the core implements it. This will allow cores to opt in to text states if desired
* make cores with actual text savestate impleemntations get ITextStatable, remove text state logic from cores that just have a binary as as text implementation
* add MAME to OpenAdvanced
* make mame launch games
limited to arcades that only need rom name. other devices require machine name and rom name, and won't run. nor they are meant to be supported anyway: we have enough emulators that do the job better for particular devices.
dunno if direct disk access will be avoidable, there are quite some files it might want to load other than the rom (parent rom, bios, artwork). trapping all of these might be a future task.
it is also known that mame can load "romname.zip" file just as well as "romname" folder, which would represent an unarchived zip. I make use of it to send it zip name with extension. it's easy, and we're not obliged to recognize mere folder paths in the mame-advanced-loader logic.
* ability to run lua code inside mame
adelikat