Godot Engine 1.0

[n-pigeon]

Właśnie została wydana pierwsza stabilna wersja darmowego silnika do tworzenia gier Godot Engine.

Jeśli chcecie dowiedzieć się o nim więcej zapraszamy do lektury artykułu.

 

Pełna treść: Godot Engine 1.0

[n-pigeon]

Używam od pewnego czasu i jest naprawdę sympatyczny w użyciu, a do tego bardzo rozbudowany. Polecam przetestować ;)

[Kroopson]

Wow. Fajne strasznie, i jeszcze w pythonie się pisze.

Podziwiam Twoją pasję n-pigeon, niezły artykuł :)

[Creator]

OK a pomijając cenę, jak ten silnik się ma do Unity na płaszczyźnie 2D?

 

Wow. Fajne strasznie, i jeszcze w pythonie się pisze.

Dla mnie to akurat minus :) Edytowane 16 Grudzień 2014 przez Creator

[Skoti]

Wow. Fajne strasznie, i jeszcze w pythonie się pisze.

Nie w pythonie (w innym przypadku powiedziałbym na szczęście, ale tu nie jestem przekonany). Twórcy silnika próbowali Lua, Python i Squirrel, ale żaden im nie podpasował i stworzyli własny język GDScript (który jako język odziedziczył wady powyższych, ale łatwo im się podpina pod silnik).

[Gość Marqin]

Warto dodać, że jest możliwość napisania własnego modułu do innego języka (na githubie jest jeden do LUA, ale jeszcze zbugowany). Tutaj może taki mały spoiler: twórcy rozważają dodanie kiedyś C#, ale wszystko zależy od tego na jakiej licencji zostanie wydana opensourcowa(ma wyjść) VM Microsoftu. Z Mono jest ten problem, że LGPL nie pozwala na zrobienie zamkniętej aplikacji mobilnej, a inne licencje od Xamarina kosztują(stąd min. cena Unity).

 

Co do 2D, mi się wygodniej pisze niż w Unity, o 3D to musi się ktoś inny wypowiedzieć.

[bolitic]

Super artykul. Musze sie przyjzec temu silnikowi. Czy jest ktos kto go uzywa oraz Unity3D i moze porownac?

[Monio]

Nie widzę tego. Przynajmniej na razie. Założenia są piękne ale jeśli goście nie ogarną modelu biznesowego to ten Godot pozostanie tylko zabawką dla hobbystów i przemijającego gatunku osób które wolą programować zamiast skupić się sednie robienia gier, czyli designie.*

 

To co odróżnia tego Godota od Unity to kilkadziesiąt lat roboczogodzin spędzonych na developingu narzędzi które można kupić na asset storze. W dzisiejszych czasach silnik gier który nie oferuje zintegrowanej platformy do handlowania pluginami i assetami nie ma racji bytu. Gruba większość kosztów branży IT to robocizna. Jak podliczy się koszta napisania/kupienia narzędzia czy kawałków mechaniki gry to wyjdzie jasno że robienie gier na takim niby darmowym Godocie wygeneruje dużo większe koszta niż zakup unity pro + opasłego zestawu assetów + zatrudnienia osoby która te assety zaimplementuje i przerobi pod dany projekt. Taki silnik się biznesowo zwyczajnie nie opłaca przy tym co oferuje Unity czy nawet młody UE4.

Jeśli goście od Godota zrobią taką platformę na której będą mogli zarabiać developerzy third party to przed tym silnikiem będzie świetlana przyszłość. Bez tego zostanie egzotyczną zabawką.

 

*This War of Mine. Poza grafikami nad grą pracowało 4 game-designerów i 2 koderów z czego jeden tylko od AI. To o czymś świadczy. ;)

[olaf]

*This War of Mine. Poza grafikami nad grą pracowało 4 game-designerów i 2 koderów z czego jeden tylko od AI. To o czymś świadczy. ;)

Taczka grafików kosztuje tyle, co jeden programista od AI.

 

Ciekawy silnik, nie wiem czy komukolwiek potrzebny, bo wiekszość rzeczy jakie posiada mozna sobie do dowolnego jezyka/silnika ogarnąc jako bibliotekę/framework. Z Moniem się zgadzam, dodam tylko, że brakuje mu jeszcze prostego modelu monetyzacji - plugin pod przegladarkę albo natywne wsparcie jak w html5/flash, gdzie mali developerzy i webmasterzy moga łatwo monetyzować kontent przy pomocy reklam.

 

BTW. Ostatnio znajomy mi mówił, ze nody to tez jest forma programowania. Nie wiedziałem ze to też się kwalifikuje pod programowanie.

[Creator]

BTW. Ostatnio znajomy mi mówił, ze nody to tez jest forma programowania. Nie wiedziałem ze to też się kwalifikuje pod programowanie.

Chyba dla leszczy :P

[olaf]

no pierwsze o czym pomyslalem, to że php już nie będzie na końcu łancucha programowania ;)

Ale jakbym miał uczyc 5-6latki programowania to raczej tylko i wylacznie na nodach.

[n-pigeon]

@Kroopson

 

Wybacz mogłem rozwinąć tą myśl. Jest jak Skoti mówi nie jest to do końca Python. Składnia i semantyka jest BARDZO Pythonowa (jest troszkę Lua), ale VM (maszyna wirtualna) która ten kod obsługuje, jest napisana przez twórców Godota i różni się do CPython (oficjalna implementacja referencyjna Pythona).

Przykładowo CPython używa Garbage Collector'a do zarządzania pamięcią, a GDS stosuje Reference Counting, ponieważ twórcy uważają, że lepiej nadaje się dla języka skryptowego używanego do tworzenia gier. To jako przykład.

Do tego GDS posiada dodatkowe funkcje które Python nie posiada (typy wektorów, matryc, quaternion'ów itp. oczywiście dodać je to nie problem, ale tutaj są out of the box i są wspierane na poziomie innych typów podstawowych), lub żaden inny język nie posiada, ponieważ mają po prostu ułatwić prace z silnikiem (np. keywordy export i tool).

 

Jednak jeśli ktoś używał już Pythona, to przesiadka będzie bezbolesna, trzeba tylko zapamiętać minimalne różnice i zapamiętać kilka nowych, które są po to by poprawić integracje języka z silnikiem.

 

@Creator

 

O Unity na razie za wiele nie wiem, dopiero zacząłem, a właściwie zacznę, jego naukę, bo muszę.

Jednak z tego co wiem Unity nie ma prawdziwego modułu 2D, gry 2D są robione w 3D z ortogonalną kamerą, na co wiele użytkowników przychodzących do Godota z Unity narzekało. W Godot masz prawdziwe 2D i jest w sumie na razie lepiej dopieszczone niż ich 3D ponieważ, do tej pory większość projektów w Okam była 2D. Teraz pracują nad jakimś dużym projektem 3D więc, teraz dostanie się i 3D coś dobrego.

Ogólnie, byłym użytkownikom Unity przypada do gustu, wielu twierdzi, że jest wygodniejszy.

 

@Skoti

 

Heeej, dawno cię tu nie widziałem, fajnie, że piszesz. Wiedziałem, że Ci specjalnie nie przypadnie do gustu ich wybór :D

 

No jak MS uwolni VM C# to planują go dodać jako oficjalne wsparcie, ale nie wiem czy to Ci by pasowało.

Twoim ulubieńcem jest AngelScript? Na razie nikt, nie marudził, że nie ma wsparcia dla niego, niestety.

Na pierwszym miejscu naciskania, by dodać inny język jest Lua, potem JavaScript, potem C#, heh.

Lua zdaje się też nie lubisz, ale była próba dodania Lua przez zewnętrznego developera, na razie spasował ponieważ natrafił na problemy, ale branch jest publicznie dostępny.

 

Z językami skryptowymi jest trochę jak z polityką, każdy ma zdanie.

 

Podzielisz się swoją szerszą opinią o silniku? Czy jeszcze nie miałeś czasu bliżej mu się przyjrzeć. Jestem ciekaw twojego zdania.

 

@bolitic

 

W 2D jest prawdopodobnie lepszy, w 3D wygląda na to, że jest zbliżony poziom. Choć Unity jeszcze za słabo znam.

Byłym użytkownikom Unity przypada bardzo do gustu, z tego co z nimi rozmawiałem.

 

@Monio

 

Z Blenderem mam znacznie dłuższy staż, takie opinie słyszałem wiele razy jak zaczynałem z nim pracować, a był ZNACZNIE bardziej w tyle w stosunku do innych pakietów 3D, niż taki Godot ma zaległości do Unreala, bo jeśli chodzi o Unity są zbliżeni.

 

Różnica między Unity a Godot jest taka. Unity powstał by sprzedawać go ludziom którzy chcą robić gry i na nich zarobić, a Godot po to by tworzyć gry i na nich zarobić. ;)

I powiedz mi teraz, że Unity miał design na uwadze bardziej, niż Godot.

Jednak Unity ma duża przewagę nad Godotem, maja hajs na reklamy, wszędzie ich pełno.

 

Każdy może zarabiać na dodatkach do Godota, nie ma problemu z licencjami jak w przypadku Blendera. Sami twórcy chcą się skupić na open source'owych aspekcie silnika.

 

Juan to akurat geniusz ;) a Ariel nie jest tylko od AI. Przez ostatnie 10 miesięcy dostali tony patchy, ilość developerów będzie tylko rosła.

 

@olaf

 

W Godocie jest to mieszane, strukturę gry tworzysz w drzewku, strukturę blend'ów animacji w nodach w formie flow graph'u, niedługo to samo z dźwiękiem, ale potem logikę między nimi tworzysz w kodzie.

No niedługo dojdzie też wizualne programowanie, bo tak fachowo nazywa się programowanie w nodach, dla shaderów.

 

Flow Graph widziałbym również w sygnałach. Możliwe, że w przyszłości dojdzie opcjonalny "syntax" dla GDScript oparty o nody, heh, ale moim zdaniem to mały priorytet w tej chwili.

Edytowane 16 Grudzień 2014 przez n-pigeon

[Monio]

w 3D wygląda na to, że jest zbliżony poziom.

Godot nie umywa się do unity w temacie wyświetlania grafiki ani narzędzi do operacji na scenach 3d. Godot korzysta z GLES2.0 czyli w na pecetowe standardy technologi sprzed 10 lat! Unity pozwala na całkiem wydajne renderowanie grafiki z wykorzystaniem dzisiejszych rozwiązań sprzętowych. Za kilka tygodni wchodzi unity5 z przepisanym pipelinem renderingu, wbudowanymi shaderami PBR i Enlightenem a Godot nie ma nawet najprostszego wypalania lightmap i utknie na gęstszej geometrii bo GLES2.0 nie obsługuje occlusion queries...

 

Unity powstał by sprzedawać go ludziom którzy chcą robić gry i na nich zarobić

Bzdura. Poczytaj o historii firmy. Ten silnik powstawał razem z developingiem gry, dopiero potem zdecydowali się go skomercjalizować.

 

jeśli chodzi o Unity są zbliżeni.

Piszesz to na poważnie? Zbliżeni w czym? Porównując ilość ficzerów gołego Unity Free i Godota to ten drugi wypada bardzo, bardzo biednie. Co dopiero porównując Unity Pro + około 3 tysiące skryptów i rozszerzeń edytora dostępnych na asset store...

Na prawdę nie rozumiem na jakiej zasadzie stawiasz znak równości pomiędzy tymi silnikami. Unity jest teraz takim molochem że widzę coś dokładnie odwrotnego w temacie porównania do sytuacji blenderowej.

 

Jednak Unity ma duża przewagę nad Godotem

Główną przewagą Unity jest to że mają 300 developerów rozwijających silnik a nie jednego. Wiem że ludzie od opensource to zdolni pasjonaci ale nie przesadzajmy bo to żarty. Niech się rozwijają ale bez strategi na zbudowania community third-party developerów Godot pozostanie tylko kolejną zabawką dla hobbystów. Jak to zrobią to za parę lat będziemy mogli porównywać. Na razie trzymam za nich kciuki i kupuje ShaderForge na asset storze. ;) Edytowane 16 Grudzień 2014 przez Monio

[n-pigeon]

Godot nie umywa się do unity w temacie wyświetlania grafiki ani narzędzi do operacji na scenach 3d. Godot korzysta z GLES2.0 czyli w na pecetowe standardy technologi sprzed 10 lat! Unity pozwala na całkiem wydajne renderowanie grafiki z wykorzystaniem dzisiejszych rozwiązań sprzętowych. Za kilka tygodni wchodzi unity5 z przepisanym pipelinem renderingu, wbudowanymi shaderami PBR i Enlightenem a Godot nie ma nawet najprostszego wypalania lightmap i utknie na gęstszej geometrii bo GLES2.0 nie obsługuje occlusion queries...

 

Nie jest tak różowo jak myślisz, niestety :(

GLES2 jest na poziomie OGL 2 (no trochę funkcji z poziomu 3 i 4.1... też się znajdzie...) to prawda, ale tak samo Unity, a to dlatego, że problemem nie jest to, że im się nie chce, albo nie mieli czasu. Zwyczajnie w świecie nie było sensu tworzyć na OGL, a znacząca większość urządzeń mobilnych nie obsłuży GLES3. Zatem tworząc grę mobilną w Unity i tak używasz GLES2 bo kasa.

Unity ma tą przewagę, że na PC może używać OGL i DX jeśli się nie mylę hehe. Jednak znowu dlaczego nie ma sensu tworzyć backendu na OGL w tej chwili?

Rozpoczęto prace nad OpenGL NEXT który będzie zrywał wsteczną kompatybilność z OpenGL, a przy okazji będzie unifikował desktopowy OGL z GLES, nie opłaca się wiec tym bardziej tworzyć backendu na OGL, w tej chwili.

 

Deweloperzy w tym roku planują napisać backend na GLES3 z PBR, GI w RT i takie tam, ponieważ w 2016 roku będzie dość urządzeń na rynku które będą w stanie to odpalić. ^^'

 

Sprawdź jeszcze raz :) ma lightmap bake. I to oparty na octree więc nie potrzeba UVłek, no niestety na mobile trzeba :

 

Bzdura. Poczytaj o historii firmy. Ten silnik powstawał razem z developingiem gry, dopiero potem zdecydowali się go skomercjalizować.

 

Tak, oczywiście, tylko dlaczego dali sobie spokój z tworzeniem gier, skoro ich to tak pasjonowało. Ja tam byłbym ostrożny ;) Po za tym Unity robi wszystko po staremu, nie wybija się na tle innych komercyjnych silników pod względem technologicznym.

Okam też miał oferty komercjalizacji silnika.

 

Piszesz to na poważnie? Zbliżeni w czym? Porównując ilość ficzerów gołego Unity Free i Godota to ten drugi wypada bardzo, bardzo biednie. Co dopiero porównując Unity Pro + około 3 tysiące skryptów i rozszerzeń edytora dostępnych na asset store...

Na prawdę nie rozumiem na jakiej zasadzie stawiasz znak równości pomiędzy tymi silnikami. Unity jest teraz takim molochem że widzę coś dokładnie odwrotnego w temacie porównania do sytuacji blenderowej.

 

Co masz konkretnie na myśli? Ja nie widzę by wypadał biednie hehe. Ja widzę tylko lepszy bake w Unity. Godotowy wymaga doszlifowania niestety. Za to Unity nie potrafi 2D. Niestety tworzenie sceny zarówno w Godot jak i Unity mnie trochę męczy. Całe szczęście Godot ma świetną integracje z Blenderem, a kolega jeszcze pracuje nad addonem dla Blendka więc będzie miodzio. Niestety trzeba popracować na content creation w Godot by dorównać Unrealowi.

Porównuje gołego Unity, to prawda, troche na rękę Godotowi, bo Unity bez pluginów jest biedny. Godot nie ma setek komercyjny zewnętrznych pluginów, ale za to ma setki darmowych patchy hehe.

 

Niech się rozwijają ale bez strategi na zbudowania community third-party developerów Godot pozostanie tylko kolejną zabaweczką dla hobbystów.

 

Możliwe, czas pokaże. Tylko na przeciwwadze mamy community third-party developerów silnika, nie dodatków, więc... serio czekam, jestem ciekaw co przyniesie nam przyszłość :)

Edytowane 16 Grudzień 2014 przez n-pigeon

[Creator]

Za to Unity nie potrafi 2D.

Łat? Łat ??!! .......... -_-

To nie jest kwestia że przerabiasz sobie scene 3D na 2D, masz tutaj w Unity narzędzia tylko do 2D.

- myślę że to video pomoże Ci zmienić zdanie :D To promo sprzed roku, a narzędzia 2D cały czas się rozwijają.

[Skoti]

Z Mono jest ten problem, że LGPL nie pozwala na zrobienie zamkniętej aplikacji mobilnej, a inne licencje od Xamarina kosztują(stąd min. cena Unity).

Jasne, że LGPL pozwala na zrobienie zamkniętej aplikacji mobilnej (zarówno w iOS jak i Android). Problemem jedynie jest to, że to systemy w które użytkownik nie bardzo może ingerować więc trzeba zrobić sztuczkę i możliwość podmienienia libki (wystarczy dać możliwość wczytania własnego libmono.so przykładowo z karty pamięci - w credits na koncu wystarczy umieścić info w jakim katalogu taki plik ma być) i licencja jest spełniona (LGPL nie zabrania nawet linkowania statycznego, a jedynie nakazuje umożliwić użytkownikowi zmienić na własną wersję kod tej libki). Ofc nie każdy chce się bawić, a licencja Xamarin nie jest aż tak droga, aby jej nie kupić (kupić musi jedynie producent silnika i może reszcie udostępniać ten zamknięty libek jako część produktu silnika).

 

No jak MS uwolni VM C# to planują go dodać jako oficjalne wsparcie, ale nie wiem czy to Ci by pasowało.

Twoim ulubieńcem jest AngelScript? Na razie nikt, nie marudził, że nie ma wsparcia dla niego, niestety.

Na pierwszym miejscu naciskania, by dodać inny język jest Lua, potem JavaScript, potem C#, heh.

Lua zdaje się też nie lubisz, ale była próba dodania Lua przez zewnętrznego developera, na razie spasował ponieważ natrafił na problemy, ale branch jest publicznie dostępny.

 

Z językami skryptowymi jest trochę jak z polityką, każdy ma zdanie.

 

Podzielisz się swoją szerszą opinią o silniku? Czy jeszcze nie miałeś czasu bliżej mu się przyjrzeć. Jestem ciekaw twojego zdania.

Czyli jeszcze wiele lat nie planują C# ;p. Ofc C# przy tych językach które próbowali to niebo, a ziemia. AngelScript jest nie tyle ulubieńcem, co jest jest najfajniejszy z języków skryptowych niezależnych od silnika. Ale nie mam nic przeciwko UnrealScript, językowi z idTechów (teraz zwany super-script czyli podzbiór C++), C# (przykładowo Unity)... uważam te wybory za znacznie lepsze niż języki jak Lua (CryEngine) czy Squirrel (Valve Source). Nie dziwie się, że nikt nie marudził, bo AngelScript to język nie tak popularny (mało kto go zna) jak powyższe w zadaniach do wszystkiego (a jak wiadomo co do wszystkiego to...), a jest specyficznie tworzony przez programistę gier dla programistów gier (jak języki w Unreal Engine czy idTech) - praktycznie jedynym programem (nie grą), który możesz znać jest 3d-Coat.

Z tego co czytałem to używali Lua na samym początku, później przeskoczyli na Pythona, Squirrel i dopiero stworzyli GDScript, a teraz mówisz, że zastanawiają się nad C# (słusznie ;p) - skaczą po językach nie bardzo chyba wiedząc czego chcą, zamiast usiąść na początku przedyskutować sprawę, to jakie są dostępne opcje i jeśli nie ma satysfakcjonującej zrobić własny spełniający oczekiwania (a tak robią wiele razy tą samą robotę).

https://github.com/okamstudio/godot/wiki/gdscript

 

Co do opinii to będzie ciężko, bo nie znam tego silnika. Jednak z tego co widzę to ułamek możliwości Unity, a dodatkowo kiepskie wybory jak języki skryptowe odstraszają.

 

PS. Co do tego co piszesz później, że "Unity nie potrafi 2D" czy że się nie wybija (coraz bardziej zaczyna i o ile to kilka lat temu był po prostu tani silnik, tak teraz jest to już ścisła czołówka technologiczna) to po prostu bzdury.

[Monio]

Unity ma tą przewagę, że na PC może używać OGL i DX

Oczywiście pisałem o PC i innych platformach które obsługują nowsze wersje bibliotek. Goście mówią że ich silnik nadaje się do robienia gierek z "realistyczną grafiką 3d" na PC i konsole. Jak dla mnie to jest nadużycie. Grę odpalisz ale co z tego jeśli max tego co możesz osiągnąć graficznie to emulacja mega niewydajnego GLES2. OGLNext to świetna inicjatywa ale zanim to się ustandaryzuje miną lata. Oczywista sprawa że opłaca się pisać teraz nowoczesne renderery na desktopowym OGLu czy DXie. Firmy z zespołami specjalistów dużo bardziej ogarniętymych niż goście od Godota to robią i prześcigają się w efektach oraz wydajności. Zanim wszyscy przestawia się na OGLNext jeszcze dużo wyciągną z podejścia AZDO.

 

Godot nie ma setek komercyjny zewnętrznych pluginów, ale za to ma setki darmowych patchy (...) Tylko na przeciwwadze mamy community third-party developerów silnika, nie dodatków

Nie ma ani jednego ani drugiego. Popatrz na ich Githuba ilu jest aktywnych programistów. Łącznie 51 uczestników z czego 2 aktywnych i 3 średnio aktywnych. Reszta to drobnica która zrobiła po jednym czy 2 bugfixy. Jak w ogóle można to porównywać do 300 etatowych programistów Unity i ponad 1000 developerów dodatków (w tym wielu darmowych)?

 

