¿Qué problemas podrían ocurrir si utiliza tanto la API de MonoGame como la API de gráficos subyacente?


10

¿En qué tipo de problemas podría encontrarse uno si estuviera haciendo un juego con MonoGame y también comenzara a hacer llamadas a la API de gráficos subyacente?

Por ejemplo, si quisiera hacer algo en un proyecto de MonoGame que MonoGame no necesariamente apoyara, o simplemente no pudiera encontrar la documentación / ejemplo adecuado, pero podría encontrar un ejemplo de cómo hacerlo en OpenTK, ¿estoy? ¿Tengo problemas si lo implemento usando OpenTK directamente mientras uso la API de MonoGame en cualquier otro lugar? Específicamente, estoy buscando averiguar si se conocen problemas importantes que puedan resultar de esto y no algo oscuro que sucederá en casos muy raros.

Intenté investigar un poco a través de Google y el sitio GD.SE en sí y no pude encontrar mucho. Tal vez MonoGame realmente ha cubierto la mayoría de sus bases, pero ¿qué pasa si quisiera solucionar manualmente uno de sus problemas pendientes o una característica que aún no está implementada?

Si es así, ¿qué tipo de problemas podrían surgir? ¿Hay alguna forma de ayudar a mitigar estos problemas?

Respuestas:


12

En la mayoría de los casos, estos problemas caerían en la categoría de "comportamiento indefinido" (no en el sentido de C ++, sino en una comprensión más amplia).

Lo que estaría haciendo es esencialmente eludir la abstracción proporcionada por MonoGame (como ejemplo, esto, por supuesto, se aplica básicamente a cualquier API de nivel superior). Al hacerlo, puede hacer que se infrinjan las garantías invariables de clase, lo que a su vez significa que las suposiciones en las que los autores de MonoGame pudieron escribir su código ya no son ciertas y el código puede comportarse inesperadamente. Su propio código realmente ya no puede confiar en las garantías invariantes de la abstracción, ya que las ha roto.

Este comportamiento inesperado incluirá, potencialmente, toda la gama de tales comportamientos, desde simples artefactos de renderizado hasta bloqueos o daños en la memoria.

  • Por ejemplo, si juega con algún estado de API de renderizado al ejecutar MonoGame, es posible que no pueda detectar ese cambio de estado (porque probablemente no sondeará los cambios en la API subyacente, es más eficiente que simplemente suponga que es el que controla la API y rastrea esos cambios en sí mismo). En consecuencia, puede decidir, en el próximo pase de renderizado, que no necesita actualizar algo que de hecho debería actualizarse y su escena puede no renderizarse correctamente.

  • O podría meterse con la API subyacente y alterar el recuento de referencia de algún objeto del dispositivo (suponiendo D3D), lo que significa que puede liberarse prematuramente de MonoGame o accidentalmente no liberarse, lo que resulta en un posible bloqueo o pérdida de recursos.

  • O bien, podría hacer algo que funcione, pero debido a que se está burlando de una manera no compatible y con características indocumentadas o patrones de acceso inesperados, puede encontrar su código horriblemente roto en la próxima versión.

  • O podría hacer algo, funciona bien para algunas versiones, pero luego se encuentra con otro error y tiene dificultades para rastrearlo, por lo que le pide ayuda a la gente de MonoGame, tal vez enviando un informe de error porque está seguro de que Un problema en su código. No pueden reproducir el error, por supuesto, y finalmente resulta que estás haciendo esta piratería de acceso directo y, en ese momento, independientemente de si tu piratería es la causa principal del error, Probablemente deje de gastar recursos en su solución simplemente porque está haciendo algo sin soporte (o al menos, probablemente lo desestabilizarán).

Por supuesto, en algunos casos, a pesar de todo puede tener para eludir la API, tal vez para evitar un error en el software para el que no se dará a conocer el parche oficial en el tiempo de envío. Si absolutamente tiene que hacer esto, debe tomar el enfoque suave: intente alcanzar su acceso directo de la manera más estrecha posible y asegúrese de intentar dejar el estado de la API subyacente lo más inalterable posible cuando haya terminado con su intromisión. . No es una garantía de éxito, pero puede ayudar.

Sin embargo, idealmente evitarás este tipo de cosas por completo.


3

Estoy completamente de acuerdo con la respuesta de Josh, pero me gustaría agregar algunas ideas.

El propósito de MonoGame es llevar la API XNA a muchas plataformas. Si está utilizando OpenTK directamente, se está restringiendo solo a aquellas plataformas que lo admiten. Por lo tanto, podría perder uno de los principales beneficios de usar la abstracción.

Si desea hacer algo que MonoGame no admite o tiene problemas para encontrar la documentación, primero haga la pregunta más específica de lo que está tratando de hacer. Puede encontrar que ya hay una manera de hacerlo o tal vez es una característica planificada que aún no se ha implementado.

Después de discutirlo, es posible que usted u otra persona puedan implementar las funciones que faltan en MonoGame para beneficio de todos.


3

Con respecto a cómo mitigar los problemas que surgen al combinar esas dos ideas:

MonoGame es de código abierto, modifíquelo directamente y no necesita preocuparse por los problemas de usar ambos.

Si crees que necesitas cosas adicionales, entonces, por supuesto: crea un tenedor. Use ese código base y agregue el suyo encima. Recompila MonoGame y listo. Esto también le permitiría actualizar la bifurcación MonoGame cuando se actualice (por supuesto, tendrá que solucionar cualquier conflicto que pueda surgir en el proceso).


Quien haya votado en contra, diga su razón, para que pueda saber la próxima vez si siente que escribí algo mal.
Timotei

1
¿Cómo responde esto a la pregunta?

1
Bueno, uno podría evitar cualquier problema que surja de combinar esos dos (monogame + la API subyacente) modificando directamente la fuente del monogame (es decir, en un solo lugar). Tenga en cuenta su última pregunta: "Si es así, ¿qué tipo de problemas pueden surgir y hay alguna forma de ayudar a mitigar estos problemas?"
Timotei

Buen punto Timotei, he hecho una pequeña edición para que quede un poco más claro cuál es tu respuesta.
MichaelHouse

Me gusta este punto Creo que realmente tendría más sentido intentar encontrar un lugar apropiado dentro del monojuego para implementar una característica que implementarla específicamente en su propia biblioteca de juegos. Existen las trampas obvias de no entender el monojuego correctamente y aún implementarlo incorrectamente, pero ese es otro problema por completo.
SpartanDonut
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.