summaryrefslogtreecommitdiffstatshomepage
path: root/src/frontend/mame/ui/submenu.cpp
diff options
context:
space:
mode:
author Vas Crabb <vas@vastheman.com>2019-07-06 00:23:20 +1000
committer Vas Crabb <vas@vastheman.com>2019-07-06 00:23:20 +1000
commitc38a3395e94e38a37cf6b8efdf9f49a5c9d415df (patch)
tree8ad5f6ee37953b4d19241ce31d11da23a712cc3e /src/frontend/mame/ui/submenu.cpp
parent7ee50ffec7afabd20a027f89e47f11b116301071 (diff)
Make layout format more flexible:
* 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.
Diffstat (limited to 'src/frontend/mame/ui/submenu.cpp')
-rw-r--r--src/frontend/mame/ui/submenu.cpp5
1 files changed, 0 insertions, 5 deletions
diff --git a/src/frontend/mame/ui/submenu.cpp b/src/frontend/mame/ui/submenu.cpp
index a9134935f7a..f9cff799c1f 100644
--- a/src/frontend/mame/ui/submenu.cpp
+++ b/src/frontend/mame/ui/submenu.cpp
@@ -55,11 +55,6 @@ std::vector<submenu::option> const submenu::advanced_options = {
{ submenu::option_type::HEAD, __("Artwork Options") },
{ submenu::option_type::EMU, __("Artwork Crop"), OPTION_ARTWORK_CROP },
- { submenu::option_type::EMU, __("Use Backdrops"), OPTION_USE_BACKDROPS },
- { submenu::option_type::EMU, __("Use Overlays"), OPTION_USE_OVERLAYS },
- { submenu::option_type::EMU, __("Use Bezels"), OPTION_USE_BEZELS },
- { submenu::option_type::EMU, __("Use Control Panels"), OPTION_USE_CPANELS },
- { submenu::option_type::EMU, __("Use Marquees"), OPTION_USE_MARQUEES },
{ submenu::option_type::HEAD, __("State/Playback Options") },
{ submenu::option_type::EMU, __("Automatic save/restore"), OPTION_AUTOSAVE },