developer's mag
main page
article
part 1
part 2
part 3
part 4
part 5
part 6
part 7
part 8
part 9
5 - Performance issues
Especially for game design the natural question is, at what level do I program at?From LCD_ through img_ to CWindow, we see the progression of calls, and the extra error checking involved. At this top level, we don't need to initialize and close the display, figure out the number of colors or orientation, clip our drawing, and so forth. Drawing images and text is straightforward. However, does this extra handling code decrease drawing speed?
The answer is not really. Although any additional code will add cycles, in fact the actual percentage is quite small, as the drawing library is very optimized. For a test, I tried to code alternatives to the CWindow code for functions such as shape filling, or copying an image to the display. Under OS 1.0, I was getting speed improvements of 20x. However, the current OS 2.0 is much quicker, and the results were mixed - with some functions slightly faster and some slightly slower. The end result is that, with no effort needed on my part, programs speed up significantly after a recompile, and it would take a great deal of extra effort (most likely with hand-optimized assembly coding) to significantly improve on the operating system's handling of drawing.
Another aspect of the low vs. high level coding issue is portability. If a future ebm model has a 256-color (or gray) display, CWindow code will compile with minimal changes. However, any code that depends on four bits to a pixel will blow up spectacularly, not to mention the code in the hands of your customers will likely behave strangely, requiring a patch or upgrade.
Now that we've looked over the graphics functions and discussed the display, let's investigate a small program with animation to show the details of programming CWindow graphics.
Previous Section
Next Section