iis 发布网站 500,企业机房建设公司,仿唯品会wordpress商城主题,织梦和wordpress哪个好无论如何#xff0c;我们今天有一些调试工作要做#xff0c;因为昨天做了一些修改#xff0c;结果没有时间进行调试和处理。我们知道自己还有一些需要解决的问题#xff0c;却没有及时完成#xff0c;所以我们想继续进行这些调试。对我们来说#xff0c;拖延调试工作总是…无论如何我们今天有一些调试工作要做因为昨天做了一些修改结果没有时间进行调试和处理。我们知道自己还有一些需要解决的问题却没有及时完成所以我们想继续进行这些调试。对我们来说拖延调试工作总是很烦人。
一些论坛上的人已经猜测了可能存在的错误他们的推测或许是对的但我们并不确定。正如之前提到的我们昨晚停下来了没能抽出时间来逐步调试因此我们不清楚实际情况以及具体的错误在哪里。
修复 IsInRectangle 剪切/粘贴错误
有人报告了一个错误肯定是一个问题无论是不是我们自己引起的但确实是个 bug。昨天在进行剪切和粘贴操作时我们没有检查矩形三的 Z 坐标。这个问题显而易见但我们的数学库可能还有很多问题。为了澄清我们目前并不太关注这些 bugs主要是想在架构方面做一些实验等一切都准备好之后再进行更多的测试和修正。
当有问题被指出时及时修复是很好的。这次问题是我们在处理矩形时没有考虑 Z 坐标尤其是在从二维变成三维时矩形的维度发生了变化导致了这个问题。其他的内容似乎并没有太大变化主要还是在潜在的向量处理上没有什么需要改动的地方。 修复 ChunkPositionFromTilePosition 错误
有一个错误被报告了出现在世界代码中。昨天的更改涉及到将所有操作转换为三维但在处理临时世界构建时我们使用了错误的坐标系统。具体来说在计算瓷砖空间中的物体位置时错误地使用了“ChunkDimInMeters”而实际上应该使用“TileSideInMeters”。这种错误导致了世界变得更加稀疏因为我们错误地将物体放置在了瓷砖边界处而现在没有瓷砖的概念了。
此外这个问题暴露了一个更深层次的错误虽然这只是一个定位辅助工具用来帮助我们在处理更复杂的世界时做一些瓷砖相关的操作但它显然是个 bug。幸运的是大家在论坛上指出了这个问题让我们能够修正它。通过这种方式仿佛拥有了一大批代码审查员可以实时帮忙寻找并指出错误这对调试过程来说是一个非常有价值的补充。
尽管修复了这些问题我们不确定它们能否完全解决最初的问题。可能并不会完全修复还需要进一步的检查和修正。 调试 MapIntoChunkSpace 精度问题
出现了一个问题似乎在更改代码时导致了地图切分的错误。特别是我们在将地图坐标映射到大块空间时存在精度问题。当数字变得较大时精度下降导致难以准确确定物体应该位于哪个瓷砖或哪个大块区域。这种问题本来是可以预料到的尤其是在处理大规模世界构建时。
为了解决这个问题未来我们可能会采用将世界分割成局部区域的策略并在浮点坐标系统中进行处理。这样在构建较大的世界时可以通过移动焦点来优化处理而不是让世界变得过于庞大而难以管理。我们将继续在本地坐标系下进行操作并将整个区域移动到新的位置以确保精度问题不会影响到整个世界的构建。
这意味着我们的目标是能够构建更大的世界而不仅仅是将所有内容都放入一个浮点系统中从而避免让世界变得过于复杂或庞大。这个方法将使我们能够处理更大、更复杂的虚拟世界。 目前关于构建一个庞大的游戏世界虽然我们面临精度问题但并不特别担心。通过增加局部坐标原点附近的精度我们希望能够在将来解决这些问题尤其是在不依赖大范围世界构建的情况下。虽然当前存在一些问题但我们计划在未来通过调整epsilon值使其趋近于零避免这些问题影响最终效果。
我们遇到的一些错误如世界构建时的精度问题其实并不算严重。尽管地图的计算误差可能较大但这并没有阻止世界的继续扩展。当前的错误主要是由于坐标范围的扩大导致的精度损失。尽管如此错误的程度并不会对整体结构产生根本性影响仍然能够顺利进行其他方面的工作。
总的来说这些问题虽然存在但并不会阻止项目的继续发展。将来当世界构建逐步转向局部坐标系统时我们将能够更加高效地处理这些问题并确保游戏世界的质量。
调试跳过世界问题
目前我们可以跳跃进入下一个层级并返回地面但Z轴的处理存在一些问题尚未完全正确。问题出现在跳跃时虽然Z轴的加速度已经包括了重力负9.8 m/s²并与水平方向的运动方程一起计算但跳跃的表现仍有些异常。
首先跳跃的代码应该在按下空格键时设置一个向上的速度但跳跃的行为看起来并不像预期的那样。虽然在处理Z轴时没有出现明显错误我们仍然需要仔细检查可能是由于某些细节未完全调整好。
在跳跃过程中如果角色跳得足够高可能会进入一个新的Z轴区间导致角色未能回到地面。为了进一步解决这个问题需要查看并调试代码特别是涉及Z轴运动方程和跳跃逻辑的部分。
总体来说虽然有些异常情况出现但问题并不严重需要进一步检查Z轴的跳跃和回归地面的逻辑。
图示跳跃到下一个更高的块
在跳跃代码的处理过程中角色的Z轴位置是根据相对于相机的位置进行检查的。当角色跳跃并超越当前的Z轴位置时假设跳跃高度足够角色会进入下一个Z轴区间。然而代码仅检查角色的Z轴位置是否小于零而没有检测是否与其他物体发生碰撞导致角色可以穿越平台并继续跳跃。
具体而言跳跃的逻辑目前存在一个问题由于代码只判断Z轴位置是否小于零来确定角色是否已经落地这样的检查方式忽略了平台间的相对位置导致角色跳过平台后并不会停在上面。实际上跳跃的行为应该像平台游戏一样角色能够穿越上面的平台但落地时应该停在平台上。
另外关于相机的更新当前的代码似乎只使用了大块Z来进行相机的跟踪而没有进行完整的Z轴跟踪。这可能是导致跳跃行为异常的原因之一。因此调试需要首先集中在角色跳跃时Z轴行为的异常上确认是否是由于相机跟踪的处理不完全导致的问题。 发现问题
问题的根本原因在于相机的Z轴跟踪。之前角色的Z轴位置与相机同步导致跳跃时相机也跟着角色的Z轴变化从而使得角色的跳跃行为发生偏移。当禁用了相机跟随功能后角色的跳跃行为恢复正常看起来是正确的。接下来目标是通过调整Z轴偏移来防止相机继续跟踪角色的Z轴位置避免影响跳跃过程。
在进一步调整时可以采取只处理X和Y坐标的方法保存Z轴偏移量并在需要时恢复相机的原始Z轴偏移。通过这种方式跳跃过程中的Z轴变化就不会影响到相机的位置跟踪。
尽管目前仍然可以通过无限跳跃来实现角色逐层上升但接下来可能会需要进行更多的思考和调整。这些调整虽然可能看起来不必要但为了实现更加精确的控制还是决定继续进行优化即便这种优化可能看似没有多大意义。 接下来Minkowski 包含测试
接下来将继续处理其他任务比如实现Minkowski包含测试和可更新反弹等功能。
Frinstancesδ
接下来的工作将集中在实现起伏不定的局面处理这需要通过多个实例进行思考。例如需要处理一些场景如上下楼层、进入洞穴、与楼下的BOSS互动等。这些问题的处理方式与Minkowski包含测试相关尽管Minkowski本身并不是强制要求使用的概念但它是讨论空间内实体交互和模拟的一种方法。
目前在模拟区域内有一个实体聚集的概念我们通过检查某个边界内的所有实体判断哪些实体与边界重叠并将这些实体放入模拟区域。这个过程主要用于在有限的地理区域内模拟实体的交互因为我们不能在一个时间内模拟整个世界中的所有实体。因此通过分区域模拟可以更有效地处理实体间的互动。
然而现有的代码存在问题主要是没有考虑到实体本身的大小。之前的处理方式未能准确反映实体的尺寸导致在模拟过程中出现问题。因此接下来的任务是更新代码使其能够更加精确地处理实体的大小以确保更高效和更清晰的模拟过程。
图示问题
在当前的实现中实体的边界只考虑了二维空间的宽度和高度但为了更精确地模拟实体在三维空间中的交互必须加入实体的深度信息。因此需要将实体的尺寸概念改为三维v3以存储所有三个坐标轴上的尺寸。
此外在模拟区域的聚集过程中现有的包含测试只检查实体的中心点位置是否在边界内这对大尺寸的实体来说可能不够准确。因为即使实体的中心点在边界内实体的实际边界可能超出了该范围因此需要改进这一测试。
一种改进的方法是使用Minkowski包含测试它可以通过扩展边界来考虑实体的尺寸将距离添加到矩形的每一边从而生成一个新的测试矩形进行重叠检测。另一种方法是直接进行矩形重叠测试检查两个矩形是否相交。两种方法的效果相似选择哪一种方式并不会产生显著的差别但必须进行其中的一种。
此外还存在一个相关问题需要进一步探讨是否解决。
AABBAxis-Aligned Bounding Box轴对齐包围盒是一种用于表示物体空间范围的几何形状常用于碰撞检测、物体筛选等应用中。AABB的特点是它的边界与坐标轴对齐即盒子的每一条边都与坐标系的X、Y以及Z轴在三维空间中平行。它是一个矩形二维或长方体三维并且其边界不随物体的旋转而旋转因此称为“轴对齐”。
AABB的特性
简易计算由于AABB的边界与坐标轴平行计算其是否与其他物体重叠或是否包含其他物体的范围非常简单通常只需要比较边界的坐标。空间效率AABB通常用于快速判断两个物体是否相交尤其在3D游戏和物理引擎中用于简化碰撞检测的计算。局限性AABB并不考虑物体的旋转导致在某些情况下物体可能会被包裹在一个比实际需要的空间更大的AABB内从而降低精度。
示例
在二维空间中一个AABB可以由两个点表示左下角和右上角。这两个点的坐标分别代表该AABB的最小和最大边界。在三维空间中一个AABB则由前述的两个点扩展为六个数值最小和最大X、Y、Z坐标。
由于其计算简单AABB在许多实时系统中非常常见尤其是游戏开发和物理模拟中。
相关问题在测试区域外查找碰撞实体
目前面临的问题是如何有效地处理实体聚集的区域。我们有一些瓦块tile chunks这些瓦块存储了实体。当我们进行聚集操作时我们遍历与聚集区域接触的瓦块。这些瓦块的范围通常是9个正方形我们对这些区域内的实体进行测试以避免每次都遍历整个世界中的所有实体这样做是为了提高效率。
然而问题在于如果一个实体恰好位于某个瓦块的边缘且该瓦块没有被当前聚集区域包含那么这个实体就会被忽略即使它的边界可能部分超出了当前区域。如果聚集区域不恰好对齐或者实体本身比较大这个问题会变得更加明显。
为了解决这个问题有几种可能的方法。首先我们可以考虑双重存储实体任何跨越多个瓦块的实体都可以同时存储在这些瓦块中这样就能确保这些实体在所有涉及的区域内被正确处理。另一个方法是扩展聚集区域考虑到最大实体的半径这样即使某个实体的边界超出了聚集区域的边缘也能够被包含在内。
扩展聚集区域的优点是能够确保所有实体都能被正确测试但缺点是如果大多数实体比较小而只有个别实体非常大那么每次进行聚集操作时系统会浪费大量资源去检查这些不必要的大范围区域。因此这种方法的效率可能会受到影响。
另一方面双重存储方法能够处理跨瓦块的实体但如果所有实体大小差异不大双重存储会导致大量不必要的重复操作浪费存储和计算资源。
目前还不清楚哪种方法最为有效因为缺乏关于实体大小分布的具体信息。考虑到实现的简易性和避免不必要的复杂性选择扩展聚集区域的方法可能更为合理尤其是在大多数实体相对较小的情况下。
实现更简单的选项
这段内容描述了一个游戏开发过程中关于实体半径、速度、区域更新、碰撞检测等方面的实现和调整。主要涉及以下几个方面 实体半径和区域更新 游戏中有一个最大实体半径约为五米用来定义实体的最大影响范围。模拟区域会根据该半径进行更新确保区域的大小能够适应所有可能的实体。 最大半径和速度限制 通过设定最大实体半径和最大速度防止出现过大的实体或过快的速度。为了确保物理模拟的稳定性开发者考虑通过多种方式如增加安全边际来防止实体超出设定的最大值。速度被定义为最大实体速度与时间步长DT的乘积。 实体速度和碰撞检测 对实体的速度进行校验确保它不会超过设定的最大速度。开发者使用了长度平方的方式来避免计算实际的速度值从而优化性能。为了确保速度不超过限制开发者考虑使用断言assert来检查速度如果超出最大速度可以进行限制。 跳跃和重力处理 游戏中的跳跃功能存在问题实体的速度没有在接触地面时清零导致速度继续增长。通过调整代码确保实体在接触地面时将垂直方向的速度归零从而避免跳跃速度不正常。 区域碰撞检测和维度处理 在模拟区域内开发者计划添加基于矩形的碰撞检测以确保实体和区域的交集能够被正确检测到。实体的维度被定义为宽度、高度和深度开发者将相关代码中的“高度”改为实体的维度以提高代码的通用性。 后续计划 游戏开发者计划进一步调整和优化与Z轴相关的运动代码如跳跃和物理反应并进行更多的探索和实验以改进实体的垂直运动。预计未来会对这些部分进行更深入的开发。
这些更改和改进旨在确保游戏中的实体运动和碰撞系统更加稳定和真实避免出现过大的实体或速度问题同时改进游戏体验。 你在 APCS 上的成绩是什么
参加AP计算机科学考试时即使已经有七年没有使用考试所用语言编程依然获得了满分5分。考试所用的语言是Pascal这对于大多数人来说并不是常见的编程语言。尽管早在9岁时就学习过Pascal但已经很久没有使用它。尽管如此仍然能够取得满分这令人感到惊讶和困惑。这种现象让人怀疑尽管存在某种程度的成绩膨胀考试的评分标准可能存在不合理之处因为如果一个人很久没有使用考试所用的编程语言通常不应该轻易取得最高分。
但你在高中上过哪些数学课成绩如何
回顾高中时所修的数学课程以及获得的成绩虽然这些内容与当前讨论的话题无关但并不妨碍提及。既然没有特别相关的主题问题那么谈论一些离题的内容也无妨。
我注意到你有很多函数是内联的。使用常规函数和内联函数有什么区别
在编程中使用内联函数时其意义和效果并不像以前那样直接。使用内联函数通常是为了提示编译器将函数展开到每个调用处。然而在现代编译器中内联函数并不总是如预期那样进行展开。由于采用了“统一构建”方式所有代码都在同一个文件中编译器能够访问所有的函数并根据需要自行决定是否进行内联优化。因此在这种构建方式下inline关键字更多的是作为一种提示而不是强制指令。实际上编译器可能会对未标记为内联的函数进行优化内联处理。
此外现代链接时代码生成Link Time Code Generation, LTO也可以自动进行函数内联无需显式标记。因此即使某些函数没有显式声明为内联编译器仍可能会对它们进行内联优化。如果希望确保某些函数被强制内联可能需要使用其他编译器指令而不仅仅依赖inline关键字。
总的来说inline现在更多的是一个编程上的提示而不再是编译器执行内联优化的绝对指令。
你觉得还需要多久
如果每天只一个小时那么完成一个完整的游戏开发项目将需要相当长的时间。假设需要三到四个月的时间来编写整个游戏的代码而每天只投入一个小时这样计算下来大约需要600天差不多是两年左右。虽然游戏的开发可能看起来每一天都能完成一些小任务但实际进展较慢每天工作一小时意味着每次能做的事情有限。因此整个过程会持续很长时间因为每天的工作量并不多。
你能看看玩家的碰撞吗他们生成时很接近彼此
玩家在游戏中生成的位置非常接近彼此导致可能发生碰撞或其他相关问题。这里提到的问题可能是玩家生成时位置相互重叠或接近过近导致游戏中的物体或角色发生意外的交互。
四维向量有任何好的使用案例吗
四维向量有两个非常常见的用途几乎可以说是无处不在的应用虽然之前已经看过其中一个案例但尚未实际使用过。因此可能会为此添加一个四维向量。
四维向量
四维向量例如四元数有两个非常常见的用途。第一个用例是四元数它是一个四元素的向量通常存储为 X、Y、Z 和 W。四元数通常用于表示旋转其中前三个元素表示旋转轴最后一个元素 W 表示旋转角度的余弦值的一半。四元数的 V 部分即 XYZ表示旋转轴的正弦值的一半与旋转轴本身的乘积。四元数在许多引擎代码中有广泛应用尽管在某些项目中可能不需要完整的3D旋转。
第二个常见用途是颜色存储通常使用 RGBA 格式其中 A 表示透明度。颜色可以通过一个四元素的向量表示其中 RGB 表示颜色A 表示透明度。这种存储方式在很多情况下都非常实用。
一般编程问题你是否倾向于以某种顺序排列你的函数——公共/私有/静态——或者是按流向——函数A调用函数B你通常会把它们一个个放在一起吗还是你从不考虑这些
函数的排序主要是根据它们的调用关系进行的。通常会将被调用的函数放在调用它们的函数之前这样就不需要额外的声明。除此之外函数的排序还会根据文件来进行将功能相关的函数放在一起。例如所有与模拟相关的函数放在一个文件中所有与实体相关的函数放在另一个文件中。这样做是为了保持代码的整洁方便查看和管理。尽管编辑器对代码的可视化支持有限但这种排序方式能够帮助提高代码的可维护性和可读性。
你会将 Minkowski 碰撞实现扩展到处理旋转/任意凸多边形吗
目前关于旋转和任意凸多边形的碰撞检测是否会扩展的问题尚不明确。对于旋转可能并不需要因为目前不涉及旋转的操作。虽然将来可能会需要处理旋转但不确定是否会实现尤其是在动画旋转方面。碰撞检测本身通常不适用于动画旋转现有的碰撞求解器并没有很好地处理旋转特别是持续旋转。可以通过基于搜索的方式来处理这种情况但通常没有非迭代的方式来精确处理动画旋转。
对于旋转常见的做法是使用起始或结束位置的旋转或者取中间位置的旋转但没有一种方法能够精确地处理正在旋转的物体之间的碰撞除非增加维度。现有的如GJK算法也无法处理这种情况。因此旋转的处理通常并不完全准确尤其是动态旋转的碰撞检测通常会用一些近似方法例如通过细分、计算旋转可能覆盖的最大面积来进行碰撞测试。总的来说旋转动画导致的碰撞检测要比不动旋转的情况复杂得多而且通常需要一种不那么完美的解决方案。因此最好尽量避免这种情况以减少碰撞检测的复杂度。
为什么 Win32 鼠标处理那么麻烦 - WM_LMOUSEDOWN 但如果你离开窗口就没有 WM_LMOUSEUPWM_MOUSELEAVE 除非你被 AltTab 走SetCapture 帮助如果你离开窗口除非 AltTab…
Windows平台上的鼠标事件处理存在一些问题尤其是关于鼠标按下和松开事件的处理。对于这种情况使用原始输入raw input方式查询鼠标可能会更好一些。之所以Windows的鼠标处理会让人觉得烦恼是因为操作系统本身在输入事件传递给应用程序时存在一些问题许多平台在这方面都有类似的缺陷。Windows并没有很好地将输入事件传递到应用程序中这个问题一直存在也可能很难得到解决。
实体的 Z 索引什么时候会发生
关于实体的Z索引Z索引通常用于表示元素在3D空间中的深度或者在2D渲染中的前后层级关系。它指的是一个实体在某一坐标轴通常是Z轴上的位置决定了该实体在视觉上是位于前景还是背景。如果提到Z索引时没有特别的上下文可能是指此类深度或层级信息。
这里有谁足够大怀念“大太空过山车”吗
提到的内容涉及一个过时的电视节目《The Great Space Coaster》并且提到节目中一位名为Gary的人物。尽管没有具体的细节但可以推测这是对过去某段时间文化或节目的一种怀念或调侃。
你预见到项目会发展到接受其他开发者的拉取请求和合并请求来修复bug、添加功能或其他吗当然你得先开始使用版本控制避免硬盘损坏
提到的内容讨论了项目未来是否会接受其他开发者的拉取请求pull request以修复 bug 或添加功能。目前没有明确计划接收外部贡献。项目的代码将在游戏发布两年后进入公共领域届时任何人都可以托管自己的代码库并可能会有社区参与维护。
我从大概第12集跳到现在的直播所以如果这个问题之前已经回答过抱歉为什么玩家需要跳跃
提到的内容解释了玩家跳跃机制的设计。玩家本身并不需要跳跃这一功能是因为有人提议而加入的用来测试 Z 轴的运动。虽然跳跃并不是游戏的核心功能但它在测试飞行敌人等元素时起到了作用因此暂时保留。最终当 Z 轴的功能完善后跳跃功能可能会被移除。
使用 Xbox 控制器创建第二个玩家它会非常接近由键盘创建的玩家导致两者无法同时移动
在处理多个角色生成时如果它们相互重叠游戏目前没有处理这些重叠的机制。为了增强程序的健壮性计划通过重投影等方法解决实体重叠问题。这不仅能解决实体间的碰撞问题还能修正由于浮动点不精确而导致的实体进入另一个实体的情况。开发计划是让这些问题得到处理以便在未来不会成为阻碍确保碰撞检测能更加健壮。虽然这项工作可能不会很快完成但会在后续的碰撞检测修复中逐步完善。
目前游戏中最优雅/最性感的代码是哪一段
目前游戏中最具吸引力的部分可能是实现了循环即时代码编辑功能。这项技术使得整个游戏能够回溯并执行一些非常酷的操作。在编程时可以设置所谓的循环点并重复播放这一部分内容且在播放的过程中开发者可以实时编辑代码。例如可以直接更改角色的外观甚至给角色添加额外的元素如头部。通过这种方式游戏的代码可以在运行时被动态编辑从而即时反映出用户输入或其他变动极大提高了开发效率。很多游戏引擎甚至一些商业引擎通常并不具备这样的功能因此这一功能非常特别和强大。
如果我没记错的话你的代码中到目前为止没有使用任何前向声明也没有遇到循环依赖。这是巧合吗还是你在编写新函数/结构体时有意避免它们
在编写代码时采取了一种排序方法即按照函数之间的调用关系进行排序确保需要先声明的函数位于调用它们的函数之上。这种做法避免了使用前置声明减少了不必要的依赖。至于循环依赖的情况通常并不常见因此也很少需要进行前置声明。只有在少数情况下例如在处理“添加实体”时因为该操作可能会引入新的实体这时才需要使用前置声明。总体而言排序方法让代码更加整洁避免了过多的复制和粘贴也不必处理复杂的前置声明问题。
实体的从后到前绘制
关于敌人绘制顺序目前还没有确定何时实现从后到前的绘制。首先可能会实现实体的从后到前的绘制至于敌人的绘制可能会继续采用从前到后的顺序因为这种方法通常更快。敌人的从前到后的绘制可能会在实现渲染器时才会考虑。
你有在实现任何高级数据结构吗你会推荐学习汇编语言来帮助优化 C 语言程序吗有什么练习建议吗
在项目中已经实现了一些较为复杂的数据结构例如一个基于哈希表并包含链表的“块存储”结构。虽然它不是非常复杂但相比于简单的链表或哈希表它融合了两者的特性因此可以算作一个进阶数据结构。不过目前没有实现完全独特或无法分类的数据结构常见的数据结构已经能满足需求因为它们可以用来构建大部分所需的功能。
至于学习汇编语言关键并不是要能编写汇编代码而是能够阅读它。了解编译器的工作原理并通过分析 CPU 执行的内容来理解性能瓶颈是优化程序的一个重要方面。能读懂汇编代码对于理解程序运行的底层机制至关重要尽管大多数情况下不需要用汇编语言编写完整的程序。
是否存在所谓的“硬件”光标与“软件”鼠标光标的区别
关于硬件光标与软件光标的区别历史上经历了几个阶段。在最初的时代硬件光标和软件光标并没有区别因为显示器只是简单地设置像素并显示没有专门的硬件光标。在这种情况下如果要绘制一个光标就需要多次绘制常用XOR绘制方法来避免重复覆盖避免额外的资源消耗。
随着鼠标光标变得越来越重要尤其是在游戏硬件中光标通常作为精灵sprites来实现。硬件开始支持覆盖显示专门处理鼠标光标这时硬件光标和软件光标之间的区别显而易见。
然而随着3D图形技术的发展硬件开始处理所有的位图合成包括鼠标光标和窗口的渲染。现在所有内容包括光标都是通过图形硬件进行合成的因此将鼠标光标称为硬件光标已经不再具有实际意义。总的来说硬件光标和软件光标的区别经历了多次变化现在已经趋于模糊。
仓库: https://gitee.com/mrxiao_com/2d_game
