Graveyard of Forgotten Projects (Part 3)

This is a direct continuation of the first and second parts. Let this partial quote from there serve as an introduction:

This series (hopefully) of blog posts will gather and shortly describe some previously unreleased and/or forgotten projects I’ve worked on over the past decade and a half, starting from 2000. This is by no means a complete listing, I’m still skipping over the vast majority of unfinished ideas and half-baked projects, but I’m trying to include everything which worked to an extent or has some interesting features.

The primary purpose of this is to serve as an archive for myself, because, as you will notice when I go through the list, I’ve already lost a lot of somewhat interesting stuff and would rather not have that happen again. Perhaps one thing or another might also be useful to someone else, but I obviously won’t troubleshoot code I wrote more than a decade ago and haven’t touched since then! And, just to make that clear, it’s also obviously not indicative of my current skills.

I started this series of posts at the beginning of the year, and resolved to do at least 3 before the end, so that’s why this is happening now. The previous two iterations together went up to the end of 2006, covering a lot of abortive game attempts, a released PSP game and some useful tools.

GPU-based Image Processing and Multigrid Solvers

Around that time I had already implemented my bachelor degree project, and relatively shortly later (well, 2 years, but who’s counting) – and it’s highly related, so I’ll include it here – my master degree project.

These projects together ran roughly from 2004 to 2007, and there was no specific GPU computing API at all until their very end. People were just starting to experiment with doing compute on graphics cards using standard graphics APIs, and so everything I worked on during these projects I did in OpenGL. So, my first step was to create a library which makes it easier to do compute on what is essentially a graphics platform:

Object Model OverviewBased on that, during my bachelor work I implemented a lot of image filters, from simple stuff, over arbitrary convolutions, up to non-linear/anisotropic image filtering like Perona-Malik diffusion.

Perona-MalikTo gather and evaluate a good amount of data on all the GPUs popular at the time, I  created a benchmark which reported various performance metrics and released that on Beyond3D. Other programs created were a testing environment for filter development called “ftest” (my naming sense strikes again) and even a C# GUI for comparing various data and generating charts. I lost the source for the latter, but I still have the former. In fact, ftest has no issue running on my current Windows 10 system – not bad for a binary compiled over 10 years ago (no guarantees on this one of course!):

ftestFor my master thesis in 2007 I implemented a multigrid solver for elliptic PDEs using the same framework. I won’t go into too much detail since this is getting kind of long already and we need to get back to the games! In case you are interested, here’s my master thesis.

Muh aka Project Y aka YouMUH!

This is a long story, spanning all the way from 2008 to 2012. This doesn’t mean that I worked on it for 4 years of course, just that I spent a few days on it from time to time, often with months between them. The basic idea for this game was to be a 2.5D side-scrolling platformer/action game starring Youmu Konpaku (who is in the logo of this blog by the way, and has been since its inception. I guess I always thought I’d talk about this project some day).

In any case, looking back on it now, the “game” seems to have been mostly an excuse for me to play around with whatever rendering, modeling or physics technology I was interested in at the time. That doesn’t mean that I didn’t have some idea for how the whole thing would play when it was completed (something like a mixture of Koumajou Densetsu, Bunny must die, and Noitu Love 2), just that completing it never seemed to be the point.

I started working on modeling for the game in 2008, with just a sword in Wings3D. During 2009 I spent a significant amount of time learning Blender and modeling/animating the main character. In 2009 I started with the actual coding, putting a lot of work into implementing deferred shading with a non-photorealistic art style. I created a cross-hatch shading algorithm which was based on a set of consecutively darker hatched base textures. The result looked like this:

muh_2010Subsequently, I spent far too much time with cloth simulation. At that point, this was still uncommon (nonexistent?) in games, and I basically created everything from scratch, starting with the physics simulation, over collision, to the file format used to specify cloth type/behaviour. It was an addition to the .obj file format and looked like this:

It was quite insane, but it worked out not too terribly in the end. I extended the same physics system to handle bone animations (this part worked well) and tried to also go for hair (this didn’t work well). You can see a video of the state ~2011 here. At that point, I had also switched to a more traditional cel shaded look (a decision which I would revert today).

muh_2011During all this time I continually refined the running animation, and looking back at the initial one and the final version I have to say that at least this was a clear track of improvement. The last things I worked on, some time in 2012, was level loading, where again I used a custom format, but at least it was XML-based. This is the final state of the project at this point:

muh_2012Basically, once I got a level loaded (with no materials mind you) I realized that, as a single developer, doing the entire game at a level of graphical sophistication which does the effort I put into just the main character’s skirt and running animation justice would be utterly infeasible. At the same time, doing it any lower level wasn’t going to make me happy, and just doing things again for which I already had a “proof of concept” so to speak would be boring. So, at that point I shelved the project — and a bit later started to work on DSFix, which turned out to be a lot more helpful to far more people.

