php的网站,wordpress 分割线,企业oa系统是什么,网站开发教程公司回顾
由于一直没有渲染器#xff0c;终于决定开始动手做一个渲染器#xff0c;虽然开始时并不确定该如何进行#xff0c;但一旦开始做#xff0c;发现这其实是正确的决定。因此#xff0c;接下来可能会花一到两周的时间来编写渲染器#xff0c;甚至可能更长时间#xf…回顾
由于一直没有渲染器终于决定开始动手做一个渲染器虽然开始时并不确定该如何进行但一旦开始做发现这其实是正确的决定。因此接下来可能会花一到两周的时间来编写渲染器甚至可能更长时间因为写完整个渲染器需要时间。即使不写整个渲染器至少会写够多的部分来解决当前的问题。因为之前有很多冗余的代码在没有渲染器的情况下产生了不少麻烦这时候不得不决定开始着手渲染器的开发。
另一个考虑因素是地面渲染代码也已经开始有了雏形想要支持多层地面并希望实现这一目标。面临的一个问题是目前没有缩放功能无法测试地面物件的渲染效果尤其是想实现低层次的物体看起来更远需要一种能够模拟这种效果的方式。而为了测试这一点即使渲染器不完美至少需要一个简单的渲染器来验证它是否可行确保渲染效果能够满足需求。因此决定继续推进渲染器开发直到遇到需要调整方向的情况。
黑板渲染
为了让渲染器能够正常工作游戏代码需要发出一系列指令告诉渲染器应该做什么但这些指令不会立刻执行。换句话说游戏代码会发出指令当需要渲染某些内容时它会把这些指令放入一个缓冲区。这些指令可能包括渲染某个物体的头部或者渲染一些粒子效果等。这个缓冲区被称为“推送缓冲区”原因是因为可以不断向缓冲区中推送新的指令缓冲区不会缩小只会持续增加直到渲染器最终将所有指令渲染并丢弃缓冲区中的内容。
使用这种方法有几个原因。通过将指令放入缓冲区渲染器可以延迟执行这些指令直到渲染时才统一处理从而优化渲染流程。
黑板使用 PushBuffer 的原因
推送缓冲区的第一个也是最重要的原因是希望能够进行排序。为了做到这一点需要能够在渲染之前先看到所有需要渲染的内容并决定它们的渲染顺序。虽然可以尝试设计游戏代码让它按照渲染的顺序逐步处理每个任务但这样会给游戏带来很多约束导致游戏需要进行大量不必要的计算而这并不是理想的设计。游戏的结构应该以提高灵活性和速度为目标并且优化离屏计算的效率而不是仅仅围绕如何渲染来构建整个游戏架构。
黑板围绕渲染器构建的游戏架构历史
过去游戏架构完全围绕渲染器来构建并不罕见尤其是在资源极其有限的时代比如 Atari 2600、ColecoVision 和 Commodore 64。当时若试图将渲染命令排队后再执行游戏根本无法运行因为没有足够的系统资源来高效处理这些操作游戏会非常缓慢内存也可能不足。而今天的硬件资源充足允许在不影响性能的情况下使用推送缓冲区来排队渲染命令并在需要时执行。
黑板现代的奢侈品和权衡
在现代硬件资源充足的情况下可以做出不同的权衡以优化游戏代码的整体结构。然而强调避免使用大量低效的代码来浪费 CPU 资源尤其是在如今机器性能强大的情况下更应该避免这种做法。建议尽量找到合理的权衡点使得游戏代码整体更加高效和灵活。在渲染命令的排序上通过将排序逻辑与游戏代码的结构分离能使游戏代码更加高效和灵活同时在需要时可以根据具体情况调整排序方式。这种方式的优势在于它能够根据不同的场景灵活地进行排序从而提升整体的效率和性能。
黑板输出目标
通过使用推送缓冲区可以实现将渲染命令输出到不同的目标平台上如 OpenGL、Direct3D、Mantle 等甚至可以为不同的硬件平台和软件渲染器提供优化。例如可以为 ARM 架构的处理器提供专门的 NEON 版本或者为不同的硬件平台设计专用的渲染版本。通过这种方式推送缓冲区不仅仅是排序它还允许将渲染命令转化为最适合目标平台的形式从而实现不同渲染器的优化而不需要重写整个游戏代码。这为游戏提供了一层可移植性使得可以在多种渲染目标之间进行优化而不影响游戏的整体架构。
黑板平衡优化方法
对于优化效率的追求存在一个平衡点。极端的优化哲学追求每个细节的完美可能会导致项目无法完成因为总有更多的优化可以做。同样忽视性能完全不关心它也是不理智的因为这会导致低效和不可靠的结果。理想的做法是在项目的时间范围内找到一个合理的效率平衡使得产品既能提供良好的性能又能确保高质量使得运行时感觉流畅、可靠且美观。
黑板PushBuffer 的好处
Push缓冲区可以在渲染过程中提供良好的平衡。它使得游戏代码能够迅速、简洁地描述渲染需求并且避免过度消耗资源。这个缓冲区充当了一种中间表示类似于编译器中的中间步骤使得游戏能够在不影响性能的前提下优化渲染操作。通过这种方式渲染目标如OpenGL、Direct3D或软件渲染器能够高效地处理渲染命令而不需要每帧都做过多处理。此外Push缓冲区还支持在不同平台间的移植使得代码在不同的渲染API上能够灵活转换并实现优化。
黑板支持多个目标的考虑
在设计渲染系统时虽然目前对一些渲染目标如OpenGL、软件渲染器已有经验但仍保持一种谨慎的态度假设对于某些输出目标并不完全了解。这是因为游戏可能会面临新的渲染目标例如Vulkan或Mantle而开发者无法预见所有的技术挑战。目标是确保系统可以灵活适应新平台无需重写整个游戏代码以此实现高效的渲染优化。这种方式能够帮助快速适应不同的渲染API同时保持较好的性能而不会陷入繁琐的重构工作。
黑板我们的第一个目标软件 “GPU 类渲染”
在开发软件渲染器时目标是使其模拟GPU的工作方式尽管它不会完全与GPU相同但通过这种方式可以获得宝贵的对现代游戏渲染流程的洞察。此类渲染器将稍微慢一些因为不会做出专门针对CPU优化的捷径而是力求最大程度地还原GPU的工作机制从而为开发者提供更深刻的理解尤其是关于着色器的结构和性能特点。
这种方法有助于理解GPU如何处理图形并通过该方式开发渲染器时可以从中获得对现代游戏图形渲染的宝贵见解。虽然软件渲染器的效率不如GPU但它的设计有助于开发者深入了解图形渲染的本质。
黑板两种渲染工作方式的视角1) 显式表面光栅化器
一种常见的渲染方法是通过扫描线来绘制图形。例如绘制三角形时首先会确定三角形所触及的扫描线然后遍历每条扫描线计算出三角形在每条扫描线上的跨度最终确定哪些像素属于三角形。这种方法是传统的软件光栅化方式在过去的Pentium时代较为常见。
然而虽然这种方法在某些情况下可能是更高效的当前的开发策略并不打算使用这种传统的扫描线渲染方式。即使这种方式能够提供较好的性能也不会采用它而是选择一种不同的渲染策略。
黑板2) 隐式表面光栅化器
当前的渲染策略采用了一种隐式的表面光栅化方法而不是传统的显式光栅化。传统的光栅化方法会逐像素遍历并填充需要的像素而隐式光栅化则通过粗略估算哪些区域会被图形触及来进行处理。例如可以使用一个4x4像素的方格16个像素来估算三角形与屏幕上的区域的交点而不需要明确计算每个像素是否被三角形触及。
具体操作是先估算哪些4x4的像素区块会被图形触及然后对这些区块中的所有像素进行计算而不管三角形是否真的经过这些像素。最后会通过掩蔽操作去除不被触及的像素仅填充真正被图形覆盖的区域。
黑板使用隐式方法的理由
采用这种方式有很多原因虽然现在不打算详细展开但随着实现的推进这些原因会变得更加清晰。现代GPU通常采用类似的方案进行渲染。
黑板我们的渲染器大概会是什么样
渲染器的工作流程将包括以下几个阶段首先是推送缓冲区push buffer接着进入一个定位阶段确定屏幕上各个三角形的位置。然后渲染器将选择需要填充的4x4区域针对每个三角形或其他几何图形进行处理。之后将有一个计算阶段负责计算这些4x4区域的像素值。这个阶段会使用类似光栅化的算法来处理这些区域。
黑板SIMD 指令集
渲染器将在不同的处理器架构上进行优化具体根据不同的SIMD单指令多数据宽度进行调整。对于SSE2最小目标每次计算四个像素AVX则是八个像素AVX-512则是16个像素。渲染器将根据平台的不同分别进行四倍、双倍或单倍的处理。最终通过这种方式渲染器可以在不同平台上有效运行同时保证每个像素的渲染按预定的方式进行处理过程会像流水线一样进行确保高效执行。
黑板我们正在构建的概述
目前的工作重点是处理矩形渲染因为游戏引擎是基于精灵的矩形是主要的处理对象。虽然有时可能会考虑三角形但在实际情况中处理矩形的成本和处理三角形相似因此选择专门处理矩形可以节省许多计算工作。接下来渲染器将扩展功能包括支持缩放和旋转等操作虽然目前游戏还没有请求这些功能的接口但为了能够在后续阶段处理这些需求需要在渲染管线中预留空间。当前的目标是清理和优化推送缓冲区并确保渲染器能够表达这些新的功能。
开始提取绘制函数
开始整理和提取一些功能包括绘制矩形、绘制矩形轮廓、绘制位图等操作。所有这些功能将集中在一个地方方便查看和检查确保没有出现错误。虽然在操作过程中遇到了一些小问题但这些可以逐步解决。 看看我们目前的进展
检查了当前状态后确认一切正常缓存填充工作进行顺利没有需要担心的地方项目目前处于可工作状态可以继续推进。
开始玩代码
在当前工作中发现了 PieceCount 仍然存在但不再使用进行了对齐操作确保一切显示正常。
Vaporise PieceCount
决定删除 PieceCount因为它不再被使用进行清理工作。
研究在这里添加多种命令类型首先将 entity_visible_piece 重命名为 render_group_entry
为了便于扩展命令类型决定将 entity_visible_piece 更名为 render_group_entry。这样可以更清晰地表示其实际功能并且更好地适应未来可能的复杂命令操作。
把 RenderGroupToOutput 提取到 game_render_group.cpp 中
在这一过程中计划将一些功能提取到game_render_group中主要是为了更好的组织结构便于集中管理相关内容。此举与代码本身无关完全是为了个人方便。将这一部分称为“RenderGroupToOutput”并将原本在推送缓冲区内进行的操作移到渲染组中。接下来需要传递一些必要的参数包括渲染组本身和输出缓冲区等。
对于ScreenCenter坐标X和Y等信息可以从缓冲区中计算得出。像将米转换为像素这类操作则可以通过RenderGroup直接进行尽管这可能会在稍后的过程中稍作不同的处理。最终的目标是确保所有需要的值都可以通过RenderGroup或其输出目标来获得。
重点是所需的“绘制缓冲区”实际上是一个加载的位图它代表了绘制的目标。因此将该位图作为输出目标传递其他相关的计算如屏幕中心也可以通过这个目标来完成。
总的来说这一过程并不涉及任何设计变动仅仅是一个简单的编程步骤确保代码结构更加清晰。 面向压缩编程
**压缩导向编程Compression Oriented ProgrammingCOP**是一种编程范式重点在于将压缩技术作为系统和算法设计的核心主题。其目标是通过在系统架构中广泛应用压缩技术来优化数据的存储、传输和处理。该方法不仅能够减少存储和传输成本还可以通过减少内存使用和提高数据处理速度特别是在处理大型数据集时来改善性能。
压缩导向编程的主要原则包括 数据表示使用压缩格式作为数据存储和处理的主要表示方式确保最小化空间使用。 算法设计开发能够高效处理压缩数据的算法使其在不完全解压的情况下也能快速访问和操作数据。这可能涉及专门的数据结构或编码方案以便实现压缩感知计算。 权衡管理压缩效率与压缩和解压操作开销之间的权衡。虽然压缩可以节省空间但压缩和解压所花费的时间也需要平衡以确保性能不受影响。 流处理与实时处理实现允许高效处理数据流的压缩技术确保在实时处理时不会显著影响性能通常使用如流式压缩算法等技术。 可扩展性设计能够随着数据规模的增大而扩展的系统确保即使在大规模分布式系统或大数据环境中压缩的优势仍然能够显现。
这种方法在数据传输例如网络传输、存储管理以及处理大型数据文件或数据库等领域尤为有用因为数据的庞大规模可能会成为瓶颈。
在这段讨论中强调了设计过程应当是自然、有机地进行的而不是过度设计或过度思考。整个过程应该是逐步推进的通过不断提取和简化现有的结构按照已有的代码要求来决定各部分内容的组织和功能而不是在早期就过度规划。提到在编程中重要的是写出可行的代码然后逐步整理、优化而不是一开始就进行复杂的设计例如绘制类图等这些通常没有实际意义。
这种方法避免了“过度设计”的坏习惯鼓励更关注实际代码的实现并逐步将其分解为更简洁、清晰的模块。这是一种非常有效的方式经过多次实践证明其有效性强调了本能的编程方式比许多书籍所教的“标准方法”更为高效尤其是在解决实际问题时。
考虑对一组实体进行操作
在这段内容中主要讨论了如何优化渲染指令的处理方式。首先讨论了推送缓冲区push buffer中的命令是如何被交错执行的虽然这种做法可能效率较低因为每个命令都需要检查其类型并执行相应操作但目标是尽量精简命令以避免频繁处理不必要的渲染指令。例如如果绘制大量粒子效果时每个粒子都是一个矩形且使用相同的纹理不应该单独把每个粒子作为一个渲染命令推送到缓冲区。这是因为每个粒子的处理都会引入额外的判断和开销极大影响性能。
为了优化这一过程推荐将具有相同纹理或相似渲染需求的物体合并为一个命令。例如对于具有相同纹理的多个位图图形可以将它们合并成一个渲染指令从而减少每个命令的切换和判断开销。虽然推送缓冲区中的命令数量可能很庞大但为了避免因为粒子数量庞大可能达到十万甚至更多而导致性能瓶颈必须谨慎选择在推送缓冲区中添加的命令。
最终的目标是减少切换和判断的开销以保证渲染效率。虽然目前开始的实现较为基础但在未来的优化中必须考虑如何减少这些开销确保推送缓冲区的效率不成为瓶颈。
设置处理不同类型条目的情况
在这段内容中讨论了如何改进处理推送缓冲区条目的方式。首先将Piece一词更改为Entry以便更清晰地表示这些条目是什么。在处理这些条目时首先需要判断条目的类型然后根据类型执行不同的操作。例如某个条目可能是一个“clear”操作另一个可能是一个矩形渲染命令后者通常用于精灵图像的渲染。 当前并没有明确所有条目的类型但目标是确保能够处理所有可能的情况。为此需要引入一个机制能够根据不同类型的条目执行相应的渲染操作。通过这种方式可以确保在推送缓冲区中的每个条目都能被正确处理无论它是何种类型。
引入 InvalidDefaultCase
在这段内容中讨论了使用一个宏“InvalidDefaultCase”来处理switch语句中的默认情况。这个宏的作用是确保在switch语句中如果进入默认分支程序会触发断言assert以确保不允许默认情况发生。原因在于推送到缓冲区的条目应该是可以处理的如果遇到无法处理的情况就需要为其添加一个专门的case但在处理这个case时什么也不做意味着不处理这种情况。例如某些特定于OpenGL的情况可能就不需要处理。总之目标是确保所有被推送到缓冲区的条目都是可以处理的而不允许进入默认情况。
根据 Entry-Type 增加 BaseAddress
在这段内容中讨论了如何调整基地址的变化。在处理条目时基地址的增量将根据当前条目的内容进行不同的调整这意味着每个条目的偏移量将依据其具体类型而有所不同。虽然这种方法可能不是最优化的方式但目的是确保系统能够支持这种方式。最终是否选择这种方式还需要在后续根据实际效果做进一步评估。
此外提到了一种可能的替代方案即通过指针追踪的方式来调整基地址的增量但目前不确定哪种方式更适合。计划保持灵活性待到实际实现时根据具体情况决定最终的选择。
编写这些情况
在这段内容中讨论了如何处理渲染条目的类型转换。首先通过将渲染条目如清除操作或矩形操作进行类型转换确保每个条目都被正确识别和处理。这种方式类似于使用带有区分的联合类型discriminated union其中根据条目的类型执行相应的操作。比如清除操作会被转换为对应的类型矩形操作则会转换为矩形类型。
此外还提到了一种可能的改进即将条目统一命名为“entry”并将其类型设为“TypelessEntry”或类似名称。这样一来能够更方便地识别和处理不同类型的条目。处理完每个条目后将根据条目的大小来推进基地址确保内存布局和条目顺序正确。
创建对应的 render_entries
在这段内容中讨论了如何组织渲染条目特别是如何将渲染条目分为不同的类型如“清除clear”和“矩形rectangle”。为了清晰区分这两种类型决定为每个类型创建不同的结构体例如render_entry_clear和render_entry_rectangle。每种类型将拥有不同的字段例如“清除”条目可能包含一个RGBA值用于指定清除颜色。
此外还提到需要为每个条目添加一个头部header这个头部将包含条目的类型如清除或矩形。考虑是否需要在头部中添加其他字段但最终决定目前只需要类型字段因为其他信息暂时没有想到需要添加。
为了进一步简化考虑将头部命名为“render_group_entry_header”或者使用更通用的名称“typeless_render_group_entry”但目前没有决定。最后提到会用枚举enum来表示不同的渲染条目类型具体包括“clear”和“rectangle”两种类型。 描述 “紧凑判别联合体”
在这段内容中讨论了使用“判别联合体”discriminated union来组织不同类型的渲染条目。判别联合体的特点是通过一个类型字段来区分不同的可能类型这使得每个条目在内存中可以根据其类型分配适当的空间。相比于传统的联合体union传统联合体会使用最大尺寸来确保所有类型都能容纳而判别联合体则使用一个类型字段来判断每个条目的具体类型从而根据实际类型调整内存的分配大小。
举个例子假设系统中有两种渲染条目类型一种是清除操作clear另一种是矩形rectangle。如果使用传统的联合体内存分配将为这两种类型中占用空间最大的类型提供足够的空间。例如clear可能只需要一个RGBA值而rectangle可能需要更多的数据如位置、尺寸等。传统联合体会为rectangle分配足够大的空间以容纳所有可能的数据但这会浪费内存因为clear类型只需要小部分空间。
然而使用判别联合体时可以通过类型字段来区分这两种类型。当处理清除操作时只分配必要的内存如RGBA值的大小而处理矩形时则分配矩形需要的内存大小例如包含位置和尺寸的结构体。这样每次处理时只会根据实际类型的需求来分配内存不会浪费空间。
为了进一步提高效率系统决定避免使用固定的最大内存块而是根据每个条目的类型动态调整内存地址的偏移。例如在处理矩形时如果矩形需要更大的内存块可以根据其实际大小进行内存推进如果是清除操作则只推进小量的内存。这种方式可以有效减少内存的浪费并使得推送缓冲区能够处理任意大小的条目。
至于头部字段的问题原本计划为每个条目添加一个头部字段可能包含类型和其他信息但经过讨论后认为仅保留类型字段就足够了这样可以简化结构体的设计。
进一步地为了提高内存效率计划将这些类型压缩而不是使用最大的内存块。这意味着每次处理条目时不再按照最大类型大小推进内存而是根据实际类型的大小来调整内存位置。这种方法的目的是支持推送任意大小的条目到推送缓冲区这在后续的实现中将证明非常有用。
此外讨论了是否需要添加一个头部字段header。虽然目前仍然保留了头部字段但认为可能仅需要类型字段。总体来说目标是通过这种方式有效地管理内存并确保系统能够灵活地处理不同大小的渲染条目。
回顾我们新的能力
在这段内容中讨论了如何通过判别联合体处理不同类型的渲染操作例如清除操作和矩形渲染操作。通过判别联合体的使用可以根据不同类型的渲染条目采取不同的操作。例如在遇到清除操作时可以执行清除操作而遇到矩形时则执行相应的矩形渲染操作。系统的设计允许在渲染过程中灵活处理不同类型的渲染条目使得可以扩展支持更多类型的渲染操作。
接下来计划将矩形操作进一步细化添加不同类型的矩形例如矩形轮廓outline。这一点体现了通过判别联合体的使用能够更加灵活地扩展渲染系统支持更多复杂的渲染类型。此时可以通过不同的渲染操作类型组合形成更加丰富的渲染系统。
关于推送缓冲区push buffer的操作强调了在处理过程中所采取的架构决策。通过经验积累能够较为迅速地做出正确的架构选择而不需要经历每次都从零开始的尝试。这种经验优势能够帮助在设计系统时做出更加高效的决策。对于没有这种经验的人来说可能需要更多的迭代和尝试但最终编程的方式大体上是相似的。
总的来说判别联合体的使用提高了渲染操作的灵活性并且经验的积累在系统架构设计中起到了重要作用。
荒谬技巧将类型名称与 RenderGroupEntryType 连接以构成标识符并使用 #define PushRenderElement 宏以类型安全的方式在一步中正确设置类型字段
在这段内容中讨论了如何在推送渲染元素时不仅推送渲染元素的大小还推送渲染元素的类型。为了实现这一点提出了一个技巧通过宏来动态生成类型标识符并将其应用于推送操作。
具体来说宏 PushRenderElement 被设计成接受渲染组和渲染元素类型作为参数。宏的作用是调用实际的推送函数传递渲染组并推送该类型的大小。同时宏会将类型名称的前缀附加到类型上从而创建一个带前缀的类型标识符。这个前缀是通过枚举类型中的结构类型名称生成的。
这种做法避免了复杂的模板或不必要的复杂性同时保持类型安全。在调用 PushRenderElement 时只需要指定希望推送的类型例如矩形类型其他的处理会自动完成。通过这种方式系统能够正确地设置类型字段确保类型的一致性并简化了渲染元素推送的过程。
整体而言这种方法使得渲染元素的推送更加高效、安全且简洁避免了冗余的模板操作并且确保了类型字段的正确性和一致性。
将类型传递给 PushRenderElement
在这段内容中讨论了如何在推送渲染元素时处理内存分配和类型信息。当从推送缓冲区获取结果时计划将结果作为一个“头部”来处理这意味着不管分配的内存如何它都会包含某种形式的头部信息。即使某些元素可能不需要该头部系统也能进行处理允许没有头部信息的元素插入。如果决定允许这种情况还可以在更深一层添加推送大小的处理。
此外提到如果内存空间不足可以通过在头部进行检查来轻松支持空间不足的情况。当空间不足时元素会被丢弃简单地忘记它们即可不需要更复杂的处理。
总结来说目标是通过头部信息和类型字段来管理推送的渲染元素并通过简单的检查确保空间充足避免复杂的错误处理机制。
编译并清理
在这段内容中讨论了如何正确获取并处理渲染元素的头部。首先获取头部信息后计划将其转换为相应的类型。这涉及到通过名称的修改来适应不同类型的转换。通过这些步骤可以确保在内存中正确地管理头部信息并根据需要将其转换为相应的渲染元素类型。
此外还提到了一些细节例如在进行类型转换时需要确保位置正确以避免错误发生。总体来说目标是通过这些操作确保渲染元素的类型和头部信息能够正确管理便于后续操作的顺利进行。
检查游戏中一切是否正常
讨论了为了简化操作和提升效率进一步优化了代码结构。通过进行一些调整目标是让系统能够更方便地处理不同的任务使得后续的操作更加高效。这种优化为系统提供了更好的区域化管理使得处理过程更加便捷和直观 创建位图类型
在这段内容中讨论了将原本的“位图”和“矩形”操作分离成两个独立的处理流程。通过这样做系统能够分别处理位图和矩形确保每个操作有针对性的实现。在处理时对于位图系统会执行相应的位图绘制操作而对于矩形则会按矩形的方式绘制。最终两个不同的操作被分别调用分别通过对应的推送方法来实现。这种方式提高了代码的清晰度和可维护性使得不同的渲染操作可以被更独立地处理。 为位图调用 PushPiece 函数
在这段内容中讨论了对位图操作进行逐步处理。首先继续调用“PushPiece”函数来处理位图类型。在执行时确保传入正确的类型以便系统能够正确地处理位图。通过逐步调试和确认每个步骤保证系统能够正确地处理位图数据。
由于 Entry-Bitmap 未填充触发了断言
在这段内容中讨论了在绘制固体矩形时可能会遇到断言失败的情况特别是当位图条目没有填充时。为了避免这种情况接下来需要进行调整确保在绘制固体矩形时相关的位图数据已经正确填充。
确保在调用位图类型时推送一个矩形
在这段内容中讨论了如何调整代码以确保在调用绘制矩形的函数时实际推送的是一个矩形而不是其他类型的数据。为了确保这一点暂时通过复制代码的方式来处理随后再优化代码避免重复。
检查游戏中一切是否正常
在这段内容中提到矩形的绘制虽然按预期工作但代码中存在重复部分。接下来需要考虑将这些重复的代码提取出来优化代码结构以减少冗余和提高可维护性。
将代码压缩成更可用的形式
在这段内容中计划通过压缩和简化现有的代码来提高可用性。主要目标是将与位置相关的计算如偏移量和坐标与形状的绘制分离创建一个“实体基础”概念这样可以更清晰地管理实体的位置信息。进一步地打算通过引入一个函数来处理这些计算以简化代码并避免冗余。此外还提到在处理过程中需要注意位图的尺寸问题确保这些计算正确处理。
将偏移量嵌入 PushRect 中
在这段内容中计划对矩形的绘制进行优化主要目的是简化坐标和偏移量的计算。通过调整“中心”与“半尺寸”的处理建议将计算过程更清晰地集中到一个统一的协调点从而消除原本由于坐标变换带来的复杂性。此外进一步调整了尺寸计算方式通过引入“MetersToPixels”的转换来确保矩形绘制更加合理。还讨论了坐标系中的Y轴翻转问题确保矩形在绘制时的偏移量计算正确。
提取 EntityBasis 计算
在这段内容中计划对计算过程进行进一步优化目的是简化并统一实体基础的计算。通过提取出一个用于计算“render_entity_basis”的函数来避免重复代码。该函数将接受渲染实体基础并计算偏移量最终返回一个包含这些计算结果的值。进一步的调整包括将entry改为EntityBasis并清理冗余代码确保整体代码更简洁和可维护。 清理
在这一段中计划调整函数的输入参数将ScreenCenter和RenderGroup传递给相关的函数并确保在计算过程中正确处理它们。ScreenCenter可能已经在管道中全程可用因此可以进一步优化这一点。另外dim被移除因为它仅在矩形处理时使用之后通过调整代码将其放置到矩形部分。接下来需要填充基础结构调整命名保持一致并修复可能存在的命名不一致问题。由于在处理时存在一定的注意力分散可能会有一些错误但目标是改进代码结构和简化操作。 看看我们现在的进展
目前代码调整看起来已经顺利进行基本上已经达到了预期的状态所有的更改看起来是正确的。到此为止工作可以暂时停下来尽管还有一些小的调整但整体上进展顺利。
当你在游戏中遇到 bug 并能重现它时你会在编程中看到 bug 行吗还是它是如何工作的
当遇到游戏中的错误并能够重现时通常有两种类型的错误。一种是比较容易追踪的能快速定位到问题所在并进行修复另一种则比较复杂需要花费时间创建特定的情境来推断问题的根本原因然后再进行修复。至于“bug line”这个术语不太清楚是什么意思抱歉没有更明确的解释。
关于是否值得对渲染条目进行对齐这个问题也涉及到优化和代码结构可能要根据具体的需求来决定是否进行对齐。
是否值得对 render_entries 进行对齐
目前来说render_entries不需要特别对齐因为所有的render_entries都会已经是8字节对齐的。这是因为render_entries中会包含指针而指针通常是8字节对齐的所以这种情况下已经足够。但是当开始处理更为可变大小的内容时可能需要对齐以避免把数据放在不对齐的内存地址上这样做有助于避免性能问题。至于进一步的对齐可能不会做太多处理但需要根据实际情况测试。对齐有时能带来性能提升但有时也可能带来空间浪费进而影响内存带宽或缓存效率可能会抵消对齐带来的好处。
至于Mantle它是一个由AMD推出的低级别图形API旨在提供比OpenGL和DirectX更直接的硬件访问从而提高性能。
Mantle 是什么
Mantle 是AMD推出的一种图形API旨在提供更直接的硬件访问主要用于访问其GPU。它比传统的图形API如OpenGL和DirectX提供了更为直接的控制使得开发者能够更高效地与硬件进行交互。
有关 GPU、渲染、光栅化的阅读推荐吗除了谷歌搜索
对于关于GPU渲染和光栅化的阅读推荐推荐访问Fabien Gazin的博客他是图形编程和优化领域的顶尖程序员之一。在他的博客中尤其有一篇关于图形管线的文章非常值得阅读。这篇文章深入讲解了图形工作原理并且提供了一个良好的起点来理解图形渲染过程。虽然这篇文章发布于2011年内容可能有些过时但它依然能提供关于2015年及以前的图形管线的扎实理解并帮助读者更好地理解后来的更新内容。
如果能花时间深入研究这篇文章将能大大提高对图形管线的理解并能轻松阅读其他与图形渲染相关的资料。总的来说这篇博客被认为是了解图形渲染的一个极为重要的资源。 google 搜索The ryg blog https://fgiesen.wordpress.com/ 博客 不过这个博客好像外网才能访问
为什么使用指针而不是引用
在讨论为什么使用指针而不是引用时指出指针和引用之间实际上没有太大区别尤其是在不使用C特性时二者在CPU执行上没有本质差异。指针和引用都可以实现相同的功能。指针是引用的超集因为指针可以改变指向的对象而引用则不能更改指向的对象尽管有些C的最新规范似乎允许引用指向的对象变化。
之所以不使用引用是因为它们并不带来额外的好处。在实际编码中指针在做指针运算时更加灵活而引用只能用于直接的引用功能相对较弱。因此倾向于使用指针因为指针可以做更多事情而引用则没有这些能力。
关于 Mantle你是否知道 AMD 已经停止开发它并将大量人力投入帮助推动 Vulkan
关于Mantle虽然已经知道AMD曾试图通过Mantle为Vulkan奠定基础并在推动Vulkan的过程中做出贡献但并不清楚AMD已经停止了对Mantle的开发。此前并没有关注到AMD停止支持Mantle的消息。实际上可能仍然假设他们会在未来某个时刻继续进行Mantle的工作。总的来说未对AMD的更新有深入关注因此并不清楚最新的动态。
是一个依赖内存进行通信的抽象层而不是一堆函数如果我理解正确的话。这是你通常喜欢的 API 设计方式吗
对于API设计倾向于使用基于内存的设计而不是基于函数的设计。基于内存的API更灵活具有更高的可扩展性并且能够支持如跟踪、捕捉等重要功能。相比之下基于函数的API通常更复杂、更难以文档化容易变得杂乱无章。对于渲染器这类问题明确、输入输出清晰的场景基于内存的API设计尤其合适。然而在一些更为复杂的场景中比如整个游戏系统的API设计基于内存的设计可能就不适用了因为它会过于复杂。总体而言在遇到明确问题时倾向于采用基于内存的API设计。
