游戏引擎学习第200天

回首并为当天的工作设定阶段目的

本日的工作方向是会合在用户界面（UI）代码的实现，固然这个项目本身并不涉及大量的UI筹划，但我们会暂时偏离原来的使命，举行一个小小的探索。告急是由于在之前的工作中，UI部门并没有太多涉及，而这对于那些渴望相识如安在本身的项目中实现UI代码的人来说，大概会有资助。固然这个项目本身不是一个以UI为主的游戏，好比像模拟都会、文明大概模拟人生那样有大量的UI界面，但我们仍然可以花点时间来讨论UI的实现，特别是怎样实现调试UI，这对于游戏开发中调试和监控来说黑白常告急的。
目的是让UI的实现更加简便和机动，以便以后可以快速增长新功能和界面，而不会给步伐员带来过多的负担。在调试UI的实现上，重点是让它尽大概的轻便和高效，如许即便后续必要扩展，也能通过简单的代码修改和调解来实现新的功能，而不必要大规模重构。
在昨天的工作中，我们已经抽象了交互代码，这让我们可以或许更好地管理和复用这些代码。接下来的工作是让UI绘制部门更加顺畅，确保调试UI的绘制可以或许正确体现。本日，我们会重点关注调试UI的绘制实现。这个使命可以分为两个部门：一部门是继续改善UI绘制的方式，另一部门是关于如那里理对象的深拷贝标题。当前我们有一个标题，就是当复制一个对象（如渲染器）时，它只是做了引用复制，导致多个对象间的数据完全同步，如许大概会产生不渴望的结果，我们必要办理这个标题。
不外，思量到时间安排，我们决定暂时专注于调试UI的绘制部门，确保它可以或许正常工作，等这个部门完成后再思量其他改进步伐。因此，本日的使命告急是让绘制部门的代码运行起来，并确保它符合我们的渴望。

查察我们当前怎样绘制内容 (game.debug.cpp)

本日的目的是改进如今的绘制代码，制止它显得过于暂时和零散。当前的绘制方式是通过一个简单的 for 循环，遍历全部必要绘制的范例，并在循环中直接编写绘制代码。固然这种方式在早期阶段能快速实现需求，但随着功能的增长，代码变得越来越紊乱，维护和扩展变得更加困难。
最初在处理处罚交互时，固然我们也使用了雷同的方法，但之后我们创建了一个 debug interaction 范例来封装交互的内容。如许做的长处是可以将交互逻辑抽象出来，制止重复代码，同时也方便了对交互状态（比方高亮）举行管理。通过这种方式，代码变得更加整齐、清晰，也进步了机动性和可维护性。
接下来，我们筹划接纳雷同的方式重构绘制代码。如今的绘制代码也比力零散，涉及到盘算各个元素的位置、巨细等利用，而且这些利用的实现较为分散。为了制止重复和冗余的代码，我们筹划将这些绘制逻辑抽取到一个共享的地方，如允许以同一管理并包管代码的整齐性，同时也便于后续的修改和扩展。
通过这种重构，绘制代码将变得更加模块化，可以复用的部门被提取出来，代码的可读性和可维护性也会大大进步。别的，这种改进也能让我们在添加新的绘制元素时，不必要重复编写相似的代码，而是可以直接调用已经封装好的方法，保持代码的简便性和同等性。
引入布局布局体以包罗局部变量 (game_debug.cpp)

本日的工作重点是将现有的重复代码提取出来，举行简化和重构，以便更高效地管理和修改。在当前的代码中，有多个地方在处理处罚雷同的功能，比方绘制位图和计数器线程列表等。这些功能大多数情况下都从雷同的位置开始，而这些位置通常都是雷同的，然而如今的代码在差别地方重复了相似的内容。举个例子，假如我们想要修改这些内容的缩进方式，必须在多个地方举行修改，如许就袒露了代码重复的标题。
为了制止这种冗余和潜伏的维护标题，我们决定将这些重复的部门提取出来，创建一个共同的布局体来管理这些变量。具体来说，我们从当前的代码中提取了深度（depth）、行进量（line advance）以及干系的坐标等变量，将它们放入一个布局体中。通过这种方式，全部必要使用这些变量的函数，都可以通过转达该布局体来访问这些数据。
这意味着，我们不但仅是将这些变量放入布局体中，而是渴望通过这种方式将它们封装起来，使得这些数据能方便地转达给其他函数。如许做的长处是，原先的变量分散在差别的地方，如今我们只必要通过布局体转达一次，就可以让函数知道这些数据的状态。通过这种方式，我们实现了雷同闭包（closure）一样的结果，使得代码更加模块化和简便。
总之，本日的工作是将一些重复的逻辑抽取出来，封装成布局体，如许不但制止了代码重复，还为以后大概的修改和扩展提供了便利。这种做法让后续的功能扩展和修改变得更加机动和高效。