Nonetheless, I learned a lot doing YouMUH! over the years, including:

  • Modeling and animation in Blender (and that I’m not great at it)
  • Deferred shading
  • Some approaches to non-photorealistic rendering
  • Physics simulation (particularly cloth/hair)
  • Some of the problems that come with trying to integrate neat state-of-the-art code with, well, art

And also, that it’s not a good idea to attempt a medium-fidelity 3D PC game (with bleeding edge features like cloth simulation and NPR) while doing almost everything from scratch and also handling all the code and art on your own. Well, it’s not a good idea if you want to finish something, it’s pretty nice as a hobby and for learning things!


That’s it for this iteration. There’s still one more project I’ve never posted about that I consider significant, and a few smaller ones. But I really wanted to at least reach the 2010s before 2015 is over!

Graveyard of Forgotten Projects (Part 2)

This is a direct continuation of the first part. Let this partial quote from there serve as an introduction:

This series (hopefully) of blog posts will gather and shortly describe some previously unreleased and/or forgotten projects I’ve worked on over the past decade and a half, starting from 2000. This is by no means a complete listing, I’m still skipping over the vast majority of unfinished ideas and half-baked projects, but I’m trying to include everything which worked to an extent or has some interesting features.

The primary purpose of this is to serve as an archive for myself, because, as you will notice when I go through the list, I’ve already lost a lot of somewhat interesting stuff and would rather not have that happen again. Perhaps one thing or another might also be useful to someone else, but I obviously won’t troubleshoot code I wrote more than a decade ago and haven’t touched since then! And, just to make that clear, it’s also obviously not indicative of my current skills.

I stopped the previous post around 2003-2004, a timeframe of abortive attempts at creating a 3D multiplayer physics-driven space ball game.

Rudloid

I wasn’t sure where to slot this in, as I started this project in ~2002, but did a lot of work on it in 2005. I chose to go with something closer to the latter than the former. This is an Arkanoid clone written in Ruby. It used the RUDL SDL wrapper (another amazing example of my naming sense really), and initially did software rendering. Later on I switched to using OpenGL for the rendering for performance reasons, which is why the final 2005 iteration was called RudloidGL.

What is interesting about this project is that it’s actually written rather well, in some ways at least. For example, I implemented features like collision detection, sound effects and sprite animation as Ruby mixins, and they are re-used in every object where it makes sense. So the balls, paddle, blocks etc. use the same basic collision code with distinct response events, and animated blocks, paddles and balls use the exact same sprite animation code just with slightly different parameters.

Of course, there are also some things were I was maybe going a bit too far with trying to be smart. For example, I used the “evil” library (yes, that’s actually its name) to implement different ball/paddle/etc. types and changing between them (when picking up a powerup pill) by actually changing the class type. It works, and in a way it’s elegant, but it’s also a bit wild.

Talking about powerups, that’s actually another thing where the code for this game is a lot better already than most of what I discussed in the first post in this series. For example, I seem to have had attained a decent understanding of the “once and only once” principle at this point, and the value of setting up tools in the code base so that it can be effectively used. For example, this is the actual, entire definition code for all 12 powerup pills in the game:

While eval’ing some random strings would make my hair stand on end now, at least the heart for this code is in the right place, and I still appreciate how concise it is.

The game also features a level editor, which nicely reuses most of the actual game rendering and related code. It also allows for undo/redo and copy/paste operations.

On the whole, this isn’t too bad really. What was bad, no, terrible are the sound effects. I never spent much time on those and it really, really shows. Check it out for yourself in this Shadowplay video I took of the game (after spending literally 2 hours finding all the dependencies in compatible versions and getting them to work together).

I will not upload the .zip for this, since I don’t think I am actually allowed to distribute some of the music and sound effects I used. If anyone cares a lot, post a comment and I’ll try to create a working package without those.

Wasser

The imaginatively-named “Wasser” (German for Water) is a very small program I hacked up in early 2005 in order to generate daily data fitting a decent-looking curve from monthly data about the electricity production from hydroelectric power plants. Until I made this, that was apparently a process carried out manually in Excel (I shit you not).

wasser2There are two interesting things about this one:

  • It uses both Tk for the UI window and SDL (via RUDL) for the visualization window. That’s insane, but I guess I just used what I knew, and it works.
  • I came up with the method of how to distribute data across the days of each month on my own, without really knowing how one would actually solve such a thing correctly. Nonetheless, what I do in the end isn’t too different from what an explicit iterative solver would look like.

You can get it here, though I have no idea why you’d want to.

Ragex

Released (actually released!) Christmas 2005, Ragex is a tiny generator for XHTML. I don’t need to write much about it here, because the web page is still online, I’m just including it for completeness’ sake. The best part about this one was when I got an email from someone actually using it, in 2008 or so, when I had almost forgotten creating it.

