Podejrzewam, że zmiany, o których mówisz, to różnice w strukturze, a nie język C #. W Unity3d używasz frameworku .Net (Via Mono) i specyficznych elementów frameworku Unity w języku C #.
Mike B
To tylko bardzo stara wersja. Jeśli chcesz najnowszą wersję C # i Mono i chcesz zaprogramować, a nie napisać gotowy
Den
Zauważyłem niewielkie różnice w bibliotece, na przykład w Unity istnieje klasa Mathf dla funkcji matematycznych zamiast klasy Math. Nie zwracałem uwagi, jeśli istnieją inne różnice, ale to ta, która się wyróżniała.
Alex
@Alex System.Math jest nadal dostępny i najwyraźniej jest w rzeczywistości szybszy niż UnityEngine.Mathf . Tak więc jedynym prawdziwym powodem korzystania z wersji Unity jest unikanie wielu rzutów (float) .. kosztem pewnej wydajności.
FlintZA
Odpowiedzi:
9
Jak stwierdzono w innych odpowiedziach, Unity 4.x używa zmodyfikowanej wersji Mono opartej na Mono 2.6
W przeważającej części jest to zgodne z .Net 2.0 , chociaż nie udało mi się wyśledzić listy kompatybilności Mono 2.6.
Wygląda inaczej niż zwykły C #, ale jest tam kilka zwykłych elementów C #.
Jak wspomniano w jednym z komentarzy do twojego pytania, jest to prawdopodobnie spowodowane szczególnym skryptowym interfejsem API Unity, a nie samym językiem.
Na przykład wiele kodu w typowych projektach Unity znajduje się w podklasach klasy o nazwie MonoBehavior. Są to komponenty upuszczane na GameObjects w środowisku Unity Editor. Ta architektura prowadzi do kodu C #, który wygląda inaczej niż typowy kod C # (w każdym razie dla mnie) na wiele sposobów:
Do czasu wydania Unity 4 obiekty te nie mogły być zawarte w przestrzeniach nazw, dlatego zawsze znajdują się w globalnej przestrzeni nazw
Udostępniają pola środowisku edytora, upubliczniając je (lub używając atrybutu SerializeField, ale okazuje się, że niewielu ludzi korzysta z tego), co prowadzi do niezwykle dużej liczby pól publicznych w klasach
Prywatność i konwencje przypadków Unity nie są zgodne z Microsoftem, więc może to wyglądać dziwnie dla „tradycyjnego” programisty C #
Korzystają z szeregu specjalnych metod na tych komponentach, takich jak Start i Update, które nie są nadpisywane, jak można by się zwykle spodziewać, ale są dostępne za pomocą refleksji.
Praktycznie rzecz biorąc, największą funkcją języka C #, za którą tęsknię w obecnej wersji C # Unity, jest obsługa asynchronicznych i powiązanych słów kluczowych oraz funkcjonalność. Podobną koncepcją w Unity są coroutines . Są one wykonywane w głównym wątku, więc nie są prawdziwą asynchronizacją, ale pozwalają na podział długiego kodu na wiele ramek. Wielowątkowość niższego poziomu jest nadal obsługiwana.
Dla wyjaśnienia, asyncw języku C # nie jest również prawdziwa asynchronizacja, jak w przypadku wątków wielowątkowych - działa również na wątku głównym. Największe różnice, z punktu widzenia użycia, między coroutines a async to czas uruchomienia kodu.
ruguje
Dzięki. Tak, async! = Wielowątkowy, choć powiedziałbym, że o wiele bardziej powszechne jest używanie asynchronizacji do ukrywania / interakcji z operacjami wielowątkowymi niż w przypadku rutyn. Napisałem opaskę, która uruchamia delegowanie zadań w puli wątków, co zapewnia mi bardzo podobny poziom elastyczności, ale nadal nie miałbym nic przeciwko posiadaniu „właściwego” wsparcia asynchronicznego. Oczywiście przyzwoity nowoczesny GC byłby jeszcze lepszy;)
FlintZA
21
Unity 4 korzysta z Mono 2.6 , która jest pełną implementacją frameworku .NET, w tym języka C #.
Nie jestem pewien, jak to wygląda inaczej, ale pamiętaj, że Unity obsługuje kilka języków, z których wszystkie działają na tym samym środowisku uruchomieniowym Mono. Czy to możliwe, że mylisz język C # z UnityScript ?
Z drugiej strony, kiedy piszesz C # w Unity, będziesz używać wielu ich bibliotek, ale o ile mi wiadomo, wszystko co możliwe w C # jest możliwe w Unity, oprócz różnic wymienionych poniżej:
Bardziej szczegółowe obszary .Net związane z Windows Forms i ASP są niedostępne przez Unity.
Chociaż możesz używać programu Visual Studio do edycji i błędów podczas kompilacji, musisz zbudować i uruchomić w środowisku Unity IDE.
Unity używa Mono, która jest implementacją .Net typu open source, co oznacza, że istnieją niewielkie różnice.
Aby rozwinąć swój drugi punkt - możesz również debugować w Visual Studio za pomocą UnityVS . Firma Microsoft niedawno pozyskała programistów, aby w najbliższej przyszłości wydali wtyczkę za darmo.
mrohlf
Przepraszamy, ale nie jest to zbliżone do zwykłego C #.
Alper
0
Na pytanie, czy wersja C # używana przez Unity różni się od „zwykłej” wersji C #, odpowiedziały inne posty. Ponieważ wyraźnie pytasz o pewne elementy, które mogą różnić się od tak regularnej wersji, podzielę się jedyną niewielką różnicą, którą zauważyłem, porównując C #, którego używam w pracy (tj. C # 4.0 w Visual Studio 2010 i wyższych) i C # w Unity, które jest to, że nie mogę użyć wartości domyślnych dla parametrów w definicjach funkcji. to znaczy, że musisz ostrożniej skonfigurować swój projekt, aby móc korzystać z nowszej wersji C #. Zobacz ten link w celu uzyskania dalszych wyjaśnień.
Edycja:
Pozostawiam tę odpowiedź, ponieważ o ile wiem, jest to nieporozumienie, które przytrafia się dość wielu ludziom.
Ponieważ ta funkcja została dodana do C # tylko w wersji 4.0 i wcześniej nie była obecna, jej brak tak naprawdę nie można nazwać „różnicą” do „C #”.
LUB Mapper
1
Wersja C # 4 została wydana w 2010 roku. Myślę, że wiele osób korzysta z niej i, podobnie jak ja, odczuwa jej brak podczas programowania w Unity.
Nessuno,
Czy na pewno nie możesz użyć wartości domyślnych? Jestem prawie pewien, że mam i mam ...
NPSF3000
Cóż, próbowałem i nie da się skompilować z komunikatem, że nie mogę użyć wartości domyślnych. Czy używasz specjalnej wersji Unity? Podoba Ci się wersja pro?
Nessuno,
1
Możesz absolutnie użyć wartości domyślnych i nie ma to nic wspólnego z pro ani non-pro. Unity i MonoDevelop mają dziwny związek. Automatycznie generowane projekty w MonoDevelop są często ustawione na wcześniejsze wersje C #, które nie obsługują wartości domyślnych. Jeśli jednak zmienisz to ustawienie w projekcie, będzie działać dobrze. Jeśli zignorujesz kompilację w MonoDevelop i po prostu wrócisz do Unity, zauważysz, że Unity nie narzeka na domyślne parametry.
Odpowiedzi:
Jak stwierdzono w innych odpowiedziach, Unity 4.x używa zmodyfikowanej wersji Mono opartej na Mono 2.6
W przeważającej części jest to zgodne z .Net 2.0 , chociaż nie udało mi się wyśledzić listy kompatybilności Mono 2.6.
Jak wspomniano w jednym z komentarzy do twojego pytania, jest to prawdopodobnie spowodowane szczególnym skryptowym interfejsem API Unity, a nie samym językiem.
Na przykład wiele kodu w typowych projektach Unity znajduje się w podklasach klasy o nazwie MonoBehavior. Są to komponenty upuszczane na GameObjects w środowisku Unity Editor. Ta architektura prowadzi do kodu C #, który wygląda inaczej niż typowy kod C # (w każdym razie dla mnie) na wiele sposobów:
Praktycznie rzecz biorąc, największą funkcją języka C #, za którą tęsknię w obecnej wersji C # Unity, jest obsługa asynchronicznych i powiązanych słów kluczowych oraz funkcjonalność. Podobną koncepcją w Unity są coroutines . Są one wykonywane w głównym wątku, więc nie są prawdziwą asynchronizacją, ale pozwalają na podział długiego kodu na wiele ramek. Wielowątkowość niższego poziomu jest nadal obsługiwana.
źródło
asyncw języku C # nie jest również prawdziwa asynchronizacja, jak w przypadku wątków wielowątkowych - działa również na wątku głównym. Największe różnice, z punktu widzenia użycia, między coroutines a async to czas uruchomienia kodu.Unity 4 korzysta z Mono 2.6 , która jest pełną implementacją frameworku .NET, w tym języka C #.
Nie jestem pewien, jak to wygląda inaczej, ale pamiętaj, że Unity obsługuje kilka języków, z których wszystkie działają na tym samym środowisku uruchomieniowym Mono. Czy to możliwe, że mylisz język C # z UnityScript ?
źródło
Unity używa zwykłego C #.
Z drugiej strony, kiedy piszesz C # w Unity, będziesz używać wielu ich bibliotek, ale o ile mi wiadomo, wszystko co możliwe w C # jest możliwe w Unity, oprócz różnic wymienionych poniżej:
Bardziej szczegółowe obszary .Net związane z Windows Forms i ASP są niedostępne przez Unity.
Chociaż możesz używać programu Visual Studio do edycji i błędów podczas kompilacji, musisz zbudować i uruchomić w środowisku Unity IDE.
Unity używa Mono, która jest implementacją .Net typu open source, co oznacza, że istnieją niewielkie różnice.
źródło
Na pytanie, czy wersja C # używana przez Unity różni się od „zwykłej” wersji C #, odpowiedziały inne posty. Ponieważ wyraźnie pytasz o pewne elementy, które mogą różnić się od tak regularnej wersji, podzielę się jedyną niewielką różnicą, którą zauważyłem, porównując C #, którego używam w pracy (tj. C # 4.0 w Visual Studio 2010 i wyższych) i C # w Unity,
które jest to, że nie mogę użyć wartości domyślnych dla parametrów w definicjach funkcji.to znaczy, że musisz ostrożniej skonfigurować swój projekt, aby móc korzystać z nowszej wersji C #. Zobacz ten link w celu uzyskania dalszych wyjaśnień.Edycja: Pozostawiam tę odpowiedź, ponieważ o ile wiem, jest to nieporozumienie, które przytrafia się dość wielu ludziom.
źródło