Here's some of the stuff I've done or am working on - Victor Dods - last updated 2012.04.30.

XRB 2D game engine 2004-present The original "sdl_test" program, displaying a skull-and-crossbones spinning around the screen. The strange visual echoes were actually a cool-looking bug in the rendering code (this was before I switched everything to OpenGL). From after "sdl_test" became XRB. Still with software rendering, a screenshot demonstrating some of the GUI layout capabilities and the transparency. In the background is a WorldViewWidget, which is what renders the game world. Here is probably the nicest-looking screenshot made of the map editor, showing the physical parameters of Entity objects being modified (the green arrows are the linear velocities of each object). The grid was adaptive and faded out as the view zoomed out, to reveal the next larger scale grid. Similarly for zooming in. I was quite proud of how well the user interface worked - moving/rotation/ scaling/selection/etc actions were performed using the mouse, mouse buttons and shift/alt/ctrl keys. Creating and editing objects was very quick and easy. Editing polygonal object vertices in the map editor. XRB (which stands for 'XuqRijBuh', a random name I made up a long time ago for a video game which has the advantage of not being used anywhere else by anyone) is a sprite-based 2d game engine I have been working on intermittently since 2004. It is free open source software, released under the GPL license. What started out as a scratch program called "sdl_test" to test out and learn SDL turned into a full-fledged game engine. Originally it used the SDL framebuffer and did all rasterization in software. The rendering code was fun to develop, but no modern game does graphics in software, so soon OpenGL supplanted the software rendering code. I created a pretty detailed map editor to fill what I saw would be a large need for map creation. Sprite and polygonal object creation was finely controllable, with velocities, angular velocities and so forth. As XRB developed, the boring test application turned into Disasteroids, a game which I would describe as a super-violent asteroids on crack. Disasteroids used only dynamic game world generation, so the map editor lay unused for a long time, and became more outdated as I grew lazy and didn't bother maintaining it. Eventually I met someone who gave me the idea of using SVG files for the game maps. Using (a subset of) this standard format allows any vector-based graphics editor (such as Inkscape to be used as a map editor. While there will be less game-specific integration in such a graphics editor, the lack of a need for maintainence is appealing. Inkscape's XML editor mode allows the user to add attributes and elements to map sprites to provide game-specific information about each object. I later added support for polygonal objects, for which vertex editing was necessary. This was a much more difficult interface to create, and while never fully completed before its timely demise, it was also quick and easy to use. I hadn't got around to adding the capability to edit texture UV coordinates. I would really have liked to have had the time to maintain the map editor in parallel with the engine as it evolved. As it stood though, I hadn't created any application which actually required the map editor (such as a platformer game with lots of levels). I'm hoping that because SVG files can be made by many common illustration programs (e.g. Adobe Illustrator, Inkscape, etc), it will be easier for artists to create assets for XRB games. Disasteroids was originally designed to be an example app to test and demonstrate XRB. It inevitably grew into a full-fledged game, and while not finished, could be considered a feature-complete arcade game. There are 5 types of enemies, each coming in 4 different levels, indicated by their colors and sizes. There are shields, armor, engines and 7 different weapons (also each coming in 4 different levels). There is a tractor beam "weapon" which facilitates collection of the minerals necessary to buy and upgrade items. The tractor beam operates in 3 modes: the green mode sucks up only goodies (minerals and health powerups), the blue mode sucks up everything (Devourment and Demi, the two large enemy types, each use this mode), and the red mode pushes everything away (useful for deflecting attacks, also used by Demi). I made the ship artwork in Inkscape, and am sort of proud of it. Most of the other artwork in the game is more or less engineer placeholder art, and needs to be done for real. I originally made sketches of each of the ships while bored in a meeting at work. I sketched a lot of ideas for a platformer game I'm planning for the unspecified future as well, but that's another story. The visual style for Devourment and the enemy level palette-variation were inspired by the SEGA games Fantasy Zone and Phantasy Star respectively. Interlopers ram the player to cause collision damage. They flock together and swarm the player in massive numbers. Shades mimic the velocity of the player to "float" nearby and fire slow-moving bullets. They can teleport away when threatened. Revulsions attack with Gauss guns when the player's back is turned, but will flee when looked at directly. Devourments want only to consume. While not directly aggressive to the player, they will pursue and suck up anything that nears their grinder maws, including other enemies. Their normal diet consists of asteroids. When killed, potentially many minerals (and health powerups) are released, making the difficult investment of destroying a Devourment worth it. Demi is the boss enemy. Equipped with many weapons and tractor beams, they vary their attacks and continually harass the player (for example if the player attempts to flee, a Demi will either charge the player or use its powerful tractor beam to fling the player back into the line of fire). Here's our hero, "Solitary". This term comes from my friend Chris Messineo who described the awesomeness of the idea that in a shoot-em-up-style game, a small, solitary ship takes on overwhelming swarms of enemies and emerges in triumph. (Though to give fair warning, in Disasteroids, the waves keep coming and the game continues until the player dies in glorious battle!) Here are some in-game screenshots. Unfortunately the hectic action is not captured properly in still shots (mental note: motion-blurred screenshots). Left: Swarms of Interlopers rush from offscreen in each wave. Right: Devourments will eat anything, including other enemies. Left: A Demi (the boss enemy) spraying flames. Right: Zooming out in debug mode shows the game world tiling. Left: The player attacks a 2nd level Demi with grenades. Right: Exploding bosses spawn goodies and baddies. Left: The EMP shockwave weapon disables enemies within its blast radius. Right: Mid-game carnage. XRB uses SDL and OpenGL ES for maximum platform compatibility (the Linux, Mac OS X, Windows and iPhone platforms have working builds). There is a (nearly) complete GUI system (modeled loosely after QT) including a decent font engine. The fonts are generated at runtime using the FreeType library, and then cached for later loading. This allows builds without linking the FreeType library to use previously cached font data. Much effort went into creating an easy-to-use widget layout system, so that widgets are positioned and sized automatically, without much user interference. Any screen size is easily handled, with font sizes being based on the screen height. Thus the game takes on the same proportions (widget proportions, font proportions, etc) for any proportional resolutions. Libpng is used for image loading/saving. The rendering system is simple yet robust, allowing for color masking and biasing through the GUI widget hierarchy and game world view. Transparent objects are supported and ordered so as to be rendered correctly. There is a set of abstract classes in the Engine2 namespace which provide a framework on which to build game-specific code. These classes include [game] World class (which controls the game world), the PhysicsHandler class (which is an interface that World uses to run the game physics), the Entity class (for animate objects), etc. Currently (2010.06.02) there is no sound. This is something I hope to remedy soon, since XRB has gone silent long enough. I have written some lesson applications, annotated with Doxygen comments, to incrementally teach usage of the XRB library. Ben Nichols and I have ported XRB to the iPhone/iPod Touch platform for future game development. Porting to this platform involved abstracting the use of all libraries to the "PAL" interface (Platform Abstraction Layer). This includes image and font loading, image saving, timing mechanisms, setting video modes, etc. SDL, libpng and FreeType - the libraries of choice for the desktop platforms - were hidden behind this interface. A minimal iPhone PAL was created to use what was provided by the iPhone APIs, as well as to avoid unnecessary library dependency - the use of SDL, libpng and FreeType was avoided. The other main difficulty in the iPhone port was to "downgrade" the use of OpenGL to OpenGL ES. It wasn't so much a downgrade, as no functionality was lost (XRB doesn't need much in the way of OpenGL, and doesn't really do anything too fancy). While everything worked without too much trouble, the original performance was terrible. Certain techniques were needed to cut down render time. Texture atlases (a technique of packing multiple sprites into one OpenGL texture to cut down on the overhead of switching textures) were implemented. This was difficult to do while preserving all the mipmap functionality XRB had grown used to. I came up with a fancy way to pack different sized textures in a careful way so their mipmaps wouldn't overlap. Actual empirical data on the packing efficiency is still needed however. Another optimization was to do as much matrix math as possible in software. This provided a speedup, since full 4x4 matrices are not necessary in a 2d game world. These optimizations, along with a few others, rendered a decent speedup. Additionally, I added a screen- rotation feature, so that rendering could be done at any angle (any multiple of 90 degrees), i.e. on an iPhone when it flips to the side. The iPhone platform code is private and is not included in the Sourceforge repository, but it's really not hard to implement your own iPhone PAL. Here is an ASCII-art quine I wrote to use as a logo for "XRB GAMES" which is the quasi-real studio name I'm going to slap on the games I produce with XRB. xrb_games_quine.c Source code (also available on Sourceforge via svn): XXX BARF compiler tools 2006-present BARF is a suite of compiler tools I have been working on intermittently since 2006. It is free open source software, released under the GPL license. It started out as "trison", a replacement to GNU's "bison" LALR(1) parser generator. I found the code generated by bison (and flex) to be abhorrent, and therefore was highly motivated to write my own compiler-compiler. The first version of trison used a source file almost identical to that used by bison, but produced only C++ parsers. The C++ framework code was semi-hardcoded and run through a preprocessor to generate each custom parser. My friend Dan Palm was responsible for the name BARF, suggesting it originally as "Bison's Awesome Replacement Framework", which I modified to "Bison Awesomely Replaced, Flex" (i.e. Flex/Bison Awesomely Replaced) after adding "reflex", a lexical scanner generator. Reflex brought a redesign of the preprocessor system, such that arbitrary target languages could be supported (though only C++ was targeted at the time) via a "targetspec" and (possibly multiple) "codespec" files. The targetspec describes what directives are available to reflex to customize the generated scanner code, and the codespec is a preprocessor file containing the framework code. This design essentially turned reflex into a fancy preprocessor - all it does is generate a DFA and then munge the appropriate targetspec and codespec files in the manner of a preprocessor, macros and everything, to output the desired scanner code. Trison was eventually adapted to this design as well, which allowed a significant amount of code to be shared between the two programs. The original trison supported only LALR(1) grammars, but the revamp allowed LALR(k) via NPDAs and eventually DPDAs (though the DPDA-generating algorithm, while functional, is aesthetically displeasing and somewhat incomplete). Currently only C++ targets have been written, but the textfile-based model allows for additional target languages to be added without having to recompile the tools. Support for a Python target is not yet possible due to Python's indentation-based scoping, though I do want to add such support because Python is neat. Source code (also available on Sourceforge via svn): barf-0.9.20101002.tar.bz2 barf-0.9.20100116.tar.bz2 LiViD C++ utility code library 2006-present LiViD (LIbrary of VIctor Dods, acronymed to LVD) is a small library of C++ utility code, making heavy use of C++ templates, geared toward being able to plop its source code (or a subset thereof) into a project and go immediately, without annoying build logistics. It is among the most groomed and well-tested code I've written. Prominently featured in the library is a very robust test framework which runs each test in a spawned child process. This is so that the parent process can detect signals sent by the child (segmentation faults, assertion failures, etc). This makes the test framework able to handle any type of fault. While portability is the goal here (since the library is very general C++ utility code), I haven't yet attempted a WIN32 compile. Mainly because I utterly detest the entire Windows development experience. So for now, we'll just say it's targeted for Unix. I created this library mainly because every time I made a new project, there were certain source code files I copied verbatim from my old projects (notably the commandline parser class). LVD is an attempt to provide drop-in utility source code. The current features (as of 2006.06.02) are (* indicates what I've found the most useful): Template metaprogramming classes (such as static assert, if-statements, integer types, integer log, integer pow, classes for binary integer literals) A callstack-printing facility (though only if the "addr2line" binary is available, i.e. Unix) * A commandline option parser (very automated, handles short and long options, and prints its own nicely-formatted help message) A class wrapper for making bitflags more strongly typed A class wrapper for making enums more specifiable and strongly typed * A templatized matrix class * A templatized vector class (which works with the matrix class) A templatized, strongly typed printf function (though this will likely be dumped because it generates massive code) A child process spawning utility (used by the test framework) * A test framework (as described above), which is used to test LVD itself Some UTF8 utility functions A simplified XML parser (this uses BARF to generate its scanner and parser classes) Emphasis is on simplicity, tidiness and the lack of a massive dependency tree. LVD is free open source software released under the GPL. The version numbering is as follows. The first number is the major revision (an increment to this number indicates a break in compatibility). The rest of the numbers are the release date for the version. livid-1.20100602.tar.bz2 Note that if you modify lvd_xml_parser.trison or lvd_xml_scanner.trison, you'll need trison or reflex (found in BARF), respectively, to re-generate the parser or scanner C++ source files. I would not recommend modifying the parser or scanner C++ source files, since they're generated by BARF, and you'll lose your changes if you ever re-BARF the trison or reflex sources. Einstein's Eye ray-tracing-on-manifolds program 2008-present Einstein's Eye (EE) does ray tracing on manifolds (i.e. curved spaces). Ordinary ray tracing simulates optics for generating images of model-based geometry in the following way. Given a point of view (the eye) and direction of view, one generates a pixelated image by "tracing" a ray out from the eye through each pixel on the screen (imagine the pixels form a rectangle in front of the eye). The computer determines the first thing hit by the light ray, and records its color to the pixel. Doing this for all pixels on the screen generates the image. This is a simplified description of the algorithm - to generate photo-realistic images is much more complex. This is ray tracing in "flat space" (where light travels in straight lines). But say we live inside a curved space (the appropriate mathematical object is a Riemannian manifold). Einstein mathematically proved that gravity curves space. Ostensibly, light must travel paths which stay within the universe, so must follow the curvature of space. Due to minimizing properties of the trajectories of light, it must follow what are called "geodesics" - geodesics can be thought of as the "straightest lines possible" in the curved space. The exact formulation of geodesics is (can be) done in the language of the calculus of variations. The approach is the same - follow the light rays until they hit something, then record the color. The details of doing so are more involved, due to the loss of the vector space structure one relies upon in traditional ray tracing. Rather than using a simple parametric equation for a line, one must now solve the geodesic equations (a second-order system of ODEs). Left: This is a gravity well (a non-physically-accurate depiction of a black hole) in front of a picture frame (I need to create some room models so there is more context for what's going on in this picture). The concentric rings are multiple (distorted) images of the picture frame, resulting from the light rays looping around the gravity well a number of times before hitting the picture frame, the closer they pass to the center of the well. Right: For reference, here is the original image for the "picture frame" in the gravity well image. There are certain other technical issues such as representing model geometry within a manifold, and more importantly, moving said model geometry around the manifold (which may be irregularly curved) in a physically meaningful way. The visualization is straightforward, and even doing rudimentary lighting is relatively easy. The model geometry and animation is the real challenge. I am currently learning elastic and continuum mechanics in order to have a mathematical foundation for solving these problems. Undoubtedly the equations (PDEs, most likely) governing motion of an elastic body in a general manifold (think some arbitrary blob surface) are intractibly difficult to solve. Special cases such as homogeneous and/or isotropic manifolds may render tractable solutions. Homogeneous and isotropic manifolds should allow for rigid-body mechanics. Here, the universe is a flat 3-torus (i.e. space is a cube which wraps on itself like Pacman). No lighting is done in this rendering; the shading is due to a fog effect applied for objects seen at a distance. There is only a single globe in the manifold. The torus wraps back on itself which creates the infinite grid of seen globes. In terms of the EE program, numerical methods for approximating solutions to PDEs should be able to handle the general solutions (arbitrary manifolds). Certain special manifolds (spheres, tori, etc) should render closed forms for geodesics which will really speed up visualization. Making use of the GPU for numerically solving the geodesic equations - a highly parallel operation - will also give a critical speed-up. The more subtle methods of ray tracing (use of the rendering equation, distance blur, reflections, etc) are planned, though these will be a challenge due to a general manifold's lack of a vector space structure. Embedding objects and modeling physics in Riemannian manifolds is the subject of my research as a Math Ph.D. student at UCSC. Left: This image is again a flat 3-torus, only there is a floor and ceiling added, blocking the sight of the up-and-down repetition. The scene models are more interesting (a lamp and a table), and a light source has been added to the lamp. The lighting operates via caustics, which is the only method which makes sense in the general case. A manifold with additional structure (e.g. a space of constant-curvature) could yield easier lighting calculations. Right: Here is a similar scene, slightly rearranged, a globe added to the table. Only now there is no tiling of space, but instead a gravity well has been added to the manifold. Notice how the right edge of the table appears to curve downward, making the underside visible. No physical distortion is happening, it's all a result of the optical lensing effect due to the curvature of space. The irregularities in the lighting are due to a temporary hack/approximation in the caustic algorithm. HACKSAW TO THE THROAT progressive/syncopated/melodic death/thrash/grind 2002-2008 Look and listen. The second link is MP3s of our two full-length CDs. nothing substantial enough for a journal Visualization Of The Effects Of Curved Space 2003 A paper written for my senior seminar project at UCSC. The program implementation (whose source code was lost in a hard drive failure) was the predecessor to Einstein's Eye (an infinitely better program). visualization_of_the_effects_of_curved_space.pdf Rigid Body Collisions 2004-2005 Deriving the math behind rigid-body collision response (impulse-based change of velocities). I did this before grad school, and my skill in linear algebra and mathematical writing has drastically improved since then. I may rewrite this paper at some point with my newly gained powers of mechanics. rigid_body_collision.pdf Understanding Real Derivatives Of Complex-Valued Maps 2010 After slogging through countless tangent map calculations (i.e. multivariable derivatives in the vector calculus sense) involving maps that were inherently defined in terms of complex variables, I came up with a slightly more efficient means of computation. While I'm sure it's by no means original mathematics (it's straightforward enough that an undergrad with a solid linear algebra, vector calculus and complex analysis background could provide proofs for the results presented here), I have not seen it in any book or article. I presented this material at a differential geometry seminar at UCSC, Spring quarter 2010, held by Wyatt Howard, Corey Shanbrom and me. I presented it for the graduate colloquium series at UCSC during Fall quarter 2010, and then again for the undergraduate colloquium series at UCSC during Winter quarter 2011. derivatives_of_complex_maps.pdf Tensor Heaven 2012 The use of tensor objects (in the form of tensor fields) is ubitquitous in differential geometry (e.g. curvature tensors, general relativity, continuum mechanics), and therefore expertise in their use is critical. Over probably a two-year period starting in 2010, I began working with tensors and tensor fields in a way which uses the notion of "strongy typed" language (borrowed from computer science) to formulate a robust technique for doing tensor calculations. In it, the "type" of an object is used to explicitly express which constructions and operations are allowed, using only the natural pairing on a vector space or vector bundle. Errors resulting from inherent misusage of the objects are readily detected. Furthermore, the meaning of objects or means of their usage can often be inferred from their type. This exposition is an introduction to the linear-algebraic formulation. There will be more to come, specifically targeted at tensor calculus, in which the notion of a "pullback bundle" further enriches the type system used within. I presented this material at the Graduate Colloquium Series at UCSC, Spring quarter 2012. 20120405-tensor-heaven.pdf Medal Of Honor: Pacific Assault 2003-2005 TKO Software (now defunct) was contracted by Electronic Arts to implement the multiplayer mode of Medal of Honor: Pacific Assault (MOHPA - or as we sometimes called it, PacAss). The MOH engine at that point had a long pedigree consisting of Quake 3 Arena, Heavy Metal FAKK 2, MOH Allied Assault, and MOH Breakthrough (there might be another in there I'm forgetting). Pure C code up though MOHBT, the MOHPA engine brought skin-grafts of C++ and by that point was getting to be a heaping monstrosity. Much of the emphasis of MOHPA was on the looks of the game (and it did look great) - a persistent mouse-lag problem was symptomatic of this. The multiplayer game development started off with a prototype of the "invader" gametype (similar to the "assault" gametype in Unreal Tournament 2004) in the MOHBT engine. The MOHBT engine was efficient and responsive, the maps cannibalized for prototyping were compact and hectic, and the development experience at that point was a lot of playtesting and game tuning fun. In particular, I had created a map script to control a massive blast door on the front of a tunnel, which made for some very fun (and hilarious) gameplay. Players could push on either side of it, with more players equating to more force. Jeff Zaring (a designer at TKO) added "murder holes" to the blast door for extra carnage. The tunnel/door map was a prototype for what eventually became the Corregidor map, though the blast door game element was not included. In general, the tuned gameplay mechanics we developed during prototyping the invader gametype were not used in the final game. The objectives became generic "blow this wall up", "activate this radio", "destroy this thingy" missions, spread out over gigantic maps, which left players running to catch up most of the time. The close-quarters prototype maps were much more fun. While the gameplay wasn't special, the game looked great. And that's obviously all that really matters. Results of one of the playtest games held during the month-long deathmarch at EA's LA headquarters (EALA). A lot of the playtesters involved in MOHPA were based in EA's Redwood Shores office (EARS). I did a significant portion of the multiplayer map scripting (the MOH scripting language has some really cool features such as multi-threading, but is terribly finnicky in practice), worked on some of the engine network code, worked on getting the (existing) ragdoll physics working in multiplayer (a monumental pain in the ass) and probably most prominently, designed and implemented the multiplayer scoreboard (see right). There was a persistent and hilarious bug in the ragdoll physics where when you'd kill another player, he would end up standing up (at first it was in the animator's "jesus pose", then later in the "i'm aiming my gun" pose). This phenomenon was termed "VERTICORPSE". Eventually, in playtesting, we started ignoring players that were standing still, assuming they were verticorpses. Eventually, we learned to stand still to mimic a verticorpse and therefore be ignored. Eventually, we learned to shoot everyone, no matter how verticorpsey they looked. My favorite part of the final product multiplayer game was the simple pleasure of stabbing people in the face with the bayonet. Toward the end of the project, for what ended up being the entire month of October 2004, the whole MOHPA team at TKO Software (based in Santa Cruz) was shipped down to EA's Los Angeles headquarters so we could work 12-14 hour days under the watchful eye of the EA execs. This was completely uncalled for, as there was nothing we could do in LA that we couldn't do in Santa Cruz. Furthermore, it torpedoed morale even more than normal crunch mode, as we were all away from our homes/families/friends, put up in some sterile corporate hotel-housing not too far from the office. There were many loopy late nights, as my friend Nate Lieby can attest to. So loopy, in fact, that we were considered disruptive, and separated so as not to cause any more circle-running, penny-snapping, hippopotamus-hippopotamus, old-man-double-voice ruckus. Fortunately, Stu Fullmer and I continued the loopy times from our new desks, surrounded by EA engineers who I'm sure were delighted by our presence. PUDL2 Compiler for a UI-control scripting language 2006 PUDL2 (Producer's Unified Description Language) was (is?*) a scriptable control system for the UI flow in the MCL (Media Control Library - Lightsurf's Picturemail library for Sprint phones). The original PUDL was controlled by scripts which looked not unlike assembler code, and was very hard to read, write and maintain. The second coming of PUDL (hence the 2) turned the control language into a full fledged C-syntax scripting language. Of course, this required writing a compiler, a task with which I was (gladly) charged - I like language theory and compilers (see BARF). The Great And Venerable Ward Willats wrote the bytecode runtime (the thing which ended up running the compiled bytecode in the MCL itself) and did most of the language design. I contributed a little bit to the language design, for example 'switch' statement blocks defaulting to 'break', and requiring the 'continue' keyword to fall through as in C. The compiler took about a month to design and code. The GNU tools bison and flex were used to generate the parser and scanner code respectively. Integrating the code that these tools produced into a reentrant C++ program sucked total shit. The generated code is overflowing with preprocessor macros and is hard to read. Besides that annoyance, the PUDL2 compiler development went really smoothly. Later in the MCL's development, coworkers would come to me claiming they had found a bug in the compiler. Invariably it would turn out to be a bug in the MCL itself (ha ha!), which was great because it meant I had done some solid work. On the other hand, it meant that I had to reason to have fun working on the compiler again. </vanity> The crappy experience using bison and flex for parser/scanner development directly inspired the first version of trison, which led to the BARF project. * I'm not sure (though I doubt) if the MCL is still in active production. Morph GUI-controlled image morphing program 2002 Done for Professor Alex Pang's CMPS 161 (computer graphics) at UCSC during Winter quarter of 2002, it used a clever and simple linear interpolation method to morph between two images with source/destination feature data supplied by the user. There was a GUI (written in FLTK, the GUI toolkit of choice for the class) which allowed the user to specify pairs of oriented line segments on the source and destination images. The source image data in a weighted neighborhood of each line segment would be interpolated with the weighted neighborhood of the corresponding line segment in the destination image data. The source code for this, as well as much of my other source code at the time, was lost in a hard drive failure in 2003 (boo, IBM deskstar harddrives). The original webpage made for the CMPS 161 assignment (on the right in the source and destination pictures is Mike Graben, a friend of mine who lost 100 pounds on the Atkins diet - I would have made this particular morph more detailed, but drawing the line segment pairs was a pain in the ass). Addendum to the Atkins Diet results Radiosity progressive radiosity lighting for 3D scenes 2002 Done for Professor Alex Pang's CMPS 260 (computer graphics) at UCSC during Spring quarter 2002, it modeled soft shadows and lighting in 3d scenes by determining light contributions from all visible sources (light sources and surfaces reflecting light), as opposed to the harsh point-light method of ray tracing. It consisted of two passes: 1. form a matrix of light contribution ratios between all pairs of surfaces in the scene, 2. numerically approximate a steady-state solution for a system of ODEs formed from the matrix in the first part. With a little OpenGL fanciness, part 1 could be done in hardware by rendering the scene from the perspective of each surface, recording the ratio of pixels visible from each other surface. I just did it in software, so it was slow, but it would be something cool to try again one day. The source code for this, as well as much of my other source code at the time, was lost in a hard drive failure in 2003 (boo, IBM deskstar harddrives). Here are some images produced by the program (all the scene geometry was generated programmatically - I should have bothered to get some nice models for this). Left: One of the earlier images, with a low triangle-count and using only flat shading. Right: The light is pure white and the colors are coming from the reflections of the colored balls. Left: Another view of the previous scene. Right: A single diamond-shaped surface emitting light (facing away) within a room with no ceiling, showing the reflection of light to areas of the room behind the diamond-shaped light. Left: A pentagram casting two shadows from the red and yellow colored lights below. Right: A grid of white spheres over a white floor showing the interplay of the colored lights above. Left and right: Two more views of the previous scene. Uthelleaux Othello game clone done in QT 2 2002 Uthelleaux is an Othello game implemented in Trolltech's QT toolkit version 2 (QT is by far the best GUI toolkit I've used. The QT development tools are top notch, the library is solid, and the documentation is abundant). There are several levels of AI (implemented using an minimax DFS algorithm (with alpha-beta pruning, if I recall correctly), which gives pretty decent performance and difficulty (though definitely beatable). Uthelleax 1.0 was written in MFC (for WIN32) and therefore sucked. Plus it didn't have very difficult AI players. I'm not sure if I even care if I have the source code. There is light-green highlighting to indicate valid moves, and holding the right mouse button on a square will give a preview of the result of that move. Since QT 2 is outdated, I haven't been able to compile Uthelleaux in several years. It would be nice to someday port it to QT 4. Left: Beginning of the game. Right: Menu for player type and/or AI difficulty. Left: The legal play squares are highlighted. Right: Game-over statistics. Uthelleaux is free open source software, released under the GNU GPL license. Source code: uthelleaux-2.0.tar.bz2 Antichess chess-based game in QT 2 and for web CGI 2002 A screenshot of the QT version of Antichess, showing the selected piece (black king) and all the pieces it threatens (the white queen). The visual style was predicated on XBoard. Antichess was a game taught to me by my friend Danny Greenhouse. An absurd variant of chess, the object is to be the first one to lose all your pieces. The key rule is that if a player can take a piece, they must. If they can take more than one piece, they get the choice. There are no other rules, except that the king is not special. I took two approaches to this game: a web CGI version (which is clunky by today's web 2.0 standards), and a GUI app (done in QT 2, just like Uthelleaux). The web version can be found here, though is having problems with processing the commandline arguments it needs to run (but hey, the executable is literally 8 years old - it's amazing it still runs at all). Each player must click on a piece to select it, then click on a square to move it. The only thing I would have liked to have added is a little yellow box around a selected piece. This web CGI version of Antichess looks good, but is very primitive from a web development perspective. In a way, it was an exercise to learn web CGI. The QT version was similar to Uthelleaux in design and style. It included a computer player (not terribly difficult), and displayed the available moves and captures for the selected piece. Like Uthelleaux, it uses a deprecated version of QT, so I haven't been able to run it in a while. I'm thinking if I get terribly bored some day, I'll port it and Uthelleaux to QT 4, so they can live once again. Antichess is free open source software, released under the GNU GPL license. Source code: antichess-0.9.2.tar.bz2 Quake 3 Arena maps 2003 After first playing Q3A in 2000, I had joined the clan "Dynasty" in 2002 using the handle "Humiliation", which was what the game announcer said when a player was killed with the melee gauntlet weapon. Dynasty started out as an instagib deathmatch clan (instagib is a railgun-only, one-shot-one-kill game mode), but soon got into instagib capture-the-flag (ICTF). Eventually I tried my hand at designing some Q3A maps, mainly for ICTF, some of them actually being pretty fun team play maps. One of the maps, dynasty-ctf4, was designed by James Majidian ("Impulse"). Left: "King Of The Mountain" (dynasty-ctf1) was simple and blocky, and a little too open for real instagib CTF matches, but made for some good rocket/trick jumping. Right: "Into The Fucking Pit!" (dynasty-ctf2) was another blocky-design map with many pillars jutting out from a large pit in the center. Players could try to strafe jump over the pillars, or run some carefully guided lines along the sides. The windows in front of each flag would open when shot. The main design feature of these maps was the use of slick (as in ice) Bezier patches (curved surfaces). These were used in portions of certain maps to give a skating dynamic to the maps. Two of the maps resembled skate parks. Left: "Blood Bowl" (dynasty-ctf3) was probably the best-looking and best-playing of the maps. There was an "underground" area below the glass bowl players could try to run through and lose pursuers. Carefully done teamwork could allow players to grab the flag, jump in the bowl and have their teammates boost them down into the bowl, shooting them out to the safety of their home base. Uncareful players would jump in the bowl, become stuck and get popped by the diligent efforts of the railgun-toting defenders. This is the best example of the simple aesthetic design maps I made, where the only structural texture used was concrete, and everything else was done with lighting. Right: "It's All In The Gravity" (dynasty-ctf5) was the giant skate park map. On the hardware of the era (e.g. a 1.4 Ghz machine), this map ran a little slow, and was a little too big and open to be an effective map for competitive play, but was still fun especially for rocket jumping. Left: "Altar Of Sacrifice" (dynasty-ctf6) was the most structurally detailed of the maps, and was more like a traditional Q3A map than the others. Because of its high level of detail, it ran a little slow in some areas (like the main altar room), but this didn't seem to hinder the intense gameplay. Right: "Skate... Or DIE!!!" (dynasty-ctf7) was essentially a half-pipe with a few boosters providing some vertical to the dynamic. Glass barriers in front of the flags, over which players would have to jump to get to the safety of capture provided many tense moments. The overall design aesthetic was simple/minimalistic, making heavy use of colored lights in place of geometric detail. Another element I was sort of proud of was the addition of "iris doors" into dynasty-ctf5, which were visually and kinetically quite pleasing. I never bothered to add weapons or powerups to the maps, since Dynasty was an instagib-only clan. Unfortunately I lost all the map source files in a hard drive crash in 2003, and the q3map "bsp-to-map" conversion is far from perfect. Left: "Sumo Wrestling, Humiliation Style"(dynasty-dm1) used a special configuration file. It was based on sumo wrestling - players try to knock each other back with the gauntlet weapon into the spikes at the edge of the ring. The glass bowl is slick, just like in dynasty-ctf3, and players gain points for staying within the ring, and lose points for getting popped on the spikes. Again, this map was pretty absurd, but super fun. Right: "Newtonian Playground" (dynasty-ctf8) was predicated on q3hockey but was formed into a giant, slick, ellipsoidal arena in which it was possible to be boosted by teammates up and around the curved walls - this map was tiny and a little absurd, but extremely fun. The PK3 files are available here. The dynasty-ctf1 through dynasty-ctf7 and dynasty-dm1 maps are in the first file, dynasty-ctf8 and the others are in the second. Besides dynasty-ctf8, the "beta" pack file maps aren't particularly high quality. dynasty-maps.pk3 dynasty-maps2-beta.pk3 Rage Q3A mod 2005-2007 A logo made for Rage by Clint Dunn ("Toad"). At TKO Software, after finishing MOHPA, Nate Lieby and I did some prototype game development using the Quake 3 engine, designing and implementing a Robotron-2084-style game. This involved a lot of really fun hacking, as game design and prototyping work is always the most enjoyable part of game development. The vanilla Q3 engine uses C and is designed in a very straightforward manner, making it easily modded. Quake 3 Arena (which was effectively ID's demonstration of their then new 3D game engine) operated on two levels - the engine code (which was proprietary at the time, though has since been GPL'ed), and the moddable game code (game logic, weapons, GUI display, console commands, etc). Both were written in C, though the client code was compiled into some sort of platform-independent bytecode by a separate compiler - the same mod files could be used on any of the supported platforms. The moddable source code was freely available and really strengthened the Q3A community by encouraging player participation in the development of the game itself. Two particularly well-done Q3A mods were OSP and Threewave (the Threewave mod came with many high-quality maps), each specifically geared towards tournament play. Rage was a Q3A mod I originally created to test out the technology and improve some of the details of vanilla Q3A I saw as lacking. At first the changes were mainly cosmetic, such as spawning blood/guts (aka gibs) having the same momentum as the player when s/he died (in vanilla Q3A, the gibs would spawn from a fixed point in space, which looked wrong if the player was moving quickly). Later, gameplay features were added, such as different scoring mechanics (see the feature list below under "different deathmatch scoring types"). A few of the more hilarious features added were the ability to scream at the touch of a button (using your character's death scream), the ability to spawn gibs at the touch of a button, and weapon heads (the model for your currently equipped weapon would be used as your head). The "main" feature of Rage ended up being the addition of 6 more teams for multiplayer gametypes (in colors matching that of the colorized console text). To get the deathmatch and team deathmatch modes working was relatively easy. The capture-the-flag (CTF) gametype took considerably more effort, and while functional, was never completed to a fully polished quality. Additionally, the multi-team CTF gametype required customized maps having a base for each participating team. TribalCTF was another Q3A mod made specifically for 3-team CTF, and whose beautifully-done (though polygon-intensive and therefore relatively slow-running) maps could be used in Rage. Left: Setting the cvar cg_weaponheads to 1 enabled weaponheads, where the currently equipped weapon model would be used in place of each player's head. Right: Lots of things were colorized (blood/gibs, teams, railgun trails, quaddamage aura), some of them being configurable. Also the number of gibs spawn when a body was popped was configurable. After a year or so of development hiatus for Rage, talking with fellow Q3A players Brian Vitko ("DeadArcher") and Clint Dunn ("Toad") got interest going again. We decided to team up to develop Rage into a polished mod. While never originally intended to replace one of the major mods, we decided our goal would be to make a fork of the OSP Q3A mod (which had long ceased active development, though was still widely used). I contacted the OSP guys, asking if I could have the (proprietarily-kept) source code to continue its development, merging it with the Rage codebase in the process. While I did get the buy-off from one of the creators, I never heard back from the second guy, so it unfortunately never happened. This effectively stopped development, as bringing Rage to the quality of a full mod would have been too great. Before that happened though, we did manage to augment a few of the standard Q3A CTF maps (and a couple Threewave CTF maps) to use multiple teams (cutting apart the map geometry and pasting it together with a 3 or 4-fold symmetry instead of the usual 2-fold symmetry). Radiant (the map editor used by Q3A) was unfortunately not designed to handle perfect 3-fold symmetry well (one couldn't duplicate parts of the map rotated by 120 degrees without many map leak and visibility headaches). Left: The team deathmatch scoreboard for a 4-team game. I didn't get a chance to make a nice scoreboard before development halted. Right: Showing a capture of two flags at once on the ragectf1 map. ragectf1 was a modified version of q3ctf4 made by Brian Vitko ("DeadArcher"), having bases for 4 CTF teams. Players could pick up and return multiple enemy flags, while the flashing aura around the flag carrier would give additional indicators as to which flags were being carried. The work on Rage was very easy and enjoyable, and I really wish we had the time to bring it to the polished level of an OSP or Threewave (of course, I make the same time-wish about everything I do). I was really hoping that Quake 4 multiplayer would turn out as good as or better than Q3A, but was sadly disappointed. While Raven (the studio contracted by ID to make Q4) clearly made an effort to duplicate the physics and gameplay of Q3A, there was just something lacking. Hopefully Quake 5 will redeem the series :) The feature list included with the mod read as follows: 6 new teams for a total of 8 teams in team game types. 4 times the teams means 4 times the violence (CTF still in initial implementation stages). Customizable number of gibs. Want more gratuitous gore? Crank cg_gibs up to 50 and let the blood rain (while listening to SLAYER, of course). Client-side correction of body-gibbing momentum (gibs preserve the body's momentum). User-selectable coloring of blood and gibs. The colors available are the same as the text colors (starting with 0: black, red, green, yellow, blue, cyan, purple and white). Death-rattle corpses: Instead of blandly sinking into the ground, ungibbed corpses will enter a death rattle and explode, doing radius damage. Kill your friends from beyond the grave with your own corpse. This defaults to off, but is highly configurable. Customizable weapon damage values for all of the standard q3 weapons. Configurable weapon cycle times (time it takes to fire 1 round). Spam your friends with rockets and grenades. Configurable run speed factors per weapon. Cvar-controlled spread factors on the machinegun and shotgun. Controllable number of shotgun pellets. Railgun slugs can hit a cvar-controlled number of people (no longer capped at 4). See if you can get your friends to line up so you can get a 15-fer. Flags retain the momentum of the carrier when they're dropped for more realistic motion. Self-damage is toggleable for your rocket jumping, plasma climbing and grenade hopping pleasure. Drowning damage is toggleable, for your hiding-under-water pleasure. Fake gibbing. Freak out your friends by spewing gibs without dying. Screaming - trick your friends and enemies into thinking you've snuffed it by screaming your falling or death sounds. Gravity now works on everything correctly (players, grenades, etc). Vampire mode - when you damage other players, you gain health, configurable by cvars. Controllable weapon loadout. Controllable starting weapon. Controllable ammo ammounts (including -1 for infinite). CTF flag throwing. Play keep away from your least popular friend. Players now gib upon disconnecting (which includes if they're kicked). Client-side help command. /cg_help Different deathmatch scoring types: 0: standard deathmatch 1: getting killed resets your score (winning streak scoring) 2: getting killed lowers your score by 1 (net kills scoring) Detailed weapon statistics. Annoy your friends with how high your fucking railgun accuracy is. WEAPON HEADS! YAY! Suicides can now be configured to credit the last person who attacked you. Catch-all weapon/health/armor/ammo/powerup/holdable disabling (in addition to the existing, verbose disabling cvars). Teammates/enemies have different spawning/teleporting sounds. Configurable maximum health, start health, equilibrium health, and start armor. Configurable respawn wait time. Weapon dropping when dead can be turned off. DOS graphics programming 1993-1997 I originally got into computer programming because of games - specifically, figuring out how to cheat at games by using a DOS hex editor; changing scores, experience points, and even character dialog. Eventually programming seized me at age 13, starting with QBASIC. Regrettably all my BASIC source code, including the source code to a rather impressive (for a kid) graphical analog clock program I wrote, has been lost to the void of byte-oblivion. The entire screen cleared and repainted once a second to update the clock hands, as I had no idea what a backbuffer was at that point. This was 1993, at the height of BBSes, and right before the web was really known. Eventually my mom bought me a book on Turbo Pascal, saying that it'll eventually help me earn lots of money, which is good seeing as I'll be supporting her some day. I had also got my hands on the first version of the PCGPE, which got me started on VGA video mode coding (320x200 resolution, 256 paletted colors), which relied heavily on assembler programming. "Denthor of Asphyxia"'s tutorials were notably helpful. Between 1994 and 1995, I had begun to create some somewhat decent video demos, including some rudimentary 3D wireframe rendering programs. Pascal was a much richer language than BASIC, especially when coupled with its inline assembler mode. This type of programming is no longer exactly possible in modern operating systems, due to the safety of unprivileged execution modes and sanctioning system calls in order to do anything privileged (like access the hardware directly). Unfortunately, all my Pascal source code has gone to Pascal heaven. In 1996, I took a C programming course at Diablo Valley College (the local junior college) with my friend Danny Greenhouse. While absurdly easy, the class was certainly productive and did help formalize some of my programming. The use of pointers and structures (as opposed to Pascal's "records") make C a very powerful language - the Linux kernel is written in C, for example. Turbo C++ 3.0 was the compiler of choice. Like Turbo Pascal, Turbo C++ supported inline assembler code, so much of the knowledge and experience I had from writing inline assembler code in Pascal programs carried over. I kind of miss the whole DOS development experience - using a text mode editor with its simple but attractive syntax highlighting and equally simple user interfaces with programmer efficiency in mind, the programmer bothering to spend time writing assembler code, instruction by instruction. I even miss the DOS console font and the 16 ANSI colors. I kept doing DOS graphics programming, and getting a little bit into sound coding. Recently (2009), to my unbounded delight, I recovered the data off of an old hard drive which had all of my old C source code, as well as my copy of TC3. Most of the programs were dated 1997, "by chainsaw", which was my BBS handle back then. I was ecstatic, because that meant I could actually run TC3 again (this time in DosBox) and compile and run my old programs. If I had an absurd amount of free time, I would consider even doing more DOS programming in TC3 within DosBox. Some of the programs didn't run properly, possibly from bugs in DosBox (the real DOS was relatively easy to crash anyway). Many of the programs did run, and I went through as many as I could, taking screenshots. I would like to take video of some of them to capture the animation (especially for the fire demo). Left: "Bolt" - a lightning bolt demo program could run at high framerates (DosBox clocked in at above 60 FPS, and judging by the performance of other DOS games within DosBox, this is approximately the performance of an actual 486 system). Right: "Dots" - one of several 3D programs, this one rendered sprites for each of the point-masses in the rotating model. The sprites' on-screen sizes were scaled depending on how distant they were in the 3D scene. Left: "Duck" - this demo is the one I was most proud of - a 3D polygonal graphics engine with flat shading. The face-ordering algorithm was slightly incorrect, causing some distant polygons to be rendered in front of nearby polygons. This demo ran at 12-15 FPS on a 486 100Mhz machine, so it wasn't quite as visually pleasing. The duck spun around wildly changing axes. Right: "Fire" - The obligatory fire demo. The algorithm was quite clever and simple (gleaned from PCPGE as mentioned above), and ran fast - I believe 40 FPS in DosBox. I would like to have this exact demo as a screensaver (complete with blocky resolution graphics). Left: "Potter's Field" - this was a demo I made for my friend Erik Fong's BBS "Potter's Field". This demo was predicated on the "duck" demo shown above - the logo spun around. I had also added sounds of Beavis and Butthead laughing at random intervals, though when I compiled and ran it in DosBox, the sounds came through as complete garbage. Right: "Texture Map" - one of the more intricate routines I had written was a texture mapper. It ran really slow, but it looked pretty decent. Just having done it was enough for me though. Here is some of the source code - specifically for "Duck" and "Fire". The code organization is utterly retarded compared to professional work - I even included C files for fuck's sake - but who cares, I was a kid :) Fracture GUI-based fractal exploring/generating app done in MFC 1998 Made using MFC after taking a class at Diablo Valley College in C++ GUI programming, Fracture was a fractal image exploring and generating program for Mandelbrot and Julia type fractals. It had a nice color gradient editor for creating detailed colorings to apply to the fractal shading. In general, the most basic style of rendering assigns each pixel a color based on the number of iterations required to determine if a point in the complex plane is not in the set (and usually black if the point lies in the set). This gives a visually discrete coloring pattern (see this for an excellent example from Wikipedia). At some point, I had Fracture performing smoothing to make the fractal coloring appear continuous (see this for the corresponding smoothed Wikipedia example), but it looks like I took it out in later versions. Left: A red-green-blue gradient colored portion of the Mandelbrot set. Right: A zoomed out image of a particular Julia set. Various color schemes on various portions of the Mandelbrot set. I have a 2 by 3 foot printout of the fluorescently colored one hanging above my desk in the UCSC math office. Found by my friend Danny Greenhouse, this is my favorite image. It shows a high degree of very pleasing self-similarity. This one is also hanging above my desk in the UCSC math office. Unfortunately, Fracture uses MFC, and Visual Studio Express (the free version) doesn't come with MFC. I've been too lazy to find and install my old copy of Visual Studio 6, so no screenshots of the application itself in action (for now). Plus, I loathe the entire Windows development experience, so I'm not particularly motivated to get that development environment running again. Hopefully, the source code compiles as-is. Left: Fracture in action, at the main exploration screen. The exploration screen uses a low-resolution preview to save computational time. High-quality images can be created via the "render" menu. Right: The gradient-editing dialog. Fracture is free open source software, released under the GNU GPL license. Source code: fracture.zip Histogram text-based histogram generator 2004 Histogram was a tiny little C program I wrote when I needed to analyze some data. It prints out a hashmark histogram (frequency chart). You have to enter the data in descending order. I suppose it would be nice to have it accept data in any order, but whateva'. Here's a screenshot of histogram in action. Here is the source code. Note that it must be linked with the math library (-lm in Unix). histogram.c SDH subversion diff highlighting 2005 SDH is a tiny C program which highlights the output of the `svn diff` command. I use a bash shell alias set up to pipe it into `less`: alias svndiff='svn diff --no-diff-deleted | sdh | less -r' Here's a screenshot of histogram in action. There's not much else to say. Here's the source code: sdh.c Textbot timed text input replay program 2005 Textbot was a little utility I wrote to ease the tedium of manually testing console applications which require time-based input (i.e. where commands can not be buffered and serialized). While not especially clever or robust, it got the job done. It works like this: you run your application "behind" textbot as such: ./textbot stupid_app stupid arguments Textbot will eat directives (any line that starts with @). The @help directive prints: ********************************************************* *** help ********************************************************* *** @record <name> record a named macro *** @play <name> play back a named macro *** @loop <number> start a loop of given iterations *** @stop end the most recent loop or macro *** @macrolist print list of recorded macros *** @help this message ********************************************************* Macros can be recorded and played back. Looping is possible as well. I thought I created a way to dump the recorded macros to a file for later reloading, but apparently not (or maybe I lost that particular version somewhere). I'll probably add that (back) at some point. Source code (released under the GNU GPL version 2): textbot-20100607.zip Textbot uses GNU Flex to generate the scanner code (I'm using version 2.5.35), though you shouldn't necessarily need flex to compile, since the generated scanner code files are included.