• Visual Basic 6 source (not updated since 4/30/2007)
• Visual C++ 6: Shared and Test source (build 5/24/2007) (make Test and Shared folders adjacent to each other). For now it only renders in OpenGL. You'll need the extension headers from OpenGL.org in order for the GL code to compile. Check the OpenGLRender.h header file for expected file location. You can get the required glext.h file here. Note that the .fnt files are my own custom binaries.

• (4/14/2007) Just a video demonstrating the portal engine with mirrors, static lightmaps, decals, alpha surfaces and a bouncing ball. Captured real time from Visual Basic 6.
• (4/18/2007) Another video showing off an initial attempt at dynamic lighting. Real time, Visual Basic 6.
• (4/18/2007) This is a sped up demo showing how dynamic light interacts with lightmaps and decals. Visual Basic 6.
• (4/22/2007) New version of lighting, using one minus destination instead of source alpha. Visual Basic 6.
• (4/30/2007) Lighting tweaked a little to pre-light around corners. Visual C++ 6.
• (5/4/2007) Demonstration of a bug I found while converting to C++ and incorporating shared offscreen lightmaps. Visual C++ 6.
• (5/6/2007) Latest version, adding doors, projected floor texture and a static light source combined with dynamic. Visual C++ 6.
• (5/7/2007) Multitextured terrain with projected textures and stars. Stars are rendered as lines when the viewpoint changes, although it's hard to tell in the video.
• (5/9/2007) Light flares. Currently, they don't show in mirrors or through alpha walls, as the demo demonstrates. Doing it through alpha walls would be tricky, actually, since an alpha wall can have solid portions, and I'd have to determine if the light is actually visible. Doing it through mirrors is another challenge. I would have to submit the alpha flares for rendering at the end of all things, then determine if they are actually visible. For now, I'll hold off on that, I think I'd like to try some particle emitters.
• (5/10/2007) Particles. This demo is of a fairly decent flame effect, requiring around 50 particles. I give each a slight reverse gravity with varying rates of reduction in radius. Not too bad. Next step is to get it into the portal map.
• (5/10/2007) Particles in the portal map. It isn't a perfect solution, I'll still need to figure out how to handle mobile particle emitters, since particles are only drawn with an emitter as it is part of a room. So if you fling a torch into a room that isn't visible, the flame particles it leaves behind will suddenly disappear.
• (5/13/2007) No demo at this time, I've been experimenting with quadtrees and octrees and integrating an octree into my portal engine to render mobile objects, doors, particle sets and light sources. After I get all that working I can focus on new effects, and maybe make a more complex map with many objects to render so I can test how well the octree optimizes the rendering and collision detection.
• (5/15/2007) Particles moving from one room to another. Previously, the particles would have strange erasures because they aren't being written with depth information. Now I move them from room to room and render the particles after everything else in a room is rendered. Here's another with a lot more particles - you'll hear a beep in this one, low disk space warning!
• (5/16/2007) Terrain shadows following the sun across the sky. If I were to implement this for a game, I would only calculate one cell of the terrain at a time, which should look ok as long as the sun is travelling gradually enough.
• (5/18/2007) I was goofing around with polling the joystick using Direct Input 8 and made a small demo allowing you to alter your viewpoint in outer space and fire some texture lasers. I want the stars to properly stretch from frame to frame but I'm having difficulty getting them to be consistent between a dark and lighter background. In any case, I'm tempted to try some other outer space style effects.
• (5/22/2007) Half-life 2, Episode 1, $10 download. Bargain! Anyway, full-region terrain rendering is coming soon, I'll probably have something tomorrow. Well, ok, sooner. Pardon the poor quality of the video. I still have to set up intersections between LODs and tweak the textures a bit, but so far, it's not a bad first try.
• (5/24/2007) Another terrain flyby. This time, you can see the divisions between the LODs that the engine is trying to fill in. I have yet to set the texture coordinates properly, so they mostly just look like colored strips. You can also see the blocks in the corners that I have yet to complete. There is a corner-only case as well that I discovered while testing.
• (5/24/2007) And here's a tentative final result. The pop up and down effects are a little disconcerting, but there are no holes, and best I can see the texture mapping is for the most part doing what it's supposed to. I'll have to try it out with some test textures to make sure it's all working the way it should. Later, I'll set the illumination and shading and see what the LODs do to those values.
• (5/30/2007) Not a lot happening at this point. Mostly, any changes right now would involve refining or improving the existing state of each part of the engine. I'll be more likely to come up with something new when I find another concept I've always wanted to try, or push myself to piece everything together into something more gamey.

