Filed Under: Journal - Development - Game Development
So I've been giving graphics a lot of thought again, now that I've got at least somewhat a workable network layer. It's still missing a UDP executor, but my grey matter is still wrangling that for now. I've been wrestling with the rather odd quandry of how to consolidate a virtual inheritence tree with renderable objects.
As I see it, generating the tree isn't that difficult a thing. Since OpenGL is so nicely stateful, a renderable object would rather easily consist of things inside containers which are also things. This paradigm seems to handle everything quite nicely from the projection matrix down to the smallest triangle. The real problem is generating these trees intelligently, and rendering them in a relatively quick way.
Since the largest advantage of a tree structure like this is the virtualization of each object, it follows that they all have to inherit from a pure virtual base class they can be handled by. At the same time though, more complex objects like landscapes which contain potentially thousands of triangles would incur a huge overhead when dynamically dereferencing each of the child triangles. A couple of solutions to this problem seem apparent, one being that the virtually inheriting classes are simply inlining abstractions of non-virtual implementations, which would allow complex objects like landscapes, which will only contain triangles to contain only triangle implementations and therefore skip all of the virtual derefrencing necessary. The second option is simply to count on the compiler to know that the pointers actually point to the type they are referenced by, which seems to be a fairly consistantly correct assumption, at least while using g++.
The other problem is one I'm less certain how to resolve is how to cull the renderation, and calculate useful bounds for the children of each node. Since this structure is intended to hold all the objects in the scene, many of the objects will have continuously moving locations or changing bounds which restricts them from playing nicely in a quad tree, or any other structured tree which recursively crops invisible nodes. Perhaps a good solution is to keep two or more seperate trees, one which contains only a flat representation in which all the elements must be checked all the time, and another passive tree which can be stored as a quad or oct tree.
I suppose I can just write the code without the abstracted implementations and strip out the implementation code after if the compiler is generating dynamic casts all over the place.
On a more personal note, it's nice to be back on graphics, even if just for a while. I've been getting awfully bored of network abstraction, and there's still all of the scripting abstraction to do. Not to mention the fact that I haven't even picked a language yet for the script to be in. Probably lua, but I wouldn't mind looking into php since I already know it. My guess is that it'll be too heavy anyway, and there will probably be license restrictions since the final destination of this whole thing is a closed license product. Something tells me that a simple abstraction layer doesn't count as enough seperation to allow it to be linked into a commercial product without being properly license, and even if it was legally I would feel wrong about doing it anyway.
There's also the issue of a map editor, which I would assume will be one of the first projects after I've finished the chat and pong. Actually, it should probably be after (or consecutively with) the final rendering engine so I can see the results of the editing real time. And because I'm impatient.