Engine

[ra-v]

Witam...

Chciałem sie dowiedzieć jak to naprawde jest z enginami...

Wiem że to jest podstawa gry, ale jest także wiele darmowych enginów.

Czy do gry najlepiej robić własny czy wykorzystać już istniejący?

I potem jak już sie zrobi engin t trzeba wszystko jakoś dodawać w DirectX ?

 

Jakieś tutki ewentualnie...

Bo ciekawi mnie to a nie moge sie dowiedziec dokładnie co i jak...

[PelzaK]

Enginy do gier oczywiscie są darmowe... Engine to zazwyczaj są klasy napisane przez kogoś, które ułatwiają używanie DirectXa i/lub openGLa. Przykładowo... gdybyś chciał napisać program z wykorzystaniem DirectX i np animować na ekranie jakiś model zrobiony w 3d studio (np obracać) to zajęło by ci to powiedzmy 10 stron kodu...

Wliczając w to:

• inicjalizację directX
• wczytywanie ręczne pliku z 3ds i zamiana go na coś co roruzmie już directX
• animacja właściwa

Sama inicjalizacja DX to zadanie nie całkiem łatwe... musisz sprawdzić jaką masz kartę.. jakie tryby dostępne.. użyć jeden z nich etc... czyli innymi słowy piszesz ze 2 strony kodu dla samej inicjalizacji.

 

Teraz mając gotowy napisany przez kogoś (lub przez siebie) engine po prostu wpisujesz góra 2 linijki i wszystkei te operacje załatwiają za Ciebie klasy tego enginu.

Dodatkowo engine ma wiele innych usprawnień, umie wczytywać zazwyczaj modele 3D w róznych formatach.. umożliwia dodawanie animacji, obsługe kejfrejmingu., obsługę dzwięku, mechanizmy wykrywania kolizji... efekty cząsteczkowe, czy np z góry przewidziany format mapy... Cyztasz po prostu instrukcje enginu i wiesz jak masz i czym stworzyć mapę żeby dało się ją od razu wczytać w grze i poruszać po niej...

Bez gotowego enginu musiałbyś to sam wszystko pisać.. a wierz mi.. to jest masa roboty... około rok pracy/1 osobe :)

 

Ja kiedyś zaczałem pisać grę której nie skończyłem... zaczałem przerabiać istniejący prosty engine do gry 2D w celu zwięszkenia jego funcjonalności... Samo to zabrało mi ogrom czasu...

Myśle wiec że warto wykorzystać przynajmniej szkielet innego enginu do stworzenia własnego

[ra-v]

a jaki engine polecałbyś ?

jest może jakiś polski, dobry i funkcjonalny ?

ja osobiście bawiłem sie irrichtem, ale interesuje mnie cos polskiej produkcji...

jest coś takiego ?

[PelzaK]

osobiscie bawiłem się enginem 2D który był opisany w ksiazce helionu... programowanie gier. Innych nie miałem okazji ruszać :). Poszukaj na stronach

 

http://nehe.gamedev.net/

http://www.flipcode.com/articles/articles_summary.shtml

 

z tutorialem jak napisać własną grę :)

http://2dgame-tutorial.com/

 

lub polskie

 

http://www.komires.com/pl/page1.html

 

no i google... Jest jescze polska strona coś w stylu warsztat.pac ale coś nie chce się właczyć... Tam było sporo ludzi z polski zajmujących się programowaniem gier...

[novo]

Witam,

 

Z darmowych polecam Ogre3D. Nie jest to co prawda kompletny silnik, glownie renderer. Ale mozna podpiac pod niego np ODE i juz mamy fizyke. Dzwiek i input do prostych gier to jest kwestia paru tysiecy linijek wiec to tez raczej problemu nie robi.

Pisanie silnika to dosc duze przedsiewziecie. Ja swoj pisze juz 2lata i na razie prawie nic nie ma. Zawsze przychodzil moment kiedy sie okazywalo ze cos zle zalozylem i kod byl juz na tyle zagmatwany ze musialem wszystko od nowa pisac. Jezeli chcesz sie za to zabrac to i tak polecam sciagnac zrodelka ogre3d i przestudiowac. Kod jest bardzo elegancko napisany.

 

A co do warsztatu, to nadal istnieje., tylko juz dawno nie pod adresem warsztat.pac.pl. Oficjalna strona jest na www.gamedev.pl, ale nie polecam bo jest to eksperyment paru osob z java/cocoonem i srednio sie prezentuje. Jeden z warsztatowiczow zrobil samemu gotowy serwis i on glownie jest teraz uaktualniany: Warsztat2b.