Next up (in no particular order):

• Terrain occlusion to reduce rendering (requires best contained box, or multiple, beneath the terrain)
• Terrain rendering via frustum in preparation for merging with a portal map (window looking outside a house, for example), and looking into a portal map from outside
• Using texture instead of vertices for lighting and alpha blending across terrain so that lower LOD's look more similar to higher LOD's
• Accurately projecting a texture on an arbitary surface with an arbitrary rotation
• DirectInput keyboard (buffered) and mouse (buffered buttons, buffered movement if it works properly)
• DirectSound (maintain sound attached to objects, looping sounds, priority, max number of sounds playing and sequential sounds - more likely scripted sequences that wait for certain sounds to stop before starting the next one)
• Spotlights, both lightmaps and textured. Static spotlights will be easy for generating static lightmaps and lighting simple models. Dynamic spotlights require projecting a texture, which I can't do yet. And even with static spotlights, I'll still need to project them dynamically on to doors.
• Alpha flare options on objects that don't require light sources, like engines on a ship
• Merging the portal and terrain engine together for a complete world render
• Support for .tga RGBA textures
• .jpg loader
• Test speed of 64x64 sphere light splices instead of 256x256

Eventually I'd like to turn it into a simple dungeon crawl, complete with outside terrain, a small town with a quest NPC, a building with windows, and a cave with hallways and doors to explore.

Articles (sort of)

• Portal engine - things I learned while developing the portal engine
• Lightmaps - insights as dynamic lightmapping took shape
• Decals - my thoughts on decalling surfaces
• Collisions (bounce, slide) - methodologies for sphere collisions
• Quad trees (and octrees, similar concept)
• Particles - just some initial attempts and ideas
• Multitexturing demystified - for those of you curious about multitexturing, and are working your way up to pixel shaders
• Terrain - just some initial ideas on how I handle terrain rendering

Pitfalls

I've started and stopped a lot of attempts at game and graphics engines over the years. I'll start one up, it will get complicated, and I'll just stop because to improve it, things would start to get convoluted. Then, when I gets ideas for one again, I end up starting from scratch, barely ever re-using code from the old projects. It's not a great way to work, and probably more a matter of my own perception than the quality of what I've done before.

Start with a good game/window architecture

Should you make a window that calls the game code from its idle loop? Or should you make a game structure that keeps the primary loop and calls a sort of 'DoEvents()' so that the window can accept inputs?

Previously, I took the idle loop approach, and it just seemed cloogy to me. It made much more sense for the game code to command the primary loop, then go off and tell Windows to process its messages, then come back. When I developed software for a business using Borland C++, the ProcessMessages() command was used to allow updating a progress bar while data loaded, or even clicking a Cancel button to stop the loading. Visual basic has a similar command called DoEvents. C++ doesn't really have one, but it's simple enough to write one:

MSG oMSG;
while(::PeekMessage(&oMSG, NULL, 0, 0, PM_NOREMOVE))
{
if(::GetMessage(&oMSG, NULL, 0, 0))
{
::TranslateMessage(&oMSG);
::DispatchMessage(&oMSG);
}
else
{
break;
}
}

As far as I know, this chunk of code allows Windows to process all relevent messages for any window that is running, including the one you are using to run your program. When it returns, any Windows controls, keyboard or mouse events on your window will have been picked up and processed by your WindowProc routine. Basically, the DoEvents() says 'go accept and process inputs in my window', and in the WindowProc, you can code to watch for mouse, keyboard and button events and provide those results to your game code via your own homegrown event list, keyboard state array, etc.

Using this architecture in Visual Basic, I set up a spinning cube demo like this:

done = false
while not done
..Set Viewport
..Clear Screen
..Transform Viewpoint
..Render Cube
..Swap Buffers
..DoEvents
wend

and when the Done button is clicked, all it does is set done = true, and the animation ends.

To me, that architecture is more intuitive than having to set up an idle loop to call a variable chunk of code, not to mention having to preserve all the variables necessary for the specific routine running, since I would have to leave my procedure every tick, which loses all the local variables. I could define them all as static, but on the first run I would need to set some flag to initialize them... bleh, headache. If I'm going to run a looping demo, I should only need the variables required to run that chunk of code in the procedure with the loop, which I can conveniently define at the beginning of the procedure. Anyone looking at my code can then quickly see what kinds of variables I need for that loop instead of looking them up in an encapsulating class, and if they were to look at the list there, they would have to wonder which demo loops each was actually used for. Using the DoEvents(), pretty much the only common variables are done, keyDown[] and a couple others to facilitate what to do when the render window is clicked.

