Які проблеми можуть виникнути, якщо ви скористаєтесь API MonoGame та графічним API?

З якими проблемами можна було б зіткнутися, якби вони робили гру з MonoGame і почали телефонувати також до базового графічного API?

Наприклад, якщо я хотів щось зробити в MonoGame проект, який MonoGame не обов'язково підтримував, або я просто не міг знайти належну документацію / приклад, але я міг знайти приклад того, як це зробити в OpenTK, чи я налаштувати себе на проблему, якщо я впроваджую його безпосередньо за допомогою OpenTK, використовуючи API MonoGame скрізь? Зокрема, я хочу дізнатися, чи існують якісь великі проблеми, які можуть бути наслідком цього, а не щось незрозуміле, що трапляється в дуже рідкісних випадках.

Я спробував зробити невелике дослідження через Google і на самому сайті GD.SE, і я не міг багато чого знайти. Можливо, MonoGame дійсно охопив більшість своїх баз, але що робити, якщо я вручну хотів обійти одну із своїх невирішених проблем або функцію, яка ще не реалізована?

Якщо так, то які проблеми можуть виникнути і чи є способи допомогти пом'якшити ці проблеми?

У більшості випадків ці проблеми підпадають під категорію "невизначеної поведінки" (не в сенсі С ++, а в більш широкому розумінні).

Те, що ви робите, - це, по суті, обійти абстракцію, надану MonoGame (як приклад, це, звичайно, стосується будь-якого такого API вищого рівня). Тим самим ви можете спричинити порушення гарантій класної інваріантності, що в свою чергу означає, що припущення, під якими автори MonoGame змогли записати свій код, вже не можуть бути правдивими, і код може поводитися несподівано. Ваш власний код насправді вже не може покладатися на інваріантні гарантії абстракції, оскільки ви їх порушили.

Ця несподівана поведінка потенційно буде включати всю гаму такої поведінки: від простих рендеринга артефактів до збоїв або пошкодження пам'яті.

• Наприклад, якщо ви поспілкуєтеся з деяким станом API візуалізації, закінчившись навколо MonoGame, він може не змогти виявити зміни цього стану (оскільки він, ймовірно, не запитає базовий API на зміни, для нього ефективніше просто припустимо, це той, хто контролює API і відстежує ці зміни сам). Отже, при наступному пропуску візуалізації може вирішити, що не потрібно оновлювати щось, що насправді має бути оновлено, і ваша сцена може не відображатись правильно.

• Або ви можете поплутатися з базовим API і змінити кількість посилань на якийсь об’єкт пристрою (якщо припустити D3D), це означає, що він може бути передчасно випущений з-під MonoGame або випадково не випущений, що призведе до ймовірного збою або витоку ресурсу.

• Або ви можете зробити щось, що працює, але, оскільки ви обмінюєтесь непідтримуваним чином і з недокументованими функціями або несподіваними моделями доступу, ви можете знайти свій код жахливо зламаний у наступному випуску.

• Або ви можете щось зробити, це працює чудово для декількох версій, але пізніше ви натрапите на якусь іншу помилку і зіткнетеся з її труднощами, тому ви звертаєтесь до людей у ​​MonoGame про допомогу, можливо, надсилаючи звіт про помилку, оскільки ви впевнені, що її проблема в їхньому коді. Вони, звичайно, не можуть відтворити помилку, і, нарешті, виявляється, що ви робите цей дивний хакер з прямим доступом, і в цей момент - незалежно від того, ваш хакер є першопричиною помилки, чи ні Напевно, ви перестанете витрачати ресурси на ваше виправлення просто тому, що ви робите непідтримувану річ (або, принаймні, вони, ймовірно, позбавлять вас пріоритетності).

Звичайно, в деяких випадках вам, можливо, доведеться обійти API, можливо, щоб обійти помилку в транспортному забезпеченні, для якого офіційний патч не буде випущений вчасно. Якщо ви абсолютно повинні це зробити, ви повинні скористатися м'яким підходом: постарайтеся максимально обмежити свій прямий доступ і переконайтеся, що ви намагаєтеся залишити стан базового API якомога незмінним, коли закінчите з замішуванням. . Це не гарантія успіху, але може допомогти.

В ідеалі ви все-таки уникатимете подібних речей.

Я повністю погоджуюся з відповіддю Джоша, але хотів би додати кілька думок.

Мета MonoGame - наблизити API XNA до багатьох платформ. Якщо ви безпосередньо використовуєте OpenTK, ви обмежуєте себе лише тими платформами, які його підтримують. Тому ви можете втратити одну з головних переваг використання абстракції.

Якщо ви хочете зробити щось, що MonoGame не підтримує, або у вас є проблеми з пошуком документації, спочатку задайте більш конкретний питання, що ви намагаєтеся зробити. Ви можете виявити, що є спосіб зробити це вже, або, можливо, це запланована функція, яка ще не була реалізована.

Після обговорення цього можливо, що ви чи хтось інший зможете реалізувати відсутні функції в MonoGame на користь кожному.

Щодо того, як пом'якшити проблеми, що виникають при поєднанні цих двох ідей:

MonoGame є відкритим кодом, модифікуйте його безпосередньо, і вам не потрібно турбуватися про проблеми від використання обох.

Якщо ви думаєте, що вам потрібні додаткові речі в ньому, то всіма силами: створіть виделку. Використовуйте цей базовий код і додайте свій поверх нього. Перекомпілюйте MonoGame і ось там. Це також дозволить вам оновити виделку MonoGame, коли вона оновлюється (звичайно, вам доведеться виправити будь-які конфлікти, які можуть виникнути в процесі).