Autor Wątek: Wyścigi 2d- potrzebny mi silnik?  (Przeczytany 4364 razy)

Offline menajev

  • Użytkownik
    • Karate Inowrocław

# Grudzień 19, 2007, 20:57:28
Tworze sobie 2-wymiarowy wyścigi i tak się zastanawiam, czy silnik graficzny mógłby mi w czymkolwiek pomóc [do tej pory żadnego nie używałem]. Jestem na etapie, gdzie samochód to biały prostokąt [SDL +OGL], ale problemy sprawia mi wyświetlanie tła [grafik ze mnie żaden, a kiedy chce żeby to jakoś wyglądało, to zaczyna lagować], więc czy dzięki silnikowi będzie łatwiej, czy kombinować będę musiał tak samo, jak używając glVertex3f()?   

Offline Mr. Spam

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

FREQUENT

  • Gość
# Grudzień 19, 2007, 21:15:41
Żaden silnik z Ciebie grafika nie zrobi. A po drugie, przecież glVertex3f() nie jest takim złym rozwiązaniem. ;)
Moim zdaniem silnik Ci niepotrzebny, aby by namieszał. Proste wyścigi 2D to [SDL+OGL] najlepsza sprawa.

Offline Grelo

  • Użytkownik

# Grudzień 19, 2007, 21:55:10
IMO silnik jest Ci zupełnie zbędny. Tylko skomplikuje sprawę, a napisanie gry bez silnika nauczy Cię korzystać z SDL+OGL , a to przyda sie. przy pisaniu własnego silnika w przyszłości. Co do lagowania to jeśli chcesz żeby było szybko radze zacząć uczyć się DX, mi jeszcze nigdy nie lagowało.

Życzę szczęścia przy pisaniu wyścigówki ;D

Offline Krzysiek K.

  • Redaktor
    • DevKK.net

# Grudzień 20, 2007, 02:23:50
Cytuj
A po drugie, przecież glVertex3f() nie jest takim złym rozwiązaniem. ;)
glVertex3f jest najwolniejszym sposobem wysyłania wierzchołków do karty, jaki udało się dotychczas wymyślić, ale na początek może to być wystarczające rozwiązanie. :)

Offline S.Producer

  • Użytkownik

# Grudzień 20, 2007, 05:01:32
Jeżeli to 2d, to używaj glVertex2f, nie będziesz musiał wklepywać dodatkowego zera na końcu :).

Offline Moriturius

  • Użytkownik

# Grudzień 20, 2007, 12:36:54
Cytuj
A po drugie, przecież glVertex3f() nie jest takim złym rozwiązaniem. ;)
glVertex3f jest najwolniejszym sposobem wysyłania wierzchołków do karty, jaki udało się dotychczas wymyślić, ale na początek może to być wystarczające rozwiązanie. :)

Myślę, że jeśli ktoś by się postarał  to i wymyśliłby wolniejszy, ale nikomu sie nie chce ;)

Jeżeli to 2d, to używaj glVertex2f, nie będziesz musiał wklepywać dodatkowego zera na końcu :).

Nie lepiej po prostu użyć buforów wierzchołków? Bądź co bądź KK ma rację z tą wydajnością glVertex[X][Y]() ;)

Offline Krzysiek K.

  • Redaktor
    • DevKK.net

# Grudzień 20, 2007, 13:00:01
Cytuj
Nie lepiej po prostu użyć buforów wierzchołków?
Najprościej i najbezpieczniej w grze 2D użyć vertex array, bo i tak przecież co klatkę będzie się wszystko zmieniało, z dynamicznymi VBO trzeba trochę uważać. :)

Offline Moriturius

  • Użytkownik

# Grudzień 20, 2007, 18:48:54
Cytuj
Nie lepiej po prostu użyć buforów wierzchołków?
Najprościej i najbezpieczniej w grze 2D użyć vertex array, bo i tak przecież co klatkę będzie się wszystko zmieniało, z dynamicznymi VBO trzeba trochę uważać. :)

To dobrze, bo w moim AGE uzywam wlasnie vertex array do rysowania, a skoro Ty tak mowisz to znaczy ze nie ma lepszego sposobu ;)

Offline menajev

  • Użytkownik
    • Karate Inowrocław

# Grudzień 20, 2007, 20:41:30
OK, wielkie dzięki, silnika nie biorę.
Co do wydajności i DX- lagowało raczej nie przez OGL, tylko przez naprawdę 'pojemną' pętle, która sprawdzała rodzaj podłoża, a o DX nie ma nawet mowy, bo pod linuxem tworzę.

Offline S.Producer

  • Użytkownik

# Grudzień 20, 2007, 21:13:10
Ja na razie piszę glVertex2d'ami, ale jak już będzie coś większego, zmienię odpowiednio kod rysowania :P.

Offline Krzysiek K.

  • Redaktor
    • DevKK.net

