tModLoader中UI缩放对NewText方法的文本换行影响分析

问题概述

在tModLoader游戏模组开发框架中，Main.NewText方法用于在游戏中显示文本消息。该方法会自动将长文本消息换行显示，但其换行计算存在一个关键缺陷：未考虑游戏界面缩放比例(UIScale)的影响。

技术细节分析

当前实现机制

当前Main.NewText方法通过以下方式计算最大文本宽度：

num = Main.screenWidth - 320;

这一计算方式存在两个主要问题：

1. 当屏幕分辨率改变时，系统会调用chatMonitor.OnResolutionChange()方法，触发ChatMessageContainer.MarkToNeedRefresh标记，使ChatMessageContainer重新计算最大消息宽度。然而，当用户调整UI缩放比例时，没有类似的刷新机制。

2. ChatMessageContainer.Refresh方法在计算最大消息宽度时，没有将Main.UIScale因素纳入考虑。

实际表现影响

在不同UI缩放比例下，文本显示会出现以下问题：

• 高缩放比例(如170%)：文本换行计算错误，导致部分文本超出屏幕可视范围
• 低缩放比例(如50%)：文本过早换行，造成不必要的空白区域
• 分辨率变化时：虽然会重新计算，但UI缩放变化时不会触发重新计算

相关渲染问题

在深入分析过程中，还发现了一个相关的渲染问题：ChatManager.DrawColorCodedString方法在绘制彩色文本时，会逐个单词进行绘制。这种实现方式会导致：

1. 对每个单词单独调用DynamicSpriteFont.MeasureString测量尺寸
2. 手动跟踪绘制位置
3. 未能正确处理某些字符(如'A'、'R'、'7')的负右间距(rightPadding)值

这会导致实际绘制的文本宽度与ChatMessageContainer.Refresh中通过Utils.WordwrapStringSmart计算的预期宽度不一致，因为后者会测量整行文本并正确处理字符间距。

解决方案建议

针对上述问题，建议从以下方面进行改进：

1. UI缩放感知：修改ChatMessageContainer.Refresh方法，使其在计算最大宽度时考虑Main.UIScale因素

2. 刷新机制扩展：为UI缩放变化添加类似于分辨率变化的刷新机制，确保缩放比例改变时也能重新计算文本布局

3. 文本绘制优化：考虑重构ChatManager.DrawColorCodedString的绘制逻辑，使其测量方式与换行计算保持一致，或者找到更高效的整体绘制方法

对模组开发的影响

对于tModLoader模组开发者而言，了解这一问题十分重要：

1. 当模组需要显示大量文本信息时，应考虑不同UI缩放比例下的显示效果
2. 对于关键信息显示，可能需要实现自定义的文本显示逻辑来规避此问题
3. 在测试模组时，应在不同UI缩放设置下验证文本显示效果

总结

tModLoader中的文本显示系统在UI缩放处理方面存在不足，主要影响长文本消息的自动换行功能。这一问题的根本原因在于宽度计算未考虑缩放因素，以及相关刷新机制不完善。虽然对普通玩家影响较小，但对模组开发者展示复杂信息时可能造成困扰。理解这一问题的本质有助于开发者更好地控制模组中的文本显示效果。