http://bugs.winehq.org/show_bug.cgi?id=21534
Summary: TF2 stops when pushing on the key : "Display multiplayer scores" key (tab key by default) Product: Wine Version: 1.1.37 Platform: x86-64 OS/Version: Linux Status: UNCONFIRMED Severity: critical Priority: P2 Component: -unknown AssignedTo: wine-bugs@winehq.org ReportedBy: mokrad@gmail.com CC: mokrad@gmail.com
TF2 stops when pushing on the key : "Display multiplayer scores" key (tab key by default)
http://bugs.winehq.org/show_bug.cgi?id=21534
mokrad mokrad@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|TF2 stops when pushing on |TF2 stops when pushing on |the key : "Display |the key : "Display |multiplayer scores" key |multiplayer scores" (tab |(tab key by default) |key by default)
http://bugs.winehq.org/show_bug.cgi?id=21534
Clément Danjou clement.danjou@vinaigredemiel.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Ever Confirmed|0 |1
--- Comment #1 from Clément Danjou clement.danjou@vinaigredemiel.com 2010-01-29 13:21:19 --- *** This bug has been confirmed by popular vote. ***
http://bugs.winehq.org/show_bug.cgi?id=21534
Clément Danjou clement.danjou@vinaigredemiel.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |clement.danjou@vinaigredemi | |el.com
--- Comment #2 from Clément Danjou clement.danjou@vinaigredemiel.com 2010-01-29 13:22:44 --- Same problem here: hit tab or win a round and TF2 crash since last update.
http://bugs.winehq.org/show_bug.cgi?id=21534
--- Comment #3 from mokrad mokrad@gmail.com 2010-01-29 13:26:42 --- I have this bug since the valve update for TF2 dated the 27th january.
http://bugs.winehq.org/show_bug.cgi?id=21534
Michael Abbott michael@araneidae.co.uk changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |michael@araneidae.co.uk
--- Comment #4 from Michael Abbott michael@araneidae.co.uk 2010-01-29 17:26:39 --- Yes, I can confirm this. As of the most recent update (27th January?) pressing Tab kills TF2. I think also that TF2 dies when the associated end-of-round player state screen comes up (this is identical to the screen summoned by pressing Tab).
I have reported this in game as a bug, but hey, I guess it's really a Wine issue.
http://bugs.winehq.org/show_bug.cgi?id=21534
Vitaliy Margolen vitaliy@kievinfo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Severity|critical |normal
--- Comment #5 from Vitaliy Margolen vitaliy@kievinfo.com 2010-01-29 21:31:10 --- Attach (as a plain text file) complete terminal output. If it doesn't have the crash (since Steam catches that and runs memory dump on it) run winedbg on the mem dump TF2 generates (look in it's directory for .mdmp files).
http://bugs.winehq.org/show_bug.cgi?id=21534
--- Comment #6 from mhdevel@gmail.com 2010-01-30 03:03:40 --- Created an attachment (id=25959) --> (http://bugs.winehq.org/attachment.cgi?id=25959) a winedbg log of the mdmp-file
http://bugs.winehq.org/show_bug.cgi?id=21534
--- Comment #7 from Michael Abbott michael@araneidae.co.uk 2010-01-30 03:48:05 --- Yes, my winedbg output is pretty much identical. As it's so small, I'm including it inline:
$ winedbg hl2_4097_crash_2010_1_29T20_9_47C0.mdmp WineDbg starting on minidump on pid 0046 hl2.exe was running on #1 Intel Pentium 4 or AMD Athlon64 (0.9985) CPU on Windows XP (2600) Register dump: CS:0073 SS:007b DS:007b ES:007b FS:0033 GS:003b EIP:0e8254bc ESP:0033de34 EBP:0033de8c EFLAGS:00010286( R- -- I S - -P- ) EAX:98d16200 EBX:00000042 ECX:0033df38 EDX:00000042 ESI:0e8c8b2c EDI:0e8c8b10 Stack dump: 0x0033de34: 00000080 0e8c8b10 00000042 0e835dcf 0x0033de44: 0b42d012 0033de78 033cc450 00000033 0x0033de54: 00000000 033cc47c 0e8367be 00000013 0x0033de64: 00000000 0e8c8b10 0033df58 0033df84 0x0033de74: 033cc47c 00000033 00330000 68440881 0x0033de84: 0e8c8b10 ffffffff 0033df58 0e825b8f 0006: sel=0037 base=00000000 limit=00000000 32-bit r-- Backtrace: =>0 0x0e8254bc in vguimatsurface (+0x54bc) (0x0033de8c) 1 0x0e825b8f in vguimatsurface (+0x5b8f) (0x0033df58) 2 0x0e825d80 in vguimatsurface (+0x5d80) (0x0033dfbc) 3 0xffffffff (0x00000000) WineDbg starting on pid 0046
http://bugs.winehq.org/show_bug.cgi?id=21534
mhdevel@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |mhdevel@gmail.com
--- Comment #8 from mhdevel@gmail.com 2010-01-30 09:12:56 --- On low resolutions+windowed mode the tab key works for me: Works on: 640x480, 800x600, 1024x768. (all windowed) Crash on 1280x1024 (windowed). Crash on 2048x1152 (fullscreen), 1920x1080 (windowed)
http://bugs.winehq.org/show_bug.cgi?id=21534
--- Comment #9 from Vitaliy Margolen vitaliy@kievinfo.com 2010-01-30 11:58:33 --- Does it still work with older Wine version(s)?
http://bugs.winehq.org/show_bug.cgi?id=21534
--- Comment #10 from Michael Abbott michael@araneidae.co.uk 2010-01-30 14:06:18 --- (In reply to comment #8)
On low resolutions+windowed mode the tab key works for me: Works on: 640x480, 800x600, 1024x768. (all windowed) Crash on 1280x1024 (windowed). Crash on 2048x1152 (fullscreen), 1920x1080 (windowed)
Well, something is rather interesting: I tried 1024x768 (windowed) and it worked, tried 1280x1024 (also windowed) and it also worked ... until I switched to a different map! Maybe a particular user icon? In which case the resolution changing is a red herring...
(In reply to comment #9)
Does it still work with older Wine version(s)?
Can you suggest particular versions to try? Certainly the .36 to .37 upgrade made no difference, and the problem is new with the Valve update -- so it's not, on the face of it, a regression as such.
By the way, the Shift-Tab key (don't know what that is bound to) always crashed TF2 for me, at least in the last several months.
http://bugs.winehq.org/show_bug.cgi?id=21534
mutantmonkey+bugs@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |mutantmonkey+bugs@gmail.com
--- Comment #11 from mutantmonkey+bugs@gmail.com 2010-01-30 14:13:28 ---
By the way, the Shift-Tab key (don't know what that is bound to) always crashed TF2 for me, at least in the last several months.
The Shift-Tab key is bound to Steam Community In-Game by default, which does not work in Wine.
http://bugs.winehq.org/show_bug.cgi?id=21534
--- Comment #12 from Michael Abbott michael@araneidae.co.uk 2010-01-31 04:19:44 --- (In reply to comment #10)
Maybe a particular user icon?
Not this. Tried a local map, 1280x1024 resolution, immediately crashed on Tab. Looks like this resolution is borderline for whatever the problem is.
http://bugs.winehq.org/show_bug.cgi?id=21534
--- Comment #13 from Michael Abbott michael@araneidae.co.uk 2010-01-31 04:58:37 --- (In reply to comment #9)
Does it still work with older Wine version(s)?
Well, a downgrade to 1.1.31 makes no difference.
http://bugs.winehq.org/show_bug.cgi?id=21534
--- Comment #14 from mokrad mokrad@gmail.com 2010-02-06 03:39:30 --- I played on TF2 with wine since wine version 0.9.56 (I never player in windows on my computer). Due to this bug, It's the first time that I cannot play on TF2. The game stops when pushing on the key : "Display multiplayer scores" and It stops at the end of the round. In my opinion, this bug is due to a valve update and not to a wine change. What can I do to help you to solve this very critical bug ?
http://bugs.winehq.org/show_bug.cgi?id=21534
Felix Zielcke fzielcke@z-51.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |fzielcke@z-51.de
http://bugs.winehq.org/show_bug.cgi?id=21534
--- Comment #15 from sgrunt smelenchuk@gmail.com 2010-02-09 00:02:56 --- I can usually avoid a crash by bringing up the console immediately after connecting to a server, then pressing tab while at the team select screen - the scores screen renders largely fine except that the team score counters aren't rendered.
Similarly, having the scores screen open at the end of around will occasionally (but not consistently) prevent a crash.
Given the visual anomaly of the team score counters not rendering, and that that's common between the two screens, I suspect that issues can be traced there.
http://bugs.winehq.org/show_bug.cgi?id=21534
--- Comment #16 from mokrad mokrad@gmail.com 2010-02-09 11:22:12 --- (In reply to comment #15)
I can usually avoid a crash by bringing up the console immediately after connecting to a server, then pressing tab while at the team select screen - the scores screen renders largely fine except that the team score counters aren't rendered.
Your trick to avoid this bug is true but randomly the game crash on tab key pushing during playing. Your trick don't avoid at 100% this bug. it's a strange bug.
Similarly, having the scores screen open at the end of around will occasionally (but not consistently) prevent a crash.
Given the visual anomaly of the team score counters not rendering, and that that's common between the two screens, I suspect that issues can be traced there.
Can you clarify what do you want to explain ("Given the visual anomaly of the team score counters not rendering") ?
http://bugs.winehq.org/show_bug.cgi?id=21534
sgrunt smelenchuk@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |smelenchuk@gmail.com
--- Comment #17 from sgrunt smelenchuk@gmail.com 2010-02-10 09:50:58 --- (In reply to comment #16)
Given the visual anomaly of the team score counters not rendering, and that that's common between the two screens, I suspect that issues can be traced there.
Can you clarify what do you want to explain ("Given the visual anomaly of the team score counters not rendering") ?
Next to the team names at the top of the score board, there is supposed to be a large numeral indicating the current score of that team. In previous versions of the game this has rendered fine, but as of the previously mentioned patch it no longer displays (at times when it does not result in a crash).
http://bugs.winehq.org/show_bug.cgi?id=21534
sgrunt smelenchuk@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|smelenchuk@gmail.com |
http://bugs.winehq.org/show_bug.cgi?id=21534
--- Comment #18 from mutantmonkey+bugs@gmail.com 2010-02-13 17:40:42 --- I'm not sure if this is helpful, but the game does not crash for me when I run it in windowed mode, even at high resolutions.
http://bugs.winehq.org/show_bug.cgi?id=21534
--- Comment #19 from mhdevel@gmail.com 2010-02-14 02:17:35 --- After the last updates of TF2 i tested again:
1280x960 works 1280x1024 crashes
1360x768 works 1920x1080 crashes
1440x900 works 1600x1024 crashes
my conclusion: it crashes if the height of the resolution is equal to or higher than 1024 pixels. i assume that all resolutions will work in fullscreen mode if the height of resolution is lower than 1024 px, but i only tried 1360x768.
can anyone confirm this?
http://bugs.winehq.org/show_bug.cgi?id=21534
Jeff Cook cookiecaper@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |cookiecaper@gmail.com
--- Comment #20 from Jeff Cook cookiecaper@gmail.com 2010-02-16 07:40:03 ---
can anyone confirm this?
I can't confirm it conclusively because my tests were brief, but I got similar results. At 1920x1080, the game crashes on scoreboard display, but at 1152x864 there didn't seem to be a problem displaying it.
http://bugs.winehq.org/show_bug.cgi?id=21534
--- Comment #21 from Henri Verbeet hverbeet@gmail.com 2010-02-16 10:16:59 --- (In reply to comment #14)
In my opinion, this bug is due to a valve update and not to a wine change. What can I do to help you to solve this very critical bug ?
Can anyone verify if this does / doesn't happen on Windows with a similar configuration?
http://bugs.winehq.org/show_bug.cgi?id=21534
--- Comment #22 from mokrad mokrad@gmail.com 2010-02-16 12:26:02 ---
Can anyone verify if this does / doesn't happen on Windows with a similar configuration ?
Not happen in windows (works fine)
http://bugs.winehq.org/show_bug.cgi?id=21534
--- Comment #23 from Michael Abbott michael@araneidae.co.uk 2010-02-26 14:16:18 --- Can confirm this bug still present, wine version 1.1.39, latest version of TF2, even latest version of Steam Beta UI:
Works ok with resolution 1024x768 Crashes half of the time with resolution 1280x1024.
Probably need to bring the graphics driver into this: GeForce 9400 GT with whatever drivers come with Ubuntu 9.10.
http://bugs.winehq.org/show_bug.cgi?id=21534
--- Comment #24 from Stuart Freeman stuart@tyro.homelinux.com 2010-02-26 20:53:28 --- Created an attachment (id=26510) --> (http://bugs.winehq.org/attachment.cgi?id=26510) game console log for a crashed session
I don't know if this will help, but I'm attaching the log from the in-game console leading up to a crash. Crashed sessions always seem to end with ~1000 of these "Reference Count for Material foo != 0" messages.
http://bugs.winehq.org/show_bug.cgi?id=21534
alexandre alexand69580@yahoo.fr changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |alexand69580@yahoo.fr
--- Comment #25 from alexandre alexand69580@yahoo.fr 2010-03-13 03:32:16 --- i had the same problem, with wine .40, i've changed it to .39 and no problems in 1280x1024 :D
http://bugs.winehq.org/show_bug.cgi?id=21534
--- Comment #26 from Michael Abbott michael@araneidae.co.uk 2010-03-13 13:36:58 --- (In reply to comment #25)
i had the same problem, with wine .40, i've changed it to .39 and no problems in 1280x1024 :D
Alas, I'm pretty sure there's no regression, I've already noted (#23) that .39 crashes for me. I think it's more likely that with 1280x1024 you're being lucky; certainly my experience is that below this resolution the crash doesn't happen, above this resolution it always happens, but at 1280x1024 the game crashes some of the time.
No ideas from developers or suggestions for investigation?
http://bugs.winehq.org/show_bug.cgi?id=21534
--- Comment #27 from alexandre alexand69580@yahoo.fr 2010-03-14 09:47:40 --- but i crash with .40 and not with .39 :S .
(i always crash but more later, because of alsa apparently, ESD have, in the past, resolved this problem :) )
ps: yes i'm french, if you find some mistakes
http://bugs.winehq.org/show_bug.cgi?id=21534
edward savage epssyis@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |epssyis@gmail.com
--- Comment #28 from edward savage epssyis@gmail.com 2010-03-29 00:27:43 --- (In reply to comment #26)
Alas, I'm pretty sure there's no regression, I've already noted (#23) that .39 crashes for me. I think it's more likely that with 1280x1024 you're being lucky; certainly my experience is that below this resolution the crash doesn't happen, above this resolution it always happens, but at 1280x1024 the game crashes some of the time.
No ideas from developers or suggestions for investigation?
The crash is reproducible in 1.1.30 and Steam does not appear to start in versions older than this any more (at least 28-29) so it is pretty safe to say there has been no regression.
A work around for the tab crash issue is to enable the Minimal HUD option under Options -> Multiplayer -> Advanced and then changing to an alternative HUD like Flame. Ensure you've enabled Minimal HUD first and you backup your original Resources folder (the script folder is new). You can download Flame here; http://code.google.com/p/flamehud/downloads/list
Mitigating the automatic tab crash shows this bug to be closely related to how many users are on a server. A friend and I played using Ubuntu and Flame for almost a hour without a crash on a server with 4-6 players per side. On the same server we invited some extra friends bumping up each side to 8-12 players. The increased numbers resulted in an unplayable amount of crashes for the Linux players (5 of us) and no crashes for the Windows players.
In short a server with less than ten people will not normally crash at the end of a round or on press of tab whereas a server with twenty people will crash in both instances in almost all cases.
I started a discussion of this issue on the Steam TF2 forums in the bug thread which you can follow here; http://forums.steampowered.com/forums/showthread.php?p=14050785&posted=1...
In the same place that the Minimal HUD is enabled there is an option to Disable MOTD which should mitigate the crash on server load a lot of people were having issues with.
The console log from a complete TF2 run to crash in Wine 1.1.30 is here; http://pastebin.com/SbDH5YCx
http://bugs.winehq.org/show_bug.cgi?id=21534
rasmus.ry@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |rasmus.ry@gmail.com
--- Comment #29 from rasmus.ry@gmail.com 2010-04-01 15:48:44 --- I'm getting the same backtrace as in #6 and #7.
With similar behavior: 1024x768 crashes randomly over longer periods and 1280x1024 crashes randomly over shorter periods.
This is with Wine 1.1.41 and nvidia 195.36.15 on ubuntu 9.10 x86_64. Tf2 is running at dxlevel 81.
I've checked the backtrace addresses and the error is occouring during lookup in an internal (source engine) font related data structure. If we unwind the stack dump in #7, we have the return address as the topmost word (0e825b8f), then a saved register (0033df58), and a local variable (ffffffff). This local variable is used in the lookup which generates the access violation causing the minidump.
This variable is intended to index into font/character heights of <16, <32, <64 and <128. It being -1 means that the font/character being worked on exceeds the expected heights.
http://bugs.winehq.org/show_bug.cgi?id=21534
--- Comment #30 from rasmus.ry@gmail.com 2010-04-02 06:28:30 --- Created an attachment (id=27158) --> (http://bugs.winehq.org/attachment.cgi?id=27158) Log of font creation involving HalfLife2 font
http://bugs.winehq.org/show_bug.cgi?id=21534
--- Comment #31 from rasmus.ry@gmail.com 2010-04-02 06:29:17 --- Created an attachment (id=27159) --> (http://bugs.winehq.org/attachment.cgi?id=27159) Log of font creation involving TF2 font
http://bugs.winehq.org/show_bug.cgi?id=21534
--- Comment #32 from rasmus.ry@gmail.com 2010-04-02 06:32:07 --- I've been going through a log of the font channel, looking for fonts which may be exceeding the upper limit of 127.
At 127 I find the following fonts: "HalfLife2" (halflife2.ttf), "Tahoma", "Courier New" and "TF2" (tf2.ttf).
Out of these, HalfLife2 and TF2 returns text metrics (through trace:font:GetTextMetricsW) which differ from the height of 127 specified during creation. HalfLife2 by -1 giving 126 and TF2 by +1 giving 128.
I've attached the relevant log snippets for each font.
http://bugs.winehq.org/show_bug.cgi?id=21534
--- Comment #33 from rasmus.ry@gmail.com 2010-04-02 06:37:04 --- (From update of attachment 27158)
trace:font:FONT_EnumFontFamiliesEx lfFaceName = L"HalfLife2" lfCharset = 1 trace:font:WineEngEnumFonts facename = L"HalfLife2" charset 1 trace:font:GetEnumStructs Cached trace:font:WineEngEnumFonts enuming face L"HalfLife2" full L"HalfLife2" style L"Regular" charset 0 type 4 script L"Western" it 0 weight 400 ntmflags 00000040 trace:font:CreateFontIndirectW (127 0 0 0 0 0 0 4 0) L"HalfLife2" => 0xe60 trace:font:WineEngCreateFontInstance L"HalfLife2", h=127, it=0, weight=400, PandF=00, charset=0 orient 0 escapement 0 trace:font:WineEngCreateFontInstance DC transform 1.000000 0.000000 0.000000 1.000000 trace:font:WineEngCreateFontInstance not in cache trace:font:WineEngCreateFontInstance (it=0, bd=0) is selected for (it=0, bd=0) trace:font:WineEngCreateFontInstance Chosen: L"HalfLife2" L"Regular" (/home/rasmus/.wine/dosdevices/c:/Program Files/Steam/steamapps/*******/team fortress 2/hl2/resource/halflife2.ttf/(nil):0) trace:font:WineEngCreateFontInstance font scale y: 1.000000 trace:font:OpenFontFace "/home/rasmus/.wine/dosdevices/c:/Program Files/Steam/steamapps/*******/team fortress 2/hl2/resource/halflife2.ttf"/(nil), 0, 0 x 127 trace:font:WineEngGetFontData font=0x1581d9e8, table=VDMX, offset=0x0, buf=0x33de1c, cbData=0x6 trace:font:load_VDMX numRecs = 1 numRatios = 1 trace:font:WineEngGetFontData font=0x1581d9e8, table=VDMX, offset=0x6, buf=0x33de7c, cbData=0x4 trace:font:load_VDMX Ratios[0] 1 1 : 1 -> 1 trace:font:WineEngGetFontData font=0x1581d9e8, table=VDMX, offset=0xa, buf=0x33de8a, cbData=0x2 trace:font:WineEngGetFontData font=0x1581d9e8, table=VDMX, offset=0xc, buf=0x33de80, cbData=0x4 trace:font:load_VDMX recs=248 startsz=8 endsz=255 trace:font:WineEngGetFontData font=0x1581d9e8, table=VDMX, offset=0x10, buf=0x163bfd88, cbData=0x5d0 trace:font:load_VDMX ppem 111 found; height=127 yMax=110 yMin=-16 trace:font:OpenFontFace height 127 => ppem 111 trace:font:select_charmap found cmap with platform_id 0, encoding_id 3 trace:font:select_charmap found cmap with platform_id 3, encoding_id 1 trace:font:WineEngCreateFontInstance caching: gdiFont=0x1581d9e8 hfont=0xe60 trace:font:X11DRV_SelectFont hdc=0xe54, hfont=0xe60 trace:font:X11DRV_SelectFont gdiFont = 0x1581d9e8 trace:font:WineEngGetFontData font=0x1581d9e8, table=gasp, offset=0x0, buf=(nil), cbData=0x0 trace:font:WineEngGetFontData Can't find table gasp trace:font:update_font_code_page charset 0 => cp 1252 trace:font:WineEngGetOutlineTextMetrics font=0x1581d9e8 trace:font:WineEngGetOutlineTextMetrics OS/2 winA = 985 winD = 144 typoA = 712 typoD = -220 typoLG = 0 FT_Face a = 985, d = -226, h = 1211: HORZ a = 985, d = -226 lg = 0 maxY = 991 minY = -144 trace:font:GetTextMetricsW text metrics: Weight = 400 FirstChar = 32 AveCharWidth = 116 Italic = 0 LastChar = 57352 MaxCharWidth = 224 UnderLined = 0 DefaultChar = 31 Overhang = 0 StruckOut = 0 BreakChar = 32 CharSet = 0 PitchAndFamily = 17
InternalLeading = 15 Ascent = 110 Descent = 16 Height = 126 trace:font:WineEngCreateFontInstance L"HalfLife2", h=127, it=0, weight=400, PandF=00, charset=0 orient 0 escapement 0 trace:font:WineEngCreateFontInstance DC transform 1.000000 0.000000 0.000000 1.000000 trace:font:WineEngCreateFontInstance returning cached gdiFont(0x1581d9e8) for hFont 0xe60 trace:font:X11DRV_SelectFont hdc=0xe54, hfont=0xe60 trace:font:X11DRV_SelectFont gdiFont = 0x1581d9e8 trace:font:update_font_code_page charset 0 => cp 1252
http://bugs.winehq.org/show_bug.cgi?id=21534
--- Comment #34 from edward savage epssyis@gmail.com 2010-04-02 07:57:45 --- I highlighted the recent debuging information in the #winehackers channel and Jeffz suggested that this bug maybe a duplicate. He linked to bug 7698 which appears to have the same issues with other source based games.
I went through the workarounds offered and none of them appear to work. The two I was told should work were patch 6953 and/or setting winver to win98. Against the current git the end of match crashes were still easily reproduced. I have a work around for the tab score panel crashes so I don't know if that was solved.
http://bugs.winehq.org/show_bug.cgi?id=7698
http://bugs.winehq.org/show_bug.cgi?id=21534
--- Comment #35 from rasmus.ry@gmail.com 2010-04-02 08:36:25 --- As a workaround, try extracting /tf/resource/ClientScheme.res from /steamapps/team fortress 2 content.gcf to /steamapps/user/team fortress 2/tf/resource, using GCFExplorer.
Then open ClientScheme.res in a text editor and look for "ScoreboardTeamScore" and "HudFontGiant", I've changed the font from "TF2" to "Verdana" for sub definitions "4" and "5" in both cases. Which seems to workaround the issue, however I've only done limited testing as I've been getting a segmentation fault in real.compiz.
http://bugs.winehq.org/show_bug.cgi?id=21534
--- Comment #36 from edward savage epssyis@gmail.com 2010-04-02 12:01:48 --- (In reply to comment #35)
As a workaround, try extracting /tf/resource/ClientScheme.res from /steamapps/team fortress 2 content.gcf to /steamapps/user/team fortress 2/tf/resource, using GCFExplorer.
Then open ClientScheme.res in a text editor and look for "ScoreboardTeamScore" and "HudFontGiant", I've changed the font from "TF2" to "Verdana" for sub definitions "4" and "5" in both cases. Which seems to workaround the issue, however I've only done limited testing as I've been getting a segmentation fault in real.compiz.
The workaround appears to work well and TF2 is very playable again using Metacity and the standard HUD. It explains why the alternative HUDs were having success.
I've just played an hour long game on a series of maps with no issues. Thanks!
I am also getting the faults in compiz leading to screen tearing and performance loss which becomes apparent within the first five minutes of play in any game. This is some thing I haven't seen before today so is maybe related to a compiz update in the last couple of days? It isn't a regression as I've just tried 38, 40, and 41 and with the modified ClientScheme.res removed it is noticeable even before a score panel crash happens. Reconnecting to the game removes the tearing for a few minutes and some times it does go away for a few minutes before returning.
http://bugs.winehq.org/show_bug.cgi?id=21534
--- Comment #37 from Michael Abbott michael@araneidae.co.uk 2010-04-02 14:41:36 --- (In reply to comment #35)
As a workaround, try extracting /tf/resource/ClientScheme.res from /steamapps/team fortress 2 content.gcf to /steamapps/user/team fortress 2/tf/resource, using GCFExplorer.
Then open ClientScheme.res in a text editor and look for "ScoreboardTeamScore" and "HudFontGiant", I've changed the font from "TF2" to "Verdana" for sub definitions "4" and "5" in both cases.
Well. Think I managed to play a complete game at full resolution for the first time since the end of January. Only a few minutes, but a major step forwards!
In fact, I used the ClientScheme.res which came with FlameHUD, but I tested with the standard HUD. With FlameHUD installed (before the font patch) I would still crash at the end of the map.
http://bugs.winehq.org/show_bug.cgi?id=21534
--- Comment #38 from edward savage epssyis@gmail.com 2010-04-03 02:08:41 --- Screen tearing and performance loss isn't apparently in Compiz shipped with Ubuntu 10.04 (1:0.8.4-0ubuntu13) so I guess we wait a month for this to go away.
Those using Ubuntu 9.10 who haven't updated recently I suggest holding back your Xorg/Compiz updates.
Those who have already updated and don't want to jump to 10.04 can simply open a terminal and run metacity --replace and then play TF2 with Rasmus' workaround.
http://bugs.winehq.org/show_bug.cgi?id=21534
--- Comment #39 from Michael Abbott michael@araneidae.co.uk 2010-04-06 13:05:42 --- Created an attachment (id=27245) --> (http://bugs.winehq.org/attachment.cgi?id=27245) Working patch for ClientScheme.res
(In reply to comment #37)
(In reply to comment #35)
As a workaround, ... open ClientScheme.res [and] change[d] the font from "TF2" to "Verdana" for sub definitions "4" and "5" in both cases.
Well. Think I managed to play a complete game at full resolution for the first time since the end of January.
Yes, this is good. The attached patch is against ClientScheme.res from FlameHUD, but works with the standard HUD, and my TF2 seems to be working again.
Surely this must give the developers a massive clue?
By the way, please don't get distracted by compiz here: I don't have compiz installed, it's not relevant to this bug at all.
http://bugs.winehq.org/show_bug.cgi?id=21534
Karsten Elfenbein kelfe@gmx.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |kelfe@gmx.de
http://bugs.winehq.org/show_bug.cgi?id=21534
Erich Hoover ehoover@mines.edu changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |ehoover@mines.edu
--- Comment #40 from Erich Hoover ehoover@mines.edu 2010-04-23 09:36:35 --- (In reply to comment #32)
I've been going through a log of the font channel, looking for fonts which may be exceeding the upper limit of 127. ... Out of these, HalfLife2 and TF2 returns text metrics (through trace:font:GetTextMetricsW) which differ from the height of 127 specified during creation. HalfLife2 by -1 giving 126 and TF2 by +1 giving 128. ...
Did you try changing the text metrics routine to rail at 127 and see if that fixes it? (Note: I don't have TF2, I just saw this on the news queue and have some experience with font bugs)
http://bugs.winehq.org/show_bug.cgi?id=21534
--- Comment #41 from rasmus.ry@gmail.com 2010-04-24 13:26:44 --- (In reply to comment #40)
Did you try changing the text metrics routine to rail at 127 and see if that fixes it? (Note: I don't have TF2, I just saw this on the news queue and have some experience with font bugs)
Reading through the discussion of Bug 7698 (which is either the same issue or closely related) I decided not to push further ahead. I would find it a waste of my time if the most likely outcome is to maintain a seperate patch against either WINE or FreeType. This is my only use-case for WINE and as such I'm perfectly happy with simply modifying ClientScheme.res once.
http://bugs.winehq.org/show_bug.cgi?id=21534
--- Comment #42 from Erich Hoover ehoover@mines.edu 2010-04-24 14:05:17 --- (In reply to comment #41)
(In reply to comment #40)
Did you try changing the text metrics routine to rail at 127 and see if that fixes it? (Note: I don't have TF2, I just saw this on the news queue and have some experience with font bugs)
Reading through the discussion of Bug 7698 (which is either the same issue or closely related) I decided not to push further ahead. I would find it a waste of my time if the most likely outcome is to maintain a seperate patch against either WINE or FreeType. This is my only use-case for WINE and as such I'm perfectly happy with simply modifying ClientScheme.res once.
The key here is that you have evidence of both of the following: 1) A routine returning a value greater than it should under the circumstances. 2) Wine returning a different value for the same inputs than seen on Windows.
It looks to me like that other bug only has #2 going for it, and they've thrown in a horrible hack to fix it. I would imagine that this bug is one of two problems: 1) It has to do with differences in how rounding is approached in the scaling operation, in which case it is almost certainly related to the other bug. 2) It has to do with how an "invalid" condition is handled, in which case it is less likely to be related to the other bug (though that may just be because they have collected less useful information than you have).
My bet would be on option #2, it appears to me that it is likely that perfectly legitimate rounding causes the value to be too large for the glyph storage. I would guess that Windows rails to the maximum allowable value (since an invalidly sized glyph would cause a crash) where Wine doesn't catch the problem and tries to happily continue along using the invalid glyph height. I know for a fact that (at least a while ago) Wine didn't catch this kind of slip-up because an application I was debugging asked for a really large scaling factor (due to a not exactly font-related bug in Wine) and ended up asking for glyphs ~1000 pixels tall. Trying to track this issue down I temporarily tweaked the glyph storage to allow me to see what was going on (at the time I did not know the glyph size was the problem) and was not-so-pleasantly greeted with a font that consumed my entire screen. Personally, I would expect that should you ask for an unreasonable scaling that the closest reasonable value be substituted instead.
So, if you find that railing the value to 127 fixes the bug for you then you could relatively easily test for values that won't fit in a reasonable glyph buffer. With such a test you can rail "invalid" requests to the appropriate size for whatever the application requested when they created the font. Then with that kind of patch instead of a hack, and something similar to the above logic, you can easily justify why your patch is necessary.
http://bugs.winehq.org/show_bug.cgi?id=21534
--- Comment #43 from Clément Danjou clement.danjou@vinaigredemiel.com 2010-05-29 20:55:37 --- Problem solved for me since last TF2 update.
http://bugs.winehq.org/show_bug.cgi?id=21534
zil zilforever@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |zilforever@gmail.com
--- Comment #44 from zil zilforever@gmail.com 2010-06-12 13:15:13 --- 1.2rc3 tab key is ok
http://bugs.winehq.org/show_bug.cgi?id=21534
Wylda wylda@volny.cz changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |wylda@volny.cz
--- Comment #45 from Wylda wylda@volny.cz 2010-06-12 13:28:05 ---
Zil, comments 19 noted, that this bug depends on resolution. Could you try higher resolution and go back to .39 or so? Maybe it was fixed in wine, maybe by some TF2 update.
http://bugs.winehq.org/show_bug.cgi?id=21534
--- Comment #46 from zil zilforever@gmail.com 2010-06-13 10:46:20 ---
Problem solved for me since last TF2 update.
I think Clement is right
~/wine-git37/wine --version wine-1.1.37-138-g8894da4 ~/wine-git37/wine steam.exe -applaunch 440 no problem here with 1600x1200 or smaller but I only check (4:3), not 16:9
http://bugs.winehq.org/show_bug.cgi?id=21534
--- Comment #47 from mokrad mokrad@gmail.com 2010-06-13 11:49:13 --- (In reply to comment #45)
Zil, comments 19 noted, that this bug depends on resolution. Could you try higher resolution and go back to .39 or so? Maybe it was fixed in wine, maybe by some TF2 update.
No problem for me with this resolution : 1920*1200
http://bugs.winehq.org/show_bug.cgi?id=21534
mokrad mokrad@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED
--- Comment #48 from mokrad mokrad@gmail.com 2010-06-13 11:50:29 --- No problem with this resolution : 1920*1200
http://bugs.winehq.org/show_bug.cgi?id=21534
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #49 from Alexandre Julliard julliard@winehq.org 2010-06-18 12:47:18 --- Closing bugs fixed in 1.2-rc4.