Masalah apa yang bisa terjadi jika Anda menggunakan API MonoGame dan API grafis yang mendasarinya?

Jenis masalah apa yang bisa ditemui jika mereka membuat game dengan MonoGame dan mulai membuat panggilan ke API grafis yang mendasarinya juga?

Sebagai contoh, jika saya ingin melakukan sesuatu dalam proyek MonoGame yang belum tentu didukung oleh MonoGame, atau saya tidak dapat menemukan dokumentasi / contoh yang tepat untuk tetapi saya dapat menemukan contoh bagaimana melakukannya di OpenTK, apakah saya mengatur diri saya sendiri untuk masalah jika saya mengimplementasikannya menggunakan OpenTK secara langsung saat menggunakan API MonoGame di tempat lain? Secara khusus saya mencari tahu apakah ada masalah besar yang diketahui yang mungkin hasil dari ini dan bukan sesuatu yang tidak jelas yang akan terjadi dalam kasus yang sangat jarang.

Saya mencoba melakukan sedikit riset melalui Google dan situs GD.SE itu sendiri dan saya tidak dapat menemukan banyak. Mungkin MonoGame telah benar-benar membahas sebagian besar pangkalannya, tetapi bagaimana jika saya secara manual ingin mengatasi salah satu masalah luar biasa atau fitur yang belum diimplementasikan?

Jika demikian, masalah macam apa yang mungkin muncul dan apakah ada cara untuk membantu mengurangi masalah ini?

Dalam kebanyakan kasus masalah ini akan masuk dalam kategori "perilaku tidak terdefinisi" (bukan dalam pengertian C ++, tetapi dalam pemahaman yang lebih luas).

Apa yang akan Anda lakukan pada dasarnya adalah menghindari abstraksi yang disediakan oleh MonoGame (sebagai contoh, ini tentu saja berlaku untuk API tingkat tinggi semacam itu). Dengan melakukannya, Anda dapat menyebabkan jaminan kelas invarian dilanggar, yang pada gilirannya berarti asumsi yang penulis MonoGame mampu menulis kode mereka di bawah mungkin tidak lagi benar dan kode mungkin berperilaku tidak terduga. Kode Anda sendiri benar-benar tidak bisa lagi bergantung pada jaminan inversi abstraksi, juga, karena Anda telah melanggarnya.

Perilaku tak terduga ini akan mencakup, secara potensial, keseluruhan keseluruhan perilaku tersebut dari artefak rendering sederhana hingga kerusakan atau kerusakan memori.

• Misalnya, jika Anda mengutak-atik keadaan rendering API dengan menjalankan MonoGame sendiri, itu mungkin tidak dapat mendeteksi perubahan negara itu (karena itu mungkin tidak akan polling API yang mendasari perubahan, itu lebih efisien untuk itu hanya dengan anggap itu yang mengendalikan API dan melacak perubahan itu sendiri). Karena itu, mungkin memutuskan, pada render pass berikutnya, bahwa itu tidak perlu memperbarui sesuatu yang sebenarnya harus diperbarui dan adegan Anda mungkin tidak benar render.

• Atau Anda dapat mengacaukan dengan API yang mendasarinya dan mengubah jumlah referensi beberapa objek perangkat (dengan asumsi D3D), yang berarti bahwa itu bisa dilepaskan sebelum waktunya dari di bawah MonoGame atau tidak sengaja dilepaskan, yang mengakibatkan kemungkinan kerusakan atau kebocoran sumber daya.

• Atau Anda bisa melakukan sesuatu yang berhasil, tetapi karena Anda sedang mengoceh dengan cara yang tidak didukung dan dengan fitur tidak berdokumen atau pola akses yang tidak terduga, Anda dapat menemukan kode Anda rusak parah pada rilis berikutnya.

• Atau Anda dapat melakukan sesuatu, itu berfungsi dengan baik untuk beberapa versi, tetapi kemudian Anda mengalami beberapa bug lain dan mengalami kesulitan melacaknya, jadi Anda meminta bantuan orang MonoGame, mungkin mengirimkan laporan bug karena Anda yakin itu masalah dalam kode mereka. Mereka tidak dapat mereproduksi bug, tentu saja, dan akhirnya diketahui bahwa Anda melakukan peretasan akses langsung aneh ini dan pada saat itu - terlepas dari apakah peretasan Anda adalah penyebab utama bug - mereka Mungkin akan berhenti menghabiskan sumber daya untuk perbaikan Anda hanya karena Anda melakukan hal yang tidak didukung (atau setidaknya, mereka mungkin akan memprioritaskan Anda).

Tentu saja, dalam beberapa kasus Anda mungkin benar - benar harus menghindari API, mungkin untuk mengatasi bug dalam perangkat lunak pengiriman yang tambalan resmi tidak akan dirilis pada waktunya. Jika Anda benar - benar harus melakukan ini, Anda harus mengambil pendekatan lunak: cobalah untuk mengatur akses langsung Anda sesempit mungkin, dan pastikan Anda mencoba untuk meninggalkan keadaan API yang mendasarinya tidak berubah mungkin ketika Anda selesai dengan campur tangan Anda . Ini bukan jaminan kesuksesan, tetapi bisa membantu.

Namun, idealnya Anda akan menghindari hal semacam ini sepenuhnya.

Saya setuju dengan jawaban Josh sepenuhnya tetapi saya ingin menambahkan beberapa pemikiran.

Tujuan MonoGame adalah untuk membawa XNA API ke banyak platform. Jika Anda menggunakan OpenTK secara langsung, Anda membatasi diri hanya untuk platform yang mendukungnya. Karena itu, Anda bisa kehilangan salah satu manfaat utama menggunakan abstraksi.

Jika Anda mendapati diri Anda ingin melakukan sesuatu yang tidak didukung MonoGame atau kesulitan menemukan dokumentasi, pertama-tama tanyakan pertanyaan yang lebih spesifik tentang apa yang Anda coba lakukan. Anda mungkin menemukan bahwa sudah ada cara untuk melakukannya atau mungkin fitur yang direncanakan belum diimplementasikan.

Setelah mendiskusikannya, mungkin Anda, atau orang lain, dapat mengimplementasikan fitur yang hilang di MonoGame untuk keuntungan semua orang.

Sehubungan dengan cara mengurangi masalah yang timbul saat menggabungkan kedua ide tersebut:

MonoGame adalah open source, modifikasi secara langsung dan Anda tidak perlu khawatir tentang masalah menggunakan keduanya.

Jika Anda pikir Anda membutuhkan barang-barang tambahan di dalamnya, maka dengan segala cara: buat garpu. Gunakan kode dasar itu dan tambahkan kode Anda di atasnya. Kompilasi ulang MonoGame dan mulai lagi. Ini juga memungkinkan Anda memperbarui garpu MonoGame saat diperbarui (tentu saja Anda harus memperbaiki konflik apa pun yang mungkin timbul dalam proses).