Unreal Engine 3 w przeglądarce Firefox

16
1890
Unreal Engine
Unreal Engine

Deweloperzy Mozilli przedstawili działającą wersję silnika Unreal Engine 3 w przeglądarce internetowej. Udało się to zrobić, dzięki ostatnio dodanemu modułowi optymalizacyjnemu asm.jsOdinMonkey do rozwojowej wersji Firefox Nightly. Chciano sprawdzić jego możliwości i w tym celu skontaktowano się z deweloperami Epic Games, którzy wyrazili chęć pomocy. Cała praca zajęła tylko 4 dni, a użyto przy niej WebGL, HTML5, JavaScript oraz Emscripten, który już wcześniej wykorzystano przy Unigine Sanctuary i BananaBread.

Asm.js jest swojego rodzaju podzbiorem JavaScript, który wykorzystuje bajtkod LLVM, stworzony podczas kompilacji kodu C i C++, z użyciem kompilatorów gcc-llvm i clang, a następnie rekompiluje bajtkod do JavaScriptu. Tak powstały kod można dzięki specjalnemu silnikowi OdinMonkey, uruchomić z szybkością bliską natywnej, tj. narzutem rzędu 60 procent.

Dzięki tej technologii będzie możliwe uruchamiania jakiejkolwiek gry 3D, napisanej w WebGL, HTML5 i JavaScript na dowolnym systemie operacyjnym.

ŹRÓDŁOblog.mozilla.org
Poprzedni artykułJądra Linux 3.0.71, 3.4.38 i 3.8.5
Następny artykułZFS 0.6.1 – gotowy do wdrażania na większą skalę
Michał Olber
Interesuję się głównie sprzętem i działaniem jego pod systemami GNU/Linux. Testuję różne dystrybucje i robię recenzje. Interesuję się działaniem sprzętu pod Linuksem, dzięki czemu wiem, jaki zestaw komputerowy wybierać :)

