MonoGame APIと基になるグラフィックAPIの両方を使用すると、どのような問題が発生する可能性がありますか？

MonoGameでゲームを作成していて、基礎となるグラフィックAPIへの呼び出しも開始した場合、どのような問題が発生する可能性がありますか？

たとえば、MonoGameが必ずしもサポートしていないMonoGameプロジェクトで何かをしたい場合、または適切なドキュメント/例が見つからなかったが、OpenTKでそれを行う方法の例を見つけることができた場合、他の場所でMonoGame APIを使用しているときにOpenTKを使用して直接実装すると、問題が発生しますか？具体的には、これが原因である可能性がある既知の大きな問題があり、非常にまれなケースで発生する不明瞭な問題がないかどうかを調べています。

GoogleとGD.SEサイト自体を介して少し調べてみましたが、あまり見つけることができませんでした。MonoGameがそのベースのほとんどを本当にカバーしているかもしれませんが、未解決の問題またはまだ実装されていない機能の1つを手動で回避したい場合はどうなりますか？

もしそうなら、どのような問題が発生する可能性があり、これらの問題を軽減するのに役立つ方法はありますか？

ほとんどの場合、これらの問題は「未定義の動作」のカテゴリに分類されます（C ++の意味ではありませんが、より広い理解で）。

あなたがやろうとしていることは、基本的にMonoGameによって提供される抽象化を回避することです（例として、これはもちろん、基本的にそのようなより高レベルのAPIに適用されます）。そうすることで、クラスの不変の保証に違反する可能性があります。つまり、MonoGameの作成者がコードを記述できたという仮定が真でなくなり、コードが予期せず動作する可能性があります。あなたがそれらを壊したので、あなた自身のコードはもはや抽象の不変の保証にももはや依存することができません。

この予期しない動作には、単純なレンダリングアーティファクトからクラッシュやメモリ破損まで、そのような動作の全範囲が含まれる可能性があります。

• たとえば、MonoGame自体をエンドランしてレンダリングAPIの状態をいじる場合、状態の変化を検出できない場合があります（おそらく、基になるAPIの変更をポーリングしないため、単純に行う方が効率的です。 APIを制御するものであり、それらの変更自体を追跡するものと想定します）。その結果、次のレンダーパスで、実際に更新する必要があるものを更新する必要がないと判断し、シーンが正しくレンダリングされない場合があります。

• または、基盤となるAPIをいじって、一部のデバイスオブジェクト（D3Dを想定）の参照カウントを変更することもできます。つまり、MonoGameの下から時期尚早に解放されるか、誤って解放されず、クラッシュまたはリソースリークの可能性があります。

• または、機能するものを実行することもできますが、サポートされていない方法で、文書化されていない機能や予期しないアクセスパターンでいたずらしているため、次のリリースでコードがひどく壊れる可能性があります。

• または、何かできるかもしれませんが、いくつかのバージョンでは問題なく機能しますが、後で他のバグに遭遇して追跡するのが難しいため、MonoGameの担当者に助けを求めます。彼らのコードの問題。もちろん、バグを再現することはできません。最終的に、この奇妙なダイレクトアクセスハッカーを実行していることが判明し、その時点で-ハッカーがバグの根本的な原因であるかどうかに関係なく-おそらく、サポートされていないことを行っているという理由だけで、修正にリソースを費やすのをやめるでしょう（少なくとも、優先順位が低くなる可能性があります）。

もちろん、APIを完全に回避しなければならない場合もあります。おそらく、正式なパッチが間に合わずに出荷されるソフトウェアのバグを回避するためです。あなたが絶対場合は持っている範囲を狭くできる限りあなたの直接アクセスを試して、あなたはあなたがおせっかいで終了したとき、あなたができるだけ変わらないように根本的なAPIの状態のままにしようとすることを確認してください。これを実行するには、ソフトなアプローチを取る必要があります。これは成功を保証するものではありませんが、役立ちます。

ただし、このようなことは完全に回避するのが理想的です。

私はジョシュの答えに完全に同意しますが、いくつか考えを追加したいと思います。

MonoGameの目的は、XNA APIを多くのプラットフォームに提供することです。OpenTKを直接使用している場合は、OpenTKをサポートするプラットフォームのみに制限されます。したがって、抽象化を使用することの主な利点の1つを失う可能性があります。

MonoGameがサポートしていない何かをしたい場合や、ドキュメントを見つけるのに問題がある場合は、まず、何をしようとしているのかについて、より具体的な質問をしてください。すでにそれを行う方法があるか、またはまだ実装されていない計画された機能である場合があります。

それについて話し合った後、あなたや他の誰かが不足している機能をMonoGameに実装して、みんなの利益になるかもしれません。

これらの2つのアイデアを組み合わせることに起因する問題を軽減する方法について：

MonoGameはオープンソースであり、直接変更するので、両方を使用することによる問題を心配する必要はありません。

あなたがそれに追加のものを必要とすると思うなら、ぜひともフォークを作成してください。その基本コードを使用して、その上に独自のものを追加します。MonoGameを再コンパイルすれば完了です。これにより、更新時にMonoGameフォークを更新することもできます（もちろん、プロセスで発生する可能性のあるすべての競合を修正する必要があります）。