* create ITasMovie interface, still lots of todos
* interface for TasMovie.ChangeLog
* rename method
* interface more TasMovie things
* file rename
* interface more ITasMovie things
* make Bk2Movie and TasMovie internal, rely on interfaces for behavior and MovieService for instantiation
* MovieService cleanup
* cleanup TasBranch handling and simplify ITasMovie api
* more branch logic cleanup and ITasMovie simplificaiton
* more cleanup of branch handling
* more ITasMovie simplification
* nitpick cleanup
* Use IMovie.GetInputLogEntry instead of GetLogEntries
* more ITasMovie cleanup
* move come ITasMovie properties to TasBranchCollection
* TasMovie cleanup
* simplify ITasMovie more
* cleanup
Note that this was actually not very difficult, compared to dealing with the client sizing logic, which was teetering on the brink of total collapse. I may have messed something up while trying to support it here (mainly related to emu-space and client-space padding). There were many assumptions that the core's videoProvider would remain sensible, which this "core screen control" system subverts. The padding and sizing was added after I designed the pipeline specifically for this, so the padding and sizing is not handling it very well. Nonetheless, I think it works.
* Add MelonDS.cs, support opening (but not really) .nds files.
* init MelonDS
* MelonDS: Load selected ROM.
* MelonDS: FrameAdvance and frame counter.
* MelonDS: IVideoProvider
* MelonDS: Add DLL files.
* MelonDS: IInputPollable
* MelonDS: IStatable (and add forgotten file MelonDS_InputPollable.cs)
* update libmelonDS.dll
* MelonDS: ISoundProvider
* Add NDS to Global.SystemInfo, and convert screen coords when running NDS.
* set up default NDS controller
* MelonDS: ISaveRam
* MelonDS: remove romlist.bin
* MelonDS: ISettable
* Create firmware folder if it doesn't exist on Windows; otherwise, an exception is thrown.
* Add database entries for NDS bios/firmware files.
* MelonDS: Use the bios/firmware files selected in BizHawk's "Firmwares" dialog.
* MelonDS: Re-work sync settings a bit.
* NDS's firmware file contains user settings; these are over-written by sync settings, so we shouldn't allow them to impact the hash
* MelonDS: Add (currently unused) bootToFirmware sync setting, and NDSSettings dialog.
* Update NDS firmware hash; it seems I had somehow corrupted mine.
* MelonDS: Use boot to firmware sync setting.
* MelonDS: Allow user to set some firmware user settings via the NDS settings dialog.
* MelonDS: Add singleInstance attribute to core.
* MelonDS: IMemoryDomains
* update libmelonDS.dll
* MelonDS: Set up default sync settings if none are provided.
* MelonDS: Allow user to reset settings to default.
* MelonDS: bios+firmware files are recommended
* libmelonDS.dll
* MelonDS: Don't use real time.
* MelonDS: Update to reflect new way of handling RTC in MelonDS.
* MelonDS: Notify if savestate load failed.
* update MelonDS.dll
* MelonDS: Allow user to set startup date/time in settings dialog.
* MelonDS: Create melon directory if it doesn't already exist.
* Don't include Designer's "fixes" in PR (partially reverts 56b474c00)
* Don't show a broken console window; alert user of need to restart instead.
This fixes an error related to MelonDS trying to use the broken stdout stream.
* update default NDS controls to match other updated controls
* Implement a system bus, using ARM9 read/writes.
* MelonDS: Allow BizHawk to change the contents of the frame buffer.
* update libmelonDS.dll
* fix stuff that was merged incorrectly, or was broken by merge
* update libmelonDS.dll
(includes memory leak fix)
* update libmelonDS.dll
(fixes memory leak and an occasional savestate crash)
* fix stuff that broke with the merge
* cleanups, remove stuff that is no longer needed by service interaces
* simplify DS MemoryDomains
* DS - fix order of controller buttons to be consistent with other consoles. This probably breaks any existing movies made on this core, but those would have been experiments, right?
* NDSSettings - make min value for day and month 0, whiel those aren't "valid" values they are the default values in the core for whatever reason, better to not crash on load and not show a value that isn't actually the setting. This can easily be reverted if the core changes to default to 1
Co-authored-by: YoshiRulz <OSSYoshiRulz@gmail.com>
Co-authored-by: adelikat <adelikat@tasvideos.org>
* move one usage of Firwmare method into Firmware config where it is better suited
* PathManager - remove unused code
* move some PathEntry specific logic out of PathManger and into PathEntryCollection extension methods
* PathManager - detangle some exe pathing logic from Global.Config usage, clarify what a completely broken method should actuall do
* move more logic from PathManager to PathEntryCollection extension method
* move absolute path creation to PathEntryCollection, lots of refactoring and simplifying of PathEntries usage
* simplify PathEntryColleciton usage more
* simplify PathEntryCollection more
* break PathEntry classes into separate files, a bit of cleanup
* move Rom path logic out of PathManager into PathEntryCollectionExtensions
* move config UseRecentForRoms and LastRomPath into PathEntries, note that this is a breaking change for previous configs, those values will revert back to default values
* move SaveRamPath logic from PathManager to PathEntryCollections
* move cheats path logic from PathManager to PathEntryCollection
* move another method out of PathManager
* move some Retro hacks to PathEntryCollections, exposes more implicit dependencies
* move savestate logic out of PathManager to PathEntryCollection
* move more logic out of PathManager
* move some savestate logic out of PathManager, move most to MainForm where it is used, detangle some implicit dependencies from SaveSlotManager
* rename method
* move more logic from PathManager to PathCollectionEntry
* movie final Global.Config.PathEntries logic out of PathManager and into PathEnties
adelikat