Viewing Issue Advanced Details
|ID||Category [?]||Severity [?]||Reproducibility||Date Submitted||Last Update|
|03719||Graphics||Minor||Always||Feb 7, 2010, 22:57||Nov 6, 2017, 04:50|
|Assigned To||AJR||Resolution||Fixed||OS||Windows XP (32-bit)|
|Version||0.136u2||Fixed in Version||0.192||Build||Normal|
|Summary||03719: megat5a, magat5, megat5nj, mega6, megat3a, megat3, megat3ca, megat3nj, megat3te, megat4a, megat4, megat4te, megat4sn, megat4st: "Run21" game is missing graphics for black-suited cards.|
One of the games within these Megatouch sets, "Run21" is a card game where the object is to have each column add up to 21.
The major graphic error is that "Run21" doesn't display the black suited cards. It does display the red suits normally. The black-suited cards appear as blank cards.
So far as the Megatouch games released by Merit in the '90s I've found that this was the only game within the sets not to be emulated properly. Because this game has the identical behavior across the mentioned sets it appears that Merit simply reused the code for that one game throughout the series.
|Steps To Reproduce||
The ROM set for these games can be loaded as usual. All it takes is to insert a coin, choose the "Run 21" game and start playing it.
Also this game can be viewed in attract mode where the "Run 21" game exhibits the same behavior.
|Additional Information||There are also other card games within these Merit "Megatouch" sets that do display the black suited cards normally. Examples are the "Solitaire", "Power Solitaire", "Royal Flash" and "11 Up" games.|
|Affected Sets / Systems||megat5a, magat5, megat5nj, mega6, megat3a, megat3, megat3ca, megat3nj, megat3te, megat4a, megat4, megat4te, megat4sn, megat4st|
megat50000run21error.png (6,809 bytes) Feb 7, 2010, 23:28
|There are no relationsihp linked to this issue.|
Feb 7, 2010, 23:18
While it's appreciated that you took the effort to report a bug, this is already known. You can usually tell since the driver and all games therein come up with a warning screen which states: "Video Emulation is not 100% accurate" that you must type OK to.
Per our guidelines, I can accept such reports only if it's supported by original PCB pictures or videos depicting the issue. Even a screen shot from MAME would be useful to better illustrate the problem. In general, though, if something is flagged and it's not a regression from a previous MAME version, it's considered not worth reporting.
Feb 7, 2010, 23:30
edited on: Feb 7, 2010, 23:33
Per your request I've submitted the picture of the game in action.
I've also double-checked the problems related to the driver and games in this series. No other reports were specific about this problem.
Now that you have the evidence in front of you, it's proof that this is a major error. Let me know what else you need and I'll do my best to provide more information.
Feb 9, 2010, 00:38
edited on: Feb 9, 2010, 00:40
I took a quick look at the driver, and it's not obvious what the problem is but I'll hazard a guess.
There is a comment about the 'get transparent pen' thing being inaccurate which could be the cause, maybe transparency of the upper layer is based on which pixels have been actively used, not a specfic pen number (which would mean the code would need reworking, to fill the bitmap with an invalid pen to start with, so that pen 0 can be treated as solid)
that would be my best guess anyway, that right now the background and black card symbols of the upper layer are both pen 0, so the card details are rendered as invisible (same colour as the background of the upper layer) and thus it never gets mixed in because pen 0 is filtered out rather than unused areas being filtered out.
I don't really understand the code well enough to be confident in making such a change however.
Again, I don't think the aggressive stance taken on bug reports in the first post help Tafoid, I hadn't seen this issue before, there are no direct comments about it that I can see, and if it wasn't raised I wouldn't be able to speculate what the problem might be.
Nov 6, 2017, 04:49
|After committing 5fba45b0bc24fe41c75c334156a2ee4a5918c4c5 and being directed here by Haze, I think I can explain what went wrong. The new implementation makes it easy to see that the v9938_1's 16-color palette (previously not exposed) defined both 0 and 1 as black. Only the former is supposed to be transparent, though, and get_transpen was failing to distinguish between the two, since they were mapping to the same pen.|