Crystalise

After my 3D experiments in 2004, and other game projects that never quite reached completion, I really wanted to actually finish a game. That’s why I came up with a very simple action/puzzle principle, and Crystalise was born (also check out the help file for a visual explanation of its gameplay).

Here’s a bullet point summary:

  • It’s made for PSP, the hottest gaming device of 2005 ;)
  • The vast majority of the game is written in Lua, with some of the heavy lifting (rendering, collision detection) in C. Pretty modern in that regard!
  • As far as I can tell, I completely lost the entire C source code for this project, as well as all the original (non-distribution) assets. A valuable lesson about backups, and even more so the value of releasing the source. The lua code at least is included in the distribution.
  • It really is a complete game, including stuff like a main menu, difficulty levels and high score tracking.
  • The levels (including boss and special levels) are procedurally generated, probably one reason why I actually managed to finish this game.
  • If you hit a certain level (which probably no one except me ever did) the game increases the PSP clock speed to 300 MHz in order to keep up solid 60 FPS:
  • I believe I invented the now commonly used paradigm for writing text with a analog gamepad in this game. That is, selecting a direction with the analog stick and then selecting a character from that direction using a button:

This is one of those projects where I’m really sad I lost (part of) the source. At least in this case most of the Lua is still available. And some of it is pretty neat, check e.g. circle.lua which (despite the name) keeps track of and handles updates to the current state of the level.

LuXr

This is a C#-based program launching (and other stuff) tool that I’m still quite proud of. I made and released it in early 2006, and the web page is still online. I just downloaded and ran the 54 kB package, and it still works well on my current Windows 7 installation.The major reason I created this was because I was fed up with the Windows (pre-Vista) way of launching programs. Of course, Microsoft seemingly agreed, and the keyboard / string search driven way of using the start menu in Vista onwards pretty much made LuXr obsolete.

Still, there are a few things to like about this one:

  • The aesthetics for the startup effect were influenced by the OS in Serial Experiments Lain. Which was much more awesome of course.
  • It features a plugin system which dynamically loads plugins written in C#, which can have their own config dialogue pages (they are adressed by adding a prefix to what you type, e.g. “g something” to google “something” with the google plugin, or “e” to use the eval plugin:
  • I still prefer how this resolves substring matches comapred to the Windows Start menu search. For example, if I write “vis 13″ in the start menu on my current PC, it finds no matches. LuXr finds “Visual Studio 2013″.

What’s not to like is that I believe I lost the source for this one as well (except for the plugins, which are part of the distribution package). It seems that with the years progressing I got better about actually releasing stuff from time to time, but worse about keeping backups.

 


That’s it for today, next time around we’ll get to actual 3D graphics programming. WHOOOHOO!

Graveyard of Forgotten Projects (Part 1)

I’ve wanted to do this for a very long time, at least since early 2014, and one of my resolutions for 2015 was to finally get started. This series (hopefully) of blog posts will gather and shortly describe some previously unreleased and forgotten projects I’ve worked on over the past decade and a half, starting from 2000. These projects will mostly be games (or game ideas, rather) but also include a few applications. This is by no means a complete listing, I’m still skipping over the vast majority of unfinished ideas and half-baked projects, but I’m trying to include everything which worked to an extent or has some interesting features.

The primary purpose of this is to serve as an archive for myself, because, as you will notice when I go through the list, I’ve already lost a lot of somewhat interesting stuff and would rather not have that happen again.

Perhaps one thing or another might also be useful to someone else, but I obviously won’t troubleshoot code I wrote more than a decade ago and haven’t touched since then! And, just to make that clear, it’s also obviously not indicative of my current skills. That said, let’s start! I’ll try to do this chronologically.

Fastimg

fastimg_mainThis early 2000 (with some 2001 updates) – so, when I was in the middle of high school – project was a Delphi-based GUI tool for quickly generating pure HTML image galleries, automatically resizing images and generating thumbnails. Shout outs to Delphi for being by far the most convenient tool for generating GUI applications back in those days!

Thanks to the wonders of Windows binary compatibility and static linking, the executable I found which was compiled on 2001-11-05 simply launches and works on my current Windows 7 system. Seriously, if nothing else Microsoft deserves major kudos for making that possible, it must be absolutely maddening to work on.

fastimg_prefsYou can see the preferences dialog above. Anyway, the tool has obviously been made completely obsolete by technical progress, but it’s fun to see that it still works. Here’s a zip archive containing the sources (and holy crap, are they ever terrifying!) and binary. I don’t recommend looking at it ;)

Another Delphi application I remember writing around that time which seems to be completely lost now was an advanced Windows Registry search/replace/editing tool (which was also much faster than regedit). A bit like Advanced Regedit, but not as fully featured.

