XNA i C # vs procesory 360 w kolejności

Po przeczytaniu tego stwierdzenia , wydaje mi się, że prawdopodobnie mają rację (ponieważ Xenon i CELL BE są bardzo wrażliwe na rozgałęziony i ignorujący pamięć podręczną kod ), ale słyszałem, że ludzie świetnie sobie radzą z C #.

Czy to prawda, że ​​nie można zrobić nic profesjonalnego z XNA, czy może po prostu brakowało plakatu, co czyni XNA zabójczym API dla tworzenia gier?

Jako profesjonalista nie mam na myśli tego, że można na tym zarabiać, ale bardziej w tym sensie, że bardziej profesjonalne gry mają modele fizyki i systemy animacji, które wydają się poza zasięgiem języka z tak wyraźnymi barierami dla wewnętrznych . Jeśli chciałem napisać system kolizji lub silnik dynamiki płynów dla mojej gry, nie sądzę, że C # daje mi szansę, aby to zrobić, ponieważ generator kodu wykonawczego i brak elementów wewnętrznych przeszkadza w wydajności.

Wydaje się jednak, że wiele osób dobrze sobie radzi z tymi ograniczeniami, tworząc udane gry, ale najwyraźniej omijając problemy. Nie zauważyłem, że żadna z gier XNA robi coś bardziej złożonego niż to, co jest już dostarczane przez biblioteki lub obsługiwane przez shadery. Czy to unikanie bardziej złożonej dynamiki gry z powodu ograniczeń C # , czy po prostu ludzie koncentrują się na tym ?

Szczerze mówiąc, nie mogę uwierzyć, że wojna AI może utrzymać tyle jednostek AI bez pewnego podejścia zorientowanego na dane lub niektórych brudnych hacków C #, aby działało lepiej niż standardowe podejście, i myślę, że to częściowo moje pytanie, jak ludzie włamali się do C #, więc jest w stanie zrobić, co kodery gier robią naturalnie z C ++?

OK, po prostu wybić kilka dziur w tym rant, który połączyłeś:

