[piotrdz]

A więc rozpoczęła się główna faza przenoszenia kodu. Szykuje się dłuuugi post, ale proszę o cierpliwość

0. Skrót TL;DR Jest szkielet w SDL/OpenGL. Potrzeba chętnych do kodowania.

1. Informacje ogólne.

Istnieją teraz dwa pliki, które są tworzone w kompilacji:
- colobot_old - składa się ze starych modułów w DirectX i WinAPI
- colobot_new - składa się z nowych modułów w SDL i OpenGL - na razie to jest tylko takie "Hello, world", ale kompiluje się pod Linuksem

Stare pliki zostały przeniesione do src/old, a w ich miejsce dodaliśmy szablony nowych klas. Teraz trzeba będzie zająć się pisaniem implementacji tychże klas, ale z wykorzystaniem tylko OpenGL (i miejscami SDL).

Ogólnie to chciałbym, żeby docelowo było tak:
src/app -> klasa CApplication + wszystko związane z samym SDL'em + jakieś systemowe rzeczy
src/common -> wspólne struktury, definicje itp. bez żadnych zależności
src/graphics/common -> interfejs silnika CEngine i samego urządzenia 3D CDevice (bez konkretnej implementacji) + wszystkie "efekty" (CCamera, CLight, CParticle, ...) napisane tak, że operują na tym interfejsie silnika
src/graphics/opengl -> konkretne implementacje CEngine i CDevice w OpenGL: CGLEngine, CGLDevice
src/graphics/d3d -> w (odległej) przyszłości być może implementacja w nowszym DirectX (9? 10?)
src/object -> nie-graficzny silnik gry, czyli roboty, budynki itp. -- bez żadnych zależności do konkretnej implementacji OpenGL
src/ui -> interfejs okienkowy 2D (menu, przyciski itp.) -- też bez zależności do konkretnej implementacji
src/sound -> dźwięki i muzyka -- tutaj można zastosować bibliotekę OpenAL
src/physics -> w zasadzie zastanawiam się, czy nie przenieść do src/object
src/script -> łącznik z biblioteką CBot

2. W czym potrzebuję pomocy.

Zajmuję się obecnie nową klasą CApplication i silnikiem graficznym. Ale to nie oznacza, że nie można pracować równolegle. Potrzebne są następujące rzeczy:
- Zmiany w CBot tak, żeby uniezależnić bibliotekę od WinAPI
- Przepisanie kilku rzeczy w src/common, żeby też uniezależnić się od WinAPI,
- Przepisanie części rzeczy z src/object, tak, żeby zlikwidować zależności do DirectX. Zamiast operować na DIRECT3DDEVICE, zrobić to samo na (starym) CD3DEngine. W sumie sam mogę się tym zająć, ale pomoc by się przydała.
- Testowanie. Nie zaszkodzi, jak ktoś od czasu do czasu skompiluje kod z repo i sprawdzi, czy coś nie jest zepsute.
- Dokumentacja. Przy nowych klasach, tworzę ją na bieżąco. Ale są klasy z src/object, którymi już się nie zajmuję (bo nie mają już zależności), które ktoś może rozszyfrować.

3. Decyzje do podjęcia.

Przydałoby się podjąć kilka decyzji w sprawach, które częściowo już się pojawiły, a na pewno pojawią się wkrótce:

1. Czy przenieść kod z gałęzi dev do master?
Być może to sprawi lepsze wrażenie, że coś się dzieje na githubie Można otagować obecny commit jako np. alpha-0, bo być może to ostatni moment, kiedy stary i nowy kod jest w jednym miejscu. Jakby co, zawsze można wrócić do tego momentu.

2. Na ile "ukryć" implementację SDL w programie?
To, że kod np. operujący na oknie programu będzie ukryty to oczywiste, ale są też inne rzeczy. Ukrywając implementację np. wszystkie zdarzenia z klawiatury itp. będą musiały być przepisywane ze struktur SDL do naszych własnych struktur. Będzie to trochę żmudne i być może w przyszłości będziemy chcieli wykorzystać jeszcze jakiś szczegół implementacji z SDL, a nie przewidzieliśmy tego w naszych strukturach. Ja jestem za ukryciem SDL'a w 100%, bo trochę będzie z tym roboty, ale kod będzie za to bardzo niezależny. Ale pytam was, bo nie chcę niczego narzucać.

