Also very often map generation process just hangs or repeat many 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,
> 
> 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

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.

(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 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

(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.

Latest game update fixed this bug for me.

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.
> 
> 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.