16 KOMENTARZE

    • Asm.js ma być alternatywą dla natywnych aplikacji w c++ pisanych pod ekosystem Chrome

    • Ale jest dostępny bezpośrednio dla każdej strony?
      Jeśli tak to takie samo psucie standardów jak przedrostek webkit i mozRequestAnimationFrame.

    • No nie, bo asm.js nie wychodzi nigdzie poza standard. Odwrotnie, zawęża go. Tu jest największa zaleta (w stosunku do np. NaCl) – 100% zgodność wsteczna z obecnymi silnikami Javascript.

    • O dziękuję za to wyjaśnienie :)
      Byłem przekonany, że oni tam dodają prefixy z typami ;-)

    • Native Client też nie wychodzi poza standard nigdzie (a w tak naprawdę, to to rozwiązanie powyżej wychodzi poza standard, bo WebGL nie jest częścią standardu HTML5 (już pomijam to, że HTML5 jeszcze oficjalnie nie istnieje – istnieje dopiero szkic tego standardu i ciągle się zmienia)) – tylko o zupełnie inny standard chodzi. Native Client to natywny plugin Pepper i nie ma on nic wspólnego z JS.
      To 2 zupełnie odmienne rozwiązania. Tu prezentują po prostu nowy JIT który ma się pojawić w Firefox 22 czyli OdinMonkey którego elementem jest asm.js, robiony aby dorównać wydajności Google V8, który sobie od dawna tu radzi całkiem dobrze i w testach WebGL, czego nie można powiedzieć o Firefox (dużo niższy FPS). Tu jest po prostu rozwój silnika JS – nic mniej nic więcej… czyli konkurencja dla V8 i innych silników.

      Nie jest to alternatywa dla NaCl. NaCL to taka alternatywa dla NPAPI (Netscape Plugin API) używanego przez Mozillę, czy ActiveX Microsoftu. Z tym, że korzysta się z PPAPI (Pepper Plugin API), który dodaje możliwość integracji i współdziałania z kodem JS (czego nie daje stare api Netscape lub ActiveX) i w przeciwieństwie do NPAPI nie musi byś osobny plugin dla każdego systemu, a jeden do wszystkich (.nexe zawiera natywne wersje bibliotek dla Linux/Windows/MacOS i nie trzeba osobnych plików do osobnych platform robić).

      Ogólnie NaCL to zupełnie inny kaliber – to bezkompromisowa wydajność natywnego kodu. To atuty natywnych języków względem JS (dużo lepsze narzędzia, gotowe biblioteki…). To dostęp do pełnych możliwości kart graficznych (pełny OpenGL).

      Jeśli gra ma być prosta, nie wymagać wiele obliczeń jak fizyka, nie ma oszałamiać grafiką to WebGL jest opcją, w przeciwnym wypadku pozostają NaCL, ActiveX i Netscape Plugins, z czego NaCl jest najfajniejszą opcją.

    • Co do WebGL to chodzą plotki, że w IE11 są już widoczne nazwy funkcji to obsługujące, ale nie działają. Pytanie tylko, czy to implementują, czy chcą tylko żeby strony nie sypały za dużo błędami (co powoduje dyskomfort i szukanie rozwiązań, które działają).
      Ja tam jestem dobrej myśli.

    • Co do WebGL to i tak nie będzie on częścią standardu – standardy internetowe ustala W3C, a WebGL jest rozszerzeniem tego standardu przez grupę Khronos. Swoją drogą to, że w wycieku jest nie oznacza, że będzie on w oficjalnym wydaniu (bycie gotowym do wsparcia czegoś nie oznacza, jeszcze, że to coś się wspierać będzie zanim nie będzie to już zupełnie konieczne).

      Co do samego WebGL to mam mieszane uczucia czy jest sens go teraz wprowadzać. Opiera się on na 6cio letnim API OpenGL ES, który jest bardzo ograniczający. Brak multirender target, brak tekstur zmiennoprzecinkowych, brak instancingu, brak occlusion queries, brak transform feedback, brak sensownych formatów kompresji tekstur, brak wielu innych rzeczy, a o "nowinkach" jak shadery geometrii, tesselacji czy obliczeniowe już szkoda wspominać. W sumie bardziej by mnie ucieszyła wiadomość wydania WebGL 2.0 opartego o OpenGL ES 3.0, bo już nie byłoby to tak wielkim ograniczeniem (ofc dalej zapomnij o tesselacji, shaderach obliczeniowych czy geometrii) – dziś byłoby sensowne już iść w tym kierunku (desktopy już od bardzo starych kart wszystko to obsługują co wymaga GLES3, a i mobilne urządzenia już mają GPU, które wspiera ten standard… a zanim by wszedł do przeglądarek i zanim powstałoby na tym coś wartego uwagi, już wszystkie mobilne by miały).

    • NaCl to nie jest inny kaliber, bo już teraz asm.js pozwala osiągnąć wydajność pierwszych implementacji NaCl. I Odinminkey to już nie JIT a AOT, statyczne typowanie itd. Daje to wydajność ~10 razy wyższą niż V8.
      Konkurencją dla asm.js byłoby PNaCl, ale wygląda na to, że Google ma z nim jakieś potworne problemy. Zapowiadają od lat, a efektu nie widać.

    • Skąd wziąłęś 10 razy większą wydajność? Na stronach Asm.js piszą o wydajności 60% mniejszej niz natywny kod, czyli porównywalnie do javy. JIT jest tam dalej statyczne typowanie nie ma nic wspólnego z tym czy jest JIT. Głowną zaletą rozwiązania Mozilli jest fakt, że będzie to działać w Firefox niezależnie od systemu operacyjnego.

    • To zupełnie inny kaliber, bo to zupełnie coś innego i nawet tego się porównywać nie da.
      Wydajność NaCl nie zależy od implementacji w przeglądarce i jest taka jaka jest – natywny kod wykonywany przez NaCl nie ma nic wspólnego z przeglądarką i jest to zupełnie natywny kod jak gra/program na komputerze.
      Jeśli jest statycznie, silnie typowane to po pierwsze nie jest kompatybilne z JavaScript.

      PNaCl nie jest konkurencją tu, ani dla silników JS, ani dla natywnych rozwiązań – to konkurencja dla apletów Javy (też kod bajtowy, też dostęp do rzeczy niedostępnych z JS, jak pełny OpenGL itp.).

      Co do wydajności to chyba nie powołujesz się na "testy" mozilli, które pokazują, że SpiderMonkey jest wydajniejszy, a w praktyce jest znacznie wolniejszy. Tzn rozumiem, że wykorzystali kod wygenerowany przez asm.js do testów przeglądarek – jeśli tak to nie dziwi, że zoptymalizowany jest pod przeglądarki mozilli (tak jak Google Web Toolkit dziwnym trafem generuje z Javy kod JS kilkukrotnie szybszy w V8 niż w SpiderMonkey).

      Nie podchodziłbym też tak huraoptymistycznie do tego, że wydajność będzie bliska natywnej. Ba, to co podaje Mozilla jest wręcz komiczne – podaje, że w jej testach kod JS w obecnych silnikach SpiderMonkey i V8 jest wolniejszy o 5-6x… podczas gdy w testach wypada od około 100x wolniej od natywnego do… i tu nie ma granicy, bo JS potrafi być, bardzo, bardzo, bardzo wolny w porównaniu z natywnym kodem. Tzn jestem w stanie sobie wyobrazić prosty test w którym silniki JS będą tylko 1.2x wolniejsze od kodu natywnego, ale nic taki test nie mówi o realnych zastosowaniach. W praktyce można będzie się cieszyć jak asm.js będzie tylko 30x wolniejszy od natywnego kodu w NaCl.

ZOSTAW ODPOWIEDŹ

Proszę wpisać swój komentarz!
Proszę podać swoje imię tutaj