Prezentacja mojego silnika MagicEngine


#25

Dziwne, że musisz ładować tekstury kilka razy, nigdy nie próbowałem współdzielić kontekstu w Javie, ale normalnie współdzieląc kontekst możesz uzywać tych samych tekstur (nie da się współdzielić VAO i FBO bo to obiekty abstrakcyjne, nie znajdują się wgl. na karcie) :slight_smile:

Co do GBuffor, ogólnie im mniej masz tam danych tym lepiej, tym szybciej, jeżeli czegoś nie potrzebujesz, nie uzywaj tego :wink: Normalną radzę albo zapisysawać kątami (crytek gdzieś ma opisane jak takie pakowanie zrobić) i trzymać dwie składowe, albo wykorzystać GL_RGB10_A2, inaczej oświeltenie bedzie niskiej jakości ze względu na małą precyzję zapisanych normalnych :slight_smile: Skoro masz Depth, wyrzuć World Position, można to spokojnie odczytać z głębi, będziesz miał taniej i szybciej :wink: Co prawda istnieje kilka metod na to, ale jak uda Ci się zaimplementować którąś z tych lepszych, to powinieneś być zadowolony :slight_smile:

Zazwyczaj nie trzyma się teraz “specularity” jako trzy składowe ze względu na rzadkość wykorzystania, a duży narzut na GBuffer. Ba! Niektóre silniki wcale nie mają specularity :smiley: Bo po co xD skoro masz Glossiness, albo Roughness, to zastępuje to specular. Bo parametr specular jest zazwyczja koło 0.5 (czyli załóżmy około 0.04 odbicia światła), a kolorowany specular posiada bardzo mało materiałów :slight_smile: Więc zakłada się, że przyjmujemy kolor światła jako kolor odbicia :slight_smile: Co prawda zdarza sie jeszcze, że ktoś wykorzystuje kolorowany specular, ale zazwyczaj robi z tego niezłe sztuczki :smiley:

Wgl. zastanawiałes sie czy nie lepiej zaimplementować deferred shading zamiast deferred lighting? Jeżeli nie celujesz w konsole starej generacji to Ci się nie opłaca implementować deferred lightingu. Deferred shading jest w zasadzie prostszy i wydajniejszy. Chociaż żeby dobrze to zintegrować z PBR to przydałby się już Tile-Based, albo clustered, ew. można envmapki dawać w pierwszym passie :slight_smile:

I nie rozumiem po co UV? :smiley: UV są tak naprawdę zbędne, bo kolor powierzchni zapisujesz w diffuse.

Poza tym… Widać progress :smiley:


#26

@up
No niestety, próbowałem w dwóch canvasach zbindować tą samą teksture i niestety nie da się (w ogóle to losowo jest wybierany canvas co jest mega dziwne). Na jednym widzę normalną teksturę, a na drugim dzieją się cuda jak na przykład tekstura znajdująca się w tym samym folderze, ale nie załadowana do pamięci (to chyba było najdziwniejsze) albo paski o różnych kolorach. Nie za bardzo chcę mi się przerabiać canvas AWT LWJGL (bo raczej tam jest pewnie gdzieś błąd) bo w sumie wiele canvasów używam tylko w edytorze, a w grze będzie tylko jeden :slight_smile:.

Z tymi kątami ciekawy znowu pomysł mi rzucasz bo naprawdę fajna sprawa :smiley:. Patrzyłem sobie ostatnio na to też VBO co mi radziłeś i rzeczywiście wychodzi dużo, dużo lepiej, ale póki co rozkminiam jak to zrobić i pewnie więcej pracy włożę przy okazji mesh editora. Co do depth to póki co world position jest tylko do testów ostatecznie pozycja do obliczania wektora światła będzie brana właśnie z depth :wink:

O Roughness mało czytałem więc ciężko mi się wypowiedzieć :stuck_out_tongue:. Co do specular to racja można w sumie wykorzystać tylko jeden kanał na przykład red, ale glossiness zostaje bo fajne efekty czasem można z tego zrobić :smiley:.

Z UV mam pewien pomysł, ale nie wiem czy jeszcze zadziała więc bardziej poczekam z tym, aż będzie działać i później się wypowiem :stuck_out_tongue:

Ogólnie to trochę chcę poeksperymentować ze światłem, a poźniej powywalać pewne parametry (te które będą mi nie potrzebne).

