• 优化HGE绘图算法成功了


      HGE的核心绘图算法真是问题多多
      大家有没有发现HGE绘图的时候是很有问题的。

      每画一张图片,就需要从系统内存复制一次数据,最关键的不是数据复制的问题,而是每一次都需要LOCK锁定一次顶点缓冲区进行数据更新。锁定的时候不使用任何标记,那么就强制GPU和CPU同步,带来的是渲染延迟问题。

      最要命的是每一帧都进行从系统内存——显卡内存的操作,如果是网络游戏,每一帧都画上千张以上的图片和阿尔法混合,结果会出现什么??本来顶点缓冲区里面既然已经存在数据,那么在几帧之内,如果数据是不需要更新,就完全可以直接从顶点缓冲区里面读取数据进行绘图。那么这些是GPU的事情,而CPU只是做了很短时间的操作。这种方式才是最合理的。而且我估计所有大型的网络游戏都是采用这种处理方式。根本不可能像HGE那样每一帧的操作。小型游戏是没有所谓的。大型游戏肯定不行。

    所以如果不修改绘图算法,直接采用HGE原来的算法进行游戏开发,那么在大量的图片在每一帧里面进行绘图的时候,肯定会出现各种延迟现象和资源占用的问题。
      (关于顶点缓冲区锁定操作等问题,网上关于D3D编程的资料非常多,如果不了解这些基础的话,就很难理解了)
     
    缓存——真正的意义是保存数据。这些对于有编程经验的人来说,很容易明白它的意义,并且得到极大的利用这些缓存的好处。尤其是显卡内存的缓存,对于存储在里面的数据,肯定得到更快的渲染。
     
      而HGE原来的绘图算法,完全没有发挥顶点缓冲区和索引缓冲区的效能。就好像每一次都从系统内存复制入图片,而没有发挥显卡内存资源池的效能那样。如果像大型的3D网络游戏那样采用这种算法的话,每一次都从系统内存复制入万级面数量的数据甚至是亿以上的数据,(一个人物模型最少2000——3000面,采用索引缓冲区,一个面最少4个顶点),那样不死机才怪。

      今晚刚刚修改完绘图算法。
    基本上,在游戏里面我们是不需要每一帧都更新数据的。如果人物跑动需要每一帧都更新的话,那么一秒的时间内,需要绘制多少个画面,这个人可能不是在跑,而是在飞了。所以无论是人物移动或者释放魔法攻击这些变化都需要在某个时段内才更新不同的画面。就是说,大部分时间内(毫秒级),绘制的画面是相同的。这些相同的数据显然只需要GPU读取缓冲区原来的数据而直接绘制就行,不再需要从系统内存再锁定复制数据。只有发出更新的命令后,才需要重新更新缓冲区的内容。这段时间内,CPU完全可以做其它逻辑上面的处理,这样下一次需要更新的内容就提前做好了。等到更新的时间到了,再一次性复制到缓冲区里面,之后就由GPU来操作了。
     
      绘图算法没有采用HGE原来的架构,而是重新写了渲染和逻辑添加数据函数,图片绘制成功。只需要再细化优化一下就可以大量地批量渲染各种图片数据了。
      目前图片格式还是PNG的,这种格式的图片压缩空间已经不大。迟些再试试TGA格式的图片,这种图片是带通道的。DDS图片格式虽然可以具有很大的压缩比,只是颜色失真也很厉害。BMP和JPG完全不需要考虑。
  • 相关阅读:
    容器网络(一)docker容器网络驱动
    双指针遍历/滑动窗口 —— 209_长度最小的子数组
    双指针遍历/滑动窗口 —— 121_买卖股票的最佳时机
    双指针遍历/滑动窗口 —— 42_接雨水
    双指针遍历/滑动窗口 —— 26_删除排序数组中的重复项
    双指针遍历/滑动窗口 —— 16_最接近的三数之和
    双指针遍历/滑动窗口 —— 15_三数之和
    双指针遍历/滑动窗口 —— 11_盛最多水的容器
    双指针遍历/滑动窗口 —— 3_无重复字符的最长子串
    链表操作 —— 206_反转链表
  • 原文地址:https://www.cnblogs.com/GameDelphi/p/2394717.html
Copyright © 2020-2023  润新知