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

Offline Esidar

  • Użytkownik

# Luty 28, 2008, 13:58:22
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. :)

Nie no... :) "Coś" jednak przemawia :) Chodziło mi o napisanie edytora w C#. Nie miałem w zamiarze rozszerzać silnika o skrypty czy coś "przyśpieszać/zwalniać" :) Poprostu edytor miał mieć swobodę w operowaniu danymi i klasami. Miał też mieć możliwość rozszeżania silnika o swoje klasy używane tylko w edytorze.

Zresztą łączenie native z managed tylko po to żeby mieć skrypty, napotka na podobne problemy do tych, które opisałem. Przykładowo jeśli masz w native:
const std::vector< WorldObject* >& WorldManager::GetLights();

i będziesz chciał w managed zrobić
WorldManager.GetLights()[ 10 ].SetPosition( new Vector( 0, 0, 0 ) );

to będziesz musiał zarówno użyć RTTI jak i obejść problem _align.

I tak przy okazji, to właśnie pokazuje kolejny problem. Synchronizacja kontenerów. Musisz napisać własne kontenery które będą wrapować te z native bo musisz wiedzieć kiedy obiekty w native są dodawane i usuwane z list, albo kiedy elementy się zamieniają miejscami itd.
« Ostatnia zmiana: Luty 28, 2008, 16:53:21 wysłana przez Esidar »

Offline Mr. Spam

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

Offline Krzysiek K.

  • Redaktor
    • DevKK.net

# Luty 28, 2008, 14:33:30
Cytuj
Miał też mieć możliwość rozszeżania silnika o swoje klasy używane tylko w edytorze.
To już IMHO trochę przesada, zwłaszcza jeżeli zamierzałeś dziedziczyć klasę z C# po klasie z C++. :)

Cytuj
WorldManager.GetLights()[ 10 ].SetPosition( new Vector( 0, 0, 0 ) );
A nie prościej by było napisać:
xxSetPosition(xxGetLightHandle(10),0,0,0);(zamiast "xx" wstawić dowolny skrót nazwy silnika) ;)

Przecież żeby programować obiektowo nie trzeba wykorzystywać mechanizmów oferowanych przez dany język. W tym wypadku wystarczy zejść do wspólnego minimum i zrealizować obiektowość z interfejsem podobnym do C, dzięki czemu odpada zabawa w zmuszanie do współpracy obiektów z C++ z obiektami z C#. :)

RageX

  • Gość
# Luty 28, 2008, 14:59:18
Lights() w moim wyidealizowanym świecie, zwróci identyfikatory obiektów(string, albo int, czy co tam sobie wymyślisz...).

Do edytora(od początku miałem na myśli edytor), nie potrzebujesz wcale cudów, taki edytor nie potrzebuje tak głęboko sięgać. SetPosition(Vector3 vector) to 3 podstawowe float'y x, y i z. Nie potrzeba typu z runtime-u brać, co by to działało. Ja w silniku mam/miałem dostęp globalny do zasobów. Wystarczy wtedy coś takiego...
// C++, a potem tylko odzwierciedlone
void SetObjectPosition(string id, float x, float y, float z);
string[] GetLightsIds();
// C#
SetObjectPosition(GetLightsIds()[0], .4f, .2f, .3f)

Całe to  twoje kombinowanie kojarzy mi sie z pisaniem kompilatora wysokiego poziomu. :)

Edit: Krzysiek K. mnie wyprzedził. Ale żal było kasować co już napisałem.  :P
« Ostatnia zmiana: Luty 28, 2008, 15:00:55 wysłana przez RageX »

Offline Esidar

  • Użytkownik

# Luty 28, 2008, 15:55:10
Do edytora(od początku miałem na myśli edytor), nie potrzebujesz wcale cudów, taki edytor nie potrzebuje tak głęboko sięgać.

Akurat od tego czy zrobisz wrapper funkcjami czy klasami zależy potem wygoda w pisaniu w edytorze. Jeśli "ułatwisz" sobie pisanie wrapperów, to będziesz miał potem utrudnione korzystanie. A akurat w tym wypadku, wolę pisać wrapper 2 dni (a nie 1 dzień) po to żebym nie stracił tygodnia na pisaniu setek kilobajtów nadmiarowego kodu w edytorze.

