The programmer, like the poet, works only slightly removed from pure thought-stuff. He builds castles in the air, from air, creating by exertion of the imagination. Few media of creation are so flexible, so easy to polish and rework, so readily capable of realizing grand conceptual structures. Yet the program construct, unlike the poet’s words, is real in the sense that it moves and works, producing visible outputs separate from the construct itself. It prints results, draws pictures, produces sounds, moves arms. The magic of myth and legend has come true in our time. One types the correct incantation on a keyboard, and a display screen comes to life, showing things that never were nor could be... . The computer resembles the magic of legend in this respect, too. If one character, one pause, of the incantation is not strictly in proper form, the magic doesn’t work. Human beings are not accustomed to being perfect, and few areas of human activity demand it. Adjusting to the requirement for perfection is, I think, the most difficult part of learning to program. | ||
| --Frederick P. Brooks, The Mythical Man-Month: Essays on Software Engineering, Anniversary Edition (2nd Edition) | ||
As time progresses, the technology powering games improves at an exponential rate, and gamers begin to expect more out of a game as each year goes by. Almost all cutting-edge games these days use 3D hardware to render virtual environments that immerse the player in a sort of simulated reality. Earlier 3D games such as Castle Wolfenstein, with its 2D ray caster and vertical scan-line rasterization, were rudimentary enough that simple tools could produce suitable game content. Over the years, the capabilities of computers and 3D hardware have grown considerably, and more complex tools are required in order to produce content suitable for today’s games.
A large number of content tools for game development visualize data using a 3D API, such as Direct3D. These tools require additional consideration and planning in regards to performance and functionality. The chapters in Part III focus on topics such as swap chain management, texture browsing control creation, converting from screen space to world space, and asynchronous input polling to improve responsiveness and performance.
A graphical tool can be anything that visualizes data using some sort of drawing or rendering API, but the majority of these tools are world editors that create environments for games, or are tools that perform some sort of 3D geometry processing to create static assets like radiosity lightmaps or ambient occlusion maps, and visually display the in-process results to the user. These tools must be designed carefully and pragmatically if they are to be of any value to the intended users. Graphical tools are typically processor- and resource-intensive, so more time must be spent developing these tools than any other.
The chapters in this part will cover some common techniques and approaches to problems that exist in the majority of graphical tools.