Bug 105532 - Broken map generation in Northgard game
Summary: Broken map generation in Northgard game
Status: RESOLVED NOTOURBUG
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/Gallium/radeonsi (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: Default DRI bug account
QA Contact: Default DRI bug account
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-03-15 22:10 UTC by Alexander Tsoy
Modified: 2018-07-25 04:41 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:


Attachments
northgard_screenshot.png (2.21 MB, image/png)
2018-03-15 22:10 UTC, Alexander Tsoy
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Alexander Tsoy 2018-03-15 22:10:24 UTC
Created attachment 138148 [details]
northgard_screenshot.png

Map generation is broken in Northgard game in single player mode. See screenshot. Game developers describe map generation process as follows [1]:
"The game rendering seems to be working fine, only map generation seems to be broken on some drivers. This involves rendering 2D vectorized shapes and then reading back the resulting graphics buffer. Nothing fancy, but we had some issues in OpenGL with some Intel HD drivers on Windows in the past. Using DirectX (same code, just different driver) did fix the issue for these users."

Map generation is working fine with llvmpipe driver (LIBGL_ALWAYS_SOFTWARE=true).

OpenGL renderer string: AMD Radeon (TM) R9 380 Series (TONGA / DRM 3.19.0 / 4.14.26-gentoo, LLVM 6.0.0)

[1] http://steamcommunity.com/app/466560/discussions/0/1698293255121560931/?ctp=4#c1698293255133166837
Comment 1 Alexander Tsoy 2018-03-15 22:21:30 UTC
Also very often map generation process just hangs or repeat many times (according to the progress bar).
Comment 2 Nicolas Cannasse 2018-06-08 08:51:54 UTC
Hi,

I'm Northgard technical director.

We are creating buffers to draw various 2D shapes into textures for map generation. Then we download the textures from GPU to CPU for additional processing. These textures are then used to generate the landscape. For some reason unknown to us the textures generated in some case appears to be corrupted, resulting in these weird height maps. We haven't been able to investigate the issue in details atm.
Comment 3 Timothy Arceri 2018-06-27 05:25:34 UTC
(In reply to Nicolas Cannasse from comment #2)
> Hi,
> 
> I'm Northgard technical director.
> 
> We are creating buffers to draw various 2D shapes into textures for map
> generation. Then we download the textures from GPU to CPU for additional
> processing. These textures are then used to generate the landscape. For some
> reason unknown to us the textures generated in some case appears to be
> corrupted, resulting in these weird height maps. We haven't been able to
> investigate the issue in details atm.

If you could capture a trace of the issue in renderdoc or apitrace [1] upload it somewhere and provide the link we might be able to investigate it. But currently I can't get a trace because the HashLink virtual machine crashes. Maybe you guys could try compiling with HL/C and try grabbing a trace with the binary?

[1] https://github.com/apitrace/apitrace
Comment 4 Christian Lanig 2018-06-29 17:14:56 UTC
I have looked in the game folder. It seems like the game is using Haxe.
I don't really know what Haxe is but in the folder there is also Northgard.exe and several .dll files. So I assume that Haxe does something comparable to Wine.

Already having Wine 3.7 installed for another game I just ran: wine Northgard.exe and bingo, the game seems to run just fine - at least the map is OK and I could do basic stuff like building a house.

So assuming that Haxe is comparable to Wine and does run the Windows-executable as well, we might conclude that the data that Haxe passes the mesa drivers is not identical to the data that Wine passes them.

As a result I am quite sure that the key to the answer is in Haxe and not in the game executable.
Comment 5 Alexander Tsoy 2018-06-29 17:24:51 UTC
(In reply to Christian Lanig from comment #4)
There are native linux binaries in the linux subfolder.
Comment 6 Eric Engestrom 2018-06-29 17:32:58 UTC
From a quick search, Haxe can be found on github [1] and its website [2] has some explanations as well, including how it uses a bytecode VM [3] to work cross-platform (essentially the same way java does it).

[1] https://github.com/HaxeFoundation/haxe
[2] https://haxe.org
[3] https://hashlink.haxe.org
Comment 7 Christian Lanig 2018-06-29 17:47:13 UTC
(In reply to Alexander Tsoy from comment #5)
> (In reply to Christian Lanig from comment #4)
> There are native linux binaries in the linux subfolder.

Yes. You are right. I renamed Northgard.exe and the game still starts. I thought that Haxe would somewhere start the Windows binary after loading the data file because shipping it to Linux users didn't make that much sense to me. I'm sorry for the confusion.

Still, Haxe might be useful to localize the roots of the issue.
Comment 8 Alexander Tsoy 2018-07-21 09:09:01 UTC
Latest game update fixed this bug for me.
Comment 9 Christian Lanig 2018-07-21 15:17:30 UTC
I can confirm this for Hawaii, Polaris 20 and Raven.
Comment 10 Timothy Arceri 2018-07-25 04:41:59 UTC
(In reply to Christian Lanig from comment #7)
> (In reply to Alexander Tsoy from comment #5)
> > (In reply to Christian Lanig from comment #4)
> > There are native linux binaries in the linux subfolder.
> 
> Yes. You are right. I renamed Northgard.exe and the game still starts. I
> thought that Haxe would somewhere start the Windows binary after loading the
> data file because shipping it to Linux users didn't make that much sense to
> me. I'm sorry for the confusion.
> 
> Still, Haxe might be useful to localize the roots of the issue.

As per my reply in comment 3. The game runs in the HashLink virtual machine. Which is why I was requesting a trace grabbed via a build of the game compiled with HL/C which produces a native binary instead.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.