Unity (...) nie wybija się na tle innych komercyjnych silników pod względem technologicznym.

To jest absolutny bullshit... Unity do spółki z Epic i Valve to czołówka technologiczna gamedevu. Te firmy mają już taką pozycje na rynku że biorą czynny udział w tworzeniu nowych technologii i rozwiązań. Nawet dotyczących hardwareu. Popatrz sobie kto jest w grupie tworzących OpenGL Next o którym wspomniałeś. Ja tam widzę wielkie loga Unity, EPIC i Valve. Gości od Godota zabrakło. ;)

 

Zgadzam się ze Skotim. Na razie Godot to ułamek możliwości Unity. Ta rozmowa mi przypomina trochę to o czym mówił Andrew Price w podcaście o "checklistowej kulturze".

Są lightmapki? Check! Jest system blendowania animacji? Check! Jest fizyka? Check! Jest Occlusion culling? Check!

Tylko prawda taka że te Godotowe ficzery to jest ułamek tego co oferują takie rozwiązania jak:

Beast

Mecanim

Physx

Umbra 3

 

Popieram i kibicuje Godotowi ale nie siejmy bullshitu że ten silnik to jakość Unity bo to więcej osób odstraszy niż przyciągnie.

Jak zależy ci żeby ten silnik wyrósł na coś super to podejmij na ich forum temat ustanowienia modelu biznesowego i strategii pozyskiwania community. To właśnie jest klucz dlaczego dzisiaj ponad połowa gier mobilnych jest robiona na Unity. Zastanawiałeś się dlaczego jak wpiszesz w google jakieś ogólne pojęcie związane z gamedevem albo grafiką 3d to niemal zawsze na pierwszej stronie będziesz miał jakiś wynik powiązany z unity? Jak nie to się zastanów dobrze i przekuj to w złoto. ;)

Edytowane 17 Grudzień 2014 przez Monio

[Skoti]

Grę odpalisz ale co z tego jeśli max tego co możesz osiągnąć graficznie to emulacja mega niewydajnego GLES2. OGLNext to świetna inicjatywa ale zanim to się ustandaryzuje miną lata.

GLES 2 to jest prehistoria (aby pokazać jaka, powiem tylko, że nie obsługuje nawet MRT - które jest w OpenGL 2 i Dx9). Jeśli celują w rynek mobilny, to powinni wspierać Metal (API na nowe iOSy), i GLES3.1 z AEP na Androida - przecież jeśli ktoś będzie chciał użyć tego silnika to zanim stworzy grę to GLES2 na połowie sprzętu może być już nawet nie obsługiwane... ba mogą nawet pełny OpenGL (Tegra K1 i Android) wspierać ze wszystkimi dobrodziejstwami nowoczesnego API.

 

OpenGL Next rozwija się bardzo dynamicznie i bliżej to kwestia roku (już ze sterownikami, które w przeciwieństwie do OpenGL będą łatwe do napisania). Ofc obecnie OpenGL powinien spełnić pełnię potrzeb, a już szczególnie z nowinkami z początku miesiąca

- nic wydajniej w nowym OpenGL nie będzie, a jedynie będzie czystym api bez kompatybilności wstecznej i z IR, przez co sterowniki nie będą potrzebowały kompilatorów.

 

Skoro podałeś już wpis na blogu Grahama Sellers o AZDO (Graham Selers z AMD to jedna z 2ch osób pracujących nad API OpenGL Next (drugą jest Jeff Bolz z Nvidii - ofc nad całością OpenGL Next pracują inni jak Bill Licea-Kane z Qualcomm, który pracuje nad językiem shaderów i IR, oraz Tom Olson, który zarządza pracami) i autor najciekawszych nowinek w API graficznych od lat) to dodam jeszcze linki do prezentacji o których pisze (slajdy z konta pracownika Nvidii Cassa Everitta, bo to w sumie były prezentacje prowadzone przez Nvidię, ale brali w nich udział też pracownicy AMD/Intel)

Edytowane 17 Grudzień 2014 przez Skoti

[Monio]

Post n-pigeona wczoraj mi przypomniał o OGLNext więc przy okazji sporo się naczytałem o AZDO i planach na przyszłość. Świetna sprawa. Niestety te slajdowe prezentacje już wykraczają poza moje pojmowanie grafiki, nie jestem (jeszcze) programistą. ;)

 

