screenres.htm

3D游戏开发领域专家撰写的经典游戏开发启迪性文章之一

        <TR>
          <TD><STRONG>24-bit color</STRONG></TD>
          <TD>
            <P align=center>37.5</P></TD>
          <TD>
            <P align=center>13.4</P></TD>
          <TD>
            <P align=center>*</P></TD></TR>
        <TR>
          <TD><STRONG>32-bit color</STRONG></TD>
          <TD>
            <P align=center>15.7</P></TD>
          <TD>
            <P align=center>10.0</P></TD>
          <TD>
            <P align=center>*</P></TD></TR></TBODY>
</TABLE>
            
<P>* This mode is not available on 2 meg video cards

<P>Hmmm. Our numbers went down again, dramatically in some 
      cases. This is because page flipping forces us to wait for the flip to 
      finish itself before continuing our blits. And since the flip can only 
      occur in the monitor's vertical sync interval, our framerate is slaved to 
      the monitor's framerate. This is why so many numbers repeat themselves in 
      this table : 75.0 is the monitor's refresh rate, 37.5 is half, 15 is a 
      fifth, etc.; with page flipping, the framerate can never be higher than 
      the monitor's framerate. There is a lot of idle being spent waiting for 
      the monitor to &quot;catch up&quot;.

<P>The solution is to use triple-buffering. Triple 
      buffering involves creating a third buffer, a &quot;backup&quot; buffer 
      that we can work with whenever the two other buffers are busy. You can get 
      a detailed discussion of triple buffering here. not available 
      yet</p>
      
<TABLE border=1 borderColor=#ffffff borderColorDark=#808080 borderColorLight=#c0c0c0 width="95%">
        <TBODY>
        <TR>
          <TD colSpan=4>
            <P align=center><FONT size=4><STRONG>Raw DirectDraw Software 
            Blitting Performance, with flipping (triple 
            buffering)</STRONG></FONT></P></TD></TR>
        <TR>
          <TD>&nbsp;</TD>
          <TD>
            <P align=center><STRONG>640x480</I></FONT></H3></TD>
          <TD>
            <P align=center><STRONG>800x600</I></FONT></H3></TD>
          <TD>
            <P align=center><STRONG>1024x768</I></FONT></H3></TD></TR>
        <TR>
          <TD><STRONG>8-bit color</STRONG></TD>
          <TD>
            <P align=center>75.0</P></TD>
          <TD>
            <P align=center>75.0</P></TD>
          <TD>
            <P align=center>*</P></TD></TR>
        <TR>
          <TD><STRONG>16-bit color</STRONG></TD>
          <TD>
            <P align=center>62.1</P></TD>
          <TD>
            <P align=center>*</P></TD>
          <TD>
            <P align=center>*</P></TD></TR>
        <TR>
          <TD><STRONG>24-bit color</STRONG></TD>
          <TD>
            <P align=center>*</P></TD>
          <TD>
            <P align=center>*</P></TD>
          <TD>
            <P align=center>*</P></TD></TR>
        <TR>
          <TD><STRONG>32-bit color</STRONG></TD>
          <TD>
            <P align=center>*</P></TD>
          <TD>
            <P align=center>*</P></TD>
          <TD>
            <P align=center>*</P></TD></TR></TBODY>
</TABLE>

<P>* there is enough video memory on a 2 megs video cards to 
      setup triple buffering in this mode.

<P>Ah, good. Using triple buffering, we we're able to regain 
      most of what we lost, and the speeds we get are comparable to the raw 
      software blit speeds, on the second table. But again, there is a bad news 
      : we can only setup triple buffering in 3 modes! (on a 2 meg video card). 
      In fact, the only mode where we are getting a performance increase is 
      640x480x16; triple buffering is simply not worth it on the 8-bit color 
      modes, where we we're already maxed out in performance.

<P>So what this all means, is that the third table, the 
      slowest table, is what is closest to reality. I'll put it here 
      again so you can get a glimpse of it again:</p>

