游戏系统线程和线程池的重要性
摘要：我们知道毫无节制地申请内存和释放内存，必定会导致系统内存碎片剧烈地增加，最直接导致的后果是系统内存资源枯竭，游戏状态越来越慢，各种反应不及时，各种未知错误层出不穷！ 直到现在，我发现游戏变慢，很多人都归结为客户端的问题，其实啊，更多的问题出在服务端上面。当然还有一部分原因在于逻辑的不合理。客户端和服
阅读全文
posted @
2017-12-05 07:35
一笑如风
阅读(949)
推荐(0) 编辑
游戏系统的稳定性能
摘要：这段时间都是在重构系统数据模块。懂的朋友自然知道，什么才是系统最至关重要的部分！不懂的朋友只会关心程序的功能有多么的牛逼！去，这都是垃圾，不提！ 数据结构就是一个一个系统模块，如果整个系统都是由各个模块链接构成，那么这就形成一个更加稳定的大型游戏系统。 如果某一个环节出了问题，就直接查该环节，而不影
阅读全文
posted @
2017-11-30 23:45
一笑如风
阅读(473)
推荐(1) 编辑
全局变量的带来的焦头烂额
摘要：大量大量的全局变量，大量大量的各种麻烦............................ 很奇怪为什么没有人感到这些麻烦，当然了，Delphi 2007不会让人感觉到这些麻烦，甚至完全可以写出各种奇葩的代码，而不担心编译器报错，当然了，各种潜伏的麻烦还是会大量大量的存在。 真的，有一些还是系统
阅读全文
posted @
2017-11-07 01:41
一笑如风
阅读(410)
推荐(0) 编辑
目前HGE客户端里面的绘图机制
摘要：算是整明白HGE底层绘图机制，里面包含了两种后备缓存的方式，一种是常规的那种后备缓冲，另一种，里面采用了渲染到目标的方式。 渲染到目标纹理，除了创建一张大的纹理之外，另外还需要搭配一个缓存区。这是流程中的设置，没有什么好说的。 实际上，这样一来可以把纹理按照默认方式，创建到显示内存里面，没有这种设置
阅读全文
posted @
2017-11-05 00:36
一笑如风
阅读(842)
推荐(0) 编辑
关于引擎代码从Delphi 2007 升级至Delphi 10.1的一些历程
摘要：代码升级确实很麻烦，不是一般的麻烦。 因为需要整理出一套配合我自己写的D3D绘图引擎，所以我选择了以前的IGE作为项目的开端。原因很简单。因为现在的那些源代码是无法完成这个工作的。 而且如果有了一套完善的基础版本，那么以后无论想改成啥都容易得多。 说说绘图引擎，目前HGE算是主流吧，其实这是大家没有
阅读全文
posted @
2017-10-31 14:49
一笑如风
阅读(1439)
推荐(1) 编辑
HGE核心绘图解决方案
摘要：在【【HGE】绘图底层】这个帖子里面有些地方需要更正。 为了不误导别人，这里有必要补充一下： HGE每次绘图都需要锁定一次缓冲区，只适合绘制大量相同的图片，如果是各种不同的图片，问题就出来了。如果绘制一百张图片就需要锁定和解锁各一百次。了解D3DAPI编程的人明白这是个什么问题。所以现有的HGE绘图算法是完全不适合大型游戏的。 有些人看到HGE自带例子中绘制2000个sprite FPS达200-300以上就以为是正确的，不要忘记绘制的图片都是同一张图片。这个问题是网上一位朋友首先发现的。 这里给出解决方案： 首先删除HGE原有的渲染函数，一个都不要留。 然后制作出一个添加数据...
阅读全文
posted @
2012-03-19 21:07
一笑如风
阅读(3916)
推荐(0) 编辑
优化HGE绘图算法成功了
摘要：HGE的核心绘图算法真是问题多多 大家有没有发现HGE绘图的时候是很有问题的。 每画一张图片，就需要从系统内存复制一次数据，最关键的不是数据复制的问题，而是每一次都需要LOCK锁定一次顶点缓冲区进行数据更新。锁定的时候不使用任何标记，那么就强制GPU和CPU同步，带来的是渲染延迟问题。 最要命的是每一帧都进行从系统内存——显卡内存的操作，如果是网络游戏，每一帧都画上千张以上的图片和阿尔法混合，结果会出现什么？？本来顶点缓冲区里面既然已经存在数据，那么在几帧之内，如果数据是不需要更新，就完全可以直接从顶点缓冲区里面读取数据进行绘图。那么这些是GPU的事情，而CPU只是做了很短时间的操作...
阅读全文
posted @
2012-03-13 22:02
一笑如风
阅读(3464)
推荐(0) 编辑
HGE——重新编写HGESprite接口和字体接口
摘要：重新编写了HGESprite部分，不再使用HGESprite单元。 另外编写了一个HGECanvas单元，当然不是那个火人论坛上面的那个HGE加强版的那个。 参考ID3DSprite接口的做法，使用一个接口对象，就可以批量绘制所有的图元。 不需要创建多个接口对象。同时添加了纹理列表来管理显卡内存里面的纹理指针。 完全按照网络游戏的做法，加载完成硬盘自定义格式资源文件包后，产生所需要的显卡内存纹理对象，就可以释放系统内存，使系统内存占用相当低。 开始绘图的时候就由显卡内存读取，由GPU来进行绘制。这样使CPU和系统内存资源极大地解放了。 D3D编程最爽的地方是不需要经常从系统硬盘...
阅读全文
posted @
2012-03-07 00:01
一笑如风
阅读(3132)
推荐(0) 编辑
HGE继续修改绘图底层
摘要：HGE的基于帧回调的机制，而且还是基于Windows消息的回调机制，了解Windows消息的人应该明白，这样肯定不行。因为Windows消息有阻塞的情况存在等等问题。 测试了一下，当HGE窗口显示的时候，图片绘制还是很明显看出来绘制的过程，闪了一下才绘制上去。当拖动窗口的时候，痕迹的清除也很缓慢。 简简单单绘制一张图片，CPU占用达45%以上，跟我采用基于Main入口函数直接绘制完全不是一回事。看来还得继续改造这部分结构。 另外当时改造HGE的时候，发生了窗口无法注册的问题，这个时候才明白delphi的uses部分的单元文件是从左到右检测编译的，因为当时的情况是这样的：uses ...
阅读全文
posted @
2012-03-02 13:57
一笑如风
阅读(1367)
推荐(0) 编辑
HGE DirectX9.0C版本修改已经完成，发图祝贺一下。
摘要：完全DirectX9.0C改造，并且修改了资源载入部分。完成的效果如下图： 图片格式是：png，当然完全可以加载任何DirectX9支持的图片格式。而且资源文件也不需要特地指定封包为那种格式的图片文件。 网上也有HGEDx9的单元文件，这个文件挺搞笑的。RHW常量格式和灵活的顶点格式是不能够共存的，而且HGE在初始化设备的时候就已经设置了投影矩阵，这个时候绘制的顶点数据投影在屏幕的时候就已经是二维的。DX8和DX9还是有很多不一致的地方。两种版本混用是非常非常容易出问题的。 当然距离达到：网络游戏——降龙之剑的效果还是有一段路要走的。我指的是他的基本画面效果，其实它的色彩方面还是有问题的...
阅读全文
posted @
2012-03-01 19:44
一笑如风
阅读(3062)
推荐(0) 编辑
HGE重新架构资源管理
摘要：在HGE1.81版本开始修改结构。为什么不在HGE加强版本上面修复，原因很简单，这个版本的作者D3D功底一般，封装方面的技术一般。不但没有使引擎更符合大型游戏的开发，而且使很多方面搞得相当复杂。不利于引擎的以后强化。所以最理想的还是从官方的原版开始修改引擎基础部分。使之更符合大型游戏的开发。资源管理方面，HGE提供了一个从Zip压缩文件加载的接口类。其实任何一个商业游戏都是不可能使用Zip压缩文件作为客户端图片资源文件的。因为大家都是使用了各自的自定义文件格式资源文件。Zip压缩文件适用于补丁的更新。但是目前主流的做法好像已经改变。使用了微端技术。其实说白了，就是玩家一边玩游戏一边下载客户端资
阅读全文
posted @
2012-03-01 02:21
一笑如风
阅读(2280)
推荐(0) 编辑
【HGE】绘图底层
摘要：HGE是基于DX8.0的二维游戏引擎，多年没有更新了。而我们知道Dx8.0跟DX9.0C是不同层次的。其实基本绘图逻辑差别不是太大，只是性能方面肯定不在一个水平上面。让我感觉很大困惑的是，HGE的绘图结构效率到底适不适合即时大型网络游戏渲染？因为它的绘图逻辑是基于以前的DX7.0的绘图思想。先分析它的架构： 1 (* 2 ** HGE Primitive type constants 3 *) 4 const 5 HGEPRIM_LINES = 2; 6 HGEPRIM_TRIPLES = 3; 7 HGEPRIM_QUADS = 4; 8 9 (*10 ** HG...
阅读全文
posted @
2012-02-18 21:45
一笑如风
阅读(4701)
推荐(0) 编辑
