user will be changing those options from hawk side dialog so it's impossible to miss what you're changing (you can look at the dialog again if you're THAT sloppy)
but since we're now initializing with default nonsync settings and changing them on the fly, those UI messages would be appearing all the time
automap messages are left intact since they appear upon in-game button press
worst case scenario, UI messages are moved to hawk side, but then why limit them to only whatever upstream reports and not report every change? which is never done anyway, so I doubt it'd come to this
passing rngseed didn't fix sync, and passing all the settings is too much work for this release. will support it afterwards.
instead just tell the user BOOM demos are not supported
there's a major slowdown when doing several res changes in the same session, and its need is questionable anyway, because of potential inconsistency of screensize across states and stuff.
* Adding dosbox
* Adding placeholder
* Adding initial placeholder for DOSBox
* update
* Update
* Update
* progress
* Progress
* Increasing mem capacity
* Progress
* Now running timer correctly
* Progress
* Stable
* Parsin inputs
* Keyboard working
* stable before using memfiles
* Now accepting rw hdds
* Hard disk rw working
* Fixing conflict
* Getting samples
* Reading samples but sounds too low
* Reading samples but sounds too low
* Now accepting multiple cdrom/floppy images
* Allowing swapping
* Enabling cdrom and disk swapping
* Simplifying
* Simplifying
* Simplifications
* Simplfiications
* Capturing sdl delay
* Adding configuration presets
* Enabling joystick
* Enabling joysticks
* Added mouse support
* Adding mouse support
* Progress with hard disk
* Adding default hard disk images and making them selectable
* Adding mnemonics, more configs, and some refactoring on the standard confs
* Processing file extensions
* Adding sram
* Adding saveram
* Adding drive lights
* Adding drive lights
* Adding memory domains
* Removing warnings
* Fixing warning
* Revert unrelated changes to Multi-Disk Bundler
* Re-alphabetise lists and clean up diff
* Missed a bit
* Make `DOSBox`' `ISaveRam` implementations `override`
* Fix `DOSBox`' `[PortedCore]`
* Clean up string comparisons in `DOSBox` ctor
* Set values for `WriteableHardDiskOptions` instead of translating
* Clean up reading of DOSBox config presets from embedded resources
* Fix code style warning
* Removing duped line
* Fixing extension parsing
* Small adjustments
* Aligning fps to that of normal DOS
* Aligning fps to that of normal DOS
* Simplified extension getting and adding base config file resource
* Remove unused import
* Properly measuring extended mem size
* Adding more settings and simplifying machine presets
* Adding check for SRAM size to prevent wrong-sized HD being loaded
* Removing unnecessary directive
* Update correct DOS framerate
* Adding sensible configuration presets
* Adding to the config preset description text
* Update src/BizHawk.Emulation.Common/Base Implementations/Bk2MnemonicLookup.cs
Co-authored-by: feos <vadosnaprimer@users.noreply.github.com>
* Removing stale config files
* Fixed mouse emulation
* Fixed mouse emulation
* Removing unused keyboard flag
* Addressing feos' comment about virtual height/width
* Fixed bug with saveram
* fix VirtualWidth
scanlines remain constant so they aren't stretched, and width is adjusted to be 4/3 of height, because video modes in DOS were designed for a 4:3 monitor. exact pixel shapes may slightly differ depending on exact pixel clock but setting 4:3 for DOS is standard.
* DependentUpon
* Making FPS configurable
* Making FPS configurable
* Adding fps num/denom
* Implementing proper fps numerator / denominator defaults for DOS
* Passing mouse deltas from bk
* Passing mouse deltas from bk to the core
* expose and use deltas directly
to make it work in hawk, one needs to bind RMouse X/Y for Mouse X/Y Delta in config.ini, by manually editing the file (for now)
* Implementing support for .cue+.bin and other cdrom types
* Fixing sensitivity
* Adjusting mouse sensitivity
* Fixing integration for windows
* [WIP] loading cds from bk
* [WIP] loading cds from bk
* Using .cdrom extension for cdroms, and passing disk name to the read callback
* Using .cdrom extension for cdroms, and passing disk name to the read callback
* Cleanup and fixing .iso loading and swapping
* Fixing .iso loading and cdrom swapping
* Adding default controllers
* Added callback for video updates to prevent tearing
* Removing unnecessary message
* Fix line endings in `Bk2MnemonicLookup.cs`
* Fix indentation
* Fix misc. whitespace crimes
* Drop redundant `<None Remove/>`
* More whitespace fixes
* More code style fixes
* Small fixes
* Fixing misc comments
* Adjusting naming
* Fixing values
* Removing dead code
* Clarifying the source of DOS framerate chosen
* Removing unused variable
* Removing duped assignments
* Fixing typo
* Removing no-longer required SRAM management
* Removing no longer required sram management functions
* Removing no-longer needed SRAM logic
* Fixing framerates as per feos's comment
* Passing init struct for a more tidy initialization. Also fixing identation for good
* Fixing hard landing on failure to load SRAM. This is needed to prevent crashes in dosbox when preserving hard disk contents
* Added missing submodule and artifact
* Reverting unnecessary change
* Removing no longer needd dosbox-iso extensions
* Removing no-longer necessary virtuals
* fix
* Adding lines into readme
* fixing indentation
* Reducing job concurrency for dosbox -- otherwise the server gets overloaded
* adding recursive submodule for dosbox-x
* Simplifying
* Simplifying
* Simplifying
* Simplifying
* Only offer drive switching if more than one drive is present
* Adding proper Disc identification for ISO9660 / Joliet (default target DOS)
* Adding CDROM case
* Moving comments to proper place
* Moving comments to proper place
* Code style fixes
* Clean up handling of Next Disc buttons
* Clean up `DOSBoxKeyboard` definition
* Remove redundant button mnemonic overrides
* remove leftover hack from my initial 2-byte range
it's hard to tell from upstream code what the range should be...
* Fixing mouse buttons getting stuck and aligning mouse speed minmaxes to what dosbox expects
* Removing default framerate for DOS
* set mouse speed range to match raw deltas range
(see 93bc50288f)
since this makes minimal mouse delta 1 now instead of 2 or 3 (they were different for x and y because ranges were different), I readjusted default sensitivity to match default turning in doom in upsteam
* fix casing on public fields
we use PublicField, _privateField, and localVariable casing
this commit also includes WIP to expose attoseconds like mame does, so that 1 value could be used to determine framerate, and movie parsers won't need too many changes to support DOS framerates
* fix num/denom values to match dosbox-x for when it launches into dos
video dump info was not super clear so I relied on values that are actually assigned to `fps` in `VGA_SetupDrawing()`
TODO: check other machines, update sync settings descriptions when we expose render fps info to user
* use an existing thing instead of GetFullName
it was copied from uae where I made it because I didn't know about `Path.GetFileName(rom.RomPath)`, it's now fixed in master too
increased message duration so user could read potentially long filenames (copied from uae too)
* Move init of new `MouseState` to top and eliminate locals
* fix naming for mouse states
* update submodules
* Adding function to get video refresh rate
* Adding report on video refresh rate update
* Revert "Merge branch 'dosbox' of github.com:SergioMartin86/BizHawk into dosbox"
This reverts commit e5b16a6307, reversing
changes made to ced12c51b4.
* Merge branch 'dosbox' of github.com:SergioMartin86/BizHawk into dosbox
* Removing unnecessary directive
* Fixing reboot
* fps notice formatting
* Zero init fps vals
* Using variable framerates
* Now accepting variable framerates as given by the core
* Moving ISO9660 detection lower
* Storing refresh rate in savestate -- update it on load if different
* fix GetFullName()
* Adding function to get number of ran cycles
* Adding ICycleTiming
* attoseconds are obsolete now
* fix loading CDs with spaces in their name
* Message duration needs to be left to the user to configure. Just passing a null
* Setting notify times back to 4 seconds cause these require a bit more time to read/understand
* Updating CycleCount from within wbx
* Simplifying cycle timing
* Removing FPS change notification, using default waiting times
* Updating submodule
* Fixing bug in disc swapping
* Adding drive selection functionality
* fixing period input
* Adding logic to present disc swapping operations from repeating when holding the button
* added defines for drive id
* point submodule to specific branch
---------
Co-authored-by: YoshiRulz <OSSYoshiRulz+git@gmail.com>
Co-authored-by: feos <vadosnaprimer@users.noreply.github.com>
Co-authored-by: feos <feykomylce@gmail.com>
* fix on_bus_read issue for genplus-gx core
- related to issue #3813
- update signatures, create new value variable in each of the memory read core functions, pass it to the callback and return it instead of the inline calculations. Also, pass val to write and exec callbacks in IDebuggable since they all use the same mem_cb signature and it would break otherwise. I want to update write and exec callbacks in next commit though to ensure nothing unexpected happens.
* update write callbacks for genplus-gx
- related to issue #3813
* update exec callbacks for genplus-gx
- closes#3813
* twice memory peek for deep freeze via on_bus_read bizhawk
Read a first time to pass the read value to the callback, read a second time to read the updated value in case it was updated by the callback and effectively deep freeze the value, no matter if 8, 16 or 32 width
* remove lines from unknown source
I have no idea where those lines came from. But I never meant to add them. This should look like it currently looks in master
* reinsert const, use implicit delegate constructors
* update submodule commit to before override memory values
* rename a to addr, unsigned int to just unsigned
only doom1 uses episode number in -warp, all the rest ignore it and use the first digit to set map (episode is forced to 1 for them). to detect this we now ask the core which gamemode it is (which determines it internally too).
rename complevel setting
that way we don't have to rebuild the core for every commandline option that it already supports and we decide to use, also more meaningful presentation of those options on the managed side
fixes#4204
RANT TIME
visible area is largely nonsense when it comes to CRT TVs, because they may cover different amounts of the screen based on model, and you can adjust some of them also based on model to show more or less of it.
4:3 aspect ratio is also somewhat nonsense because TVs don't automatically rescale your video input to the entire screen like modern computers do. they just stretch or shrink it based on pixel frequency of the input and how it relates to whatever the given TV is configured to.
Rec601 was created in order to somewhat standardize this but it only contained RECOMMENDATIONS (hence the name) on how to digitize analog video, not how analog devices should be configured. so a lot of TVs looked different from what it would be digitized to based on this spec.
in gaming it's a common misconception that console output is meant to be resized to 4:3 DAR of the TV. in reality it's stretched according to PAR - pixel shape which comes from differences between color frequency of the input and standard NTSC or PAL color frequency.
if the console updates color more often than the standard, analog signal with higher pixel density will be put on the screen as is, and pixel will look "squished", sometimes up to 2x for 512px resolution modes (PS1). if the console updates color rarer, pixels will look stretched (A2600).
Amiga PAL mode has 1:1 PAR, no stretching is needed, so whatever aspect we're outputting will just go to encodes as is. NTSC Amiga PAR is 6:7, so we're shrinking a bit in encodes and when hawk is configured to device aspect.
this all means that it doesn't matter how many pixels we take of the rendered image, all we care about is stretching it to proper PAR. whether it contains overscan only affects fullscreen because extra blank area means less of useful data. and since some exceptional games decide to render AT THE VERY BOTTOM there's little to no harm in showing all 574 rendered scanlines. who hates it and wants 568 can crop it, but I don't expect anyone to care (or even notice).
so while nominal internal res for Amiga is 576 and canonical UAE default is 568 (tho it lets you adjust visible area and we don't), I think we can safely output our heretical number at all times.
feos