X5 - Meta update 1

download


So, here we are then. This is pretty much where I left off. This update adds the meta and the code is getting slightly more complicated for it. Some things are still out of place - but the next step is a little bit weird also. Uhm ... well, let me ... . Well, for once I'm a bit torn about how the memory is being managed. I mean - the thing, and this has been a bit of a problem for me since the very first time I got to this. In principle - so the design concept, or say: the lack thereof - led to this issue that once "being in the meta" - all of the system, the entire setup, was inaccessible. And well, of course. But my ideas for how to realize this interface ... well, there have been iterations and ... it always felt a little bit too hacky for me.

So, to this end - this is an intermediate update. It only slightly modifies how the system functions for someone toying with it - and it's a good "exit point" as things will take a bit of a shift from here on. Well. Things are getting complicated. And this is still close enough to the "raw" - while being already not that anymore.

So, what's happening here is that the primary include is the intended one. The file ljack.cpp is here not to be confused with the one that is to contain the Lumberjack code. It's more to say: This code is to produce "ljack" as such. The point is, that the Meta itself is comparable to a Window Manager/Desktop Environment in linux/xorg - but conceptually also a backend to whatever project might want it. So, there isn't an explicit use-case here. And to be real - I'm still trying to make my game.

The first option would be to write my game using Lumberjack "as intended" - which would be to have it be compatible with Crystals as an OS - speaking of the codebase. The next would be to modify or create a meta tailored to being a standalone executable focussed on performance. This is ... well. Initially I thought of an M mode and a T-Mode - with M mode focussing on multiple applications while T-Mode is basically Fullscreen but for the System. So, removing the overhead that M-Mode implicitly comes with.

Conversely ... welll, not important.

So ... is this usable?
Well - the final shape is however becoming visible. And that also takes us to the problem I was working on. And I'm thinking that I should perhaps ... explain a bit about what it's all about.


The BIG thing here is the Supercore. The Supercore is at this point functionally a part of the M-Core. At this point it's only here to handle "Access Units". It has essentially three things: A Source, a Unit Class and access to the T-Core. Anyway: These Access Units aren't to be mistaken for "applications". And to put it in really simple terms: The Supercore is our very lazy solution to having something like audio playback in the system.

So, the Supercore can be thought of as a System Stack. Well, stack is not the right word I suppose. And speaking of a Window Manager - that would be One Module. In essence: The M-Core/Meta is thought of as an Access Unit. And in as far as applications would take care of audio for themselves, that'd be fine. But if we wanted to separate processes from the "main system" to have some kind of "true background" functionality, it has to be decoupled somehow. I guess.

I mean, that's "the theory".

The thing is also that I have to keep things simple - while what the code can do should be a part of it, and not just some lofty ideas. But the best I can do is some middle ground.


Uh ... sorry. I forgot - I'm awesome now!

Well. We'll see. And - yea. I'm sure that the problem exists for a reason. Maybe it is just a minor multifunctional inconvenience. And so I can tell you here more about it - which will also make the next step a little easier. I mean - whichever way I look at this - now it's time to wire in the System Core and get something to the Screen - and to get something to the Screen it should also run as intended because just opening a Rendering Context ... that's silly.

So, that's the problem. The rendering context.


For once I had to contend with my habitual thinking on this. Like - I would come to this point, not have the system setup to do what had to be done and so I'd skip it.
Dangit! I keep on thinking: Actually - I should just ... do it, now. But then I look at my code and feel ... no, it's better this way.


I mean - precisely: What I'm going to do next is to mess with the system a little. I'll be starting to build some utility into this thing; As to give you an example of - a thing I guess.
And maybe I'll be leaving filesystem access out of this for now.

Yea ... I might be overthinking this right now ...