http://bugs.winehq.org/show_bug.cgi?id=3292
stefandoesinger@gmx.at changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|wine-binary |wine-gdi-(printing)
------- Additional Comments From stefandoesinger@gmx.at 2006-23-07 14:44 ------- Sadly this is not a direct3d bug, otherwise I would know how to debug it.
My d3d-site investigation shows this: BF1942 draws the text with a user pointer drawprim call, with one texture activated. The texture is a 128x128 DXTN5 texture, which is apparently supposed to hold the fonts. There is nothing special about this surface d3d wise, it is just created, locked and unlocked, then used for drawing.
I suspected a DXTn loading bug and wrote a small function which dumps the unmodified surface content into a .dds file, which can be read by the dxtex.exe utility in the DirectX sdk and quite a few Linux applications too(like kuickshow). Interestingly Battlefield 1942 only fills the surface with a dark gray instead of the text, so I think I can say that the missing fonts are not a problem in the direct3d surface or drawing code.
I suspect that bf1942 generates the font textures at startup and that this fails. I looked at a +font,+gdi,+bitmap trace but I couldn't find anything obvious. I set the bug to wine-gdi as this isn't a binary specific problem.
BTW, I couldn't find any font files in the installation directory of the full version. Interestingly, some in-game fonts work, like the player names when you look at them, or the console (°) or the fps counter('fps 1' in the console). Those fonts are not drawn from the same texture, but the broken in-game fonts are.
-
Wine Bugs