# Grudzień 20, 2007, 21:36:36
To dobrze, bo w moim AGE uzywam wlasnie vertex array do rysowania, a skoro Ty tak mowisz to znaczy ze nie ma lepszego sposobu ;)
To zależy jeszcze co robisz z tym vertex array, bo wiele osób rysuje pojedyncze quady i bawi się po drodze macierzami, co wydajne być nie może. Najlepszym sposobem rysowania 2D jest upchnięcie całej grafy na kilka dużych tekstur według ich rodzajów (np. wszystkie animacje postaci na jedną teksturę 4096x4096, elementy tła na drugą taką), a później rysowanie quadów masowo pojedynczymi wywołaniami (texcoordy i współrzędne wierzchołków wyznaczamy samemu na CPU). Do tego mamy jeden bufor indeksów (może to być VBO, bo to się nie zmienia), który indeksuje nam kolejne czwórki wierzchołków jako quady. Można trochę pokombinować z podziałem na "pakiety" rysowania według tego, co rysujemy (np. tło nie wymaga alpha blendingu), ale z reguły nie opłaca się dzielić tego na małe fragmenty. Poniżej 1000-2000 trójkątów (czyli 1000 sprite'ów w jednej paczce) koszt samego przestawiania stanów karty (np. zmiana macierzy po Rotate) jest porównywalny z kosztem samego rysowania, co ogranicza wydajność silnika. :)


Oczywiście z rzeczy trywialnych, to wypadało by zablokować/nie włączać Z-bufora, który tu się i tak zbytnio nie przydaje (czyli Disable(DEPTH_TEST), DepthMask(false) ) oraz można włączyć alpha test żeby odrzucać piksele, które i tak będą przezroczyste. :)

Offline Netrick

  • Użytkownik

# Grudzień 20, 2007, 21:41:05
Można i hardorowo do prostych gier glcopypixels ;p I tak ma to o niebo większą wydajność od takiego sdla, który na sprzęcie na którym far cry na średnich detalach chodzi płynnie, to sdl na tym sprzęcie przy jednym quadzie 800x600 z alpha-blendingiem ma... 35fps ;p

Offline S.Producer

  • Użytkownik

# Grudzień 20, 2007, 22:17:47
Cytat: Krzysiek K.
To zależy jeszcze co robisz z tym vertex array, bo wiele osób rysuje pojedyncze quady i bawi się po drodze macierzami, co wydajne być nie może.

Newton wymaga ode mnie bawienia się macierzami, więc chyba sobie odpuszczę v.array. Generalnie Hackflip to w większej części fizyka, więc tym bardziej pozostanę przy glVertex2f. Chyba że nie zrozumiałem Twej wypowiedzi do końca.

Cytat: Krzysiek K.
Najlepszym sposobem rysowania 2D jest upchnięcie całej grafy na kilka dużych tekstur według ich rodzajów (np. wszystkie animacje postaci na jedną teksturę 4096x4096, elementy tła na drugą taką), a później rysowanie quadów masowo pojedynczymi wywołaniami (texcoordy i współrzędne wierzchołków wyznaczamy samemu na CPU).

Nie zgadzam się, bo np. moja karta ma maks. 2048x2048, nie mówiąc o starszych, na których tak duże tekstury po prostu nie załadują się, chyba że podzielimy je w funkcji wczytującej na mniejsze i dopiero wtedy wyślemy do karty. Ja używam tekstur maksymalnie 512x512.

Offline Krzysiek K.

  • Redaktor
    • DevKK.net

# Grudzień 20, 2007, 23:00:58
Cytuj
Newton wymaga ode mnie bawienia się macierzami, więc chyba sobie odpuszczę v.array. Generalnie Hackflip to w większej części fizyka, więc tym bardziej pozostanę przy glVertex2f. Chyba że nie zrozumiałem Twej wypowiedzi do końca.
Macierzami możesz się bawić, ale chodzi o to, żebyś robił to na CPU, co w przypadku 2D jest dosyć proste (olewasz wyznaczanie Z, a przy braku perspektywy możesz założyć, że ostatni wiersz/kolumna to [0 0 0 1]). Użycie glRotate i tym podobnych pociąga za sobą to, że karta musi przerwać renderowanie żeby zmienić macierz, przez co może się poczuć jak bolid Formuły 1 stający co chwilę w potężnym korku ulicznym. Ideą jest to, żeby przeliczyć samemu wszystkie pozycje quadów, wrzucić to do jednej bądź kilku tablic i puścić jednym rzutem na GPU. :)

Cytuj
Nie zgadzam się, bo np. moja karta ma maks. 2048x2048, nie mówiąc o starszych, na których tak duże tekstury po prostu nie załadują się, chyba że podzielimy je w funkcji wczytującej na mniejsze i dopiero wtedy wyślemy do karty. Ja używam tekstur maksymalnie 512x512.
Jeżeli piszesz na starsze sprzęty, to możesz spokojnie używać 1024x024, bo to jest wspierane przez wszystkie karty, poza 3DFx Voodoo, które ma max 256x256 (ale kto dzisiaj ma takie coś?). :)

Offline S.Producer

  • Użytkownik

# Grudzień 21, 2007, 00:46:08
Cytuj
Macierzami możesz się bawić, ale chodzi o to, żebyś robił to na CPU, co w przypadku 2D jest dosyć proste (olewasz wyznaczanie Z, a przy braku perspektywy możesz założyć, że ostatni wiersz/kolumna to [0 0 0 1]). Użycie glRotate i tym podobnych pociąga za sobą to, że karta musi przerwać renderowanie żeby zmienić macierz, przez co może się poczuć jak bolid Formuły 1 stający co chwilę w potężnym korku ulicznym. Ideą jest to, żeby przeliczyć samemu wszystkie pozycje quadów, wrzucić to do jednej bądź kilku tablic i puścić jednym rzutem na GPU.

W sumie faktycznie, lepiej użyję mojego przyspieszonego sinusa i cosinusa (mniej dokładnego, ale o wiele szybszego, bo odczytuje stałe z tablicy). Kod trochę się nabrudzi, ale w sumie będzie bardziej pro.

...ale zajmę się tym jak lepiej rozkminię pisanie shaderów w asemblerze GPU (nie chcę używać GLSL na razie).