Tile Rendering Still Broken, but Debugging Now Possible

Happy Fourth of July, Folks! It's officially mock warzone here in the States, with explosions both near and far. I wonder how many actual gun battles are happening right now because nobody would notice?

Since we have a vacation coming up, I decided to work through this holiday and see if I could make headway on the hex rendering issue. Short version: I did not.

As you can see from today's lovely image, I am getting a black hole right around where there should be visible hexes. And the rainbow hexes are just some debug art I'm using in place of blank/black hexes, since it makes things easier to see.

All I can see besides the rainbow and missing hexes are two gray rectangles with pinkish yellow tops. It almost looks like they're edges of a hex, but I have no idea from where the game gets those graphics. Nothing I can think of looks like those, and they change color a bit when I change the hex tilesheet image.

I thought I had it figured out at one point where I saw rendering coordinates were not being calculated correctly. (Like, simple addition was occasionally not working in the code for some reason.) But even after changing that, nada.

Best I can tell right now is that the source image from which the hexmap is copied is getting corrupted. But I'm having trouble verifying that.

On the plus side, I have some Twitter peeps to thank for alerting me to a new way of doing Haxe programming. Basically, there is a new IDE out there for Haxe coding and debugging, and it even allows for breakpoints and var inspection! Up until now, I've been using ancient (in developer years) 2016 HaxeDevelop as an IDE, and trace debugging. This new regime of VSCode plus some HXCPP extensions is a godsend. Thanks @Gama11 (and @larsiusprime) for the tip!

It also may have allowed me to catch a bug I was completely unaware of. one that crashes the game when loading, but only *sometimes.* It seems to be something to do with objects in containers, and usually gets triggered by the store being stocked for the first time. Could this be the clue that solves the (not so) rare save crash? Time will tell!

Anyway, still more work do. But despite the lack of code progress today, the upgrade in production tools will mean a big difference moving forward.


Asthepanda2iscool2's picture

In the maps file, the cryo-facility is only referenced once in the mini map. I'm wondering if the issue will persist if you place a second cryo-facility next to the original. It probably won't make any difference (in fact, it's affecting a forest hex bellow the cryo-facility, and another is bound to be within your view in that screen shot), but my curiosity is tingling.

Rar! Rar rar rar! Thanks for reading :)

dcfedor's picture

The type of hex doesn't seem to change rendering at all. In the screenshot above, the reason you're seeing "cryo facility" is due to the map label, which is a separate rendering layer. I could add more of those labels around, but it won't change the broken hex art.

I think there's something else going on that seems to be corrupting either the rendered hexes, or the source from which those hex graphics are copied.

Dan Fedor - Founder, Blue Bottle Games