| Bug ID | 105532 |
|---|---|
| Summary | Broken map generation in Northgard game |
| Product | Mesa |
| Version | unspecified |
| Hardware | Other |
| OS | All |
| Status | NEW |
| Severity | normal |
| Priority | medium |
| Component | Drivers/Gallium/radeonsi |
| Assignee | dri-devel@lists.freedesktop.org |
| Reporter | alexander@tsoy.me |
| QA Contact | dri-devel@lists.freedesktop.org |
Created attachment 1381= 48 [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 seem= s to be broken on some drivers. This involves rendering 2D vectorized shapes and th= en 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 user= s." Map generation is working fine with llvmpipe driver (LIBGL_ALWAYS_SOFTWARE=3Dtrue). 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=3D4#c1698293255133166837
Also very often map generation process just hangs or repeat ma= ny times (according to the progress bar).
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.
(In reply to Nicolas Cannasse from comment #2) > Hi, >=20 > I'm Northgard technical director. >=20 > We are creating buffers to draw various 2D shapes into textures for map > generation. Then we download the textures from GPU to CPU for addition= al > processing. These textures are then used to generate the landscape. Fo= r 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] uplo= ad 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/api= trace/apitrace
| What | Removed | Added |
|---|---|---|
| CC | freedesktop@lanig.email |
I have looked in the game folder. It seems like the game is us= ing 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-execut= able 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.
(In reply to Christian Lanig from comment #4) There are native linux binaries in the linux subfolder.
From a quick search, Haxe can be found on github [1] and its w= ebsite [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/H= axeFoundation/haxe [2] https://haxe.org [3] https://hashlink.haxe.org
(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.
| What | Removed | Added |
|---|---|---|
| Resolution | --- | NOTOURBUG |
| Status | NEW | RESOLVED |
I can confirm this for Hawaii, Polaris 20 and Raven.
(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. >=20 > Yes. You are right. I renamed Northgard.exe and the game still starts.= I > thought that Haxe would somewhere start the Windows binary after loadi= ng the > data file because shipping it to Linux users didn't make that much sen= se to > me. I'm sorry for the confusion. >=20 > Still, Haxe might be useful to localize the roots of the issue. As per my reply in comment 3. T= he game runs in the HashLink virtual machine. Which is why I was requesting a trace grabbed via a build of the game compi= led with HL/C which produces a native binary instead.