Completely untitled post

Added a few macros for fixed-size matrices and vectors that work the same way as ITK_VEC_L1 and it's variants. They an be used like normal compound operations (evaluating in the address of the target object) or like temporary values created sing {} brackets. This way it's possible to create temporary anonymous matrices and vectors if needed. It's really interesting to see how easily compoung and non-compound operations can be done with pure C code. Expressions really become your friends in such situations (if they aren't already). A lof of stuff should be possible with this, but it does of course increase compile time due to quite excessive macro use. Flexibility comes at a price, as usual.

Anyway, this should ensure that I can do stuff like with normal operators (though in a somewhat different syntax). Atleast I hope so because I'd like to finally continue the stuff with actual output that's not just made of pure helper functionality. Some further analysation of the current command string render system made me realize how flexible it is. You can feed the system via sorted or unsorted linked lists, via arrays with long, generated commands string or by using a repeat parameter (and thus profit from faster execution because there's just one command to execute). Very nice indeed, but it has way of visibility clipping or scene assembling, which should be done before feeding the renderer. Personally, I prefer to split stuff this way because it's already a bit blown with this command string stuff.

Guess that's another project after I've done the basic 2D/3D stuff for IGE. There surely is still a lot to do but I like to know what stuff should be done next. The more options I have to expand my own tech for future stuff, the better it'll merge with new stuff. Atleast I hope so... Whatever. Creating some sort of scene assembling will be tricky. My understanding of virtual worlds does consist of cubes in cubes or rects in rects. Some sort of boxing is always present but I wonder how visibility detection can properly be done in combination with the graphics card. In any case, I'll atleast have to know what's our frustum in 3D or screen rect in 2D. For a non-perspective, axis-aligned rendering it's in fact trivial - that's not the difficult part. The difficulty is to combine my block arrangement with a possibly arbitrary visibility volume. Hm, in theory I could just interpret the "view volume" as a convex polygon and then apply a specialized rasterization to render determine what screen is visible in the block/box space. That may be a good idea! An octree would be perfect for this: strong, all-same box alignment and a flexible number of resolutions for adding a lot of details. One could even combine animated octrees when using the matrix used for the rotation... Yep, that could work. All I need is "a bit more time"(TM). But I think that's the perfect way of creating levels and 3D scenes for the stuff I do. Guess RPGmaker left it's mark on me with it's tile-based world creation..

No comments: