4.29.2012

Quite a few ideas

I had a lot of ideas and concepts the last couple of days and most of them shoul make perfect additions to IGE and ITK. I haven't yet updated anything since the initial 0 versions, but I'll probably do this when I tested them well enough. Since I usually connect all the new stuff so things I actually want to archieve with it, it'll be bound to IGE as well. But where to start with all this stuff? Well, first of all I've taken my previous idea of file operations to the next level by beeing a small but completely sufficient set of multi-target memory operations supporting files, memory, scalars and repeated buffers as input and output (though with some restrictions). It's not urgent or so, meaning that I'll move it to a later point where I'm in the mood for such rather tedious programming tasks (though I the idea because it merges two or three very similar modules I already moved out of ITK due to beeing superfluous). In a straight line to this we got a final draft of some highly generalized and lightweight serialization I've been dragging around with me for quite a long time. The current concept involves three or four files to quickly dump type information, memory blocks and mapping tables without any complex memory assembly or redundant file operations. But I don't intend to add more than dumping binary data and marking pointers to be updated later. Nothing fancy, just an quick dump and restore of scattered binary data. The third concept is sort of a less program-related notation of data, similar to an extremely stripped XML file based on control bytes. The idea is to have that sort of tree-like model found in XML documents but encoding a branch's begin/end using bit flags that also include information about the data that will follow, whether an additional integer or string identifier is included in this branch, whether the data is purely binary, a string or whatever else. The idea is to not have the large amount of text data of human-readable files when storing image or vector graphics data as well as having the stuff ready for iterations with identifier support and so on. You can even store bitmaps with ease in such a format, as a single pixel line only requires the line size and a preceding control bit with both end and start flags set. I really like the concept, especially because it's very easy to generate and parse. In combination with the generic memory/file transportation I described above, it'll be easy to write this in a very compact way. Even better, you can nest any data you want within it and could even support simple RLE compression by just setting the few empty bits and other stuff I haven't yet planned. Well, it's a bit limited with only 8 possible flags, but what would you need more? And last but not least I worked on IGE of course with some interesting aspects all leading to a really nice generalization of image and vertex/position data I can use for quite a lot of things I'm not yet completely aware of. All in all, stuff's getting more interesting and I'm glad that I don't work on it most of the time. I mean I'm starting my internship in justa few days - 40h a week - so I can recharge my thinking cap while doing other stuff. After all, I won't work on the stuff I'm working on right now, so the contrast is there and I get time to think about it on my way to work. In fact, I doubt that it's good for a video game company to use the tech I use - macros are hard to debug, it takes time to combine and, most importantly, takes ages to fully design since I try to inform myself about every aspect and existing solutions to form a better one. And that's one hell of a slow process I can tell you.

No comments: