czwartek, 17 lutego 2011

This is Sparta!

Na wstępie chciałem podziękować za zainteresowanie projektem kilku osobom, które mnie zmotywowały do ujawnienia poniższych informacji :). Wpis proszę traktować jako ciekawostkę, w najbliższym czasie (co najmniej do wakacji) nie planuję żadnych aktualizacji, wpisów ani akcji informacyjnych o Sparcie. Muszę się w pełni skoncentrować na prowadzonym projekcie (mort-game.com) i pisaniem pod niego komponentów GCL i usprawnianiem narzędzi, a takie artykuły, prezentacje i tworzenie filmów pochłania spore ilości czasu. Poza prowadzonym projektem, jeśli, nie uda się nawiązać współpracy z Embarcadero i tak nie ma sensu publikowanie jakichkolwiek technicznych informacji, albowiem sukces/ewentualne wypuszczenie na rynek Sparty zależy od likwidacji kilku kluczowych błędów w kompilatorze i ograniczeń IDE (sytuacją niedopuszczalną byłoby dla mnie wypuszczenie do użytku samego prototypu, czy niekompletnego i wadliwego środowiska).

Kiedyś miałem sen. Śniłem o środowisku programistycznym Delphi dedykowanym dla programowania gier. Silniki to za mało. Chciałem czegoś więcej, przez ostatnią dekadę liczyłem na to, że Borland/Codegear/Embarcadero zrobi krok w tym kierunku. Niestety, w życiu często bywa tak, że mamy tylko to co zrobimy sobie sami :)

Zrzut z IDE powinien wyjaśnić mniej więcej, o czym będę pisał w dalszej części wpisu:

http://img513.imageshack.us/img513/238/newlife.jpg

Na początek krótkie zestawienie najważniejszych elementów oferowanych przez Spartę:

*Brak VCL (! jednak można go podłączyć jako hosta).
*3D (OpenGL) w RAD Studio.
*GCL (Graphics/Game Component Library) w miejsce VCL (nie jest to nakładka na VCL czy zbiór komponentów jak GLScene, tylko nowy, niezależny system).
*Własne designery i modyfikatory
*Fizyka 2D/3D, GUI (i inne mogą) być edytowane jak formy w VCL.
*Własny system komponentów niezależny od istniejącego (nowe komponenty, moduły danych - tu moduły danych są rozumiane jako moduły na poziomie logicznym Form w VCL - mogą być tworzone w sposób znacznie prostszy i szybciej niż w tradycyjnie).
*Kompilator GLSL zintegrowany z RAD Studio
*GCL jest kompatybilny z GeForce i Radeon
*Zaawansowana i prosta binarna serializacja dla wszystkich typów danych (dosłownie wszystkich, serializator bazuje na nowym RTTI)
*Rekordy w "Object Inspector" i w plikach *.dfm (bazuje na nowym RTTI)
*Pełna integracja skryptów LUA z Delphi (bazuje na nowym RTTI)
*GCL jest gotowe na MacOSX i Linux (jako hosta używa obecnie SDL)
*Wszystkie zdarzenia komponentów mogą być kojarzone ze skryptami (dodatek ten nie ma wpływu na wydajność)
*Dodatkowe moduły pomocnicze do OTA
*Biblioteka matematyczna wprowadza szereg struktur i funkcji dla wektorów, macierzy, kwaternionów, kolizji, interpolacji etc.
*Zintegrowane narzędzia w RAD Studio do zarządzania projektem i budowania nowych elementów Sparty w Sparcie

Sparta IDE

Nad Spartą pracują dwie osoby ja (aka. HNB) i Krystian Komisarek (aka. Spider). Krótka charakterystyka:
• HNB - OTA integracja z Delphi, pomysł na całe IDE i wykonanie, projekt i implementacja GCL
• Spider - Specjalista od OpenGL, tworzenie nowych komponentów dla GCL, wiele kluczowych pomysłów

Dlaczego powstała Sparta?

1. Sparta powstała by w prosty, przejrzysty i uporządkowany sposób realizować projekty gier/wizualizacji

