Autor Wątek: Cry Engine 2  (Przeczytany 17542 razy)

Offline Krzysiek K.

  • Redaktor
    • DevKK.net

# Luty 26, 2008, 03:36:53
Cytuj
mamy nową architekturę która nie jest jakoś specjalnie pod trójkąty optymalizowana...
A na czym myślisz GPU w PS3 pracuje? :)

Offline Mr. Spam

  • Miłośnik przetworów mięsnych

Offline Esidar

  • Użytkownik

# Luty 26, 2008, 15:23:39
Nie kumam - mamy nową architekturę która nie jest jakoś specjalnie pod trójkąty optymalizowana... po co te nurbs'y w trójkąty zamieniać.
To co napisał Krzysiek "GPU w konsolach (tak jak i najnowsze układy Nvidia/Ati) cały czas pracują na trójkątach". Tutaj nic się nie zmieniło.

Nie wiem za bardzo o jakie "haki" Ci chodzi :) Mi chodziło o "optymalizacje" znane od wielu lat, jak chociażby FastDCT które ma być szybszą wersją DCT dzisiaj jest już "przestarzałe" bo szybciej jest policzyć pełne DCT za pomocą vectorów (SSE - patrz. Intel Performance Library)".

Do raytracingu faktycznie jeszcze troche brakuje mocy ale chociażby NURBS można stosować dzisiaj. Powierzchnie były użyte w Q3 w czasach Pentium II więc dlaczego "nie w tej epoce" ? :)

Cytuj
PS. Poza tym do tego o czym mówisz (wykorzystania do krańców mocy architektury) trzeba nauczyć się także operować kodem na trochę niższym poziomie, niż tylko kompilatory cpp.

To z pewnością jest kolejny etap optymalizacji, ale dzisiejsze kompilatory radzą sobie z generowaniem kodu już całkiem nieźle bez konieczności pisania wszystkiego w asm { }.
Ale nowe architektury, multi-core, operacje vectorowe, dają pole do optymalizacji na wyższym poziomie. Wystarczy poczytać na sieci jak developerzy powoli zaczynają się uczyć "zrównoleglać" liczenie ścierzek, AI, renderingu, animacji, fizyki, itd. Do tego dochodzi specyficzne wykorzystanie sprzętu, jak np. SPU w PS3. Na tegorocznym GDC08 była np. prezentacja o wykorzystaniu SPU w grach Resistance i Ratchet and Clank. Niestety nie byłem, nie słyszałem, nie wiem... ale podobno ciekawa była część dotycząca "SPU Shaders".

[Edit] No tak. Wystarczyło rzucić hasło na google by coś znaleźć na temat "SPU Shaders" http://www.insomniacgames.com/tech/techpage.php :) Właściwie to jest nawet implementacja w software microwątków o których wspomniałem w temacie o Aegeia na tym forum. Pisałem tam, że procesory mogłyby pójść w stronę wykonywania microwątków czyli niewielkich programików, liczących równolegle z głównym programem jakieś specyficzne rzeczy, jak np. mnożenie macierzy przez macierz itd. Tutaj poszli w podobnym kierunku i zrobili microprogramiki (Shadery) dynamicznie zarządzane przez kod gry. Każdy shader ma swój obszar na kod, na dane i jest dynamicznie ładowany do pamięci SPU. Dowolny kawałek kodu może zlecić wykonanie prostych obliczeń w jednym z shader'ów i uzyskać w krótkim czasie wynik. W dokumentach na tej stronie są przykłady użycia w ich implementacji fizyki.


« Ostatnia zmiana: Luty 26, 2008, 16:37:18 wysłana przez Esidar »

Offline Reg

  • Administrator
    • Adam Sawicki - Home Page

# Luty 26, 2008, 20:23:13
Mnie najbardziej zachwyciły te filmiki pokazujące edytor z CryEngine2. Zastanawiam się, jak to jest robione, że silnik można połączyć z edytorem (ciekawe czy ten edytor jest w C# czy w C++), że można sobie dynamicznie zmieniać wszystko łącznie z deformacją terenu i od razu testować jakby w grze.

RageX

  • Gość
# Luty 26, 2008, 20:32:23
Reg: To skrypty tylko. W zasadzie to łatwe (znaczy zrobienie tak, aby można było to w real time). :)

Esidar, KK: zapomniałem się... oczywiście macie rację.   ::)

RageX

  • Gość
# Luty 26, 2008, 21:05:19
Reg: jak ostatnio przegladalem oferty pracy Epic'a to poszukuja kogos kto zna sie jeszcze na MFC, wiec prawdopodobnie w tym chlamie zaczeli robic swoje narzedzia i tak juz im zostalo ;)

Offline Khaine

  • Użytkownik

