Envelope Editor was a program I wrote at work once. Used for doing animations in game.
It was a simple and quite usable tool to create and edit TCB splines (also known as Kochanek-Bartels splines). Each point (besides x,y position) has also 3 parameters: Tension, Continuity, Bias. When all are zero the spline becomes just a Catmull-Rom spline.
They had only one dimension (time on x) and produced y value.
🔍Implementation
The application was written using Direct3D9 (which I already used for few years at the time) and DXUT for GUI controls (I customized the theme).
It looked nice, dark blue. There was also a second theme that was the boring, eye tiring white.
After getting more familiar with OGRE and reaching limits of Stunt Playground fork, I started doing my own project (2007-2008).
📝Implementation
It took previous camera code and put Ogre’s terrain component to a good use. Additionally familiarizing myself with PagedGeometry for grass and later for trees too.
It was using fmod for sound, PhysX for physics (with NxOgre). Those were used by me at work, so it was easier. Of course I wouldn’t recommend any of those two, aren’t open source.
🔍Detail
Total sources were just 86kB at this stage.
You can see Stunt Rally‘s Fps bar here in left bottom corner. Surprisingly the project still starts in 2016. Must have been the time when I finally learned not to use Debug all the time, and leave some Release builds for my future self.
🛠️Editor
At the same time I was also experimenting with Editable Terrain Manager to have an editor for terrain, and with RBGui which looked a lot cooler and better for me then. There is the first [Cam – Edit] toggle bottom left, same like in earlier Track Editor versions from Stunt Rally and a brush tool window too.
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.