2. Mieszanie VCL i OpenGL jest niewygodne. Kontrolki windowsowe często nie pasują wizualnie do grafiki wyświetlanej w widoku 3D OpenGL. Często koniecznym jest tworzenie nowych komponentów w samym VCL, integracja między światem OpenGL a VCL jest uciążliwa (bardzo odczuwalne przy tworzeniu bardziej skomplikowanych edytorów i aplikacji).

3. Sprawdzony i działający kod, najaktualniejsze moduły do grafiki. Nie trzeba szukać frameworków po internecie i zastanawiać się czy użyty framework OpenGL jest nowoczesny i właściwy.

4. Wygoda kształtowania GUI. VCL został stworzony dla kontrolek Windowsowych co niesie z sobą wiele problemów i ograniczeń przy łączeniu z OpenGL. GUI z GCL zostało zaprojektowane od zera specjalnie do integracji z działającym w tle 3D. Ma trochę wspólnego z VCL (łatwość w użyciu), eliminuje częć rzeczy uciążliwych i jednoczenie wprowadza różne udogodnienia, co więcej działa bezpośrednio w OpenGL.

Czym jest Sparta?

Po pierwsze Sparta to nie tylko GUI dla OpenGL. Po drugie jedyne wspólnego co ma GCL (Sparta) z VCL (Delphi) to IDE, wygoda w użyciu i kompilator. Poniżej w podpunktach zawrę to co istotniejsze

1. Moduł na poziomie formy z VCL w GCL zyskał zupełnie nowe znaczenie. Dla ułatwienia nazwijmy te moduły na poziomie formy, Kontrolkami GCL.

2. Kontrolki GCL to między innymi : pulpit, forma, main game, fizyka 2D, menager tekstur, timer, scena, teren, particle...

3. Kontrolki GCL są zebrane w grupy : GUI (pulpit, forma) Default (main game) itd.

4. Każda z kontrolek GCL zawiera swój unikalny system komponentów (!) widoczny na palecie komponentów tylko w chwili gdy jest aktywna zakładka designera z daną kontrolką GCL. Przykładowo dla formy GUI z GCL mamy komponenty jak w VCL (buttony, listy, różne niewizualne komponenty itd.)

5. Każda z kontrolek GCL może definiować własne selektory (coś co decyduje czy dany komponent został zaznaczony) i modyfikatory (coś co wizualnie modyfikuje komponent, przesuwa go/skaluje) dla różnych komponentów i ich grup (zaznaczonych kilku komponentów).

Co daje Sparta?

1. Kontrolki GCL w przeciwieństwie do form z VCL mają liczniki referencji. Z poziomu IDE można tworzyć powiązania między kontrolkami GCL. W dużym skrócie programista może decydować które kontrolki GCL dla których mają być automatycznie stworzone/aktywne. Dzięki temu nie są ładowane wszystkie kontrolki już na starcie programu a jedynie wtedy gdy są potrzebne innej kontrolce GCL.

2. Tworzenie w usystematyzowany sposób wiele programów wirtualnych w jednym programie. Przykładem mogą być formy poprzypisywane do pulpitów. Można w prosty sposób aktywować aktualnie potrzebny pulpit. Również z poziomu projektu programistycznego można ładnie uporządkować formy GUI po katalogach danego pulpitu.

3. Koncepcja nazewnicza. Projekt tej skali wymagał stworzenia odpowiedniego podziału modułów, warstw i przedrostków i przyrostków. Istnieje wiele modułów zbiorczych i nazewniczo podobnych do tych z VCL/RTL np. gclClasses, guiClasses, dtxUtils. Doświadczony programista Delphi powinien szybko się odnaleźć w środowisku Sparty.

4. Granicą jest ludzka wyobraźnia, mając w miejscu designera form okno OpenGL można tworzyć nawet inne biblioteki aniżeli GCL, VCL... Np. do tworzenia grafów etc.

Warstwy Sparty

Projekt tego rozmiaru wymagał usystematyzowania i uporządkowania.

• Warstwa 1 (aka. SpartaRTL)
Własne moduły pomocnicze wypełniające braki w RTL. W ich skład wchodzą moduły realizujące/dostarczające mi.: serializację, matematykę, skrypty