<TABLE border=1 borderColor=#ffffff borderColorDark=#808080 borderColorLight=#c0c0c0 width="95%">
        <TBODY>
        <TR>
          <TD colSpan=4>
            <P align=center><FONT size=4><STRONG>Raw DirectDraw Software 
            Blitting Performance, with flipping (double 
            buffering)</STRONG></FONT></P></TD></TR>
        <TR>
          <TD>&nbsp;</TD>
          <TD>
            <P align=center><STRONG>640x480</P></TD>
          <TD>
            <P align=center><STRONG>800x600</P></TD>
          <TD>
            <P align=center><STRONG>1024x768</P></TD></TR>
        <TR>
          <TD><STRONG>8-bit color</STRONG></TD>
          <TD>
            <P align=center>75.0</P></TD>
          <TD>
            <P align=center>75.0</P></TD>
          <TD>
            <P align=center>37.5</P></TD></TR>
        <TR>
          <TD><STRONG>16-bit color</STRONG></TD>
          <TD>
            <P align=center>37.5</P></TD>
          <TD>
            <P align=center>37.5</P></TD>
          <TD>
            <P align=center>9.1</P></TD></TR>
        <TR>
          <TD><STRONG>24-bit color</STRONG></TD>
          <TD>
            <P align=center>37.5</P></TD>
          <TD>
            <P align=center>13.4</P></TD>
          <TD>
            <P align=center>*</P></TD></TR>
        <TR>
          <TD><STRONG>32-bit color</STRONG></TD>
          <TD>
            <P align=center>15.7</P></TD>
          <TD>
            <P align=center>10.0</P></TD>
          <TD>
            <P align=center>*</P></TD></TR></TBODY>
</TABLE>

<P>* This mode is not available on 2 meg video cards

<H3><FONT COLOR=YELLOW><I>The Conclusions</I></FONT></H3>

<P>Stay away form 24/32-bit...

<P>24-bit and 32-bit take a lot of CPU power, so they're not ideal choices 
      for a game's screen resolution. But there's an even better reason not to 
      use 24 and 32-bit : some video cards support 24-bit, others support 
      32-bit, but few support both modes. And I'm talking mainstream cards here, 
      here are some results from the ScreenBench survey:

<BLOCKQUOTE>
        <P>Videocards that support both 24 and 32-bit</P>
        <UL>
          <LI>Matrox Millenium I &amp; II 
          <LI>Matrox Mystique 
          <LI>ATI Expert@Play </LI></UL>
        <P>Videocards that support 24-bit only</P>
        <UL>
          <LI>S3 Virge 
          <LI>Intel740 (EON)* </LI></UL>
        <P>Videocards that support 32-bit only</p>
        <UL>
          <LI>S3 Trio 64V+ 
          <LI>S3 Vision968 64bit DAC 
          <LI>Diamond Viper 330 
          <LI>Creative Labs Graphics Blaster Riva TNT 
          <LI>Unbranded AT25 + Voodoo Rush </LI></UL>
        <P>*This odd card reports 40 megs of video memory, which is 
        impossible... Intel has been known to play make-believe tricks before, 
        dunno what this is all about here though.
</BLOCKQUOTE>

<P>So, basically, if you want color depth higher than 16-bit, you'll 
      pretty much have to implement both 24-bit and 32-bit, 
      otherwise your game will run only on a subset of cards. I believe this is 
      what Baldur's Gate is doing : the games graphics are in 
      16-bit, and special effects can be rendered in 24 or 32-bit, depending on 
      your videocard.

<P>32-bit = lots of wasted bandwidth...

<P>Many people believe that 32-bit has higher visual quality than 24-bit. 
      This is absolutely false : 32-bit has the same visual quality as 
      24-bit. The only difference between the two is that 32-bit has an 
      extra byte per pixel, which is often used for alphablending, but you could 
      use it for anything you want. But in a real-time game situation, there is 
      simply no use in slowing down all of your game simply to get an extra byte 
      of information on each pixel, unless you have no choice (i.e. you want 
      24-bit but the videocard only supports 32-bit).
      
<P>24-bit is only attainable in 640x480, with optimization...

<P>The only mode where 24-bit achieves good performance is 640x480; at 
      800x600 it's too choppy. I have not seen any 24-bit graphics game yet, for 
      many good reasons : the increase in visual quality from 16-bot to 24-bit 
      is not as noticeable as from 8-bit to 16-bit, and 24-bit graphics take a 
      huge amount of space in memory. The fact that many videocards don't even 
      support is also a big reason why I advise you to stay away from 24-bit.

<P>16-bit is good in 2 modes, with optimization...

<P>640x480x16 is certainly a valid choice, and many commercial games are 
      now coming out with 16-bit graphics : Baldur's Gate, Get Medieval, etc. 
      800x600x16 is a bit heavier, so you may be a bit short on CPU juice is you 
      implement a CPU-intensive AI or an isometric map. 16-bit graphics require 
      good optimization to be able to handle more heavy duty thinds like 
      alphablending, shadowing, etc. 16-bit is pretty much &quot;we're it's 
      going&quot; - but if your game has other tasks besides graphics that may 
      require a good deal of CPU juice, don't be afraid to fall back on 8-bit 
      graphics.

