Apparently someone got it running on an ARM device as well? I do have an Raspberry Pi here (actually 3/4 of them), but had not really considered doing this yet as I'd like to rewrite parts of the renderer first.
Things on Yin have been busy busy busy. There's been more work on the client/server architecture, entity components, input, audio and the material system. I've been bouncing around a lot.
Entity components are mostly done, but not yet had a reason to migrate over from the Actor system just yet, and there are some questions about how things will work from a user perspective (currently investigating entity templates outlined via node files). I've not yet considered how networking is going to work in relation to the components though...
New input stuff is mostly done, but again, not had a reason to totally migrate to it just yet, but you can outline a collection of actions with associated keys and the rest of the logic will automatically look out for any key activating said action before using a callback to do whatever is required.
For audio, there's now the AudioDriverInterface, which functions as an abstract interface towards whatever audio system is available on the given platform - in the case of Windows I've been working on supporting XAudio2 and on unix platforms I'll probably use OpenAL Soft instead. This isn't high up my list but I felt it was a good idea to get the ground work in place for doing something more substantial than what we had before, i.e. using SDL2 Mixer.
This was something that was originally envisioned for Hei but I'm on the fence about it for now, but if we have an abstraction layer for graphics in there it would probably make sense to consider one for audio, particularly as there's been a large explosion of audio APIs lately... Perhaps I'll migrate it down the line.
There wasn't really anything that substantial changed for the material system, however the post-processing is now handled through the material system finally, which was very much influenced by a bug I was trying to tackle. This did require changing how we handled the render target built-in variable, as previously this just threw over the render target used for the menu as a bodge job introduced for the game jam. The way in which we hand over the viewport size has been changed a little bit as well for the material system, but nothing too interesting to say about it.
Generally though, it's more flexible now. It also gave me an opportunity to experiment a little bit more with other effects and I think it might be likely I'll be looking at adding effects such as bloom, depth of field and more relatively soon perhaps.
Otherwise, I've been working on a tool to convert maps produced by Hammer/Jackhammer/Trench into geometry that Yin can use and been making pretty good progress. Been lacking motivation but I really hope to have it finished very soon, the only thing left to do is serialization and then we should be back to having proper environments again!
Added support for QOI to Hei before I went to bed today too. It apparently features compression close to PNG, but with a faster decoder, so that's pretty neat. It actually reminded me of arguments I'd had on another project about the speed of decoding a PNG though - dumbest argument I've ever had given it was a retro-style game with pretty small textures, so the impact was absolutely negligible, and if anything contributed to the load time it was our crappy material system we had at the time (which I take full responsibility for.) Anyway, that's all a story for another time.
Post a Comment