Autor Wątek: Budowa Silnika Gry  (Przeczytany 18544 razy)

Offline Krzysiek K.

  • Redaktor
    • DevKK.net

  • +2
# Listopad 30, 2012, 23:29:22
No, muszę zgodzić się z Kosem, próbowałem imgui np. tu: http://warsztat.gd/screen/9482/gui_na_ukonczeniu ale też lekko z tym nie było, a chcąc robić layoutery i tak trzeba znać rozmiary kontrolek w kontenerze, czyli trzeba je i tak przechowywać kontrolki po stronie gui.
Nie twierdzę, że Immediate Mode zrobi z każdego GUI rzecz idealną.

A do zrobienia layoutu nie potrzebujesz rozmiaru kontrolek. printf daje sobie radę bez tego, a jeżeli chcę nawet wypełnić całą linię okna kontrolkami, to wcześniej deklaruję podzielniki. W przypadku mojego własnego GUI stan zaczyna się dopiero na poziomie całych okien, bo tam już gdzieś trzeba pamiętać układ, pozycje i rozmiary.


A końcowy efekt wygląda tak: ;)

Offline Mr. Spam

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

Offline Kurak

  • Użytkownik

# Listopad 30, 2012, 23:47:42
I potem powstaje potworek z customowym GUI w rodzaju Blendera który swoim działaniem nie przypomina żadnego innego wytworu człowieka :) Ofc jeśli kroi się edytor pod siebie to wygodne bo zna się działanie tego doskonale, ale typowy użytkownik będzie miał dużo większy problem żeby tego zacząć używać bez czytania masy tutoriali (które też ktoś musi napisać). W ogóle wybieranie liba do GUI przez pryzmat tego w czym wygodnie się pisze jest co najmniej dyskusyjne - różnice wcale takie wielkie nie są, a toole nie są od tego żeby je się przyjemnie pisało tylko żeby użytkownik końcowy mógł ich efektywnie używać.

Offline Paweł

  • Użytkownik

  • +1
# Grudzień 01, 2012, 00:32:43
Noo, kozacko to wygląda. Ciekawi mnie jak zrealizowałeś to drzewko w rogu po lewej? W klasycznym imgui trzeba by dla każdego "liścia" zdefiniować położenie oraz etykietę. Do tego chcąc mieć możliwość dodawania i przesuwania liści dynamicznie (przez użytkownika), to trzeba dla nich i tak stworzyć Vector<Pair<Rect, String>> plus do tego dane logiki. Jak z góry znasz proporcje jakie mają mieć okienka to wszystko jest ok. Chodzi mi o to że i tak dane o położeniu przycisków oraz okien trzeba gdzieś trzymać, w podejściu imgui to użytkownik musi się o to troszczyć. Natomiast podoba mi się sprawdzanie stanu przycisków w imgui. Jednak mamy już c++11, tak więc to co w imgui wygląda tak:
if(doButton("name"){
  action();
}
moze w 'klasycznym' podejściu wyglądać tak:
window.addButton( Button("text").setOnClick([&](){action();}) } );

Offline Krzysiek K.

  • Redaktor
    • DevKK.net

# Grudzień 01, 2012, 01:38:19
Cytuj
W ogóle wybieranie liba do GUI przez pryzmat tego w czym wygodnie się pisze jest co najmniej dyskusyjne - różnice wcale takie wielkie nie są, a toole nie są od tego żeby je się przyjemnie pisało tylko żeby użytkownik końcowy mógł ich efektywnie używać.
To chyba za mało tooli pisałeś. ;)

Generalnie każda rzecz, którą robi się w gamedevie będzie dwa razy lepsza jeżeli będzie w postaci wygodnego toola. A tooli ludzie nie piszą wyłacznie dlatego, że programowanie GUI jest czasochłonne i irytujące. Używanie wygodnego GUI ma wręcz kluczowe jak dla mnie znaczenie. Na tyle kluczowe, żeby znaleźć motywację do przemęczenia się i napisania swojego raz a dobrze.

Cytuj
Ciekawi mnie jak zrealizowałeś to drzewko w rogu po lewej?
W ten sposób, że iterujesz po swojej tablicy gdzie trzymasz bloczki (zawierające predefiniowaną strukturkę), a system GUI już je renderuje i zmienia zawartość wedle uznania.

Cytuj
Jednak mamy już c++11, tak więc to co w imgui wygląda tak:
if(doButton("name"){
  action();
}
moze w 'klasycznym' podejściu wyglądać tak:
window.addButton( Button("text").setOnClick([&](){action();}) } );
Skoro takiś kozak to przepisz to:
static bool tab[10][10];
for(int y=0;y<10;y++)
{
    for(int x=0;x<10;x++)
        if(Button(tab[x][y] ? "X" : "-"))
            tab[x][y] = !tab[x][y];
    NewLine();
}

Poza tym lambda utrudnia o tyle, że nie masz w ogólności pojęcia kiedy się Twoja lambda odpali.

Offline Paweł

  • Użytkownik

# Grudzień 01, 2012, 03:28:54
Do tego mogę jeszcze dorzucić przeciąganie przycisku prawym przyciskiem myszy:static bool tab[10][10];
for(int y=0;y<10;y++)
{
  for(int x=0;x<10;x++)
    window.add(Button().setOnEvent([&, =x,=y]() {
      switch( window.getProcessedEventType() ){
        case LMB_RELEASED:
          window.getProcessedButton()->text = tab[x][y] ? "x" : "-";
          tab[x][y] = !tab[x][y];
        break;
        case RMB_DOWN:
          window.getProcessedButton()->position = getMousePosition();
        break;
    });
  window.layouter.newLine();
}
Ale nigdy czegoś takiego nie zaimplementowałem w przeciwieństwie do imgui :) Choć wygląda całkiem nieźle.

Cytuj
W ten sposób, że iterujesz po swojej tablicy gdzie trzymasz bloczki (zawierające predefiniowaną strukturkę), a system GUI już je renderuje i zmienia zawartość wedle uznania.
No właśnie, tylko ze jak masz:struct MyPredefStruct{};
vector<MyPredefStruct> guiBlocks;
to równie dobrze możesz mieć:struct MyButton : Button{};
vector<MyButton> guiButtons;
A to nie jest już imgui, bo wprowadza stan, dochodzi konieczność inicjalizacji itd.

Ostatnio myślałem nad takim rozwiązaniem ( o nie, znowu bedę kodził gui zamiast gry ;) ):
Gui gui("layout.gui");

while(true)
{//main loop
  if(gui.check("button1_left_released") ){
    gui.getCheckedButton()->text = tab[x][y] ? "x" : "-";
    tab[x][y] = !tab[x][y];
  }
  if(gui.check("button1_right_down") ){
    gui.getCheckedButton()->position = getMousePos();
  }
}

Offline Krzysiek K.

  • Redaktor
    • DevKK.net

# Grudzień 01, 2012, 13:21:16
Cytuj
No właśnie, tylko ze jak masz:
struct MyPredefStruct{};
vector<MyPredefStruct> guiBlocks;
Możesz tak mieć, ale nie musisz. Predefiniowana struktura może być pochowana w dowolnych miejscach, bo Ty iterujesz po niej (i to jednokrotnie). W praktyce wychodzi IM, bo podajesz parametry samemu co klatkę, tyle że przez strukturę bo tych parametrów jest dużo. Ale nikt nie zmusza Cię do trzymania tych struktur gdziekolwiek (możesz w każdej klatce budować je od nowa osobno dla każdego obiektu).

Cytuj
A to nie jest już imgui, bo wprowadza stan, dochodzi konieczność inicjalizacji itd.
A kto mówił że jest to w 100% czyste IM GUI? To jest po prostu zrobione tak, by pisało się pod to jak najłatwiej. :)

Poza tym przegiąłeś trochę przykład. To, że do IM GUI da się dołożyć warstwę żeby stracić IM to chyba oczywiste. Główną zaletą jest to, że nie musisz tego robić.

Cytuj
Ostatnio myślałem nad takim rozwiązaniem ( o nie, znowu bedę kodził gui zamiast gry ;) ):
Wygląda bardzo słabo, powiem szczerze. Za dużo do zaklepania, za dużo do zapamiętania. :)