<P>8-bit is safe, in any mode...

<P>8-bit is safe; slim and fast in all screen resolutions. You'll have to 
      put in a little extra effort to handle palettes, but it's well worth the 
      effort. You'll have plenty of breathing space with 8-bit graphics, and 
      you'll get good performance even if your game doesn't implement all the 
      latest optimization tricks. A good graphic artist can draw 8-bit pictures 
      that will fool you into thinking they are 16-bit or higher; it's all a 
      matter of choosing the right palette colors. I thougth Diablo was 16-bit 
      for some time until I took a screenshot and realized the file had been 
      saved as 8-bit color bitmap. 8-bit graphics are great for games that do a 
      lot more than just display pretty pictures ;-).

<H3><FONT COLOR=YELLOW><I>Considerations</I></FONT></H3>

<P>All the numbers discussed here are theorical numbers; the Screenbench 
      program does not play any sounds, it doesn't do any pathfinding, it 
      doesn't have an AI. Plus, your game may have more than 1 screen to refresh 
      at each frame : since some pictures obviously cover up each other, your 
      game will most likely blit something like one screen and a half at each 
      frame. So don't be ashamed if your numbers aren't that high - in many 
      cases, those framerates aren't attainable in a game, not wihout a great 
      deal of optimization. The numbers here are numbers to aim for - if your 
      game's framerate is close to the framerate given by Screenbench, then 
      congratulations, you can say your game is running at top notch 
      performance.

<P>That being said, when beggining your game project, you should evaluate 
      if your game will do any heavy processing besides graphics, and choose 
      with this in mind. The type of view your game uses also has a great effect 
      on performance:

<UL>
        <LI>2D top down maps are generally easy to implement 
        and provide very good speeds. There are ways to optimize maps so they 
        really run at their top speed, but this is out of the scope of this 
        article. 
        <LI>2D isometric maps take up much more juice than 
        simple top down maps. This is because of the non-squared shape of the 
        tiles : transparency has to be enabled for those tiles, bringing 
        performance down. 
        <LI>2D isometric maps &quot;with height&quot;, like 
        those in Age of Empires, take up even more juice, because there are many 
        layers of tiles to build. Will need plenty of optimization to work in 
        16-bit. 
        <LI>3D is the most CPU-intensive view; but video cards 
        are taking up more and more of the work, changing the rules of the game. 
        This is why the game market is currently being broken up in two : games 
        that don't require 3D cards, and games that do.
</UL>

<H3><FONT COLOR=YELLOW><I>A question of market</I></FONT></H3>

<P>Unless you're writing your game that is only meant for your own 
      personal enjoyment, ideally you want your game to be played by someone 
      else. This means that someone, somewhere will have to enjoy your game 
      enough to shell the thirty to fifty bucks to buy it. But there's a good 
      chance that no one will find your game enjoyable if it's playing at one 
      pixel per hour on their machine. This is the bottom line when choosing 
      your screen resolution : you can choose anything you want, but aiming for 
      the lowest common denominator will give you a lot more exposure.</P>

<!--Bottom Navigation-->
<A NAME="bottom"></A>
<!--End Bottom Navigation-->
</STRONG>
</FONT>
<!--End Body-->
<!--Bottom-->
<BR>
<IMG SRC="gradbar.jpg">
<BR>
<FONT SIZE=2 COLOR=#8B8B8B FACE=Helvetica>
<I><font color="#FBFBFB">T</font><font color="#F7F7F7">h</font><font color="#F3F3F3">e</font><font color="#EFEFEF"> </font><font color="#EBEBEB">G</font><font color="#E7E7E7">a</font><font color="#E3E3E3">m</font><font color="#DFDFDF">e</font><font color="#DBDBDB"> </font><font color="#D7D7D7">P</font><font color="#D3D3D3">r</font><font color="#CFCFCF">o</font><font color="#CBCBCB">g</font><font color="#C7C7C7">r</font><font color="#C3C3C3">a</font><font color="#BFBFBF">m</font><font color="#BBBBBB">m</font><font color="#B7B7B7">i</font><font color="#B3B3B3">n</font><font color="#AFAFAF">g</font><font color="#ABABAB"> </font><font color="#A7A7A7">M</font><font color="#A3A3A3">e</font><font color="#9F9F9F">g</font><font color="#9B9B9B">a</font><font color="#979797">S</font><font color="#939393">i</font><font color="#8F8F8F">t</font><font color="#8B8B8B">e</font> -