Jakie problemy mogą wystąpić, jeśli korzystasz zarówno z MonoGame API, jak i bazowego API graficznego?


10

Na jakie problemy można się natknąć, jeśli robią grę z MonoGame i zaczynają również nawiązywać połączenia z bazowym interfejsem API grafiki?

Na przykład, jeśli chciałbym zrobić coś w projekcie MonoGame, którego MonoGame niekoniecznie obsługiwał, lub po prostu nie mogłem znaleźć odpowiedniej dokumentacji / przykładu, ale mogę znaleźć przykład tego, jak to zrobić w OpenTK, czy jestem ustawiam się na kłopoty, jeśli zaimplementuję go za pomocą OpenTK bezpośrednio podczas korzystania z MonoGame API wszędzie indziej? W szczególności chcę dowiedzieć się, czy znane są jakieś duże problemy, które mogą wynikać z tego, a nie coś niejasnego, co zdarzy się w bardzo rzadkich przypadkach.

Próbowałem przeprowadzić małe badania za pośrednictwem Google i samej strony GD.SE i nie mogłem znaleźć wiele. Może MonoGame naprawdę obejmuje większość swoich baz, ale co jeśli ręcznie chciałbym obejść jeden z nierozwiązanych problemów lub funkcję, która nie została jeszcze zaimplementowana?

Jeśli tak, jakie problemy mogą się pojawić i czy są jakieś sposoby na złagodzenie tych problemów?

Odpowiedzi:


12

W większości przypadków problemy te należałyby do kategorii „niezdefiniowane zachowanie” (nie w sensie C ++, ale w szerszym rozumieniu).

To, co robisz, to w zasadzie omijanie abstrakcji dostarczanej przez MonoGame (na przykład, oczywiście dotyczy to zasadniczo każdego takiego API wyższego poziomu). W ten sposób możesz spowodować naruszenie niezmiennych gwarancji klas, co z kolei oznacza, że ​​założenia, do których autorzy MonoGame byli w stanie napisać kod, mogą już nie być prawdziwe, a kod może zachowywać się nieoczekiwanie. Twój własny kod nie może już dłużej polegać na niezmiennych gwarancjach abstrakcji, ponieważ je złamałeś.

To nieoczekiwane zachowanie obejmie potencjalnie całą gamę takich zachowań, od prostych renderowania artefaktów po awarie lub uszkodzenie pamięci.

  • Na przykład, jeśli masz problemy z renderowaniem stanu interfejsu API, uruchamiając się wokół samej gry MonoGame, może nie być w stanie wykryć tej zmiany stanu (ponieważ prawdopodobnie nie będzie sondował interfejsu API pod kątem zmian, jest bardziej wydajny, aby po prostu Załóżmy, że to on kontroluje interfejs API i sam śledzi te zmiany). W związku z tym może zadecydować przy następnym przejściu renderowania, że ​​nie musi aktualizować czegoś, co w rzeczywistości powinno zostać zaktualizowane, a Twoja scena może nie być poprawnie renderowana.

  • Możesz też zepsuć się z bazowym interfejsem API i zmienić liczbę referencji niektórych obiektów urządzenia (zakładając D3D), co oznacza, że ​​może on zostać przedwcześnie zwolniony z MonoGame lub przypadkowo nie zwolniony, co może spowodować awarię lub wyciek zasobów.

  • Lub możesz zrobić coś, co działa, ale ponieważ bawisz się w nieobsługiwany sposób i nieudokumentowanych funkcjach lub nieoczekiwanych wzorcach dostępu, możesz znaleźć okropnie uszkodzony kod w następnej wersji.

  • Lub możesz coś zrobić, działa dobrze dla kilku wersji, ale później napotkasz inny błąd i masz trudności ze śledzeniem go, więc poprosisz ludzi z MonoGame o pomoc, być może wysyłając raport o błędzie, ponieważ jesteś pewien, że jest to problem w ich kodzie. Oczywiście nie mogą odtworzyć błędu, a w końcu okazuje się, że robisz to dziwne hackowanie z bezpośrednim dostępem i w tym momencie - niezależnie od tego, czy Twoja hackery jest przyczyną błędu - czy nie Prawdopodobnie przestanę wydawać zasoby na poprawkę tylko dlatego, że robisz coś nieobsługiwanego (a przynajmniej zapewnią ci priorytet).