Offline XPietrucha

  • Użytkownik

# Grudzień 01, 2012, 13:37:28
Ja mam plan, aby Edytor był jak najmniej trudny, przynajmniej World Editor (co jest podstawą, aby świat gry ładnie wyglądał [a w RPG to też jakiś +]).
Nie próbowałem pisać w Qt ? (ale widziałem jak to wygląda [wygląd programów]).
Podstawą edytora to przynajmniej jedno okno gdzie będę mógł edytować wygląd świata w 3D i lista parametrów dla odpowiedniej rzeczy (typu światło, jakieś zdarzenie, punkt kontrolny, obiekt itp.)

Btw. Dzisiaj (kilkanaście minut temu skończyłem) napisałem pierwsze zarysy silnika i mają się dobrze (Zbieranie wejścia od klawiatury i myszy (czyli prawie cały zarys input), Renderowanie modeli (narazie .x i .obj, nad własnym to będę musiał pomyśleć (poczytać)), tekstur. Wczytywanie shadera do gry i obsługa poprzez klasę. Podstawowe światła (Point, Spot i Directional). Zalążek kamery (narazie 1-osobowa [czyli najzwyklejsza], dla testów). No i oczywiście obsługa urządzenia Direct3D i zarządzanie oknem.

A mam do was pytanie. Jakbym chciał, aby ktoś sprawdził wydajność jakiegoś demka (lub początkowej wersji gry), to jak to mam zrobić ? poprosić tutaj na forum ? czy założyć projekt na warsztacie i tam wrzucać linki do DL?

Offline Xion

  • Redaktor
    • xion.log

# Grudzień 01, 2012, 15:44:08
Cytuj
Generalnie każda rzecz, którą robi się w gamedevie będzie dwa razy lepsza jeżeli będzie w postaci wygodnego toola. (...)
Możesz rozwinąć, dlaczego w gamedevie taką wagę przykłada się do "otoolowania" wszystkiego? Przyznam, że to dla mnie fascynujące, bo to kolejne pole gdzie gamedev robi inaczej niż "reszta świata" :)

Normalnie programista w takiej sytuacji (tj. danych niebędących kodem, ale wpływających na wykonanie programu) wyciągnąłby po prostu jakiś format tekstowy - być może własny, ale częściej coś istniejącego a lekkiego, jak CSV czy JSON - i ustalił co tam się ma znajdować i jaką ma mieć strukturę. Najczęściej oznacza to po prostu stworzenie przykładowego pliku w ulubionym edytorze.

Potem parser to albo pikuś (jeśli rzecz jest oparta o już istniejący format), albo kilka godzin zabawy z pisaniem gramatyki i podaniem jej lokalnemu odpowiednikowi Flexa/Yacca/Bisona/etc. W rezultacie "toole" masz za darmo, bo wszystko co przetwarza tekst - począwszy od edytora, a skończywszy na grepie - będzie współpracować z twoim wynalazkiem.

Czemu więc spędzać dni/tygodnie/miesiące na tworzeniu dedykowanych programów?
* Rozumiem chęć nauki tworzenia aplikacji z GUI - umiejętności nigdy nie szkodzą. Zdziwiłbym się jednak gdybyś Ty, Krzyśku, mógł jeszcze coś z pisania takich aplikacji wyciągnąć :)
* Rozumiem że czasami z tooli korzystają nie-programiści, chociaż to też da się rozwiązać (graficy/muzycy mają swoje narzędzia, których wyjściowe formaty są znane). Ale w przypadku silnika pisanego na własnego potrzeby?...
* Rozumiem też "fun aspect", ale wydawało mi się że fajniej jest jednak pisać gry :)

Skąd więc ten 'toolism', który w studiach często prowadzi do desygnowania dedykowanych programistów do pisania tego rodzaju utili?

Offline Krzysiek K.

  • Redaktor
    • DevKK.net

# Grudzień 01, 2012, 16:00:56
Cytuj
Możesz rozwinąć, dlaczego w gamedevie taką wagę przykłada się do "otoolowania" wszystkiego? Przyznam, że to dla mnie fascynujące, bo to kolejne pole gdzie gamedev robi inaczej niż "reszta świata" :)
Generalnie to wszędzie się takie podejście sprawdzi.

