| ID | Category [?] | Severity [?] | Reproducibility | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 03824 | Graphics | Minor | Always | May 1, 2010, 14:41 | May 5, 2010, 06:34 |
| Tester | Scagazza | View Status | Public | Platform | MAME (Self-compiled) |
| Assigned To | Mamesick | Resolution | Fixed | OS | Windows XP (64-bit) |
| Status [?] | Resolved | Driver | |||
| Version | 0.137u3 | Fixed in Version | 0.137u4 | Build | 64-bit |
| Fixed in Git Commit | Github Pull Request # | ||||
| Summary | 03824: hvysmsh: Graphics replaced by black artifacts | ||||
| Description | Some graphics are replaced by black artifacts. For example I'am sure that the zone behind the goalkeeper in the first screenshot must not be black (see the second image take from maws). I'am sure the game is okay last time I played it but I'am not able to say which is the regression version. | ||||
| Steps To Reproduce | Play the games | ||||
| Additional Information | |||||
| Github Commit | |||||
| Flags | |||||
| Regression Version | 0.135u2 | ||||
| Affected Sets / Systems | hvysmsh | ||||
|
Attached Files
|
 0000.png (25,667 bytes) May 1, 2010, 14:41 | ||||
| hvysmsh.png (22,987 bytes) May 1, 2010, 14:46 | |||||
| 0001.png (23,781 bytes) May 1, 2010, 14:47 | |||||
| 0002.png (10,612 bytes) May 1, 2010, 14:48 | |||||
 No.06026
Haze Senior Tester
May 1, 2010, 15:48
|
probably broke when it was converted to devices (wrong palette base on one layer?) |
|---|---|
 No.06027
M.A.S.H. Senior Tester
May 1, 2010, 19:28
|
The regression version is MAME 0.135u2. - 0.135u2: Fabio Priuli converted the DECO156 driver to use EEPROM device. |
|
No.06030
Haze Senior Tester
May 2, 2010, 14:01
|
It's not going to have anything to do with EEPROMs. |
|
No.06036
etabeta Developer
May 2, 2010, 21:46
edited on: May 2, 2010, 21:55
|
if the regression happened before 0.136, though, decoic16 device code is not the culprit either... EDIT: if I had to bet some money on the source of the bug, I would choose the generic paletteram introduced (not by me) in that version. the driver uses both generic.paletteram.u16 and generic.paletteram.u32: could there be any case where the driver picks up the wrong one? I will take a deeper look in the next few days, if no one beats me to fix it... |
 No.06040
Mamesick Senior Tester
May 3, 2010, 16:27
|
this line is absolutely useless and is the cause of the bug:50 machine->generic.paletteram.u16 = auto_alloc_array(machine, UINT16, 0x1000/2);and consequentially the following: 55 state_save_register_global_pointer(machine, machine->generic.paletteram.u16, 0x1000/2);There's no need to allocate the 16-bit palette ram since the game uses a 32-bit one. |
 No.06041
hap Developer
May 3, 2010, 18:40
|
fix confirmed, I think it's a leftover from when videoram, colorram, spriteram, paletteram were still global, changed november 2009 |
|
No.06042
etabeta Developer
May 4, 2010, 08:21
|
not exactly. the precise problem is that the driver was defining both the correct paletteram32 and a second paletteram16 which was previously unused and therefore harmless (maybe a leftover of some testing or outdated code). with the change to machine->generic.paletteram the unused paletteram16 became the ones used by the driver. in any case, thanks Mamesick for investigating this and finding the exact fix. |