-I just hope it'll go somewhere from here too-
Ever since the days of the good old C64 I've been thinking about creating my own computer games. So far nothing happened. Just thinking about it suited me better I guess. I started late too. When it was a good enough time to finally start writing in assembly the C64 had become too much of a museum-piece.
On the 64, writing a few k's in mnemonics sounded ok. But the age of PC-DOS had went unnoticed already, and mnemonics under a Windows environment just didn't seem like the right thing for me.
Finally I stumbled upon C++. During my study of environmental sciences I was able to spend some time learning C++, and actually earned bit of money in doing so too. I discovered OpenGL later on, and quickly bought the Redbook.
Well, that's enough about me for now, as I feel a bit uncomfortable writing about myself in this journal.
As I said, i've been thinking about creating games for a long time. Since some time, my often fuzzy ideas about 'my kind of game' evolved into more clearly defined shapes. At this moment, I feel confident enough to start working on some of the details. I will restrict my ideas for the game to short side notes. One piece of advise: It is a very good idea to start with writing a plan for your game, and as extensive as possible. GameDev has some great articles about this. Read them.
For now, I've set myself up comfortably with the (free) Borland compiler, and ConTEXT. Now this is quite some tool. While editing my code with syntax highlighting, I can compile and execute the whole lot, as well as display C++ help. It's almost like a IDE, I just love it.
TRADING ROUTE & GRAPHICS
My game will have a simple cartoon-style look to it. I want cell-shading, outlines and shadows. Furthermore I want semi-transparant water with waves. I also want atmospheric effects, with at least differences in day and night. At a later stage I might include weaher conditions too.
Now, I like things neat and efficient, I prefer nice short code over messy code (since I'll spend enough time going through it), and I prefer the GPU over CPU for graphics rendering (I need the CPU for AI too). Nothing new of course, but I am very willing to make compromises. I won't spend costly CPU time on some nice graphical feature, instead I'll look for an alternative or I won't implement it at all.
Another thing concerning graphics is the time it takes to design them. I like to design graphics, but only as long as it doesn't take too long. A cartoon-style therefore suits me; plain colors instead of textures -I love it.
For now, I prefer to use the core OpenGL 1.1. I have no idea how many people have GFX-cards that fully support OpenGL 2.0. As long as I do not, I will stick to 1.1. I want the audience for my game to be as large as possible. I do not aim for visual effects, which I guess is as humble as realistic in this one man's show.
TRADING ROUTE & CELL-SHADING
The one thing about cartoon style rendering (in OpenGL 1.1) that I did not like, is CPU calculations. In methods that I've read so far a 1D-texture is used, and texture coordinates for each vertex are CPU-calculated using the angle between normal and light source.
I've devised a method to do cartoon-style shading WITHOUT ANY calculations, while still being able to rotate the light source around my models, as well as controling the color of the light (day/night differences). The method implies drawing an invisible sphere, projecting a simple 1D-texture map as contours on it (while using some texture matrix adjustments), and loading the resulting image as a texture for an environment map. This all is done by OpenGL in a short display-list. I only set the angles of the light direction before executing the list. The fragment is color-modulated with the environment mapping texture, and alpha blending for semi-transparant fragments can be done too. I've also managed to avoid environment mapping 'polar' distortions by adjusting the texture matrix.
I like this method, it suits my needs and wishes. Here's a view of the approach. The hidden sphere, to be used as the environment map texture is shown. Using OpenGL, a simple 1D-texture is projected as a contour on the sphere's surface.
The results are surely adequate. You can run into a bit of trouble though, if the environment mapping texture's size is smaller than the curvature of the model on screen. For a scene like this, the texture could be larger. The polygon-offset (for rendering the model's outlines) could be better obviously, but this is not the intended scale of things in my game.>>