update
This commit is contained in:
parent
a0e32a2ae9
commit
cde3500e22
@ -1,28 +1,23 @@
|
||||
# C++命名习惯
|
||||
- 命名统一采用驼峰命名法
|
||||
## 文件夹
|
||||
- 文件夹名字按功能命名，文件名大写
|
||||
- 文件夹下 存放 .cpp 和 .h 文件
|
||||
## 文件
|
||||
|
||||
- 文件名小写 + _
|
||||
|
||||
## 类
|
||||
- 文件名
|
||||
- 按功能命名，与文件中主要类的名字一致
|
||||
- 类名
|
||||
- 按功能命名 ，但需要加上前缀以区分 类和实例
|
||||
- 接口 I
|
||||
- 普通类 F
|
||||
- 反射类 U
|
||||
- 枚举 E
|
||||
- ...
|
||||
- 成员变量
|
||||
- protected
|
||||
- 小写开头
|
||||
- public
|
||||
- 小写开头
|
||||
- private
|
||||
- 小写开头
|
||||
- 成员函数
|
||||
- 大写开头
|
||||
|
||||
- 类名大写 + 驼峰
|
||||
- 变量
|
||||
- 私有
|
||||
- 小写 + 驼峰
|
||||
- 保护
|
||||
-
|
||||
- 公共
|
||||
- 大写 + 驼峰
|
||||
- 函数
|
||||
- 静态
|
||||
- 公共
|
||||
- 保护
|
||||
- 私有
|
||||
## 命名空间
|
||||
- 大写开头
|
||||
- 下划线连接
|
||||
|
||||
@ -70,3 +70,7 @@ git commit m "push commit"
|
||||
git push
|
||||
```
|
||||
|
||||
```cpp
|
||||
git config --global --add safe.directory "*"
|
||||
```
|
||||
|
||||
|
||||
75
note/me/求职/c++基础.md
Normal file
75
note/me/求职/c++基础.md
Normal file
@ -0,0 +1,75 @@
|
||||
# 内存管理
|
||||
## 分类
|
||||
- 堆
|
||||
- 栈
|
||||
- 静态变量
|
||||
# 类型
|
||||
## 作用域
|
||||
- 外部C链接
|
||||
- 具有C语言的名称和调用约定
|
||||
- 避免函数名被修改（为了支持重载），亦或者调用约定对不上
|
||||
- 外部链接
|
||||
- 全局作用域
|
||||
- 内部链接
|
||||
- 文件作用域
|
||||
- 无链接
|
||||
- 代码块
|
||||
## 类型转化
|
||||
- static_cast<>()
|
||||
- 有类型检查，更安全，编译期实现类型转化
|
||||
- dynamic_cast<>()
|
||||
- 动态类型检测，通过虚表检测，实现父类、子类转换
|
||||
- const_cast<>()
|
||||
- 去除const约束
|
||||
- reinterpret_cast<>()
|
||||
- 重新解释内存
|
||||
## 异常
|
||||
- 析构函数尽量不要抛出异常
|
||||
|
||||
# 关键字 & 接口
|
||||
## 基础关键字
|
||||
- sizeof 计算的是类型大小
|
||||
- 指针大小
|
||||
- 看机器位数
|
||||
- 对象大小
|
||||
- 考虑内存对齐，整数倍
|
||||
- 空对象的对象大小是1
|
||||
- 如果是0的化，对象就不存在了
|
||||
- 数组大小
|
||||
- 考虑数组退化为指针
|
||||
- 数组做参数时，底层是指针，已经丢失了数组大小的信息
|
||||
- 未退化数组大小是对的
|
||||
- 字符串大小
|
||||
- 考虑末尾的'\0'
|
||||
- 字符串是依靠末尾分隔符，才能确定字符串结束
|
||||
- 但是sizeof 计算内存大小 考虑‘\0’，strlen计算字符串大小不考虑‘\0’
|
||||
- const 不可改，声明时赋值
|
||||
const 常量是一个编译期概念，由编译器来阻止对常量的修改，和进行一些编译器优化操作
|
||||
- 常量是可修改的，但有风险
|
||||
- 如果编译器对常量进行优化，读取的可能是赋值时的字面值，即修改没有意义
|
||||
- 如果常量本身是可改的，只是由于传参导致的不可改。那确实可以改变对象值，但语义不一致，可能会有混淆
|
||||
- 修饰函数参数
|
||||
- 除了约定常量不可改外
|
||||
- 还有利于右值，左值的传递
|
||||
- 修饰成员函数
|
||||
- 保证函数不要改变对象
|
||||
- 这样const 对象可以调用const函数了
|
||||
- 修饰函数返回值
|
||||
- 同常量一样
|
||||
- 修饰指针和引用
|
||||
- 普通常量必须声明时赋值，const int* p;声明的是p，而p是可改的，所以不需要立即赋值，相当于* p 还未声明
|
||||
- 指针有两个部分p 和 * p ，需要两个const，const保证的是后面的内容不可改。
|
||||
- 引用底层是指针，但是语义上只有p的概念，所以只需一个const 就可保证不被修改
|
||||
- static
|
||||
- 修改全局变量的作用域
|
||||
- 限制变量在当前作用域下，源文件作用域、函数作用域、类作用域
|
||||
- 类作用域的范围是整个模块，所以是唯一的。而其他类型静态变量，则会有多个副本，即使有多个文件作用域引入了同一个变量，也不会报错
|
||||
- 全局变量作用域也是整个模块，所以也需要唯一的定义，借助extern 可以实现变量声明。
|
||||
- extern
|
||||
- 实现全局变量的声明，但如果包含赋值，会退化成定义。
|
||||
- 静态变量作用域不是全局，所以不能使用extern 声明
|
||||
- `volatile mutable`
|
||||
- volatile 用于避免编译器过度优化
|
||||
- mutable 用于打破const 限制
|
||||
## 新关键字
|
||||
|
||||
5
note/me/求职/readme.md
Normal file
5
note/me/求职/readme.md
Normal file
@ -0,0 +1,5 @@
|
||||
求职目标
|
||||
- 薪资高一点
|
||||
- 工作少一点，有学习时间
|
||||
- 那么如何看待工作
|
||||
-
|
||||
0
note/me/求职/渲染基础.md
Normal file
0
note/me/求职/渲染基础.md
Normal file
0
note/me/求职/游戏基础.md
Normal file
0
note/me/求职/游戏基础.md
Normal file
@ -111,13 +111,21 @@
|
||||
|
||||
逻辑是不能省的，只是可以控制逻辑实现的位置
|
||||
|
||||
## 决策层
|
||||
## 世界层
|
||||
|
||||
### 信息层
|
||||
|
||||
### 规则层
|
||||
|
||||
## 实体层
|
||||
|
||||
### 决策层
|
||||
|
||||
提出请求 或 任务
|
||||
|
||||
执行请求
|
||||
|
||||
## 任务层 暂时取消
|
||||
### 任务层 暂时取消
|
||||
|
||||
任务有哪些状态
|
||||
|
||||
@ -133,7 +141,7 @@
|
||||
|
||||
|
||||
|
||||
## 请求层
|
||||
### 请求层
|
||||
|
||||
请求的实质
|
||||
|
||||
@ -181,7 +189,7 @@ start - > tick self -> tick others -> stop
|
||||
|
||||
阻塞状态->关闭表现 关闭数据变化
|
||||
|
||||
## 行为层
|
||||
### 行为层
|
||||
|
||||
- Execute - -> update - - > tick - - > complete
|
||||
- 决定 effect 生命周期
|
||||
@ -198,7 +206,7 @@ start - > tick self -> tick others -> stop
|
||||
|
||||
start update tick stop
|
||||
|
||||
## 表现层
|
||||
### 表现层
|
||||
|
||||
提供开启和关闭接口
|
||||
|
||||
@ -218,6 +226,16 @@ start update tick stop
|
||||
|
||||
可以手动停止吗？
|
||||
|
||||
## 游戏功能层
|
||||
|
||||
### 游戏层
|
||||
|
||||
|
||||
|
||||
### 功能层
|
||||
|
||||
|
||||
|
||||
## 表格
|
||||
|
||||
playsoundeffect ， sound path ，
|
||||
|
||||
28
src/c/c++/reflection.md
Normal file
28
src/c/c++/reflection.md
Normal file
@ -0,0 +1,28 @@
|
||||
# 反射
|
||||
|
||||
|
||||
|
||||
# 类型
|
||||
|
||||
## 类型擦除
|
||||
|
||||
### 数据
|
||||
|
||||
如何用一个容器存储任意数据
|
||||
|
||||
- void *
|
||||
- 无法还原
|
||||
- 父类
|
||||
- 有虚表代价
|
||||
- 包装模板
|
||||
-
|
||||
|
||||
### 函数
|
||||
|
||||
- 参数
|
||||
- 返回值
|
||||
|
||||
## 类型还原
|
||||
|
||||
- 类型转换
|
||||
-
|
||||
@ -164,5 +164,15 @@ int main() {
|
||||
std::cout << "Type1: " << typeid(Type1).name() << std::endl;
|
||||
return 0;
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
## IDK
|
||||
|
||||
- type
|
||||
- typed_context_base*::_context
|
||||
- typed_context
|
||||
-
|
||||
- dynamic
|
||||
- type::type
|
||||
- shared_ptr<base>::_ptr
|
||||
|
||||
|
||||
57
src/c/c++/反射.md
Normal file
57
src/c/c++/反射.md
Normal file
@ -0,0 +1,57 @@
|
||||
# 反射
|
||||
|
||||
## 构建对象
|
||||
|
||||
- [x] 对象大小
|
||||
- 已记录
|
||||
|
||||
- [x] 对象类型
|
||||
|
||||
- [x] 构造函数
|
||||
- [x] 虚函数构造
|
||||
|
||||
- [x] 析构函数
|
||||
- [x] 如果使用准确类型
|
||||
- [x] 如果使用基类类型，则基类需要有虚析构
|
||||
|
||||
- [ ] 对象默认值
|
||||
- [ ] 浅拷贝
|
||||
- [ ] 深拷贝
|
||||
|
||||
## 成员变量
|
||||
|
||||
- [x] 赋值
|
||||
- 传入类型，走编译器函数
|
||||
- [x] 取值
|
||||
- 插入类型，走编译器函数
|
||||
|
||||
## 成员函数
|
||||
|
||||
- [ ] 函数调用
|
||||
|
||||
- [ ] 参数默认值
|
||||
# 重构
|
||||
## 数据存储
|
||||
|
||||
## UClass
|
||||
|
||||
- [ ] 反射数据
|
||||
- [ ] 属性 :: 参考map
|
||||
- [ ] 支持遍历
|
||||
- [ ] 序列化与反序列化
|
||||
|
||||
- [ ] 支持查找
|
||||
- [ ] 按名字？
|
||||
|
||||
- [ ] 按顺序？
|
||||
|
||||
- [ ] 赋值、取值
|
||||
- [ ] 方法
|
||||
- [ ] 同属性
|
||||
- [ ] 函数调用
|
||||
- [ ] 反射接口
|
||||
- [ ] 获取所有属性数组？
|
||||
- [ ] 获取某一属性
|
||||
|
||||
|
||||
|
||||
18
src/g/game/future.md
Normal file
18
src/g/game/future.md
Normal file
@ -0,0 +1,18 @@
|
||||
# 系统
|
||||
- 人物系统
|
||||
- 异世界的旅行者
|
||||
- 旧时代的碎片副本
|
||||
- 抽卡系统
|
||||
- 与人物系统深度绑定
|
||||
- 人物有灵魂
|
||||
- 氪金系统
|
||||
- 氪金共赢
|
||||
-
|
||||
- 宠物系统
|
||||
- 非血统论
|
||||
- 各有特色
|
||||
- 主线
|
||||
- 末日生存，重建家园
|
||||
- 消灭资本，进入共产
|
||||
- 战斗系统
|
||||
- 抄明日之后还是抄原神
|
||||
18
src/g/graph/graphviz.md
Normal file
18
src/g/graph/graphviz.md
Normal file
@ -0,0 +1,18 @@
|
||||
# dot
|
||||
|
||||
```dot
|
||||
digraph FrameGraph {
|
||||
graph [style=invis, rankdir=TB ordering=out, splines=spline]
|
||||
node [shape=record, fontname=helvetica, fontsize=10, margin="0.2,0.03"]
|
||||
|
||||
P0[label=<{ {<B>Pass1</B>} | {Refs: 1<BR/> Index: 0} }> style="rounded,filled", fillcolor=orange]
|
||||
subgraph cluster_P0 { P0 R0_1 }
|
||||
P1[label=<{ {<B>Pass2</B>} | {★ Refs: 1<BR/> Index: 1} }> style="rounded,filled", fillcolor=orange]
|
||||
R0_1[label=<{ {<B>foo</B><BR/><I>texture</I>} | {Index: 0<BR/>Refs : 2} }> style="rounded,filled", fillcolor=skyblue]
|
||||
R0_2[label=<{ {<B>foo</B> <FONT>v2</FONT><BR/><I>texture</I>} | {Index: 0<BR/>Refs : 0} }> style="rounded,filled", fillcolor=skyblue]
|
||||
P0->{ R0_1 } [color=orangered]
|
||||
P1->{ R0_2 } [color=orangered]
|
||||
R0_1->{ P1 } [color=yellowgreen]
|
||||
}
|
||||
```
|
||||
|
||||
7
src/l/leetcode/算法分类.md
Normal file
7
src/l/leetcode/算法分类.md
Normal file
@ -0,0 +1,7 @@
|
||||
# 排序算法
|
||||
[[排序算法]]
|
||||
|
||||
# 递归与分治
|
||||
- 二分搜索/查找
|
||||
- 大整数乘法
|
||||
-
|
||||
@ -261,8 +261,20 @@ modification date: Thursday 6th February 2025 13:39:59
|
||||
📅 **2023.08 - 至今** | **个人技术探索**
|
||||
|
||||
🔗 [GitHub 项目]()
|
||||
**项目描述**：
|
||||
一个基于 C++ 的模块化游戏引擎，采用 `xmake` 进行项目管理，支持 Vulkan 渲染，集成 `NoesisGUI` 和 `ImGui`，具备模块化管理、资源加载、序列化等功能。
|
||||
|
||||
- **C++ 反射 & 序列化**：构建高效 **反射系统**，支持 **序列化 & 反序列化**。
|
||||
- **XMake 多模块架构**：开发模块化 **游戏引擎架构**，提升可维护性。
|
||||
- **渲染系统优化**：基于 **Vulkan** 设计 **Framegraph**，优化渲染流程。
|
||||
- **资源管理优化**：改进 **RHI 资源管理**，提升加载 & 渲染性能。
|
||||
**核心技术点**：
|
||||
|
||||
- **模块化设计**：
|
||||
- 采用 `engine.dll + 多个 lib` 方案，合理拆分 `core.lib`、`render.lib`、`asset.lib` 等模块，减少 `dll` 依赖开销。
|
||||
- 通过 `singleton.dll` 解决跨模块全局变量问题，确保唯一性。
|
||||
- **内存管理优化**：
|
||||
- 基于 `std::pmr` 进行高效内存分配，优化 `zlib.lib` 以减少临时分配开销。
|
||||
- GPU 端实现动态缓冲区（借鉴 `NoesisGUI` 设计）。
|
||||
- **资源与序列化**：
|
||||
- 反射系统：借助 `zlib` 反射机制，实现 `JSON/YAML` 序列化与反序列化。
|
||||
- 资源管理：`asset.lib` 负责资源加载、管理与持久化存储。
|
||||
- **渲染架构**：
|
||||
- `render.lib` 采用 `FrameGraph` 设计，支持 Vulkan，并计划扩展到 OpenGL、DirectX、Metal。
|
||||
- `vulkan.dll` 实现 RHI 层，支持 `NoesisGUI` 和 `ImGui` 渲染。
|
||||
|
||||
@ -424,6 +424,8 @@ add_requires("vcpkg::zlib", "vcpkg::pcre2")
|
||||
|
||||
|
||||
## 编译配置
|
||||
- 设置工具链为MSVC
|
||||
- 其他工具不一定能编译xmake-repo的项目
|
||||
|
||||
```lua
|
||||
-- 启用调试符号
|
||||
|
||||
@ -99,6 +99,9 @@ xmake f -p linux --sdk=/usr/toolsdk --includedirs=/usr/toolsdk/xxx/include --lin
|
||||
```
|
||||
|
||||
## 生成
|
||||
```
|
||||
xmake build -vD
|
||||
```
|
||||
|
||||
```shell
|
||||
# 生成 vs 项目
|
||||
|
||||
37
src/z/zengine/开发计划.md
Normal file
37
src/z/zengine/开发计划.md
Normal file
@ -0,0 +1,37 @@
|
||||
# 渲染架构
|
||||
|
||||
## FrameGraph 体系
|
||||
|
||||
### 目标
|
||||
|
||||
基于 FrameGraph 构建渲染体系架构，简化渲染流程，自动化管理 纹理资源、渲染通道、渲染管线 等资源，自动处理CPU、GPU之间的同步问题。
|
||||
|
||||
- 缓存渲染通道
|
||||
- 通过着色器创建对应的渲染通道
|
||||
- 不同着色器是可以对应一个渲染通道的
|
||||
- 通过 FrameGraph 创建对应的渲染通道
|
||||
- 如果renderpass不存在，需要先创建对应资源
|
||||
- 缓存渲染管线
|
||||
- 一个着色器对应一个渲染管线
|
||||
- 不同着色器也可以对应同一个渲染管线？？？
|
||||
- 不可能，渲染管线包含了着色器代码
|
||||
|
||||
- 资源管理
|
||||
- 每帧通过内存池创建 纹理资源 和 缓冲资源，自动管理资源变化
|
||||
- 资源池
|
||||
- 具名对象
|
||||
- 可以通过名字引用
|
||||
- 不具名对象
|
||||
|
||||
|
||||
|
||||
## 举例
|
||||
|
||||
A =>B =>C
|
||||
|
||||
A 输入资源状态为undefined ，初始状态为colorattach， 最终状态也是 colorattach
|
||||
|
||||
B输入资源状态为colorattach，初始状态为colorattach， 最终状态是present
|
||||
|
||||
|
||||
|
||||
6
src/z/zengine/心得感悟.md
Normal file
6
src/z/zengine/心得感悟.md
Normal file
@ -0,0 +1,6 @@
|
||||
## 模块
|
||||
内存管理
|
||||
内存对齐
|
||||
## bug
|
||||
模板类型不匹配
|
||||
枚举类型、嵌套引用类型
|
||||
Loading…
Reference in New Issue
Block a user