| |
|
|
||||
![]() |
||||||
| |
|
|||||
|
An Intuitive Improvement For all of these examples, I used an ATI Rage Fury AGP graphics card with 32MB of memory. The PC is a Super 7 homebrew box running an AMD K6-2/400 CPU. This ATI board has an OpenGL ICD (download it from their web site; the driver that comes on the CD is worthless), so this system is no slouch for accelerated OpenGL rendering. The lame two frames per second rendering speed is due to the fact that we are loading the textures from the disk (cache) each time — or is it? Let's see. The next example, REFLECT_DL.EXE, uses display lists to avoid accessing the disk for each texture load. Using display lists is similar to using texture objects in some respects, so let me show you the structural changes made to account for the use of display lists. First, at the beginning of REFLECT_DL.CPP, we declare variables to hold the names of each of seven display lists. // Display list names for each texture GLuint nXray, nLightning, nFall, nCoins, nSand, nEye, nMarble; Next, in SetupRC(), we must allocate room for seven display list names and assign them to each of our numeric variables. Creating a display list is fairly straightforward, so we simply create seven display lists that encapsulate the loading of each texture. Remember that LoadBMP() calls glTexImage2D() for us: // Generate 7 display list IDs // Load the X-Ray texture // Load the Lightning texture... The final change is made to DrawCube(), where we now invoke the display list for each GL_QUAD rather than calling LoadBMP() to read the bitmap from the disk each time. // Front face of Cube On most consumer hardware, the performance increase is marginal at best (up to 3.2 FPS on the test system). As we can see from the frame rate displayed in Figure 2, using display lists for the texture loads saves very little time and has only a marginal performance benefit.
|
|
|