@EDIT:
Ok w internecie jest bardzo to zamieszane i okazuje się, że pomyliły mi się pojęcia deffered lightning z deffered shading (ale wtopa xd) i rzeczywiście implementuje deffered shading, ale pewnie przy okazji dodam odrazu wsparcie SSAO (no bo czemu nie, jak już to robię :stuck_out_tongue:).


#27

Roughness to akurat odwrotnosc Glossiness :smiley: Roughness = 1 - glossiness :smiley: Takze stawialem to na rowni (glossiness - gladkosc, roughness - szorstkosc) :slight_smile: Niewielka roznica, niektorzy kieruja sie tutaj intuicja, a inni jak crytek twierdza ze jedna z opcji jest lepsza/wydajniejsza :smiley:

SSAO to tylko efekt :slight_smile: Prosta sprawa,chociaz zalszy jak chcesz zrobic, bo opcji masa :smiley: Moze pomysl nad tym aby edytorem materialow mozna bylo robic efekty :slight_smile:

PS. tez kiedys nie moglem zalapac jak sie te techniki nazywaja :smiley: na forach masa bledow, a do tego nie rozumialem zasady dzialania tego wszystkiego :smiley:


#28

Z tego co pamiętam to właśnie chyba Unreal ma coś takiego do samych efektów w swoim metrial edytorze :slight_smile:

Co do SSAO to czytając o PBR zwróciłem szczególną uwagę na AO Mapping - dość fajna sprawa tylko, że pewnie problem będzie znaleźć jakieś gotowe modele z tymi wszystkimi teksturami. Pomyślę bo koncept bardzo mi się podoba, ale no może być ciężko z assetami :slight_smile:


#29

Ok mały update z tego co udało mi się zrobić w zeszłym tygodniu. Po pierwsze działa już deffered shading poprawnie co widać na poniższym screenie:

Mając podstawy mogłem usunąć już teksture world position i tak jak Mergul mówił zastąpić ją depth texture i wyliczać odeległość z niej.


