Autor Wątek: Planowanie silnika wieloplatformowego  (Przeczytany 3934 razy)

Offline baca130

  • Użytkownik

# Styczeń 05, 2011, 15:19:04

1. virtual - czy to dobry sposób, czy jak stworze uniwersalną klasę Renderer i pod nią podpiąć biblioteki directx(win) i ogl(win, linux, mac, android, ios, ...)
   a)
    class Renderer {...}
#ifdef directx

class RendererDX9 : public Renderer {...}
#endif
#ifdef opengl

class RendererOGL : public Renderer {...}
#endif
   b)
   czy może lepiej użyć osobnych klas Renderer dla różnych platform:
    #ifdef WIN32
class Renderer{...};
#endif
#ifdef LINUX
class Renderer{...};
#endif
...
   czy może dla wielo platformowego silnika zrezygnować z klas i pisać w czystym "C"?

2. Singleton - czy warto użyć jednej klasy dla całego silnika np. Renderer w którym są poszczególne klasy odpowiadające za komunikację z kartą,
   inicjowanie, rysowanie...?

3. Wiele klas - Czy tworzenie dużej ilości klas ułatwiających projektowanie silnika ma sens?
   np klasa Windows, klasa Renderer, klasa Sprite...i tysiąc innych.
   
4. Tworząc silnik brać pod uwagę optymalizację kodu, czy może swobodę i prostotę pisania.

5. Dokumentacja - tworząc silnik który będzie dystrybuowany tylko w postaci binarnej jako cześć innego programu, to czy warto tworzyć dokumentację?
6. Czy warto używać directx, który jest tylko dla jednej platformy?, Czy lepiej postawić na open gl?
7. Jak potencjalni odbiorcy patrzą na gry, które składają się z jednego pliku zamiast kilku set, tysięcy elementów?
8. Jak najlepiej umieścić dane w pliku wykonawczym silnika, coś w rodzaju game makera?
9. Czy warto wspierać wiele formatów mediów, czy lepiej postawić na najpopularniejsze? png, jpg, bmp, mp3, waw?, Czy może lepiej opracować własne. tak jak xenon core?
10. Czy warto tworzyć własny język skryptowy, a może lepiej skorzystać z gotowego np: lua i własną nałożyć nakładkę (w edytorze kompilować do lua byte code i w silniku go odpalać) uzupełniając brakujące funkcję języka.

1. Stosuję klasy wirtualne , wolę sposób a, między innymi do renderingu, okien, dźwięku
2. Stosuję singleton.
3. Używam wielu klas ponieważ jest to najprostszy i najefektywniejszy sposób według mnie.
4. Wolę tworzyć tak, żeby się nie pogubić w silniku.
5. Skoro tylko ja będę do niego zaglądał nie stosuję dokumentacji. zwłaszcza że gubię się jak silnik jest opisany, ponieważ wolę analizować kod, żeby go zrozumieć(obecnie mój silnik 'visual game studio'- ma 412 plików kodu i 4592,42kb samego kodu, czy się w nim gubię? Nie.).
6. Używam dx9 i próbuję go przepisać na czysty open gl, ale ciężko mi idzie, według mnie dx9 jest prostszy.
7. Wolę jak jest wszystko w jednym pliku(oczywiście mówię o grach małych w których jest to możliwe).
8. Wpakować na koniec i odczytać za pomocą tokenu. (np: "'\0', '\0', 'V', 'S', 'G', 'd', 'a', 't', 'a'", wielkość danych). A może lepiej z silnika odpalić jeden główny skrypt a z niego resztę tak jak to robi Torque, Angel, Lova, itd...
9. Według mnie lepiej wybrać konkretny format zamiast niepotrzebnie zaśmiecać silnik, np.: png, mp3...
10. Wolę gotowca z nakładką. Gotowiec dlatego bo nie muszę się martwić o szybkość i przenośność kodu a nakładka, żeby dostosować do własnych potrzeb, dodać brakujące funkcję i być może w przyszłości zastąpić gotowca.

Mimo, że odpowiedziałem na moje pytania, proszę o waszą opinię. No i sorry za mało jasne pytania.

Offline Mr. Spam

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

Offline Krzysiek K.

  • Redaktor
    • DevKK.net

# Styczeń 05, 2011, 15:45:23
1. Za dużo różnic w API, by to generalizować.
2. Jak dla mnie singleton jak najbardziej (a dokładniej: globalna zmienna danej klasy). Nie ma sensu jednek mnożyc klas podrzędnych.
3. Klas rób tyle, ile potrzeba. Nie mniej, nie więcej.
4. Jedno i drugie. W którym kierunku przesadzisz, będzie źle.
5. Zależy ile osób ma nad tym pracować i ile czasu chcesz poświęcić na dokumentację.
6. Warto. Poza tym w praktyce OpenGL też nie jest tak przenośny - na urządzeniach mobilnych masz OpenGL ES (który się od pełnego ogla nieco różni), a konsole to już w ogóle osobna działka.
7. Po prostu na to nie patrzą.
8. Tylko po co umieszczać?
9. Postawić na najpopularniejsze.
10. Skorzystać z gotowego. Szkoda czasu na zabawę (no, chyba że Tobie nie szkoda).