3. Co zrobić z restext i tłumaczeniem tekstu?
Moja propozycja - użycie biblioteki gettext. Zaleta: łatwo jest dodać nowe tłumaczenia (to tylko dodanie osobnego pliku z tłumaczeniem). Wada: w kodzie nam się trochę może namieszać za sprawą kodowania UTF-8, bo w zasadzie tylko takie jest uniwersalne w tym przypadku.

4. Co zrobić z wyświetlaniem tekstu?
Obecnie jest to tablica znaków zapisana w teksturze. Proponowałbym dać jakąś otwartą czcionkę TTF i wykorzystanie biblioteki SDL_ttf. Mam napisany w innym projekcie cały silnik renderowania tekstu w UTF-8, chociaż nie wiem, jak szybko będzie to działało przy dużej ilości tekstu. Bo najszybciej jest oczywiście tak, jak teraz - przez teksturę i stałą stronę kodowania.

Jeszcze pewnie kilka rzeczy wyjdzie w praniu.

Wszystko to, co opisałem tutaj postaram się też wstawić do README w repo.

I jeszcze taka uwaga - od 2 lipca zaczynam praktyki, więc mniej czasu będę mógł poświęcić nad projektem. Bardzo przydałby się ktoś, kto przejmie część obowiązków.

A i jeszcze jedno, napisałem do osób, które sforkowały repo na githubie zapraszając ich do naszego projektu.
Update z ostatniej chwili: dwie osoby są chętne do dołączenia do projektu. Jedna z nich to programista z USA, więc projekt jest już międzynarodowy

[krzys_h]

Co do "rzeczy do ustalenia":
1. Tak
2. Tak
3. Tak
4. Tak

Cieszę się że prace cały czas idą do przodu. Postaram się pomóc przy dokumentacji src/object/

[piotrdz]

