Autor Wątek: Disney kupił rocket engine  (Przeczytany 4788 razy)

Offline MichalBe

  • Użytkownik
    • MichalBe's Github

# Marzec 03, 2011, 14:38:56
Z tego co pamiętam to jakiś czas temu Kos twierdził że robienie silnika uzywajac DOMowych elementów to najgorsze rozwiązanie ever i nikt nigdy nie bedzie chciał tego używać a co dopiero płacić.
Widocznie jednak Disney miał niepotrzebne 20 milionów dolarów na zbyciu żeby taki shit kupić:)

http://eu.techcrunch.com/2011/03/03/disney-acquires-gaming-engine-startup-to-build-html5-games-outside-of-app-stores/

Offline Mr. Spam

  • Miłośnik przetworów mięsnych

Offline s0d

  • Użytkownik

# Marzec 03, 2011, 15:11:19
nieźle, niby fajnei że bez plugin'ów śmiga tylko obczajcie jak to kichowato chodzi na tych device'ach ;p
Założę się że ta sama gra we Flash'u chodziłaby płynniej ;)

Offline Kamma

  • Użytkownik

# Marzec 03, 2011, 16:34:42
Jeżeli rendering canvasu będzie liczony przez GPU we wszystkich nowych wersjach przeglądarek tj. akceleracja będzie powszechna ( 80-90% użytkowników internetu ), to wtedy HTML + CSS + JavaScript będą mogły konkurować z Flashem, ale tylko pod względem wydajności. Przecież jedną z największych zalet flasha są narzędzia - łatwość / szybkość tworzenia, edycji, wygoda, ergonomia pracy ( współpraca z takim kombajnem jak chociażby ScaleForm ).

Silnik Rocket Pack jest ciekawy, jednak nic dynamicznego na nim się nie stworzy. Wcześniej oglądałem jego prezentację i omówienie technologii na Google Tech Talks (YouTube) - fajna sprawa.
« Ostatnia zmiana: Marzec 03, 2011, 18:00:56 wysłana przez Kamma »

Offline Esidar

  • Użytkownik

# Marzec 03, 2011, 17:04:32
Jeżeli rendering canvasu będzie liczony przez GPU we wszystkich nowych wersjach przeglądarek tj. akceleracja będzie powszechna ( 80-90% użytkowników internetu ), to wtedy HTML + CSS + JavaScript będą mogły konkurować z Flashem, ale tylko pod względem wydajności.
"Problem" w tym że JS jest nadal powolna, a GPU 3D będzie w najnowszym flashu. Dla przykładu, jak powolna jest JS http://code.google.com/p/quake2-gwt-port/ . Mimo że na filmiku dumnie się chwalą "Up to 60fps", to widać wyraźnie że przy 2 wybuchach i 3 postaciach wydajność mocno siada a wystrzały z broni są coraz wolniejsze. To typowe zachowanie dla CPU bound.
Dla przykładu jak szybki jest AS bez GPU http://www.mike65.ukfsn.org/main/uploads/files/QuakeFlash.swf

Google będzie parło na HTML5 bo póki co nie oferują niczego innego. Z HTML5 jest ten problem, że to wciąż tylko HTML czyli rządzi się tymi samymi prawami co dokumenty www. Osobiście wolałbym pójście w innym kierunku czyli strony całkowicie zrobione w Flash/Silverlight. W tej chwili nie jest to atrakcyjne z powodu wydajności, ale zarówno Flash jak i Silverlight uzyskają wkrótce akcelerację GPU więc zrobienie identycznej strony np. tvn24.pl we Flash, która wygląda tak samo, ale ma własny silnik wyświetlania (mniej zajmuje, szybciej się ściąga itd) ma większy sens niż trzymanie się HTML "po wsze czasy".

Offline lukasyno

  • Użytkownik

# Marzec 03, 2011, 17:23:43
to ja troche sprostuje Esidar'a
1. ten link ktory dales to nie jest AS, tylko kod c++ albo c, kompilowany do kodu maszyny wirtualnej flasha...
2. GPU we flashu już jest http://labs.adobe.com/technologies/flash/molehill/
3. http://www.youtube.com/watch?v=tgwi0lWgX8w w ta gre można juz grac, (tylko trzeba zaisntalowac nowego FP) http://alternativaplatform.com/en/demos/maxracer/ gierka(demo w sumie) naprawdę robi wrażenie..
4. jejku musi byc HTML5 JS itd, nie nudzi was juz w kolko porównywanie tego do flasha(i nie oszukujmy sie porównują zazwyczaj ci którzy najmniej wiedza :))? kazdy robi w czym mu pasuje, w czymś znajdzie klienta itd, a tego można znaleźć na flasha jak i na JS / Html5... ja nie widzę żadnej kolizji.

