[Bug 46558] New: win64 dotnet Space Engineers fractal noise generation broken
https://bugs.winehq.org/show_bug.cgi?id=46558 Bug ID: 46558 Summary: win64 dotnet Space Engineers fractal noise generation broken Product: Wine-staging Version: 4.0-rc7 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: BabbleBones(a)gmail.com CC: leslie_alistair(a)hotmail.com, z.figura12(a)gmail.com Distribution: --- Space Engineers seems to work with the latest wine, dxvk, and dotnet installed to the prefix... However planet and asteroid (all voxel generation) seems to suffer from messed up procedural gen. Asteroids have small spiky bits on them in areas that whittle down to fine points and hard edges unnaturally. Not game breaking but very noticeable. Planet generation is much worse. Planets generate large spikes of rock that ascend upward well beyond the limits of the atmosphere and the lower portions of the planet seem to generate correctly if you manage to reach the ground and walk around. Extremely game breaking. This happens in multiplayer too, even with a windows based server, the client procedural gens voxels independently of the server's generation which obviously conflict the server sees free open space but the client on wine will generate these huge phantom spikes visible to the player. Something is pushing the fractal ridge generation of the game to create these utterly massive spikes and asteroid fuzz and I'm willing to bet it's something wrong with the underlying noise generation of DotNet that they use. The source code of the game is available as well for "compatibility" purposes under KeenSoftwareHouse's visible source licensing on github if it would be applicable in debugging the problem but I have a feeling this may be dotnet itself as that's where they get the noise gen from. vcrun2017 and dotnet462 have been installed in my latest prefix with winetricks. Only the version of the game [1.187] and older work as something locks up the latest version in wine after a minute or so if you want to test. https://appdb.winehq.org/objectManager.php?sClass=version&iId=30180 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=46558 --- Comment #1 from Zebediah Figura <z.figura12(a)gmail.com> --- A quick perusal of the source seems to imply that all of their noise generation is done from scratch. Do you know where the dependency on .NET is? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=46558 BabbleBones(a)gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- Distribution|--- |Ubuntu --- Comment #2 from BabbleBones(a)gmail.com --- Thought I ran into a System.Noise piece somewhere in their source, seems I was wrong. Almost everything is under VRage.Noise so I guess that'd be the place to look. Not sure what can just fudge numbers like this so I was expecting it to be something external. Anything similar to this issue ever pop up? Something massively stretching out upper noise bounds? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=46558 --- Comment #3 from Zebediah Figura <z.figura12(a)gmail.com> --- I can't say I've seen anything similar before, though it probably wouldn't be any help if I had. Most useful thing to do, if all of the relevant source is available, would be to look through the source path that surface generation takes, and identify any actual API entry points used. It may not in fact be related to noise generation. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=46558 --- Comment #4 from BabbleBones(a)gmail.com --- Alright. Nose to the grindstone on this one. Hopefully I might be able to get in contact with a member of the Keen team on the discord and ask a few questions about their surface gen to fully understand it. My programming experience extends about as far as applying a custom patch and compiling, but I understand the API entry point debug, I just can't imagine *what* would break so as to cause this from just API input. It only seems to happen for certain elements of the asteroid. Toroid and sphere gen is totally fine but the fractal peaks always freak out, so that narrows it down... -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=46558 --- Comment #5 from Matteo Bruni <matteo.mystral(a)gmail.com> --- Does this also happen with non-staging Wine? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=46558 --- Comment #6 from BabbleBones(a)gmail.com --- (In reply to Matteo Bruni from comment #5)
Does this also happen with non-staging Wine?
Yes, this bug is present in pretty much every version of wine I've tested since about 3.16, staging and nonstaging. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=46558 Paul Gofman <gofmanp(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |gofmanp(a)gmail.com -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=46558 Zebediah Figura <z.figura12(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Component|-unknown |-unknown Product|Wine-staging |Wine --- Comment #7 from Zebediah Figura <z.figura12(a)gmail.com> --- (In reply to BabbleBones from comment #6)
(In reply to Matteo Bruni from comment #5)
Does this also happen with non-staging Wine?
Yes, this bug is present in pretty much every version of wine I've tested since about 3.16, staging and nonstaging.
-- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=46558 --- Comment #8 from BabbleBones(a)gmail.com --- Issue has been found! The game decodes a 16 bit grayscale png and uses that for height information on the planets. Somehow the png may be getting truncated on read. What it truncates into I am not sure but it may be an 8 bit value that would wrap around and swing the terrain generation in crazy directions. Saving the images back to disk as 8 bit grayscale png seems to solve the issue. Please see: https://github.com/ValveSoftware/Proton/issues/1792 How is png conversion from 16bpc gray to 8bpc gray handled? Is it an external lib or internal implementation? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=46558 --- Comment #9 from Zebediah Figura <z.figura12(a)gmail.com> --- (In reply to BabbleBones from comment #8)
Issue has been found!
The game decodes a 16 bit grayscale png and uses that for height information on the planets. Somehow the png may be getting truncated on read.
What it truncates into I am not sure but it may be an 8 bit value that would wrap around and swing the terrain generation in crazy directions.
Saving the images back to disk as 8 bit grayscale png seems to solve the issue. Please see: https://github.com/ValveSoftware/Proton/issues/1792
How is png conversion from 16bpc gray to 8bpc gray handled? Is it an external lib or internal implementation?
Nice find! I would expect that would go through windowscodecs, and that would then go through libpng internally. To confirm, can you try native windowscodecs (e.g. by `winetricks -q windowscodecs`) and see if that fixes the issue? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=46558 --- Comment #10 from BabbleBones(a)gmail.com --- Sure didn't fix the issue but it prodded the right spot! Lots of pink textures in the UI where it should have been transparent and most importantly, the planet was utterly flat at a distance and crashed me, up close! That's it! The 16 -> 8 bit is giving the grief and it's somewhere in windowscodecs or libpng itself. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=46558 Zebediah Figura <z.figura12(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Component|-unknown |windowscodecs --- Comment #11 from Zebediah Figura <z.figura12(a)gmail.com> --- (In reply to BabbleBones from comment #10)
Sure didn't fix the issue but it prodded the right spot!
Lots of pink textures in the UI where it should have been transparent and most importantly, the planet was utterly flat at a distance and crashed me, up close!
That's it! The 16 -> 8 bit is giving the grief and it's somewhere in windowscodecs or libpng itself.
Hrm, somewhat disturbing, I hope there's not another bug hidden in there somewhere. Still, setting the component to windowscodecs (though of course it may be a bug in libpng, as you say). I guess the next step would be to take a +windowscodecs log. I'm presuming the relevant files are the ones in <https://github.com/KeenSoftwareHouse/SpaceEngineers/tree/master/Sources/SpaceEngineers/Content/Data/PlanetDataFiles>? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=46558 Bryon Roche <kain(a)kain.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |kain(a)kain.org --- Comment #12 from Bryon Roche <kain(a)kain.org> --- Created attachment 64212 --> https://bugs.winehq.org/attachment.cgi?id=64212 Byte swap png read/write for 16-bpp data. I suppose this is only safe on little-endian nodes. A proper patch would do the right thing on big-endian too. Is anyone actually using big-endian WINE? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=46558 --- Comment #13 from Bryon Roche <kain(a)kain.org> --- This is definitely a windowscodecs bug. >8bpp PNGs are required to be stored in network byte order, which windowscodecs is not doing. The attached patch fixes this. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=46558 Vincent Povirk <madewokherd(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |madewokherd(a)gmail.com -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=46558 Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |STAGED Ever confirmed|0 |1 Staged patchset| |https://github.com/wine-sta | |ging/wine-staging/tree/mast | |er/patches/windowscodecs-pn | |g-network -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=46558 --- Comment #14 from Vincent Povirk <madewokherd(a)gmail.com> --- Can you attach a .png file that WIC reads incorrectly? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=46558 --- Comment #15 from Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> --- (In reply to Vincent Povirk from comment #14)
Can you attach a .png file that WIC reads incorrectly?
I guess the next step would be to take a +windowscodecs log. I'm presuming the relevant files are the ones in <https://github.com/KeenSoftwareHouse/SpaceEngineers/tree/master/Sources/ SpaceEngineers/Content/Data/PlanetDataFiles>?
The file back.png from the above repository should be good enough. back.png: PNG image data, 2048 x 2048, 16-bit grayscale, non-interlaced -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=46558 --- Comment #16 from Vincent Povirk <madewokherd(a)gmail.com> --- It renders correctly in my test program without the patch applied, and incorrectly with it. It's possible we have a corresponding bug somewhere else, like the format converter. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=46558 --- Comment #17 from Vincent Povirk <madewokherd(a)gmail.com> --- Our format conversion code does appear to expect big endian data. We'll want to add tests for that and fix both at the same time. We should also check our tiff and tga code that uses 16-bit color channels. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=46558 --- Comment #18 from Gijs Vermeulen <gijsvrm(a)gmail.com> --- Is this still an issue after <https://source.winehq.org/git/wine.git/commit/0c0def962f2b86f44625f11d8d9d2013aaffa46a> and <https://source.winehq.org/git/wine.git/commit/2b7b3abc5b334ec8b17dc98a25eefd26e1d0054d> ? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=46558 Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Status|STAGED |RESOLVED Fixed by SHA1| |2b7b3abc5b334ec8b17dc98a25e | |efd26e1d0054d --- Comment #19 from Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> --- Marking as Fixed -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=46558 Alexandre Julliard <julliard(a)winehq.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #20 from Alexandre Julliard <julliard(a)winehq.org> --- Closing bugs fixed in 4.10. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=46558 Michael Stefaniuc <mstefani(a)winehq.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|--- |4.0.x -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=46558 Michael Stefaniuc <mstefani(a)winehq.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|4.0.x |--- --- Comment #21 from Michael Stefaniuc <mstefani(a)winehq.org> --- Removing the 4.0.x milestone from bug fixes included in 4.0.3. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
participants (2)
-
wine-bugs＠winehq.org -
WineHQ Bugzilla