• Warstwa 2 (aka. SpartaEngine)
Silnik gry. Istnieją różne silniki do gier. Używając samej warstwy 2 i 1 można tworzyć pełnowartościowe gry komputerowe i wizualizacje w tradycyjny sposób jak ma to miejsce w przypadku zwykłych silników, używając różnorodnych klas do kształtowania wirtualnej rzeczywistości.

• Warstwa 3 (aka. otaUtils)
Warstwa nabudowana na ToolsAPI. Znacząco upraszcza i automatyzuje użycie interfejsów z ToolsAPI. W planach jest stworzenie komponentów do VCL korzystających z warstwy 3, przeznaczonych tylko i wyłącznie do tworzenia bibliotek *.bpl dla IDE.

• Warstwa 4 (aka. Sparta IDE)
Korzystając z warstwy 3, zostało podłączone OpenGL do RAD Studio i został stworzony alternatywny system komponentów, oraz zintegrowane narzędzia w IDE (np. kompilator shaderów GLSL, wystarczy je dodać do projektu jak zwykłe pliki z kodem).

• Warstwa 5 (aka. GCL)
Zostało omówione w podpunkcie : „Czym jest Sparta?”

• Warstwa 6
Konkretne kontrolki GCL: GUI, Physics, RTS Maps, FPS... Kontrolki np. Physics mogą korzystać w swoich designerach np. z kontrolek już obecnych w Sparcie np. z GUI.

• Warstwa 7 (w planach, jednak wszystko jest pod to pisane)
Możliwość edycji kontrolek GCL w czasie działania programu (!). Selektory, modyfikatory i cały system komponentów może być przeniesiony w program. W planach jest stworzenie IDE podobnego do Delphi działającego bezpośrednio w OpenGL i w uruchomionej aplikacji/specjalnym trybie edycji. Zamiast kodu Delphi pisałoby się w skryptach LUA (lub innych), analogicznie do tego jak ma to miejsce w Delphi (zdarzenia, object inspector itd.). Nowe eventy mogą współdziałać z tymi napisanymi w Delphi, bądź mogą je nadpisywać. Możliwe by było dodawanie nowych komponentów z poziomu tego właśnie IDE do już istniejących kontrolek GCL.

Jak jest tworzona Sparta

Sparta jest tworzona równolegle z dużym projektem gry komputerowej, nie jest to środowisko pisane samo dla siebie, a hartowane na realnych zastosowaniach:

http://serwis.gamedev.nazwa.pl/screens/18a77df995aaccbcf628808f268d8d3a.jpg
http://mort-game.com
http://www.youtube.com/watch?v=za_JtzO6QGI

Stopień ukończenia Sparty

Sparta to działający prototyp. Kluczowe elementy środowiska programistycznego zostały zaimplementowane. Obecnie rozwijana jest głównie strona samego silnika gier i nowych komponentów GUI na potrzeby projektu Mort i dodatkowe funkcjonalności do IDE przyspieszające proces powstawania gry. Fajerwerki do planowanych prezentacji typu - podłączony nasz autorski silnik fizyczny pod designery - zeszły na dalszy plan (jakieś dodatkowe 2 tygodnie być może niepotrzebnej na chwilę obecną pracy). Jesteśmy w pełni skoncentrowani na kodzie dla naszej gry RTS.

Przyszłość Sparty

Pomimo zamieszczenia tematu i informacji o Sparcie moim łamanym angielskim ;) (link), nie doczekałem się niestety ani jednego komentarza od któregokolwiek pracownika na forum ani na PM...

Jedyna alternatywa dająca zbliżone możliwości do Delphi to platforma .NET i język C#. Wiele myślałem o przepisaniu Sparty, początkowo na Delphi Prism a później na C#, jednak to wymaga dodatkowego czasu a i efekt takiego zabiegu stoi pod znakiem zapytania. Rozwijana Sparta, nawet jeśli nigdy nie stanie się produktem do kupienia, może się opłacić istniejąc jako narzędzie do wewnętrznego użytku, ze względu na nasze przyszłe projekty i możliwość kompilacji na pozostałe systemy operacyjne w całkiem niedalekiej przyszłości (MacOSX, Linux). Do tego dochodzi Delphi Prism, a stąd droga na XBOXA czy najnowszy projekt "Cooper" czyli kompilator Delphi Prism tworzący "natywne" pliki javy mi. dla Androida. Nie wspomnę już nawet o planach stworzenia backendu kompilatora dla ARM :).

Drogi są dwie : nasze własne prywatne IDE, albo współpraca z Embarcadero i kto wie? :)

Na zakończenie kilka smaczków :). Skąd nazwa Sparta? Nazwa nie jest przypadkowa.

Geneza nazwy

Za twórcę Sparty jako bytu politycznego uważa się prawodawcę Likurga. Nie wiadomo, czy jest on postacią historyczną, bowiem już w czasach starożytnych uchodził za postać niemal mityczną. Żywot Likurga pióra Plutarcha zawiera krótki tekst traktujący o ustroju Sparty. Jest to tak zwana Wielka Rhetra napisana w dialekcie doryckim. Likurg miał jakoby otrzymać owe prawa od wyroczni delfijskiej, co znacznie podnosiło ich prestiż. Prawa Likurga miały zakończyć okres walk i niepokojów w Sparcie (około VIII w. p.n.e.).


Zaznaczyłem wyroczni delfijskiej gdyż jest to klasyk. Nazwa Delphi, środowiska (IDE) w którym programujemy i języka który też jest nazywany Delphi, wywodzi się z pogranicza greckiej mitologii i historii. Delphi powstało głównie z myślą o bazach danych, stąd jest szybkie i stabilne, przejrzyste, tym samym przy okazji nadaje się do pisania gier. Głównym targetem Delphi była baza danych "Oracle", stąd też Delphi zostało nazwane Delphi - Delphi oracle było jedną z najistotniejszych świątyń/wyroczni w starożytnej grecji.

Tutaj mamy obraz jednej z Delfijskich kapłanek:


Wracając do cytatu - poniekąd też dostaliśmy prawa od Delfi. Całość jest ściśle zintegrowana z językiem Delphi i IDE, dzięki czemu uzyskaliśmy własnego "clickera" do tworzenia gier.

Co więcej Delphi zawsze towarzyszą Ateny. Motyw Aten najwidoczniejszy jest w ikonkach starszych wersji i obecnie w ikonce RAD Studio 2010. Objawia się w grafice Partenonu w wersji demo (ma trochę mniej kolumn - może to wcale nie Partenon?):



Przy okazji przedstawiam ikonkę samego Delphi:



Co mają Ateny do naszej Sparty?

W wojnach perskich na początku V w. p.n.e. Sparta (miasto o pow. 300 ha i 8 tys. mieszkańców) była połączona sojuszem z Atenami – Termopile. W połowie stulecia doszło jednak do konfliktu między tymi najsilniejszymi greckimi polis. Wojnę tę, zwaną peloponeską wygrała Sparta, dzięki czemu zdobyła hegemonię w Helladzie. Zarówno Ateny jak i Sparta na przemian były opłacane przez Persję.


Po prostu Sparta to idealne wpasowanie się w klimaty - tego co robimy i języka/środowiska pod które piszemy.

Co jest symbolem Sparty? Otóż jest nim grecka litera Lambda, od Lakonii, przedstawiany najczęściej na tarczach. Oficjalne logo stworzone przez naszego grafika Ftorka jest widoczne na samym początku wpisu, nawiązuje do samej lambdy jak i tarczy:



Nazwa i charakter teamu DaThoX. Jesteśmy jak spartanie.

Poza klasycznym tekstem Leonidasa "This is Sparta!" warto nadmienić:

Państwem spartańskim zachwycała się oligarchia ateńska oraz filozofowie na czele z Platonem. Zachwycała ich prostota życia, jasność prawa oraz wysokie morale społeczeństwa mające swój wyraz w poświęceniu się całkowicie ideałowi wielkości Sparty. Do dziś jej historia jest klasycznym w swej oryginalności wycinkiem historii Hellady.


;)

Życie spartanina było ciągłym zmaganiem się z własnymi słabościami. Trening zaczynał się od dnia narodzin