Offline skoti

  • Użytkownik

# Marzec 03, 2011, 18:53:19
@Esidar: Wydajność JS nie jest taka zła jak ją malujesz, a to, że Flash/Silverlight pozwolą na to na co Java pozwala od bardzo dawna nie wiele tu zmienia - twórcy przeglądarek zapowiadają kompilowanie kodu JS do kodu natywnego, a nawet wykonywanie kodu JS na GPU za pomocą OpenCL/Dx Compute.
Ja tu widzę zupełnie inny problem - JS i WebGL oznacza w praktyce zmuszenie do otwartego kodu, dlatego sądzę, że WebGL będzie stosowany w internecie raczej do prezentacji telefonów/samochodów i innych takich zadań (gdzie kod nie jest produktem, a sposobem atrakcyjnej prezentacji produktu), ale nie widzę zastosowania w grach i innych tego typu zadaniach dlatego tu będą wykorzystywane Flash/Silverlight/Java (a nie z powodu, tego, że to HTML5 Canvas który jest akcelerowany w pełni przez GPU czy językowi JS któremu twórcy przeglądarek zapowiadają kompilatory i wykonywanie obliczeń na GPU).

PS. Co do tego, że Google będzdie parło na HTML bo nie mają niczego innego - mają swoje Google O3D, a mimo to je olali dla standardu WebGL.

Offline Krzysiek K.

  • Redaktor
    • DevKK.net

# Marzec 03, 2011, 19:16:53
Cytuj
JS i WebGL oznacza w praktyce zmuszenie do otwartego kodu
Wszystko jest kwestią dobrego obfuscatora.

Offline Dab

  • Redaktor
    • blog

# Marzec 03, 2011, 19:52:18
Zaraz, zaraz, czy HTML to czasem nie jest język do opisywania prostych dokumentów tekstowych? Smuci mnie ten feature creep tych całych HTMLi, JSów i innych pierdół. Chociażby dlatego że nie ma już na chwilę obecną szansy stworzenia jakiejś nowej alternatywnej przeglądarki od zera, jeżeli miałaby być kompatybilna z wszystkimi "cool" ficzerami.

Offline K'Aviash

  • Użytkownik

# Marzec 03, 2011, 20:15:16
Chociażby dlatego że nie ma już na chwilę obecną szansy stworzenia jakiejś nowej alternatywnej przeglądarki od zera, jeżeli miałaby być kompatybilna z wszystkimi "cool" ficzerami.
Cóż, czas indywidualistów niestety dobiega końca

Offline MichalBe

  • Użytkownik
    • MichalBe's Github

# Marzec 03, 2011, 23:10:58
Zaraz, zaraz, czy HTML to czasem nie jest język do opisywania prostych dokumentów tekstowych?

Nie, nie jest, był na początku lat 90.

Offline vashpan

  • Użytkownik
    • Strona

# Marzec 03, 2011, 23:41:08
@Esidar: Wydajność JS nie jest taka zła jak ją malujesz, a to, że Flash/Silverlight pozwolą na to na co Java pozwala od bardzo dawna nie wiele tu zmienia - twórcy przeglądarek zapowiadają kompilowanie kodu JS do kodu natywnego, a nawet wykonywanie kodu JS na GPU za pomocą OpenCL/Dx Compute.
Ja tu widzę zupełnie inny problem - JS i WebGL oznacza w praktyce zmuszenie do otwartego kodu, dlatego sądzę, że WebGL będzie stosowany w internecie raczej do prezentacji telefonów/samochodów i innych takich zadań (gdzie kod nie jest produktem, a sposobem atrakcyjnej prezentacji produktu), ale nie widzę zastosowania w grach i innych tego typu zadaniach dlatego tu będą wykorzystywane Flash/Silverlight/Java (a nie z powodu, tego, że to HTML5 Canvas który jest akcelerowany w pełni przez GPU czy językowi JS któremu twórcy przeglądarek zapowiadają kompilatory i wykonywanie obliczeń na GPU).

PS. Co do tego, że Google będzdie parło na HTML bo nie mają niczego innego - mają swoje Google O3D, a mimo to je olali dla standardu WebGL.

