Build-summon effect

Example starting town

Long time no updates! I haven't been idling, as IRL stuff have been in the way, mostly working a lot and changing a job. Without further ado, time for Sigil of Kings updates!

EntityEffect refactored to a system

While bug fixing, I located yet another small subsystem that ... stank a bit: entity effects. This is logic and data associated to visual effects attached to entities, e.g. when a creature is burning, there are flames overlaid on the creature, or when a creature is frozen, it's a bit more blue-white. Sometimes the effect needs to use the underlying sprite (e.g. boss aura) and sometimes it doesn't (e.g. burning effect). Sometimes we need a new pass and sprite to render the effect (boss aura and burning effect) and sometimes we can just apply a modification on the actual sprite (e.g. frozen effect). So, there are a few complications.

Previously, I had decided to have this subsystem embedded within the rendering system, because it's rendering related. But the rendering system has grown a lot, too much in fact, so it needs trimming. Thus I extracted the functionality to a different system, and refactor the API to something simpler. Code is now clearer, fixed a couple of other bugs along the way, and that's about it! Of course, nothing visual to demonstrate for this, which is an unfortunate pattern lately.

Starting town fov/explored, and position

Previously, player started in the middle of the map with nothing explored. This is not how it's going to be, so it might as well be improved a bit now. I've changed it so that the player now starts at the city tile closest to the center of the map (later on it might even be player choice). But to make things a bit nicer, the territory occupied by the starting city is revealed to the player, as "explored" rather than currently visible (so, slightly darker). This makes it slightly less claustrophobic to begin with, and at the same time it should hopefully incentivize exploration.

Undeath/build effect

I have this nifty destruction effect which breaks the sprite into small bits that fly/fade away. Reversing the effect looks like we're summoning things out of pure air, so I've added this for some summoning spells or building activities. No concrete gameplay scenario implemented, I just liked to have it :)

Inventory and item transfer

A bit of refactoring so that I'll be able to reuse quite a bit of code between inventory screen and the various transfer screens. The "inventory pane" has been abstracted out, that includes header and item list (text filter and tab are set "externally"). It will make more sense with an example when it's ready (e.g. chest or item pile transfer).

Split stack

Was clearly untested, a few bugfixes to make it work, like hooking up buttons and showing actual quantities of items in inventory

Color ramp support

This whole subquest started from getting a notification about a new free(-ish) tileset on itch.io. Includes lots of effects, and in 9 color variations. It always bugs me to see those specified as different sprites, because it's such a waste. I like the effects, but I don't want to have a copy for each different colors. There must be a better way! (and of course, there is). Rabbit hole time!

The way these variations are typically done, are using color ramps. This is a mapping of all 256 grayscale values to an RGB color, stored as a 1D texture. 1D textures and color ramps may not be popular with indies who tend to keep things simple, and that's why (I suppose) we don't get the color ramps. Also, it's better for the artist to say "1000 sprites!" instead of saying "100 sprites + 10 color ramps". But I don't like redundancy, so I want those ramps.

Getting the ramps is not too hard thankfully, as in this case at least the artist has provided a grayscale version that can be the baseline. So, the process of extracting a color ramp from the grayscale effect sprite and a coloured one is as simple as matching the grayscale value to the corresponding RGB one. Sometimes there is more than one value associated - in that case I use the average. Sometimes there are missing values - in that case I use interpolation based on neighbours. That's it!

Doing this work has led me to wonder: why are color ramps not yet first class citizens in my game? Time to fix this! The plan is to make a texture with a predefined set of color ramps (1 per row) and bind that in shaders that need to use it. This means that, for a color ramp texture where we have e.g. 100 different color ramps, the dimensions will be 256 width and 100 height, and the color ramp index needs 7 bits in this case. In reality I'll set a hard limit of 256 color ramps, and an effect can specify the effect sprite as usual, and the ramp index using 8 bits.