dmd-extensions
dmd-extensions copied to clipboard
freezy
Pinball FX3 volume 6. Not working
PFX3 WMS VOL. 6 New alphanumeric games from PFX3 don't function, all other PFX3 boards functions. Please advise
A possible option for this is finding out where in memory the alphanumeric characters are stored and emulating them to the DMD. The only problem I can currently foresee is that we need to know X/Y positions of each digit.
Quick check into pinball FX3 showed that when not showing the backbox, the display has 2 rows and a fixed amount of character for all the 3 alphanumeric tables. If I have some time I can take a look at what the data is pointing to (my DMD widget stopped working since upgrading to VS2019/newer QT), wishful thinking here, but if that data is valid and it's pixel data and the resolution is the same, this should be a relatively easy fix :)
As described above, DMDEXT doesn't display anything for the three new FX3 alphanumeric games. I'm using an LCD panel not a real DMD. I also noticed that although DMDEXT still works with FX3 DMD games, it doesn't pick up the correct color. For example, in the FX3 game Jaws, the DMD dots should be blue but DMDEXT is displaying them as amber. DMDEXT handled this and displayed the correct color prior to the Pinball FX3 Volume 6 update.
As described above, DMDEXT doesn't display anything for the three new FX3 alphanumeric games. I'm using an LCD panel not a real DMD. I also noticed that although DMDEXT still works with FX3 DMD games, it doesn't pick up the correct color. For example, in the FX3 game Jaws, the DMD dots should be blue but DMDEXT is displaying them as amber. DMDEXT handled this and displayed the correct color prior to the Pinball FX3 Volume 6 update.
I believe a possible culprit is this switch statement: https://github.com/freezy/dmd-extensions/blob/master/LibDmd/Input/PinballFX/PinballFX3MemoryGrabber.cs Lines 141-159, this is not the nicest way of doing this, especially if more tints get added. I wanted to submit a patch for this, but never got around to doing it, but the way I handle this is: https://github.com/BlackStar-EoP/dmdwidget/blob/master/fx3process.cpp @129 I.e. fetch the color from memory and create a color object from this for Qt, this is future proof.
I'm not getting any varying colors at all from dmdext's switch statement nor @BlackStar-EoP 's code. Are we sure those memory offsets are correct? If I change the ingame dmd color I'm not getting any different values from colorCode nor from blackstar's r g b variables...
Ideally we would like to have the actual segment data, For the DMD we're grabbing the texture, which works well because we can easily extract the pixel values from that. However, segment data is probably stored differently, so we'll need to find the right position again. I have dropped a message to NoEx.
@BlackStar-EoP Patch welcome.
@freezy did you get any response from NoEx ? Or can you implement the patch of BlackStar-eop ?
Just tested this using DMDEXT 1.10.2. The issue persists. DMDEXT doesn't display anything for FX3 alphanumeric games on a virtual DMD (i.e. LCD display). Also, with FX3 DMD games, DMDEXT doesn't render the correct color. For example, in an FX3 game like Jaws, the DMD dots should be blue. DMDEXT displays amber dots. DMDEXT detected and displayed the correct color prior to the Pinball FX3 Volume 6 update that introduced alphanumeric games.
Just tested this using DMDEXT 1.10.2. The issue persists. DMDEXT doesn't display anything for FX3 alphanumeric games on a virtual DMD (i.e. LCD display). Also, with FX3 DMD games, DMDEXT doesn't render the correct color. For example, in an FX3 game like Jaws, the DMD dots should be blue. DMDEXT displays amber dots. DMDEXT detected and displayed the correct color prior to the Pinball FX3 Volume 6 update that introduced alphanumeric games.
As far as I can remember, the amber color is the default color if the memory for the color cannot be read. I don't really have a patch at the moment, and it's all a bit foggy. The issue I had with the current implementation is that it's a table and thus by definition is not future-proof on its own. In my own DMD widget I took the 32 bit color, and made it in such a way that if FX3 introduces a new color, it will automatically work. As far as I can tell, FX3 will not be updated anymore so my implementation is pointless.
As stated above, the memory offset for the color table likely changed. I have to look into the code again to see what happened, but I think I have a global idea of how their internal data structure works. If they added a few members into their classes all the offsets change so it's pretty likely the offset is just a couple of bytes from where the current implementation tries to read this.
I might have a look at this this week when I've had a bit more sleep but I can't make any promises. It's just such a shame that Zen never implemented an API where we could subscribe to to get function calls whenever the DMD updates. I understand it from their point of view though since that's yet another subsystem they need to maintain.