Tetris Attack Puzzle Mode & Hitori Solvers

Around 2001 or 2002 or so I wrote a few Ruby scripts to solve puzzles. The first one solves Tetris Attack puzzle mode levels, outputting the optimal turn sequence. It’s command line only, so no screenshots to show off here.

hitoriThe other one helps solving Hitori puzzles, and even visualizes them, as you can see above. Here’s an archive with both scripts, though note that they require a very outdated Ruby version to get working – and are terrible in terms of code quality of course.

Urlaubtris

I wrote this Tetris clone around the end of August 2002 while it was raining for a few days when I was on vacation with my family in Italy (“Urlaub” is German for “vacation”, as you can see with e.g. GeDoSaTo my naming skills are still just as amazing as they were back then).

It uses Ruby 1.8 and RUDL (a Ruby SDL layer), and as such is almost impossible to get running on modern systems. I managed to create a packaged binary which should include the right versions of the interpreter and all the libraries, but I’m very unsure that it will actually work anywhere.

There are a few neat things about this one, considering I spent all of 2 or 3 days over 12 years ago writing it:

  • It supports an arbitrary number of cooperative players — or, well, as many as you can manage to find keyboard keys for :P – and arbitrarily sized levels.
  • It saves/loads settings as YAML files. Considering YAML history, that was some pretty damn early adoption of a technology which is still around and which I still like.
  • The code isn’t completely terrible even if I look at it now (which makes sense since it’s very small and written in a very short amount of time, makes it hard to accumulate cruft).
  • It features the Gameboy Tetris theme performed a capella by my sister as background music ;)

Here’s the archive in case you are interested. As I said above, you probably won’t be able to get it to work, and I’m obviously not going to support it.

Eball3D

This was my first 3D game project which got further than just displaying a model on screen. It was also my first larger-scale C++ (as opposed to C) project, and it’s as terrible code-wise as you might expect from that description. I started on it in 2002 and worked on it for a few weeks, and also came back to it for a few days in 2003 — at least that’s what it looks like from the file timestamps.

The game uses the Ogre3D engine, ODE for physics and OPCODE for collision detection. All in some very specific and utterly outdated version, and in a Visual Studio .NET (that is, 7) project and as such, I didn’t even try to compile it. I also made some “art” for it, using Wings3D (still a very neat, free polygon/subdivision modelling tool IMHO) and Rhinoceros, which was available at the university I had just started at.

The idea was to create a game which plays a bit like Uniball, but completely in 3D. That is, there are two teams of players, a ball, and two goals, and they can shoot the ball either to pass them between each other or at the goal, while being affected by recoil and slowdown while carrying it. I was going to go for an “energy” ball in this version, as it would have made a bit more sense in 3D when quickly “picking it up” or taking it off another player.

As I said earlier, it’s nearly impossible to get to compile (never mind running!) on modern systems, and I don’t have any screenshots anymore, so sadly some model shots must suffice:

To the left you see a ship: the semi-round thing in the front carried the energy ball if it had one, and I was going to change the blue colored stripes on the back depending on team assignments – of course I now realize that this wouldn’t have been nearly visible enough. And that the model is utter crap ;). To the right is a level. The game would take place inside the ellipsoid, with the ball bouncing off both its outer walls and the obstacles within, allowing for some skillful ricochet play. Note that a ship was small enough for two of them to easily fit through each of the holes in the central obstacle.

I got as far as loading everything, getting physics/collision for the level, ball and ships working, as well as making a single craft playable and capable of picking up and shooting the ball, before losing interest. I remember that when I wanted to get back into the project later on (in early 2003 I think) I tried upgrading it to newer versions of all the libraries used, hit some roadblocks and dropped it again.

UBC

I picked up the Eball3D idea once more in late 2003 and 2004, but realized that full 3D gameplay would simply be too complex to be fun (or even playable really). Especially since much of the enjoyment in Uniball came from pulling off precise team moves and passes.

As such, the new plan was to go with an essentially 2D level structure, but with some elevation, jumps and perhaps multiple stacked planes. However, I got distracted with developing more and more intricate revisions of the level editor with C# and never even got to a state where you could do anything in-game (unlike Eball3D).

On the left you can see a screenshot of the second unfinished revision of the UBC level editor, and on the right the initial model for the player crafts. The energy ball would have floated in the central space if carried — as you can see, the shape is much simpler (and probably more elegant) than in Eball3D, built for “2.5D” gameplay,  and would also have allowed for much faster and more exact collision detection. So I guess I learned something at least.

-

That’s it for today, as I already spent around 5 hours crawling through backups and backups of backups as well as trying to get completely outdated software working to an extent that will allow me to at least take screenshots. Next time I’ll have some more modern projects to show, which might be interesting from more than just a historical perspective.