| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
| |
* Add new option speaker_report to report clipping and other statistics after each session. This replaces the previous compile-time define and offers more detail.
|
|
|
|
| |
vector games. (#6993)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit 74f456df945cd1720dc4d6bc105f64c13e62ced8.
I will allow the feature with the following conditions:
* No skipping red warnings.
* A key-value map of device shortnames and yellow warnings must be
stored in the .cfg file, along with a timestamp of the last time the
system was run and the last time a warning was shown.
* On starting a system, the map of device shortnames and yellow warnings
must be built and compared to the one loaded from the .cfg file. If it
doesn't match, if the system hasn't been started in seven days, or a
yellow warning hasn't been shown in 14 days, the warning is not to be
skipped.
|
| |
|
|
|
|
| |
setting was enabled (nw)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When this option is specified, all console output is echoed to a log
file.
Some caveats/limitations:
- The file-open process was copied from -log, so it has the same limits
- Filename is hard-coded (debug.log)
- File is overwritten if it exists
- File is opened during emulation initialization
- Thus, the file is cleared if you invoke the "Hard Reset"
debugger command
- Probably some other details I don't know about
- Logging works as such: When a string is appended to the scrollback
buffer, it is also written to the log file.
Some commands forcibly wrap their output (e.g. `help` to 80 columns.)
Because this wrapping is done inside the scrollback buffer, the text
written to the file is not wrapped.
This can be seen with `help execution`.
|
| |
|
|
|
|
| |
discovered
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
* Remove up to one frame of input latency. Makes MAME virtually lagless on VRR monitors.
* Use empty parentheses and clean interface member calls
* Add new option -instant_blit to make this feature optional
* Rename new option to -lowlatency, -ll
|
|
|
|
|
|
|
| |
- Removed the -skip_mandatory_fileman command line option
- Created an emu.register_mandatory_file_manager_override() LUA function
to allow LUA plugins to substitute the mandatory file manager
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* There is no longer a concept of "layers" - there are only screens and elements.
* Elements are now instantiated with <element ref="...">
* Screens and elements can have explicit blending mode specified with blend="..."
* Default blending mode for screens is "add" and default for other elements is "alpha"
* Other supported modes are "none" and "multiply"
* This removes the options to enable/disable layers individually - use views instead
* Legacy layouts can still be loaded, and support won't be removed for at least a year
The current artwork model is over-stretched. It's based on a Space
Invaders cabinet model, and isn't applicable to a lot of the systems
MAME emulates now. The fact that MAME has to switch to an "alternate"
mode to deal with games like Golly! Ghost! without requiring pre-matted
bitmaps shows that the Space Invaders model wasn't even adequate for
general arcade use. It shows in that for a lot of the systems that
heavily depend on artwork, people just seem to randomly choose layers
for elements until they get something that works. Also, the fact that
MAME will switch to an alternate (Golly! Ghost!) mode depending on the
combination of elements is a trap for people learning to make artwork.
There are cases that the current approach of implying the blending mode
from the layer doesn't work with. Examples include LEDs behind
diffusers (requires additive blending for layout elements), and mutliple
stacked LCD panels (requires RGB multiplication for screens).
For configurability, it's now a lot easier to make multiple views using
groups. For example, if you want to make it possible to hide the
control panel section of your layout, you can put the control panel
elements in a group and create views with and without it.
I will gradually migrate the internal artwork to use the new approach.
I have an XSLT stylesheet that helps with this, but I'm not comfortable
adding it because it isn't a complete solution and it still requires
manul steps.
I wanted to get the re-worked pointer handling done sooner so I could
push them both at the same time, but unfortunately various things have
prevented me from progressing as quickly as I wanted to. Sorry guys,
that stuff's going to have to wait.
|
| |
|
|
|
|
| |
Some misc text changes to certain trigger usage info (nw)
|
| |
|
| |
|
| |
|
|
|
|
| |
extricate emu.h from tools (nw)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* M1COMM: update simulation based on real firmware (nw)
- read partial frames correctly now
- added VSYNC packets (framesync currently disabled as this can cause
MAME to freeze and we have no way to tell if the socket is still open)
* M2COMM: update simulation (nw)
- read partial frames correctly now
- added VSYNC packets (framesync currently disabled as this can cause
MAME to freeze and we have no way to tell if the socket is still open)
* M1COMM, M2COMM: add config option to sync frames over network (nw)
* M2COMM: another update to the simulation.
- added relay mode (used by stcc)
- added "connection loss"
* M1COMM: update to simulation (nw)
- better sync
- detect lost connection
* M2COMM: use osd_file rather than emu_file for better control (nw)
* M2COMM: handle connection loss in a a more elegant way (nw)
* M1COMM: use osd_file rather than emu_file for better control (nw)
* S32COMM: updated simulation (nw)
- handle connection loss
- use osd_file rather than emu_file for better control
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Added fallback_artwork and override_artwork as MAME options to allow default artwork to be loaded.
* Removed debug testing code.
* - Allow loading of built-in layouts even if override_artwork is specified.
- Allow loading of fallback_artwork if only default view have been found.
- Fixed order of built-in layouts with regards to fallback_artwork as agreed upon the forums.
* Changed |= true to = true, and changed override artwork so it only checks for default.lay if the <machine name>.lay is not found.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- reset scheduler savestate to what it was for years before rewind
-- changing saved variables should be done after thorough testing. right now, adding some vars breaks some machines, adding other vars breaks others
- switch to megabyte-wise capacity
-- savestate size greatly differs between machines, relying on state count is unstable
- switch to internal indexing
-- no longer depends on inaccurate machine time
- rewind accelerator key in debugger (Ctrl+F11)
- report capacity hit (once), with some useful info
- make error reports saner
- mention rewind and rewind_capacity in the docs
|
|
|
|
| |
This reverts commit 54155441e9ba9941e85d80c4834a66376a11e791.
|
|
|
|
|
| |
This reverts commit f537428e5a40ba6dde8ca9bf0fe9ae6b1f189ac4, reversing
changes made to 0d70d798107d4e4e8fb9f230410aeb1e888d65c5.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This starts the work requested in #2398.
How RAM states work.
Implemented using util::vectorstream. Instead of dumping m_save.m_entry_list to file, it writes them as binary to vectorstream. Compression is not used, as it would slow down the process. The header is written as usual, also in binary. When a state is loaded, the savestate data gets binary-read from vectorstream.
How rewind works.
Rewind is optional, it can be turned off through MAME GUI while not running. Rewind capacity is available there too. Rewind step hotkey is available from the standard hotkey menu. In the debugger you have the "rewind" command ("rw" shortcut) that works the same as the hotkey.
Every time you advance a frame (pause step), rewinder captures a RAM savestate of the frame you were at. It does the same when you do step into/over/out in the debugger. Every time it captures a new state (and when you unpause), it marks as invalid all its states that go after the current machine time, because input might change, so they are not relevant anymore. It keeps their buffers allocated though, for future use. When rewinder runs out of allowed amount of savestates it can have, it invalidates the first state in the list and tosses its unique_ptr to the end of the list, then it uses its buffer to capture a new state. When you hit the rewind step key, or use "rewind" command in the debugger, it loads a state that is immediately before the current machine time. Invalid states between valid ones are not allowed to appear, as that breaks rewinder integrity and causes problems. Rewinder keeps its own set of ram states as a vector of unique_ptr's. All rewinder operations and errors get reported using machine().popmessage().
|
|
|
|
|
|
|
|
| |
This reverts commit 9968fc71b08b2a27e930d02333cb813977a37cbd.
This hides the underlying problem that the options structure is getting
out-of-sync. It's losing the image option but not the underlying
option. Masking the problem doesn't fix it.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit 536990e77b49ccc50ef275bfbf1018cc29c16154.
Conflicts:
src/frontend/mame/mame.cpp
Sorry, but this change was half-baked. It breaks a lot of existing
functionality and clearly hasn't been tested in more than a tiny subset
of use cases. Please play this work back onto your own branch, and test
it before submitting another PR.
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is an overhaul to how MAME handles options to provide a better foundation for what MAME is already doing in practice. Previously, core_options was designed to provide an input/output facility for reading options from the command line and INI files. However, the current needs (image/slot/get_default_card_software calculus and MewUI) go way beyond that.
Broadly, this PR makes the following changes:
* core_options now has an extensibility mechanism, so one can register options that behave dramatically differently
* With that foundation, emu_options now encapsulates all of the funky image/slot/get_default_card_software calculus that were previously handled by static methods in mameopts.cpp. Changes to emu_options should not automatically cascade in such a way so that it stays in a consistent state
* emu_options no longer provides direct access to the slot_options/image_options maps; there are simpler API functions that control these capabilities
* Many core_options functions that expose internal data structures (e.g. - priority) that were only really needed because of previous (now obsolete) techniques have been removed.
* core_options is now exception based (rather than dumping text to an std::string). The burden is on the caller to catch these, and discern between warnings and errors as needed.
Obviously this is a risky change; that's why this is being submitted at the start of the dev cycle.
|
| |
|
|
|
|
|
| |
image option (#2245)
This is a hack; see commentary within the code. I intend to fix this "for real" when emu_options become more self contained
|
|
|
|
|
|
|
|
| |
This should address outstanding concerns with PR#2231. I'm trying to turn emu_options into a self contained structure that encapsulates behaviors related to options, including the gymnastics pertaining to image/slot loading and interactions with get_default_card_software() and "just works".
When the MAME 0.186 development cycle starts up, I hope to take this further. I want to make core_options::entry an abstract base class so that the entries associated with image options and slot options can derive from it. This will eliminate the current need for emu_options to directly expose maps for image and slot options.
For now, I'm in stabilization mode, and I hope to get things working for a stable 0.185 release.
|
|
|
|
|
|
|
| |
Robbbert) (#2231)
This fix really doesn't go far enough. I added hooks so that options specified at the command line can also be responded to when parsed from INI files, but in the long run much of the logic that is currently in mame_options should go into emu_options so that when an option is specified, all of the wacko logic around slot/image specification "just works" because it is encapsulated within emu_options.
We have a release 11 days away; I want to be in stabilization mode.
|
|
|
|
|
|
|
|
|
|
| |
Prior to this change, options for images and slots were stored in the emu_options collection. Anything that might restart the emulation (such as slot changes and images that reset on load) had to manipulate the emu_options structure directly. The dynamic nature of images and slots meant that some elaborate conventions for setting up this collection had to be understood by clients.
After this change, emu_options has two new members (image_options and slot_options) that expose image and slot selections via an std::map. Anything that changes images or slots in a fashion that needs to persist across sessions needs to modify these data structures. Additionally, some of the hairly logic (e.g. - get_default_card_software) now records its data here rather than trying to subvert the core_options system.
This is how MT#6531 was fixed; now when diimage.cpp sees an image that resets on load, it just modifies the image_options structure and forces a reset. This allowed some further cleanups to happen within diimage.
This should be considered a very risky change, and scrutiny/feedback is welcome. In particular, there seems to be functionality surrounding device bioses that I'm not 100% sure how it works; the syntax seems to imply that it only works on slot devices.
|
|
|
|
| |
remove long-dead option
|
|
|
|
|
|
|
|
|
|
| |
* Eliminates the need for emu_options::update_cached_options() by providing a hook for when option values change
* This is a preliminary fix to the issue identified in PR#2065
* More softlist related refactoring:
- We now only parse the command line (with core_options::parse_command_line()) once
- Options that are set up during slot and image setup go through a 'value_specifier' function
- Eliminated the command line postprocessing
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
scripts (nw)
Copied all needed files so plugins could be started under UWP
|
| |
|
|
|
|
| |
-unevenstretchx or -unevenstretchy based on source native orientation.
|
| |
|