Viewing Issue Advanced Details
ID Category [?] Severity [?] Reproducibility Date Submitted Last Update
08586 Interface Minor Always Mar 22, 2023, 18:04 Oct 9, 2023, 12:27
Tester ICEknight View Status Public Platform MAME (Official Binary)
Assigned To Resolution Open OS Windows 10/11 (64-bit)
Status [?] Confirmed Driver
Version 0.252 Fixed in Version Build 64-bit
Fixed in Git Commit Github Pull Request #
Summary 08586: All sets in capcom/cps3.cpp, konami/hornet.cpp, jaleco/ms32.cpp, neogeo/neogeo.cpp, nintendo/nes.cpp, sega/model1.cpp and more: bgfx: Brightness/Contrast/Gamma settings ignored depending on core and random chance
Description If the Video option is set to bgfx and the value of Screen Brightness is 1.00, for any games in certain cores, trying to reset the Screen Contrast/Gamma settings to their default 1.00 value (either by moving the slider or pressing Del) won't reflect any actual changes on screen.

Besides having this issue, the affected cores will also randomly display a different (yet likely related) problem and completely ignore any Brightness/Contrast/Gamma values regardless of the Brightness not being set to 1.00 (see video in comments). You get a chance to toggle this additional bug on/off by:
-Entering or exiting full screen (Alt+Enter)
-Changing the Window Screen Effect chain in the sliders
-Hard resetting (Shift+F3)
Steps To Reproduce -Set the video to bgfx, any backend.
-Run any of the systems/games in the cores listed in "Additional Information".
-Open the sliders menu.
-While the Screen Brightness value is 1.00, modify the Contrast or Gamma and then press Del. Their value will read "1.00" but the on-screen effect won't change.

Or:
-While the Screen Brightness value is 1.00, move the Contrast/Gamma slider one notch from the default 1.00 and then back to 1.00. The on-screen effect will only change for the adjacent values but not for 1.00 (the effect will be more noticeable when holding Control while pressing left/right).

Or:
-Modify the Screen Brightness value, then press Del to reset it. The value will read "1.00" but the on-screen effect won't change. Same when moving its slider values manually from/to 1.00.

Or:
-Go to the Screen Brightness slider.
-Hold Control and press right. Brightness will go up to 1.100 and the screen will get brighter.
-Hold Control and press left. Brightness will go down to 1.000 but the screen will stay brighter.
Additional Information The affected cores use bitmap_rgb32 instead of bitmap_ind16 in the screen_update function.

Known affected cores:
ausnz/mbee.cpp
capcom/cps3.cpp
beehive/microb.cpp
ccs/ccs2810.cpp
heathkit/h19.cpp
jaleco/ms32.cpp
konami/hornet.cpp
konami/konamigx.cpp
midw8080/mw8080bw.cpp
mchester/ssem.cpp
neogeo/neogeo.cpp
nintendo/famibox.cpp
nintendo/n64.cpp
nintendo/nes.cpp
nintendo/snes.cpp
nintendo/playch10.cpp
skeleton/gimix.cpp
sega/mdconsole.cpp
sega/megadriv_acbl.cpp
sega/megadriv_rad.cpp
sega/megaplay.cpp
sega/megatech.cpp
sega/model1.cpp
sega/model2.cpp
sega/saturn.cpp
sega/segac2.cpp
sega/segas32.cpp
sega/segasg1000.cpp
sega/segasms.cpp
toaplan/toaplan1.cpp
toaplan/twincobr.cpp
toaplan/wardner.cpp

Some of the unaffected cores:
capcom/mitchell.cpp
capcom/gng.cpp
capcom/cps1.cpp
capcom/cps2.cpp
dataeast/cninja.cpp
dataeast/karnov.cpp
dataeast/supbtime.cpp
jaleco/momoko.cpp
jaleco/skyfox.cpp
kaneko/galpanic.cpp
kaneko/kaneko16.cpp
kaneko/snowbros.cpp
konami/asterix.cpp
konami/combatsc.cpp
konami/gradius3.cpp
konami/parodius.cpp
nec/pce.cpp
nintendo/n8080.cpp
nintendo/popeye.cpp
nintendo/vboy.cpp
sega/segahang.cpp
sega/segaorun.cpp
sega/segapico.cpp
sega/segapm.cpp
sega/segas16a.cpp
sega/segas16b.cpp
sega/segas16b_isgsm.cpp
sega/segas18.cpp
sega/segas24.cpp
sega/suprloco.cpp
sega/system1.cpp
sega/system16.cpp
sega/turbo.cpp
sega/zaxxon.cpp
sinclair/spectrum.cpp
sinclair/spec128.cpp
taito/taitob.cpp
technos/ddragon.cpp
toaplan/toaplan2.cpp
Github Commit
Flags
Regression Version
Affected Sets / Systems All sets in capcom/cps3.cpp, konami/hornet.cpp, jaleco/ms32.cpp, neogeo/neogeo.cpp, nintendo/nes.cpp, sega/model1.cpp and more
Attached Files
 
Relationships
There are no relationship linked to this issue.
Notes
19
User avatar
No.21186
Robbbert
Senior Tester
Mar 23, 2023, 03:32
Unable to replicate this with current git.
User avatar
No.21189
cuavas
Administrator
Mar 23, 2023, 09:02
Which render module? If bgfx, which backend? If d3d, is hlsl on or off? Windowed or fullscreen? What GPU and driver version?
User avatar
No.21190
ICEknight
Tester
Mar 23, 2023, 15:58
> Which render module?
bgfx.

