Somewhere around 2006 to 2007 I was learning OGRE in practice by forking an existing project. It was Walaber’s Stunt Playground, original video looked quite different. Is on website, but the sources aren’t available anymore (he’s gone fully commercial).
📜History
OGRE was very popular at that time, had many plugins, so it was the best choice of engine for me. Its version was 1.2.1 (Dagon) then.
GUI was made using CEGUI and physics with Newton Dynamics through OgreNewt. Both of which I didn’t continue to use later since their limitations.
📊Features
The game had few cars, dynamic objects, an editor for placing and moving them, loading/saving maps, replay and sound systems.
Tracks were exported just like objects, which posed a big penalty having no level of detail on them. Plus tedious editing in 3D modellers (not in own editor) and lastly not allowing an optimized terrain, grass or trees.
✍️Motivation
Back then it also had open sources, great to learn from and not too big (180kB total). Compiling them was also not too difficult for me at that time. I learned a lot by modifying the game and it was a perfectly fitting experience that moved me forward in the direction I wanted to learn, without too many obstacles.
➡️Next
The static tracks got me into looking for terrain editors next. And I eventually developed my own track editor years later.
Now, if you know Stunt Rally 😉, you can probably already start spotting something similar. Well the camera system is greatly based on this one. And particles like sparks and dust I developed then are nearly the same.
CrystaL Recorder (or shortly cRec) was a program I wrote for recording audio.
At first, it just captured and saved in wav file format. It had a counter for files so each new incremented it.
It was coded in C++ with WinAPI calls, and using bitmap fonts made in my Crystal Font program.
📊Features
It also had an volume amplitude bar (similar to VU meter), with overflow indication, signalling too high volume of recording.
Then I featured it with a nice wave oscilloscope visualization. The line color changed depending on amplitude (going violet for high frequencies). It also has a glow effect, but not a real distance. For me it actually looked better since you could still see smaller details in glow same as in wave. It updated at 60-85 frames per second, same as monitor’s refresh rate. There is a similar wave visualization in my audio player.
For later versions I’ve also added code to use the Windows Mixer interface. Gaining most of the functionality a sound card mixer has: listing channels, muting, changing volume, picking one for record etc.
It was a nice, little, very useful program with my style of everything: colors, fonts, keys and visualization.
➡️End
I was quite angry when I moved from Windows XP to Windows 7 and it actively disallowed me to record from “What U Hear”. Due to some crap, that Microsoft always does. There are even websites about it. And people doing something to change for better.
So I stopped using (and developing) it, after I’ve found another way and then moved.
These are various demo projects done at work, using PhysX a realtime physics simulation engine. More or less the same features can be achieved using Bullet, is open source and IMO better. I did everything it offered then, e.g. rigid body, joints, cloth, fluid and car (tires) simulation.
📜History
I also implemented rag doll (for bodies) and water buoyancy areas. I had a demo with rag doll in water.
The job was very underpaid (also my first), but educational. Also good experience for my next job, since it used PhysX too.
In the next one I implemented sailboat dynamics and water buoyancy for objects, way simpler (for my taste), but at least fast. The algorithm was for a height based water and just used 2 points on each shape type to compute forces.
⏳Summary
So I learned and developed many things for game physics at the time. Definitely not all, e.g. no simulation or destruction/fracture, which got me interested. But I’d say I was a game physics programmer for few years.
The car simulation was very basic, I continued later on my own with car games.
This is a collection of programs written in C++ and using Direct3D9. Only the first one left (with green terrain) was mostly mine. It was also a project on college, for subject: 3D Graphics (I think). I did way above requirements as nobody even knew shaders.
The first small terrain had a shader for blending (mixing) terrain textures together smoothly. Already found somewhere on internet. This I knew is needed for good looking terrain for start.
After achieving just a small terrain and a cloth looking, pseudo water I started searching on internet for open source examples (it was likely the first time for me). I managed to build all of them and customize the demo applications. I didn’t put anything together as a game yet.
The water in middle was great but very demanding for CPU, which was computing the animated noise and its normals. This is done nowadays on GPU only. Still, it had the best look IMO for years.
White terrain with water on left, had a great animated noise but was always flat. Originally it also featured reflection and refraction. This always flat water, was still good and we had a similar one in our game years later.
On right there is a terrain with level of detail (LOD) Geomorphing (also described here) if I remember it was CPU generated though, but had 5 levels. That was a great and complicated implementation.
The car screenshot was someone’s 3D model, with a 2D driving code I found. I made it 3D, but only on flat ground.
➡️Conclusions
Then I started thinking and realized, I don’t want to write all 3D equations, surely not a physics system. This is when I got interested in available physics engines. Today I would definitely recommend bullet for collision detection and simulation.
Next, I had the same thought for rendering. Writing everything using calls to Direct3D was tedious and not very practical. By using a 3D engine, all becomes much easier and one can achieve much more with it. But I knew a guy at college, who liked the first approach, read books for it, and wrote his own engine. Later I found OGRE 3D and started learning it.
This is a result of me learning bump shaders with also implemented reflection and refraction (just from cube skybox). There wasn’t really a goal here, just to learn and show what could be achieved with my GPU (ATI Radeon 9800 I think) at the time.
My code was using WinAPI for window creation and messages. Then Direct3D9 calls for rendering and HLSL 2.0 for vertex and pixel shaders. Also D3DX for anything else like 3D matrix and vector operations, compiling shaders, and loading 3D models (meshes) from X files. Lastly a sprite font, for screen texts (with parameters to adjust by keys) using my bitmap fonts.
To get mouse and keyboard events I was using DirectInput. I made a camera system to move around the scene, rotate and zoom. There was also 1 point light here. I wrote a Timer (based on precise QueryPerformanceCounter) for checking intervals and computing current frame rate (Fps).
I think I made most of the basic models. I would use Blender for this now. The skull model and all textures were gathered from other demos and games.
⏳Conclusions
Professional made textures made the demos look quite good, already with simple 3D objects. But those were just demos. In a bad looking, low level written code.
I continued using just C++ and Direct3D9 for a while in next project’s forks with terrain and water. And after that moved to using OGRE 3D engine. All that was too tied to DirectX and would need major rewrites every time I wanted to use new DirectX interface. Another good reason for using an engine, it can have different rendering systems also OpenGL based.
Still, this experience was good learning for future, as I was developing shaders in Stunt Rally too, years later.
This is one of my oldest Windows programs in C++. It can generate colorized bitmap fonts from true type fonts with glow effect.
Done on college as hobby around 2005-2006. I used bitmap fonts from it in most of my programs, until about 2010. Additionally it made the text for my logo, and lastly the speed and gear digits in our game.
📜History
I had a small font tool without GUI, earlier when I was programming in Delphi. This one evolved to be a full featured program with medium size code.
I presented the program at college, during scientific circles session, for 15 minutes. The presentation was also a good experience to have.
It was a nice, useful program for me. Probably difficult to use for others due to only keyboard navigation and value changing. It had a help screen with shortcuts though.
📂Sources
Later I’ve uploaded it to Source Forge and thus it became my first FOSS program. Then I moved to Google Code and when it shut down, moved to GitHub.
There were several programs done called bitmap font creator, maker or editor. It was (or still is) a popular thing to do. Both using bitmap fonts and making a program for it.
📊Features
Among other features it allowed quick loading and saving project files and coloring schemes. Also browsing them in its own lists with previews. One could easily pick a scheme for font color and quickly match another for glow.
Glow was computed on CPU and thus rather slow, especially for big font sizes and large textures. I didn’t develop it further after realizing that all this could probably be done with a GPU shader in real time, even with animations, at least for small to medium fonts.
This is the 3rd and last version of my Frogs game for 2 players. Programmed in Delphi. Done on college, subject was Programming (I think). I’m glad I could use my existing experience to pass it easier and more creatively. Previous 2 versions were in DOS and Turbo Pascal, shown here. It had exactly the same game style.
Gameplay
Player controls a frog, jumps to reach and catch flies with tongue. After game time, the player who had more flies wins (or there is a tie). It could be a slow and tricky game if flies were appearing rarely, or a fast game with lots of flies. Still, splashing flies made them fall down. Catching a falling fly would make the frog loose 3 and vomit. This was pretty hilarious.
The screenshot is composed of few, but this is shown.
📊Features
Sadly, it had no sounds at all. A huge flaw compared to earlier Frogs II, which was even more hilarious with funny sounds. It featured:
Nice looking menu (my own logo art)
Many options, for:
Flies – max count, increase over time, width and height of appearance, resistance to water)
Frogs – jump height, resistance to water (made jumping harder), tongue speed and idle time
Game – game, time, showing a counter (of flies, particles, etc.)
Lots of particles for:
Water splashes (like 500 was already enough for big ones)
Vomit (this even had extra keys to test)
Waving grass blades
Water changing direction and look, depending on direction of frogs landing in it (e.g. always dropping from 1 side made water more fuzzy and moving faster). Strangely this doesn’t work at all now. But anyway I’m surprised this game still starts and works 15 years later.
This is my first game in C++. Done as a project on college, subject was C++ Programming, I think. It was a top down space shooter and had just 1 level. Without game end, just no more enemies.
🔍Implementation
It was using purely Direct3D9 calls for rendering and WinAPI for Window. I drew the textures myself, not many.
Player ship had 4 weapons, auto gained with game progress: main 2 dots, small lasers, main thick lasers and side dots. There were 6 enemy types and the layout with their movement paths was already quite nice. Enemy weapons were actually just 1 type of orange dot. One ship fired a dot, auto directed at player. Others fired 2 to 4 dots in certain directions.
➡️Comments
I’m glad I managed to create a game (2nd actually) at college, where the major was basically Industrial Software for Metallurgy. It was still my main hobby back then. Since I had experience in games I wanted more to use it and develop. Was also quicker, easier and more fun to make a project for that subject. Code looked cryptic, I was still coding in my own way of not doing a single space if not required, and using 1 letter abbreviations for keywords and types.
I was having fun with Scream Tracker on DOS before, so it felt best for creating music and using only keyboard for that.
I called my program simply the same way, but started with version 6 and increased until 14. Then shorted it to just S and used Roman numerals XIV.
This was such an awesome program to use and look at. Mainly because keyboard shortcuts were customized to what I wanted, and also I implemented many quite useful operations in it, e.g. in patterns editor.
🔍Implementation
It was using GLScene package for Delphi and my colored bitmap fonts from another program (it was the predecessor to Crystal Font), hence so varying and colorful texts everywhere.
By default I also used colored image backgrounds, since pages felt really empty. It even had animated text transitions for title pages text and a toggleable fire animation in corner 🔥.
But it was complete garbage at the way sound creation was done. It simply relied on a system timer event and triggered sound playing from DirectSound buffers. I know, nobody does that for music. I didn’t know any other way to code this then.
Timer was more or less stable, but I had to render very little while playing, mostly empty screen and 1 bottom line of info.
🎵Music
I made about 5 songs with it, more here. Also used it for percussion patterns when we were both playing electric guitars.
Later I was checking out Renoise, but eventually my interest faded away from creating music.
Here I will gather 2 last games I made in DOS. Each of them also featured an editor, for creating (drawing) maps. Still in resolution 320×200 (256 colors) and in Turbo Pascal 7.0 with parts in Assembler. This was on PC with Pentium 120MHz. I tried 640×400 later, but it was too slow.
🚗Car game
📜History
The first game I just called Porsche. Poor name, it’s a brand name, so it can’t be used. But I was a kid and had a model and a poster of such car. On the most bottom left screenshot there is a first, starting version of this game. This is what’s left. Very sadly, I have lost the final version (had no others) about 1 or 2 years after. But I won’t forget how we played it, in the summer of 1997 with elementary school colleague(s).
📊Features
Game was for 2 players only and had split screen. Cars were in center, map moved below. Similar way to my earlier 2 Planes game here. Maps had 3 sizes (square, in pixels): small (250 x 250), medium (450) and big (700). Due to only 640kB memory big maps didn’t start in IDE, so I could only test the game on medium.
It was a simple, rally type driving with lots of sliding (especially in winter and autumn).
The final game had 87 tracks in 7 sceneries: Forest, Jungle, Desert, Winter, Australia, Autumn, City (latest new: Mountain). About 18 of them were actually just circles, ellipses and rounded rectangles. These were real fun to play with many laps. I still have all our track prototypes drawn on paper. They lasted way longer than any of my PCs.
There was an editor for creating tracks, where I would draw road:
straights and turns,
bridges or dips
jumps (car flew for a while without control, longer with more speed at start)
Then place trees (also all of 9 types of vegetation at once), water, etc.
There were also few graphic attractions like:
staying tire trails
dust behind cars (on deserts)
screen blur effect in autumn (with more speed), kind of like rain.
Next, gameplay features were areas, with:
water
mud (slowing down)
grease (less control and random turning)
ice (no control)
These were already present in my earlier game from 1996. Water puddles in autumn were even more slippery than the wet road.
Then were some funny things:
stacks of tires – didn’t damage car, but bounced it back and sounded funny
blocks of hay – helping on road, or side, by slowing car down, e.g. before sharp turns
hedges – were along road, safe, didn’t bounce or damage car
sharp bushes damaging car (possible on road)
city tracks could have crosswalks with people (few pixels), you could smash
Game featured sounds of course. The collision detection was quite basic (bad) but worked. The car just bounced back after hitting anything (trees and such), in the opposite direction it hit. We had simple damage slowing down cars. Tracks had repairing areas, car didn’t need to stop just drive over them.
So the screenshots on left, with car in center, show actually the next version Porsche II, which was started later but never finished.
🚁Shooter
The second game, a top view scrolling shooter, again I poorly named Rambo II. Was meant to have similar jungle style to that movie.
I did the basic start of game, 2 enemy planes, 3 weapons for player’s helicopter, animating water (palette), sparks on hit, and explosions. And the editor for map was quite good. I was drawing terrain levels, then few algorithms were adding noise, blurring few times to make it look like foliage (grassy hills). Then I could put rivers, with increasing width, starting from tiny streams. Rivers had auto added rocks on sides. On screen there are 2 types visible, clear blue and olive. There was also a separate tool, visible in the middle, just for putting enemy ships and picking their paths in places on the map. It was possible to move the map (in time) to show where ships will be.
Once I showed this project in class (technical high school), I didn’t have to do anything, besides attending. It was very cool.
⏳Conclusions
Since the loss (of Porsche with 87 tracks) was a result of my stupidity, I’ll gather the faults that led to it, with what I learned to do below:
HDD fail (the worst failing Seagate 1GB). I then even bought a second of same type (was cheaper) and it failed later too. Well today I’m checking for fail rates of HDDs before I buy and I don’t go just for the cheapest. For some time I made backups on CD/DVD/BR, some lasted more than HDDs. But now I don’t, recorders cost the same as HDDs. Eventually all HDDs fail, and I think I had maybe 2 every 5, lasting longer than I needed it. Now I have one HDD more, just for backup (of important data).
I made just one backup copy, on floppy disks, using a freaking self extracting RAR (binary exe). Without the 1st I can’t extract any later. I never used self extracting type after, and also forgot about RAR after I found out 7zip, which is also supported in DoubleCommander.
I have overwritten the backup, the first 8 of 23 parts. I shouldn’t ever do that. There were several ways to avoid this. Worst is that it was actually a suggestion from, well the stupidest teacher I had. The one who also said “you can overclock your CPU, no problems” and my motherboard died after. Later he even ended in jail for stealing huge money sums, also some from students. So yeah, as the saying goes: “never follow advice from people who you wouldn’t trade places with”.
I never made any copy of the source code during. It was 65kB for game and 68kB for editor. This is so small, that I should have copied it every day. Later I started just making archives often, from just my sources. And since I started with github I have repositories of my main projects there.
I would even loose everything from DOS (my projects in Turbo Pascal) with that stupid HDD, if I didn’t copy it all to my friend. I think it was my idea, so he could learn from it. He kept it and then I could restore it back.
Finally, I used few concepts of this car game and many actual tracks in our 3D game (started 13 yeas later) Stunt Rally. And since Stunt Rally was really well made and its track count reached 176, I don’t miss my 1997 game so much (which took 2 or 3 weeks to make). While Stunt Rally had (over) 5 years of development, and I wouldn’t make it so only by myself.
