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@winehq.org Reporter: BabbleBones@gmail.com CC: leslie_alistair@hotmail.com, z.figura12@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
https://bugs.winehq.org/show_bug.cgi?id=46558
--- Comment #1 from Zebediah Figura z.figura12@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?
https://bugs.winehq.org/show_bug.cgi?id=46558
BabbleBones@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Distribution|--- |Ubuntu
--- Comment #2 from BabbleBones@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?
https://bugs.winehq.org/show_bug.cgi?id=46558
--- Comment #3 from Zebediah Figura z.figura12@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.
https://bugs.winehq.org/show_bug.cgi?id=46558
--- Comment #4 from BabbleBones@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...
https://bugs.winehq.org/show_bug.cgi?id=46558
--- Comment #5 from Matteo Bruni matteo.mystral@gmail.com --- Does this also happen with non-staging Wine?
https://bugs.winehq.org/show_bug.cgi?id=46558
--- Comment #6 from BabbleBones@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.
https://bugs.winehq.org/show_bug.cgi?id=46558
Paul Gofman gofmanp@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |gofmanp@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=46558
Zebediah Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|-unknown |-unknown Product|Wine-staging |Wine
--- Comment #7 from Zebediah Figura z.figura12@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.
https://bugs.winehq.org/show_bug.cgi?id=46558
--- Comment #8 from BabbleBones@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?
https://bugs.winehq.org/show_bug.cgi?id=46558
--- Comment #9 from Zebediah Figura z.figura12@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?
https://bugs.winehq.org/show_bug.cgi?id=46558
--- Comment #10 from BabbleBones@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.
https://bugs.winehq.org/show_bug.cgi?id=46558
Zebediah Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|-unknown |windowscodecs
--- Comment #11 from Zebediah Figura z.figura12@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?
https://bugs.winehq.org/show_bug.cgi?id=46558
Bryon Roche kain@kain.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |kain@kain.org
--- Comment #12 from Bryon Roche kain@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?
https://bugs.winehq.org/show_bug.cgi?id=46558
--- Comment #13 from Bryon Roche kain@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.
https://bugs.winehq.org/show_bug.cgi?id=46558
Vincent Povirk madewokherd@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |madewokherd@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=46558
Alistair Leslie-Hughes leslie_alistair@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
https://bugs.winehq.org/show_bug.cgi?id=46558
--- Comment #14 from Vincent Povirk madewokherd@gmail.com --- Can you attach a .png file that WIC reads incorrectly?
https://bugs.winehq.org/show_bug.cgi?id=46558
--- Comment #15 from Alistair Leslie-Hughes leslie_alistair@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
https://bugs.winehq.org/show_bug.cgi?id=46558
--- Comment #16 from Vincent Povirk madewokherd@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.
https://bugs.winehq.org/show_bug.cgi?id=46558
--- Comment #17 from Vincent Povirk madewokherd@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.
https://bugs.winehq.org/show_bug.cgi?id=46558
--- Comment #18 from Gijs Vermeulen gijsvrm@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 ?
https://bugs.winehq.org/show_bug.cgi?id=46558
Alistair Leslie-Hughes leslie_alistair@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Status|STAGED |RESOLVED Fixed by SHA1| |2b7b3abc5b334ec8b17dc98a25e | |efd26e1d0054d
--- Comment #19 from Alistair Leslie-Hughes leslie_alistair@hotmail.com --- Marking as Fixed
https://bugs.winehq.org/show_bug.cgi?id=46558
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #20 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 4.10.
https://bugs.winehq.org/show_bug.cgi?id=46558
Michael Stefaniuc mstefani@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|--- |4.0.x
https://bugs.winehq.org/show_bug.cgi?id=46558
Michael Stefaniuc mstefani@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|4.0.x |---
--- Comment #21 from Michael Stefaniuc mstefani@winehq.org --- Removing the 4.0.x milestone from bug fixes included in 4.0.3.
-
wine-bugs＠winehq.org -
WineHQ Bugzilla