如果同时使用MonoGame API和基础图形API，会发生什么问题？

如果他们使用MonoGame进行游戏并开始对基础图形API进行调用，会遇到什么问题？

例如，如果我想在MonoGame项目中做某些事情，而MonoGame不一定支持该项目，或者我只是找不到合适的文档/示例，但是我可以找到一个在OpenTK中进行操作的示例，是吗？如果我在其他地方都使用MonoGame API时直接使用OpenTK实现它，是否会给自己带来麻烦？具体来说，我正在寻找是否有已知的大问题是由这种情况引起的，而不是在极少数情况下会发生的晦涩难懂的事情。

我尝试通过Google和GD.SE网站本身进行一些研究，但找不到很多。也许MonoGame确实涵盖了它的大部分基础，但是如果我手动想解决它的一个突出问题或尚未实现的功能该怎么办？

如果是这样，可能会出现什么样的问题？有什么方法可以减轻这些问题？

在大多数情况下，这些问题将属于“未定义行为”类别（不是C ++含义，而是更广泛的理解）。

您要做的实际上是规避MonoGame提供的抽象（例如，当然，基本上适用于任何此类更高级别的API）。这样做可能会导致违反类不变保证，这反过来又意味着MonoGame作者能够编写其代码的假设可能不再成立，并且代码可能表现异常。您自己的代码实际上也不能再依赖抽象的不变保证，因为您已经破坏了它们。

这种意外的行为可能包括从简单的渲染工件到崩溃或内存损坏的整个行为范围。

• 例如，如果您通过在MonoGame本身周围进行最终运行来弄乱某些渲染API状态，则它可能无法检测到该状态更改（因为它可能不会轮询底层API的更改，因此简单地进行处理会更有效假设它是控制API并自行跟踪这些更改的人）。因此，它可以在下一个渲染过程中决定不需要更新实际上应该更新的内容，并且场景可能无法正确渲染。

• 或者你可以与底层API混乱和改变一些设备对象（假设D3D），这意味着它可能会过早地释放MonoGame下或意外的引用计数不释放，导致可能的崩溃或资源泄漏。

• 或者，您可以做一些有用的事情，但是由于您正在以一种不受支持的方式并且具有未记录的功能或意外的访问模式，因此在下一个发行版中，您的代码可能会被严重破坏。

• 或者您可以做一些事情，它在几个版本上都可以正常工作，但是后来您遇到了其他错误，并且很难找到它，因此您向MonoGame的人员寻求帮助，也许会发送错误报告，因为您确定它的错误报告他们的代码有问题。当然，他们无法重现该错误，最终结果是您正在执行此奇怪的直接访问黑客程序，并且在那时–无论您的黑客程序是否是该错误程序的根本原因-他们可能会仅仅因为您在做不受支持的事情而停止花在修复上的资源（或者至少，它们可能会降低您的优先级）。

当然，在某些情况下，您可能绝对必须绕过API，也许是要解决无法及时发布官方补丁的运输软件中的错误。如果你绝对有这样做，则应采用软方法：尝试尽可能缩小范围的直接访问，并确保在完成干预后尽量使基础API的状态保持不变。 。这不是成功的保证，但可以提供帮助。

理想情况下，您将完全避免这种事情。

我完全同意Josh的回答，但我想补充一些想法。

MonoGame的目的是将XNA API引入许多平台。如果直接使用OpenTK，则只能将自己限制在支持OpenTK的平台上。因此，您可能会失去使用抽象的主要好处之一。

如果您发现自己想做MonoGame不支持的事情或找不到文档，请先询问您要做什么的更具体的问题。您可能会发现已经有一种方法，或者这是尚未实现的计划功能。

讨论之后，可能是您或其他人可以为每个人的利益实现MonoGame中缺少的功能。

关于如何减轻将这两种想法结合在一起产生的问题：

MonoGame是开源的，可以直接对其进行修改，您无需担心同时使用它们会带来的问题。

如果您认为还需要其他东西，则一定要：创建一个叉子。使用该基本代码，并在其上面添加您的基本代码。重新编译MonoGame，您就可以开始了。这也可以让您在更新MonoGame分支时对其进行更新（当然，您必须修复过程中可能出现的任何冲突）。