Quais problemas podem ocorrer se você usar a API MonoGame e a API gráfica subjacente?

Em que tipos de problemas alguém poderia se deparar com o MonoGame e começar a fazer chamadas para a API gráfica subjacente também?

Por exemplo, se eu quisesse fazer algo em um projeto MonoGame que o MonoGame não necessariamente apoiasse, ou simplesmente não consegui encontrar a documentação / exemplo adequado, mas poderia encontrar um exemplo de como fazê-lo no OpenTK, estou me preparando para problemas se eu implementá-lo usando o OpenTK diretamente enquanto estiver usando a API MonoGame em qualquer outro lugar? Especificamente, estou procurando descobrir se existem grandes problemas conhecidos que possam resultar disso e não algo obscuro que acontecerá em casos muito raros.

Tentei fazer uma pequena pesquisa via Google e no próprio site GD.SE e não consegui encontrar muita coisa. Talvez o MonoGame tenha realmente coberto a maior parte de suas bases, mas e se eu quisesse solucionar manualmente um de seus problemas pendentes ou um recurso que ainda não foi implementado?

Em caso afirmativo, que tipo de problemas podem surgir e existem maneiras de ajudar a mitigar esses problemas?

Na maioria dos casos, esses problemas se enquadram na categoria de "comportamento indefinido" (não no sentido C ++, mas em um entendimento mais amplo).

O que você estaria fazendo é essencialmente contornar a abstração fornecida pelo MonoGame (como exemplo, isso obviamente se aplica a basicamente qualquer API de nível superior). Ao fazer isso, você pode fazer com que as garantias invariantes de classe sejam violadas, o que, por sua vez, significa que as suposições sob as quais os autores do MonoGame foram capazes de escrever seu código podem não ser mais verdadeiras e o código pode se comportar inesperadamente. Seu próprio código também não pode mais confiar nas garantias invariantes da abstração, desde que você as violou.

Esse comportamento inesperado incluirá, potencialmente, toda a gama desse comportamento, de artefatos simples de renderização a falhas ou corrupção de memória.

• Por exemplo, se você mexer com algum estado da API de renderização executando o próprio MonoGame, talvez não seja possível detectar essa alteração de estado (porque provavelmente não pesquisará as alterações na API subjacente, é mais eficiente simplesmente suponha que é o único que controla a API e rastreia essas alterações). Conseqüentemente, pode decidir, na próxima passagem de renderização, que não precisa atualizar algo que deve ser atualizado e sua cena pode não ser renderizada corretamente.

• Ou você pode mexer com a API subjacente e alterar a contagem de referência de algum objeto do dispositivo (assumindo o D3D), o que significa que ele pode ser lançado prematuramente sob o MonoGame ou acidentalmente não liberado, resultando em uma provável falha ou vazamento de recursos.

• Ou você pode fazer algo que funcione, mas como você está mexendo de uma maneira não suportada e com recursos não documentados ou padrões de acesso inesperados, poderá encontrar seu código terrivelmente quebrado no próximo lançamento.

• Ou você pode fazer algo, ele funciona bem para algumas versões, mas depois você encontra algum outro bug e tem dificuldade em localizá-lo, então pede ajuda ao pessoal do MonoGame, talvez enviando um relatório de bug, porque você tem certeza de que um problema no código deles. Eles não podem reproduzir o bug, é claro, e finalmente surge que você está fazendo esse hackery estranho de acesso direto e nesse ponto - independentemente de seu hackery ser ou não a causa raiz do bug - eles provavelmente deixará de gastar recursos em sua correção, simplesmente porque você está fazendo uma coisa não suportada (ou pelo menos, eles provavelmente a priorizarão).

É claro que, em alguns casos, você pode absolutamente precisar burlar a API, talvez para solucionar um erro no software de remessa, para o qual o patch oficial não será lançado a tempo. Se você absolutamente precisar fazer isso, deve adotar a abordagem mais suave: tente definir o escopo do seu acesso direto o mais estreitamente possível e tente deixar o estado da API subjacente o mais inalterado possível quando terminar sua intromissão. . Não é uma garantia de sucesso, mas pode ajudar.

Idealmente, você evitará esse tipo de coisa completamente.

Concordo plenamente com a resposta de Josh, mas gostaria de acrescentar algumas idéias.

O objetivo do MonoGame é levar a API do XNA para muitas plataformas. Se você estiver usando o OpenTK diretamente, estará se restringindo apenas às plataformas que o suportam. Portanto, você pode perder um dos principais benefícios do uso da abstração.

Se você deseja fazer algo que o MonoGame não suporta ou está tendo problemas para encontrar a documentação, primeiro faça a pergunta mais específica sobre o que você está tentando fazer. Você pode achar que já existe uma maneira de fazer isso ou talvez seja um recurso planejado que ainda não foi implementado.

Após discuti-lo, pode ser que você, ou outra pessoa, possa implementar os recursos ausentes no MonoGame para benefício de todos.

No que diz respeito a como mitigar os problemas decorrentes da combinação dessas duas idéias:

O MonoGame é de código aberto, modifique-o diretamente e você não precisa se preocupar com problemas ao usar os dois.

Se você acha que precisa de mais coisas, crie um garfo. Use esse código base e adicione o seu sobre ele. Recompile o MonoGame e pronto. Isso também permitirá que você atualize o fork do MonoGame quando for atualizado (é claro que você precisará corrigir quaisquer conflitos que possam surgir no processo).