游戏引擎

上一篇文章《渲染工作流与任务提交》对应的代码：renderer flow & command commit 前言 3D空间坐标系和相机的实现，往深了讲，内容还挺多的，一篇文章内无法一一道明。对Open

渲染工作流 完整的游戏引擎中，渲染流程一般拆分为两大部分，一部分在业务层，生成渲染的数据、更新状态，另一部分在真正的渲染层，和图形API打交道。 第一部分称为Renderer，第二部分称为Render

前言 本节我们对VertexArray进行抽象封装，目标是将Application中对OpenGL的直接调用都剥离到Renderer层。 VertexArray抽象 原本Application中分别持

前言 Application.cpp中，设置一组顶点到OpenGL的 ArrayBuffer： 现在只有一种顶点属性，即由3个float组成的position(坐标)，如果再加上color(颜色)、n

Application类中还有一些和OpenGL平台相关的代码，需要提出去，使整个引擎逐步向跨平台方向演进。 本节将VertexBuffer和IndexBuffer抽象出来。设计成抽象接口Buffer

前言 在Application中写大段的shader逻辑显然不合理，而且每个shader都会走一遍编译、链接的逻辑，很直观的想到，将重复的逻辑抽象出来，写成shader类 Shader封装 提出ver

从这篇起，开始进入渲染模块(Renderer)，Renderer是游戏引擎中最重要的一块，需要具备良好的数学、图形学、OpenGL基础 Context抽象 要设计更通用的游戏引擎，需要将图形API抽象

集成数据库GLM 图形或者游戏开发中，必不可少需要用到矩阵、向量的运算。 GLM是最常用的数学库，对OpenGL支持非常好。 这节简述GLM集成过程. clone GLM库 glm地址： https:

做一个好看的窗口 imGui有个docking分支，支持docking和多窗口功能. docking docking功能指的是拖动窗口，四边会出现一组响应区域，鼠标拖动子窗口到对应热区，会对齐到该边上

前言 一个用户交互的程序一定有键盘输入，不同的平台按键对应的编码也不一样，我们怎么知道用户按了什么键？ 这节，我们实现一个输入(Input)模块，解决这个问题，并可以拓展到不同的平台。 实现跨平台，最

前言 增加一篇，修复上节代码中的bug。imGui渲染的列表大小和坐标都不对. 修复后效果，imgui界面整齐的摆放到右上角(忽略背景色，感觉会灰色的比较好看，绿色的太刺眼了) 修改点说明 关键的修改

用了两年的Macbook开不了机了，耽搁了几天，积累了多年的资料都没了。难过😞。 前言 完整的引擎都支持编辑的功能，提升开发效率，也让美术、交互等角色参与进来，通过点击拖拽就能实现一些原型效果。 虚幻

前言 游戏中的元素并不会平铺到一层上处理，而是分到不同的层级中。有点像photoshop中的图层。 一个点击事件到底是触发前面的按钮，还是触发后面的人物模型动画呢？ 按优先级，应该是优先按钮消费，如果

前言 这节完善事件处理，包括移动鼠标、窗口缩放、鼠标点击等，没有新增文件。另外修复上一节几处代码错误。 GLFW可以设置常见的事件回调，在WindowsWindow中我们将这些回调透传到Applica

前言 终于，到了可以看到界面的阶段了。 基于glad和GLFW来构建渲染上屏的功能。 我们熟悉的OpenGL只是一套图形标准，GL版本众多，函数的地址无法在编译时确定下来，需要运行时查询，寻址的方法和

前言 游戏中会有各种各样的输入，键盘、鼠标、游戏手柄等。 这节我们就来定义好常见的输入事件 Event设计与实现 新增Event相关类之后的代码结构： 辅助类 Hazel/src/Hazel/Core

前言 日志系统是所有程序中的刚需，本章节将开源的spdlog集成到引擎中。 spdlog是一个只有头文件，性能很好的C++日志库 集成spdlog spdlog以submodule的形式集成到项目中。

前言 前面花几篇文章把整体的框架搭建好，稍安勿躁。 本章节在引擎内增加Application基类和入口类EntryPoint，业务层增加Application的继承类。另调整部分代码。 先整体看下，文

前言 学习图形学有几年的时间了，计划用半年的时间，搭建一个简易的游戏引擎，加深对游戏引擎和图形学的理解，查漏补缺。 参考youtube上的教程 Game Engine series[1]，做了简化，降

这篇文章参考自从零实现ECS(entity component system)，增加了些自己的理解。 通过简单的代码搞清楚ECS的实现逻辑。 面向对象 vs ECS 什么是ECS 所有的程序员都知道面