交流游戏技术开发

bigbook2000

上次给看了网络部分，结果没反应，估计写的不好，呵呵，没关系，继续

[概述]

  NGCore 根据一些自己经验和别人成果，教学式的总结，非常适合进行游戏技术开发交流，不同于简单的Winsock和DirectX的封装，而是将游戏的框架进行了简化，函数调用少，理解起来比较容易，使用起来比较方便。

  NGCore Lib 分为2部分，网络部分和图形部分，网络部分由服务器和客户端2个模块组成，图形部分是2D小游戏的一个简单示意，有些可以参看具体的代码和我的一些文章，欢迎大家能够进行交流。

  本来的代码量不算是很大，但为了一些自己（和周围的一些朋友）利益，部分代码不能公开，但我想如果能够理解，应该可以自己写出来的。

[文件说明]
   
  开发包中包含了所需的运行库，开发库和头文件，服务器和客户端两部分，每部分都有Debug和Release两个版本，后缀d的为Debug版本。图形部分只有debug版本，而且需要安装最新版本的DX9。


\ngcore\dll   ---- 运行库
\ngcore\inc   ---- 头文件
\ngcore\lib   ---- 开发库

\ngcore\dll\gc_core.dll
\ngcore\dll\gc_core_d.dll
\ngcore\dll\gs_core.dll
\ngcore\dll\gs_core_d.dll
\ngcore\lib\gc_img_d.dll

\ngcore\inc\cls_cmd.h       ---- 命令消息类
\ngcore\inc\cls_log.h       ---- 日志类（参考，可以不用）
\ngcore\inc\gc_core.h       ---- 客户端头文件
\ngcore\inc\gs_core.h       ---- 服务器头文件

\ngcore\inc\cls_obj.h       ---- 图形对象文件，这个文件很重要
\ngcore\inc\gc_def.h        ---- 图形对象定义
\ngcore\inc\gc_img.h        ---- 图形对象头文件

\ngcore\lib\gc_core.lib
\ngcore\lib\gc_core_d.lib
\ngcore\lib\gs_core.lib
\ngcore\lib\gs_core_d.lib
\ngcore\lib\gc_img_d.lib

并有一个例子

[附录]
  这里我要特别提到那个cls_obj对象，它是图形部分的核心，所有渲染的对象都是一个cls_obj对象，而且对象之间是有关系的，这种关系是内在的，抽象的，由核心自己管理，不需要开发者来处理。

茹枫

要公开就彻底点。

bigbook2000

呵呵，很公开了，剩下的那点东西就是点体力活

新版本

上面的版本是个交流版，但是没人发表什么看法，所以，继续

这个版本图形部分增加了个时钟处理，也增加了些注释和说明

上传800K上限，还差的远呢

bigbook2000

再自己说一下

上面的版本所有的对象都没有释放，如何释放对象，这里是有一点技巧的

通常情况下，我们在内存中new一个对象，然后调用delete来释放这个对象

但是，如果我们的对象在不同的堆上进行引用，比如，我在dll里new了一个对象，但是我想在调用这个dll的应用程序中释放这个对象，调用delete时便会出现堆异常，反过来一样。

在我的游戏模块中，我用了一个箱子来将所有的cls_obj实例指针放进去，但是这个cls_obj可能是外部应用程序生成的，我无法在我的核心模块中调用delete来帮助开发者释放掉他们所new出来的对象。我只能借助开发者自己定义的函数来释放掉它。那么虚函数刚好能够帮助我来实现这个功能

#define IMP_DEL  virtual void Release( ) { delete this; }

只要开发者在派生cls_obj的时候，声明一下上面的宏就可以了

当然，为了防止这个函数不被重载的情况出现，我将其声明为了pure virtual function

呵呵，正在改进之中

bigbook2000

自言自语的继续 。。。

很多时候，游戏的引擎都不自己去直接管理游戏对象的实例，仅仅提供一套管理游戏对象的机制。这样的引擎，游戏对象都是需要开发者自己来处理，需要他们自己调用初始化函数，游戏退出的时候调用释放函数，游戏的图片等资源，也是需要开发者自己new，自己delete，游戏引擎仅仅把new和delete得过程进行封装。

这样有一个好处就是，游戏引擎不对他所处理的对象进行负责，好一点的引擎，负责将开发者的图片等资源提供送进渲染管道的接口并提供将图片从渲染管道中移出的接口，垃圾一点的引擎，仅仅提供一个渲染函数，什么时候想渲染，只要调用一下函数就可以了。

通用的问题就是，渲染的对象是否有效，都由开发者负责，如果渲染出错了，肯定是渲染对象的实例指针出现问题，这样在C++中是很常见的，经常出现无效的指针，0xC0000005: Access Violation这样的提示，相信使用VC的人不会不熟悉。如果游戏小，那么开发者有能力去排查这个无效的指针并更正，但是，如果资源变得相当复杂，成千上万，想要查找这么一个指针在什么时候失效了，并不是一件容易的事，尤其是游戏程序，每秒渲染几十FPS甚至上百FPS。

我现在提供了这样一个框架，游戏引擎负责管理游戏对象实例指针，我并不希望开发者去访问我的渲染管道，在我的概念中，只要是实例化的对象，就自动放进渲染管道进行渲染，对象被释放，就从自动从渲染管道中移出。这样游戏开发者并不需要去担心：我的对象被释放了但忘了从渲染管道中移出。也不需要去处理生成了一个对象但忘了释放。

要做到这一点，就必须将所有渲染的对象封装起来（这才是真正的对象化渲染），而且要将构造函数和析构函数进行封装，因为我的引擎需要知道对象什么时候生成和释放，不能让开发者自己处理构造函数和析构函数。

有人可能会问，需要渲染的对象可能千千万。但是并不是每个对象都需要渲染的，呵呵，要注意的是，我说的仅仅是需要渲染的对象，不需要渲染的对象就不要生成或者释放掉，或者根本就不是cls_obj的派生类。有可能我这次生成了一个对象，这次需要渲染，下次不需要了，过一会又需要了，那么这种临时关闭渲染的，可以通过可见性等属性来处理。

这样带来的问题是什么？大家可能已经想到了，在渲染的过程中，随着游戏的进行，每时每刻都大量的对象在生成，同时又有大量的对象被释放，这里存在一个效率问题。那么我要说的是，我的这个引擎仅仅适用于休闲小游戏，屏幕上的对象最多也就上千，基本上不会有太大的问题。当然这确实是一个弊端，需要去改进它。我拿出来的原因也就是希望大家能想出更好的办法。

另外还有一点，由于对象的动态变化非常频繁，所有在处理的过程中，可能会出现对象访问冲突的情况，在游戏客户端使用锁是不可想象的，因此，我现在采用了一种带异常的处理方式。这也是一个弊端，如何解决，也希望大家支招。

bigbook2000

新版本

解决了内存释放问题