Doom w JavaScripcie

31 maja 2011

Niedowiarkom nie dającym szans duetowi HTML5 + CSS + JavaScript w porównaniu do Flasha czy natywnych aplikacji zapewne opadną szczęki, ale Doom został właśnie przeportowany do JavaScriptu. I działa nie gorzej niż w DOS-ie na Pentium I 75Mhz 🙂

Gra działa najlepiej w przeglądarce Firefox (wymagana jest najnowsza stabilna wersja).

Po tym jak id Software otworzyło kod źródłowy swojego szlagieru sprzed lat, Doom został przeportowany na wiele platform i do wielu języków programowania. Port JavaScriptowy był możliwy dzięki projektowi Javascript backend for LLVM, a ściągnąć go możecie tu: Doom w JavaScript (źródła)

PODOBNE WPISY:

żadnych reklam, sama wiedza.

Zarejestruj się na BEZPŁATNY NEWSLETTER i raz w tygodniu otrzymuj najważniejsze wiadmości
ze świata IT, nowych technologii i kryptowalut.

Bez reklam.

Zarejestruj się za darmo

Technologie

63 odpowiedzi na „Doom w JavaScripcie”

Cobra

1 czerwca 2011

Długo nie pograłem: http://6g6.eu/sih-doom-failure

Odpowiedz
Wizard

1 czerwca 2011

"I działa nie gorzej niż w DOS-ie na Pentium I 75Mhz" – na core i5, a przeglądarka wcina w tym czasie 350MB ramu? To jest dopiero rozwój. Czekam na port Turbo Pascala.

Odpowiedz
1. Kwant
  
  1 czerwca 2011
  
  To jest demo technologiczne, pokazuje że język skryptowy (interpretowany) na współczesnym sprzęcie ma porównywalną wydajność co asembler na sprzęcie sprzed 10-15 lat.
  
  Dlaczego warto? bo wirtualizacjia, wirtualizacja, wirtualizacja… (czytaj: bezpieczeństwo+przenośność). Nie wszystko warto ,,przenosić'' ale DOOM jest akurat dość powszechnie przenoszony, nawet port na kalkulator gdzieś widziałem 🙂
  
  A poza tym to marudzisz… Uruchamia się szybciej niż na PI 75 MHz no i komputer z PI 75 MHz był w swoim czasie droższy niż współczesny i5 😉
  
  Odpowiedz
  1. Speaktrap
    
    1 czerwca 2011
    
    Doom w assemblerze? Bardzo ciekawe.
    
    Odpowiedz
    1. _asd
      
      2 czerwca 2011
      
      w Doom 3 transformacje kości w modelach 3d są napisane w asemblerze.
      
      Odpowiedz
  2. dnkt@o2.pl
    
    2 czerwca 2011
    
    > Dlaczego warto? bo wirtualizacjia, wirtualizacja, wirtualizacja… (czytaj: bezpieczeństwo+przenośność)
    
    To nie powinien być argument. Dla mnie kompilacja ahead-of-time z kompatybilnego bytecodu razem z jakąś ustandaryzowaną biblioteką standardową rozwiązuje problem przenośności. Problem bezpieczeństwa też nie powinien być rozwiązywany w ten sposób. Jaki zresztą jest tak w zasadzie ten problem bezpieczeństwa i z czego on wynika?
    
    Odpowiedz
2. SeeM
  
  1 czerwca 2011
  
  To jest rozwój. Przyzwyczaiłeś się do Flasha i Javy, więc okienko z grą cię nie dziwi. Ale to demko nie jest okienkiem z grą. To jest strona zrobiona w html, tak samo jak twój komentarz.
  
  Odpowiedz
3. szarpaj
  
  1 czerwca 2011
  
  Ja czekam aż wszystko będzie trzymane w chmurze, a sprzęt będzie się składał jedynie z procesora, pamięci i szybkiego łącza. I wbudowanego magicznego ucha od Wielkiego Brata.
  
  Odpowiedz
  1. michuk
    
    1 czerwca 2011
    
    No, to długo już nie musisz czekać bo Google Chromebook nadchodzi latem.
    
    Odpowiedz
    1. morsik
      
      1 czerwca 2011
      
      Brakuje tylko tej najważniejszej rzeczy wymienionej przez szarpaja… szybkiego łącza.
      
      Odpowiedz
      1. michuk
        
        1 czerwca 2011
        
        W Stanach nie brakuje.
      2. Darek
        
        1 czerwca 2011
        
        W Stanach jest akurat wolny internet, w porównaniu do Polski i reszty Europy – ciężko tam znaleźć więcej niż 20Mbps. Net komórkowy to co innego, choć prędkości też podobne – tyle że tam z reguły jest on bez limitu.
