Elegy Engine, USB handbrakes and productivity
So I finally found some time to re-enable rendering in Elegy. I also noticed I've been a bit more productive lately. Oh, and my ESP32 chips arrived!
Legacy blogs about Elegy Engine
View All TagsSo I finally found some time to re-enable rendering in Elegy. I also noticed I've been a bit more productive lately. Oh, and my ESP32 chips arrived!
Very epic news! If we look back at April this year:
Congrats! A door that will never ever open. I did also think about triggering and stuff, I even went ahead to modify TrenchBroom a bit so I can have autocompletion for these triggerable events, e.g.
mydoor.Open()
can be a valid keyvalue. However I need to experiment more.
You'll notice I didn't exactly have triggering implemented. I only thought about it. Well GUESS WHAT.
I have extended fennecs
with my own stuff on top, in a separate library which I might as well release in its own NuGet package! Eventually.
As of recently, the Elegy team has officially gotten a new member! A friend of mine, Amara, is gonna contribute to the tooling and stuff which is very epic.
A big change happened again. The engine subsystems have become separated from the engine. Now the engine is basically an application framework, and using code generation it automatically initialises and launches various engine subsystems.
This way tools will only use what they need from the engine, and won't pull unnecessary dependencies with them, reducing needed filesize and stuff.
A couple weeks ago I experimented with a hybrid ECS that supports Source-style entity OOP... now I've thought up of a concept that might just make that obsolete. My idea for entity components was basically twofold: massive data processing and entity traits.
I experimented with the entity parsing a bit further, and was able to elegantly make it work using code generation. It's very powerful, I must say!
A couple weeks ago I experimented with a hybrid ECS that supports Source-style entity OOP... now I've thought up of a concept that might just make that obsolete. My idea for entity components was basically twofold: massive data processing and entity traits.
Entity traits would "inject" functionality into entities, and honestly, I think this is just the way to go. FGD files would become entity archetype descriptions at that point:
@BaseClass = Door
[
Door.Angle(string) : "Open-close angle"
...
]
@SolidClass base( Door ) = func_door
[]
@PointClass base( Door, Model ) = prop_door
[]
The material system is now a thing. It can read Quake 3-style material definitions like these:
materials/tools/nodraw
{
materialTemplate NoDraw
{
// TrenchBroom dies upon encountering quotation marks here, so do not use them
map materials/textures/tools/nodraw
}
compilerParams
{
// Stripped away
Nodraw 1
// Nodraw implies that lightmap will be 0, but yeah
Lightmap 0
// This one will probably need tweaking. If we ever end up
// using brushes for collision acceleration, this will have
// to be 1.
Collide 0
}
}