Offline SeaMonster131

  • Użytkownik

# Styczeń 05, 2011, 15:51:30
Ja dopowiem do pkt 6:
z badań wynika że w 2010 roku ~95% użytkowników komputerów używa Windows. Więc sam zdecyduj czy będziesz pisać w OpenGL dla tych 100% użytkowników komputerów czy dla tych 95% w DirectX.
Ja osobiście pisze dla tych w Windows hehe ;)

Offline Kos

  • Użytkownik
    • kos.gd

# Styczeń 05, 2011, 16:11:53
@OP: Zapomniałeś, do czego służy OpenGL.

Jeżeli chcesz napisać wieloplatformowy silnik, to OGL jest po to, byś NIE MUSIAŁ robić wszystkiego, o czym mówisz - napiszesz jeden renderer na oglu i pójdzie wszystkim.

Proste!

Offline Reg

  • Administrator
    • Adam Sawicki - Home Page

# Styczeń 05, 2011, 16:25:26
Ogólnie rzecz biorąc to są trudne pytania. Odpowiedzi na nie przyjdą raczej z doświadczeniem, nie ma możliwości żeby przeskoczyć wielokrotne popełnianie błędów, rozpoczynanie pisania od nowa i od razu znać najlepsze rozwiązanie. Ale można próbować. Moja (niekoniecznie obiektywna) opinia...

1. virtual, jeśli chcesz mieć możliwość zmiany renderera na inny w tym samym systemie operacyjnym, np. pod Windows wybór DirectX albo OpenGL.
2. Chyba tak. Równie dobrze może być wiele singletonów - osobno renderer, system dźwiękowy, manager zasobów, logger i inne takie podstawowe systemy.
3. Nie, wymyślanie jak najwięcej klas może moim zdaniem utrudnić pisanie. Lepiej pisać jak najprostszy kod, a nowe klasy wprowadzać albo istniejące rozbijać na części wtedy kiedy jest to potrzebne.
4. Jedno nie wyklucza drugiego. To że pisanie wydajnego kodu jest sprzeczne z jego czytelnością to jest popularny mit pośród tych, którym "optymalizacja" kojarzy się tylko z przepisaniem kodu na asembler :P Jeśli znasz jakieś techniki na pisanie silnika w taki sposób, żeby działał wydajnie, to je stosuj.
5. Hmm... Z umiarem. Możesz na przykład dodawać komentarze opisujące funkcje, klasy i ich metody w plikach nagłówkowych. Możesz je pisać w specjalny formacie, żeby potem Doxygen automatycznie wygenerował z nich dokumentację. Możesz też spisać ogólne informacje na temat swojego kodu dotyczące takich rzeczy, które nie są oczywiste, żeby za jakiś czas, kiedy wrócisz do tego kodu, można je było sobie łatwo przypomnieć.
6. Kwestia gustu i nigdy niekończący się spór :) Ja stoję po stronie DirectX. Przypominam też, że większość gier na PC korzysta właśnie z DirectX. Oraz że zdecydowana większość gier PC wymaga, a większość graczy korzysta z systemu Windows. Dlatego pomyśl, czy warty zachodu jest dodatkowy - duży! - wysiłek włożony w przenośność kodu na Linuksa.
7. Bardzo pozytywnie. Kiedy gra ma swoje zasoby wpakowane do jakiś własnych archiwów VFS, to wygląda profesjonalnie. Tak robi większość poważnych gier.
9. Postawić na najpopularniejsze, a jeszcze lepiej na tylko te których będziesz używał. Najlepiej na tylko jeden z nich i wszystkie zasoby przygotować dla gry w tym formacie (np. tekstury DDS, modele w jakimś własnym formacie, dźwięki WAV, muzyka OGG).
10. Zdecydowanie wykorzystać gotowy język. Pisanie własnego języka skryptowego to fascynujący temat, ale tak obszerny, że musiałbyś się raczej zająć tylko tym, a nie pisaniem silnika 3D.

Offline Krzysiek K.

  • Redaktor
    • DevKK.net

# Styczeń 05, 2011, 16:31:41
Cytuj
Jeżeli chcesz napisać wieloplatformowy silnik, to OGL jest po to, byś NIE MUSIAŁ robić wszystkiego, o czym mówisz - napiszesz jeden renderer na oglu i pójdzie wszystkim.
Urban myth. Gdyby tak było, to życie game developera było by różowe. Niestety, pod Windowsem masz DX9/10, pod XBoxem masz DX9E, pod PS3 nie masz nic tylko po ringu piszesz.

Offline Kos

  • Użytkownik
    • kos.gd

# Styczeń 05, 2011, 16:41:37
@up - a jeśli celujemy tylko w Windows/Mac z silnikiem (bo czemu nie?), to czy cokolwiek stoi na przeszkodzie, by używać wyłącznie OpenGL-a?

Offline Dab

  • Redaktor
    • blog