4. MarekD
  
  1 czerwca 2011
  
  Przecież doom działał całkiem nieźle na 386, żadne pentium mu nie było potrzebne.
  
  W tej chwili jest już przeglądarkowy port kompilatora c (oraz działający linux) to na kompilator pascala długo nie będziesz musiał czekać, zobacz sobie na http://bellard.org/jslinux/
  
  Odpowiedz
Theq

1 czerwca 2011

Zajebiste, można odpalić 20 letnią gierkę, która będzie chodzić prawie tak samo na 100x szybszym sprzęcie. HTML5 + CS + JS nie przestaje mnie zaskakiwać.

Odpowiedz
1. SeeM
  
  1 czerwca 2011
  
  To nie jest DooM, tylko tak wygląda.
  
  Odpowiedz
konski_pytong

1 czerwca 2011

Na chrome coś nie idzie, to samo na IE, tylko FF – naprawdę interoperacyjny ten HTML5.
Nie spodziewałem się również, że gra ponad 20 letnia może chodzić z zawrotną szybkością 22 fps 😀 Najlepsze jest to, że Duke 3D chodzi płynnie (ponad 25 fps) na telefonach z symbianem a to cudo rozpędza się do 22 fps na współczesnych komputerach – naprawde zacna technologia, jeszcze jakieś 5 lat prac i bedzie można uruchomić Windows 95 JavaScript Edition w przeglądarce 😀

Odpowiedz
1. Tomek N.
  
  1 czerwca 2011
  
  "bedzie można uruchomić Windows 95 JavaScript Edition w przeglądarce": Linuksa się już da: http://bellard.org/jslinux 😉
  
  Odpowiedz
2. grigg
  
  1 czerwca 2011
  
  Pod Operą 11.11 też działa. Nie działa pod Fx 3.6 (wysypuje przeglądarkę, przynajmniej u mnie).
  
  Odpowiedz
3. @KonradStrozik
  
  1 czerwca 2011
  
  "naprawdę interoperacyjny ten HTML5" – Html5 to standard, który powinien zostać zaimplementowany TAK SAMO w każdej przeglądarce, a to, że z tym narazie jest problem (bo każda firma robi to po swojemu) to chyba nie jest wina standardu? Gdyby wtyczki do flasha robiło 5 różnych firm to dopiero mielibyśmy interoperacyjność:)
  
  Odpowiedz
  1. konski_pytong
    
    1 czerwca 2011
    
    a czy ja winie idee? raczej stwierdzam fakt jak jest obecnie
    
    Odpowiedz
Kuba

1 czerwca 2011

A nie czasem trio/tercet ? 🙂

Odpowiedz
1. Michał
  
  1 czerwca 2011
  
  HTML + CSS + JS to taki duet złożony z trzech elementów 🙂
  
  Odpowiedz
  1. @mhaligowski
    
    1 czerwca 2011
    
    niektórzy cały czas uznają JS za niedorozwinięty język, może dlatego.
    
    "duet złożony z trzech elementów" to prawie jak "trylogia w pięciu częściach":)
    
    Odpowiedz
    1. wladca_kodu
      
      1 czerwca 2011
      
      Dopóki nie skaluje się na wiele rdzeni, to można uznać, że jest trochę niedorozwinięty… Choć na szczęście szybko nadrabia 🙂
      
      Odpowiedz
      1. el.pescado
        
        1 czerwca 2011
        
        Prawie żaden język imperatywny nie skaluje się sam z siebie "skaluje na wiele rdzeni". A wątki to kwesia ortogonalna do samego języka – to że główna implementacja JS nie ma wątków, nie znaczy że ich zaimplementować się nie da (np. Web Workers w HTML5). Poza tym, wielowątkowość jest przereklamowana;)
      2. wladca_kodu
        
        2 czerwca 2011
        
        A czy ja gdzieś coś o wielowątkowości pisałem? Sam z siebie może nie, ale większość języków z niewielką pomocą daje się skalować – bo zapewniają do tego odpowiednie mechanizmy np. wątki, STM, asynchroniczne komunikaty, równoległość operacji na danych itp. Wielowątkowość implementowana jako biblioteka w języku, który nic o niej nie wie, działa zwykle słabo (czego przykładem jest C++).
