The engine started out as a fairly simple parser. The reason for this is that I wanted
to have a good scripting system. This way to make a game or demo, one would not have
to edit or add much code to the engine itself, but merely write a script to controll
the engines already existing features.
The lexer pulls data from an array (called parsBuffer()) and sets engine states
accordingly.
In the case of how vertex data is stored, the parser subroutine can be sent many different
codes for what mode it should operate in. These modes change based on what type of file
you are trying to parse. In the case of .raw model files (exported by the Blender modeling
app) the parser fills an array called modelBuffer(). After the modelBuffer is filled the
program is then routed to a loadModel subroutine.
The loadModel subroutine is the final stop for vertex data. A lot happens here. The
vertex data is put into a multi dimensional array called vertexArray, the first dimension
of the array stores the models code number, and the second contains all of that models
vertex data. This allows multiple models to be stored in that same array. Also in the
loadModel sub, is an array that stores modelnum and that associated models properties, such
as filename, and object properties.
In the script you can define object properties, such as rendermode (wireframe, points, etc).
When you define the rendermode for an 3d model, those properties are stored to that modelProperties array found in loadModel. This allows for many options for how you would want to effect an 3d obejct. Such as, but not limited to
-render mode
-key bindings
-anim bindings
-path bindings
In the script you might have something that looks a bit like this.
engineMode fps
load 3dcube.raw
bindInput 3dcube.raw
renderMode 3dcube.raw quads
That little bit of script would tell the engine that it is running in "fps" mode. And this means
that if an object is bindInput, it will be bound to the standard controll scheme of an fps style
game (wsad + mouse). Obviously you would be able to override the standard control schemes, but in many cases you would not need to. Second, in the script loads the .raw model, and after binding fps input, the engine is told to render that model in quads mode.
Some of my newest additions, are multi line comment system, that allows comments to be contained in the script. For example...
/* this is where
we start the engine */
engineMode fps
This is how the multi line comments look at the moment.
I am also working with occlusion and culling. Right now I am working on an extremely simple spherical object culling system. The way this is working right now is, the distance between vertex and center of the camera is measured. Any first vertex in a set of 4 verticies, and the 3 verticies that follow it that exceeds the limitation of view distance is not rendered. A little more clear way to say it is. If an vertex is out of range, the entire quad is not rendered. This means we skip 12 sets of coordinate data. This is going to be for static objects only in the future. The way it will work for dynamic objects is, the entire object will not be rendered if just 1 vertex is out of view.
The reason I get rid of the entire quad on static objects is because it is slow to do a check for each vertex to see if it is out of view. If I check only the root vertex per quad, this is much faster! We save the time of what would have been 12 conditional checks, that involve complex floating point math, per quad.
It is a bit slower than Octree's would be, but much faster than nothing at all. It is also much more simple then Octree's I might add.
