Hi again :)

Today went reasonably well, although it was mostly getting my new laptop set up.

I finally tried out i3 and decided that, right now, it’s not for me, and I’ve gone back to using stumpwm. I’ll probably spend more time getting used to i3’s approach to splitting in the future. It’s stacks and workspaces did seem very cool although I should experiment with stumpwm’s groups feature first.

Getting my server dev environment set up was pretty painless (yay docker), although I currently have an issue where TaleSpire isn’t uploading boards to my local minio server. I’m not sure what the issue is, so I’ll need to do more testing tomorrow. I’ve prepared the patches for the DB and erlang server, so I now need to test TS with these changes. With that done, I’ll be able to push to production, and then we’ll be ready for creature scaling.

Ree’s been working hard on fixing all manner of issues relating to creature control at low (and high) fps. Getting that stable is a heck of a project, but it’s paying off.

To follow up on the log from earlier today, it does seem that the latest patch does fix the SSE4 issue, which is great! We’ll be able to close a bunch of tickets from github real soon :)

Have a good night folks, Back with more tomorrow.

Heya folks, time for another log.

We have a content update dropping soon, but also in there is a potential fix for those who have been unable to play due to their machine not supporting SSE4. This limitation was due to older versions of the Burst compiler not supporting earlier SIMD instructions. We had wanted to upgrade the Burst compiler package previously, but we found a bug in that package that blocked us. We (reported it to Unity not long back)[https://issuetracker.unity3d.com/issues/the-sizeof-of-struct-with-structlayout-returns-a-smaller-value-in-the-burst-compiled-code-compared-to-the-mono-compiled-code] and they have already shipped a fix! With the packages updated, we should now support fallback to SSE2 (which every x64 machine supports).

My laptop, after holding on for nine years, finally started breaking the other day. My new one has just arrived. That means I’m going to lose at least a day to swearing at windows for being such a massive, invasive, pain in the ass and setting up Linux so I can get server work done in a more agreeable environment.

I’ve also started on the server changes to support creature scale. These are going well, and I will begin integrating the changes on the client-side soon.

Alright, that’ll do for now. Back to the laptop for me.

Ciao

A short one this time. Between two Norwegian national holidays and my own brain, I’ve been struggling with focus. Progress has slowly continued on the fog of war. I’ve written the compute shader, but I still need to do some plumbing, so I’ve nothing gif-worthy yet.

Ree’s work on the creature controller is wrapping up, so that will ship soon. There are a slew of fixes, and the work includes the bulk of the work for creature scaling. So once the first update has shipped (hopefully early next week), I’ll jump tasks to implement the sync and persistence for scaling.

The art team has also been working away, so you can expect a new asset update soon!

I’m going to spend the rest of today around the community, so if you are around, seeya there.

Hi folks, another day of slow but steady progress on the fog of war. What I did today was hook up the code that queues up mesher jobs when the underlying fog data changes. I can now select a region, press a key, and the fog volume data for all the zones in the region is updated. The presentation for those zones then enqueues a job that reads the volume data and generates a minecraft-style mesh that will (in time) be used for fog. As, in this test, the selection tools work with cuboids, the fog only follows that shape, but we can see that the resulting mesh is reasonable (lower poly compared to the worst case), and I can see that the jobs are being run in parallel. So far, so good.

Now, this is done I can write the code that takes the cubemaps captured from the line-of-sight system that handles hiding creatures, and passes them to a new compute-shader which will make an update mask of what areas are visible. I’ll be doing this on the GPU as:

• The data I need is already on the GPU which means no having to shift it around
• The approach I’ll be trying is trivial to parallelize without divergence and so should be very suited to running there.

From the CPU side, we will then wait on a GPU-fence (which tells us when the compute-shader has finished), read the result from the compute-buffer, and apply it to the fog data in the zone. This change will then trigger the code we wrote today and we should see the new mesh which will hopefully have removed all parts that were in view. It will absolutely be rough, to begin with, but with the full round trip written, we can move onto playing with it and making it better.

I’ll go into more detail on the approach once I’ve got it working as it should be pretty simple.

Alright, seeya around.

Hi folks, today I’ve been poking around with fog of war and working out how the updates are going to be spread over multiple frames. I’m going to keep working on this so I can select areas and apply fog to them. For now, the mesh generated will just be a big, grey, minecraft-looking mesh as we don’t need to worry about the visuals for a while yet.

Ree’s been working on business things today, and his work on the creature-controller has gone well too. There are still some things to work out with creature scaling over various framerates, but it’s getting closer.

Back soon with more!

Nothing substantial today, I’m afraid. That last day or so, I’ve had something like writer’s block for coding, so I’ve moved my weekend a bit sooner.

I had started looking into fog-of-war, but I’ve got nothing new to report yet.

When I’m rested up, I’ll dig back into a few tile related bugs that have been reported this week, and then I’ll get back to the fog of war.

Have a good one folks.

Heya folks,

After shipping the update yesterday, I reviewed all the usages of the data from the boardAsset files in TaleSpire. There were clear patterns in the usage that will allow us to pick better data layouts and divide the data that is needed in jobs from the data, which isn’t. This description is pretty vague, but basically, it’s good news :)