Oczywiście w niektórych przypadkach może być absolutnie konieczne obejście API, być może w celu obejścia błędu w oprogramowaniu wysyłkowym, dla którego oficjalna łatka nie zostanie wydana na czas. Jeśli absolutnie musisz to zrobić, powinieneś zastosować podejście miękkie: spróbuj ograniczyć swój bezpośredni dostęp tak wąsko, jak to możliwe, i upewnij się, że próbujesz pozostawić stan bazowego interfejsu API tak niezmieniony, jak to możliwe, gdy skończysz wtrącanie się . To nie jest gwarancja sukcesu, ale może pomóc.

Idealnie jednak całkowicie tego unikniesz.


3

W pełni zgadzam się z odpowiedzią Josha, ale chciałbym dodać kilka przemyśleń.

Celem MonoGame jest przeniesienie interfejsu API XNA na wiele platform. Jeśli używasz OpenTK bezpośrednio, ograniczasz się tylko do tych platform, które go obsługują. Dlatego możesz stracić jedną z głównych zalet korzystania z abstrakcji.

Jeśli chcesz zrobić coś, czego MonoGame nie obsługuje lub masz problemy ze znalezieniem dokumentacji, najpierw zadaj bardziej szczegółowe pytanie, co próbujesz zrobić. Może się okazać, że jest już sposób, aby to zrobić, a może jest to planowana funkcja, która nie została jeszcze zaimplementowana.

Po omówieniu może być możliwe, że Ty lub ktoś inny zaimplementujesz brakujące funkcje w MonoGame z korzyścią dla wszystkich.


3

W odniesieniu do tego, jak złagodzić problemy wynikające z połączenia tych dwóch pomysłów:

MonoGame jest open source, zmodyfikuj go bezpośrednio i nie musisz martwić się problemami związanymi z korzystaniem z obu.

Jeśli uważasz, że potrzebujesz w nim dodatkowych rzeczy, to na pewno: stwórz widelec. Użyj tego kodu bazowego i dodaj swój. Ponownie skompiluj MonoGame i gotowe. Pozwoliłoby to również zaktualizować widelec MonoGame, gdy jest on aktualizowany (oczywiście będziesz musiał naprawić wszelkie konflikty, które mogą powstać w trakcie procesu).


Ktokolwiek zagłosował, proszę podać powód, abym mógł dowiedzieć się następnym razem, jeśli poczujesz, że napisałem coś nie tak.
Timotei

1
Jak to odpowiada na pytanie?

1
Cóż, można obejść wszelkie problemy wynikające z połączenia tych dwóch (monogame + podkreślający API) poprzez bezpośrednią modyfikację źródła monogame (to znaczy w jednym miejscu). Zwróć uwagę na jego ostatnie pytanie: „Jeśli tak, jakie problemy mogą się pojawić i czy są jakieś sposoby na złagodzenie tych problemów?”
Timotei

Dobrze, Timotei, wprowadziłem niewielką edycję, aby wyjaśnić, co odpowiadasz.
MichaelHouse

Podoba mi się ten punkt. Myślę, że naprawdę sensowniej byłoby spróbować znaleźć odpowiednie miejsce w monogrze do zaimplementowania funkcji niż zaimplementować ją specjalnie we własnej bibliotece gier. Istnieją oczywiste pułapki związane z niewłaściwym zrozumieniem monogry i wciąż nieprawidłowym jej wdrażaniem, ale to zupełnie inny problem.
SpartanDonut
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.