Od wczoraj wieczorem sa jakies problemy, ale serwis na pewno nie umarl, tylko jakies problemy techniczne. Polecam przejrzec artykuly na stronie glownej. I przed zadaniem pytania na forum koniecznie uzyc f-cji szukaj, bo inaczej duza szansa ze topic poleci.

 

Pozdr!

novo.

Edytowane 7 Maja 2006 przez novo

[oldskul]

A co z enginem Q3? Jest darmowy przecież już od września ubiegłego roku o tu: http://www.fileshack.com/file.x?fid=7547

[novo]

Nie polecam. Dlaczego?

 

1. Silnik jest stary(2000r). Nie bylo wtedy jeszcze shaderow(90% obecnych efektow sie na nich opiera). Ogre jest rozwijany caly czas i mysle ze mozna grafike przez niego generowana spokojnie porownac do far cry(czego o q3 raczej powiedziec nie mozna).

 

2. Ogre jest projektem open source. Co za tym idzie kod jest duzo czytelniejszy i bardziej elegancko napisany. Q3 powstawal w jednej firmie i w takim przypadku mozna sobie pozwolic na mniej czytelny kod. Jezeli sie czegos nie rozumie to idzie sie do kolegi obok i tlumaczy co napisal :).

 

3. Ogre jest napisany w C++ z wrecz podrecznikowym designem OO. Q3 jest strukturalny i napisany w C. Dla niektorych moze to byc zaleta, ale jednak i tak niewiele to q3 pomaga.

 

4. Ogre jest caly czas rozwijany, a q3 nie.

 

5. Brak dokumentacji do q3. Wypuszczony zostal tylko kod zrodlowy na GPLu. Do Ogra jest sporo tutoriali i wielkie community. Jakiekolwiek problemy i watpliwosci sa najczesciej rozwiazywane w ciagu 24h od wyslania posta.

 

6. Ogre jest na LGPLu a co za tym idzie mozna go wykorzystywac w komercyjnych projektach bez wymogu umieszczania zrodel(GPL na to nie pozwala).

 

Ogolnie silnik q3 mozna 'przerobic' jezeli jestesmy ciekawi jak to panowie z ID zakodzili. Ogre pod wzgledem technologicznym stoi na poziomie wspolczesnych komercyjnych silnikow. Dodatkowa zaleta q3 jest to ze dostajemy kompletny silnik(nie tylko renderer jak ogre), ale brak dokumentacji w zasadzie uniemozliwia poznanie go w rozsadnym czasie. Analizowanie calego kodu moze byc troche pracochlonne biorac pod uwage jego ilosc.

 

// EDIT:

 

Jeszcze co do pytania z poczatku watku.

 

Dobrze napisany silnik zajmuje sie cala techniczna otoczka pisania gry. Programiscie zostaje tylko skodzenie mechaniki gry, a nie wyswietlania grafiki, odczytywania klawiatury/myszki czy odgrywania dzwiekow. Majac silnik jedyne czym sie zajmujesz to gra sama w sobie, czyli pisanie obiektow reprezentujacych postacie, przedmioty, NPC i interakcje miedzy nimi. W silniku masz zaimplementowane wszystkie efekty(cienie, realistyczna woda, oswietlenie, ladowanie mapy i zarzadzanie geometria, kolizje, podstawa do napisania AI, obsluga dzwieku itp.). Nie musisz znac nawet OpenGL/DirectX zeby sie zabrac za pisanie gry(jednak wiedza o tym jak silnik dziala i jak jest zbudowany bardzo pomaga, szczegolnie przy optymalizacji). Silnik tworzy API w ktorym piszesz gre. Bez silnika musisz wszystko robic recznie(w zasadzie kazda gra posiada silnik, mniej lub bardziej profesjonalny).

 

Pozdr!

novo.

Edytowane 7 Maja 2006 przez novo

[ra-v]

mam problem z tym Ogre3D, mianowicie przepisałem tutka, wszystko ustawiłem niby jak trzeba, ale gdy kompiluję, pojawia mi sie bład, coś z hash_set...

i nie wiem co robic, a być może że kod źródłowy zaczne studiowac.

pozdrawiam

 

PS. a ten OGRE zawiera wszystkie PIXEL SHADERY i opiera sie na najnowszym DirectX3D9 ??

[novo]

Tak, wspiera. Jest nawet niezalezny od graficznego API, wiec mozesz wyswietlac za pomoca DX9, albo OpenGL. Napisz jaki kompilator/IDE i jaki dokladnie blad, bo tak ciezko pomoc :)

 