引入 Advance

如今，我们正在优化和整理现有的绘制逻辑，使代码更具条理性，同时镌汰冗余部门。当前的代码存在一些标题，好比在处理处罚界限（bounds）时有些不须要的复杂性。这种复杂性告急泉源于我们在实验复用代码路径，以确保推进逻辑（advancement code）的同等性。然而，这种方式并不须要，由于实际上没有来由逼迫全部对象都使用雷同的界限推进方式，每个对象以致大概有多个界限（bounds）。
因此，我们的目的是重新构造代码，使界限的处理处罚更加直观。起首，我们将界限的盘算逻辑移入局部作用域，确保它们在局部函数内部处理处罚，而不是分散在整个代码块中。如许，我们可以镌汰界限处理处罚逻辑的分散性，使代码更易维护。
在文本绘制方面，之前的实现方式较为贫困，由于文本的界限必要特定处理处罚，而这种处理处罚方式导致代码在多个地方做了额外的适配工作。如今，我们正在调解代码布局，使这些适配工作更自然地融入整个体系，不再必要额外的“弯曲”代码逻辑来适配差别的情况。
接下来，我们引入了一种新的推进方式，即创建一个 Advance 函数，并将其应用到布局（layout）对象上。这个 Advance 函数的核心头脑是让对象本身负责界限推进，而不是在外部显式地皮算和更新 Y 坐标。具体来说，我们在 Advance 函数中吸收 layout 和 bounds，然后直接更新 layout 的 Y 坐标，使其便是 bounds 的最小角（min corner）。如许，我们在主代码逻辑中不再必要手动徐徐更新坐标，而是只需调用 Advance 函数即可完成相应的推进利用。
随着 Advance 函数的引入，我们在代码的各个地方徐徐更换了原来的手动推进逻辑，使代码更加清晰、模块化。比方，全部涉及 layout 干系的变量，如 layout.addx、layout.aty、layout.spacingX、layout.spacingY、layout.depth 以及 layout.lineAdvance，如今都可以通过 layout 布局体举行会合管理，而不必要在各处分别维护。这种方式镌汰了重复代码，进步了可维护性，并为未来大概的修改和扩展提供了便利。
在代码迁徙的过程中，我们徐徐处理处罚了编译错误，确保全部干系变量都正确引用 layout 布局体。如许一来，代码逻辑更加清晰，绘制与布局推进的逻辑分离，使得后续的开发更加机动和高效。
团体而言，我们的工作重点是简化界限盘算逻辑、引入 Advance 机制，并将全部干系变量会合到 layout 布局体中举行管理。如许不但镌汰了代码重复，还使得布局推进的逻辑更加直观和易于维护，从而优化整个 UI 体系的开发流程。

运行游戏并发现它和之前一样

如今，我们已经完成了对代码的重构，使其在逻辑上保持与之前雷同的功能，同时优化了代码的布局和可读性。从如今的运行结果来看，代码的活动与之前保持同等，这表明我们的调解是公道的，未引入额外的错误或影响原有功能的变更。
具体来说，我们引入了一种新的 Advance 机制，使得 layout 布局体可以更自然地管理和推进布局状态，制止了之前代码中手动盘算和更新坐标的繁琐利用。通过将 layout.addx、layout.aty、layout.spacingX、layout.spacingY、layout.depth 和 layout.lineAdvance 等变量会合管理，我们镌汰了代码冗余，进步了可维护性。
别的，我们调解了界限（bounds）的盘算方式，使其局部化，制止了界限盘算逻辑在代码各处分散的情况。如今，界限的盘算逻辑封装在 Advance 函数内部，确保了每个对象可以或许独立管理本身的界限，而不是依靠全局代码举行推进。这种改进不但镌汰了代码重复，还使得逻辑更加直观。
如今，全部的调解已经完成，而且测试结果表明代码功能仍然保持同等，这阐明我们的改进没有粉碎原有的功能。接下来，我们可以继续优化代码，使其更具扩展性和可读性。

引入 PlaceRectangle (game_debug.cpp)

如今，我们已经有了 layout 布局体，而且全部干系的代码都开始使用它。接下来的目的是进一步优化代码，提取出显着重复的部门，使其更加模块化和可复用。
在查抄 counter thread list 干系的代码时，我们发现此中的 dimension（尺寸） 盘算逻辑是手写的，但实际上这个盘算逻辑是通用的，并不必要每个地方都单独实现。因此，我们可以将其提取出来，使任何具有 dimension 属性的对象都可以或许复用这一盘算方法。
改进方案

我们筹划实现一个 PlaceRectangle 函数，它的作用是根据 dimension 的信息，返回恰当绘制的 矩形地区（rectangle）。如许，我们就可以制止手动盘算 minCorner 和 maxCorner 的重复利用，使代码更加简便和模块化。

• 原始代码的标题
  
  
  
  • 代码中多次手动盘算 minCorner 和 maxCorner，然后再基于它们创建 rectangle，导致重复逻辑。
    
  • 这些盘算完全依靠于 layout 的信息，如 layout.atX、layout.atY，没有须要在多个地方重新盘算。
    
  
  
• 新的 PlaceRectangle 筹划
  
  
  
  • PlaceRectangle 函数吸收 dimension 作为参数，并联合 layout 的当前状态，主动盘算矩形的位置。
    
  • 该函数会返回 minCorner 和 maxCorner，提供完备的矩形界说。
    
  • 如许，调用者无需关心具体的盘算细节，而是直接得到结果，进步了代码的可读性和复用性。
    
  
  

代码优化过程

• 我们在 layout 布局体中增长 PlaceRectangle 方法，使其可以或许根据传入的 dimension 主动盘算 minCorner 和 maxCorner。
  
• 盘算逻辑保持与之前雷同，但被封装在一个函数中，以便复用。
  
• 代码中全部手动盘算 minCorner 和 maxCorner 的地方，如今可以直接调用 PlaceRectangle，制止重复代码，进步代码整齐度。
  
• PlaceRectangle 方法的返回值是 rectangle(minCorner, maxCorner)，如许我们可以直接使用它，而不必要手动盘算每个角的坐标。
  

终极优化结果

• 镌汰代码重复：全部的 minCorner 和 maxCorner 盘算逻辑被封装在 PlaceRectangle 中，不必要每次手动写这些盘算。
  
• 进步代码可读性：如今代码逻辑更直观，调用 PlaceRectangle 即可得到正确的矩形地区，而不必要手动盘算界限。
  
• 加强可维护性：假如以后必要修改 rectangle 的盘算方式，只必要修改 PlaceRectangle，而不必要到每个调用位置举行修改。
  

通过这些优化，我们乐成消除了大量冗余代码，使 layout 布局更加清晰和易用，同时提升了整个代码的模块化水平。

运行游戏并发现它正常工作

理论上，如今全部的 性能分析（profile） 干系代码都已经颠末优化后的 layout 处理处罚，而且应该可以正常工作。颠末测试，结果符合预期，全部功能都如预期运行，没有出现标题，这证实白优化方案的可行性。
这意味着，我们乐成地将 绘制布局的逻辑 举行了提取和封装，使得 layout 布局可以或许更高效地管理界面元素的 尺寸盘算、对齐方式以及位置确定。同时，全部涉及 性能分析 的界面绘制代码如今都使用了这一改进后的 layout，制止了手动盘算 界限（bounds），大幅镌汰了冗余代码，进步了可维护性和可读性。
这是优化的第一步，接下来可以思量进一步改进，使得 layout 机制更加通用和机动。
使用 PlaceRectangle 盘算元素的布局

