I have to admit that I didn't code much because I didn't quite knew what's the best way to continue without needing to rewrite stuff later. See, OpenGL's API is almost exclusively made up of functions calls and I guess that a lot of functions just fill some buffers with no real function code at all, just stuff that could be done inline. Sooo, just adding stuff and properties and function calls to graphical elements becomes more and more slow and also removes the possibilities that come from just mixing OpenGL calls in random ways. Previously, I described how I thought about using some sort of command string as a more dynamic way of reducing requiring memory and function calls. The idea is interesting enough to completely drop any number of fixed settings for display objects, keep the z sorting to seperate and order different depth buffer clearings (for rendering seperate scenes or sprites) and provide arrays/lists with command identifiers and parameters as the sole input for describing the stuff that should be rendered. I don't know how's OpenGL implemented under the hood and whether this may just be another layer of the same functionality, but that's not important right now. I'm always looking for interesting ways of feeding programs and compilers in my freetime, so this just perfectly fits. I'm having quite a lot of interesting ideas that would make the whole state machine thingie OpenGL is made of to work a bit more nicely and less state-dependent. It may even integrate well enough to completely drop all inefficient atom-like OpenGL function calls and just rely on given array addresses. Don't know what exactly I can do with OpenGL this way but I trust my idea to be the perfect way of feeding a render system (yep, I'm quite arrogant today).
Soooooo, I have to design some command sets and related trees/constants to let stuff happen more efficient! Yep, this includes some more reading and reasearch. But well, more time spent on developing good solutions does usually pay off in some way.