Kolejnym etapem było zrobienie światła. Udało się zrobić wszystkie trzy rodzaje (chociaż przy stożkowym nie działają gładkie krawędzie, ale już nie miałem siły - za dużo matematyki jak na jeden raz :stuck_out_tongue:.Póki co glossiness i specular jest ustawio ne sztywno, ale nie trudno będzie to zmienić.

W tym tygodniu będę trochę siedział przy chyba to się nazywa potok renderowania? Chodzi oto jak obiekty (światła, przedmioty, budyki) będą sortowane przy wyświetlaniu. Na pewno obiekty pół-przezroczyste (których będzie bardzo bardzo mało w grze) będą wyświetlane osobno - forward rendering. Podobnie będzie z particlami na które nie trzeba nakładać światła (a jak już to w bardzo uproszczonej wersji). I tutaj przychodzi z pomocą trochę kanał mask w moim material edytorze, który odrzuca te piksele, które są zamalowane na czarno w masce (później pokaże na zasadzie trawy jak to będzie działało.
Drugą rzeczą na pewno będzie (a raczej jest bo już robię) jest przeglądarka katalogu assetów w której będzie można tworzyć nowe modele, nowe materiały, wyszukiwać oraz tworzyć i usuwać katalogi (może brzmi śmiesznie, ale bardzo przydatne narzędzie :stuck_out_tongue: ).


#30

W zeszłym tygodniu przez święta trochę mało czasu było ale trochę udało się zrobić. Zacząłem pracę nad Asset Browser’em.


Tak wygląda główny widok (czerwone ikonki oznaczają foldery)


Tutaj można sobie szybko zobaczyć jak wyglądają tekstury przed ich wyborem.


Zółta ikonka oznacz materiał, który potem można edytować a material edytorze.


Pop-up z możliwością tworzenia pików oraz wklejania czegoś ze schowka.


Możliwe operacje na plikach.


Operacje na katalogach i to jak to wygląda jak się zaznaczy pliki i foldery.

Jeszcze trochę mi tutaj zostało do zrobienia, a później w końcu może uda mi się skończyć edytor materiałów.


#31

Aktualizauje temat. W poprzednim tygodniu dużo siedziałem nad poprawą wydajności w całym edytorze tak żeby można było edytować tyle materiałów i obiektów w grze ile tylko dusza zapragnie. Jest już lepiej, ale niestety czasami następuje crash, gdy zamknie się i uruchomi ponownie ten sam plik -> nie mam pojęcia czemu :confused:. Do tego dodana opcja zapisu i odczytu materiałów oraz zmienione ikonki. Obecnie pracuję nad materiałami dla obiektów architektonicznych takich jak budynki, mosty itd.


Nowe ikonki folderów i materiałów robiłem sam :stuck_out_tongue:


Zdjęcia drewna z użyciem tzw. detail mapy. Niestety wygląda to tak skomplikowanie, ale dzisiaj mam nadzieje zastąpić to wszystko jednym nodem. Ponad to zainteresował mnie pewien artykuł (Artykuł) i podobny efekt architektury chciałbym zobaczyć w mojej grze :smiley:.


#32

Aktualizuje temat bo sporo się działo w poprzednim tygodniu. Przede wszystkim w końcu udało mi się (prawdopodobnie) usunąć błąd, który crashował całą aplikację edytora w bardzo rzadkich sytuacjach. Przeanalizowałem też pamięć Video RAM i po zamknięciu okna z edytorem materiału mam pewność, że wszystkie zasoby się zwalniają. Do tego poprawiłem usuwanie z pamięci okien bo był z tym nie mały problem. Koniec końców edytor teraz jest bardzo stabilny i na dobrych komputerach potrafi odpalić bardzo dużo canwasów w tym samym czasie dzięki czemu można edytować dużo plików jednocześnie :smiley:.

Kolejna rzecz to dodanie kilku nowych nodów. Pierwszy z nich to blend by distance, który zmienia kolor wraz z odległością od kamery. Mały teścik poniżej.

Detail material zrobiony w poprzednim tygodniu w ogóle nie działał tak jak powinien więc zabrałem się za niego porządnie i efekt jest super :smiley:. W zależności od tego jak blisko znajdujemy się przy obiekcie to albo są wyświetlane dodatkowe żłobienia albo nie. Nie wiem czy cokolwiek widać, ale wstawiam linka:
https://www.instagram.com/p/BdoMxOpBK0K/?taken-by=alan.dragomirus

Dalej ten sam nod, ale dla normal mapy przez co musiałem też dodać nod, który odczytuje “spakowaną” normalną:

No i finalnie dodałem glossiness i specularity do renderingu. Jednak tak jak @Mergul proponował będzie później PBR :stuck_out_tongue:.

Dzięki kilku osobom dowiedziałem się również jak działa proces wywalania zbędnych zmiennych, funkcji itd. z shaderów podczas kompilacji dzięki czemu mogłem ustawić domyślne koordynaty dla pobierania próbki z tekstury w przypadku kiedy użytkownik nie poda noda. W skrócie to mniej połączeń jest pomiędzy nodami przez co jest czytelniej :stuck_out_tongue:.

Obecnie pracuje nad wyświetlaniem klatki w grze. Szczerze to na początku jak zobaczyłem analiże wyświetlania klatki w Unreal Engine 4 to trochę mnie to przerosło, ale na szczęście już powoli zaczynam to kumać. Jeżeli chodzi o deferred shading to jest to bardzo zbliżone do unreal 4, a tekstury wyglądają tak:

  1. Scene color deferred, czyli albedo pomnożone przez ambient
  2. Normal
  3. Distortion - Metalness/Roughness (ale póki co jest to glossiness)/Specularity
  4. Albedo + AO

#33

W tym tygodniu będzie bardzo krótka aktualizacja. Niestety w pewnym momencie Java przestała być dla mnie wystarczalna. Okazuje się, że SWING sam w sobie ma parę problemów, poza tym gerbage collector strasznie mi zaczął przeszkadzać przez swą nie deterministyczność. Tak więc przenosze wszystko na język C++ - myślę, że nie bedzie to aż tak trudne jakby się mogło wydawać, a większość klas po prostu będę kopiował (nie wspominając o shaderach).
Dzięki językowi C++ porzucam też systemy Mac OSX oraz Linux na rzecz Playstation 4 i XBox One (w przyszłości jednak zamierzam do nich powrócić), a bibliotekę SWING zastępuje tutaj Qt (ma wiele gotowych elementów, które w swingu musiałem pisać w sumie od nowa).
Także wracam za jakieś pewnie 3-4 tygodnie :stuck_out_tongue:.

Na koniec zdjęcie z ostatniego tygodnia, gdzie robiłem test materiałów w silniku :slight_smile:


#34

Pochwalam decyzję :smiley:


#35

To znaczy, że robisz to źle. GC jest po to, żeby sprzątał, ale z drugiej strony ty nie musisz śmiecić. Recycling obiektów jest w grach czymś wręcz koniecznym. Do tego używasz pewnie standardowej JVM. Polecam tą załączaną przełącznikiem -server. Ma ona domyślnie włączone DoEscapeAnalysis, które jest niedostępne dla zwykłej JVM. Poczytaj sobie co to cudo robi :wink: No i sam wybór GC ma ogromne znaczenie. Wiedziałeś, że JVM ma kilka rodzajów? Polecam +UseConcMarkSweepGC :slight_smile:

Ogólnie to poczytaj sobie o Javie, skoro się już za ten język wziąłeś. Java w dobrych rękach jest niezwykle wydajna, wydajniejsza niż C# a pod względem szybkości tworzenia w niej czegokolwiek na pewno korzystniejsza niż C++. Nawet jeśli jest wolniejsza.
W silniku gry i tak najważniejsza jest obsługa GPU oraz wygoda dla end usera. W dobrym silniku CPU nie ma za dużo do roboty a alokacja pamięci po wstępnym ‘rozkręceniu się’ nie powinna mieć miejsca.


#36

W dobrym silniku CPU nie ma za dużo do roboty

To ciekawe czemu powstało API takie jak Vulkan :smiley: Pewnie dlatego, że lepszy driver sprawi że GPU będzie szybsze :smiley:
Nie no, ogólnie CPU jest w wielu dzisiejszych grach wąskim gardłem. I są przerwy w pracy GPU.

Jeżeli chodzi o ograniczenia Javy to są spore. I to jest chyba jedna z większych wad Javy. ze dużo rzeczy Java po prostu zabrania, zabrania też dobrego zarządzania pamięcią, co z natury psuje dobre zarządzanie pamięcią GPU. Brak pracy na wskaźnikach, brak nadpisywania operatorów. A samo GC nie ważne jak jest zrobione zazwyczaj jest problemem. Oczywiście w nawet dość skomplikowanej grze niekoniecznie powstrzyma to Twoje prace, niemniej wpłynie na jakość rozgrywki :slight_smile: Zazwyczaj zarządzanie pamiecią w silnikach odbywa się w określonych momentach, ponieważ sami decydujemy kiedy i co zwalniamy. Przy obsłudze większej ilości elementów nie ominiesz zarządzania pamiecią. Nie można tak po prostu wszystkiego trzymać w pamięci :smiley:

Da się zrobić grę, a nawet silnik do gier w Javie. Ale im większy projekt, tym więcej stracisz. Dodatkowo powołując się chociazby na to że mało która dobra gra czy silnik jest tak “czysto” obiektowy. Zwraca się uwagę na takie rzeczy jak DOD, mimo że przecież wydaje się ze wszystko jest takie szybkie i fajne :smiley: Jednak momentami dobre zarządzanie pamiecią potrafi czynić cuda :slight_smile:

Tak samo spora liczba algorytmów, jeżeli dobrze nie ułożysz danych w pamieci, i nie możesz wykorzystać wskaźników, to naprawdę wydajna implementacja algorytmu nie jest możliwa :slight_smile: Nie bez powodu robi się gry dalej w C++ :smiley: Fakt że C/C++ nie jest jedynym słusznym wyborem, ale mimo wszystko ciągle jest jednym z najlepszych wyborów w tym kierunku. (Sam osobiście nie piszę już w C++)


#37

Chodzi o to, że przy dobrze zorganizowanym projekcie CPU powinno mieć duży zapas. A już na pewno nie powinno być marnowane na GC, które wiąże się z czymś tak niemiłym jak stop-the-world. Ogólnie Parallel GC + ConcMarkSweep pozwala zminimalizować ‘straty’, ale i tak wszystko zależy od programisty. Jak wszędzie. Najlepszy na świecie język będzie kiepski w rękach kogoś, kto się na nim nie zna.

Co do zarządzania pamięcią to wg mojej wiedzy direct bytebuffer daje radę w grach.

I tu właśnie objawia się potęga ‘escape analysis’, która pozwala na trzymanie obiektów na stosie a wszystko, co jest tworzone na dłużej niż wykonanie funkcji może (i powinno) być poddawane recyclingowi. Jeśli z jakiegoś powodu nie jest to możliwe to odpowiednia konfiguracja rozmiaru sterty + wybór właśnie ConcMarkSweep pozwala zminimalizować straty do praktycznie niezauważalnych.

I nie bez powodu istnieją takie silniki jak Unity oparte o powolne wręcz Mono.
Żeby było jasne: nie jestem przeciwnikiem C++, lubię ten język, lata temu pisałem w nim system czasu rzeczywistego. Ale lubię tez Javę którą całkiem dobrze poznałem.
Ostatecznie wg mnie Java jest najlepszym wyborem dla kogoś, kto chce zrobić dobrze działający projekt w sensownym czasie i ma ku temu odpowiednią wiedzę. W C++ jest zwyczajnie więcej roboty, na wybór tego języka może sobie pozwolić ktoś, kto nie startuje dużego projektu albo ktoś, kto ma odpowiednie zasoby ludzkie. Odpowiednie wyważenie pomiędzy utratą wydajności a wzrostem szybkości tworzenia aplikacji stało za powstaniem takich jezyków jak Java i C#, języków używanych w dużo bardziej krytycznych zagadnieniach niż utrzymanie wysokiego FPS :wink:


#38

Tutaj musze się zgodzić jak najbardziej :slight_smile: Wszscy prawie narzekają na to ze Unity jest powolne. I jest to prawda :smiley: Ale jak ktoś nie umie robić gier, a idea dobrego programowania przerasta go, to nauka prostszego (w podstawach) silnika jest znacznie prostsza. Dopóki nie robisz ogromnej gry, to Unity potrafi dac na tyle dobre rezultaty, że nikt nie przejmuje się tym ze mogłoby być lepiej :slight_smile:
Bardziej czasami tylko mnie smuci to, że naturalnie uznaje się teraz że podejście Unity jest jedynym słusznym, i nikt nie próbuje inaczej. Nawet większośc innych silników, wymagajacych trochę większego doświadczenia jest negowana :slight_smile:

Nie uważam że Java jest złym jezykiem, ale jest nad wyraz idealizowana. Sam miałem okazję poznać jej ograniczenia. I ostatecznie większośc sprowadza się do tego, że Java często traktuje nas jak idiotów, i mówi nam “albo robisz tak jak chcę, albo zmień język” :smiley:

Mimo wszystko dalej uważam że Java nie jest dobrym wyborem na silnik do gier. O ile do gry może dać radę, o tyle do silnika jest jednak zbyt ograniczona :slight_smile: Nie tylko GC jest przeszkodą, chociaż musze przyznać że również i to. Doświadczyłem również tego, że jeżeli chcesz coś zrobić dobrze w Javie to często wymaga to więcej pracy niż w C++. Przy naprawde duzych projektach tracisz większość zalet. Bo duży czysto obiektowy projekt staje sie nieczytelny. Sama Java głównie na czasie zyskuje tam gdzie wyręcza nas właśnie zarzadzaniem pamięci, oraz rozbudowaną biblioteką standardową. Poza tym wymaga więcje kodu niż większośc języków do prostych rzeczy. Napisanie wygodnego API, chociażby przez brak nadpisywania operatorów bywa uciążliwe :wink:

Ja osobiście przesiadłem się na D. I zaletami jakie odczuwam w stosunku do C++ są: większa efektywność pracy, czystszy kod, mega szablony (prawie wszystko się da), większe bezpieczeństwo (łatwiej wykryć błędy i ich nie robić). Przyznaję ze C++ jest mocno przestarzały, i posiada wiele wad. Jednak Java nie powstała do tworzenia gier :slight_smile: Ba… główną zaletą Javy nie jest szybkość programowania, a łatwość nauki. Łatiej nauczyć programować w Javie kogoś, kto nie rozumie programowania. Dużo programistów Javy nie rozumie programowania. Bo Java na to pozwala (chociaż znam przypadki ludzi nierozumiących programowania kodzących w C++ , i to mnie czasami zadziwia, że to działa).

Co prawda, to prawda. Tutaj również zgadzam się w 100% :slight_smile: Jednak tutaj znowu lekko zaatakuje :smiley: Java zakłada wiele rzeczy za programistę, więc ostatecznie bywa niewydajna i uciązliwa dla dobrych programistów. To znaczy ze jak ktos ogarnia programowanie, to bywa to denerwujace że czegoś nie da się zrobić, bądź nie można zoptymalizować :smiley: C++ pozwala na znacznie więcej. I tak, dochodze do tego, że każda rzecz (typu GC) która jest wbudowana w język, jest czymś co czyni ten język ogólnie “gorszym” od pozostałych nie posiadających takich elementów. W tym względzie, że o ile w niektórych zastosowaniach bedzie lepszy (programy o GC potrafią byc wydajniejsze z marszu, bo nie mają tyle alokacji pamięci, i napewno są bardziej bezpieczne), o tyle możliwości jego zmniejszają się, poniważ nie pozwala wykorzystać w pełni możliwości procesora.

Wgl. dobrym porównaniem jest porównanie Javy do Unity :smiley: Java to takie Unity wśród językóœ programowania. To znaczy stawia się na łatwość i 'bezbłędność" (ro znaczy dbanie o poprawne działanie za programistę) bardzije niż na wydajność i mozliwości. Java jest prostsza, w wielu przypadkach łatwiejsza do programowania. Fakt, że słaby programista zazwyczaj lepiej poradzi sobie w Javie, tak samo w Unity. Dlatego że jest łatwiej i wiele mu zapewni język. O tyle dobry programista zazwyczaj odwrotnie. Oczywiście nie mówię że wszyscy programiści Javy sa słabi :smiley: Nie chcę także obrażać rozmówcy. Po prostu sama Java do takich rzeczy głównie się rozwija. Do prostoty (która często bywa bardziej pogmatwana, niż toporny C++) :slight_smile:

Dodam że sporo osób dalej korzysta z czystego C. Sami “wielcy” programiści często narzekają na programowanie obiektowe jako że jest słabe. A wiec narzekają także na C++ (a tym bardziej na Jave). Dlatego też wybór języka programowania zależy od programisty. Dla kazdego co innego da najlepsze rezultaty. Wszystko zależy od czasu, umiejętnosci i chęci.

Poza tym przepraszam za spory offtop przez moją gadanę :smiley:


#39

To może po kolei też się włączę w dyskusje :stuck_out_tongue: . Przede wszystkim w bardziej wydajnych silnikach w javie używa się strumieniowania opartego na C++ jednak. W samej Javie wywołuje się tylko poszczególne funkcje, które zakodzone są w pliku dll.
Druga sprawa to recycling obiektów. Zgadzam się i mój silnik ciągle korzysta z tzw. poola, który non-stop przetwarza już zużyte obiekty,

Problem z Javą miałem przy edytorze i to głównie z nim. Przede wszystkim canvas OpenGla sam w sobie działał źle, a jakoś nie za bardzo chcę mi się pisać od nowa go :confused:. Druga rzecz to okna. Przy dużej ich ilości GC nie ogarniał kiedy ma zwalniać pamięć i czasami czekałem na to dobre 5 min mimo iż dałem mu do zrozumienia żeby ruszył tyłek do roboty :stuck_out_tongue:. Qt możecie mówić co chcecie, ale jednak potrzebuje mniej pamięci dla samego okna. Poza tym jest dużo kontrolek, których nie muszę pisać od nowa (jak properties tree) i dużo dużo lepiej napisany GL canvas. Trzeci czynnik to platforma XBox One i PS4. Jako, że głównie gram na konsolach, a na PC tylko kodze chciałbym kiedyś zobaczyć swój silnik w akcji na Xboxie One (bo tylko z tego co wiem ta platforma jest darmowa). Jednak najbardziej przekonała mnie dyskusja z kolegą z pracy na temat silników. W Javie jest problem z optymalizacją kodu. Nie mówię, że tylko w tym języku bo zdarzają się takie perełki jak Unity (chodzi mi o grę Ubisoftu :stuck_out_tongue: ), ale jednak w C++ łatwiej jest zoptymalizować działanie silnika.
Do tego może wydawać się to śmieszne, ale trochę tęsknie za referencjami, pair, tuple oraz macrami define i często mi tego brakowało w Javie. Ogólnie to zawsze mi trochę brakowało rzeczy z C++ bo Java robiła coś inaczej.

Także reasumując. Głównym powodem zmiany nie jest sam silnik gry, a bardziej edytor do tego silnika (sama gra już w okienku OpenGLa bardzo ładnie chodziła i nie miała wycieków pamięci) oraz po części brak możliwości zrobienia solidnej optymalizacji kodu. Możecie mi wierzyć lub nie, ale nawet prawostronna referencja podobno wpływa na wydajność gry. Oczywiście ktoś może tutaj powiedzieć, że mogę napisać edytor w C++, a samą grę w Javie, ale moim zdaniem to się mija z celem. Ponad to nie odchodzę aż tak od Javy. Podobno wiele gier MMO ma servery napisane właśnie w Javie więc chciałbym przynajmniej spróbować zrobić integracje Javy z C++ w jakimś stopniu, ale póki co skupiam się na kliencie gry :slight_smile:.


[MMORPG VIA WWW] Perspective, Ultima VI, VII, Tibia
#40

Trochę mnie nie było w moim temacie bo w pracy musiałem ostatnie pół roku sporo kodzić i w sumie przepisać od nowa cały silnik renderujący. Z tych powodów nie miałem też siły robić dokładnie tego samego jeszcze po pracy :stuck_out_tongue:.

Jeżeli chodzi o projekt to plany się trochę zmieniły. Otóż zostaje przy pisaniu silnika w Javie z tego względu, że na rynku nie ma obecnie żadnego fajnego silnika 3D napisanego w javie z dobrą grafiką. Wszyscy też twierdzą, że Java nie nadaje się do pisania dużych gier, ale nikt tego zbytnio nie udowodnił. Sprawdzę zobaczę co i jak i jeżeli rzeczywiście będzie tragedia to przepisze to na C++ jednak już teraz mogę wam zdradzić, że w silniku jest kosmos i petarda :smiley:.

Co do API to nadal pozostaje przy OpenGL jednak teraz zwiększyłem wersje do 4.3. W nie dalekiej przyszłości również pojawi się wsparcie dla Vulkana z tego względu, że jestem ciekaw jak szybko będzie renderował rzeczy skoro OpenGL 4.3 robi to naprawdę szybko.

Po powrocie póki co porzuciłem renderowanie obiektów na mapie i teraz skupiam się głównie znowu na terenie. W pierwszej kolejności zaimplementowałem drzewo czwórkowe, morfowanie pomiędzy różnymi Level of detail (im kamera jest dalej tym mniej szczegółowy teren jest wyświetlany), tessalacje, obsługę heightmap oraz generowanie normal mapy z height mapy. Do tego poprawiłem przesyłanie tablic do shaderów bo nie działało i compute shader.

Efektem tego wszystkiego jest ogromna możliwość wyświetlania terenu przy minimalnych spadkach FPS. Po pierwszych testach jestem podwrażeniem ile OpenGL 4.3 daje. Teren o wielkości 8km jest wyświetlany bez najmniejszego wysiłku pomimo braku frustum culling! Większego terenu w moim silniku nie będzie. Obecnie będę pracował na edytorem terenu przez pewnie najbliższe kilka tygodni, a później chcę zająć się generowanie ocenu FFT i możliwością umieszczenia go na mapie. Zdjęcia z terenu wrzucę jakoś w niedzielę :slight_smile:.


#41

Nie widziałem tego tematu wcześniej. Też piszę w Javie (właściwie to w Scali). Teraz przy okazji używam jej do pisania gry MMO. 2D więc większość rzeczy z tego tematu mnie omija :slight_smile:

Nie wiem czy ktoś wcześniej poruszył ten temat, ale jakie masz podejście do samej pracy serwera i synchronizacji danych z klientem? Jak w teorii ma wyglądać praca na Twoim silniku jeśli chodzi o warstwę sieciową?

  • Serwer chodzi w pętli, wylicza stan świata co jakiś czas, klient interpoluje? Czy jakiś sprytniejszy mechanizm?
  • Dzielisz świat na części? W jaki sposób?
  • Jak wygląda zapis do bazy danych? Serwer działa w pamięci i zapisuje dane raz na jakiś czas? Czy może pisze i czyta cały czas bazę danych (lub cache)?
  • Serwer wspiera klastrowanie?

(Jeśli gdzieś o tym pisałeś już w wątku do podeślij odnośnik. Trudno mi było przechodzić przez ściany tekstu :slight_smile: )

Zauważyłem, że w gamedevie brakuje ciekawego rozwiązania w formie frameworku/silnika ale dla samego tworzenia części sieciowej w MMO. Pomijając oprawę audiowizualną, którą można stworzyć w czymkolwiek.

Co do javy, dla mnie największy problem z nią to brak wsparcia konsol. Co jest dość kuriozalne, bo java właśnie szczyciła się byciem crossplatformową technologią :slight_smile:


#42

Właśnie coś ostatnio ktoś wspominał, że jest wielka możliwość otwarcia Javy dla Playstation 5 chociaż podobno rozmowy trwają (były też przy okazji PS4, ale wiadomo jak to się skończyło).

System podobny do tego z Counterstrike oparty na tickrate. Pętla, która zbiera informacje o ruchach/akcjach i wysyła je do gracza tyle razy na sekundę ile się ustaw w configu jednak zostanę pewnie przy 32/64.

Każdy obszar jest podzielony na lokacje. Coś jak w WOWie gdzie masz świat podzielony na krainy. Każda kraina/lokacja chodzi w oddzielnym wątku. Wątki synchronizują się tylko z głównym wątkiem, który obsługuję wysyłanie wiadomości/dodanie gracza do gry. Co do dzielenia lokacji to po prostu jest ona dzielona na mniejsze chunki, które przechowują konkretne obikety jak leżące przedmioty na ziemi/innych graczy. Ty jako gracz widzisz tylko pewien wycinek chunków.

Gra zapisuje stan gracza w momencie wylogowania się go z gry. Kopia robiona jest codziennie o wyznaczonej godzinie. W tym momencie również czyści się mapa i serwer się resetuje. Pozostałe rzeczy takie jak oferty czy bany zapisuje w czasie rzeczywistym przy użyciu LevelDB - obecnie najszybsza baza danych na rynku od Googla :slight_smile:.

Rozwiń temat bo to dość obszerne pojęcia i nie za bardzo wiem o co dokładnie chodzi :slight_smile:.

Silnik chcę by w finalnej wersji wyglądał jak Unity jednak tylko dla gier MMORPG :slight_smile:. Chcę dodać jeszcze parę bajerów, ale pracuje nad pewnym system od chyba 5-6 lat i nadal napotykam mnóstwo przeszkód, więc do końca nie wiem czy to jest realne. Być może u mnie w silniku pojawi się też nowy system, którego jeszcze nie widzieliście w żadnej innej grze, a to dlatego, że kolega pisze prace i jak opatentuje pewną rzecz to ja z niej chcę skorzystać od razu :stuck_out_tongue:.


#43

Dzięki :slight_smile: Ciekawe jak to będzie działało w praktyce :slight_smile:

Czy będzie się dało rozproszyć serwer tak by świat gry działał w jednym klastrze wielu fizycznych maszyn?
Z punktu widzenia MMO, zdolność do skalowania jest jedną z bardziej istotnych rzeczy, ale zawsze odbywa się jakimś kosztem (CAP). Ciekawi mnie jak Ty do tego podchodzisz.

Twoje przemyślenia pewnie przydadzą się każdemu kto pisze grę sieciową, w tym mnie :smiley: stąd te pytania :slight_smile:


#44

A spoko oto chodzi. Ok więc nad tym jeszcze nie myślałem bardzo i szczerze mówiąc nie wiem czy jest sens. Na pewno przy ogromym świecie (lub gdy dojdzie fizyka) zrobi się testy i zobaczę aczkolwiek wiele gier z tego co kojarzę to pomija zupełnie ten aspekt -> np. Tibia i Metin (ale tego nie jestem pewien). Na obecnym etapie za wcześnie żeby o tym myśleć aczkolwiek już kiedyś do tego tak bardzo bardzo wstępnie podchodziłem, jednak to póki co luźne pomysły :slight_smile:. Czyli podsumowując jak już będę sklejał bardziej konkretną grę gdzie będzie na mapie dużo obiektów i wejdzie fizyka to zobaczę jak to będzie wyglądać w praktyce i wtedy pomyślę. Póki co jest mi ciężko powiedzieć czy dodawanie tego ma sens :slight_smile:.
W ogóle w obecnej postaci serwer obsługuję maks 1000 graczy online tak btw. :stuck_out_tongue: