[piotrdz]

A więc ogłaszam wszem i wobec - mamy projekt w CMake, który kompiluje się pod MinGW

Istnieją teraz dwie gałęzie w repozytorium:
- główna (master)
- rozwojowa mingw_dev, gdzie oprócz plików z głównej są też pliki CMake i instrukcja jak skompilować projekt pod MinGW

Również sprawdziliśmy, że projekt kompiluje się pod VisualStudio 2008 i 2010.

Niestety, jest problem z grafiką. Objawia się to tak, że:
- pod MSVC6 wszystko działa poprawnie
- pod każdym innym kompilatorem, nie działa.
Prawdopodobnie jest zepsute ładowanie tekstur efektów, tylko trudno to zdebugować.

Poza tym odkryliśmy problem z colobot.ini - przed uruchomieniem programu czasem trzeba usunąć stary plik (z "zepsutej" wersji programu).

Ale wyłączając te błędy, nad którymi będziemy też pracować, mamy wreszcie bazę, od której możemy pracować dalej. Proponuję, aby teraz przyjąć następujący plan działania:

1. Dokonać sensownego podziału kodu na:
- CBot (już wydzielony),
- główną aplikację,
- silnik grafiki,
- silnik fizyczny,
- typowe klasy modeli, czyli roboty itp.
- jeszcze parę innych pewnie się znajdzie

2. Pozbyć się zależności do typów D3DVECTOR, D3DMATRIX wszędzie poza silnikiem graficznym - trzeba po prostu napisać własne struktury i funkcje matematyczne (zebrać je z d3dmath i math3d).

3. Jak to skończone - popatrzeć na interfejs silnika grafiki i sklonować to samo, tyle że w OpenGL.

4. Tak samo zrobić z modułem samej aplikacji - funkcje WindowsAPI zastąpić SDL.

No i na koniec powinniśmy mieć przeportowaną grę. Tyle, że łatwo powiedzieć, trudniej wykonać. Czas pokaże, jak to wyjdzie.

Edit: oczywiście "my" to ja i Programerus.

[PoxiPol]

Twoje dzialania sa blogoslawienstwem, porownujac twoj entuzjazm, do wiekszosci reszty. No ale zeby nie bylo ze na kogos zle mowie, rozumiem ze teraz jest szkola, i sa problemy i matura itd : P Na pelny ruch czekam do wakacji.
Na Github z tym!

[Programerus]

@PoxiPol: A ja to co? Nie zauważyłeś, że cały post jest pisany w formie "my"?

[piotrdz]

No właśnie, zapomniałem dopisać Programerusa.

No cóż, do tej pory miałem trochę czasu, ale niestety w maju będę miał mniej. Być może rzeczywiście dopiero od czerwca zacznie się dziać więcej.

Edit:

Ha! Pomoc Programerusa, przebłysk geniuszu i zakomentowanie 4 linii w kodzie i efekt... grafika działa! Pod MinGW i VisualStudio 2010!

Dowód: http://i.imgur.com/awmuZ.jpg

Edit2:

Teraz trochę odwróciła się sytuacja - w głównej gałęzi mamy projekt już w CMake. Jak ktoś chce skompilować z MSVC6 albo Visualem, to niech sobie przywróci pliki projektu z poprzednich commitów. Docelowo CMake zostaje - (w przyszłości) można nawet wykorzystać jego różne generatory i kompilować z kompilatorem Visuala.

[PoxiPol]

Ty wygrales uzytkownik miesiacaa, wiec no : P

[lukas_j]

Gratuluje solidnej roboty! Zaraz pobieram i coś testuje. Nareszcie coś ruszyło, to może w końcu zaczne coś robić przy tym projekcie

[piotrdz]

Przez długi weekend coś spróbuję ruszyć. Założyłem nową gałąź dev - z podziałem kodu na moduły i próbuję przepisać funkcje i struktury matematyczne (na razie jest tam bałagan, więc nie sugerujcie się tym).

Update: struktury Vector i Matrix w zasadzie gotowe. Pozostaje jeszcze zaimplementować pozostałe funkcje i przetestować dokładnie.

Update 2:
Niestety, mój czas wolny się skończył - dodałem opis, co zrobiłem i co jest jeszcze do zrobienia w pliku README-DEV.txt. Zbliżają się zaliczenia i sesja, więc chyba dopiero w czerwcu będę miał czas zająć się tym dalej

[krzys_h]

Szkoda, że nie znam DirectX ani OpenGL, nie mogę pomóc w portowaniu Ale zajmę się innymi usprawnieniami

[piotrdz]

OK. No to prawie ustaliliśmy spotkanie na IRC, ale nie zaszkodzi napisać jeszcze kilka szczegółów technicznych tutaj, czyli o czym chcę porozmawiać.

Jak widać, moja praca dotychczas skupiła się na module z funkcjami i strukturami matematycznymi (Matrix, Vector, Point). Praca jest w ok. 70% skończona. Tutaj mogę kogoś "zatrudnić" do pomocy przy testach.