Jak mialoby wygladac wykonywanie kodu JS na GPU ? Bo ja jakos nie widze tego... Co do JIT, to przeciez wiekszosc przegladarek juz to ma. Na pewno Chrome od samego poczatku... Ale kompilowanie do kodu maszynowego ? W sensie statycznie ? Jak masz jakies info, to zapodaj linkami bo to tak w ogole ciekawy temat :)

Zas co do przyszlosci gamedevu pod przegladarkami... Warto zwrocic uwage na jeszcze jedna technologie Google'a: Native Client, ktora powoli bedzie zmierzala do stabilnego Chrome. W skrocie jest to sandbox umozliwiajacy odpalanie w przegladarce calkowicie natywnego kodu i korzystanie z calkowicie natywnych bibliotek, etc, itd... A takze modyfikowanie DOM'em z poziomu C++ Niby taki stary ActiveX, ale ma byc wieloplatformowy i lepszy ;) Google pracuje nad tym ostro zapewne z mysla o Chrome OS, wowczas ten system zaczal by miec sens. Nie mowiac juz o potencjale tworzenia gier ;)

http://code.google.com/p/nativeclient/

Offline Dab

  • Redaktor
    • blog

# Marzec 04, 2011, 02:52:10
Zaraz, zaraz, czy HTML to czasem nie jest język do opisywania prostych dokumentów tekstowych?

Nie, nie jest, był na początku lat 90.

A szkoda.

Cytuj
Jak mialoby wygladac wykonywanie kodu JS na GPU

Dokładnie, ja też nie mam pojęcia ocb. Ale pewnie po przejściu jakiejś informacji przez 4 portale i 3 wersje językowe wyszedł komuś JS na GPU :)

Offline skoti

  • Użytkownik

# Marzec 04, 2011, 14:31:40
Jak mialoby wygladac wykonywanie kodu JS na GPU ? Bo ja jakos nie widze tego... Co do JIT, to przeciez wiekszosc przegladarek juz to ma. Na pewno Chrome od samego poczatku... Ale kompilowanie do kodu maszynowego ? W sensie statycznie ? Jak masz jakies info, to zapodaj linkami bo to tak w ogole ciekawy temat :)
Mozilla mówiła o JS na GPU jako optymalizacji kodu - wektoryzują go (jak kompilatory C++ dla SSE) i generują kernele OpenCL. Chociaż raczej teraz pomysł upadnie bo już nie ma sensu - Khronos zapowiedział WebCL więc obliczenia na GPU i kernele programiści będą mogli sami pisać.
Co do JIT to przeglądarki mają, ale Google zapowiadał, że przestanie kompilować tylko to co zamierza uruchomić, a zaraz po ściągnięciu kodu JS zostanie cały skompilowany do natywnego kodu, a wywołania funkcji z HTML będą szły bezpośrednio do natywnego kodu (ma nie być już tak, że dopiero jak jakieś zdarzenie nastąpi to fragment kodu jest kompilowany i uruchamiany).

Offline nembutal

  • Użytkownik

# Marzec 04, 2011, 15:05:48
Jakie są obiektywne korzyści dla użytkowników i programistów z pisania gier webowych w HTML5?

Offline skoti

  • Użytkownik

# Marzec 04, 2011, 15:53:30
Jakie są obiektywne korzyści dla użytkowników i programistów z pisania gier webowych w HTML5?
Z samego HTML5 żadne (do HTML5 który jest tylko opisem stron trzeba dodać JavaScript, CSS, WebGL, WebCL, itd.). HTML5 po prostu daje elementy jak Canvas które pozwalają innym technologiom operować na nich. Ale jedyne plusy jakie tak naprawdę istnieją to wieloplatformowość (może działać na każdym systemie i urządzeniu - zarówno komputerach jak i tabletach/telefonach - a iPhone/iPad nie ma możliwości użycia Flash/Silverlight, a to bardzo popularne urządzenia do przeglądania sieci - tablety/telefony oparte na Androidzie będą obsługiwać Flash, ale SL już nie - WebGL za to będą obsługiwać z pewnością), otwartość (nie jest zależne od jednej firmy) i brak konieczności instalowania wtyczek w przeglądarkach (są to bardzo ważne kryteria np. dla takich zastosowań jak strona firmy motoryzacyjnej prezentująca model auta w 3d - nie jest ważne jak - ważne, że działa wszędzie).
« Ostatnia zmiana: Marzec 04, 2011, 20:52:25 wysłana przez Netrix »