【DND】【01】游戏引擎构想和基本工具设想01
我打算写一系列的文章来诉说我的游戏引擎，由于本人比较懒，没有动力写文档和注释包括策划规划等等，就由此来涵括吧。首先此引擎的名字是DNDEngine，就简称DND吧。由于对3d游戏编程不是特别熟悉，建模也很困难，所以DND是2D游戏引擎（好像说了废话）。由于本人长期使用windows操作系统和VS2010盗版旗舰版，导致只熟悉windows平台下的编程，所以引擎使用了directx9.0（传统管线）和windows平台下的库函数。所以要配置环境并编译的同学请自行下载dx9（a5另有帖子提供下载），这并不是研究dx，所以暂时不说这个了，先说说游戏引擎的框架。首先有个DNDCore单例类，此类暂时实现以下功能：
=======================
_init_direct 初始化d3d9（强制开启垂直同步60fps）
Create_Window 创建窗口（此窗口包含标题，图标，最小化按钮，关闭按钮，有边框，固定大小）
Start_Framefunc 进入指定帧函数（开始游戏循环）
End 结束程序
=======================
现在我们思考一下该怎么实现高效的绘四边形图片！这是个很严重的问题，从d3d的角度看：
为了实现缩放，旋转，翻转最方便的还是纹理映射。所以需要先创建4个顶点，6个索引形成一个矩形，绕序如下：
http://www.0xaa55.com/forum.php?mod=image&aid=3244&size=300x300&key=12fb4eafd6fb6a9a&nocache=yes&type=fixnone（卧槽这么小，点开看吧）
这样纹理（一张图片，或者图片的一部分）就被拉伸映射到四个角上面了。例如图片的旋转，拉伸，缩放，翻转等其实都通过改变4个点得位置来实现得，这就是我们的绘制图片的方式，但是如果只简单的暴露接口，那游戏中的很多功能就需要用户（程序员用户）自己实现，他肯定会大骂这个引擎的作者。我觉得这一系列的封装抽象才是真正重要的。所以下面来谈谈这一部分。
我们有一个类，叫做DNDTexture，用来代表一张图片，肯定的，这张图片是方正的，有宽度和高度。现在为DNDCore添加一个函数：
=======================
Create_Texture_With_File 从文件加载纹理（返回DNDTexture指针类型）
=======================
在hge引擎中，只有一个默认的顶点缓冲流，对于用户（程序员用户）是不可见的。这就导致纹理的变更，就需要调用direct的setTexure，这样就不可能一次绘完一个顶点缓冲流，效率上就会打折扣。
包括世界坐标变换，改变顶点索引，设置裁剪区域，都会中断批量绘制。所以我想的办法是将其容纳成一个整体，抽象成一个虚基类DNDBatch，用来批量绘图，一些属性相同的东西可以成为一个整体：
包含成员：
DNDCoorSys 坐标系（设置绘制时的世界矩阵。坐标系之间具有父子关系，可以多层嵌套，实现层的效果）
DNDClip4V 4边形裁剪 （裁剪并不好嵌套，目前为止没想到办法）
除了DNDBatchDot，DNDBathcLine以外的DNDBatchQuad（四边形批量绘制）还具有纹理成员：
DNDTexture 大图纹理
那么DNDBatch怎么使用呢？大概如下：
现在我们又给DNDCore添加了一个函数：
=======================
Create_Batch_Dot 创建一个点批量绘制（参数有最大点数，order（绘制顺序），裁剪区域，坐标系）
=======================
假设返回的是dot变量，这个dot就相当于点的容器，里面存储了每个点的信息。添加点的信息后，将此变量提交给DNDCore的某个函数执行绘制即可。这样的好处是将所有绘图分成各个小部分，可以执行批量绘图。将静态物体和动态物体分离开来，整体改变位置的物体可以直接改变Batch的坐标系，静态的物体就无需改变。这样Batch里的顶点并不需要解锁更改值，意味着减少了和显卡的交互。而对于独立随时都变化的物体呢？有如下两种情况：
1.颜色变化
2.位置变化
第一个是颜色，比如说游戏里面一个单位中毒后呈现绿色，这时候最简单的方法是改变顶点颜色（由于不需要每帧都变化所以效率影响不大）；还有一种是直接更换纹理，比如对纹理处理后的纹理，最常见的是彩色转灰度图，高斯模糊等等，前面的颜色叠加也可以实现，但是没有必要用此方法。其次是位置，角色移动是很常见的事，到底是每一个角色一个Batch，还是即时改变顶点的位置呢？我想了很久还是认为后者为好（很纠结）。
基本绘图方法给出后，我们应该在之上再写一个DNDSprite类。来更加抽象的表示游戏物体，包括了Box2d实现的碰撞功能。（我考虑后认为，碰撞检测和拾取应该合二唯一，虽然物理引擎不能响应基于像素的碰撞反馈，而拾取可以。由此干脆不提供基于像素的拾取）（更加利于精灵编辑器的实现= =）。
未完待续（之后是动画，音效，视频，文件，字体的简要介绍。完毕后再是单独的细节说明）
16-2-2
前排支持~~ 顶贴!!!!
页:
[1]