Unite 2010GDC ChinaAsia Game Show 2010GDC 2011
|
Window DrawingRecursion is a double-edged sword. It makes the window drawing code very easy to follow, but it also ends up touching pixels twice, which can be a significant performance hit (say, for example, you have a stack of fifty windows, all the same size and at the same screen position - the code will run through the drawing loop fifty times, and touch the same set of pixels fifty times). This is a notorious problem. There are certainly hidden-surface elimination algorithms one could apply to this situation - in fact, this is an area I need to spend some time with on my own code - Quaternion's GUI is most active during the non-game screens (title, closing, etc.), places where it's perfectly OK for the GUI to be a hog, because there isn't anything else going on. But, I am tinkering with it; I'm currently trying to employ the DirectDrawClipper object in my drawing routines. So far, the initial code looks pretty promising. Here's the way it will work: The desktop window "clears" the clipper object. Each window then draws is subwindows backwards, top one first, bottom one last. After each window is drawn, it adds its screen rectangle to the Clipper, effectively "excluding" that area from the windows below it (yes, this assumes all windows are 100% opaque). This helps to ensure that at the very least, each pixel will be touched only once; granted, the code is still churning through all of the calculations and calls required for GUI rendering, (and the clipper's probably got its hands full, too), but at least the code isn't actually drawing redundant pixels. Whether the clipper object operates fast enough to make this worthwhile remains to be seen. I'm tossing around several other ideas, too - perhaps using the built-in z-buffer on the 3D graphics card, or implementing some sort of dirty rectangle setup. If you've got any ideas, let me know; or, try them yourself and let me know what you found. Most of the bulk of the window drawing code I cut out, because it's very specific to my situation (it calls my custom sprite classes). Suffice it to say that once you know the exact screen dimensions of where you're going to draw a window, the actual drawing code is straightforward (and fun) to implement. Fundamentally, my drawing code takes a set of nine sprites - four for the corners, four for the edges, one for the background - and uses those sprites to draw the window. The color sets deserve a small explanation. I decided that each window would have two unique color sets; one set for when that window is active, one set for when it's not. Before the drawing code gets started, it makes a call to getappropriatecolorset(), which returns the correct color set for the window's activation status. Having separate colors for active and inactive windows is a basic principle of GUI design; it was also fairly easy to implement. Now our windows draw, so it's time to start looking at messaging….
|
|
|
|
