Open cuavas opened 1 year ago
I’ll look at the config crash myself. There’s a bit of a fundamental problem at the moment in that render modules aren’t actually OSD modules in the same sense as the other OSD modules. There’s just a static function that knows about all possible renderer classes. It might be time to bite the bullet and change that. It would make several things simpler.
I've already told moogly about these, they're not regressions:
The window resizing works fine on linux for me with this update fwiw. I have always had issues with the full screen toggle not working so thats not a regression either.
Thanks for making this thread, Vas.
I'll have a look at the slowness with D3D12 and Vulkan first, I suspect there's a significant amount of overhead due to MAME's whole rendering architecture assuming immediate mode. It's very likely that there might not be much I can do about it in the immediate term, but I can try to identify any low-hanging fruit that exists.
Oh, I should mention it here and add it to the description. There’s still the font texture atlas optimisation weirdness with two windows.
BGFX fullscreen toggle has been broken for a while on the Mac with the Metal backend. I'm unclear if this is our fault or BGFX's. Here's the dump macOS gives, it appears to be a use-after-free.
VM Region Info: 0x7f190f4a8168 is not in any region. Bytes after previous region: 16600165667177 Bytes before following region: 786300239512 REGION TYPE START - END [ VSIZE] PRT/MAX SHRMOD REGION DETAIL Stack 700008481000-700008503000 [ 520K] rw-/rwx SM=PRV thread 10 ---> GAP OF 0xfd01a1fd000 BYTES MALLOC_TINY 7fd022700000-7fd022800000 [ 1024K] rw-/rwx SM=PRV
Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 libobjc.A.dylib 0x7ff810f54e1d objc_msgSend + 29 1 mame 0x10bba3aea bgfx::mtl::SwapChainMtl::init(void) + 714 2 mame 0x10bba9c07 bgfx::mtl::RendererContextMtl::updateResolution(bgfx::Resolution const&) + 199 3 mame 0x10bba577a bgfx::mtl::RendererContextMtl::submit(bgfx::Frame, bgfx::ClearQuad&, bgfx::TextVideoMemBlitter&) + 394 4 mame 0x10bb6a0b0 bgfx::Context::renderFrame(int) + 160 5 mame 0x10bb69e8e bgfx::Context::swap() + 398 6 mame 0x10bb686e5 bgfx::Context::frame(bool) + 197 7 mame 0x10b6fb351 renderer_bgfx::draw(int) + 1537
I've found issues with the screen curvatures at the corners.
mame -norc -rompath Z:\Mame\roms -window -video bgfx -bgfx_backend auto -bgfx_screen_chains crt-geom sf2ce
I've found issues with the screen curvatures at the corners.
Tested on linux can reproduce on before and after when tinkering with window sizes to make it happen. Fullscreen and maximum window is fine though
Toggle fullscreen to window (and vice-versa) with BGFX on Debian, makes mame crash, it doesn't happen if -video opengl
.
mametiny -norc -rompath Z:\Mame\roms -nowindow -video bgfx -bgfx_backend auto -bgfx_screen_chains crt-geom wrally
Error:
X Error of failed request: BadWindow (invalid Window parameter)
Major opcode of failed request: 149 (GLX)
Minor opcode of failed request: 0 ()
Resource id in failed request: 0x1600011
Serial number of failed request: 1191
Current serial number in output stream: 1191
Full AddressSanitizer log with -video bgfx
:
video_bgfx.txt
Full AddressSanitizer log with -video opengl
(no crash)
video_opengl.txt
In sdl_window_info::toggle_full_screen the window and renderer are destroyed and recreated. That's overkill and probably causing the problem. A simple resize should work.
El mar, 31 ene 2023 a las 12:43, cd4053 @.***>) escribió:
Toggle fullscreen to window (and vice-versa) with BGFX on Debian, makes mame crash, it doesn't happen if -video opengl.
mametiny -norc -rompath Z:\Mame\roms -nowindow -video bgfx -bgfx_backend auto -bgfx_screen_chains crt-geom wrally
Error:
X Error of failed request: BadWindow (invalid Window parameter) Major opcode of failed request: 149 (GLX) Minor opcode of failed request: 0 () Resource id in failed request: 0x1600011 Serial number of failed request: 1191 Current serial number in output stream: 1191
Full AddressSanitizer log with -video bgfx: video_bgfx.txt https://github.com/mamedev/mame/files/10545907/video_bgfx.txt
Full AddressSanitizer log with -video opengl (no crash) video_opengl.txt https://github.com/mamedev/mame/files/10545930/video_opengl.txt
— Reply to this email directly, view it on GitHub https://github.com/mamedev/mame/issues/10859#issuecomment-1410208017, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEAMAEIOTZLRSSU2CLV4JDDWVD3HBANCNFSM6AAAAAAUJ2EUQM . You are receiving this because you are subscribed to this thread.Message ID: @.***>
The renderer is torn down and recreated on Windows, too, without this issue. The issue on Linux specifically arises from recreating the renderer prior to the window itself having been recreated.
Let's stick to reporting issues, and leave the actual triage and fixes to those of us who are actually equipped to fix them.
2810c9d91bfaee4d833b3c6dc03672799053f702 fixes the configuration persistence issues (both crashing on exit after toggling fullscreen and persisting most settings across a fullscreen toggle).
Not tearing down windows when toggling fullscreen isn’t always an option. There are a few avenues to investigate for addressing the issue of BGFX having its primary window stolen from under it.
AddressSanitizer log from commit https://github.com/mamedev/mame/commit/2810c9d91bfaee4d833b3c6dc03672799053f702.
It doesn't display a BadWindow
error anymore.
video_bgfx2.txt
MAME used to crash on Mac for unclean exits (fatalerror()) and the like. With the latest it crashes on clean exits too (pressing Esc).
0 mame 0x11132b0c8 texture_manager::~texture_manager() + 88 1 mame 0x11133a6c9 renderer_bgfx::~renderer_bgfx() + 969 2 mame 0x11133a85e renderer_bgfx::~renderer_bgfx() + 14 3 mame 0x1112e2a64 osd_common_t::osd_exit() + 68 4 mame 0x11137bd59 sdl_osd_interface::osd_exit() + 9
MAME used to crash on Mac for unclean exits (fatalerror()) and the like. With the latest it crashes on clean exits too (pressing Esc).
That shouldn’t be happening. I intentionally destroy the renderers before shutting down the module and destroying the windows in an effort to avoid exactly this (see here). Going to need more information:
-video opengl
and -video accel
still work?texture_manager::~texture_manager()
in the specific build the stack trace comes from so I can see what it’s actually doing when it crashes?Linux is having the same behavior segfault on clean exit and a segfault on full screen toggle it used to just freeze up or say bad window depending if you started with -window or not but the clean exit segfault is new. Everything works fine on -video opengl
There’s an object lifecycle issue with texture providers. I’ll try and sort that out tonight.
47aa6fd60d6b1aca920f4c49175752d8124ed689 should fix leaked and double-freed textures. Target manager textures are owned by the target manager, all other textures are owned by the texture manager. You need to explicitly supply a reference or smart pointer when adding a texture to the texture manager depending on whether you will delete it yourself or let the texture manager delete it when it’s removed (or on destruction).
f408dd83e27fb106ed60b66eafebc4015040bf26 fixes crash on toggling fullscreen on Linux (and maybe Mac if we’re lucky).
For some reason slider settings don’t save/restore properly on Linux at the moment. I’ll look into it.
Fix https://github.com/mamedev/mame/commit/f408dd83e27fb106ed60b66eafebc4015040bf26 confirmed, thank you @cuavas.
Fullscreen toggle works on Mac, and exiting no longer crashes. Thanks!
6ff51387fa39a3a1b2a178b16ffcd687445dae83 fixes the config issues I was having.
If you want your chain selections to be saved/restored automatically per-system, don’t put bgfx_screen_chains
in your mame.ini or set it to an empty string.
Fullscreen toggle and exit works fine on linux as well with both opengl and vulkan bgfx backends. The issues of shaders crashing when scrolling through is fixed as well. I always have had and was given the impression it was it was mesa issues. This for me is a big update in usability the kind of quality fixes often get left thankless.
Is Linux Wayland support a thing BGFX upstream need to do, or a task for MAME?
At this point, I really don’t care about supporting Wayland in MAME besides via X11 compatibility. It’s more trouble than it’s worth for us.
Thanks for the work with improving the BGFX support in MAME!
I've been building MAME with emscripten (wasm) every now and then for the last years out of curiosity but haven't been able to get BGFX working with emscripten since somewhere around MAME 0.236 using emscripten 2.0.23. However, building later versions of MAME with later emscripten versions has been working well as long as BGFX isn't used.
There is however an issue with building MAME with emscripten from master now, the compile fails with the following errors:
Compiling src/osd/modules/render/drawbgfx.cpp...
../../../../../src/osd/modules/render/drawbgfx.cpp:416:2: error: "Unsupported BX platform"
#error "Unsupported BX platform"
^
In file included from ../../../../../src/osd/modules/render/drawbgfx.cpp:9:
../../../../../src/osd/modules/render/drawbgfx.h:143:11: error: private field 'm_view_width' is not used [-Werror,-Wunused-private-field]
uint16_t m_view_width;
^
../../../../../src/osd/modules/render/drawbgfx.h:144:11: error: private field 'm_view_height' is not used [-Werror,-Wunused-private-field]
uint16_t m_view_height;
^
3 errors generated.
The error occurs using the latest mame src (28fce32e875fa7e1fc3a73218e3759b88915db6e
) and emscripten 3.1.24.
The build issue can be reproduced by:
docker run --rm -ti -v $PWD:/src emscripten/emsdk:3.1.24 emmake make -j 1 SUBTARGET=arcade SOURCES=src/mame/capcom/cps1.cpp WEBASSEMBLY=1 PYTHON_EXECUTABLE=python3 OPTIMIZE=3 ARCHOPTS=-Wno-unused-command-line-argument -Wno-error=unused-command-line-argument -s MAX_WEBGL_VERSION=2 -s LEGACY_GL_EMULATION=1 -s WEBGL2_BACKWARDS_COMPATIBILITY_EMULATION=1 ARCHOPTS_CXX=-Wno-unused-but-set-variable -Wno-unused-command-line-argument -Wno-c++11-narrowing -Wno-deprecated-declarations -s -Wno-unused-variable -Wno-error
(replace -j 1
with -j $(nproc)
for faster compilation)
It would be awesome to be able to again get BGFX working in emscripten builds but that might require some more work in MAME or BGFX but to at least get the emscripten work at all would be good enough :)
Well it needs to supply whatever BGFX wants as the window identifier in the platform data there. Maybe the reason it didn't work is that whichever path it was previously defaulting to (probably X11) didn't actually work with Emscripten, so BGFX was trying to use an invalid "window".
b9c878e6271b73e2b8751fa4efbd8a5d905b42ae checks the window manager type returned by SDL rather than making an assumption at compile time. I expect it still won’t actually work with Emscripten.
For some reason, some Konami GX games don’t show video with -bgfx_backend vulkan
and may crash on Linux, see #10815. Affected games include daskiss
and sexyparo
.
On cubeqst I cannot get the overlay graphics to use the Fighters chain and the LD content to use 'none' at the same time.
mame cubeqst -norc -video bgfx -bgfx_screen_chains none,Fighters -rompath roms;d:\chds
Some LD content is trying to play in the far left columns of the screen (the logo appearance). Happens in cliffhgr too.
0.251 (mame0251-334-g519554c8464) Windows 11 x64 22621.1194 2560x1440 Monitor Res.
Question: Should the LD games default their LD content to 'none' for the cleanest presentation if a screen0 or screen1 chain is not specifically called out?
On cubeqst I cannot get the overlay graphics to use the Fighters chain and the LD content to use 'none' at the same time.
Yes, because they are on the same screen (not two screens superimposed using a semi-reflective mirror). That’s correct behaviour.
Question: Should the LD games default their LD content to 'none' for the cleanest presentation if a screen0 or screen1 chain is not specifically called out?
No, they should default to the default screen chain.
So just using the Fighters chain should apply to all elements onscreen for LD games, yes?
mame cubeqst -norc -video bgfx -bgfx_screen_chains Fighters
In this example the overlay graphics appear to be using 'Default' instead of Fighters on Window 0, Screen1. I cleared the cfg in case there was some interplay w/ the recent BGFX settings savings in there.
John, do these games appear correctly when running with -video d3d -hlsl
?
|John, do these games appear correctly when running with -video d3d -hlsl?
Negative. The overlay text 'smears' downwards and to the right leaving graphic residue, it's pretty wild (attached). The LD content does show behind it, but it's tough to see through the smears as it (the smearing) remains onscreen. I'm using an AMD 5600XT if that makes a difference.
mame cubeqst -norc -video d3d -hlsl_enable
Believe the HLSL directory and .ini presets (raster, etc.) are up to date.
So, some of the chains do seem to work with my command line argument below (crt-geom works). Others, like Fighters produce the blank LD content.
mame cubeqst -norc -video bgfx -bgfx_screen_chains default,crt-geom
Working chains w/ above argument: none, default, crt-geom, hlsl Non-working chains w/ above argument: Fighters, crt-geom-deluxe, the hqXx family
@cuavas design question: If we're planning on BGFX as default I'm wondering about the current default behaviour of multi-screen games like Punch Out and the Game & Watches.
Would it be more user friendly to have their (most likely) single chain .ini entry applied to both screens by default so folks don't launch it and see it only on the top screen?
With HLSL it currently applies the effects to both screens; and might take some new education to clue them in on using commas for multiple screens with -bgfx_screen_chains.
mame punchout -video bgfx -bgfx_screen_chains Fighters
vs.
mame punchout -hlsl_enable
Here's another weird edge case. The interaction between -prescale X and the BGFX Chains produces some odd results:
mame polepos -norc -bgfx_screen_chains hlsl -video bgfx -prescale 5
This will show just a small 'window' in the middle of the full screen with Pole Position playing, like you're looking through a box.
mame dkong -bgfx_screen_chains Fighters -norc -video bgfx -prescale 5
Shows the full screen but with an odd blurred image of the shadowmask(?) enlarged from the chain.
Images attached.
New issue, regression from .251, HLSL and Game & Watch combo causing failure to display and then AVs:
mame -v gnw_bjack -video d3d -hlsl_enable -norc
0.251 (mame0251-342-g678eb8d5cf2) Windows 11 x64 22H2 22621.1194 AMD 5600XT Raster.ini and gnw_bjack artwork attached
Attempting to parse: default.cfg
Attempting to parse: gnw_bjack.cfg
Direct3D: Get texture target - not found - 960x645:0
Direct3D: Create texture target - 536x368
Direct3D: Get texture target - not found - 960x645:1
Direct3D: Create texture target - 536x368
Direct3D: Get texture target - not found - 960x648:2
Direct3D: Create texture target - 529x355
Direct3D: Get texture target - not found - 960x648:3
Direct3D: Create texture target - 530x356
-----------------------------------------------------
Exception at EIP=00007ff70c2d5dd9 (not found): ACCESS VIOLATION
While attempting to read memory at 00000000000004e8
-----------------------------------------------------
RAX=0000000000000000 RBX=000001b200ccb850 RCX=00007ff715cd02b0 RDX=00007ff715cd02b0
RSI=0000000000000000 RDI=0000000000000001 RBP=00007ff715cd02b0 RSP=000000790fbf8a40
R8=0000000000000000 R9=fffffffffff2cae0 R10=b1d1877f545bc370 R11=8101010101010100
R12=000001b200ce3110 R13=0000000000000000 R14=000001b21beb8e40 R15=000001b215ed57e0
-----------------------------------------------------
Stack crawl:
000000790fbf8ab0: 00007ff70c2d5dd9 (not found)
000000790fbf8b90: 00007ff70c2dbaa8 (not found)
000000790fbf8d10: 00007ff70c21a40d (not found)
000000790fbf8dc0: 00007ff70c21a678 (not found)
000000790fbf8e20: 00007ff70c220221 (not found)
000000790fbf8e80: 00007ff70c2345e8 (not found)
000000790fbf8f70: 00007ff70c236385 (not found)
000000790fbf90d0: 00007ff9e51b8281 (DispatchMessageW+0x0741)
000000790fbf9120: 00007ff9e51b7acb (CallWindowProcW+0x008b)
000000790fbf91c0: 00007ff97ae3a8fe (Direct3DCreate9Ex+0x4a3e)
000000790fbf9320: 00007ff9e51b8281 (DispatchMessageW+0x0741)
000000790fbf93d0: 00007ff9e51b77ad (SendMessageW+0x037d)
000000790fbf9430: 00007ff9e51b7567 (SendMessageW+0x0137)
000000790fbf9470: 00007ff70c23339a (not found)
000000790fbf9500: 00007ff70c1b16f0 (not found)
000000790fbf9560: 00007ff70c168e9a (not found)
000000790fbf95d0: 00007ff70c16350b (not found)
000000790fbf9750: 00007ff70c1116d0 (not found)
000000790fbfebe0: 00007ff70cb9c746 (not found)
000000790fbfefd0: 00007ff70cc37fd6 (not found)
000000790fbff2e0: 00007ff70cc385ea (not found)
000000790fbff340: 00007ff70cb96f97 (not found)
000000790fbff700: 00007ff711ef7970 (not found)
000000790fbff750: 00007ff7056c12ee (not found)
000000790fbff780: 00007ff7056c1406 (not found)
000000790fbff7b0: 00007ff9e54126bd (BaseThreadInitThunk+0x001d)
000000790fbff830: 00007ff9e698dfb8 (RtlUserThreadStart+0x0028)`
I agree with the suggestion of extending a user's chain selection onto multiple screens if only one is supplied. Further, I would say that if the user supplies two or more chain selections themselves, then it should resort to applying the default chain to screens 3 and up.
Regarding the issue with Konami GX games and -video bgfx -bgfx_backend vulkan
, I just spent a bunch of time testing various points throughout my changes and then finally tested it before I had made any changes at all, and it turns out it existed in MAME even before these changes. I'll do my best to fix it, but it's enough of an edge case that I don't think it should be a blocker for switching over to BGFX as the default.
New issue, regression from .251, HLSL and Game & Watch combo causing failure to display and then AVs:
mame -v gnw_bjack -video d3d -hlsl_enable -norc
0.251 (mame0251-342-g678eb8d5cf2) Windows 11 x64 22H2 22621.1194 AMD 5600XT Raster.ini and gnw_bjack artwork attached
Attempting to parse: default.cfg Attempting to parse: gnw_bjack.cfg Direct3D: Get texture target - not found - 960x645:0 Direct3D: Create texture target - 536x368 Direct3D: Get texture target - not found - 960x645:1 Direct3D: Create texture target - 536x368 Direct3D: Get texture target - not found - 960x648:2 Direct3D: Create texture target - 529x355 Direct3D: Get texture target - not found - 960x648:3 Direct3D: Create texture target - 530x356 ----------------------------------------------------- Exception at EIP=00007ff70c2d5dd9 (not found): ACCESS VIOLATION While attempting to read memory at 00000000000004e8 ----------------------------------------------------- RAX=0000000000000000 RBX=000001b200ccb850 RCX=00007ff715cd02b0 RDX=00007ff715cd02b0 RSI=0000000000000000 RDI=0000000000000001 RBP=00007ff715cd02b0 RSP=000000790fbf8a40 R8=0000000000000000 R9=fffffffffff2cae0 R10=b1d1877f545bc370 R11=8101010101010100 R12=000001b200ce3110 R13=0000000000000000 R14=000001b21beb8e40 R15=000001b215ed57e0 ----------------------------------------------------- Stack crawl: 000000790fbf8ab0: 00007ff70c2d5dd9 (not found) 000000790fbf8b90: 00007ff70c2dbaa8 (not found) 000000790fbf8d10: 00007ff70c21a40d (not found) 000000790fbf8dc0: 00007ff70c21a678 (not found) 000000790fbf8e20: 00007ff70c220221 (not found) 000000790fbf8e80: 00007ff70c2345e8 (not found) 000000790fbf8f70: 00007ff70c236385 (not found) 000000790fbf90d0: 00007ff9e51b8281 (DispatchMessageW+0x0741) 000000790fbf9120: 00007ff9e51b7acb (CallWindowProcW+0x008b) 000000790fbf91c0: 00007ff97ae3a8fe (Direct3DCreate9Ex+0x4a3e) 000000790fbf9320: 00007ff9e51b8281 (DispatchMessageW+0x0741) 000000790fbf93d0: 00007ff9e51b77ad (SendMessageW+0x037d) 000000790fbf9430: 00007ff9e51b7567 (SendMessageW+0x0137) 000000790fbf9470: 00007ff70c23339a (not found) 000000790fbf9500: 00007ff70c1b16f0 (not found) 000000790fbf9560: 00007ff70c168e9a (not found) 000000790fbf95d0: 00007ff70c16350b (not found) 000000790fbf9750: 00007ff70c1116d0 (not found) 000000790fbfebe0: 00007ff70cb9c746 (not found) 000000790fbfefd0: 00007ff70cc37fd6 (not found) 000000790fbff2e0: 00007ff70cc385ea (not found) 000000790fbff340: 00007ff70cb96f97 (not found) 000000790fbff700: 00007ff711ef7970 (not found) 000000790fbff750: 00007ff7056c12ee (not found) 000000790fbff780: 00007ff7056c1406 (not found) 000000790fbff7b0: 00007ff9e54126bd (BaseThreadInitThunk+0x001d) 000000790fbff830: 00007ff9e698dfb8 (RtlUserThreadStart+0x0028)`
Please file this as a separate issue. You're reporting issues with the D3D renderer in a thread about making BGFX the default renderer. If anything, it gives justification for why MAME should switch to BGFX.
b9c878e checks the window manager type returned by SDL rather than making an assumption at compile time. I expect it still won’t actually work with Emscripten.
Thanks Vas! I can confirm that the change resolves the compile issue and that the emscripten build now is functional again.
When starting an emscripten build with -video bgfx
, BGFX initialization fails and the video module selection defaults to soft
which is the same as before the recent changes. It seems like the issue is related to finding the shaders (or that the shaders cannot be loaded for some other reason). This is some of the console output:
BGFX: Unable to load required shaders. Please update the bgfx folder or adjust your bgfx_path setting.
loader.js:1052 Initializing video module bgfx failed
loader.js:1052 Attempting to initialize video module soft
loader.js:1052 Using SDL multi-window soft driver (SDL 2.0+)
loader.js:1053 Initializing video module bgfx failed, falling back to soft
loader.js:1052 Enter sdlwindow_init
Perhaps getting BGFX to work again with emscripten builds of MAME should be handled as a separate issue?
@cuavas I'm testing the BGFX saving into the .cfgs. Should a mask_texture change save to the CFG? Currently it doesn't when I change it away from the .json's default:
{ "sampler": "mask_texture", "texture": "bgfx/chains/crt-geom/aperture_2_4_rgb.png", "selection": "Shadow mask" }
0.251 (mame0251-354-ge8533db8527), altered crt-geom.jason attached. I was trying to have it switch and stay at aperture_2_5_BGR
@cuavas I'm testing the BGFX saving into the .cfgs. Should a mask_texture change save to the CFG?
It shouldn’t right now.
@cuavas is it the ultimate intent that one will be allowed to alter a game's BGFX sliders and have them stored in the .cfg even if you have different default settings in mame.ini?
I'm finding I like to change the screen0 and screen1 chains on LD games (cubeqst) via slider away from the mame.ini. Currently any changes to individual machine cfgs appear to be reset when altering the chains in this way and re-running the game (I think I read you said that was a limitation (?) somewhere).
@cuavas is it the ultimate intent that one will be allowed to alter a game's BGFX sliders and have them stored in the .cfg even if you have different default settings in mame.ini?
I'm finding I like to change the screen0 and screen1 chains on LD games (cubeqst) via slider away from the mame.ini. Currently any changes to individual machine cfgs appear to be reset when altering the chains in this way and re-running the game (I think I read you said that was a limitation (?) somewhere).
Remove the bgfx_screen_chains
from your INI files if you want it to remember the screen chains you choose with sliders. It assumes that if you have it set in an INI file or on the command line, you actually want it to apply.
Is there a way to set default settings for sliders? I tried to copy some settings to default.cfg, but mame just removes them.
You can edit the bgfx\chains\*.json
files directly. You could then create an \ini\presets\*.ini
for only the games you want to use it, with -bgfx_screen_chains blahblah
in it. I have separate chains used for vertical and horizontal games using this method.
Thanks, that would work, but it would be great if there was another option. I'm on linux and installed mame from the repo, I would rather not touch anything in /usr/share. There's bgfx_path option, but it supports only one path, unlike some other options in mame.ini, that means I can't copy only files I want to edit, instead I have to copy everything from bgfx directory. And no matter what, copying the files also would mean I have to keep them updated manually.
Is it possible to specify a default chain and then have MAME save the latest selected one?
Edit: I see it's now possible, thanks for fixing it.
I think Vulkan is a better choice: https://www.vulkan.org/
It's an industry standard across all devices. Something MAME needs. You don't want to maintain bgfx yourself if it's suddenly abandoned. The chance this will happen with Vulkan is astronomically smaller...
So Vulkan is the way to go!
Many open source projects are switching to Vulkan. If I'm correct, also Blender.
It would be good to get to a point where we can make BGFX the default render module, at least on Windows where Direct3D 9 is very much on life support, and on macOS where Metal support has been pretty important for quite a while now. With #10858 merged, a lot of corner cases should be fixed, and at least for emulated systems with raster screens, there should be no more need to use legacy Direct3D with HLSL. This issue is for identifying and tracking things that need to be fixed before BGFX can become the default render module.
Please report problems encountered during testing here.
Crash on saving slider state after toggling fullscreenThe render objects are desctroyed and recreated when toggling fullscreen. A proxy object is needed to handle the configuration load/save callbacks to get around this issue.Settings lost on toggling fullscreenOnly the active screen chains are saved on toggling fullscreen, other settings are lost. It should be possible to rope the configuration load/save hooks into service for this, which ties in with the previous point.Some Konami GX games not showing video with Vulkan backend
Some Konami GX games show no video (black screen) with
-bgfx_backend vulkan
on Windows or Linux, and may crash on Linux. Most backends don’t seem to be affected (opengl
,d3d9
,d3d11
,d3d12
all work). Reproduced with NVIDIA GeForce using consumer GeForce driver on Windows and NVIDIA proprietary driver on Linux. Affected systems includedaiskiss
andsexyparo
. See #10815.Font textures sized for most recently resized window rather than window showing UI
The easiest way to demonstrate this is with two windows – the system doesn’t matter,
pacman
is just an example:mame -window -numscreens 2 -skip_gameinfo pacman
The issue is that the font textures seem to be sized for the most recently resized window, not the window displaying the UI container.
Maximum prescaled texture size weirdness
The chain manager sets its maximum prescaled screen texture size
m_max_prescale_size
based on the initial window size and never updates it. However, based on testing it seems that the actual prescaled texture sizes are not what one would expect when the initial window size is small.