aktualności

Mozilla prezentuje demo Epic Citadel uruchomione w Firefoksie – Unreal Engine 3 w przeglądarce

30
29 marca 2013, 09:30 Eryk Napierała

Era Flasha mija, i zdaje się, że niedługo minie minie bezpowrotnie, a jednak zapotrzebowanie na zaawansowane funkcje multimedialne przeglądarek pozostaje, a raczej staje się coraz większe. Z tego powodu twórcy silników renderujących strony prześcigają się w implementowaniu technologii znanych pod zbiorczą (i nie do końca poprawną) nazwą HTML5, w tym CSS3, WebGL oraz szybkich i dających dostęp do wielu różnych API silników JavaScript. Na tych technologiach mają opierać się gry przeglądarkowe następnej generacji, które skomplikowaniem będą znacznie odbiegać od prostych programików pisanych we Flashu. Na wirtualnej rozrywce skupiła się w ostatnim czasie Mozilla, fundacja zajmująca się rozwojem silnika Gecko, z którego korzysta między innymi przeglądarka Firefox oraz system operacyjny dla smartfonów Firefox OS. Na tegorocznej konferencji GDC zaprezentowano coś naprawdę godnego uwagi – silnik Unreal Engine 3 przeportowany na JavaScript. Za pokaz możliwości przeglądarki posłużyło demo Epic Citadel, kilka lat temu oszałamiające grafiką na iPadach i iPhoneach.

Przystosowanie Unreal Engine 3 do działania w przeglądarce zajęło ponoć ekipie Mozilli i Epic Games tylko cztery dni. Nie byłoby to możliwe bez kompilatora emscripten, umiejącego przetworzyć kod napisany w C++ na JavaScript. By wydajność silnika liczącego ponad milion linii kodu była zadowalająca, podczas konwersji użyto technologii asm.js, zaimplementowanej w najnowszych deweloperskich wersjach Gecko (a raczej silnika JavaScript Odin Monkey). Nazwa asm.js nie bez powodu kojarzy się z assemblerem, bo w istocie jest to język niskopoziomowy – przynajmniej mniej wysokopoziomowy niż standardowy JavaScript. Technologia ta pozwala na skorzystanie ze znacznie wydajniejszych, ale trudniejszego w wykorzystaniu mechanizmów, takich jak statyczne typowanie, wskaźniki czy operatory bitowe. Wersja emscripten z asm.js skompilowała kod Unreal Engine właśnie do takiego zoptymalizowanego JavaScriptu. Co ważne, taki kod uruchamia się w każdej przeglądarce zgodnej z powszechnie przyjętym standardem ECMAScript, ale cały swój potencjał ujawnia tylko w Firefoksie. Wzrost wydajności jest spory, bo kod skompilowany za pomocą asm.js może wykonywać się do 10 razy szybciej niż zwykły JavaScript (przy czym nadal obecny jest około 60% narzut w porównaniu do kodu natywnego uruchomionego na tej samej maszynie).

Z serwerów Mozilli można już pobrać eksperymentalne wersje przeglądarki zdolne do współpracy z asm.js (finalne wydanie jest planowane na czerwiec), jednak samego dema Epic Citadel nie da się na razie przetestować. Publicznie zostanie ono udostępnione dopiero za kilka tygodni, więc na razie trzeba zadowolić się nagraniem z serwisu YouTube. Jeśli wierzyć twórcom ognistego liska, prezentuje ono obecny stan zaawansowania prac na przeglądarkowym Unreal Engine 3.

Wydaniem webowych gier opartych na silniku Epic Games są zainteresowani tacy giganci branży jak Electronics Arts i Disney Interactive. Daje to dobre rokowania na przyszłość... o ile z technologii zaproponowanej przez Mozillę zechce skorzystać także Google, mające obecnie ponad 20% udziału w rynku przeglądarek (Microsoft ma niestety zbyt konserwatywne podejście do WebGL). Twórca Chrome od długiego czasu rozwija własny pomysł na zwiększenie wydajności aplikacji webowych – Native Client (NaCl), czyli API pozwalające uruchamiać w przeglądarce kod natywny skompilowany dla danej maszyny. Obydwa podejścia mają swoje wady i zalety, więc zwycięstwo osiągnie najpewniej to z większym wsparciem twórców gier, a może raczej większym zapleczem finansowym.

