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.