Dobra wiadomość: nawiązałem kontakt z rzeczonym programistą z USA. Czyta nasze forum przez Google Translate, więc wie, że coś działamy (Jeremy, if you're reading this, cheers ). Więc wygląda na to, że zabierzemy się razem do pracy.

Ktoś jeszcze wypowie się oprócz krzys_h? Nie chcę być w projekcie "dyktatorem" i podejmować decyzje "bo tak", więc jak ktoś ma coś do dodania, to zapraszam.

[Raptor]

Znać się nie znam, ale czcionki istotnie powinny być generowane natywnie, zamiast tekstur. W chwili obecnej, przy rozdzielczościach większych niż VGA, wygląda to po prostu słabo.

Chciałbym wspomnieć też o tym, że w późniejszych pracach nad źródłem powinniśmy uniezależnić grę od zasobów DAT. Wszystkie zasoby będą leżały estetycznie, w osobnych katalogach. Będzie łatwiej wtedy cokolwiek podmieniać bądź dodawać (obiekty, dźwięki, tekstury). Trzeba pamiętać też o zmianie formatów modeli i tekstur na bardziej standardowe i łatwo edytowalne. Ale to również robota na dalszy plan.

[adiblol]

[piotrdz]

Cytat:

Unicode to bezwzględna konieczność. Bez tego mamy zabawkę a nie program komputerowy.

Pytanie tylko, czy Unicode 16-bitowe, czy UTF-8. Byłbym za tym drugim, bo łatwiej zintegrować z gettext, ale z kolei kod wyświetlania się komplikuje. Jakby co, to mam to zrobione dla UTF-8, tylko, że właśnie może okazać się wolne.

Cytat:

http://www.libsdl.org/projects/SDL_image/

O SDL_image już pomyślałem (jest już w CMakeLists.txt).

[ Dodano: 27-06-2012, 00:06 ]
Taki tylko update - w sumie zdecydowałem na usunięcie starych plików w src/old z repo. Zostaje tylko nowy kod w SDL/OpenGL w gałęzi dev. Dodatkowo, będą utworzone osobne gałęzie do rozwijania kodu np. już istniejąca dev-opengl, a zmiany będą merge'owane do dev - będzie to taka gałąź integracyjna. Więcej szczegółów w plikach README w każdej z gałęzi.

[Zaba_999]

Jo, Jo,

Czy mamy już jakiś konkretny plan działania. Bo widzę że trochę chaos panuje. Zatem myślę że trzebaby uzgodnić jakieś etapy prac. Ogólnie przydałby się ktoś kto będzie "zarządał" planami działania (nie koniecznie kumaty z programowania), tak aby nie było sytuacji że każdy robi co mu się podoba bo wtedy nic z tego nie wyjdzie.

Przydałoby się też środowisko/framework do testowania kodu. Np gtest/cpputest, tak aby można było sprawdzać czy poprawiany/pisany kod działa według naszych oczekiwań. Ewentualne popisanie testów charakteryzacyjnych aby można było kod modyfikować bez większego ryzyka rozwalenia go.

Ja osobiście na początek chętnie zająłbym się posprzątaniem kodu. Dokładniej doprowadzenia go do kompilacji i działania bez potrzeby używania flagi fpermissive, a następnie załączenie -Wall i wyczyszczenie wszyskich warningów i wywalenia martwego kodu.

Tylko nie wiem czy działamy na master branchu czy na dev no i nie mam konta na githubie, czy można takowe dostać, chyba że działamy na zasadzie zgłaszania patchy

M.

[piotrdz]

@Zaba_999: wbij na kanał IRC dzisiaj wieczorem, to wyjaśnię wszystko.

Generalnie to na mnie spadła organizacja wszystkiego i właśnie za chwilę biorę się za oficjalne wiki dla developerów. Dodam tam wszystkie informacje. Po części są one teraz rozrzucone na forum i w README w repo.

[Zaba_999]

Jo,

Ok postaram się wbić na IRC koło 21.30, niestety wczesniej nie dam rady.

pozdro

[piotrdz]

Ostatnio zrobiłem trochę porządków, więc daję informację też tutaj:
- silnik ściśle OpenGL-owy został już skończony i wydzielony w kodzie, stąd dev-opengl znika
- pojawia się dev-graphics -> dalsze prace nad silnikiem graficznym -> w zasadzie kod już ogarnięty, tylko przepisać go teraz
- pojawia się dev-ui -> już można zacząć pracować nad interfejsem 2D, być może jakieś okienka się pojawią niedługo

[ Dodano: 13-08-2012, 18:48 ]
Forum coś ostatnio przymarło, ale IRC aktywne jak mało kiedy. Prace ostatnio nabrały tempa.

Na chwilę obecną:

1. Silnik graficzny w zasadniczej części jest zaimplementowany.

Każda funkcja w src/graphics już ma implementację. No, tyle że część na razie nic nie robi - są to głównie klasy "efektów", które na razie można sobie podarować: CLightning, CParticle i CPyro. Pozostałe funkcje są przepisane na nowo, ale trzeba je teraz intensywnie przetestować. Do tego posłuży nadal gałąź dev-graphics.

2. Zaczynamy pracę nad drugą częścią grafiki, czyli interfejsem 2D (src/ui).

Powinno to już pójść szybciej, kod można też od razu testować, bo grafika, zdarzenia itp. już działają. Do prac służy gałąź dev-ui w repo.

3. Nic nie stoi już na przeszkodzie, żeby rozejrzeć się we właściwym silniku gry, czyli src/object.

Tam powinno być jeszcze mniej problemów. Więcej tak na prawdę zajmie przetestowanie wszystkiego i ogarnięcie wszystkiego tak, żeby dało się jako tako zagrać. Jest to cel nieco bardziej odległy od interfejsu 2D i grafiki 3D, ale z drugiej strony, silnik gry nie polega tak mocno na grafice i część rzeczy można już robić równolegle.


I teraz zła wiadomość: 15.08-22.08 jestem na urlopie. Prace nad dev-ui przekazałem kilku kompetentnym osobom, więc na pewno robota nie stanie


Prace są ogólnie na takim etapie, że każdy może coś zrobić. Nie wymagana jest w ogóle znajomość OpenGL czy nawet kodu grafiki w paru przypadkach. Więc wszystkich chętnych zapraszam na IRC.