I’m going to play a little with non-burst-compiled jobs in Unity as they are going to be useful in the future when I need to do simple processing on non-blittable types, but don’t want to have to introduce a sync point.

I’ve also started looking back into a bug, which forced me to hold off from fog-of-war before the beta release. I had a case where rendering to a cubemap would result in the top and bottom faces being flipped. I didn’t report it at the time (which was dumb on my part), so I spent the first part of today reproducing the issue and submitting the issue to Unity for review.

You can find the repro that shows the issue here. Luckily it seems this issue does not occur when using a different RenderTexture constructor as reported by this lovely person here. With this knowledge, I can dig back into this and see if I can make more progress on fog-of-war again.

I can also give an update that the last bug we reported to Unity has been successfully reproduced internally, so odds are good that we will see progress on that in the future.

That’s all for now. I’ll probably make a more detailed post on the fog of war implementation once I have some more news.

Peace

I’ve been a little quiet today, but I’ve been around. I’ve mainly been testing and re-checking the code that handles board format upgrades. I didn’t push out an update today as, during testing, I saw some cases where GM-blocks showed up incorrectly. I’m pretty sure these are pre-existing bugs, but it’s better to delay the release and fix them, rather than take the risk.

Tomorrow I’ll carry on testing the board format upgrading and then put out the release. Initially, the release was to add fog control to atmospheres but it now also includes:

• A fix which means that when you return to boards, it (finally) remembers where your camera was and where it was facing
• A fix for one instance of an error where, on rejoining a board that failed to load, you got a ‘failed to correctly assign internal id’ error.

And of course the above gm-block fixes.

After this, I’m aiming to focus on updating the asset format used by TaleSpire. I’ve been talking about doing this for about a year, but other things were always more important. The big goals are to improve load times and to make the asset data accessible to the job system. This will be huge for me as there is far too much complexity and inefficiency in the asset code due to constantly having to repack data in structures amenable to the job system.

Of course, some community projects have started consuming some of this data and, even though use of that data is not supported, I’d rather not break those. What I think we’ll do is make a portion of the data available as a separate json file. TaleSpire itself won’t use that file, but it’ll be handy for others. I’ll keep you posted on these changes.

Have a great evening folks,

Peace.

Yesterday didn’t bring too much new from me. I submitted the potential bug to Unity, pushed out our release, and then spent most of the day catching up with social media and discord posts.

Today I’m going to try staring at the ‘delete tiles coming back on reload/copy’ bug and see if I can make any headway on it. It’s a real nightmare of a bug as it’s hard to reproduce, and it seems to be about something that isn’t happening. It’s not throwing any apparent errors and doesn’t show up until way after the presumed event. I’m not expecting to find it today, but maybe I can rule out some potential causes.

I hope you have a good day folks!

p.s. A note to people thinking of doing the indy game thing. Do not underestimate the amount of time it takes to write updates, handle support tickets, keep up to date with your community, and do the business stuff. It’s a privilege to have these ‘problems,’ but writing updates will take you longer than coding some features :p The less of you there are, the more time you’ll each be spending. Shout-out to Ree & Dwarf who’ve handled all the support tickets and business-ness while doing all their other jobs too.

Ah, it’s a been a day that reminds you that rarely in programming can you ‘just’ do something.

On Saturday, I wanted to push a patch that fixed a bunch of bugs, one of which was related to an SSE4 requirement in the current build.

The fix should have been simple, SSE2 support has been added in later versions of the Burst compiler, we can just upgrade the package and rebuild.

The package is still in preview, and so there can be bugs. However, sometimes that kind of tradeoff is worth it, especially given that we are still in Beta. If it passed our tests, I’d have been happy.

Alas, we quickly saw issues which only occurred in the Burst compiled jobs. Time to get testing :)

As expected, the commit that caused the issue was the one where we upgraded the packages. We then tested each version of Burst and Unity.Collections to track down the first version, which caused the error.

In the release notes for the earliest problematic version we saw that one change was:

Improve codegen for structs with explicit layout and overlapping fields.

This was a great candidate as we had a type that is essentially a c# union. You can write such structs in c# like this:

[StructLayout(LayoutKind.Explicit)]
public struct Test
{
    [FieldOffset(0)] public int A;
    [FieldOffset(4)] public Bar B;
    [FieldOffset(4)] public Baz C;
}

I took our structs and removed parts until I had a simple case that showed the issue. I then moved it to a separate project, re-confirmed the packages and pulled other Unity versions to make sure it was still an issue.

I’ve made a repo for the test, and tomorrow I’ll report this as a potential issue to Unity.

Now the take-away from this is not to shit on Unity. This is an under-development build of the package explicitly available for finding these kinds of issues. This is just development.

However, it’s a fun example of how ‘just download it’ is almost never really the case in any significant project.

Hope this finds you well, sorry I’ve not been around the community today, constantly recompiling does not make one that sociable :p