
|
I wrote this thing back in 1997, my 3rd year of University, for my intro to computer graphics course. It was the first time I ever wrote something that rendered objects in actual 3D-space, so it was a lot of fun to make.
All the rendering is done by me, not a 3D API (like OpenGL or Direct3D)--this was the whole point of the assignment. The only graphics API I used was the FastGraph library for setting the video mode and getting a pointer to the raw video memory.
Basically, there are some wireframe objects (cubes and cylinders) that you can fly around. The objects are near and far clipped (this was part of the assignment), so that's why you see them disappear when they get past a certain distance away. In the top left of the screen is the framerate and below that is the current focal value.
Download (47KB) It's a DOS program, but runs under Windows XP fine for me.
| Input | Action |
|---|---|
| Up Arrow or Keypad 8 | Move Forward |
| Down Arrow or Keypad 2 | Move Backward |
| Left Arrow or Keypad 4 | Turn Left |
| Right Arrow or Keypad 6 | Turn Right |
| Keypad 1 | Strafe Left |
| Keypad 3 | Strafe Right |
| S | Move Up |
| X | Move Down |
| Shift | Move/Turn Faster |
| - (Minus) | Decrease Focus |
| + (Plus) | Increase Focus |
| ESC | Quit |
|
This was the final assignment in the same University class mentioned above (so also in 1997). Again, a 3D API was not used. I used FastGraph to set the video mode, and that's it. The perspective-correct texture mapping was done by myself. This is in 8-bit color (320x200x8), so the textures don't look so hot--certainly not compared to games these days! Also, I didn't do any mip-mapping, so the textures look especially bad from far away (very pixelated).
I used portal technology to help organize the level and determine what is potentially visible from a given point. There is very simple collision detection: you are a point in space but you have no width. So you can get really close to a wall, and actually see through it if you turn sideways :-) I also implemented "enemies", if you can call them that. The enemies in this game are just big uh... diamonds. They just float around randomly, bumping into walls and each other. You can shoot them, but they can't hurt you. I think width is taken into consideration when you shoot or bump into an entity, but I really can't remember. I implemented very, very basic lighting. Things get darker the farther away from you they are. This simple lighting effect really helped add the appearance of depth.
I had some bugs that turned up just once in a blue moon back on my 486 (or whatever I had at the time). But on the fast PCs of today, it's hard to run the thing without the bugs popping up! There is a bug with the sin/cos lookup tables I implemented, which will crash you out of the game with an error (some rounding error around 360, which should map to 0). There is also a bug with the entities. I think it happens occasionally as they move from one sector to another. They seem to multiply, and eventually crash the game. I used to have 3 in the level, but I edited the level file and took all but one out before uploading it to here so that it won't happen as often. I've noticed that sometimes the mouse input doesn't appear to work. I'm not sure if this is because it's running in windows but using legacy mouse support, or what. I can't really fix the bugs now, because I don't have all the required stuff to build it anymore (the Watcom compiler, Fastgraph, etc).
Download (302KB) Again, it's a DOS program, but appears to run under Windows XP.
| Input | Action |
|---|---|
| Up Arrow, Keypad 8, or Mouse Up | Move Forward |
| Down Arrow, Keypad 2, or Mouse Down | Move Backward |
| Left Arrow, Keypad 4, or Mouse Left | Turn Left |
| Right Arrow, Keypad 6, or Mouse Right | Turn Right |
| Keypad 1 | Strafe Left |
| Keypad 3 | Strafe Right |
| S | Move Up |
| X | Move Down |
| NumLock | Twist Counter Clockwise |
| Keypad * | Twist Clockwise |
| Keypad 7 | Turn Down |
| Keypad 9 | Turn Up |
| Enter | Reset Orientation |
| Shift | Move/Turn Faster |
| Control or Left Mouse Button | Shoot |
| - (Minus) | Decrease Focus |
| + (Plus) | Increase Focus |
| \ | Reset Focus |
| O | Lighting Off |
| L | Lighting On |
| ESC | Quit |
|
This was also written in 1997 as a University project. It was the final project in my artificial intelligence class. We got to choose from a few options and I chose to do this ant simulator to demonstrate "emergent behaviour". Basically, you implement the behaviour of a single entity and watch how group behaviours emerge. So in this case, I implemented the behavior of a single ant, and you can see the ants working together as a colony.
Each ant (red dot) can sense food (the green stuff) from a certain distance away. They can also sense ant pheromones/scents (the purple stuff) from a certain distance away. If no food or pheromones are in range, they wander randomly. If food is in range, they move towards the highest concentration of it (brightest green), with slightly random motion. If they step onto a location with food, they pick up as much as they can carry, and start walking towards the anthill (the red plus), dropping pheromones on the way. They can sense the anthill from pretty far away (by default), but if they are too far, they will wander randomly until they are within range. If an ant does not sense food, but senses a pheromone trail, it will follow it in a direction away from the anthill, looking for food.
The emergent behaviour is really interesting to watch. The ants start out randomly placed around the anthill. As ants discover food and leave their pheromone trails behind, others see the trail and head over to the food stash. The pheromones they drop wear off over time (the purple gets darker), so long paths to distant food are hard to follow if only a small number of ants have that food pile. As a result, you will see that closer food tends to be harvested first.
The default graphics mode and such are setup for older PCs, so you can experiment with higher resolutions, more ants, bigger food piles, etc. The batch file Hmm.bat (contained in the Zip) will run it with an example alternate configuration. There are a ton of command-line parameters, so use /? to see the complete list of them.
Download (209KB) Again, it's a DOS program, but appears to run under Windows XP. I keep meaning to port it to Windows as a screen saver. One day...
| Input | Action |
|---|---|
| ESC | Quit |
|
Okay, this one is my pride and joy :-) I did this as my Honours Project in 1999, in my last year at Carleton University. This engine can load up Quake 1 map files and render them quite efficiently. It uses OpenGL so that the 3D rendering is hardware accelerated. It uses the Quake 1 BSP (Binary Space Partitioning) tree data structure, and several other technologies, to help it determine what is visible from your current location and orientation. Because of this, in each frame it can throw away huge portions of the map to save precious CPU cycles.
It also takes advantage of the lighting information (light maps) stored in the level files, so that it can render realistic lighting effects. I didn't get the light maps 100% perfect, because Quake BSP file documention at that time was severely limited. However, they are applied properly in most areas of the levels I tried. Oh and of course, about what.. 6 months after I finished this project, id released all the Quake 1 souce code! Man... what I would have done for just the algorithm for applying a light map to a surface!
This engine was a huge amount of work. The most painful parts were getting all the details of the Quake 1 .BSP file structure right, and of course figuring out how to apply the light maps. Many, many all-nighters went into this thing (and the write-up). This is definitely my favourite thing I've ever programmed.
The controls are 100% configurable, so I'll let you look for them in the UI, instead of listing them here. ESC quits.
Download (1.66MB) It should be able to run on any Windows OS since Windows 95, as long as you have a video card that accelerates OpenGL (any decent card made in the last few years should). I still want to add Direct3D support one day.
|
I wanted a tool to make naming and numbering images from my digital camera both easier and quicker. So I wrote this GUI application as a C# and .NET learning project.
Instead of repeating everything that is is the documentation, just RTFM :-)
Download (110KB) It is a Windows application that uses the .NET framework. If the installer aborts telling you that you need .NET, just run Windows Update and you should see it in there. I think it's optional, so it doesn't install automatically--you have to select it.