Gra w życie wykonana z użyciem NaCl

Warto się jeszcze zastanowić, czy potrzebę grania w zaawansowane tytuły w przeglądarkach widzą sami gracze? Można się spodziewać, że nie każdy zrozumie działanie tego rodzaju programów, a bez tego trudno o akceptację średniej jakości grafiki idącej w parze z wysokimi wymaganiami sprzętowymi. Nawet entuzjaści technologii webowych mogą nie chcieć na co dzień katować swoich maszyn grami mocno obciążającymi sprzęt tylko dlatego, że ktoś zechciał użyć do ich stworzenia JavaScript.

Czekając na cytadelę i można wypróbować inne aplikacje przedstawiające możliwości współczesnych przeglądarek: JavaScriptową wersję silnika fizyki Bullet, fenomenalnie wyglądące demo oparte na technologii Unigine, a także przeglądarkowy klon Quake III – BananaBread.

Źródła: CNet 1, 2

kretosZobacz profil
Poziom ostrzeżenia: 0%
kretos2013.03.29, 10:05
hmm, wymyślamy nowe mechanizmy po to, aby coś co działa bardzo dobrze, działało gorzej. Dodatkowo duże gry to setki MB, które trzeba będzie przepchnąć przed rozpoczęciem rozgrywki.
Więc dalej gry w przeglądarce będą raczej proste.
Więc po co?
Chyba tylko dla totalnej kontroli gracza. Gra jest za darmo tylko za przeciwników trzeba zapłacić:)
kwahooZobacz profil
Poziom ostrzeżenia: 0%
kwahoo2013.03.29, 10:22
kretos @ 2013.03.29 10:05  Post: 646357
hmm, wymyślamy nowe mechanizmy po to, aby coś co działa bardzo dobrze, działało gorzej.

Nie, wymyślamy po to by coś działało wszędzie. Już teraz mamy kilka/kilkanaście niekompatybilnych platform. A takie rozwiązania jak .Net/Mono czy Java nie są wydajniejsze o asm.js.
Inna sprawa, że nie ma żadnych przeciwwskazań żeby wszystko uruchamiać lokalnie. Część serwerowa nie jest potrzebna.
TelvasZobacz profil
Poziom ostrzeżenia: 0%
Telvas2013.03.29, 10:22
kretos @ 2013.03.29 10:05  Post: 646357
hmm, wymyślamy nowe mechanizmy po to, aby coś co działa bardzo dobrze, działało gorzej. Dodatkowo duże gry to setki MB, które trzeba będzie przepchnąć przed rozpoczęciem rozgrywki.
Więc dalej gry w przeglądarce będą raczej proste.
Więc po co?
Chyba tylko dla totalnej kontroli gracza. Gra jest za darmo tylko za przeciwników trzeba zapłacić:)

Od siebie dodam jeszcze tylko, że to także kwestia lenistwa (skąpstwa), bo zrobienie gry w gotowym frameworku, któremu bliżej do kreatora niż IDE, jest teoretycznie prostsze i wymaga mniej nakładów. Tylko że efekt końcowy często komplikuje wszystkim życie znacznie bardziej, niż gotowce i pośredni kod uproszczają, a i w trakcie prac rozwojowych okazuje się, że zaskakujaco dużo czasu i pracy trzeba poświęcić na obchodzenie ograniczeń i robienie protez uzdatniających to i owo do założeń projektu.
Żeby było jasne: nie krytykuję Unreal Engine, bo to świetny produkt. Krytykuję ścieżkę techniczną, którą podąża produkt przedstawiony w newsie.

kwahoo @ 2013.03.29 10:22  Post: 646365
kretos @ 2013.03.29 10:05  Post: 646357
hmm, wymyślamy nowe mechanizmy po to, aby coś co działa bardzo dobrze, działało gorzej.

