Prezentacja mojego silnika MagicEngine


#20

Graś screenów z tego co udało mi się zrobić w poprzednim tygodniu:


Skończony string edytor do edytowania wszystkich napisów w grze


Możliwość usuwania nodów oraz połączeń między nimi


Myślę, że już ostatnia prosta jeżeli chodzi o edytor materiałów. W przyszłości zamiast pozycję kamery wyliczać z view matrixa zastąpi to pewnie uniform lub nawet UBO. Pozostało mi w sumie tylko już aktualizować shadera i dodać deffered lightning, które póki co nie do końca wiem jak działa jeszcze, ale pewnie wyjaśni się to mi na dniach :slight_smile:


#21

W poprzednim tygodniu wiele zrobiłem w silniku i zaczyna to wyglądać naprawdę fajnie :smiley:.
Po pierwsze: w nod edytorze da się już tak naprawdę stworzyć dowolny materiał jaki tylko byście chcieli mieć (niestety nie działa jeszcze światło :confused:). Także jeżeli widzieliście zwiastun wiedźmin 2, gdzie Triss Merigold znikają fajnie ciuchy to tak w moim silniku da się też to napisać :stuck_out_tongue:. Jak będę miał więcej czasu to może jakieś takie demko sobie przygotuję, ale to dużo zabawy z tym by było. Póki co wrzucam screeny jakie zrobiłem przez poprzedni tydzień:


Na początku poszedł test kanału diffuse na wektorze, który repezentuje tutaj kolor.

https://www.instagram.com/p/BcV34OVBfdg/?taken-by=alan.dragomirus
Tutaj demko jak działa funkcja czasu w moim edytorze.


Dodany nod “texture sampler” dzięki czemu można nakładać na model tekstury. Z tym był największy problem niestety. Okazuje się, że nawet współdzieląc kontekst OpenGLa przez kilkanaście canvasów nie można współdzielić tekstury na GPU. Także, jeżeli potrzebuję dwóch tekstur to niestety muszę załadować je dwa razy. Zamiast jednego asset managera ma ich dokładnie tyle co canvasów :confused:.

https://www.instagram.com/p/BcdpAaLhZ8G/?taken-by=alan.dragomirus
Interpolacja dwóch kolorów oraz byskanie przypisane do uniformu? Nie ma sprawy już działa :smiley:.

14
No i ostatnia rzecz zrobiuona w zeszłym tygodniu czyli dodana obsługa FBO (bez multi sampli póki co). Powoli zabieram się już za implementacje Deffered lightning (i mam nadzieję skończyć w tym tygodniu), a raczej kończe bo już działa GBuffer, więc efekt ze światłem będzie mam nadzieję sto razy lepszy :smiley:.

2
Tak wygląda szkic tego aczkolwiek od razu mówię, że póki co skupiam się tylko na: world position, diffuse oraz normal. Reszta dojdzie w między czasie :slight_smile:.


#22

Zakładam, że Twoje posty rozumie dość nieliczne grono ludzi (niestety ja bez googlowania nie), ale jednak chętnie śledzę postepy i cały czas uczę się dzięki Tobie nowych rzeczy. Trzymaj tak dalej! :slight_smile:


#23

Ja tak z ciekawości zapytam: dlaczego flow edytora materiałów idzie z prawej do lewej :stuck_out_tongue: ?


#24

Dzięki wielkie za motywacje :slight_smile:. Ogólnie to mam nadzieje, że w niedługim czasie będę wstawiał zdjęcia już bezpośrednio z gry, a nie z edytora wtedy efekty można będzie od razu zobaczyć. bez wdawania się w szczegóły techniczne :slight_smile:.

@jonasz787
Bardzo inspiruje się silnikiem wiedźmina 2 (red engine2 - można powiedzieć, że rozkładam go na części pierwsze :stuck_out_tongue:), ale też wiele elementów biorę z nowszych produkcji i z wiedźmin 3 (redengine3, jeżeli opis działania czegoś był na jakiejś prezentacji). Jak weźmiesz edytor materiałów do wiedźmina 2 to w sumie większość wyglądu jest wzięta właśnie z tego edytora (w tym flow), ale mnie szczerze mówiąc mnie to już irytuję więc jak skończe wszystkoto zmienie kierunek obiecuje :stuck_out_tongue:


#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