Month: October 2020

Be more sensitive about when to lock and unlock mutexes in order to fix crahes/vulkan memory warnings in a variety of situations

Resolves #66

Hello, not particularly exciting, but that should take away the most occurring problems resulting in crashes. There may be some visible flicking sometimes when placing a window now, but I definitely prefer that over potential crashes. 🙂
On to the next usability topics, doing bulk wallpaper changes. Byeee!

Add the ability to change the floor for an entire room at once

Resolves #38

After much under the bonnet work I’ve decided to put in two long-standing tickets, bulk editing for wall tiles and floor tiles, this commit implements the tile part:

Implementing this got a lot easier by finally introducing the concept of “rooms” a while back. On more good news, doing this will also make implementing the wall counter-part of this ticket a bit easier. However, not happening in release builds, but debug builds is a weird race condition that I will have a look into first. Hopefully that is not going to take too long, but be that as it may, I’m happy to see this happening finally. 🙂

– Fix race conditions when drawing placement markers that regularly caused validation errors (or even crashes)
– Replace marker state hash and wall state hash calculation with a simple increment as it is only called after actually changes    

Resolves #50, #49
Relates to #52

Hi! Yet another low-key change that has a big impact: no more random crashes (or warnings) when placing walls due to the build marker code doing some funny things when synchronising the draw commands.
There are some other issues which may be due to similar race conditions, but I’ll get to that at some other point, this was definitely the worst example for this problem, making building walls for testing purposes a bit of a gamble.
While doing that I also finally got around to replace two over-complicated and not necessarily reliably working (build markers and walls) hash functions with a simple increment.
Since either recalculation only ever gets triggered after actual state changes there is no harm done here, in fact it greatly simplifies the code, so, yay!
Next up are more visible changes again, which is also good for my motivation. Byeee.

Simplify the window light creation and use the correct minimum value when calculating room light intensities

Hello! Sooner than I expected the weird ambient light flicking issues that happened when rooms affected by light sources from multiple other rooms seem to be resolved. That puts an end to the light saga for the time being.
On to new things. 🙂

– Only take the 10 closest light sources per tile into consideration
– Do not update per-tile light index information unnecessarily  

Resolves #58

Hi! Every tile can keep track of up to 10 different light sources that can affect it. Until now, every light source was taken into consideration (read: the first ten), so if a room (or more likely the great outdoors) had more than ten light sources, every light source above that threshold would have no visible effect.
This is now remedied by simply sorting the possible light sources by distance. While doing that, I also did a fair share of profiling to discover a lot of updates to these index values even though they didn’t change on every tick, that too is now remedied as well as some minor optimisations. So I will deem this good enough for the time being.
That means for now the remaining problem are some rather unfortunate recursive ambient light calculation issues when rooms are connected through windows. The end of this topic is finally in sight 🙂