https://bugs.winehq.org/show_bug.cgi?id=42585
Bug ID: 42585 Summary: Final Fantasy V Corrupt Fonts Product: Wine Version: 2.3 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs@winehq.org Reporter: mrdeathjr28@yahoo.es Distribution: ---
Created attachment 57509 --> https://bugs.winehq.org/attachment.cgi?id=57509 backtrace-finalfantasyv
Final Fantasy V show corrupted fonts with wine 2.3 and before versions
Added too backtrace
https://bugs.winehq.org/show_bug.cgi?id=42585
mrdeathjr28@yahoo.es changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |mrdeathjr28@yahoo.es
https://bugs.winehq.org/show_bug.cgi?id=42585
--- Comment #1 from Rafał Mużyło galtgendo@o2.pl --- Somewhat surprisingly, this isn't an opengl bug, but a gdiplus one.
There's a next-to-trivial hack that fixes this problem, but it looks like something that *might* break other things.
https://bugs.winehq.org/show_bug.cgi?id=42585
tokktokk fdsfgs@krutt.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |fdsfgs@krutt.org
https://bugs.winehq.org/show_bug.cgi?id=42585
Sagawa sagawa.aki+winebugs@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |sagawa.aki+winebugs@gmail.c | |om
--- Comment #2 from Sagawa sagawa.aki+winebugs@gmail.com --- The backtrace is similar to Bug 43475 which was fixed in Wine 2.15. Please retest with Wine 3.0 or recent development build.
https://bugs.winehq.org/show_bug.cgi?id=42585
--- Comment #3 from Rafał Mużyło galtgendo@o2.pl --- That backtrace has likely very little to do with text corruption. It's likely simply because this bug was opened after bug 42381 was closed and the reporter attached the old backtrace.
Though, while still unrelated to the text problem, there *is* some major raciness either in the app or wine (hard to tell one way or another) wrt. setting the language. Not sure if it's related to that, but crashes on startup happen too.
That raciness problem is that if you manually set the language to 7 (Japanese) sometimes it gets correctly set and sometimes it doesn't (checked as a curio). Though it just might be that the executable doesn't fully support CJK, even though the required resources are present. (yet, I still think it should be deterministic, not random)
Still let's try to see if there's a proper fix for the text first.
https://bugs.winehq.org/show_bug.cgi?id=42585
--- Comment #4 from Rafał Mużyło galtgendo@o2.pl --- ...also, after the corruption is fixed, 'g' is an interesting case (that is easiest to observe the problem on) - can't say if it's game design or a wine bug, but the lowest part part is visibly clipped...
https://bugs.winehq.org/show_bug.cgi?id=42585
--- Comment #5 from Rafał Mużyło galtgendo@o2.pl --- Updating with more recent info: instead of the mentioned hack, it would seem that the problem is in a slightly different place - not in GdipDrawString (actually in one of its subfunctions), but in GdipGraphicsClear.
Note a detail about those calls: clear color is 0xffffff, not 0xffffffff. Meaning, that clears with a transparent color are supposed to do something, instead - as it's the case now - be silently ignored. Here, resetting the color to 0xff000000 (in case of image being GpBitmap) offers what seems to be proper result, but I have no idea what should be the generic case.
https://bugs.winehq.org/show_bug.cgi?id=42585
Steven Wilson sw-wine@alpha.germy.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |sw-wine@alpha.germy.net
--- Comment #6 from Steven Wilson sw-wine@alpha.germy.net --- (Wine development newbie here; I've been using it for years, but rarely dug into the code)
I'm far from a GDI(+) expert, but from the documentation I would expect that the pixels in the target GpGraphics are all set to the specified color, including alpha if applicable to the pixel format.
I tried to accomplish this by changing the compositing mode of the GpGraphics to CompositingModeSourceCopy in GdipGraphicsClear(), but saw no visible change in behavior with Final Fantasy V. Right now my best guess is that in Wine's gdiplus implementation, the compositing mode is ignored and GDI+ draw operations use the equivalent of GDI's AC_SRC_OVER BlendOp. This seems consistent with the behavior of some sample code that demonstrates use of CompositingModeSourceCopy [1]. What exactly all of this means for the management of this bug is well above my pay grade here.
[1] https://docs.microsoft.com/en-us/windows/desktop/gdiplus/-gdiplus-using-comp...
https://bugs.winehq.org/show_bug.cgi?id=42585
--- Comment #7 from Rafał Mużyło galtgendo@o2.pl --- So, years later...
Anyway, with bug 30506 fixed by 3c8784bf9c1a897de021587437c5ec4f648c84a1, the (seemingly correct) fix for this problem seems to be adding 'if (!(src_color & 0xff000000)) src_color = 0;' condition to the '(comp_mode == CompositingModeSourceCopy)' branch.
Bug 30506 seem to confirm it for transparent black, this one for transparent white, so it's likely it's simply for transparent case.
https://bugs.winehq.org/show_bug.cgi?id=42585
Damjan Jovanovic damjan.jov@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|-unknown |gdiplus CC| |damjan.jov@gmail.com Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Keywords| |patch
--- Comment #8 from Damjan Jovanovic damjan.jov@gmail.com --- Thank you Rafał, that's probably it!
When I was developing 3c8784bf9c1a897de021587437c5ec4f648c84a1 and re-enabling some related broken/disabled gdiplus unit tests, I was wondering why a few of them still weren't working. If fully transparent colors are treated as black, that might be the answer. I'll test this later.
https://bugs.winehq.org/show_bug.cgi?id=42585
--- Comment #9 from Damjan Jovanovic damjan.jov@gmail.com --- Created attachment 66542 --> https://bugs.winehq.org/attachment.cgi?id=66542 Patch to make fully transparent pixels black
Can someone please try this patch? It should draw all fully transparent pixels as black, which also fixes a unit test.
https://bugs.winehq.org/show_bug.cgi?id=42585
Vijay Kamuju infyquest@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED CC| |infyquest@gmail.com Fixed by SHA1| |99a171981cc42970f0caee69e1c | |eb0e810d5955f Status|NEW |RESOLVED
--- Comment #10 from Vijay Kamuju infyquest@gmail.com --- Fix committed will be present in 5.4
https://bugs.winehq.org/show_bug.cgi?id=42585
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #11 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 5.4.
https://bugs.winehq.org/show_bug.cgi?id=42585
Michael Stefaniuc mstefani@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|--- |5.0.x
https://bugs.winehq.org/show_bug.cgi?id=42585
Michael Stefaniuc mstefani@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|5.0.x |---
--- Comment #12 from Michael Stefaniuc mstefani@winehq.org --- Removing the 5.0.x milestone from bug fixes included in 5.0.1.
https://bugs.winehq.org/show_bug.cgi?id=42585
--- Comment #13 from Steven Wilson sw-wine@alpha.germy.net --- As far as I can tell, rather than this problem really being fixed, the text is now just replaced with black boxes. Has anyone else seen different behavior?
https://bugs.winehq.org/show_bug.cgi?id=42585
--- Comment #14 from Steven Wilson sw-wine@alpha.germy.net --- Never mind; this does seem to be fixed. I wasn't running the code I thought I was; what I saw was probably the effect of the fix for Bug 30506 without also having the fix attached to this bug.
-
wine-bugs＠winehq.org -
WineHQ Bugzilla