# Styczeń 05, 2011, 16:42:02
W tej sytuacji wspieranie DX wydaje mi się bezsensowne. Dobrą obsługę OpenGL masz na Maku, Linuksie i większości Windows (nie licząc 6%* grafikopodobnych produktów Intela, ale przy rezygnacji z części funkcjonalności da radę i na tym odpalić grę). Na platformach mobilnych masz OpenGL ES który się trochę różni od zwykłego (nie zapominaj że ES1 = fixed pipeline, ES2 = tylko shadery). W każdym razie olewając Intela i platformy mobilne bez shaderów można mieć wieloplatformowy renderer OpenGL z umiarkowaną ilością kombinowania funkcjonalnościami.

Aczkolwiek nie wiem czy jest praktyczny sens pakowania się w platformy desktopowe i mobilne naraz (zwłaszcza bez doświadczenia w obu). Nie widziałem jeszcze dużego silnika który by wspierał oba targety (które są diametralnie różne, nawet bardziej niż PC vs X360/PS3).

* wg. Steam Hardware Survey

Natomiast na pozostałe pytania generalnie nie da się odpowiedzieć jednym postem. Po napisaniu kilku silników sam będziesz miał świadomość co jest dobre, a co nie. :)

BTW

Cytuj
ma 412 plików kodu i 4592,42kb samego kodu

Mi z szybkich obliczeń (średnio 15 znaków na linię) wychodzi z grubsza 300000 linii kodu -- solidny projekt :) aczkolwiek dziwią mnie w takim razie niektóre pytania.
« Ostatnia zmiana: Styczeń 05, 2011, 16:44:58 wysłana przez Dab »

Offline baca130

  • Użytkownik

# Styczeń 05, 2011, 16:51:28
up: 2 lata programowania no i się trochę nazbierało.

Offline Krzysiek K.

  • Redaktor
    • DevKK.net

# Styczeń 05, 2011, 16:57:12
Cytuj
nie licząc 6%* grafikopodobnych produktów Intela
W takim razie lepiej już odrzucić 0.1% grających linuksowców, niż 6% grających intelowców. ;)

Cytuj
Nie widziałem jeszcze dużego silnika który by wspierał oba targety
A Rage Carmacka? ;)

Offline yarpen

  • Użytkownik

# Styczeń 05, 2011, 16:59:25
UE tez chodzi na Iphone/Ipad/I*.

Offline Dab

  • Redaktor
    • blog

# Styczeń 05, 2011, 17:09:23
Cytuj
W takim razie lepiej już odrzucić 0.1% grających linuksowców, niż 6% grających intelowców. ;)

Patrząc na wyniki http://www.humblebundle.com/, grających jabłeczników i linuksiarzy jest nieporównywalnie więcej w stosunku do podawanych publicznie statystyk (0.1% rzekomego udziału Linuksa).

Cytuj
A Rage Carmacka? ;)

Carmack w którymś z wywiadów powiedział że silnik Rage nie ma nic wspólnego z id Tech, jest to przeróbka silnika z mobilnego Dooma3 (którego w ogóle nie napisało ID software) używająca tych samych formatów plików co id Tech 4.

Nie wiem jak z UE.

Offline Karol

  • Użytkownik

# Styczeń 05, 2011, 17:14:12
7. Jak potencjalni odbiorcy patrzą na gry, które składają się z jednego pliku zamiast kilku set, tysięcy elementów?
Ja na to zwracam uwagę, część moich znajomych także. Gry posiadające tysiące pliczków z zasobami niezmiernie mnie irytują, ponieważ:

  • długa instalacja, kopiowanie "rozpędza się" tylko dla dużych plików, a kopiowanie wielu małych pliczków jest wolne, szczególnie czuć to jeżeli instaluje się z płyty CD/DVD, a krew zalewa jak te pliki są po całej płycie rozsiane (zdarzają się takie przypadki, i to wcale nie tak rzadko i zamiast szybkiej instalacji jest tutorial scratchowania płytą)
  • adekwatnie długa deinstalacja
  • lubię w TotalCmd sprawdzać objętość folderów i jak jakiś ma dużo plików to.. frustracja rośnie  :o
  • brak "rispektu" i podejrzanie o lenistwo, zlepienie wielu plików w jeden i utworzenie jakiegoś indeksu to chwila roboty i tylko odrobinka kodu

Offline K'Aviash

  • Użytkownik

# Styczeń 05, 2011, 17:46:22
Brak archiwów daje możliwość swobodniejszego "pogrzebania w bebechach", dla niektórych, np. mnie kusząca :D
Z tym, że z punktu widzenia niektórych developerów chowanie contentu jest ważne 

Offline Liki

  • Użytkownik

# Styczeń 05, 2011, 22:26:16
Nie widziałem jeszcze dużego silnika który by wspierał oba targety (które są diametralnie różne, nawet bardziej niż PC vs X360/PS3).

Jest jeszcze Unity3D, co prawda nie celuje w gry AAA, ale raczej mobilne lub przeglądarkowe, niemniej działa na platformach mobilnych, PC i konsolach stacjonarnych.