接下来，我们的 第二步优化 目的是复用刚刚提取的 layout 代码，使着实用于 位图（bitmap） 的布局盘算，从而镌汰代码重复，进步团体同等性。
当前在 位图缩放（bitmap scale） 盘算过程中，我们举行了一些 尺寸修正（dimension correction），好比 bitmap_display_dimx 之类的盘算。然而，这些盘算并不真正依靠 位图的具体位置（Min corner），而是仅仅必要确定位图的 尺寸（size）。换句话说，我们之前转达 Min corner 着实是多余的，由于终极的布局盘算才决定了它的实际位置。
因此，我们可以在 尺寸修正 之后，直接调用 layout 干系代码，让 layout 机制帮我们完成 位图的布局盘算。如允许以镌汰重复的逻辑，让全部布局干系的盘算保持同等，并确保代码更加 简便、可维护且易于扩展。
在这一优化过程中，我们还必要 正确处理处罚 size P（位图尺寸），并使用 layout 盘算出来的 bounds（界限） 来确定 位图终极的位置。如许，绘制位图时就可以直接使用 GetMinCorner(bounds)，而不再必要手动盘算位置。
如许优化后，我们的 位图布局 逻辑将会更加规范化，并与其他界面元素的布局盘算保持同等，使整个代码布局更加清晰公道。

运行游戏并体现使用雷同布局的元素

我们乐成压缩了代码，这是一项很好的改进。如今，无论是 计数器线程列表（counter thread list） 照旧 位图（bitmap） 的布局盘算，都已经使用了雷同的 layout 例程（layout routine）。这正是我们渴望的结果。
通过如许的优化，任何须要雷同布局功能的代码，都可以直接调用这一 layout 机制，主动完成 界限盘算（bounds calculation），而不必要再手动盘算具体位置。这不但镌汰了代码重复，还大大低落了维护本钱，使整个代码布局更加清晰、易用、可扩展。
接下来，我们渴望进一步优化和调解代码，使其更加通用化和易用化。
思量提取 SizeP 盘算的难度 (game_debug.cpp)

我们渴望进一步扩展 layout 机制，使其可以主动处理处罚 SizeBox（尺寸框）。在之前的实现中，我们发现 计数器线程列表（counter thread list） 和 位图（bitmap） 视图的 SizeBox 逻辑是雷同的。因此，假如 layout 机制 可以或许同一处理处罚 SizeBox，那么在以后添加雷同的功能时，我们就能直接复用代码，而不必要手动实现这些细节。
目的

在一个 良好的 UI 筹划 中，开发者应该可以或许 方便地 选择现有组件，而不必要关心底层的实现细节。因此，我们渴望做到：

• 任何组件 只要必要 SizeBox，都可以 直接声明，而不必要额外处理处罚布局逻辑。
  
• 主动盘算 SizeBox 的界限（bounds），确保布局体系可以或许正确放置它们。
  
• 镌汰代码重复，让 layout 机制 同一管理这些 SizeBox。
  

当前遇到的标题

• SizeBox 交互辩论：
  
  
  
  • 在布局中，我们发现 SizeBox 大概会与 bitmap 组件的交互地区发生辩论。
    
  • 比方，当我们实验拖动 SizeBox 时，体系大概会 误以为 我们正在利用 bitmap，从而触发错误的交互活动。
    
  
  
• Hit Testing（点击检测）标题：
  
  
  
  • 如今，我们的 点击检测（hit test）是按序次实行的，先检测到的对象优先级较低，而 后检测到的对象优先级较高。
    
  • 这意味着，假如 bitmap 的 hit test 发生在 SizeBox 之前，那么 SizeBox 的交互大概会被覆盖。
    
  
  
• 大概的办理方案：
  
  
  
  • 引入 Z 轴深度（Z-value）：通过给差别的 UI 组件分配 差别的 Z 轴层级，让更高层级的组件（如 SizeBox）可以正确拦截交互事故。
    
  • 优化交互检测机制：改进 hit test 逻辑，确保 鼠标指针位于 SizeBox 内部时，优先触发 SizeBox 的交互，而不是被底层的 bitmap 误捕获。
    
  • 调解架构：确保 layout 机制 在盘算 SizeBox 的界限 时，同时思量 交互优先级，制止错误的 UI 活动。
    
  
  

下一步筹划

• 优化 layout 机制，使其可以主动盘算 SizeBox 的布局信息。
  
• 调解 hit testing 逻辑，确保 SizeBox 能正确拦截交互事故。
  
• 测试新的布局机制，观察是否能办理 UI 交互标题。
  

简化并剥离 DEBUGDrawMainMenu 中的盘算 (game_debug.cpp)

我们正在实验优化 布局体系（layout system），让其更加模块化、简便，并镌汰代码重复。我们的目的是创建一个 通用的布局组件（layout element），可以或许主动处理处罚巨细调解（sizable）、交互（interaction）等活动，从而简化 UI 代码。

---

核心思绪

• 界说通用的布局元素（element）
  
  
  
  • 通过 begin_element(Rectangle, dimensions) 创建一个矩形布局元素。
    
  • 通过 EndElement() 竣事该元素，并返回是否处理处罚了鼠标交互。
    
  
  
• 支持可调解巨细（sizable）
  
  
  
  • 通过 、MakeElementSizable() 让当前元素支持尺寸调解。
    
  • 如许，任何 UI 组件只需调用这一方法，就能具备尺寸调解本领，而无需额外逻辑。
    
  
  
• 优化交互处理处罚（interaction handling）
  
  
  
  • EndElement() 返回一个布尔值，指示当前元素是否捕获了鼠标交互。
    
  • 如允许以制止引入 Z 轴排序（Z-value sorting） 这类复杂的机制，同时包管交互处理处罚的正确性。
    
  
  

---

实现步调

• 改进布局布局
  
  
  
  • 如今的代码中，布局信息（如尺寸、界限）必要在 元素竣事后（EndElement） 才华确定。
    
  • 我们调解逻辑，使其可以或许在元素创建时就转达尺寸地点，确保后续盘算能正确使用这些尺寸信息。
    
  
  
• 消除多余代码
  
  
  
  • 通过新的 element 机制，可以消除大量 手动处理处罚尺寸 和 交互 的代码。
    
  • 比方，原来必要手动盘算 SizeBox 和 interaction，如今这些都可以由 layout 机制主动管理。
    
  
  
• 优化文本布局
  
  
  
  • 如今可以使用 begin_element() 直接转达文本尺寸（text_bounds.width 和 layout_line_advance），制止手动盘算宽高。
    
  • 交互逻辑也可以通过 默认交互参数（default_interaction） 直接转达，进一步镌汰代码量。
    
  
  

---

当前优化结果

• 代码布局更清晰：
  
  
  
  • 如今的 UI 代码更紧凑，只必要调用 begin_element() 和 EndElement()，别的逻辑都交给 layout 机制 处理处罚。
    
  
  
• 镌汰代码重复：
  
  
  
  • 之前手动盘算 SizeBox、interaction、layout_spacing 等的代码已被移除，全部由 layout 组件 同一管理。
    
  
  
• 交互逻辑更可靠：
  
  
  
  • 通过 EndElement() 返回的交互信息，我们制止了 错误的鼠标捕获，无需额外的 Z 轴管理。
    
  
  

---

下一步筹划

• 测试新布局体系的兼容性，确保全部 UI 组件都能正确使用 begin_element() 和 EndElement()。
  
• 优化默认活动，比方是否必要显式转达 layout_spacing，照旧让 layout 机制 主动管理这些值。
  
• 进一步精简代码，实验将 文本渲染 也纳入 element 体系，以镌汰 UI 代码的复杂度。
  
  
  
  

引入 BeginElementRectangle、MakeElementSizable、DefaultInteraction 和 EndElement (game_debug.cpp)

• 函数概览
  
  
  
  • BeginElementRectangle：返回一个布局元素，吸收布局对象和指向矩形尺寸的指针。
    
  • 使元素可调解巨细：、MakeElementSizable 通过添加 size_box 使元素可调解巨细。
    
  • 设置默认交互方式：DefaultInteraction 将默认交互方式设为调试交互。
    
  • 竣事元素界说：EndElement 标记取元素界说完成。
    
  
  
• 核心逻辑
  如今全部逻辑都可以内联处理处罚，无需推迟到 EndElement 调用后再实行。这种方式更简便直观。
  
  
  
  • 变量 V2 dim 代表尺寸，并作为指针传入。
    
  • layout 变量存储布局信息。
    
  • size、interaction、bounds 都初始化为空值，以便后续盘算。
    
  
  
• 盘算元素的总尺寸
  
  
  
  • TotalDim 初始值为用户指定的 dim。
    
  • 若元素可调解巨细，则在 TotalDim 根本上扩展一个额外地区（即 size_box）。
    
  • size_box 的尺寸可设定为固定值，如 4px。
    
  
  
• 盘算矩形的界限
  
  
  
  • TotalMinCorner 和 TotalMaxCorner 代表整个元素的最小/最大角点。
    
  • InteriorMinCorner 和 InteriorMaxCorner 代表元素的内部矩形地区。
    
  • element_bounds 存储的是返回给用户的终极可用地区。
    
  
  