Pozdr!

novo.

Edytowane 7 Maja 2006 przez novo

[PelzaK]

kolejny programista który nie czyta błędów kompilatora :).. Przyczytaj.. naciśniej F1.. zrozum co chce od Ciebie kompilator.. ewentualnie podaj nam tutaj co Ci napisał jeśli nie rozumiesz.... Błędy kompilaotra i ogólnie programó to nie JAKEIŚ TAM BŁĘDY.. tlyko to jest informacja dla inteligetnego programisty/informatyka co jest nie tak... Dlatego też dobry informatyk czyta błędy i rozumie komputery a zwykły user mu za to płaci....

[ra-v]

a polecacie książke Helion "DirectX rendering w czasie rzeczywistym" ?

bo chyba kuię, ale 80 zł to troche duzo i chce sie dowiedziec czy warto...

[PelzaK]

napewno dowiesz sie jak działa i jaką ma strukturę directX... ale jeśli chcesz napisać grę a nie jesteś jeszcze dobry w te klocki to polecam uzycie gotowego enginu... Robienie go od nowa to katorga... nigdy nei zrobisz tego od razu prawidłowo, najoptymalniej etc.. nie uwzglednisz wszystkiego... a używając już gotowego masz pewność ze zostało to przetestowane rpzez wielu ludzi... i nei ma raczej rażących błędów.

[novo]

Przy prostych grach, mozesz spokojnie wszystko rysowac recznie w dx'ie. Przy bardziej zaawansowanych musisz juz miec jakis silnik, albo swoj, albo gotowy. Druga sprawa: jak zaczniesz pisac engine, to szanse ze napiszesz jakakolwiek gre spadaja prawie do 0 :). Nie dla tego ze nie masz szans na napisanie go, wrecz przeciwnie. Po prostu zawsze bedzie cos co bedziesz chcial do niego dodac :). To jest glowny problem programistow-amatorow. Przy profesjonalnych projektach, przed napisaniem silnika robi sie zalozenia co bedzie obslugiwal i potem sie pisze az sie skonczy. Jak juz programisci zaczna pisac kod, to zadko sie zdaza zeby cos bylo dodawane. Silnik mozna pisac w nieskonczonosc. Najlepszym tego przykladem jest Duke Nukem: Forever. Chlopaki chca zrobic gre idealna, silnik zmieniali juz z 5 razy a gry nie widac.

 

Co do ksiazki: Slyszalem ze dobra. Jezeli chcesz oszczedzic kase, to polecam pouczyc sie z tutkow z netu. Po polsku masz dimmension3.spine.pl. Z angielskojezycznych polecam www.gamedev.net(Ogolnie game dev), (OpenGL) i www.ultimategameprogramming.com(DX i OGL).

 

Na poczatek polecalbym OpenGL. Dla mnie jest latwiejszy od dx'a a oferuja ta sama funkcjonalnosc(pod wzglem grafiki 3D, bo dx ma jeszcze dinput, dsound, ale i tak najczesciej nawet piszac pod OGL'a ich sie uzywa wiec tak czy siak bedziesz musial sie tego nauczyc). Argument, ze lepiej uzyc dx'a bo ma od razu nie tylko 3d, ale wlasnie pozostale komponenty jest raczej nie trafiony. Nauka Direct3D nie ulatwi ci wcale nauki dsound(mimo ze tez COM, to zupelnie co innego bo dotyczy dzwieku) czy dinput(bardzo proste API, napiszesz sobie raz wrapper i na najblizsze 5lat ci starczy. D3D i OGL oferuja ta sama funkcjonalnosc(jedyne ograniczenie to karta graficzna), wiec klotnie nad wyzszoscia jednego nad drugim sa bez sensu. Ja uwazam ze OGL jest na start latwiejszy i raczej wiekszosc wypowiedzi ktore czytalem byla podobna, chociaz zdazali sie ludzie ktorym API D3D bardziej pasowalo. Jak nauczysz sie jednego API to w zasadzie nauka drugiego pojdzie ci bez problemow bo to praktycznie to samo, tylko inaczej przedstawione :). Kolejnym problemem jest zblizajacy sie DX10. Microsoft zapowiedzial totalna przebudowe tego API i odejscie od COM'ow. Nowa wersja bedzie niekompatybilna wstecz. DX9 i starsze bedzie po prostu emulowane przez DX10, co umozliwi odpalanie starszych gier, ale samo API ma sie zmienic. Dokladnych informacji nie podam, bo DX'em nie bawie sie juz od ok roku i skupilem sie na razie na OGL(przenosnosc), chociaz planuje renderer tak, zeby zaimplementowac obsluge i D3D i OGLa.

 

