* 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
This change is more convenient at the cost of a little duplicate code in
ToolManager. The annotation is [ExternalToolEntryPointForm], and having no more
than one such class per assembly is enforced.
This doesn't compile because of Input.cs, didn't know what to do. Also search for Merge TODO for some commenting things that probably need to be deleted
# Conflicts:
# BizHawk.Client.EmuHawk/BizHawk.Client.EmuHawk.csproj
# BizHawk.Client.EmuHawk/CustomControls/InputRoll.Drawing.cs
# BizHawk.Client.EmuHawk/CustomControls/InputRoll/InputRoll.cs
# BizHawk.Client.EmuHawk/Program.cs
# BizHawk.Client.EmuHawk/tools/Lua/LuaConsole.cs
# BizHawk.Client.EmuHawk/tools/TAStudio/TAStudio.cs
# BizHawk.Client.EmuHawk/tools/ToolHelpers.cs
# BizHawk.Client.EmuHawk/tools/ToolManager.cs
# BizHawk.Client.EmuHawk/tools/TraceLogger.Designer.cs
# BizHawk.Client.EmuHawk/tools/TraceLogger.cs
# BizHawk.Client.EmuHawk/tools/Watch/RamSearch.Designer.cs
# BizHawk.Client.EmuHawk/tools/Watch/RamSearch.cs
# BizHawk.Common/BizInvoke/DynamicLibraryImportResolver.cs
* 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
SuuperW