• 盘算元素的交互地区
  
  
  
  • size_box 仅作用于矩形右下角，答应用户拖动调解巨细。
    
  • 盘算 size_box 位置时，InteriorMaxCorner 作为出发点，TotalMaxCorner 作为尽头。
    
  
  
• 渲染边框
  
  
  
  • 通过绘制四条边框矩形来实现，分别是左边、右边、顶部和底部。
    
  • left_edge 和 right_edge 通过 TotalMinCorner 与 InteriorMinCorner 界说。
    
  • top_edge 和 bottom_edge 通过 TotalMinCorner 与 InteriorMaxCorner 盘算。
    
  
  
• 修正调试状态转达
  
  
  
  • debug_state 直接存入 layout，制止每次转达参数时重复利用。
    
  • MouseP 也放入 layout，确保全部函数都能正确获取鼠标位置。
    
  
  
• 优化代码
  
  
  
  • 移除 add_radius_to，直接对 dim 举行加法运算，进步简便性。
    
  • getWidth 干系调用修正为 GetDim x 和 GetDim y，确保盘算正确性。
    
  • push_rect 同一使用 ElementBounds 作为绘制地区。
    
  
  

团体来看，这部门代码告急完成了 UI 元素的初始化、尺寸调解、界限盘算、交互地区界说以及边框绘制，并举行了部门优化以进步可读性和实行服从。

运行游戏并发现错误

我们如今实现了几个关键的 UI 干系函数，此中包罗 begin_element_rectangle，它担当一个布局（layout）和指向矩形尺寸的指针，返回一个布局元素。别的，我们还实现了 make_element_sizable，用于添加可调解巨细的功能，即为元素添加尺寸框（SizeBox）。同时，我们提供了 set_default_interaction 作为默认交互方式，并通过 EndElement 来竣事元素的创建，体现该 UI 元素的全部属性已界说完成。
实现细节

我们决定将全部逻辑内联实现，而不是推迟到 EndElement 调用时再举行整合。如允许以在调用 EndElement 时直接构造 UI 元素，并确保全部盘算在此时完成。
在 begin_element_rectangle 里：

• layout 直接赋值。
  
• dim 赋值为传入的尺寸指针。
  
• size 指针初始化为空。
  
• interaction 设为默认交互方式（null）。
  
• bounds 设为 null。
  

当 EndElement 被调用时：

• 盘算元素的总尺寸（total dim），假如该元素是可调解巨细的，则必要在原始尺寸的根本上增长一个尺寸框（SizeBox）。
  
• 盘算总界限（total bounds），包罗 UI 组件的团体地区。
  
• 盘算内部界限（interior bounds），即实际内容地区，不包罗尺寸框。
  
• 盘算 minCorner 和 maxCorner，分别体现总界限和内部界限的最小、最大角坐标。
  
• 盘算尺寸框的矩形地区，即 SizeBox 位置。
  

对于尺寸框（SizeBox）：

• 盘算它的具体位置，使其出如今元素的右下角。
  
• 确保其交互逻辑可以或许正确处理处罚用户输入（如鼠标拖动等）。
  

在 EndElement 里，还必要处理处罚 mouseP（鼠标位置）：

• 这必要从 layout 布局中获取，并确保它可以或许被正确转达到 UI 组件中。
  
• 如允许以确保 SizeBox 可以正确相应鼠标交互。
  

绘制边框

为了更清晰地展示 UI 组件，我们决定绘制元素边框：

• 左边框：从 total minCorner 到 interior minCorner。
  
• 右边框：从 interior maxCorner 到 total maxCorner。
  
• 上边框：从 total minCorner Y 到 interior minCorner Y，在 X 方向上覆盖整个宽度。
  
• 下边框：从 interior maxCorner Y 到 total maxCorner Y，同样覆盖整个宽度。
  

别的，我们还筹划在 SizeBox 处绘制一个额外的交互地区，使其更加清晰可见，并便于用户利用。
调试和优化

• 修正 get_width 和 get_dim_y 等函数的调用，以匹配实际的数据布局。
  
• 通过 debugState 转达 UI 组件的调试信息，并优化其访问方式，以镌汰多次转达。
  
• 代码中大概存在一些小错误，比方 add_radius_to 盘算禁绝确，我们优化了这部门逻辑，使其直接在 dim 上举行简单的加法运算，而不使用 add_radius_to。
  