Nie, wymyślamy po to by coś działało wszędzie. Już teraz mamy kilka/kilkanaście niekompatybilnych platform. A takie rozwiązania jak .Net/Mono czy Java nie są wydajniejsze o asm.js.
Inna sprawa, że nie ma żadnych przeciwwskazań żeby wszystko uruchamiać lokalnie. Część serwerowa nie jest potrzebna.

I uważasz, że przeglądarka i pluginy do niej są dobrą platformą do rozwiązywania takich problemów? :> Ja uważam, że powinno się kłaść nacisk na pisanie przenośnego (natywnego!) kodu i rozwijanie/wykorzystywanie wieloplatformowych bibliotek, jak choćby OpenGL. Dobrze napisany projekt można z jednego kodu kompilować na różne platformy (oczywiście stopień złożoności projektu komplikuje to proste uogólnienie). Owszem, wymaga to pewnego dodatkowego nakładu pracy. Ale jest to nowy kierunek rozwoju, nowy rynek, nowe zwyczaje kodowania - raz rozpoznana technika zostaje w firmie 'na zawsze'. Tylko oczywiście wymaga to na początku zmiany przyzwyczajeń... co bywa problematyczne, nawet w tak dynamicznej branży, jak IT ;p
Eryk PiastZobacz profil
Poziom ostrzeżenia: 0%
Autor publikacjiEryk Piast2013.03.29, 10:38
@kretos, to trochę tak wygląda... Ale trzeba spojrzeć z szerszej perspektywy - HTML5 był potrzebny firmom rozwijającym przeglądarki, by mogły się one uniezależnić od własnościowego kodu Adobe. By na przykład Google mogło optymalizować ten 'silnik multimediów' pod Androida, a Mozilla pod Firefox OS, a jednocześnie żeby szybciej wykrywać bugi.

A czy HTML5 jest potrzebny użytkownikom? Zawsze głównym argumentem za jest niewygoda konieczności instalacji wtyczek, ale w praktyce to przecież nie ma znaczenia. Mechanizmy asystowania są już tak dopracowane, że wystarczy kilka kliknięć i przejście przez naprawdę proste kreatory. A chrome ma Flasha wbudowanego...

Z perspektywy zwykłego 'przeglądacza' stron Flash jest lepszy, bo działa szybciej i mniej obciąża procka. Trzeba jednak pamiętać, że HTML5 to młodsza technologia. I nie chodzi mi o to, żeby pobłażać, ale dostrzegać potencjał. To są otwarte i ustandaryzowane technologie, które mogą rozwinąć się taki sposób, w jaki być może nigdy nie dałoby się rozwinąć Flasha. Bo mają możliwość głębokiej integracji z innymi częściami przeglądarki, mają dostęp do wielu powszechnie dostępnych API, z których mogą korzystać nie tylko browsery, ale na przykład takie silniki aplikacji jak na przykład w Firefox OS czy WinRT. Myślę, że ostatecznie wszyscy skorzystają na tym przejściu, ale niekoniecznie teraz, a nawet niekoniecznie za rok lub dwa. Jeszcze przez jakiś czas Flash będzie wydawać się lepszy w codziennych zastosowaniach, ale w końcu odejdzie do lamusa.
kwahooZobacz profil
Poziom ostrzeżenia: 0%
kwahoo2013.03.29, 11:33
Telvas @ 2013.03.29 10:22  Post: 646366

I uważasz, że przeglądarka i pluginy do niej są dobrą platformą do rozwiązywania takich problemów? :> Ja uważam, że powinno się kłaść nacisk na pisanie przenośnego (natywnego!) kodu i rozwijanie/wykorzystywanie wieloplatformowych bibliotek, jak choćby OpenGL. Dobrze napisany projekt można z jednego kodu kompilować na różne platformy (oczywiście stopień złożoności projektu komplikuje to proste uogólnienie). Owszem, wymaga to pewnego dodatkowego nakładu pracy.

Jakich pluginów? asm.js nie wykracza nigdzie poza standardowy JavaScript.

