Times, trials, and turbulence.
Sucked into academia.
Hello! It’s been a while.
Recently I’ve fallen into a world that revolves around school and general self-education. This consists of classes, upcoming midterms, administrative (and programming) work for the uni’s GameDev Club, researching/writing my article, and now taking another spin at developing a software 3D rasterizer. In a nutshell, Project Skirmish is sitting at the back of the stove for the moment.
I’m still making slow progress on the game development article, but progress nonetheless. I’ve always had a hard time writing reports/essays/articles in the past, so I didn’t expect this one to be an exception. I would say that the article itself is half-way done, and I’ve begun playing with the demos/source that will come alongside it.
(Above: Example of naive implementation of Metaballs)
As I work on the article more and more, I find myself learning more and more about Metaballs and isosurfaces, which oftentimes means going back and changing chunks of things I previously wrote in order increase the overall accuracy. I don’t think I’m in too hot of water, since most of the articles on Metaballs I’ve read just explain how to get pretty-looking gooey balls on the screen, rather than understanding the math, ideas, and concepts behind them. I’m eager to bring a little more of that into the world with my article. 🙂
I wrote the basic beginnings of one of these several months ago, but a lack of understanding in the area of mathematical knowledge and low-level programming soon brought it to abandonment. With all that I’ve learned since those days, I’m very interested in writing a comprehensive 3D rasterizer to a much more complete degree. I’m in a very early stage of development, so I don’t even have a triangle to show yet. I’m hoping to document my progress here as it moves forward, though.
What is a 3D rasterizer? It’s a fancy term that means: “doing things to triangles that are drawn to the screen”. After cutting off a lot of other goodies, OpenGL and Direct3D are both 3D rasterizers, as are whatever library fuels the 3D games on N64/PS1/PS2/XBox/etcetera. Naturally, these implementations run on super-fast hardware designed for 3D rendering, so mine will be a software implementation. It will be particularly interesting to see what kinds of shortcuts and tricks I can pull off to optimize the speed running on the CPU alone. 🙂
Today’s work was the not-so-simple task of getting [the ancient] DirectDraw up and running. The casual reader might argue, “Why not use a higher-level library that abstracts DDraw’s ugliness, like Allegro or SDL?”. It’s true that Allegro and SDL (on Windows, at least) both use DirectDraw underneath the hood. However, it’s exactly true that both also abstract the video buffer access that they give, to some degree. Allegro is the slowest for direct pixel manipulation, while SDL is nearly twice as fast. From my initial tests with DirectDraw — after nearly 3 hours getting the thing initialized properly and reading archaic documentation — is much faster than either. Now that I’m as un-fillrate-limited as possible, reaching better framerates shouldn’t be as much out of the question.
(Above: Drawing the XOR texture per-pixel at about 1048 Frames-Per-Second)
Anyways, there is certainly a limit to how much can be said on the topic when I haven’t even drawn any 3D goodies on the screen yet. I’ll digress for the time being. 😉