2. michuk
  
  1 czerwca 2011
  
  Miał być pierwotnie chyba duet HTML+JS ale gdzieś się po drodzie CSS przyplątał i tak już zostało 🙂
  
  Odpowiedz
MiL999

1 czerwca 2011

Sztuka dla sztuki.

Odpowiedz
wladca_kodu

1 czerwca 2011

Też mi coś. Quake II został przportowany na Javę i działa _tak samo szybko_ jak oryginalna wersja napisana w C.
To może następne niech przeportują Crisisa? Na odpowiednio mocnym sprzęcie też pójdzie 😀

Odpowiedz
1. konski_pytong
  
  1 czerwca 2011
  
  Raczej nie, bo do tego to trzeba by ferme serwerów a wiadomo jak obecnie z obsługą wielu rdzeniu w przeglądarkach (zwłaszcza tych OS)
  
  Odpowiedz
  1. konski_pytong
    
    1 czerwca 2011
    
    http://www.chip.pl/artykuly/recenzje/2011/05/wyko…
    
    "Wszystkie przeglądarki za wyjątkiem Internet Explorer 9 dawały radę zagospodarować tylko jeden rdzeń do obsłużenia jednej karty. Co to oznacza? Nawet gdy posiadasz procesor 6-rdzeniowy, a trafisz na bardzo wymagającą stronę, nie wykorzystasz mocy swojego procesora. Przeglądarka zacznie reagować irytująco wolno, podczas gdy większość wolnych zasobów będzie leżała odłogiem"
    
    Odpowiedz
    1. szarpaj
      
      1 czerwca 2011
      
      Nic nowego, od dawna wiadomo, że tylko produkty MS potrafią zaorać całe zasoby, przelać się do pliku wymiany i osiągnąć responsywność szachisty w stanie kataleptycznym. (;
      
      Odpowiedz
    2. el.pescado
      
      1 czerwca 2011
      
      Tego by brakowało, żeby jedna karta wymagała więcej niż jednego CPU do wyświetlenia… Poza tym, JS z natury jest jednowątkowy, więc ciężko zagospodarować więcej niż jeden rdzeń jednej karcie. Chyba, żeby renderowanie puścić w jednym wątku, a JS w drugim…
      
      A ludzie narzekają że Mono jest wolne…
      
      Odpowiedz
2. michuk
  
  1 czerwca 2011
  
  Akurat różnica szybkości między C a Java jest minimalna w porównaniu z (do niedawna) różnicą między językami niskiego poziomu a interpretowanym JavaScriptem. To, że chodzi w nm teraz Doom pokazuje ogromny rozwój JS i jego gotowość do większości zadań, do których wcześniej potrzeba było pisać natywne aplikacje.
  
  Odpowiedz
  1. maniek
    
    1 czerwca 2011
    
    Zenada.
    
    Na szybko porównanie z grą pod nową wersje flasha. W przeglądarce. http://www.youtube.com/watch?v=tgwi0lWgX8w
    
    Ogromny rozwój ? Js jako jezyk powinien wyginac razem z dinozaurami. Nascie lat na karku i wciaz brak typowania ?
    
    Odpowiedz
    1. michuk
      
      1 czerwca 2011
      
      A zamiast wyginąć stał się najpopularniejszym językiem świata i raczej zostanie z nami przez długie jeszcze lata.
      
      Odpowiedz
    2. Cobra
      
      1 czerwca 2011
      
      Typowanie dynamiczne nazywasz _brakiem_ typowania?! Sam jesteś Dinozaur, ot co!
      
      Odpowiedz
      1. iron_irony
        
        2 czerwca 2011
        
        wszystkich lubiących typowanie dynamiczne zachęcam do programowania długich, złożonych programów. I testowania, testowania, testowania…
        Bo to co innym programistom wyjdzie na etapie kompilacji, to przy typowaniu dynamicznym trzeba sprawdzić w czasie wykonania.
      2. wladca_kodu
        
        2 czerwca 2011
        
        Właśnie ostatnio piszę coś w Pythonie i brak statycznego typowania jest okropnie wnerwiający, a projekt ma może 500 linii. Po kilka razy muszę odpalać program, żeby złapać wszystkie błędy, które normalnie dostałbym przy kompilacji. I nie, nie da się tego zrobić (łatwo) testami jednostkowymi, bo to kod w warstwie GUI i to odpalany w pewnym zewnętrznym środowisku.
      3. Cobra
        
        2 czerwca 2011
        
        > […] może 500 linii. Po kilka razy muszę odpalać program, żeby złapać wszystkie błędy […]
        "Wszystkie" błędy wśród 500 linii? Może czas na jakiś urlop, więcej magnezu w diecie etc.?
        A testy są przecież konieczne tak czy inaczej – jeśli ktoś uważa, że "kompiluje się więc jest ok" to powinien pisać tylko dla siebie.
      4. iron_irony
        
        2 czerwca 2011
        
        "jeśli ktoś uważa, że "kompiluje się więc jest ok" to powinien pisać tylko dla siebie. " .
        
        Negacją "dużo testowania" nie jest brak testowania tylko "mniej testowania". W związku z tym wysunięta przez Ciebie jest poza tematem tego wątku.
        
        Po to wymyślono styczne typowanie, żeby część błędów nie popełnić, bo wyjdą już na etapie kompilacji. Nie oznacza to, że nie testujemy, tylko wykrywamy błędy wcześniej jeszcze przed testami, czyli w praktyce szybciej piszemy dobre programy.
        
        "wśród 500 linii? Może czas na jakiś urlop, więcej magnezu w diecie"
        
        LOL. Miarą złożoności kodu jest "oczywiście" ilość linii. 😉 Tylko pogratulować porad.
      5. iron_irony
        
        2 czerwca 2011
        
        poprawka:
        Negacją "dużo testowania" nie jest brak testowania tylko "mniej testowania". W związku z tym wysunięta przez Ciebie _teza_ jest poza tematem tego wątku.
      6. wladca_kodu
        
        2 czerwca 2011
        
        Wiesz, to pewnie kwestia doświadczenia z językiem i wsparcia narzędzi. W Pythonie programuję od niecałego tygodnia i akurat błędy typu "ta funkcja nazywała się inaczej" albo "przyjmowała argumenty w innej kolejności", zdarzają się dosyć często, szczególnie, że IDE w wielu sytuacjach nie podpowiada. Mo, jak ma podpowiadać, jak nie zna typów argumentów metod? Wróżką nie jest.
        
        Czyli mam wybór, albo zerkać co chwila do dokumentacji (co spowalnia kodowanie), albo pisać z pamięci i później ewentualnie poprawiać (co też spowalnia kodowanie). Jak zaczynałem programować w statycznie typowanej Scali, to szło dużo, dużo szybciej, również mimo braku doświadczenia z językiem, i mimo tego, że Scala oferuje nieco więcej niż Python i jest przez to bardziej rozbudowana. I tak, zwykle po przebrnięciu fazy kompilacji, kod działał dobrze.
        
        A co do testów, to testami co najwyżej można wykazać, że jest błąd, a nie że go nie ma. Statyczny system typów za to daje 100% gwarancję, jeśli chodzi o pewne klasy błędów. Co oznacza, że jest o ileś nudnych testów do napisania mniej i można się skupić tylko na ciekawych, naprawdę istotnych przypadkach.
      7. konski_pytong
        
        2 czerwca 2011
        
        zmien IDE
      8. wladca_kodu
        
        3 czerwca 2011
        
        To ja poproszę o IDE, które w funkcji
        
        def fun(a, b, c, d):
        a. # tu mam kursor i wciskam skrót do autocomplete
        
        domyśli się, jakiego typu jest a i co można podpowiedzieć 😀
      9. konski_pytong
        
        3 czerwca 2011
        
        tak to to tylko w erze, tfffu t-mobile
        nawet visual nie pomoże
    3. el.pescado
      
      1 czerwca 2011
      
      Nascie lat na karku i wciaz brak typowania ?
      
      Czy to dziwne w języku z założenia dynamicznym?
      
      Odpowiedz
    4. iron_irony
      
      2 czerwca 2011
      
      Oczywiście masz świadomość, że Twój link to jest film we Flashu, nie dynamicznie renderowana gra we Flashu ?
      
      Odpowiedz
    5. mikolajs
      
      2 czerwca 2011
      
      Nie miałbym nic przeciw typowaniu, ale typowanie poważnie utrudniłoby kompatybilność wstecz jak również utrzymanie obecnych cech charakterystycznych dla języków dynamicznych. Programowanie w JS byłoby nieco wolniejsze i trudniejsze. W końcu JS służy do dodawania funkcjonalności stronie a nie pisania w nim dużych gier i systemów operacyjnych. W przypadku potrzeby użycia szybszego języka statycznie typowanego jest przecież Java.
      
      Odpowiedz
  2. steelman
    
    2 czerwca 2011
    
    Zgodzę się na "rozwój implementacji". Sam język pozostaje nieco kulawy: zmienne domyślnie globalne, pułapka z brakiem `new' przy tworzeniu obiektów. Trochę tego jest.
    
    Odpowiedz
3. kwahoo
  
  1 czerwca 2011
  
  Q2 zostało także przeportowane na Javascript i WebGL + Javę (GWT). http://playwebgl.com/games/quake-2-webgl/
  
  U mnie (test pod nickiem) jakieś 3x wolniejsze.
  
  Odpowiedz
  1. @mhaligowski
    
    1 czerwca 2011
    
    GWT to nie Java, tylko Javascript. Tzn. owszem, pisze się w Javie, ale całość i tak jest kompilowana do JS
    
    Odpowiedz
    1. kwahoo
      
      1 czerwca 2011
      
      JS jest chyba tylko po stronie klienta… Serwer to dalej Java.
      
      PS Inna fajna rzecz http://www.pythonocc.org/news/experimental-webgl-…
      
      Odpowiedz
      1. Wizard
        
        1 czerwca 2011
        
        Niekoniecznie, pod spodem może być cokolwiek.
mikolajs

1 czerwca 2011

Bez porządnej karty graficznej mam 4fps 🙂
Chyba nikt nie oczkuje, że zaczną robić duże gry w JS?
Do zastąpienia flasha akurat się nadaje Googlowska wersja kompilatora js jest w benchmarkach tylko około 8 razy wolniejsza od C++. Więc sporo zastosowań jest już możliwe.

Odpowiedz
1. el.pescado
  
  2 czerwca 2011
  
  Oryginalny Doom miał programowy renderer (wtedy nie było innych), więc wydajność karty graficznej nie powinna mieć znaczenia – chyba że chodzi o sprzętowe renderowanie samego firefoksa.
  
  Odpowiedz
Sławek

1 czerwca 2011

JavaScript Bakcend for LLVM? Czy ja dobrze rozumiem – kod pośredni jest tłumaczony na kod JS?

Odpowiedz
1. mikolajs
  
  2 czerwca 2011
  
  Tak. Program napisany w C został skompilowany do bitecodu LLVM, a potem zamieniony na JS
  Gdyby nie to że mają gotowy kod w C to byłaby to robota głupiego marnować szybki kod na zamianę w JS 🙂
  Ciekawie wygląda perspektywa pisania pod LLVM. Piszesz program w dowolnym języku kompilowanym do bitecodu LLVM, a otrzymujesz wersje na każdy system, a nawet przeglądarkę 🙂
  
  Odpowiedz
  1. joseph
    
    2 czerwca 2011
    
    Nie wiem, czy dobrze mi się wydaje, ale cześć kodu musieli chyba przepisać. To co jest odpowiedzialne za rysowanie na ekranie nie mogło zostać przeniesione bezpośrednio na JS. O ile pamiętam czasy dos-a, to tam pisało się pikselami bezpośrednio w pamięci karty graficznej, nie było żadnych warstw pośrednich. W przeglądarce rysujemy na warstwie canvas przy pomocy JS. Nie jestem zbytnio w tym obeznany, więc możliwe, że piszę bzdury 🙂
    
    Odpowiedz
    1. el.pescado
      
      2 czerwca 2011
      
      Patrząc na zrzut ekranu, to był port Dooma wykorzystujący SDL, więc jest jakaś warstwa pośrednia.
      
      Odpowiedz
michuk

1 czerwca 2011

@maniek poczytaj sobie o obecnych zastosowaniach JavaScriptu, choćby o node.js, phonegap, fabric.js…

Odpowiedz
Vigud

3 czerwca 2011

http://www.youtube.com/watch?v=d0S2dsuSxHw

Odpowiedz
NomadDemon

3 czerwca 2011

37 fps
ubuntu 11.04
r600g – radeon 4850

Odpowiedz