Devlog KAG March Roundup - Script-Accessible Textures, Fixes, Materials Changes

Hey folks,

This month has been slow going. I've been moving into shared office space and had to spend some time on other projects. I'll let the effect that's had on KAG progress speak for itself.

On the plus side, I've been working on getting script-accessible textures working. I'm hoping I can supersede the existing ReloadSprite and TeamTexture and PixelOffset stuff using this functionality. This will mean there's an "do it yourself" path to more team colours, multiple team colours, combined textures, procedural texturing and more.

The first working script-generated procedural texture in KAG.

And the code that generated it (just a simple dither pattern).


That legacy functionality (teamtextures and pixel offsets) will be deprecated but not removed - if I ever manage to completely remove it from the KAG codebase, I'll print a warning the first time they're called from mods. I might need to change the behaviour of the PixelOffset code to leave the texture content alone, but it depends whether I can just shield the script-accessible textures from those changes.

I've had to fight the irrlicht texture cache quite sternly - it's not so much of a fan of external references, but it does obey reference counting. What this means is I can make old copies of textures that have been removed from the cache not be deleted until they are actually not used any more. The alternative is the game crashes as soon as you delete a texture that's in use.

There's still quite a bit of work to be done here - there needs to be a way to plug these textures into all the existing renderable stuff, but the screenshot shows that I've got sprites working, getting it working with particles shouldn't be too much of a stretch. Getting it working with the GUI code might be a bit more troublesome, as there's a lot of functions there and just doing a renamed version of them sounds.. quite awful. I'll look into my options there before settling on anything.

This development is as a result of looking at the pixeloffset code and not wanting to fight it if I can avoid it; I'm still looking at options for a quick fix, but if I can just completely sideline the old code I'd like to, as then there's minimal room for downstream bugs.


In other news, since last build, I've also fixed 2 bugs:

• Crash with moss stone block tile close to bottom of map
• Receiver script error when placed a particular way

And made a small handful of tweaks:

• Fellere Four Rivers removed from the default rotation (host this on modded servers if you want it, file will still be there)
  
• 2 community maps patched (shark romance and ant queen)
• Cannot open siege-containing crates within 5 blocks of the map (avoids them glitching/falling off towers)
• Added file chunk size autoconfig var (allows throttling or speeding up mod downloads, defaults to 8kB per frame)

Also, @Fuzzle has sent through a series of changes for the materials code. I'll let him describe the changes below as I'm quite short on time. This involves some breaking code changes that might affect mods. He says he's happy to liaise with any modders affected and get their code working again.

 

FUCK YEA
cant wait for texture stuff

 

Looks boring but this builder's texture (note: fem texture) and pixel offsets are handled entirely by scripts now. Team colouring is still missing but I'll make it more extensible once it's in. I'm also considering re-adding the skin colouring that never made it to the public build.

The only problem is coordinating where to store the data and handling all the sprite "reload" events that are needed - the way it previously worked, there were a few magic "reload" triggers that may or may not be acted on based on the filename set in the sprite. All of that is a hairy nightmare to debug, and instead i've made the onReload hook fire when the team, sex, hat, head, or class numbers are changed.

I'm wondering how to handle legacy code here. It's tempting to just say "it should all just work" but the texture system is a horrible mess, and if I leave it around the sprite system needs to "know" about both ways of doing things, with sometimes incompatible semantics (eg: what does it mean to "reload" a sprite after its texture has been set - there's no file to check any more).

There's also a pretty heavy memory cost to letting the existing team texture code recolour all the sprites before the scripts get a say in it - if they're going to do their own recolouring, the work done by the engine will sit around, wasted. There's currently a lot of "grey, blue and red" variations loaded - the blue variation is always loaded, anything that's neutral team has a grey variation loaded, and anything that's player-related generally gets at least red and blue teams loaded. This is even the case for textures with no team colours at all - and it means that KAG uses effectively double the texture memory that it could. It's not exactly a huge amount of memory as it stands anyway, but it matters for people playing on toasters and just rubs me the wrong way to have so many copies floating around.

The way I'm considering doing it is:

• Having the engine by default just load the file and assign it as is, doing nothing further with it. No team textures, no pixel offsets.
• Add some kind of LegacyLoadSprite() function which would do the rest, for those that wanted it (for compatibility with older code), and would set a flag on the sprite re-enabling a lot of the older behaviour.
• I'd like to add a new hook (different to onReload) to notify scripts that something changed and maybe you want to reload your sprite (probably with some kind of flags object telling you what changed) - and fire off at the end of the frame, not mid-call.
• Do the rest of the work in scripts; data can be kept blob- or rules-locally easily enough.
• Profile and optimise whatever doesn't "like" this system. Cant think of much off the top of my head though.

 

Oh this could give some fresh spice to the textures.
If you need somebody to replace by hand the skin colours, to have separate skin sheets rather than substituting colours via engine (if that makes more sense or is lighter for clients-servers), hell, I can do it.

 

I'd really rather do it in-engine, but if I was going to do it externally I'd write a script rather than get someone to do it by hand ;)

Just the top of the map, actually.

Nope, as franek said, sorry.