> If bgfx, which backend?
Any.

> Windowed or fullscreen?
Both.

> What GPU and driver version?
Any, tested with different cards and computers with Windows 10.


tl;dr: Happens when using bgfx, any combination.
User avatar
No.21192
Robbbert
Senior Tester
Mar 23, 2023, 23:49
With bgfx it is confirmed.

>mame -video bgfx nes smb
User avatar
No.21196
cuavas
Administrator
Mar 24, 2023, 01:35
What do the affected systems have in common which is different from the unaffected systems?
User avatar
No.21197
Robbbert
Senior Tester
Mar 24, 2023, 04:28
I assume that is a rhetorical question, as that is a job for the assigned dev to determine.

However, I did more testing, and established 3 groups of systems.

1. The sliders don't work at all - examples are mbee, ssem, ccs2422 (they work with d3d)

2. The sliders work correctly - most arcade games

3. The bug reported here occurs - anything with a software list item, plus some other random things such as h19, gimix, invaders, dm3270.
User avatar
No.21198
cuavas
Administrator
Mar 24, 2023, 08:27
No it's a serious question. There's clearly some difference between the systems where it happens, probably somehow related to screen configuration. Determining what ths difference is would be the first step in working out what's going wrong.

I'm not going to believe the presence of software list items triggers the bug - they don't affect the render stack at all. I mean are you saying it happens with slotted MVS (e.g. mame neogeo kof99) but not the fixed MVS configurations (e.g. mame kof99)?
User avatar
No.21199
Robbbert
Senior Tester
Mar 24, 2023, 08:41
I tested 3 versions of kof99

1. kof99 - all is good

2. aes kof99 - sliders don't work

3. neogeo kof99 - all is good

I would assume they all use exactly the same screen coding, so what do you make of that?
User avatar
No.21201
cuavas
Administrator
Mar 24, 2023, 13:18
Just tested all three kof99 variants and a couple of NES games with a recent build, and the screen brightness and contrast sliders are non-functional for all of them with BGFX. I can’t get the behaviour ICEknight described at all. Maybe it’s something triggering undefined behaviour, and the “certain systems” part is a red herring?
User avatar
No.21202
cuavas
Administrator
Mar 24, 2023, 13:33
Unfortunately I don’t have a new enough version of valgrind here to deal with BGFX (the version I have can’t handle “vcvtph2ps ymm5,xmm5” instructions), so I can’t find check for uninitialised variables that way.
User avatar
No.21203
Robbbert
Senior Tester
Mar 24, 2023, 14:03
I just updated to the latest git, and some behaviour has changed. I'm only adjusting Brightness (but the Contrast and Gamma have the same issues).

schaser, invaders and invadpt2 all behave the same now, the sliders have no effect, but if you leave (for example the brightness all the way up), then quit and restart, suddenly the brightness *is* all the way up. So the setting is being saved and restored correctly, but not being applied "live".

Yet, kof99 and captcomm, the sliders do work live, there's no bug at all with them. And nes smb, it's exactly how iceknight says - it applies, up and down, but while the Del key returns it to 1.0, the screen doesn't follow suit.

So yes, either undefined behaviour, a straight-out bug, or the dreaded undefined variable.
User avatar
No.21206
ICEknight
Tester
Mar 24, 2023, 17:36
Just updated the description, the bug seems to be tied to the Screen Brightness value being 1.
User avatar
No.21228
Kale
Developer
Mar 29, 2023, 16:16
On my experience seldomly brightness/contrast/gamma don't pickup properly, and I have brightness and gamma to non-1. Windows 10, toaplan1.cpp games (outzone).

brightness                0.95
contrast                  1.0
gamma                     0.95
[...]
bgfx_path                 bgfx
bgfx_backend              auto
bgfx_debug                0
bgfx_screen_chains        unfiltered
bgfx_shadow_mask          slot-mask.png
bgfx_lut                  
bgfx_avi_name             auto
User avatar
No.21500
ICEknight
Tester
Jun 2, 2023, 19:57
Just uploaded a new video showing how bug report #8621 also happens at random when changing between bgfx Screen Effects:
User avatar
No.21501
cuavas
Administrator
Jun 2, 2023, 20:02
If you want to help, run the code in a memory analyser and work out where it’s misbehaving. Bumping with irrelevant videos is just going to annoy people. If you actually thought about how software works, it would be obvious why MT08621 is a duplicate of this.
User avatar
No.21502
ICEknight
Tester
Jun 2, 2023, 20:49
I'm just a user reporting issues as I come across them, which is what this platform is for.

If somebody moderating a bug tracker finds it annoying that regular users are not tracing and finding the source of the bugs themselves, I really don't know what to say.
User avatar
No.21503
cuavas
Administrator
Jun 2, 2023, 21:04
There’s a difference between reporting issues and your constant stream of argumentative comments. You need to learn to listen and think. We’ve established that screen adjustments aren’t always applied with BGFX with no clear pattern for when it does or doesn’t happen. Your video adds nothing except making the comments take longer to load and sending web traffic to Google every time this bug is viewed. If you don’t have the skills to further isolate the issue, there’s probably nothing you can add.
User avatar
No.21715
ICEknight
Tester
Aug 29, 2023, 03:24
Just did some more testing and added a list of known cores which show this problem. There's many more than the console-related systems we already knew of, even including the CPS3.
User avatar
No.21719
ICEknight
Tester
Aug 29, 2023, 17:03
Osso pointed out that the cores affected by this bug use bitmap_rgb32 instead of bitmap_ind16 in the screen_update function. This seems to indeed be the common denominator.