Pozdr!

novo.

[ra-v]

ok, więc może wykorzystam jeden z instniejących enginów,

 

i teraz mam pytanie :

Czy uczyć sie DirectX3D9 ?

Bo przecież korzystania z np. OGRE (bo do niego jestem najbardziej jak narazie przekonany) naucze sie z tutuków

A poza tym niedługo ma wyjść DirectX10 więc bede musiał uczyć sie ponownie...

 

Ja chciałbym zrobić grę, a kolega tu pisze że engin można caly czas poprawiać, a jak do końca nie wiem co potrzebuje itd...

 

Tymczasem pobawię sie tym OGRE3D i sprawdze ten bład co mi wywala...

 

EDIT :

 

Sprawdziłem ten błąd oto on :

 

c:\ogresdk\include\ogrestdheaders.h(31) : fatal error C1083: Cannot open include file: 'hash_set': No such file or directory

Error executing cl.exe.

 

Niestety F1 mi nie działa bo MSDN nie mam zainstalowanego (pracuje w Microsoft Visual C++)

ale rozumiem ten bład, kompilator nie może w pliku ogrestdheaders.h na linijce 31 otworzyć includa hash_set...

 

I co mam w takiej sytuacji zrobić ?

 

Pozdro

Edytowane 8 Maja 2006 przez ra-v

[novo]

Do obslugi ogre'a nie musisz znac dx'a bo ogre calkowicie go zaslania. Na pewno jak dx'a poznasz, bedzie Ci duzo latwiej. Nie chodzi tu o poznanie samego API, ale raczej sposobow generowania grafiki 3D. Np. nVidia podaje ze najlepiej jest do karty wysylac po 3-4k vertexow na raz, bo wtedy uzyskuje sie maxymalna wydajnosc. Dobrze jest ogolnie wiedziec co ile czasu sie wykonuje. Osobiscie z ogre'a nie korzystalem, tylko czytam sobie zrodla, wiec za duzo ci w tym temacie nie pomoge. Jakiekolwiek pytania dotyczace silnika proponuje kierowac na forum ogre, tam na pewno uzyskasz odpowiedz.

 

Pozdr!

novo.

[PelzaK]

prawdę rzeczesz...

 

aczkolwiek nie mozna jednoznacznie stwierdzić czy lepszy openGL czy DX... tutaj zdania są podzielone, jak i wielbiciele... POdobnie jak windows kontra linux. A to że openGL jest przenoszalny jakoś bardziej gromadzi wokół siebie użytkowników linuxa.. A fakt ze DX pochodzi spod ręki billa powoduje że windowsiarze zazwyczaj bardziej go preferują...

Wszystko zależy od upodobań. Ja osobiście wolę DX. I pozwolę się niezgodzić do końca z teorią iż poznanie D3D czy DDRAW nie wpływa na dalsze poznanie działąnia DSOUND czy DINPUT. Wszstko to opiera się o podobne struktury których w directXie jest cała masa... Nie mówię ze są dokąłdne analogie pomiędzy tymi modułami, ale mając pojęcie o d3d w pewien sposób poznanaie dsound jest już łatwiejsze...

[novo]

Moim zdaniem sa to tak niskopoziomowe API, ze kazde funkcjonuje na innej zasadzie. Chodzi mi o to, ze to jakie funkcje sie wywoluje nie ma wiekszego znaczenia. Wazne jest zeby wiedziec do dana f-cja robi. I tak przy d3d wymagana jest znajomosc dzialania karty graficznej(nie jakos super niskopoziomowo, ale potok renderowania powinno sie znac), tak samo przy dsound trzeba wiedziec jak drivery/karta ten dzwiek odgrywa. DInput jest na tyle prosty, ze nawet nie warto o nim wspominac. Mi napisanie wrappera na dinput przy kompletnej nieznajomosci DX zajelo 2h(wszelkie info z dokumentacji), a bylo to juz ze 3 lata temu(duuuuzo slabiej wtedy kodzilem :)). Wiadomo ze oba API sa oparte o COM, ale tak naprawde jest to tylko kwestia wywolywania f-cji ktorych nazwy, parametry i zwracane wartosci wyczytamy z dokumentacji.

 

Co do wyzszosci DX nad OGL to jak pisalem raczej nie ma roznicy, bo to tak naprawde tylko nakladka na driver/karte graf. Potok renderowania jest ten sam, tylko kod ma troche inna strukture. Poznanie jednego API najczesciej polega na nauczeniu sie generowania grafiki 3D, poznawanie drugiego API to juz tylko nauka odpowiednich f-cji z dokumentacji. Z OGL'em sa problemy przy pisaniu efektow na jak najstarsze karty graficzne ze wzgledu na brak PS1.x niezaleznego od producenta karty. Wszystko trzeba robic na rozszerzeniach ATI lub NV. Przy DXie nie ma problemow. Ja tylko osobiscie uwazam ze na poczatek OGL jest latwiejszy i z tego co czytalem wiekszosc tak uwaza. Ale to jest kwestia gustu, a o gustach jak wiadomo sie nie dyskutuje :). Najlepiej sprobowac popisac w jednym i drugim API i sprawdzic jak jest nam wygodniej.

 

Pozdr!

novo.

Edytowane 8 Maja 2006 przez novo

[ra-v]

novo - napisałeś już kiedyś własnego engina ?

Ile Ci to zajęło, i dobrze wyszedł ?

[novo]

Pisanie silnika to dosc duze przedsiewziecie. Ja swoj pisze juz 2lata i na razie prawie nic nie ma. Zawsze przychodzil moment kiedy sie okazywalo ze cos zle zalozylem i kod byl juz na tyle zagmatwany ze musialem wszystko od nowa pisac.

:D

 

Na razie mam sam kernel(bez VFS). Teraz zabieram sie za pisanie renderera. W chwili obecnej nie mam za duzo czasu bo maturke poprawiam(nie starczylo punkciorow na UW na infe a Fizyka na UW suxx :)). Po maturach prace zostana wznowione :)

 

Pozdr!

novo.

[ra-v]

I teraz mam takowy problem :

Ściągnąłem sobie SDK i OGRE SDK do CODE::BLOCKS i kiedy daje kod z tutka, to niby sie kompiluje, i na końcu pokazuje sie :

 

collect2: ld returned 1 exit status

Process terminated with status 1 (0 minutes, 13 seconds)

 

I ani program nie ruszy, ani plik .exe sie nie stworzy :/

Proszę o pomoc...

[PelzaK]

jednak silniki oparte o OGL i DX tworzą inne efekty wizualne :) Wprawiony gracz od razu 1 rzutem oka rozpozna czy gra chodzi na OGL czy DX :) Zatem można by się spierać ze jednak różnice są widoczne...

 

co do pisania własnego enginu.. imho szkoda czasu na to... Życie mnie już nauczyło że czasami nie opłąca sie robić czegoś samemu.. Po to kupe ludzi siedziało spory czas i udostepniło swoją pracę innym żeby z tego korzystać. Mnie pzreróbka enginu tak wciagnęła że zamiast gry pisałem ciagle engin... i w końcu nie stworzyłem nic... :)

 

Zwróć uwagę iż np taki unreal engine.. Oczywiście komercyjny jednak w wielu grach został zastosowany gdyż programiści stwierdzili że nie ma sensu wymyślać koła od nowa... skoro już jest to się go używa... Podobnie ostatni unreal engine 3... Panowie programisci stworzyli engine który inni programiści będa uzywać i z góry widzą jaki będzie efekt końcowy.. Skupiają sie jedynie na logice gry...

[novo]

Cos krecisz. OGL I DX i tak sa implementowane w driverze i to on decyduje o wygladzie sceny. Wyglad jest totalnie niezalezny od api. Zawsze da sie skonfigurowac tak zeby na obu api widok byl ten sam.

[PelzaK]

szczerze wątpię... Odpal chociażby gre unreal tournament... Wybierz renderera na DX a potem na OGL... DX ma zimne kolory.. ostre krawędzie.. podczas gdy OGL daje bardziej ciepłe otoczenie.. bardziej rozmyte... Nie wiem.. może to kwestia implementacji, możliwości... ale ja potrafię powiedzieć czy gra idzie na DX czy na OGL... Przynajmniej starsze gry.. bo w nowe nie miałem okazji grać od jakiegoś czasu...

[novo]

Przy starszych grach(bez T&L) ta roznica moze byc widoczna, bo vertexy szly na CPU a nie GPU i to api bylo odpowiedzialne za ich wyswietlanie. Ale przy dzisiejszych GPU i tak wszystko sie na nich liczy(albo fixed czyli nie masz za bardzo na to wplywu, albo shadery), wiec API juz takiej roznicy nie robi.

 

Pozdr!

novo.

[PelzaK]

niech Ci będzie... nie grałem w nowe gry :D wiec przyjmę Twą teorię za zgodną z rzeczywistością... :)