http://bugs.winehq.org/show_bug.cgi?id=26893
Summary: SimTower draws some objects misaligned Product: Wine Version: 1.3.18 Platform: All OS/Version: All Status: UNCONFIRMED Severity: normal Priority: P2 Component: gdiplus AssignedTo: wine-bugs@winehq.org ReportedBy: jeffrey.pfau@gmail.com
For several versions of Wine (going back to well before 1.2), many of the objects you can construct (notably offices and apartments) will draw offset, such that the edge of the room will be >10px from the left of the edge. The amount it is offset is constant per object type. Given that one side of the room is also offset vertically by 1px, it would appear to be the case that drawing these rooms uses the wrong offset to the pixel data.
I have observed this bug in 32- and 64-bit versions of Wine on Linux, and 64-bit version of Wine on Mac. The bug is present in SimTower v1.0 and v1.1b. I have not tested any other versions.
http://bugs.winehq.org/show_bug.cgi?id=26893
--- Comment #1 from Vincent Povirk madewokherd@gmail.com 2011-04-22 13:33:16 CDT --- Why did you set the component to gdiplus? Does winetricks gdiplus work around this?
http://bugs.winehq.org/show_bug.cgi?id=26893
--- Comment #2 from Jeffrey Pfau jeffrey.pfau@gmail.com 2011-04-22 13:59:25 CDT --- I set the component to gdiplus because I was under the impression that this was used for drawing in SimTower, and the bug was directly related to drawing. This might have been in error, as the native version of gdiplus.dll didn't fix the problem.
http://bugs.winehq.org/show_bug.cgi?id=26893
Juan Lang juan_lang@yahoo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|gdiplus |-unknown
--- Comment #3 from Juan Lang juan_lang@yahoo.com 2011-04-22 18:49:59 CDT --- If native gdiplus doesn't fix it, it's not a gdiplus bug.
http://bugs.winehq.org/show_bug.cgi?id=26893
Dmitry Timoshkov dmitry@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Platform|All |Other OS/Version|All |other
http://bugs.winehq.org/show_bug.cgi?id=26893
David Goodwin david@zx.net.nz changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |david@zx.net.nz
--- Comment #4 from David Goodwin david@zx.net.nz 2012-02-15 01:03:43 CST --- This still happens in wine-1.4-rc2, simtower 1.1b, ubuntu 11.10 64bit
https://bugs.winehq.org/show_bug.cgi?id=26893
--- Comment #5 from Austin English austinenglish@gmail.com --- This is your friendly reminder that there has been no bug activity for 2 years. Is this still an issue in current (1.7.16 or newer) wine?
http://bugs.winehq.org/show_bug.cgi?id=26893
keigen.shu@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |keigen.shu@gmail.com
--- Comment #6 from keigen.shu@gmail.com --- This is still an issue in wine-1.7.18 (Arch).
Screenshot:
http://postimg.com/image/150000/2014-05-12-232022_1366x768_scrot-149112.jpg
https://bugs.winehq.org/show_bug.cgi?id=26893
hanska2@luukku.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |hanska2@luukku.com
--- Comment #7 from hanska2@luukku.com --- Created attachment 49326 --> https://bugs.winehq.org/attachment.cgi?id=49326 pic
I uploaded the picture into this database. So it doesnt get lost on the external one.
Any debug output?
https://bugs.winehq.org/show_bug.cgi?id=26893
--- Comment #8 from Austin English austinenglish@gmail.com --- This is your friendly reminder that there has been no bug activity for over a year. Is this still an issue in current (1.7.51 or newer) wine?
https://bugs.winehq.org/show_bug.cgi?id=26893
Linus Unnebäck linus@folkdatorn.se changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |linus@folkdatorn.se
--- Comment #9 from Linus Unnebäck linus@folkdatorn.se --- This is still an issue in wine-2.0.3 (macOS)
https://bugs.winehq.org/show_bug.cgi?id=26893
--- Comment #10 from Linus Unnebäck linus@folkdatorn.se --- This is still an issue with Wine 3.6 on macOS 10.13.4
https://bugs.winehq.org/show_bug.cgi?id=26893
tokktokk fdsfgs@krutt.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |fdsfgs@krutt.org
https://bugs.winehq.org/show_bug.cgi?id=26893
--- Comment #11 from Jeffrey Pfau jeffrey.pfau@gmail.com --- This is still an issue on 5.15.
https://bugs.winehq.org/show_bug.cgi?id=26893
--- Comment #12 from Vicki Pfau jeffrey.pfau@gmail.com --- This is still an issue on wine-staging 8.3
https://bugs.winehq.org/show_bug.cgi?id=26893
--- Comment #13 from Vicki Pfau jeffrey.pfau@gmail.com --- I spent a bunch of time digging through logs and even the assets of the game last night and determined that the assets affected are ones where they have multiple sub-images in the same asset, and the amount assets are offset by is always the same, -32 pixels. Further, the top row of that seems to be taken from the last 32 pixels of the last row of the image, so there's some modulo going in there.
Some other object types have other weird offsets, including stairs and elevators. I haven't looked too hard at those assets yet. I also haven't figured out what functions are used for compositing the image before it's put on the screen, as it doesn't look like the compositing shows up in bitblt logs. GDI's Rectangle function is also not used for this. It's applied to the screen using WinG, but that also doesn't seem to be used for the compositing itself.
https://bugs.winehq.org/show_bug.cgi?id=26893
--- Comment #14 from Vicki Pfau jeffrey.pfau@gmail.com --- I've spent yet more time digging at this, and I've annotated a few functions in a Ghidra disassembly. It's really frustrating to debug, and I'm not really sure how to proceed, but my best guess is that one of the resources allocated winds up with an unexpected alignment. The resource in question does *not* appear to be the bitmap resource mapped out of the NE binary itself, but when trying to trace where the bitmap gets copied into, I get kind of stymied. The function at 1250:0114 seems to be a strided copy that moves it from the bitmap resource itself into some buffer, but where it goes from that buffer is a bit opaque to me. Even trying to corrupt the destination buffer doesn't appear to show up on-screen.
I can see why this bug hasn't been fixed yet. It's extremely vexing to track down where the faulty code is.
https://bugs.winehq.org/show_bug.cgi?id=26893
David Gow david@davidgow.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |david@davidgow.net
-
wine-bugs＠winehq.org -
WineHQ Bugzilla