blob: 38d7b1cd54dd056ea404ebfb3cb0405786345ce3 (
plain)
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
|
* General
- Big level - =GameObject= streaming from disk
- How to solve in-editor/dev-env performance problems?
- A number of common namespaces used throughout the projects
- =Utils= contains misc functions that are not attached to any class
- =Metadata= contains, well, metadata related things. Most of the functions in here have definitions created by [[*Codegen Design][codegen]] during compilation
- =Tags= contains various enums that need to be unscoped (=enum= instead of =enum class=) for simplicity of interop with libraries and/or use with arrays, but don't want to pollute the global namespace with.
* Codegen Design
This code generator assumes the source-header pair structure. For each header, there needs to be at least one corresponding =.cpp= file (translation unit) for codegen to work (by including the generated code at the bottom of the =.cpp= file). At the same time, if anything residing inside a =.cpp= needs code generation, those will also be placed at the =.inl= included.
** Iteration 1
- 2 kinds of files to deal with: an included file (headers) with no ODR restrictions, and TU files (can be included at most once, or directly compiled)
- Headers can be included in generated =.cpp= files
- Source can not be included; they must include the generated =.cpp= files
- Referenced constructs can exist in both kinds of files
- Dynamically link everything?
** Iteration 2
- "gh" = Generated Header
- "gph" = Generated Pre-Header
- "gs" = Generated Source
- "gps" = Generated Pre-Source
- "g" = General generated file, with any suffix (e.g. =.cpp= or =.hpp=)
* =GameObject= Allocator Design
- TODO
* The General Engine Organization Plan
游戏世界 <-> =GameObject= 之间的组织结构
** Iteration 1
- 分成几个逻辑上的子系统：physics, "rest"。
- physics子系统
- 负责处理 =GameObject= 移动逻辑
- 数据直接储存在 =GameWorld= 里，lazily从实现了 =IPhysicsObject= 的 =GameObject= 里获取
- 例：多个地板对象提供的collision mesh会被汇总到 =GameWorld= 地下，由kinematics solver直接处理
- "rest"子系统
- 就是剩下的一般 =GameObject= 逻辑，实现陷阱、玩家、门之类的逻辑
- 数据表现为 =GameObject= 和派生类的member variable、member function等
*** 脑洞: =TerrainObject=
把所有静止对象全部和到同个 =GameObject= 里，反正每个 =GameObject= 可以提供多个 =RenderObject= 而静止物体又不需要处理逻辑，直接一股脑丢给渲染器和物理引擎就可以了
- 优点
- 降低 =GameObject= 个数
- 缺点
- 模糊了 =GameObject= 的语义，它到底表现的是什么？
- 调试相对麻烦
- 需要单独为 =TerrainObject= 编写/维护一套编辑器
** Iteration 2
TODO
|
