https://bugs.winehq.org/show_bug.cgi?id=50876
Bug ID: 50876 Summary: Sid Meier's SimGolf does not render properly Product: Wine Version: 6.3 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: directx-d3d Assignee: wine-bugs@winehq.org Reporter: haakobja@gmail.com Distribution: ---
Created attachment 69686 --> https://bugs.winehq.org/attachment.cgi?id=69686 Screenshot of the bug
The terrain in SimGolf is not rendering properly. I've attached a screenshot and a trace log, however I'm not certain where this problem occur, but it's probably a rendering problem.
I didn't get anything when using the following debug channels: +ddraw,+d2d,+d3d. In the attached log, I've used +all,-relay,-dsound,-heap,-pulse,-sync, which might provide a log with too much information.
https://bugs.winehq.org/show_bug.cgi?id=50876
--- Comment #1 from Håkon haakobja@gmail.com --- Created attachment 69687 --> https://bugs.winehq.org/attachment.cgi?id=69687 SimGolf log
Added log.
I also forgot to mention that this problem is present in both the retail edition and the SimGolf demo (available on archive.org: https://archive.org/details/Simgolfdemo)
https://bugs.winehq.org/show_bug.cgi?id=50876
joaopa jeremielapuree@yahoo.fr changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jeremielapuree@yahoo.fr
--- Comment #2 from joaopa jeremielapuree@yahoo.fr --- Confirming with wine-6.18.
https://bugs.winehq.org/show_bug.cgi?id=50876
--- Comment #3 from joaopa jeremielapuree@yahoo.fr --- Confirming with wine-7.16 Can an administrator put the link at URL place? https://archive.org/details/Simgolfdemo
https://bugs.winehq.org/show_bug.cgi?id=50876
Olivier F. R. Dierick o.dierick@piezo-forte.be changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download URL| |https://archive.org/details | |/Simgolfdemo CC| |o.dierick@piezo-forte.be
https://bugs.winehq.org/show_bug.cgi?id=50876
AdeC adec2011.ac@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |adec2011.ac@gmail.com
--- Comment #4 from AdeC adec2011.ac@gmail.com --- Still exists in Wine 8.1
https://bugs.winehq.org/show_bug.cgi?id=50876
nerdistmonk@fastmail.fm changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |nerdistmonk@fastmail.fm
--- Comment #5 from nerdistmonk@fastmail.fm --- Can confirm this bug exists in Wine 9.2.
ddrawcompat and dgvoodoo just make the game crash.
Colors are wild/inverted.
https://bugs.winehq.org/show_bug.cgi?id=50876
Michał Dec moog621@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |moog621@gmail.com
--- Comment #6 from Michał Dec moog621@gmail.com --- Can we please change the status of this bug to confirmed already? The bug report itself has been lying around for 3 years.
It's been apparent for at least 12 years according to screenshots available here https://appdb.winehq.org/screenshots.php?iAppId=6047&iVersionId=9651 judging by the fact that one of the earliest screenshots with a specific Wine version specifies Wine 1.5.4 which dates at the earliest to May 2012 - that this bug exists.
Before that, we had countless reports in https://appdb.winehq.org/objectManager.php?sClass=version&iId=9651 saying that the issue persists throughout the ages. I just found out now when scrutinizing this situation that even the first ever report for this game, that's gonna be 15 years old this year, confirms the existence of this bug: https://appdb.winehq.org/objectManager.php?sClass=version&iId=9651&i...
I don't want to pass judgement on anyone, I just want to make the case that the bug deserves confirmation.
https://bugs.winehq.org/show_bug.cgi?id=50876
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Ever confirmed|0 |1 Status|UNCONFIRMED |NEW
--- Comment #7 from Austin English austinenglish@gmail.com --- Confirming.
https://bugs.winehq.org/show_bug.cgi?id=50876
jed@tymorris.co.uk changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jed@tymorris.co.uk
--- Comment #8 from jed@tymorris.co.uk --- Just chiming in to confirm that I'm also experiencing this bug on openSUSE Tumbleweed.
Tested with wine 9.9, and have also tried running through lutris with several different wine runners.
All exhibit this bug on my end.
Have also experienced this bug before on other distros.
https://bugs.winehq.org/show_bug.cgi?id=50876
Benjamin Davidson bpd137@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |bpd137@gmail.com
--- Comment #9 from Benjamin Davidson bpd137@gmail.com --- Confirming this bug occurs on Steam Deck (SteamOS 3.5.19) and any version of Wine (also Proton 5.0 through 9.0, Lutris, etc.) I throw at it.
https://bugs.winehq.org/show_bug.cgi?id=50876
--- Comment #10 from nerdistmonk nerdistmonk@fastmail.fm --- (In reply to Benjamin Davidson from comment #9)
Confirming this bug occurs on Steam Deck (SteamOS 3.5.19) and any version of Wine (also Proton 5.0 through 9.0, Lutris, etc.) I throw at it.
I can add the following enhancements to the testing:
*Bug effects -all- versions of simgolf (v1.0, 1.01 and 1.02) *Bug is still present even with ddrawcompat present (version 0.4.0) *Bug is still present even with dgvoodoo present (version 2.79.1) *Bug is still present even with the Command and Conquer DDraw patch
Normally a ddraw wrapper makes short work of problems like this, but not in Simgolf's case.
Version 9.11 of Wine is still affected by this bug, I am trying to play it via "wow64" compiled binaries (as opposed to multilib, the bug is present in both variations of wine).
https://bugs.winehq.org/show_bug.cgi?id=50876
--- Comment #11 from nerdistmonk nerdistmonk@fastmail.fm --- Update:
Found a temporary workaround for the corrupted colors, if you look in the install directory of Simgolf, there is 4 text files related to lighting in game, change the content of each of the 4 text files (parklandlighting, desertlighting, tropicallighting, etc) to have this for their contents:
#AMBIENT 100 100 80 #DIFFUSE 100 100 100 #SPECULAR 100 100 100 #HIGHLIGHT 100 100 100
This will almost entirely correct the inverted colors, the buffer issue is still present however (the best i've come up with so far is if you scroll away and come back, it clears it so you can keep playing).
It's not much, it's bubblegum and paperclips, but the game is at least playable again.
http://bugs.winehq.org/show_bug.cgi?id=50876
ttoocs@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |ttoocs@gmail.com
--- Comment #12 from ttoocs@gmail.com --- Was curious to play simgolf myself and ran into this. So ran simgolf with WINEDBG=+all, and traced it down a trace:opengl:wglChoosePixelFormat with PDF_DRAW_BITMAP. Which seemed to match this and to the same functions discussed in https://bugs.winehq.org/show_bug.cgi?id=58662 . There's a commit in the wglChoosePixelFormat function that changes how it handles that flag, prior it would ignore it (I think this is how we get the trippy colors) and now fails and gives me just black terrain. I believe bug 58662 is this, where no valid pixel formats existing of r5g5b5a1... as I guess from my searching only some windows opengl 1.1 software rendering driver actually supported PDF_DRAW_BITMAP anyhow.
It seems Zowie is working on a solution on bug 58662, and while a dev myself, he already started on it a week ago, and presumably knows something of the codebase.
(I accidentally lost the original 1.5Gb logfile, but even in the "short" 400Mb one, I was doing line-jumps of 50,000k-500,000k to find when functions actually seemed to change. grep -n "trace:bidi:BIDI_Reorder" was a great bookmark/chapters for simgolf, "... one moment ..." and then the next is seems to be related the error. There's also a CALL Terrain.?initSystem@Terrain<garbled> which occurs right before calls to gdu32 and opengl32 start, tho maybe prior ones as well (lost the log to check) )