I've seen people say using the DoEvents() indicates a design flaw. I heartily disagree. If your program is entirely windows control driven, then you don't need a DoEvents() very often except when maybe a dialog has an animated progress bar with a cancel button and you'd like to keep the progress bar updated and have the option of cancelling the loop operation. I'm sure there are plenty of other circumstances. But games aren't window event driven. They are logic driven. DoEvents() allows me the architecture that is much more intuitive for me, and my Visual Basic code for this engine wouldn't have developed as far as it did without it. Adding a bunch of extra background bookkeeping to allow an idle loop (or worse yet, a Timer control on a VB form to simulate an idle loop) just piles on junk you don't need.

I can't stress enough that the ability to just slap on another button to make a simple demo loop in the same app, without having to convolute a class with extra variables or make another project just to see something new, really kept my productivity up.

Polymorphism and derived classes are nice (and necessary in some cases), but don't overdo it

Those of you who have worked enough with C++ to get into polymorphism very likely saw the holy light when you realized the kinds of things that could be done with it. If you were taught about the subject, you might have been given a simple example like a base class named CDog with a virtual function named Bark(), and two classes derived from CDog named CStBernard and CChihuahua. The CStBernard::Bark() routine printed "WOOF!" and the CChihuahua::Bark() routine printed "Yip!". It illustrates polymorphism's capacity, but can be misleading when it comes to when to use it and when not to.

Some time ago, I was experimenting with AI game behaviors and was trying to figure out a way to structure them more intuitively. I attempted to created a CBehavior class with virtual functions and derived other behavior classes from it. Then I could just assign a pointer to a variable made with those behavior classes to game objects, and viola, they took on that behavior. But it became a debugging nightmare. When a problem arose, I had to open so many source files to find the problem that I slapped myself when I finally found it (I couldn't figure out why a sound stopped when the object got a certain distance away from the viewpoint. It turns out in a previous experimentation, I had actually coded to behavior to stop the sound when it got close just to see if it would work, and I didn't change it back before taking a long break).

I also wrote a template linked list class with deleted node functionality. I derived other list classes from that, and in the derived class's EmptyList() routines and DeleteNode() routines, I would perform special operations on the nodes if need be before passing control on to the CLinkedList::EmptyList() and CLinkedList::DeleteNode() routines. This worked quite well, since some nodes had allocated data assigned to them that I wanted to get rid of before moving the node to the deleted list. This is a good use of derived classes (it's not polymorphism, since no virtual functions are involved).

The example with the game behavior above would probably have been better serviced with a switch() statement with a behavior type variable rather than separating all possible behaviors into their own class. The number of class names it would have added to the project list would have been another headache. The linked list functionality, however, couldn't be handled with a switch statement unless I was willing to add another variable to the CLinkedList class. The way I handled it with derived classes, however, makes the class behave in a much more transparent way and keeps me from having to do extra coding (setting the switch-required listType variable and what-not). It also makes sure that construction and destruction is handled properly and automatically.

My Render class is a mostly virtual function class that I can point to either an OpenGL object or a DirectX object. Using only the Render class's functions, I get identical results in each API and hide the guts of working with the API's from the game coders.

OpenGL/DirectX pitfalls

• wglGetProcAddress() will NOT return anything if OpenGL isn't initialized!
• Visual Basic 6 sadly has no inherent GL extension support (you can't directly retrieve a procedure address and call it using that pointer). You have to trick the compiled code and rewrite a class's vTable in order to call the routines. Doing so, however, prevents some state values from being returned (such as glCheckFramebufferStatusEXT, which for me always returned 0 using this method). Look here to see what I'm talking about, very useful chunk of code. Visual Basic 2005 can make use of the 'Tao' toolset to access OpenGL's extensions.
• If you disable depth testing, polygons will always render, but don't write depth data! Make sure you know this. If you want polygons to always be written and with their depth data, change DepthFunc to GL_ALWAYS rather than disable depth testing.
• OpenGL sets clip planes in world space, DirectX sets clip planes in eye space!
• For some very strange reason, if I wanted to set up a pseudo-ortho projection so I could render text in a 1:1 pixel ratio (rendering from a 256x256 texture with the font in it), I would use the scale (1/256,1/256,1) in GL's texture matrix, but had to use (1/255,1/255,1) in DirectX to get an identical result.
• When you are testing that a model is rendered correctly, make sure you know exactly how it is supposed to look. I was developing on my graphics engine for a while before I realized the cubes were actually being rendered backwards. Had I set up an irregular shape, I would have noticed immediately.