What I’ve been working on today…
Created a stub for lxcore.lib
Currently, LxEngine is composed of the following:
- glgeom (header-only library of math functions)
- lxengine.lib (where the vast majority of the code is)
- lxengineapp.exe (a small front-end that drives the code in lxengine.lib)
What I’d like it to be is:
- glgeom (same as before)
- lxcore.lib (low-level, standalone functions and data types from lxengine.lib)
- lxframework.lib (the higher-level framework of Engine, Document, View, Element, classes)
- lxengine.exe (slightly larger front-end that drives the framework in a flexible, configurable form)
That’s a bit of an over simplification since there’s also extension libraries like lxrasterizer.lib and plug-ins like soundAL.dll, which exist now and will continue to exist.
The general point however is that I want make the framework “leaner.” Right now it has too many specific features (mostly from early development when things weren’t very modular) and it should really be a rather bare but flexible MVC framework. Those features belong in plug-ins and extensions. Even the utility stand-alone functions belong elsewhere (lxcore.lib). The end goal is a smaller framework is much better: frameworks are useful – right up until the point they become bloated and hard to understand (and thus defect prone and with steep learning curves).
GLGeom Error Handling
Long story short: all this time, I’ve been using “assert(0)” as an error handling mechanism in GLGeom to keep from tying in any dependencies. That’s not a very valid approach…
So I’m added a simple, but flexible error handling mechanism instead: docs here.
GLGeom Compute Primitive Buffer Adjacency Info
Still a work-in-progress, I’m trying to port over some old code that is pretty fast at computing adjacency from a polygon soup. This is also stressing GLGeom from a new angle, which is helping me fill in the blanks on some of the functionality in this currently-version-0.0.5-library.
Better get back to working on it…