I became interested in programming computer games in the 1990's while teaching an undergraduate course in Computer Graphics. Students seem to lack enthusiasm for the mathematics of graphics and I realized that by using game programming I could enliven the mathematical material. This turned out to be the case and students wrote several interesting games, including Paintris by Pedro Sanders that was a variation of Tetris using paint buckets as the dropping objects. I gave a presentation on "Teaching Graphics Through Video Games" in the SIGGRAPH'97 educator's program. (A summary can be found in the August 1997 issue of Computer Graphics, pp.56-57.)
At that time we were using Unix and the unwieldy X Window System. I had written a Starter Toolkit that simplified the use of the X Window System, so students were shielded from the horrors of X. (I gave a presentation "`How to Teach Graphics Using X (and Live to Tell About It)'' in the SIGGRAPH'96 educator's program, summarized in the August 1996 issue of Computer Graphics, pp. 41-42.) Some of the students wanted to use their PCs and they wrote a version of the Starter Toolkit and they wrote a version of the Starter Toolkit for Microsoft Windows. That made porting games between platforms quite easy. A student would develop the game on a PC and the code would be recompiled on Unix and tested by the instructor.
All this came to an end in 2000 when I took a terminal leave in anticipation of my retirement from Stony Brook University. The terminal leave almost turned out to be truly terminal - I developed heart problems and in October of 2000 I had open heart surgery that, fortunately, was a success. Still my health problems were enough of a disruption that a lot of the material related to the graphics course was not properly preserved. In January 2001 I joined Symbol Technologies which put me even further away from the graphics course. I left that company in the middle of 2002 (see Symbol Story) but by that time game programming had receded far in the background.
I became again interested in game programming because, being fully retired, I had plenty of time in my hands. I started by reverse engineering some games that I liked except for a few features that I removed in the versions I wrote. (Sorry folks, no samples of such work can be posted. I do not like letters from corporate lawyers.) Eventually I realized that game programming would be good training for programmers because it incorporates so many elements of modern programming, such as event driven programming, multithreading, and animation. Games also offer a challenge to portability of software. While the "logic" of a game can be written in a platform independent way, it is hard to do the same for the user interface. The design challenge is to organize the code in such a way that there is a clean interface between the two parts in order to simplify porting.
My concern about portability dates back to the time I joined Bell Labs in 1980. One of the first projects I worked on was an enhancement of PLOT, the Unix portable graphics package. We had four test devices: a character terminal, a CRT graphics scope (yes, folks these are ancient devices but we talk about a quarter of a century ago), the TROFF phototypesetter (1000 dpi) and a raster graphics device (those had just made their appearance in affordable prices). There were several challenges and eventually we gave up. One problem is whether to take advantage of device capabilities. We could implement only low level functions, so that to draw a curve the application would have to provide the x,y of the points, quite portable but ugly and wasteful. Or we could implement high level functions, but then we would limit the applications writer since we could not possibly anticipate all high level that some one might need. Combinations are possible, but we could not find a completely satisfactory solution.
The portability task becomes easier if we limit the type of devices under consideration, but problems still persist. One can see these problems by examining Microsoft's GDI. They do a poor job on curves - they have Bezier splines, a weak choice. (The number of control points on the curve must be of the form 3N+1). In Unix curves were quadratic guided splines that could have any number of control points!
Semi-transparent objects offer another challenge to portability. If the display device has an alpha channel (usually 32 bits/pixel) and the proper software the task is simple. (See Section ___ of the tutorial.) But what are we to do in an 8 bit/pixel display? We can give up color and use all bits for gray scale in which case we can create the semi-transparent effect (also with a lot of extra code to simulate the alpha channel). Or we can keep the color and give up the semi-transparent effect. Either way straightforward porting is not possible.
| theopavlidis.com | Site Map |