当前标题

• 大概在 SizeBox 盘算时没有正确添加条件查抄，导致某些情况下 SizeBox 被错误绘制。
  
• 必要进一步测试 EndElement 内部的交互逻辑，确保尺寸调解功能能正确相应用户输入。
  

接下来，我们将举行调试，查察终极的 UI 渲染结果，看看是否另有逻辑标题必要修正。
仅当元素具有巨细时才推送矩形，并制止让文本元素变得可调解巨细 (game_debug.cpp)

在实现 UI 元素的过程中，我们遇到了一些标题，并举行了修正和优化。
标题分析与修正

我们发现，全部的 UI 盘算（如界限盘算、尺寸调解等）只有在元素具有 SizeBox 时才会实行。这意味着，假如某个元素本身并未被标记为可调解巨细（sizable），那么全部这些盘算都不应该发生。因此，我们必要确保：

• 只有在元素具有 SizeBox 时，才实行干系的盘算和利用。
  
• 制止不须要的盘算，以进步性能和代码的清晰度。
  

之前的标题在于，某些盘算没有被正确地限定在 SizeBox 存在的情况下实行，导致了一些不测的活动。因此，我们必要确保：

• 假如 SizeBox 存在，则盘算界限、尺寸和 SizeBox 位置。
  
• 假如 SizeBox 不存在，则跳过这些盘算，以制止错误。
  

错误定位

在排查过程中，我们发现了几个关键错误：

• 错误地将某些 UI 盘算应用到了没有 SizeBox 的元素上
  
  
  
  • 这导致了一些偶然义的盘算，以致大概影响其他 UI 元素的布局。
    
  • 必要确保 SizeBox 干系代码只运行在 sizable 的元素上。
    
  
  
• 未正确天生 UI 元素
  
  
  
  • 在 element size 盘算时，我们必要正确地检测 SizeBox 是否存在，并据此决定是否推送矩形界限数据。
    
  • 之前的代码错误地实行了 push all the wrecks（推送全部矩形数据），纵然元素本身并不支持尺寸调解，导致了一些不测活动。
    
  
  
• 逻辑错误：忘记正确标记元素为 sizable
  
  
  
  • 代码逻辑上，我们必要正确地在元素创建时指定 sizable 属性，否则纵然代码流程是正确的，仍然不会触发尺寸调解功能。
    
  • 这一点属于利用失误（operator error），即手动设置时的疏忽。
    
  
  

修正方案

• 修正 if 语句，确保 SizeBox 盘算只在 sizable 元素上实行。
  
• 优化 EndElement 逻辑，制止对非 sizable 元素实行不须要的盘算。
  
• 查抄 element size 盘算流程，确保它正确地推送矩形数据，仅在 sizable 元素存在时实行推送。
  
• 在元素创建时正确设置 sizable，以制止后续盘算出现错误。
  

后续优化

• 增长调试输出，以便更快定位 SizeBox 干系的盘算错误。
  
• 进一步优化 EndElement 逻辑，镌汰不须要的盘算步调，进步运行服从。
  
• 确保全部 UI 组件的 SizeBox 逻辑保持同等，以制止差别组件间出现不兼容标题。
  

接下来，我们将测试修改后的代码，确保 SizeBox 的盘算和 UI 渲染逻辑正确无误。

添加 DefaultInteraction (game_debug.cpp)

在 UI 交互逻辑的实现过程中，我们如今必要添加默认的交互活动。
目的

• 为元素添加默认交互活动。
  
• 检测元素是否具有交互范例（interaction type），并根据该范例举行交互处理处罚。
  
• 假如元素交互地区（bounds）包罗当前交互位置，则更新调试状态（debug state）。
  
• 确保 SizeBox 在交互优先级上高于平凡元素，即便它们不重叠，也要在交互优先级上优先处理处罚 SizeBox。
  

---

实现方案

• 检测元素是否具有交互范例
  
  
  
  • 通过 interaction.type 判定当前元素是否被赋予了交互范例。
    
  • 假如 interaction.type 具有特定值，阐明该元素支持交互，必要进一步处理处罚。
    
  
  
• 判定交互位置是否在元素的 bounds 内
  
  
  
  • 接纳 IsInRectangle 方法，检测当前交互点是否落入元素的 bounds 范围内。
    
  • bounds 指的是元素的内部地区，而非整个 UI 组件。
    
  
  