# Luty 26, 2008, 21:58:56
Cytuj
Mnie najbardziej zachwyciły te filmiki pokazujące edytor z CryEngine2. Zastanawiam się, jak to jest robione, że silnik można połączyć z edytorem (ciekawe czy ten edytor jest w C# czy w C++), że można sobie dynamicznie zmieniać wszystko łącznie z deformacją terenu i od razu testować jakby w grze.
Gdyby chcieli pisac w C# to silnik musial by kozystac z net frameworka, wiec od razu odpada, no chyba, ze chcialo by im sie exportowac wszystko z dll (bo mozna exportowac c/c++). Po drugie, aplikacje net frameworkowe maja nieco inny wyglad (patrz visual studio).

Offline yarpen

  • Użytkownik

# Luty 26, 2008, 22:21:13
Reg: jak ostatnio przegladalem oferty pracy Epic'a to poszukuja kogos kto zna sie jeszcze na MFC, wiec prawdopodobnie w tym chlamie zaczeli robic swoje narzedzia i tak juz im zostalo ;)
Toole Epica sa w wxWidgets.

RageX

  • Gość
# Luty 27, 2008, 00:02:17
Aha. W takim razie to bardzo ciekawe po kiego grzyba im ktos znajacy MFC :). Chociaz w sumie... po co mieliby uzywac MFC skoro u nich wszystko jest cross-platform, to nie dosc ze dolozyliby sobie roboty to jeszcze napsuli nerwy ta malo przyjazna biblioteka :)

Offline mINA87

  • Użytkownik

# Luty 27, 2008, 02:24:12
Wychodza z założenia że jeśli ktoś zna ideę programowanie w MFC, to poradzi sobie w wxWidgets ;)
Poza tym skąd wiesz jakie tajniackie toolsy klepią w zanadrzu do katowania artystów? :P

Offline Riddlemaster

  • Użytkownik
    • Moja strona domowa

# Luty 27, 2008, 18:00:47
Cytuj
Poza tym skąd wiesz jakie tajniackie toolsy klepią w zanadrzu do katowania artystów?
Właśnie? Przy tej okazji przypomniał mi się pewien cytat z gamasutry (piszę z pamięci): "graficy i programiści nie przepadają za sobą. Ci pierwsi nazywają tych drugich geeks i żartują z nich, a ci drudzy tworzą złośliwie jak najmniej intuicyjne edytory dla artystów" :) I chyba coś w tym jest - programistom często wystarczają toole w konsoli. Artystom - nie.

Cytuj
Zastanawiam się, jak to jest robione, że silnik można połączyć z edytorem
Nic trudnego ;) Mnie samego to zainspirowało do małego researchu, w wyniku którego udało mi się osiągnąć kiedyś pewną namiastkę czegoś takiego. Okazuje się, że .dllki z silnika napisanego w C++ bardzo łatwo podpiąć pod edytor napisany w managed c++ czy c#. Co prawda nie zawsze podoba się to Visual Studio (generuje momentami dziwne wyjątki, nie lubi kodu który nie może być zarządzany), ale wszystko działa bez zarzutów i jest bardzo eleganckie (przynajmniej z poziomu użytkownika).

Cytuj
Gdyby chcieli pisac w C# to silnik musial by kozystac z net frameworka, wiec od razu odpada, no chyba, ze chcialo by im sie exportowac wszystko z dll
Zwykle wczytuje się .dllki, niektóre rzeczy trzeba "owrappować", ale wcale nie wszystko.

Offline Esidar

  • Użytkownik

# Luty 28, 2008, 00:34:12
Właśnie? Przy tej okazji przypomniał mi się pewien cytat z gamasutry (piszę z pamięci): "graficy i programiści nie przepadają za sobą. Ci pierwsi nazywają tych drugich geeks i żartują z nich, a ci drudzy tworzą złośliwie jak najmniej intuicyjne edytory dla artystów" :) I chyba coś w tym jest - programistom często wystarczają toole w konsoli. Artystom - nie.

Mi się szczególnie spodobał tytuł artukułu na ten sam temat (może to nawet ten sam artykuł :) "Gdy prawa półkula mózgu spotyka się z lewą". Niestety sam też widzę, że wielu jeszcze progamistów woli "dokładnie wszystko rozpisać i mieć przed oczami co się dzieje" i dlatego piszą toole w konsoli. Ja już jestem na etapie "fajnie by było gdyby się wszystko dało zrobić jednym przyciskiem" :)

Cytuj
Zwykle wczytuje się .dllki, niektóre rzeczy trzeba "owrappować", ale wcale nie wszystko.
Ja mam złe doświadczenia z wrapowaniem kodu native do managed. Przez długi czas byłem cierpliwy i zwalczałem różne problemy. Ale jest z tym bardzo dużo dobrej i nikomu nie potrzebnej roboty. Teraz piszę albo tylko w native albo tylko w c# :) W pewnym momencie minusy przesłoniły mi plusy i przestałem łączyć managed z native :)

RageX

  • Gość
# Luty 28, 2008, 02:02:49
Trik z tym skryptowaniem i wrappowaniem cpp w c# jest taki, że jeśli wrappujemy dla siebie, to możemy luzem pominąć marshalling - w końcu to skrypty, proste zaprogramowane komendy. Jedną klasę z funkcjami robimy na zewnątrz i tyle. Takie wrappowanie, jest proste (bez wspomnianego marshallingu)... może coś przekombinowałeś, chciałeś za dużo?

Offline Esidar

  • Użytkownik

