-
Notifications
You must be signed in to change notification settings - Fork 65
/
dev.log
161 lines (113 loc) · 11.6 KB
/
dev.log
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
# 关于 Korok
Korok 取自塞尔达传说里面的森林精灵，在我的最初计划里面这应该是一个面向组件的简单易扩展的2D游戏引擎，引擎的设计启发自：bitsquid.blogspot.com 。
在一般的游戏引擎中都会有游戏对象的概念，比如：Unity 的 GameObject，Cocos2D 的 Sprite，在 korok 里面，是没有这个概念的，它的本质是一个ECS系统，GameObject
是通过一个 id索引各种相关组件组成的，现在设计了几种组件：
1. RenderComp 渲染一个可渲染对象
2. Transform 负责坐标和场景图
3. Animator 动画控制器
3. SourceComp 负责音频
--七夕的第二天
操千曲而后晓声，观千剑而后识器。在之前的设计中，渲染引擎的基础架构设计的不够好，导致后面的系统集成变得艰难。在阅读了大量的开源游戏引擎的渲染系统代码之后，对基础图形API接口的设计
有了新的想法。这样的API符合的特征是：
1. 无状态渲染提交(stateless)
2. 基于排序渲染(sort-based)
3. 易于实现多线程(multi-thread)
4. 兼容新的图形API
这部分的底层API，实现在 `gfx/bk` 叫做 'bk-api'。目前版本的实现搭建了基本的API框架，排序，多线程等暂时都没有实现。但是架构在此，以后添加上这些并非难事。
从现在的观点看来，这种API设计是比较主流的底层图形API设计方式，Ogre3D/Paradox/BitSquid 等大型3D开源引擎都采用了这种设计，此处的设计借鉴了 bgfx 的实现，可以说
是一个简版的 bgfx，但是移除了 bgfx 里面大量的资源管理功能。
--国庆的第二天
基于 bk-API，分别实现了一个用于渲染简单网格的 MeshRender 和 一个用于批量精灵纹理渲染的 BatchRender。Korok 的 Batch 系统，底层维护了8个VBO，最多可以生成128个Batch分组。
Batch接口采用了一个半自动的方案：提供一个 batch-id 字段，如果用户把一组图元标记为相同的 batch-id，那么他们可能会被batch在一起。还有另外两种常见方案：
1. 使用 SpriteBatch 提供手动的 Batch 接口
2. 引擎检测材质，自动根据不同材质进行合并
第一种略显过时，第二种常常会造成困扰，比如我们认为应该batch的场景却没有batch。而korok中采用半自动的方案，可以在无法batch时做出相应的提示，并且尽量按照用户希望
的方式batch，或许能提供更好的开发体验。
--2017/10/06
音频系统暂时可以工作了，这部分api实现在 `audio/ap` 叫做 'ap-API'。这是一套非常底层的API具体负责：
1. 统一的资源管理
2. 播放优先级决策
音频格式(编解码)的支持在 `audio/xx` 目录下实现，这里有两个已经支持的音频格式:wav 和 ogg. wav 一般用来测试和播放占用内存较少的音效，ogg 用来播放背景音乐之类。
此处并不打算支持 mp3 格式，相较来说无论文件大小还是保真程度 ogg 都是优于 mp3 的，所以应该尽量用 ogg 格式来编码游戏音频。编解码模块和底层音频播放系统是完全分离的，
我们通过上层 API 来配置音频的编解码，相互之间通过接口依赖，这样方便以后添加更多音频格式支持。
音频管理（内存管理）和播放部分还有一些功能没有实现(TODO)。
--2017/10/14
在 `gfx/dbg/` 目录下实现了 debug 绘制功能，这这种功能通常用来显示一些debug信息，比如fps,GPU和GPU状态监控等。目前可以用来在屏幕上打印矩形和字符串，这是一个自包含的
模块，可以说是一个微型的渲染系统，它不依赖GUI，也不依赖于引擎的渲染系统（直接基于bk-API）实现。我们的API使用了 *ImmediateMode GUI* 设计，这种 API 接口简单，却能够
实现强大的功能，对于打印一些临时信息来说再好不过，下面是一个段示例：
```
func OnLoop() {
// draw something...
dbg.Move(50, 50)
dbg.Color(0xFFFF0000)
dbg.DrawRect(0, 0, 50, 50)
dbg.Move(300, 50)
dbg.DrawStr("fps:60000!!")
// advance frame
dbg.AdvanceFrame()
}
```
-- 2017/10/17
Korok的最终架构这几天确定了 - Comp/Table/System，我们的所有数据采用类似数据库表的概念来管理，所以对一个组件的增删改查类似于表的CRUD操作。我们的底层引擎也会使用同样的接口来操作数据
比如SpriteComp/MeshComp的各自存储在自己的表中。渲染引擎在渲染的时候也是读取当前的表查出所有可渲染对象然后再做绘制。此次没有功能上的更新，大多是运行时系统的重构，但是却
很重要，因为这次我们确定了整体架构和设计哲学，这会直接影响到以后的系统设计/开发。
-- 万圣节的第二天 🎃
可见性系统的设计还是很不完善，而且也没有太好的想法，暂时去掉这个功能，这样可以继续完善渲染系统。目前渲染系统的把Feature和Render分开了，Render是可以复用的基于
Shader的渲染工具，Feature是具体的渲染类型，比如SpriteComp/TextComp.. 它们都可以用BatchRender来渲染，只是使用上有细微的差别。由于 Golang 不支持泛型所以
只能采取间接层的方式--既Feature，来实现差异部分的功能。
-- 2017/12/04
当前已经可以使用 MeshComp 来渲染网格，用 SpriteComp 来渲染精灵图片，从接口API道底层渲染系统联调通过。中间写了一些临时代码，以后会去掉。批量渲染精灵的API如下:
```
id, _ := assets.Texture.GetTexture("src/main/assets/ball.png")
for i := 0; i < 50; i++ {
face := korok.Entity.New()
korok.Sprite.NewComp(face, assets.AsSubTexture(id))
faceXF := korok.Transform.NewComp(face)
x := float32(rand.Intn(480))
y := float32(rand.Intn(320))
faceXF.Position = mgl32.Vec2{x, y}
}
```
今天是个值得庆祝的日子！😊
-- 2017/12/07
重新组织了包名和域名，现在可以使用 `go get korok.io/korok` 来下载引擎了(还没有启用HTTPS，需要加`-insecure`标记).
-- 2017/12/12
设计了粒子系统的初步版本，粒子系统通过 ParticleComp 提供，每个 ParticleComp 都可以设置一个仿真器 - Simulator, 它的实现决定了
具体的粒子效果。仿真部分采用 Pool + Channel + Simulator 组合实现，渲染部分参考 Xenko 的实现申请一个足够容纳所有粒子的VBO来渲染粒子
(注意：大部分引擎是每个系统对应一个VBO)，具体渲染使用的是 MeshRender，当前的代码仅仅验证了想法和一个可以工作的仿真器，接下来会优化接口。
-- 冬至
现在正在一步一步的实现GUI系统，现在的GUI系统主要参考了 dear-imgui 的设计，比如形状的绘制算法，文字渲染等。区别于 imgui 是
我们的设计是分层的：drawing/ui2d/window， drawing 模块负责最底层的UI元素渲染，并生成顶点数组，这样可以使用 gfx 模块的 api
把顶点渲染到屏幕，ui2d模块负责提供ui元素，比如:button/text/image 组件，window 模块在最上层用来实现窗口系统。当然这是一个比较
理想的设计（这个设计也受到了 [OurMachinery](http://ourmachinery.com/)的影响）。
-- 2018/01/05
这段时间主要尝试实现动画系统，并且实现GUI布局和动画，动画系统实现三个子模块：骨骼动画/帧动画/补间动画，这个系统实现的不是很满意，以后
可能会有大的改动。其次就是GUI，IM-GUI并不擅长布局和动画，尝试了诸多方案，比如类似flatui的2-pass方案等，最后采用的方案是在前一帧缓存
UI元素的大小，这样在下一帧的时候可以用这些缓存的数据计算布局。这样的实现使当前显示的UI实际上是上一帧的UI（延迟了一帧），如果30或者60FPS
的刷新率这是感觉不到的。目前这个系统已经可以工作，但是代码上还需要一些优化，接下来会发布beta版本，这个版本之后不会再做新功能的开发。
-- 2018/02/21(初六)
现在各个模块和API接口已经趋于稳定，在发布1.0版本（正式）之前还需要修复一些小bug。之后的版本需要更新的地方还有很多，比如异步资源/场景加载，
GUI的布局系统/ID系统优化等，估计会在1.1 ~ 2.0 之间的某个版本中实现。目前的实现已经具备一定的开发能力，有经验的开发者已经可以用来做一些
东西，但是对于初级用户来说还需要不断完善的API。
-- 2018/03/29
今天其实值得庆祝的，我们把引擎成功的移植到了Android/iOS, 构建一个移动应用仅仅使用 gomobile 命令即可（非常之快之简单）。而且还发现了一些
额外的好处，比如构建出的包大小非常小Android一个架构在5M左右，并且做了一些粗略的性能测试，主要就是在测试Batch系统的性能上限，在iPhone6上
批量10000个精灵还是可以保持60fps的，在红米5A上可以批量1000个精灵保持60fps，2000个精灵会降到30fps（红米5A价值600RMB配置为晓龙425/2G）
这个粗略的测试表明我们的系统是完全可以胜任绝大部分类型游戏的性能需求的，这点令人兴奋。另外我们引擎的潜力并没有完全释放，一是3D支持，二是多
线程支持，这得益于我们的架构设计非常容易的添加新的系统也非常容易的使之并行化。
-- 2018/04/13
好久没有写开发日志了，距离我们正式开始项目已经过去了1年多的时间。到现在为止我们的各个模块的架构设计基本固定不会再有太多的变化。最近这段时间
主要是忙着写博客文章(Marketing)和做 Demo - 一个仿 flappy-bird 的小游戏，同时通过这个 Demo 来发现引擎再实战中的问题。其中比较大的一次改
变是关于引擎的渲染架构部分，按照最早的设计我们各个渲染子系统是互相分离的，但是这样的话我们在处理 Batch 的时候不能把不同 z-order 但是可以
Batch 的元素batch到一起，这件事始终让我耿耿于怀（事实上即使不Batch, 到了bk-api还会产生一次排序，对性能其实影响微乎其微）。所以为了消除这
种心理上的不愉快我还是改变了渲染架构部分（现在实现更接近于 Destiny 的 RenderFeature 架构）。现在会经过两个阶段：Extract 和 Draw，在
Extract 阶段收集所有可见的元素生成一个可以排序的列表，按 z-Order 进行全局排序。然后是 Draw 阶段，此时会根据排序结果进行渲染，渲染还是通
过各个子系统做的，只是在上层(渲染系统)重新调度。现阶段存在的主要问题是重复代码太多，之前我们做系统的时候为了避免过早优化采用的策略是不做任何
抽象，现在随着代码和功能变多，已经到了一个不得不做优化的阶段，这个工作需要在接下来完成。
-- 2018/05/19
最近一个多月的时间主要用来写一个仿 Guppy 的小游戏，主要目的还是检测引擎的实用性，庆幸的是基本上没有遇到太多困难。有一些小的功能添加，比如相机
的一些API，大体上是完全可用的。在实现这个游戏的过程中，用到了物理引擎（Box2D），Box2D的设计思路和我们的ECS架构是很吻合的所以很快的就集成
了。另外把游戏打包 Android/iOS 平台的时候也异常顺利，直接用 gomobile 工具打包就 OK 了。在做文件存储的时候遇到一些困难，写了一些辅助方法，
比如查询当前平台的文件目录。目前来看如果只是做一些典型的小游戏是没有问题的，但是对于国内的情况来说，可能还要集成统计、广告的SDK，现阶段我们还
没有从引擎上直接支持，如果做这些工作，需要使用 gmobile-bind 模式比较容易。
-- 2018/07/12