Przenośny kod nie jest receptą na wszystko. Dalej musisz wiele razy kompilować, dystrybuować, debuggować. A za parę lat będziesz chciał uruchomić swój program i nie będziesz mógł, bo nie będzie już np. Windows i x86 a będzie BSD i MIPS (przykład całkowicie przypadkowy).
Tu chodzi o jakąś sprytną warstwę abstrakcji opartą o LLVM. Wydajną i całkowicie niezależną od sprzętu.

Po co takie wynalazki jak Unity Web Player czy launcher Square Enix? I nie chodzi tu tylko o gry, ale też o takie rzeczy jak Netflix. Na co robić kilkanaście różnych wersji?
I czemu mam nie móc uruchomić apki z Androida na iOS-ie albo Windowsie?


TelvasZobacz profil
Poziom ostrzeżenia: 0%
Telvas2013.03.29, 12:14
kwahoo @ 2013.03.29 11:33  Post: 646383
Telvas @ 2013.03.29 10:22  Post: 646366

I uważasz, że przeglądarka i pluginy do niej są dobrą platformą do rozwiązywania takich problemów? :> Ja uważam, że powinno się kłaść nacisk na pisanie przenośnego (natywnego!) kodu i rozwijanie/wykorzystywanie wieloplatformowych bibliotek, jak choćby OpenGL. Dobrze napisany projekt można z jednego kodu kompilować na różne platformy (oczywiście stopień złożoności projektu komplikuje to proste uogólnienie). Owszem, wymaga to pewnego dodatkowego nakładu pracy.

Jakich pluginów? asm.js nie wykracza nigdzie poza standardowy JavaScript.

Przenośny kod nie jest receptą na wszystko. Dalej musisz wiele razy kompilować, dystrybuować, debuggować. A za parę lat będziesz chciał uruchomić swój program i nie będziesz mógł, bo nie będzie już np. Windows i x86 a będzie BSD i MIPS (przykład całkowicie przypadkowy).
Tu chodzi o jakąś sprytną warstwę abstrakcji opartą o LLVM. Wydajną i całkowicie niezależną od sprzętu.

Po co takie wynalazki jak Unity Web Player czy launcher Square Enix? I nie chodzi tu tylko o gry, ale też o takie rzeczy jak Netflix. Na co robić kilkanaście różnych wersji?
I czemu mam nie móc uruchomić apki z Androida na iOS-ie albo Windowsie?



Skoro mamy tworzyć kolejną 'sprytną warstwę abstrakcji' żeby (z racji przenośności i możliwości odpalania wszystkiego) życie aplikacji mogło się w niej toczyć, to może od razu przesiądźmy się wszyscy na jednego OS-a z paroma shellami do wyboru i tyle. Zamiast 10 warstw API/wirutalizacji/emulacji/etc jedna na drugiej będziemy mieli jedno API systemowe i problem z głowy.
Różnice w platformach nie powstały bez powodu. Po to platformy są różne, żeby spełniały określone wymagania. Niestety nie tylko sprzętowe czy funkcjonalne, ale też biznesowe, prawne czy marketingowo-widzimisiowe. To jest taka sama sytuacja jak ta:
http://xkcd.com/927/
Można mnożyć warstwy i platformy abstrakcji/emulacji/wirtualizacji. Było X, ktoś stwierdził, że przecież jest za dużo pracy z przenośnością, za duży narzut wydajności, zbyt chaotyczne API, etc. etc. etc, powstał nowy standard i teraz jest ich X+1.
Wystarczy zobaczyć, ile czasu, pracy i nwerwów kosztowała ludzi Java. Owszem, teraz po wielu latach mamy nawet sprzętowe wykonywanie kodu pośredniego na dedykowanych procach i wszelkiej maści akcleracje, ale wystarczyło parę lat od powstanai Javy, żeby lenistwo programistów ('bo ta Java taka łatwa i fajna i szybko się pisze i tak mało błędów wypluwa' ) doprowadziło do takich absurdów, że soft korporacyjny, działający na jednolitych platformach (nie ma problemu przenośności) pisze się w Javie. Bo przeciętny koder Javy jest tańszy od przeciętnego C++iarza czy nawet .NET-owca. O absurdach pokroju że Matlab jest napisany w Javie i zamula nawet na szybkich kompach jak Crysis odpalony na Netboku, nawet nie wspomnę ;)