Cytuj
Czemu więc spędzać dni/tygodnie/miesiące na tworzeniu dedykowanych programów?
* Rozumiem chęć nauki tworzenia aplikacji z GUI - umiejętności nigdy nie szkodzą. Zdziwiłbym się jednak gdybyś Ty, Krzyśku, mógł jeszcze coś z pisania takich aplikacji wyciągnąć :)
* Rozumiem że czasami z tooli korzystają nie-programiści, chociaż to też da się rozwiązać (graficy/muzycy mają swoje narzędzia, których wyjściowe formaty są znane). Ale w przypadku silnika pisanego na własnego potrzeby?...
* Rozumiem też "fun aspect", ale wydawało mi się że fajniej jest jednak pisać gry :)
Wszystko sprowadza się do jednego: czasu iteracji contentu. Gry fajnie się pisze, ale żeby była to gra to poza programem muszą powstać też assety, levele, itp. A one powstają tym szybciej, im łatwiejsze w obsłudze i bardziej WYSIWYG są toole.

Screenshot który wcześniej podesłałem przedstawia mojego toola do intra 4k. Jak inaczej bez tego wyobrażasz sobie sensowne stworzenie czegoś takiego bez dedykowanego toola?

Offline Pawelx156

  • Użytkownik

# Grudzień 01, 2012, 18:38:44
Krzysiek K ma absolutnie rację. Dobre narzędzie to podstawa.

Ja sobie do swojej gry zrobiłem 2 programy.
1- program do textur ( wynikiem jest plik z którego korzysta gra )
2 - in-game-editor edytorek wygląda tak:


