Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Regular DMD dots changed after update to 3.6 v.1122 #372

Closed
TXT111 opened this issue Nov 20, 2024 · 32 comments
Closed

Regular DMD dots changed after update to 3.6 v.1122 #372

TXT111 opened this issue Nov 20, 2024 · 32 comments
Labels
bug regression

Comments

@TXT111
Copy link

TXT111 commented Nov 20, 2024

I have come across a strange change to my VPinMame DMD's.... - All of my normal "regular" (non-coloured, non Freezy, non PAC and non Serum based) DMD displays have lost their background dots. E,g. when I press 'F1' to bring up the VPinMame window, the '0' intensity settings used to show background dots if I set this between 8 to 15, but now it shows just like a 'blanket' colouring. They have lost the background dots. The 66% and 33% intensity settings seems to still contain dots. If I switch to 'Use Externall.dll' DMD's (the Freezy, the PAC and the Serum files) these look fine. Is there any setting in DmdDevice.ini file that would affect regular VPinmame DMD's dots? I recently updated my DMDText to 2.3.0 but this was happening before that update.... When I moved back to VPinMame 3.6 v. 992 the dots in the '0' intensity settings showed once again, so it seems like "something" has changed in 1122.
@volkenborn
Copy link
Contributor

I have that too in regular mingw compiles.
It seems the problem started with commit d00eaed ("DMD: fix backward compatibility (VPX renderer, colorization plugins) and clean ups") by @vbousquet on Sep 9.
This was the first time the dots did not look as before. In that commit, the background was all black though as opposed to "all off" pixels. Later commits seem to have changed that once more.
BTW, even for games that have the DMD_NOAA flag set like Phantom Haus, the DMD is anti-aliased by now.

@volkenborn
Copy link
Contributor

Problem is in core_dmd_render_internal: DMD_PAL(0) returns 32 where it should actually return 0.

@volkenborn
Copy link
Contributor

volkenborn commented Nov 20, 2024 •
edited
Loading

@TXT111 Could you please retry with version 1160?
https://github.com/vpinball/pinmame/actions/runs/11930795488

@toxieainc
Copy link
Member

Thanks a lot for looking into this!

@TXT111
Copy link
Author

TXT111 commented Nov 20, 2024 via email

@TXT111
Copy link
Author

TXT111 commented Nov 21, 2024 via email

@volkenborn
Copy link
Contributor

Yes, that's because the antialias factor defaulted to 100 percent in 1159.
I fixed that in build 1160, and edited my post accordingly.

@TXT111
Copy link
Author

TXT111 commented Nov 21, 2024 via email

@volkenborn
Copy link
Contributor

But of course, I also updated the link!

@volkenborn
Copy link
Contributor

https://github.com/vpinball/pinmame/actions/runs/11930795488

@volkenborn
Copy link
Contributor

You'd better follow this issue here: #372

@francisdb
Copy link
Contributor

francisdb commented Nov 21, 2024 •
edited
Loading

Would be useful to have some screenshots for these kinds of issues :-)
You can do a copy-paste in the github issue comment field.

@francisdb
Copy link
Contributor

I was just wondering if this is related to #346 ?

@volkenborn
Copy link
Contributor

Version 1158, before my changes:
image

Version 1162 (current, two more fixes for mini DMDs):
image

@volkenborn
Copy link
Contributor

And here's how it looks if I use my own settings:
dmd_perc0 10
dmd_perc33 50
dmd_perc66 75
dmd_antialias 40

image

@francisdb
Copy link
Contributor

Thanks, that clarifies things. Seems to be unrelated.

@toxieainc
Copy link
Member

Thanks a lot @volkenborn. Now the only thing still on my list regarding output rendering is that somehow dimmed segments render out way too dark in VPM.

@vbousquet
Copy link
Contributor

@volkenborn Thanks a lot for fixing my mess!

@toxieainc Not sure what you are pointing at. The test I made while doing the latest change leads to the capture below. It's Bride of the pinbot's service menu with full luminance on first row, and faded second line (it blinks slowly between two faded levels). It seems right to me.

image

@toxieainc
Copy link
Member

Interesting enough, i currently get this now:
grafik

@toxieainc
Copy link
Member

toxieainc commented Nov 21, 2024 •
edited
Loading

The way too dark thing was maybe only with my own (no local modifications) builds? Have to double check again..

@TXT111
Copy link
Author

TXT111 commented Nov 21, 2024 via email

@volkenborn
Copy link
Contributor

Interesting enough, i currently get this now: grafik

Aha! The dmd_perc values are also applied to the antialiasing of segment digits! That should be changed, only the color tint (dmd_red etc.) should be used.

@volkenborn
Copy link
Contributor

But you're right @toxieainc - All the WPC, GTS3, and Alvin G. games with segment displays are not rendered correctly in VPinMAME!
So there must be some code branch that corrupts them - in console PinMAME, they all look fine.

@vbousquet
Copy link
Contributor

But you're right @toxieainc - All the WPC, GTS3, and Alvin G. games with segment displays are not rendered correctly in VPinMAME! So there must be some code branch that corrupts them - in console PinMAME, they all look fine.

How do you get VPM to render these games ?

@volkenborn
Copy link
Contributor

I started them using the Test function of setup.exe

@volkenborn
Copy link
Contributor

volkenborn commented Nov 22, 2024 •
edited
Loading

And I can get the same bug as @toxieainc with the colors 119,255,119. Only the "off" intensity value changes the luminance.
Also, when using the colors 0,0,255 you can get an even more interesting result:
image

@vbousquet
Copy link
Contributor

The code for rendering in this situation uses a RGB565 LUT instead of the palette like other rendering parts. I can revert this by using the same palette as the one used for faded DMD, but it seems intentional (@toxieainc you added it last march). Perhaps there is something missing to let PinMame handle the bitmap as RGB565 instead of paletted ?

@toxieainc
Copy link
Member

AFAIR i did it like that to support more brightness levels.

@vbousquet
Copy link
Contributor

Yeah, but it looks like PinMame process the data as paletted instead of RGB565. Do you know how to switch that ? Or should we use the DMD palette instead ?

@toxieainc
Copy link
Member

All kinds of weird. Back then when i implemented it like that (i just double checked my notes) it worked as intended with my local VPM build, but not the official github one (lit segments were waaaaay too dark).

The issue above is new (so don't know if related), and i haven't looked into it in detail yet. So i just wonder why it could have ever worked for me then?!

@volkenborn
Copy link
Contributor

volkenborn commented Nov 25, 2024 •
edited
Loading

I can only suggest to remove some #ifdef VPINMAME because it looks just spot-on in regular console. Display test even does alternate runs with full-on and dimmed segments.

@toxieainc
Copy link
Member

At least we should really try to keep using the full available RGB range, as it was such an improvement back then to have really smooth fading.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug regression
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@francisdb @vbousquet @volkenborn @toxieainc @TXT111