The Compton engine itself is still very much in mind for a very particular game I've wanted to make for a long long time too, hence the hesitation, so this is pretty much a matter for me to buckle down and finish that damn game at this stage. Though it's not like Compton doesn't have it's own challenges. Sigh.
Unsurprisingly my plan to prioritise also didn't pan out... I've wasted a good amount of time farting around as usual with a number of different projects. Really need to experiment and learn better ways to focus myself when it comes to these things. I'm at least very concious that Compton and Yin are my two primary focuses, but now and then something can distract me for a good few weeks for something that's really too ambitious for my own good - I'll get frustrated, and then rinse and repeat.
I'd also made Yin public for a brief while on GitHub, but it made me feel a little anxious about touching it knowing there could be eyes on everything I'd be doing. For now I'll likely continue with the routine of making whatever with the engine and then releasing that copy of the source code once I've progressed further along. That said, most future publications will likely be under LGPLv3 rather than public domain as I'd done in the past.
Actually I'd forgotten to mention before but Compton isn't public on GitHub either anymore, though in that case it's more so that I don't want anyone playing the game I'm working on there before it's ready (whereas in the case of Yin, there's currently no game.)
Worth outlining that I'm not bigoted enough to think that Yin as an engine is useful to anyone but me, but I'd hope that some things in there could at least be somewhat informative or educational, either as a do or don't do this sort of thing. Probably more of the latter.
With that out the way however, here is a list of things that I've done for Yin since the last post (pretty much just had a quick nose through the significant bits in the commit history, given I don't tend to keep the changelog especially up-to-date.)
- Began migrating what exists of the editor into the engine
- Made more progress on the AST for Dickens scripting language, though there's still a long way to go
- Implemented a preview state for materials, so you can see how it may look without having to necessarily load the whole material into memory; used for the material browser
- Implemented a first pass of the material browser
- Created new icons for the editor modes
- Pulled over the binary serialisation system from Compton
- Made a minor syntax change to the Node format; 'integer' type is now just 'int', for consistency
- Experimented with creating a face-inspector for the World Editor
- Updated the memory manager so for cached objects we now store a hashed name as the id, store a descriptor for debugging and use the hashed name for the lookup
- Rewrote the lighting shader
- Overhauled the profiling overlay
- Updated the Blender plugin to support the latest format changes
- Introduced a file aliasing system, essentially allow you to override a file I/O request with a different file
- Default mount locations are now provided by a Node file rather than being hard-coded as before
- Added support for bloom
- Mouse look (finally)
- Gave the client-side input code a bit more TLC
- Fleshed out client state management a bit more, with query for connection with server-side etc.
- Reintroduced fog which can now be controlled via the world properties
- Started hooking up player movement again
- Face normals are now generated
- Started implementing visible face determination and portal traversal when drawing the scene
- Started experimenting with mirrors
- Started implementing Lisp interpreter as an interim solution until Dickens can replace it (or they'll more likely live side-by-side)
Most of the significant work lately has been towards the World stuff, which makes sense I guess since it's sort of the meat and bones. The engine can now pretty much go from sector to sector and collect a list of visible faces, then split that between portals or just general faces, and then we could pretty much now just keep rendering the same sector over and over from each portal with all the actors correctly transformed over.
Downside is that there's still lots and lots and lots of work still to do, especially on the rendering side.
Lighting is an obstacle that can technically now be overcome (right now light sources are hard-coded and then passed through the material system as if they'd been picked up for that particular surface) but it's still a question for me as to how lights are generally best implemented. Long long ago Yin was originally envisioned as a scene graph oriented renderer and the API for this still actually exists in the engine, but as I experimented and prototyped I'd somehow just drifted away from it, but to get to where I need to be it really would make sense to go back to that design. Point is I'd like to do this before fleshing out the lighting system more.
This video shows some experiments with updating the lighting, as it didn't really behave correctly before. There's support for specular and normal maps, however they're not demonstrated in the video below (fairly sure I demonstrated them in the past at least.)
The screenshot below shows the initial pass of the material browser which is scalable too.
The eventual plan is to have it so that clicking onto (or hovering over) the material might give a (probably optional) live preview, so you can see how it immediately looks under lit conditions or with animations playing.
This final screenshot shows a quick little test map I whipped up with the Blender plugin; you can pretty much mesh out whatever geometry and just export it for the engine as a "World Mesh", which can then be used as the body of a sector. The gateway currently features a portal surface which is just being used as a mirror, though there are some problems I need to solve with this at some stage (not to mention mirrors are a bit of a stretch goal).