• „C # korzysta z interpretera„ Just In Time ” - źle - jest to kompilator JIT . Po jednokrotnym zastosowaniu metody JIT skompilowany kod jest ponownie wykorzystywany dla każdego wywołania. Skompilowany kod jest bardzo podobny do natywnego, wstępnie skompilowanego kodu.
• „Procesor ksenonowy to„ procesor ”na miejscu - czy on ma na myśli„ w porządku ”? - I: „Procesor ksenonowy nie ma przewidywania gałęzi” . Sugeruje to, że oznacza to, że kompilacja JIT w naturalny sposób wytwarza zły kod, który musi być ponownie uporządkowany przez CPU i powoduje wiele rozgałęzień - co jest absolutnym nonsensem . Te same porady dotyczące wydajności dla tej architektury procesora dotyczą zarówno C ++, jak i C #.
• „[JIT] wymaga ciągłego opróżniania na 360” - źle, skompilowany kod może być przechowywany w pamięci podręcznej, jak każdy normalnie skompilowany kod. (Jeśli ma na myśli spłukanie rurociągu, patrz powyższy punkt).
• „generics [...] używają generowania kodu” - generics są JITowane jak wszystko inne i, podobnie jak wszystko inne, kod JITted jest szybki. Nie ma ograniczenia wydajności za używanie leków generycznych.
• „wszystkie seksowne fragmenty języka [...] wymagają przewidywania gałęzi ...” - jak to nie dotyczy również C ++? - „... lub [...] generowanie kodu w miejscu” - czy on ma na myśli JITting? Czy wspomniałem, że jest szybki? (Nie będę wchodził we wszystkie miejsca, w których CLR na komputerze używa faktycznego generowania kodu - funkcja nie obsługiwana przez Xbox 360!)
• „[C # nie ma] ogromnych bibliotek [C ++]” - oprócz, powiedzmy, samego XNA? I wiele więcej . (Mimo to jest to dość słuszna kwestia).

XNA na Xbox 360 działa na zmodyfikowanej wersji .NET Compact Framework CLR. Nie mam wątpliwości, że nie odpowiada standardowi wersji komputerowej. JITter prawdopodobnie nie jest tak dobry - ale nie sądzę, żeby był zły . Dziwię się, że nie wspomniał o śmietniku, który jest okropny w porównaniu do CLR na komputery.

(Oczywiście - nie powinno być uderzenie śmieciarza w profesjonalnie opracowanej grze i tak , jak trzeba być ostrożnym z alokacji w każdej grze profesjonalnej jakości).

(W celu faktycznej dyskusji technicznej na temat .NET Compact Framework, być może zacznij od serii artykułów: Omówienie , Kompilator JIT oraz GC i sterty .)

To, że jest całkowicie nieokreślony w swojej terminologii, utrudnia nawet zrozumienie, co ma na myśli. Albo jest w trybie maksymalnego wyrażenia opinii, albo nie wie, o czym mówi.

Teraz, gdy mamy, że z drogi, oto kilka rzeczy, które nie przegapić za pomocą XNA na 360, raczej niż ojczysty :

• Dostęp do jednostki SIMD / Vector do wykonywania naprawdę, bardzo szybkich obliczeń zmiennoprzecinkowych procesora
• Możliwość użycia kodu języka ojczystego, który prawdopodobnie będzie trochę szybszy niż C #
• Możliwość być trochę nieco leniwi w jaki sposób alokować pamięć
• Gry XBLIG mają dostęp tylko do 4 z 6 rdzeni (ale wciąż otrzymujemy wszystkie 3 procesory i nie są też pełnymi rdzeniami, więc nie tracimy wiele) - nie jestem pewien, czy dotyczy to XNA innych niż XBLIG Gry
• Pełny dostęp do DirectX do robienia naprawdę niejasnych podstępów graficznych

Warto również zauważyć, że są to tylko ograniczenia po stronie procesora. Nadal masz całkowicie darmowy dostęp do GPU.

Opisałem te rzeczy w tej odpowiedzi na to, co faktycznie jest tym samym pytaniem, co to. Jak wspomniałem w tej odpowiedzi, XNA jest absolutnie odpowiedni do „profesjonalnego” rozwoju .

Jedynym powodem, dla którego należy unikać, jest to, że nie można zatrudnić talentów C #, licencjonować silników C # i ponownie użyć istniejącego kodu C # w taki sam sposób, jak w przypadku istniejącej bazy wiedzy C ++. Lub ponieważ możesz również kierować reklamy na platformę, która nie obsługuje C #.

Oczywiście dla wielu z nas, którzy nie są „profesjonalnymi” programistami, XNA jest naszą jedyną opcją wejścia na konsolę Xbox 360, co sprawia, że ​​jest to kwestia sporna.

Aby odpowiedzieć na inne pytania:

Nic w języku C # nie powstrzymuje cię przed podejściem zorientowanym na dane w dokładnie ten sam sposób, w jaki używasz ich w języku C ++.

C # nie ma możliwości automatycznego wstawiania kodu w czasie kompilacji i (bez ruszania się w celu sprawdzenia) jestem prawie pewien, że JITter kompaktowego CLR nie umie wstawiać metod (może to zrobić CLR na pulpicie). Dlatego w przypadku kodu krytycznego dla wydajności może być konieczne ręczne wstawienie w języku C #, gdzie C ++ zapewnia pewną pomoc.

Prawdopodobnie większym powodem, dla którego nie często widuje się matematyki procesora, takich jak wykrywanie kolizji i symulacje płynów w języku C #, jest brak dostępu do jednostki wektorowej (jak wspomniano powyżej).

Musisz zdefiniować „profesjonalista”. Czy możesz zrobić Angry Birds, Plants vs. Zombies itp.? Absolutnie. Czy możesz zrobić Crysis 2, COD, Halo? Wątpię. Używanie C # ma naprawdę wpływ tylko na gry, które są bardzo obciążające procesor, a także muszą wycisnąć każdy ostatni bajt pamięci (przegrywasz do wyrzucania elementów bezużytecznych), więc jest jeszcze bardzo dużo do zrobienia.

Jako narzędzie do nauki dla osób rozpoczynających pracę, narzędzie do tworzenia prototypów, platforma do pisania gier, które mogą poradzić sobie z kompromisem itp. Jest fantastyczny i ma dużą moc i prostotę, po prostu nie jest zaprojektowany do robienia tego, co koniecznie trzeba nazywaj grami „AAA”. Usuwa również wiele bólu i cierpienia, o które ludzie muszą się martwić dzięki przenoszeniu i kompatybilności między platformami.

Jeśli wymyślisz niesamowitą grę i napotkasz ograniczenia tego, co możesz zrobić z XNA, sugerowałbym bezpośredni kontakt ze stwardnieniem rozsianym, jeśli pomysł jest naprawdę wystarczająco dobry, mogą po prostu pozwolić ci uzyskać pełny rozwój. zestaw.

Prostym faktem jest to, że nie potrzebujesz dużej liczby wielokątów, pełnego oświetlenia HDR lub najciekawszej fizyki na świecie, aby stworzyć interesującą grę, a jeśli twój plan gry nie zawiera żadnej z nich, to dlaczego nie wybrać szybszej rozwiązanie czasu rozwoju?

bardziej profesjonalne gry mają modele fizyki i systemy animacji

Po prostu źle. Profesjonalne gry mają wszystko, czego potrzebują, aby wdrożyć swoją rozgrywkę i osiągnąć swój artystyczny wygląd, i nic więcej, a nawet nic mniej. Gra nie jest bardziej profesjonalna, ponieważ wygląda bardziej realistycznie lub ma bardziej szczegółową fizykę. Gra, która jest profesjonalna, osiąga cele gry i cele wizualne na czas, w ramach budżetu itp., A także dostarcza i przynosi zysk.