A poza tym to totalnie nie rozumiem tego przenoszenia wszystkiego w przeglądarkę. Jeszcze trochę i przeglądarka stanie się domyślnym shellem systemu operacyjnego... Jaki to ma sens? Jak wpakujemy tam wszystko, to wrócimy do punktu wyjścia, tylko shell będzie się nazywał FirefoxOS (czy jak mu tam), zamiast Explorer czy Gnome.

P.S. A jeśli coś ma działać wydajnie na dowolnym systemie docelowym, to wszystkie te rozwiązania pośrednie i tak sprowadzają się do kompilacji czegoś pośredniego na postać natywną dla systemu docelowego... Czyli wychodzi na to samo, co przełącznik targetu w kompilacji projektu - tylko ze się przeważnie dzieje po stronie klienta. Sytuacja ta jasno pokazuje, że problemem nie jest techniczny stopień trudności przy rekompilacji na różne platformy, ale fakt, że developerzy chcą, żeby ktoś ich to za nich robił. Na prawdę tworzenie i dystrybucja wieloplatformowego kodu nie jest tak straszna, jak ją malują. A zachowując nad nią kontrolę mamy dużo większe możliwości i panowanie nad zachowaniem aplikacji.
Oczywiście często przetwarzając kod pośredni (skompilowany, bez jawnego źródła) na natywny można zastosować dodatkowe optymalizacje przed uruchomieniem, a kompilacja z jednolitych źródeł też często nie wchodzi w grę (soft zamkniętoźródłowy), ale znów robiąc soft na pojedyncza platformę tez nikt się tym nie przejmuje (i jakoś nigdy nie przejmował ;) ).
ext73Zobacz profil
Poziom ostrzeżenia: 0%
ext732013.03.29, 12:21
Widzę, że do kompilacji używaj tez Clanga ... ale słabiutko tylko z flagą -O2 :P
kwahooZobacz profil
Poziom ostrzeżenia: 0%
kwahoo2013.03.29, 12:59
Telvas @ 2013.03.29 12:14  Post: 646390

A poza tym to totalnie nie rozumiem tego przenoszenia wszystkiego w przeglądarkę. Jeszcze trochę i przeglądarka stanie się domyślnym shellem systemu operacyjnego... Jaki to ma sens? Jak wpakujemy tam wszystko, to wrócimy do punktu wyjścia, tylko shell będzie się nazywał FirefoxOS (czy jak mu tam), zamiast Explorer czy Gnome.



Minimalizm. System ma tylko interpretować HTML5+JS.
A nie jak teraz, tu Qt, tam GTK, tu GDI, tam WPF, tu Python, tam Java, Flash, apki natywne i milion innych dziadostw nad których aktualizacjami i bezpieczeństwem nikt nie panuje.
fajny RafałekZobacz profil
Poziom ostrzeżenia: 0%
fajny Rafałek2013.03.29, 13:38
-1#9
A poza tym to totalnie nie rozumiem tego przenoszenia wszystkiego w przeglądarkę. Jeszcze trochę i przeglądarka stanie się domyślnym shellem systemu operacyjnego... Jaki to ma sens? Jak wpakujemy tam wszystko, to wrócimy do punktu wyjścia, tylko shell będzie się nazywał FirefoxOS (czy jak mu tam), zamiast Explorer czy Gnome.


No IE akurat jest dość mocno powiązany z systemem operacyjnym i tak było od dłuższego czasu.
WibowitZobacz profil
Poziom ostrzeżenia: 0%
Wibowit2013.03.29, 13:49
Bo przeciętny koder Javy jest tańszy od przeciętnego C++iarza czy nawet .NET-owca.

ZTCW to sytuacja jest dokładnie odwrotna. Średnio najwięcej zarabiają Javowcy, .NETowcy nieco mniej, a na samym końcu są C++owcy.

Ile masz komercyjnego doświadczenia jako programista (i w czym)?
Funkcja komentowania została wyłączona. Do dyskusji zapraszamy na forum.
1