Jak zahaczyliśmy o temat nowych API to ciekawi mnie twoja opinia na temat Metala. Myślisz że to się utrzyma na dłużej czy wywalą go chwilę po tym jak wyjdzie pierwsza wersja OGLNext? Z tego co się orientuje to głównym powodem powstania Metala było to że GLES2 jest biedny a PowerVR miał jakieś problemy w pogodzeniu GLES3.1 ze swoją autorską kompresją tekstur. Będzie jakikolwiek sens rozwijania Metala gdy wyjdzie nowy OGL?

 

Skąd bierzesz newsy o tym co się dzieje z nowym OGLem? Chętnie bym to zaczął śledzić. :)

[Skoti]

@Monio: Moje zdanie jest takie, że Metal umrze podobnie jak Mantle śmiercią naturalną zaraz po wyjściu OpenGL Next, bo stracą całkowicie sens istnienia (no chyba, że zawarzą względy marketingowe, typu oni mają standard ogólny, a my mamy super hiper własny). PowerVR nie miał żadnych problemów ze swoją kompresją tekstur PVRTC, a to Apple miało. Wszystkie gry i aplikacje wykorzystujące GLES2 wykorzystują PVRTC, więc nie mogą wybrać innych GPU (bo wszystko by przestało działać) - Apple promując PVRTC sprawiło, że jest zmuszone do produktów PowerVR.

Apple jednak miałoby problem z tlumaczeniem fanom dlaczego ich produkt nie dostarcza najfajniejszych możliwości które ma konkurencja jak przykładowo Google z Android Extension Pack czyli:

- Teselacja,

- SSBO obsługiwane przez shadery fragmentów,

- Draw Indirect (sztoda, że nie multi draw indirect, bo by rządził ;p).

- ASTC najlepsza istniejąca kompresja tekstur,

- większe możliwości przy MRT.

To czego nie potrafią PowerVR potrafią Tegra K1, Adreno 4xx, Mali 800 pod Androidem.

Produkty Apple z GPU bez tych możliwości, które są na Androidzie wyglądały by blado i świetnie tu rolę zasłony dymnej robi Metal - fajne API, jednak o słabych możliwościach.

 

Niestety nie mam dostępu do Khronos. Informację zbieram od znajomych pracujących zarówno dla producentów sprzetu, jak i silników gier, którzy mają wgląd w Khronos. Ale także z tweetów twórców narzędzi dla OpenGL (przykładowo miesiąc temu jeden z takich, którzy mają wgląd do prac w Khronos, pisał, że wersja OpenGL Next jego narzędzia jest gotowa, ale z wydaniem czeka na oficjalną prezentacje standardu, więc wcale bym się nie zdziwił gdyby przynajmniej wersja prowizoryczna była wydana już w okolicach GDC).

Edytowane 17 Grudzień 2014 przez Skoti

[Gość Marqin]

Jasne, że LGPL pozwala na zrobienie zamkniętej aplikacji mobilnej (zarówno w iOS jak i Android). Problemem jedynie jest to, że to systemy w które użytkownik nie bardzo może ingerować więc trzeba zrobić sztuczkę i możliwość podmienienia libki (wystarczy dać możliwość wczytania własnego libmono.so przykładowo z karty pamięci - w credits na koncu wystarczy umieścić info w jakim katalogu taki plik ma być) i licencja jest spełniona (LGPL nie zabrania nawet linkowania statycznego, a jedynie nakazuje umożliwić użytkownikowi zmienić na własną wersję kod tej libki). [\QUOTE]

 

Nikt profesjonalny by tak nie zrobił, bo zbytnio to ułatwia crackowanie i oszukiwanie, podmieniając libmono.so na niezaufane przez twórców gry. Rozmawiałem z Juanem o tym i powiedział, że woli poczekać na .NET 2015, który będzie na licencji MIT niż robić połowiczne rozwiązania, jeśli mieliby w ogóle dodać jako dodatkowy C#.

 

 

Z tego co czytałem to używali Lua na samym początku, później przeskoczyli na Pythona, Squirrel i dopiero stworzyli GDScript, a teraz mówisz, że zastanawiają się nad C# (słusznie ;p) - skaczą po językach nie bardzo chyba wiedząc czego chcą, zamiast usiąść na początku przedyskutować sprawę, to jakie są dostępne opcje i jeśli nie ma satysfakcjonującej zrobić własny spełniający oczekiwania (a tak robią wiele razy tą samą robotę).