Pierwsza wersja w chwili gdy nie było do końca wiadome czy uda się podłączyć pod RAD Studio w sposób oczekiwany, nazwa kodowa brzmiała "Termopile".

Bitwa została przedstawiona w filmie 300. Cóż. Mieliśmy podobną sytuację.

Spartanie dowiedli wówczas, że wolą zginąć niż się poddać


My jednak łamiąc historyczną tradycję żyjemy, a nasz prototyp działa. :)

PS. Sparta uchodziła za najpotężniejsze państwo starożytnej Grecji:

http://www.spartan3.republika.pl/sparta.htm

Pozdrawiam wszystkich, którzy przebrnęli przez ten cały długi wpis :)!

czwartek, 6 stycznia 2011

Cisza w eterze

Prawie pół roku bez postów :). Pracuję od wielu miesięcy nad bardzo dużym projektem. Całość ma już ponad 150k LOC. Niebawem będę mógł ujawnić nieco więcej szczegółów o prowadzonych od czerwca pracach. Sądzę, że to będzie wielkie zaskoczenie dla wszystkich, zwłaszcza dla programistów Delphi :).

Przez ten cały czas zdążyło wyjść "RAD Studio XE" a w nim masa naprawionych błędów z wersji poprzednich (liczone w tysiącach). Jednak szału nie ma. Po pierwsze, żadnej większej nowości w składni. Np. {$STRONGLINKTYPES ON} obecne już w Delphi 2010 tylko nieudokumentowane (strasznie nie lubię tej dyrektywy ponieważ ma działanie na wszystkie deklarowane typy w projekcie i nie można "silnie zlinkować" wybranych klas, wielka szkoda...).

Pomimo, że mam licencję na XE, nie używam go. Dodanie jednej funkcjonalności do RTTI to stanowczo za mało. TVirtualMethodInterceptor - klasa umożliwiająca przechwycenie/zastąpienie dowolnej metody wirtualnej w instancji klasy to trochę za mało. Dodano też moduł do wyrażeń regularnych i klika mniejszych usprawnień.

Podstawową przeszkodą w używaniu DelphiXE jest debugowanie IDE w IDE... Nowa wersja przysporzyła mi kilku kłopotów np. w OTA zmieniając zachowania niektórych elementów. Nie wspomnę już o beznadziejnej dołączonej do Delphi wersji (DEMO! WTF?) AQTime 7 która wywala się na moich projektach -,-...

Jako ciekawostkę przytoczę post mówiący o historii kompilatora Delphi, napisany przez Allena Bauera (Embarcadero Chief Scientist):

It is mostly C, with very little C++. The Delphi32 bit compiler was a port from a (at the time) Borland Pascal compatible Atari ST compiler that targeted the 68000 CPU. It was called "Pure Pascal." Borland purchased the IP and contracted with the original author to create an x86 backend. While much of the original architecture remains, it is so significantly different that it hardly looks like the original code.

I personally worked with the original author for many months to get the Borland Pascal RTL and Turbo Vision building for 32bit. That work was put aside and things shifted to the new fledgling Delphi project. Even while the Delphi project was in full swing and initially targeted Windows 16bit, work continued on the 32bit compiler. That work had also shifted to add the Delphi specific language features.

The original Turbo Pascal compiler targeted the Z80 CPU and was written in Assembler. At the behest of Philippe Kahn, Anders Hejlsberg ported the assembler to 8086 and targeted the same. Because the 8086 is an evolution of the 8080A (as is the Z80), it shared many of the same opcodes as the 8080A/Z80/8085, so the port was fairly mechanical. This is also why that up through Turbo Pascal 3.0 the compiler would only
create .COM file, which was limited to 64K.

The Turbo Pascal/Borland Pascal/Delphi compilers have never been written in Pascal. Not because it isn't possible, but was simply not practical or economical. Academically, yes, many times it is the goal of the compiler author to get the compiler to the point where it can compile itself. This is usually the first "real-world" use of a new compiler and serves as a validation suite. However, the world of
commercial software has more practical and economic factors that weigh heavily in the development process.


Na deser:

mały obraz z Delphi64 bit (ma wyjść w tym roku) i CHASM (nie ma już BASM):