前不久用模拟器玩了SFC上的一个经典SLG——圣龙战记后,突然对他出色的表现有了浓厚的兴趣,尤其是在那种硬件平台下,仅仅3M的游戏竟然能够有如此出色的表现!不但是画面表现得极致,而且整个游戏的系统,情节相对当今的大多数游戏来说,实在是有过之而无不及!~实在是佩服万分~!

  确实,现在的硬件条件都比以前好多了,做一个游戏也越来越简单了(虽然我没有在DOS下写过程式,但是经过两年多的编程,对各个方面都有些了解,仍能体会到在DOS下写游戏的痛苦:)), 现在各种各样的游戏研发包也越来越多了,不说别的,就直接用DirectX SDK吧,做一个小的游戏比如飞机类也不会花几天时间(以前我花了3天做过一个^_^),研发简单了,自然有些东西就不那么讲究了,比如说现在的商业游戏的容量,无论是什么都先比光盘多少,您的3CD,我来5CD,除去里面"免费赠送"的一些"原声大蝶" 阿,"官方资料"阿之类的东西,一个游戏至少也有1个G,(大概是现在的硬盘在大家的眼中不怎么值钱了吧,可能商家是这么认为的,也可能是大众心理:东西越多越好嘛:)),真正有用的数据有多少?估计也只有商家才清楚~先不说某些游戏连压缩都没压缩过就裸用一大堆的24Bit BMP( 没错,就是标准的位图)来做游戏中的资源(仅仅做了一个未压缩的资源包,很轻松就能提取出全部资源:)),画面看起来效果好么?确实,但是那没有什么,反正就是美工的表现嘛!还对机器需要至少有PIII 500、128M以上的RAM~真是Faint!

  赫赫,也许大多数人不在乎上面提到的东西~可是作为一个游戏研发者,一个游戏程式设计者,就要在能力范围内对游戏程式做尽可能的优化(先不提商业制作的一些"无奈"的原因的阻碍),就比如说星际,大概是我所见到的PC上的商业游戏中做的最好的一个了:)

  好了,废话了一大堆,下面来谈谈点正式的。
  如今2D PC游戏上,最流行的就是16位色的显示方式(主要是从速度和内存消耗连同显示质量这些方面上来综合),16位色上基本上是565的显示方式(我到现在还从来没有见到一台555显示的机器或一块555的显卡),所以我只讨论16bit下565 模式。

  下面的方法是由于'调色板'而来的灵感~
  (先申明,这种方法绝对不适合主流技术,基于上面我所说的游戏----圣龙战记,能够做类似的游戏~不适合基于象素的游戏,对TILE类游戏比较实用)

  由于TILE类游戏用到的TILE颜色相对都比较固定,颜色种类比较少,所以我们能够选取一个固定的调色板,里面能容纳大部分的TILE颜色,这样任何TILE的数据都能够用这个调色板的索引来表示,当然为了方便,256种颜色最好但是,这样每个点只占8位(也许有人会说,这样不就干脆创建一个8位色的游戏不就行了?嘿嘿,稍安勿躁,马上解释),在内存消耗上就有了很大的优势~假如再压缩一下,嘿嘿........

  从速度上来说,由于游戏里面需要大量的特效,比如最常用的半透明效果,色彩饱和效果、阴影效果、灰度化等等效果,所以从这方面来考虑。

  由于只用到了256色,混合后的颜色也在256种颜色内,所以考虑用查表方式,
  这256种颜色从16Bit 565模式共65536种颜色的色彩空间中提取出来,这样就算是32级的Alpha混合也就只占用256*256*32*8bit=2M的内存。
  但是用16级或12级我就觉得够了,这样就有 256*256*16*8Bit = 1M 或 256*256*12*8Bit = 768K
  色彩饱和表就只需要 256*256*8Bit = 64K

  阴影表也就只要 256*256*8Bit = 64K
  灰度表只要 256*8Bit = 0.256K
  一共加起来也就1M左右,呵呵够少吧!
  如下:
    static unsigned char BDI_AlphaBlendTable[16][256][256]; //16级Alpha混和表
    static unsigned char BDI_AdditiveTable[256][256]; //Additive表
    static unsigned char BDI_SubTable[256][256]; //阴影表
    static unsigned char BDI_GrayTable[256]; //灰度表

  那么,哪256种颜色能够很好的描述大部分图片的颜色呢?
  尝试过几个不同的调色板后,最后发现下面这个调色板效果最好(并且更有附加的优势!稍后看到)
  如下,
    unsigned short wPal[256];
    for(int i=0;i<256;i )
    {
     wPal[i]=i|(i<<8);
    }

  也就是说这个调色板的高8位和低8位是相同的,嘿嘿,想到什么了?(赶快用10秒钟猜猜,下面回答)

  当然这样一来也就不能直接用DirectDraw里面的Blt之类的东西啦~,另外,由于我们的数据保留的是调色板的索引,所以,不能直接Blt到BackSurface上,自己分配一个缓冲区,大小和BackSurface相同大,但是用byte类型就够啦~

  自己写几个Blt吧:

  比如一个Alpha混合的操作:(代码取自我给出的Demo)
void GBDI::DrawToScreenAdditiveSrcColorKey(unsigned char*pBufDest,int nDestWidth,unsigned char*pBufSour,int nLine,int nRow)
{
unsigned char*pDestAddr = pBufDest;
unsigned char*pSourAddr = pBufSour;
for(register int i=0;i<nRow;i )
{
for(register int j=0;j<nLine;j )
{
if(*pSourAddr != m_byColorKeyIndex)
{
*pDestAddr = GBDI::BDI_AdditiveTable[*pSourAddr][*pDestAddr];
//这个地方极大的节省了大量的数学运算
}
pDestAddr ;
pSourAddr ;
}
pBufDest = nDestWidth;
pBufSour = m_nWidth;
pDestAddr = pBufDest;
pSourAddr = pBufSour;
}
}

上面的操作是经过裁减过后的显示,裁减代码如下:

RECT rtDest = {m_position.x,m_position.y,m_position.x pScreen->GetWidth(),m_position.y pScreen->GetHeight()};
RECT rtSour = m_rtShowArea;

文章整理:西部数码--专业提供域名注册虚拟主机服务
http://www.west263.com
以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息,谢谢!