Change of pace. In the last week I’ve had an idea clawing at the back of my head, and it’s clear the thing isn’t going to leave me alone until I do something with it. I don’t usually blog about my little programming projects (with the exception of the Terrain Project) because I like to imagine this site has some sort of focus, but the choice here is for me to blog about this or leave the site fallow for a week. So I’m blogging it. Perhaps you’ll find it entertaining anyway.
There are several reasons for wanting to do this.
|It’s comical now, but this was a real eye-grabber in 1996.|
Way back in my early days of 3D development a lot of my work was focused on creating effects or finding tricks to make it look like there is more to the scene than what is really being rendered. A lot of work was being done by game companies to simply push the technology as far as it would go, but I enjoyed getting halfway there with technology and then going the rest of the way with a good facade and some lighting tricks. The techniques I used in the mid 90’s would seem laughably simplistic and trivial today, but at the time I remember getting a lot of “How did you do this?!?” type reactions to my work.
For example: I wanted to make a city, but the scene just couldn’t render things at a great enough distance to give you a “big city” feel. It just felt like a handful of big boxes next to each other in the middle of a featureless plain. So I set the city at night, scaled the buildings down so that they weren’t really much bigger than houses, and slightly pinched the tops of them so that the top of the (apparent) cube was smaller than the base. The reduced scale let me get a lot of buildings close together, the night lighting let me suggest more detail than was really present, and the skewed shape created a false impression of height. (The eye wanted to believe that these building-ish objects were cubes, and so when you looked up it made them seem taller than they were.) The scene was pretty astounding in 1996, although I doubt it would impress anyone today.
This sort of thing was an unusual blend of technical and artistic work, and I enjoyed it immensely.
My new graphics card is ridiculously powerful. While I’m working less and less with graphics these days, on the rare occasions where that sort of work crops up it’s still focused on getting more out of widely adopted low-end technology. So I haven’t worked with much new technology. (“New” being very relative. For me, anything younger than a kindergartner is new.) This makes me some sort of cutting-edge Luddite, pushing the limits of stale technology.
CPU’s have stagnated a bit over the last few years while GPU’s have continued to accelerate. (No pun intended.) This has moved a lot of the old bottlenecks around. I think it would be good for me to get to know one of these recent GPU’s and see what it’s like to work with them.
And finally, I love procedural content, but I never get a chance to work with it.
1. The goal is to make a nighttime cityscape that is mostly made of lights and suggestions rather than real detail.
2. The city will be entirely procedurally generated. That is, the program will contain no art assets. No textures. No models. Everything must be built from scratch at startup.
3. I’m budgeting a week of nights and weekends for the project. So, probably about 30 hours of time total.
4. I’m going to use only conventional rendering. While I’d love to muck about with pixel shaders and see what the new ones can do, I haven’t messed with that sort of thing since 2006. Just getting up to speed on the subject would blow my entire time budget. (Pixel shaders are special programs that run on your graphics card instead of on your “computer” with all of your other software. They are strange, amazingly powerful, and difficult to master.)
5. I’m aiming for something that will run on a broad range of machines. This will be a little tricky, since my current machine is pretty beefy compared to the average. (I’m talking about the average windows-based PC, not the average gaming computer.) It’s much easier to develop on an old machine than to develop on a new one and try to guess where the bottlenecks will appear when run on old hardware. All of our older machines around the house have been converted to Ubuntu, and running under WINE wouldn’t make for a very useful benchmark. So this goal will be difficult to judge. The best I can do is aim for the program running at at least 100 frames per second on my PC and hope that it can still manage 25 or so on an older machine. Even this is pretty dicey, but it’s the best I can do for now.
I don’t know what I’ll do with the program beyond the goals above. Give away the source? Turn it into a screensaver? Add more features? We’ll see where the project takes me and how interesting this is to people.
The first step in a project like this is to make a simple program to open a window, start up OpenGL, and provide some basic camera interface so that I’ll be able to examine my work. This involves gathering up a lot of boring boilerplate code, creating the project files, and adding a bunch of not-very-interesting low-level systems. The result is not very compelling:
Sorry for dragging you all this way only to show you an empty window, but this is how it often goes. I’ll make sure to have something more compelling to show you next time around. This series will run all week, assuming everything goes to plan.
There are two major schools of thought about how you should write software. Here's what they are and why people argue about it.
Pixel City Dev Blog
An attempt to make a good looking cityscape with nothing but simple tricks and a few rectangles of light.
C++ is a wonderful language for making horrible code.
The Best of 2013
My picks for what was important, awesome, or worth talking about in 2013.
Why Batman Can't Kill
His problem isn't that he's dumb, the problem is that he bends the world he inhabits.