Commit project notes

1 files changed, 52 insertions, 0 deletions

diff --git a/docs/notes.org b/docs/notes.org
new file mode 100644
index 0000000..38d7b1c
--- /dev/null
+++ b/docs/notes.org
@@ -0,0 +1,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