Nie wyobrażam sobie( choć to gra 2d ) żebym miał jakieś inne narzędzie, albo jak jaskiniowiec składał levele " Ręcznie" ( jakieś pozycje ręcznie wklepywał itp. 
A że ja poziomów czy sceneri ( menu, credist, itp ) nie składam tylko ktoś inny, więc takie narzędzie bardzo pomaga. Zwłaszcza że ten co robi poziomy ( mój brat ) to lewa noga z programowania.
A że to edytor In-game to w czasie rzeczywistym może robić poprawki, testować fragmenty mapy itp.




Offline Xion

  • Redaktor
    • xion.log

# Grudzień 01, 2012, 18:44:00
Cytuj
Wszystko sprowadza się do jednego: czasu iteracji contentu. Gry fajnie się pisze, ale żeby była to gra to poza programem muszą powstać też assety, levele, itp. A one powstają tym szybciej, im łatwiejsze w obsłudze i bardziej WYSIWYG są toole.
Okej, to ma sens. Zwłaszcza w przypadku silników wielokrotnego użytku dobry toolset może rzeczywiście znacznie przyspieszyć tworzenie contentu.

Cytuj
Screenshot który wcześniej podesłałem przedstawia mojego toola do intra 4k. Jak inaczej bez tego wyobrażasz sobie sensowne stworzenie czegoś takiego bez dedykowanego toola?
Trochę trudno wywnioskować ze screenu jaka dokładnie funkcjonalność jest tam dostępna, no ale spróbujmy:

* Graf w lewym dolnym wygląda na strukturę drzewka sceny, które dałoby się zapisać w hierarchicznym formacie tekstowym. Ze względu na cross-linki pewnie konieczny byłby bardziej YAML niż JSON, który ponadto ma tę zaletę że pisze się go niezwykle szybko (praktycznie zero składni typu " czy { }). O XML-u nie wspominam, bo nikogo nie podejrzewam o taki masochizm :)

* Kod na prawo od grafu wygląda na GLSL z autorskimi dyrektywami (linie zaczynające się od @) więc to już jest w postaci łatwej do przetwarzania.

* Drzewko z plikami projektu to standardowy element dowolnego edytora.

* Nie wiem dokładnie do czego służą okienka Properties, ale strzelam że chodzi o regulowanie parametrów elementów wspomnianego na początku grafu, więc to też załatwiałby plik tekstowy grafu.

* Preview w czasie rzeczywistym to w sumie jedyna rzecz, którą należałoby dopisać do dema, tzn. observer na system plików i automatyczny reload gdy coś się zmieni. Nie sądzę, by było to trudniejsze niż osadzenie renderera we własnym edytorze.

Gdy tak patrzę na ten screen, to przychodzi mi do głowy porównanie z moim własnym setupem, gdzie ekran(y) mam podzielone na:

* edytor z kodem, skonfigurowany z opcją save_on_focus_lost
* konsolę z działającym serwerem, reloadowanym po każdej zmianie plików
* konsolę narzędziową (odpalanie testów, git-owanie, itp.)
* okno przeglądarki

Gdyby jeszcze to ostatnie potrafiło jakoś skomunikować się z serwerem i zrobić automatyczne odświeżenie strony po zmianach (plugin?...), to można by mówić o kodowaniu z iteracjami w real-time :)
« Ostatnia zmiana: Grudzień 01, 2012, 18:47:29 wysłana przez Xion »

Offline Krzysiek K.

  • Redaktor
    • DevKK.net

# Grudzień 01, 2012, 19:31:10
Cytuj
Okej, to ma sens. Zwłaszcza w przypadku silników wielokrotnego użytku dobry toolset może rzeczywiście znacznie przyspieszyć tworzenie contentu.
Przyspiesza już przy pierwszej grze.

Cytuj
* Graf w lewym dolnym wygląda na strukturę drzewka sceny, które dałoby się zapisać w hierarchicznym formacie tekstowym. Ze względu na cross-linki pewnie konieczny byłby bardziej YAML niż JSON, który ponadto ma tę zaletę że pisze się go niezwykle szybko (praktycznie zero składni typu " czy { }). O XML-u nie wspominam, bo nikogo nie podejrzewam o taki masochizm :)
Jak nakłonisz dowolnego grafika do przesiadki z 3DS Max na ręczne pisanie glPushMatrix/glRotate/glPopMatrix, to się zgodzę. ;)

Cytuj
* Kod na prawo od grafu wygląda na GLSL z autorskimi dyrektywami (linie zaczynające się od @) więc to już jest w postaci łatwej do przetwarzania.
HLSL z dyrektywami. Tylko tutaj kwestia jest taka, że pod spodem siedzi tool w postaci parsera i optymalizatora HLSL pod rozmiar, co daje zyski rzędu 100-200 bajtów. Nie mam pojęcia jak chciałbyś się takiego dedykowanego toola do przetwarzania shaderów pozbyć (nie mówię tu o edytorze tekstu).

Cytuj
* Drzewko z plikami projektu to standardowy element dowolnego edytora.
True. Ale tutaj chodzi o całą resztę, która standardem już raczej nie jest.

Cytuj
* Nie wiem dokładnie do czego służą okienka Properties, ale strzelam że chodzi o regulowanie parametrów elementów wspomnianego na początku grafu, więc to też załatwiałby plik tekstowy grafu.
I tutaj dochodzimy do czułych kwestii. Z pozoru jest to zwykły property grid, ale:
- pozwala na "scrollowanie" wartości (łapiesz myszą za wartość i przesuwasz) z natychmiastowym podglądem widoku,
- pozwala na przejrzenie podobnych wartości użytych w projekcie i wybranie akceptowalnej wartości do reuse (co pozwala bardzo szybko zbić rozmiar intra przed deadlinem) - oczywiście z natychmiastowym podglądem, bo nie można tego robić w ciemno

I generalnie 90% pracy z projektem opiera się na scrollowaniu tych wartości i ustawianiu tak, żeby całość wyglądała ja najlepiej.

Cytuj
* Preview w czasie rzeczywistym to w sumie jedyna rzecz, którą należałoby dopisać do dema, tzn. observer na system plików i automatyczny reload gdy coś się zmieni. Nie sądzę, by było to trudniejsze niż osadzenie renderera we własnym edytorze.
Nie jest i poprzednie dema tak robiłem. Ale w takim układzie drastycznie wydłużasz czas iteracji. Z płynnego scrollowania dowolnej wartości w intrze i obserwacji jak to wygląda skaczesz do ~1-2s na każdą zmianę.

Wyobrażasz sobie co by było, gdybyś w przeglądarce nie miał scrollbara tylko wpisywał w osobnym pliku tekstowym ile px od góry ma zacząć się pokazywanie strony? No to tutaj było by to mniej więcej tak samo wygodne i praktyczne.

Offline Xion

  • Redaktor
    • xion.log

# Grudzień 01, 2012, 21:11:21
Cytuj
Jak nakłonisz dowolnego grafika do przesiadki z 3DS Max na ręczne pisanie glPushMatrix/glRotate/glPopMatrix, to się zgodzę. ;)
Ale ja ci nie każę (tudzież grafikowi) modelować w pliku tekstowym. (Been there, done that, never again - ale przynajmniej dwa przedmioty na uczelni tym zaliczyłem ;)) Chodziło mi raczej o opis sceny złożonej z gotowych już modeli + ich przekształceń.