• 更新调试状态
  
  
  
  • 假如 bounds 内检测乐成，则将 debugStates.nextHotInteraction 设置为当前交互的元素。
    
  • 如允许以跟踪当前正在被交互的 UI 组件，便于调试和优化。
    
  
  
• 处理处罚 SizeBox 交互优先级
  
  
  
  • 确保 SizeBox 交互优先级最高，即便 SizeBox 与平凡元素没有重叠，也要优先处理处罚它的交互逻辑。
    
  • 如许纵然 SizeBox 和其他交互元素发生重叠，SizeBox 仍然可以或许正确相应交互事故。
    
  
  

---

标题与办理

• 交互元素优先级管理
  必要确保 SizeBox 在交互处理处罚时优先级更高。如许即便某个平凡 UI 元素有交互，SizeBox 仍然能正确捕获交互事故。
  
• 交互界限检测的优化
  
  
  
  • bounds 的检测逻辑必要包管充足精准，以制止误判交互地区。
    
  • 可以优化 IsInRectangle 逻辑，使其更高效地判定当前鼠标或触摸点是否落在 bounds 内部。
    
  
  
• 调试工具的改进
  
  
  
  • debugStates.nextHotInteraction 必要正确更新，以便后续在调试工具中可以或许直观体现当前交互的元素。
    
  • 可以思量参加额外的日记或 UI 提示，方便跟踪交互状态的厘革。
    
  
  

---

后续优化方向

• 优化 SizeBox 与平凡交互元素的优先级管理，使着实用于更复杂的 UI 场景。
  
• 改进 IsInRectangle 逻辑，进步交互检测的正确度和性能。
  
• 增长可视化调试工具，资助开发者快速定位交互标题。
  
• 测试 SizeBox 在差别 UI 组件层级下的交互体现，确保它可以或许始终正确相应交互事故。
  

接下来，我们将举行测试，确保 SizeBox 交互的优先级正确，并观察 debugStates.nextHotInteraction 是否能正确反映当前交互状态。

运行游戏并看到齐备正常工作

如今来看，齐备都运行得相当顺遂，比预期的结果要好很多，整个流程比预想中更顺畅，根本上没有遇到必要额外调试的标题，这点让人非常满足。
当前渴望

• 交互逻辑和 UI 处理处罚工作已经顺遂完成。
  
• size box 组件可以或许正常工作，而且团体布局逻辑已经独立拆分，使得代码布局更加清晰。
  
• 全部 UI 元素的交互活动都能正确相应，测试结果良好。
  

---

进一步的扩展

如今已经具备了充足的根原来举行扩展，可以思量以下方向：

• 改进 size box 的可利用性
  
  
  
  • 如今 size box 只是简单的框架，但可以进一步优化，好比：
    
    
    
    • 让 size box 拥有更丰富的利用方式，好比可以直接从差别的边或角举行调解巨细。
      
    • 以致可以将其酿成一个厚边框（thick frame），答应用户从多个方向调解尺寸。
      
    
    
  
  
• 增长 UI 组件的通用属性
  
  
  
  • 如今创建新 UI 组件的代码量已经大幅镌汰，可以轻松扩展 UI 元素的本领。
    
  • 比方，可以为 UI 组件添加：
    
    
    
    • 可移动（movable） 属性，使组件可以被拖拽。
      
    • 可调解（resizable） 属性，使组件巨细可变。
      
    • 可旋转（rotatable） 属性，使组件支持旋转利用。
      
    
    
  • 通过这种方式，可以实现一个更加模块化和机动的 UI 体系。
    
  
  
• 优化布局逻辑
  
  
  
  • 如今全部的布局代码已经完全拆分，使得扩展新的 UI 组件变得非常简单。
    
  • 后续可以进一步优化，使得添加新 UI 组件时不必要修改已有的代码布局，只需增量添加新功能即可。
    
  
  

---

下一步筹划

• 暂缓进一步开发，留待来日诰日继续。
  
• 当进步度是一个很好的停顿点，由于根本架构已经搭建完成。
  
• 来日诰日可以专注于增长新功能，好比让 UI 元素更具互动性，并支持更多自界说利用。
  

团体来说，整个体系已经变得非常机动，如今可以非常轻松地添加新的 UI 组件，并赋予它们新的交互属性，使其具备更丰富的功能。