Dalej, dokumentacja kodu kuleje i to bardzo. Nie ukrywam, że bardzo potrzebne jest ogólne rozeznanie. Nie chodzi tu tylko o grafikę, bo tym tak czy siak będziemy się zajmować, ale też o klasy robotów itp. Chodzi o to, żeby mieć taki "plan" kodu - wiedzieć po prostu co za co odpowiada. Ważny jest też podział projektu na podmoduły. Ten podział, który wykonałem jest na razie wstępny.

Dalej tak - sam silnik graficzny to zbiór funkcji w modułach, które zebrałem osobno w graphics/d3d. Niestety w innych miejscach znajdują się moduły, które częściowo korzystają z D3D i niestety trudno będzie rozdzielić do końca różne funkcjonalności. Idealnie, interfejs silnik graficzny <-> reszta gry powinien być jak najwęższy, żeby się nie natrudzić z pisaniem i portowaniem wszystkiego. I ten interfejs trzeba będzie ustalić i ściśle rozdzielić na odpowiednie klasy. I tutaj przydałby się ktoś z doświadczeniem w D3D, bo bardzo trudno będzie wszystko ogarnąć.

I teraz co do samego sedna problemu portowania. Możemy przyjąć dwie strategie:
- zachować cały kod windowsowy i D3D w niezmienionej formie i tylko dopisać nasze nowe moduły, a z czasem po prostu wyeliminować stary kod,
- wywalić/zakomentować kod windowsowy i D3D i wszystko spróbować przepisać od nowa.

Obie stategie mają swoje zalety i wady. Moim zdaniem łatwiejsza będzie opcja nr 2, bo od razu uzyskamy coś - jeszcze nie całą grę, ale już coś - co będzie działało pod Linuksem. Potem będziemy mieli, że tak powiem, większą zachętę do pracy. No ale sporo w sumie będzie zależało od złożoności kodu.

To zostawiam wam to do przemyślenia. Dyskusję oczywiście będziemy kontynuowali na IRC.

[piotrdz]

Ech, głupie forum mnie wylogowało, ale post jest jak widać.

[patrolez]

Myślałeś już o zrobieniu wizualizacji w postaci wygenerowanego diagramu UML? Myślę, że od tego by warto zacząć z dokumentacją. Z takim diagramem wszystko widać.
http://www.youtube.com/watch?v=efd0wEYkUk0

[ Dodano: 08-06-2012, 15:02 ]
W sensie dziedziczenie, polimorfizm, agregację, metody, pola i ich rodzaje etc. etc.

[piotrdz]

Doxygen już nam generuje dokumentację klas z takimi diagramami. Ale to nie pomaga za wiele, bo kod prawie nie wykorzystuje dziedziczenia -- są bodajże tylko trzy drzewa dziedziczenia w stylu klasy CAuto* dziedziczą po CAuto. Łatwo się w tym połapać i właściwie już wiemy mniej więcej co gdzie jest.

Za to ważniejsze teraz jest udokumentowanie poszczególnych zależności i tego, jak współpracują różne klasy. Np. jak przekazywane i obsługiwane są zdarzenia np. z klawiatury, jak działają poszczególne obiekty budynków itp.

PS. Widzę kolega też z PWr

[ Dodano: 19-06-2012, 20:50 ]
Po ostatnich zmaganiach z kodem, miałem okazję trochę więcej przejrzeć i zrozumieć strukturę silnika grafiki. I teraz widzę, że w sumie problemów będzie mniej niż się spodziewałem. W kodzie jest co prawda kilka przypadków specyficznego wykorzystania D3D, których nie da się tak łatwo przenieść na OpenGL, ale z drugiej strony np. kod ustawiający transformacje widoku, projekcji itp. jest w słownie dwóch, trzech miejscach. Co więcej, większość właściwego rysowania obiektów to po prostu wywoływanie DrawPrimitive() z tablicą D3DVERTEX albo D3DVERTEX2, czyli coś, co da się prosto przenieść do OpenGL. Zatem podstawową funkcjonalność można uzyskać w zasadzie niewielkim kosztem.

Za to widzę już, że aby ruszyć z dalszymi modyfikacjami np. nowymi robotami itp., trzeba będzie sporo kodu przepisać zupełnie od nowa. Np. w każdym miejscu, gdzie sprawdzany jest warunek np. czy jakiś robot/budynek jest blisko, jest przeglądana lista wszystkich istniejących obiektów. I jest to porówywane na zasadzie if (object->RetType() == ...). Czyli każdy nowy rodzaj obiektu musi być we wszystkich takich porównaniach uwzględniony. Jednym słowem: brakuje *klas* obiektów.

Ale wracając do grafiki, mam już mniej więcej plan jak zrobić to przejście do OpenGL. Trzeba zacząć od napisania uniwersalnych struktur: Color, Light, Vertex, rozszerzony Vertex (D3DVERTEX2). Dalej trzeba przenieść cały wykonujący właściwe funkcje D3D do d3dengine.cpp - chodzi tu głównie o moduły z graphics/common. I po tym można już napisać analogiczną implementację CD3DEngine w OpenGL. Równolegle trzeba będzie popracować nad d3dapp.cpp i przeniesieniem kodu WinAPI na SDL.

Myślę, że całość jest do zrobienia przez wakacje, trzeba się tylko zorganizować.