略游 发表于 2016-2-2 22:30:19

【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






0x01810 发表于 2016-2-3 09:15:55

前排支持~~

账号已注销 发表于 2016-2-17 16:37:18

顶贴!!!!
页: [1]
查看完整版本: 【DND】【01】游戏引擎构想和基本工具设想01