# Luty 28, 2008, 11:25:17
Jedną klasę z funkcjami robimy na zewnątrz i tyle.

Wrapowanie globalnych funkcji czy mało skomplikowanych klas, jest oczywiście proste. Ja wrapowałem cały silnik, tak aby wszystkie klasy były dostępne z poziomu C#. A problemy z tym są różne. Z pamięci mogę przytoczyć:

1. Klasy z atrybutem __declspec(align). C++ nie potrafi użyć z poziomu managed, klasy native która ma włączony align. Np. klasa Vector (x,y,z,w). Najpierw trzeba napisać wrapper native UnalignedVector(), który pozwala na przekazywanie obiektów bez align, a następnie zrobić drugi wrapper ManagedVector() który będzie udostępniać Vector poprzez UnalignedVector() :)

2. Musisz mieć RTTI (defaultowe z C++ lub swoje). Jeśli wrapujesz metodę "WorldObject* GetObject( u32 id )", to musisz rozpoznać zwracany typ obiektu i do Managed zwrócić odpowiedni wrapper. Ja "na szczęście" użyłem swojego RTTI. Dzięki temu nie musiałem mieć metody "object GetWrapperForNativeObject( void* )" w której byłoby 500x switch/case i dynamic_cast. Ja dzięki swojemu rozwiązaniu miałem coś takiego:
[BaseObjectWrapper( WrapperFor = 0x12A78F7a3 )]
ref class MeshWorldObject : WorldObject
{
};
I potem metoda "object GetWrapperForNativeObject( BaseObject* )" miała tablicę wrapperów i tworzyła obiekt Managed dla odpowiedniego typu Native (wszystkie klasy native muszą oczywiście dziedziczyć z klasy podstawowej BaseObject która potrafi zwrócić typ 0x12A78F7a3).

3. Przeciążanie metody virtualnych. Jeśli masz w native metodę dajmy na to "Renderable::Render()" i chcesz stworzyć w managed własną klasę która robi "override Render()", to musisz znowu posłużyć się dodatkowym wrapperem w native. Musisz stworzyć klasę "NativeRenderable" która będzie mieć wskaźnik na "ManagedRenderable^" i z tamtąd będzie w momencie wywołania "NativeRenderable::Renderable" wywoływać "ManagedRenderable::Render()", a tą metodę z kolei można już przeciążyć w C#. Oczywiście taki wrapper musisz pisać do każdej metody virtualnej.
[Edit] To rozwiązanie pozwala jedynie na stworzenie w .NET własnych klas dziedziczących z Renderable w native. Niestety nie znalazłem prostego rozwiązania aby tak zrobić wrapper na już istniejącą klasę native np. "MeshRenderable" aby możliwe było przeciążanie metod virtualnych tej klasy czyli żeby zablokować wywoływanie MeshRenderable::Render" i zamiast niej wywoływać "ManagedMeshRenderable::Render". Warunek jaki sobie postawiłem to taki, że nie będę modyfikować istniejących klas native tylko po to aby współdziałały z kodem Managed.

Oczywiście każdy problem dało się rozwiązać, ale w końcu argumenty za korzystaniem z C# okazały się nie wystarczające żeby dalej spędzać więcej czasu na pisaniu wrapperów niż na właściwym kodzie :)
« Ostatnia zmiana: Luty 28, 2008, 11:50:53 wysłana przez Esidar »

RageX

  • Gość
# Luty 28, 2008, 13:32:38
No i popełniłeś "ten" błąd. Za czymś takim nic nie przemawia. Ostatecznie nic z tego nie ma. Ani jakiejś specyficznej enkapsulacji, ani wzrostu szybkości, ani nawet shell'a i dynamicznego oskryptowania. :)
Heh. Takie ambicje(wrappowanie wszystkiego) sobie szybko wybiłem z głowy, takie działania nie są w żaden sposób uzasadnione... kolejny kod do napisania, z którego nic nie wynika.

Dodam jeszcze do kwestii "managed" jedno hasło - IronPython. Mamy środowisko shell'owe, dynamiczną obsługę clr i .net, w tym słodkie Microsoft.Windows.Forms. Problem tylko taki, że nie mamy tak prostego designera i reszty pomocy przy tworzeniu okienek, znanej z vc#. Oczywiście, dalej (znaczy się w IronPythonie) bez sensu jest wrappowanie wszystkiego, lepiej stworzyć jakiś prosty interface.

No ale do IronPythona trzeba znać Pythona (kolejny język z fajną, ale niestety nową składnią). :)

Offline Krzysiek K.

  • Redaktor
    • DevKK.net

# Luty 28, 2008, 13:50:36
Cytuj
Heh. Takie ambicje(wrappowanie wszystkiego) sobie szybko wybiłem z głowy, takie działania nie są w żaden sposób uzasadnione... kolejny kod do napisania, z którego nic nie wynika.
Co prawda nie bawiłem się z C#, ale w przypadku wrapowania miałbym podobne podejście - owinąć jedynie zewnętrzny interface silnika, korzystając w dodatku z OpenGL'owej filozofii - wszystko w prostych funkcjach C i jak najmniej wskaźników. :)