Zaczeli od Lua, bo to znali najlepiej (a Twój ukochany C# wtedy jeszcze nie istniał), z CPythona musieli zrezygnować bo miał jakieś problemy, a o Squirrel nic nie wiem. GDScript jest w pełni wystarczający, a o C# myślą, bo dużo osób z community ich o to prosi.

[Skoti]

Nikt profesjonalny by tak nie zrobił, bo zbytnio to ułatwia crackowanie i oszukiwanie, podmieniając libmono.so na niezaufane przez twórców gry. Rozmawiałem z Juanem o tym i powiedział, że woli poczekać na .NET 2015, który będzie na licencji MIT niż robić połowiczne rozwiązania, jeśli mieliby w ogóle dodać jako dodatkowy C#.

No pewnie, że nikt profesjonalny tak nie robi (podałem tą możliwość, bo tu o profesjonaliźmie nie ma mowy) - profesjonaliści po prostu kupili by tą tania licencje i dołączyli zamkniętą binarkę do silnika.

 

Zaczeli od Lua, bo to znali najlepiej (a Twój ukochany C# wtedy jeszcze nie istniał), z CPythona musieli zrezygnować bo miał jakieś problemy, a o Squirrel nic nie wiem. GDScript jest w pełni wystarczający, a o C# myślą, bo dużo osób z community ich o to prosi.

Możliwe, że Lua znali najlepiej (jednak skoro tak to powinni sobie zdawać sprawę z jego wad i nawet nie myśleć o nim), z CPythonem podobnie jak z innymi znanymi mi implementacjami (poza cpythonem mam doświadczenie z jak i z BoostPython) mają kiepskie api wymagające dużo zachodu do prostych rzeczy. GDScript jest "wystarczający" - powiedziałbym nawet, że każdy z tych języków jest wystarczający, ale tu nie o wystarczaniu, a o wygodzie i wydajności (mówię o wydajności pracy ofc, a nie o szybkości działania, bo tu to dokonywali wyborów wręcz tragicznych, ale to jest mało znaczące).

 

PS. C# zdecydowanie nie jest przezemnie ukochany, a nawet w mojej czołówce, ale to dobry język (znacznie lepszy niż reszta, którą próbowali), jednak chciałem się czegoś dowiedzieć... to ile lat oni ten silnik tworzyli? Czyżby ponad 13 lat (.NET 1.0 z C# wydany został 13 lat temu).

Edytowane 27 Grudzień 2014 przez Skoti

[NV]

Skoti: Z czystej ciekawości abstrahując od silników, dlaczego CPython jest wg. Ciebie gorszy od np. C#? Czy może chodziło o zastosowania strikte gamedev ? W webdev python w połączeniu z django zyskuje na popularności i sprawdza się świetnie, podobnie node.js z MEAN.io. Przynajmniej na tej płaszczyźnie języki skryptowe radzą sobie nieźle. Sam trochę programowałem w javie/c# i podoba mi się "korporacyjność" i porządek w tych językach , ale jednocześnie zawsze miałem wrażenie że niesie to ze sobą pewien bagaż toporności. Jaki ty masz do tego stosunek? Jaki jest twój ulubiony język :) ?

[Skoti]

@NV: W webDev ogólnie jest słaby wybór. Tu popularne masz języki takie jak PHP i Python/Perl/Ruby ze względu na to, że łatwo o serwer ze wsparciem dla tych języków. Ja osobiście wybrałbym JSP lub ewentualnie ASP.NET... jednak o serwer z obsługą serwletów Javy (np. Tomcat) lub kodu zarządzanego .NET (windowsowe serwery z obsługą ASP.NET (nie mylić z ASP, bez net (rozszerzenie asp, a nie aspx))) jest znacznie trudniej i pewnie gdybym był zmuszony do wyboru mocno bym rozważył za i przeciw - przy stronie dla siebie poszukałbym serwera z JSP... przy kodzie na sprzedaż dla innych celowałbym w PHP/Python/Ruby ze względu na to, że praktycznie na każdym serwerze będzie działać, a to duża zaleta w tym przypadku, co powoduje, że opłaca się męczyć z tymi językami.

 

Z JSP i ASP.NET jest trochę jak z pisaniem programu dla PowerPC. O ile ten program jest dla Ciebie (lub pod zamówienie specjalne) i masz PowerPC (serwer JSP) to wszystko ok... ale jeżli celujesz w sprzedaż ogólną, a nie na zamówienie to x86 (języki dostępne praktycznie wszędzie przez prodte moduły czy zwykłe CGI) jest znacznie zyskowniejszym i większym rynkiem ;p.