Cytuj
HLSL z dyrektywami. Tylko tutaj kwestia jest taka, że pod spodem siedzi tool w postaci parsera i optymalizatora HLSL pod rozmiar, co daje zyski rzędu 100-200 bajtów. Nie mam pojęcia jak chciałbyś się takiego dedykowanego toola do przetwarzania shaderów pozbyć (nie mówię tu o edytorze tekstu).
Wcale nie chcę się go pozbywać. Taki optymalizator to przykład narzędzi które bardzo cenię: jeden feature, tekstowe wejście, łatwe łączenie w większą całość (z kompilacją/linkowaniem/crinklerowaniem/cokolwiek strasznego robisz temu demu). Nie musi to być część jakiegoś wielgachnego dedykowanego edytora, żeby spełniało swoje zadanie.

Cytuj
I tutaj dochodzimy do czułych kwestii. Z pozoru jest to zwykły property grid, ale (...)
Więc jest to w sumie dość wyspecjalizowane narzędzie, które przypomina raczej wbudowany debugger zamiast zewnętrznego edytora. A skoro, jak twierdzisz:
Cytuj
(...) generalnie 90% pracy z projektem opiera się na scrollowaniu tych wartości (...)
to rzeczywiście takie narzędzie jest potrzebne. Tyle że jeśli użyjemy mojej analogii do webdevu:
Cytuj
Wyobrażasz sobie co by było, gdybyś w przeglądarce nie miał scrollbara tylko wpisywał w osobnym pliku tekstowym ile px od góry ma zacząć się pokazywanie strony?
to mówimy tutaj o toolu typu Firebug / Chrome Developer Tools. Różnica polega oczywiście na tym, że 90% aplikacji tam nie powstaje.

Offline Krzysiek K.

  • Redaktor
    • DevKK.net

# Grudzień 01, 2012, 21:22:35
Cytuj
Ale ja ci nie każę (tudzież grafikowi) modelować w pliku tekstowym. (Been there, done that, never again - ale przynajmniej dwa przedmioty na uczelni tym zaliczyłem ;)) Chodziło mi raczej o opis sceny złożonej z gotowych już modeli + ich przekształceń.
Nawet jak jedynym dostępnym modelem jest sześcian i masz z niego wymodelować na przykład drzewo?

Cytuj
Więc jest to w sumie dość wyspecjalizowane narzędzie, które przypomina raczej wbudowany debugger zamiast zewnętrznego edytora.
Nie. To jest właśnie edytor. Za bardzo przyzwyczaiłeś się do kodowania, gdzie czasy iteracji są nawet rzędu minut. Przy tworzeniu contentu liczy się WYSIWYG i to niezależnie jakiego contentu.

Cytuj
Różnica polega oczywiście na tym, że 90% aplikacji tam nie powstaje.
Chodziło mi o 90% użytkowania toola. Samo użytkowanie toola to może 5-10% czasu developmentu intra. Pozostałe 90% to napisanie toola i playera. Tyle że bez toola proces robienia contentu był by morderczy na tyle, że intro by nie powstało w ogóle.

Offline mihu

  • Użytkownik
    • mihu

# Grudzień 01, 2012, 23:10:23
- pozwala na przejrzenie podobnych wartości użytych w projekcie i wybranie akceptowalnej wartości do reuse (co pozwala bardzo szybko zbić rozmiar intra przed deadlinem)
PROPS! Super pomysł.