03356: driftout: Player car flickers on DirectX renderer + multithreading

NOTE: In 0.139, games using OKI were broken when using Save State.
This issue has been fixed in 0.139u1. Please check 3969 for more info.

Viewing Issue Advanced Details [ Jump to Notes ]

[ View Source: taito_f2.c ]

Category [?]

Severity [?]

Reproducibility

Date Submitted

Last Update

03356

Graphics

Minor

Always

2009-07-25 19:12

2009-09-12 17:11

Tester

hap

View Status

Public

Assigned To

Platform

MAME (Self-compiled)

Priority

normal

Resolution

Reopened

Status [?]

Acknowledged

Driver

taito_f2.c

Projection

None

Version

0.133

ETA

None

Fixed in Version

Build

Summary

03356: driftout: Player car flickers on DirectX renderer + multithreading

Description

The player car always flickers black

Steps To Reproduce

play the game

Additional Information

Flags

Regression Version

0.127u6

Affected Sets

driftout

Old BugID

Attached Files

drift_black.jpg (14,816 bytes) 2009-07-25 23:34

Relationships

Notes
(04698) Haze (Senior Tester) 2009-07-25 19:56	there is a black flickering shadow which looks normal, I don't see any obvious glitches?

(04701) hap (Developer) 2009-07-25 20:24	Ahh, I see now that it only happens with mame.ini "multithreading" set to 1, strange. Can you confirm?

(04703) Firewave (Senior Tester) 2009-07-25 21:19	I cannot confirm. Can you try to produce snapshots that show the differences?

(04704) hap (Developer) 2009-07-25 23:40	Another thing I just found out: it only happens on DirectX hardware renderers, and the effect is not internal: F12 (snapshot) outputs normal data. So the problem's on my end due to a vidcard driver bug, or a bug in MAME's renderer. Very strange though that, in this game, it only affects the car. Does MAME use multiple textures? eg. one for each layer.

(04705) Tafoid (Administrator) 2009-07-26 01:59	It's likely the your driver and not MAME. I tried with and without -mt switch and it looks fine (mamedev 0.133 - 32 bit build). Closing this out. If you find out anything more regarding this, contact me privately.

(04775) Tafoid (Administrator) 2009-08-07 00:11	Reopened on word that there may be a renderer issue that was found.

(04776) hap (Developer) 2009-08-07 01:08 edited on: 2009-08-07 01:09	Thanks Tafoid. The problem started after the palette/renderer changes in 0.127u6. render.c function add_container_primitives CONTAINER_ITEM_QUAD section changed prim->texture.palette assignment to texture_get_adjusted_palette. In the case of this odd driftout bug here, palette_entry_list_adjusted under TEXFORMAT_PALETTE16 returns the wrong palette if multithreading is set on for me, the actual cause is unknown to me, and may have existed before 0.127u6. Changing this part to pre-0.127u6 behaviour fixes the problem for me (that is, switching around machine palette check and no-adjustment check), I don't know if this workaround is harmless or not: whether or not the order of these checks matters. In short, I'm still clueless about the cause (at least unrelated to 03379), but pretty sure the problem's in MAME, not videocard driver related.

(04835) hap (Developer) 2009-08-20 19:48 edited on: 2009-08-20 20:06	Ok, I dug into it some more. The cause is simple and can affect any game with multithreading on. If multithreading is on, rendering uses the bitmaps from the driver VIDEO_UPDATE containing pen data that points to the current palette, not the palette contents at the time of the update. (some more info) [21:50] <n_n> rename your mame.ini, then do "mame driftout -multithreading", and play the game [21:52] <Tafoid> Hap - same as tested before - no repro with or without -mt swtich [21:52] <n_n> it probably varies per computer [21:53] <n_n> depending on the time the renderer fetches palette data [21:54] <n_n> driftout rewrites the palette in mid-frame [21:54] <n_n> if the renderer gets the palette when driftout's not yet done, it will be glitchy

(04838) hap (Developer) 2009-08-22 18:00 edited on: 2009-09-12 17:10	The specific effect in driftout (car flickering) was fixed with a workaround. The fact that renderer update is not synced to video update when mt is on remains.

(04903) Tafoid (Administrator) 2009-09-04 15:08	Reopened this bug so that it can get some user/developer discussion as well as finding a way to fix the underlaying problem, rather than patching the specific instance in question.

(04904) Haze (Senior Tester) 2009-09-04 15:48 edited on: 2009-09-04 15:50	I requested this be reopened because to me it's a core issue rather than being something driver specific. The kludge in the driver might work around the issue in this case, but it's just as liable to appear elsewhere in the same situation, and hacking around the issue on a per driver basis is not the correct solution. If I was cleaning the driver the kludge is something I'd probably remove as it really shouldn't be needed and doesn't document the hardware...

(04905) hap (Developer) 2009-09-04 16:06	It annoyed me :P Yes, you're right that this workaround is ugly and doesn't document the hardware. A better fix for this driver, suggested by Kale, would be to use partial updates whenever a game writes to video hardware in mid-frame.

(04907) Haze (Senior Tester) 2009-09-04 20:26 edited on: 2009-09-04 20:26	I'm not even convinced that a better fix would be to use partial updates. The underlying concern is that MAME handles an identical situation in a different way depending on if the -mt switch is specified. This is a problem that could potentially affect any correctly coded driver, and workarounds (be it buffering the palette, or using partial updates) _SHOULD NOT_ be in the driver. Drivers should behave in the same way, and the final output should be the same regardless of switches.

(04938) hap (Developer) 2009-09-12 17:11	I reverted the driftout kludge