CEL Devel - main

CEL Devel

Projects:
MacFrac
Moog and Blith

Contact:
Chris
Ed
Leo

Links:
Slashdot
Freshmeat
NeHe OpenGL
POV-Ray

CEL Devel

Here are some screenshots of the more signifcant stages of Moog and Blith development

Version 0.01:
The entity class is created, and my favorite model, GLman is used as graphical representation

Version 0.05:
I decided on using skeletal animation, and break GLman into his separate limbs. The bone class and the and the .cod file type are created. Basic mechanics is added.

Version 0.11:
Animation begins. Framedef.cfd is created with a handfull of animations. The console begins to evolve.

Version 0.12:
Multible entities are used. The .cod file format is changed to hold not positions, but bounding box specifications. Collision detection between the cylindrical bounding boxes of bones is established.

Version 0.13:
The OpenGL window creation is replaced with a better version. Fullscreen support is added. Also, the characters are given depth.

Version 0.15:
The code is sent to Leo for "de-big-ball-of-mud-ification", in other words, I no longer have function bodies in headers and other such heinous coding practices. The program does not change at all, but the code is much more organized.

Version 0.17:
Blocking is added. Also, the camera now tracks the players to keep them both on screen.

Version 0.18:
The game gets a true third dimension with the new stepin and stepout abilities. Camera work is finished.

Version 0.19:
Collision detection between gross entites is created. I unfortunately chose to implement this with a variation of Coulomb's law (kqq/r^2) to make them repel.

Version 0.22:
The cimg class is created to load bitmaps from a file. Since I had no texturing program, the textures were applied by hand, a very painful and time-consuming process.

Version 0.23:
Text is added. Also, blending is added. A texture can now be specified by a 24-bit (RGB) bitmap combined with an 8-bit (A) image for RGBA. Unfortunately, the GL_DEPTH_TEST takes the wind out of the fun, making drawing order more important than translucency.

Version 0.24:
The HUD (Heads Up Display) is created. A new entity, the arena is added.

Version 0.25:
Fireballs! Projectiles are added. The arena is changed again (there was a version I made a while back, which I don't have anymore), to a room. Can anyone recongnize the game I stole the desert backdrop from?

Versions 0.26-0.27:
In one of my most productive all-night coding sessions, a LOT of the program is transformed. The first step was reading POV-ray (www.povray.org) files. These files are special because I can convert my Lightwave 3D (www.newtek.com) objects to this format. I wrote a program, pov2c3d which converts .pov to .c3d. To do this, I needed to also rewrite the .c3d file format. Also, while reading the .pov format, I realized how to smoothing. Once all of my lightwave models were converted to .c3d, I had to apply textures. This required another new program, my c3d texture applicator. If you ever use this, it will become apparent that it was created in only a few hours. Also, the file config.cfg is parsed at startup, as well as command-line parameters. As is typical of huge changes like this, There is no working version from this time, and therefore, no screenshots.

Version 0.28:
Console output is added, and the key struct is rewritten so that any key can be bound to any console command.

Version 0.29:
The mbmenu class is created. The main menu, as well as the pause menu are created. I also fall in love with the underscore. Also, the main idle and display functions are replaced with function pointers. Now, each gametype (mainmenu, playerselect, etc) has an init function that changes these function pointers and initializes the variables needed.

Version 0.30:
The player select screen is born, after many fun IPFs (when a program tries to use protected memory). Also, the loading function is added to provide smooth(er) transitions between menus.

Version 0.31:
The player select screen is enhanced. The loading function is now also given a new parameter for the destructor, enabling continued display even with complex displays.