Dla przykładu jeśli chcesz zrobić okno w stylu "Properties" takie jakie jest w Visualu, Crysis, Unreal itd. to robisz klasy managed które udostępniają pola typu property i wrzucasz do JEDNEJ tylko kontrolki wskaźnik do obiektu typu "object" i masz "z głowy" zarówno wyświetlanie jak i edytowanie pól obiektu.

Jeśli zrobisz to samo funkcjami to będziesz musiał mieć tyle "sposóbów" otwarcia okna Properties, ile rodzajów obiektów w silniku, a każde otwarcie okna "Properties" będziesz poprzedzał kilobajtem kodu napisanego osobno dla każdej klasy w stylu "GetLightPosition()", "GetLightAttenuation()", "GetLightName()" itd... a potem każda zmiana parametru to wywołanie zarejestrowanej w kontrolce funkcji "SetLightPosition()", "SetLightAttenuation()", "SetLightName()". I teraz pomnóż to przez 100 klas które byś chciał edytować.

I to jest akurat ważny feature dla które warto korzystać z .NET (czyli pola typu properties). Jeżeli nie zamierzasz korzystać z Properties albo z delegatów to wogóle nie używaj .NET bo na tym się kończą jego zalety. Równie dobrze możesz pisać edytor w kodzie native i wxWidgets :) I właśnie o to mi chodziło, pisząc że "minusy przesłoniły mi plusy" i dlatego nie piszę edytora w C#. Jeśli widzicie inne zalety pisania w C#, chętnie usłyszę o nich :)



Cytuj
To już IMHO trochę przesada, zwłaszcza jeżeli zamierzałeś dziedziczyć klasę z C# po klasie z C++.
Wolisz dopisywać do silnika wszystkie klasy których Ci brakuje w edytorze ? :) A w edytorze są potrzebne przykładowo takie klasy "BoundingBoxRenderable", "WalkPathRenderable", "CameraMoveSplineRenderable"... w silniku już nie bardzo są potrzebne. IMHO. :)

RageX

  • Gość
# Luty 28, 2008, 17:14:21
...możesz od razu pisać właściwości (to też funkcje)... nie widzę problemu w zamianie funkcji Get Set na daną właściwość.

Jak nie chce ci się ręcznie przepisywać, a chcesz mieć "wszystko" - napisz kompilator do nagłówków. Podejście "mieć w skrypcie wszystko" w blenderze i integralnym pythonie jest zaserwowane (chyba nawet właśnie w ten sposób).

Jeśli mówimy tylko o C# w kontekście tylko edytora to rzeczywiście oprócz designera w VC#EE, kontrolki właściwości i kodu samego już edytora w C# - nie wiele zyskujemy. Jeśli dorzucimy możliwość skryptowania, edycji źródeł samego edytora dla użytkownika (nie silnika) to już zyskujemy dużo - np. taki FX Composer 2 w ten sposób(o ile oczywiście się nie mylę) śmiga. Jeśli C# w tym przykładzie zamienimy na IronPython - a, to mamy to co wyżej, plus shell... który można by w c# zrobić... (który ma wspomaganie dla tworzenia typów dynamicznie) ale to duża robota. Jeżeli szukamy tylko możliwości oskryptowania silnika bez  edytora to raczej jakieś lua, CPython, itp.

Offline Krzysiek K.

  • Redaktor
    • DevKK.net

# Luty 28, 2008, 20:28:49
Cytuj
Wolisz dopisywać do silnika wszystkie klasy których Ci brakuje w edytorze ? :) A w edytorze są potrzebne przykładowo takie klasy "BoundingBoxRenderable", "WalkPathRenderable", "CameraMoveSplineRenderable"... w silniku już nie bardzo są potrzebne. IMHO. :)
Jasne, że dopisać do silnika, dzieki temu przy projektowaniu silnika można nawet sie pokusić o odrzucenie założenia, że silnik jest rozszerzalny "z zewnatrz". Jeżeli takie obiekty nawet by przeszkadzały w jakiś sposób (powiedzmy że walczysz o kilobajty na konsoli), to zawsze można w silniku w wersji "final release" felerny kod wyifdefować. :)

Offline Khaine

  • Użytkownik

# Luty 28, 2008, 21:13:57
mozna sie pokusic o system pluginow do silnika ;)