Názory k článku
Jak vytvořit pseudo 3D hry v HTML5 canvasu s raycastingem

Jú, funguje to i v Konqueroru. No to je úlet ;)

Jo, přesně tohle jsem se chystal napsat. :D

Muzu se na neco zeptat? K cemu je to dobre?

Bude to standard a nativne podporovane v prehliadacoch, na rozdiel treba od Flashu. Ja sa na toto velmi tesim, pretoze s Flashom mam len same problemy na 64 bit Linuxe a verim, ze to raz bude nahrada za Flash. Okrem ineho, Flash je na stranke ako black-box objekt, kdezto toto je mozne pekne previazat s HTML prvkami a JS, co dava nesporne vyhody. Flash stranka s textami nieje indexovatelna robotmi, kdezto tu je mozne docielit to same a byt pekne viditelny

Nemyslel jsem Canvas. Ptam se k cemu je dobre implementovat pseudo 3D engine, ktery je brutalne pomaly v necem jako je html (at uz s canvasem nebo JS, to je jedno).

Me to neprijde prakticky vyuzitelne tak jak to je, ale z toho kodu jsem se napriklad ja osobne hodne poucil, zjistil spoustu novych veci, ktere jsem pred tim delal zbytecne sloziteji a take zjistil par zajimavosti kolem matematiky. Takze zbytecne to urcite neni, otazkou je na co to kdo pouzije.

Ja si nemyslím, že to má mať praktické využitie, skôr ide o akési "technology demo", teda ukážku toho, čo všetko sa s canvas-om dá spraviť.

pekna ukazka ako sa to robi. optimalizacie to cele len skomplikuju a na optimalizovanom kode sa tazko uci.

mne sa clanok velmi pacil, je super mat moznost pozriet si takyto 3d engine v niecom tak jednoduchom a bez problemov modifikovatelnom ako je javascript!

html sa tiez clovek uci na hello world napisanom vo vimku a nie na ajaxovych strankach generovanych sialenymi regexpami v perle.

To je evoluce. Počítače sice máme stále rychlejší, ale všechny běžné úkoly trvají stejně dlouho a i ten Word se spouští pořád stejně rychle, jako před patnácti lety :)

Síce tiež nemám moc rád Flash, ale dovoľte kolega, aby som Vás trochu poopravil :-).
Flash dokáže volať v prostredí dokumentu JS funkcie, čím je možné prostredníctvom JS teoreticky manimulovať so stránkou... strašne neohrabané, viem... ale je to možné. Samo o sebe to ale hovorí v prospech JS :).
Flash je indexovateľný robotmi za istých okolností... ale v takmer 100% prípadov na potrebné veci vývojári nedbajú, takže v konečnom dôsledku v podstate nie je.
A mimochodom - neviem čo presne myslíte tým "docieliť to isté a byť pekne viditeľný". Ak by som vytvoril stránku tvorenú len pomocou JS, ktorý by generoval všetok obsah, tak by roboti toho moc nezaindexovali :). JS je dobré používať, ale človek musí vedieť ako ho používať ;-).

Flash nikdy nenahradí nic tak divného jako Canvas + HTML5...

Nahrazovat se bude Flash nebo to divné? :)

ano, tomu wolfovi sveho casu stacila 286ka :)

Proc delat neco efektivne, kdyz to jde i neefektivne. Nechapu lidi, co tohle delaji. K cemu je to dobre? Misto aby se prosazovalo programovani efektivnich aplikaci, tak se takto plytva vypocetnimi zdroji.

Ono ide o to, ze efektivita je casto nepriamo umerna zrozumitelnosti kodu. A pri takychto prikladoch, samozrejme, nejde o to urobit to co najefektivnejsie, ale co najprehladnejsie a zrozumitelne. A podla mna je clanok fajn...

Takisto by ma potesilo, keby sa Canvas a HTML5 presadili na ukor Flash-u. Avsak je pravda, ze keby sme mali nieco taketo uz skor, Flash by davno nebol tak rozsireny (ak vobec), ako je teraz.

Mam na mysli neefektivitu jakychkoliv aplikaci bezicich v prohlizeci napsanych v javascriptu.

Prave ze to jste uplne vedle -- vemte si, jak to bezi na starsich prohlizecich, jak pomalu to bezi na starsich pocitacich s novymi prohlizeci a vemte si, jak se plytva vykonem pocitace, a jak se plytva i vasim casem, kdyz na tu aplikaci musite cekat. Mnohem efektivnejsi by bylo stahnout si binarku a spoustet primo tu.

Vy rikate, ze o tom to je, ale soucasne prohlizece maji vazne problemy s vykonem, tudiz je otazkou, zda-li je dobry napad implementovat do nich aplikace.

Osobne bych rekl, ze Java i .NET urcyhluji vyvoj aplikaci a zvysuji jejich bezpecnost, zatimco javascript nedela ani jedno.

S kompatibilitou je na tom asi stale nejlepe C.

S tim Flashem s vami naprosto souhlasim.

To je otazne.Java aj .NET akurat presunul problematiku bezpecnosti z programatora na deployment a prostredie.Inak povedane bezpecne nastaveny system s c/c++ aplikaciou (ktora je maximalne safe ako moze byt) je rovnaka ako nejaky VM.Ostatne v Unixoch napriklad chroot existuje dlho.Problem s verziami a kniznicami je aj pod Javou/NETom len sa to ako som napisal presuva inde.Co sa tyka urychlenia vyvoju, to je zasa otazne.Klikacie generatory kodu/gui sa daju spravit na kazdy jazyk.Davno pred nejakym Swingom alebo C# gui editorom v MSVC tu bolo napriklad Delphi, ktore co sa tyka RADu aj dnes nema moc konkurencie (bohuzial ale iba co sa radu tyka,ostatne taky VB tiez dost veci kopiroval,alebo naopak).Obcas mam pocit ze sa objavuje objavene a este mame MS/Adobe/Google a ostatnym za to asi tileskat.
Mimochodom z aktualneho web developmentu a trendov je mi dost nevolno.Jedina vec z ktorej v poslednej dobe mam aspon trochu pozitivny pocit je Flex.

Problém s verzemi a knihovnami v .NETu prakticky není - vše je jasně definováno, knihovny se podepisují. Bezpečnost je násobně vyšší oproti nativním programům (např. buffer overflow útokům atd.). Jestli si myslíte, že efektivita .netu je v naklikávání, tak jste v tom asi moc nenapsal.
Javascript a další technologie uměle naroubované na html - to je slepá ulička, kdo to pochopí, ušetří neuvřitelné množství peněz a času.

Jeste bych doplnil, ze ne vsechny prohlizece podporuji javascript a ne vsichni uzivatele ho maji zapnuty.

Zakladnim duvodem je zpristupnit programovani/ovladani prostredi vice uzivatelum
(Je otazkou jak moc je to zvrhla myslenka - osobne myslim, ze neni spatna - jelikoz dnes a denne vidime na internetu priklady velmi zajimavych reseni, myslenek, projektu, ktere by nevznikly byt tu jen assembler).

Zprehlednovanim kodu, snadnejsimi vyvojovymi nastroji, a upoutanim uzivatele tech.demem jako je toto, se laka uzivatel k tomu aby se do programovani pustil. To je neci marketing. Ale zaroven je to prinosne(viz text v zavorkach vyse).

Proto panove nepiseme v assebleru a stranky si neprohlizime v textovem modu na zelenocernem monitoru.

Tim chci take rict, jen houst s takovymi tutorialy! Root vede!

Za redakci Zdrojáku děkuji 8-)

Myslim, ze divit se nebudeme, protoze pokud se JS radikalne nezmeni (nezavede silne typovani), bude stale umorne pomaly. Uvedomte si prosim fakt, ze kdyz mnoho spolecnosti do neceho investuje a necemu veri, tak to neznamena, ze neexistuje neco lepsiho.

chtel jsem napsat silne staticke typovani

Se statickým typováním nemáte úplně pravdu. Zrovna můj dnešní článek tady na Zdrojáku ukazuje, jak se s absencí typových deklarací poměrně úspěšně vyrovnává interpret SquirrelFish (WebKit/Safari) - jednoduše si potřebná data posbírá v runtime. Podobně to dělá V8 (Google Chrome). SpiderMonkey/TraceMoneky (Firefox) zas používá techniku trace trees, která nedostatek informací o typch také v určitých případech dovede obejít.

Pokud se interpret napíše opravdu dobře (což ale stojí poměrně hodně úsilí, proto se to moc nedělá), dá se s ním dosáhnout rychlosti blízké rychlosti céčka. Viz zmínka Avi Bryanta o Strongtalku, dialektu SmallTalku:

Strongtalk is that it does allow optional static type annotations, but the optimizer completely ignores them: your code runs exactly as fast if you duck type everything as if you statically type everything. That’s not because the implementors were lazy - their goal was to produce the fastest system possible, it’s just that their dynamic implementation was already fast enough that the static information didn’t help.

Podobně také viz jazyk Self:

Despite this complete devotion to objects, Self code runs at up to half the speed of optimized C, the high performance being achieved through dynamic profile-driven optimization.

JavaScript na tom sice nyní tak dobře, aby běžel polovinou rychlosti céčkového kódu, není, ale není nepravděpodobné, že brzy někde okolo těchto hodnot bude.

Optimalizace ve vasem clanku uvedene v castech "Pristup k vlastnostem objektu" nebo "Typova inference" se prakticky jen snazi zmirnit fakt, ze chybi typove informace -- resp. kdyby tam typy byly tak k clenskym datum objektu muzete pristupovat v case konstantnim a bez nejake rezie ci optimalizace.

Jazyk Self neznam, nicmene srovnavate, ze rychlost jeho interpretru se blizi rychlosti kompilovaneho C, coz je sice chvalihodne, ale je otazka, zda je vystup kompilatoru C skutecne ultimatni cil, zda nejde jit jeste dale.

Problem jazyka C je zejm. prima manipulace s pameti, kde kompilator nemuze nic moc delat. Napriklad jazyky jako Clean, Haskell maji potencialne moznost toto vyresit mnohem lepe -- navic uz ted provadeji optimalizace celych programu.

Vemte si napriklad kompilator omezene varianty jazyka Scheme jmenem Stalin, ten je schopen vyplodit rychlejsi kod (preklada do C), nez je rucne psany kod v C. Porad ale plati, ze kompilatory dynamickych jazyku se musi spolehat predevsim na urcitou intuici (nebo na statistiky z predeslych behu programu) -- tudiz vysledek neni jisty. Zato kompilatory staticky typovanych jazyku nemusi pouzivat intuici k detekci typu, protoze je maji predem (jasne) dane.

Je treba uznat, ze kompilator staticky typovaneho jazyka je proste ve vyhode oproti kompilatoru dynamicky typovaneho jazyka, nebot ma informace navic.

Je treba uznat, ze kompilator staticky typovaneho jazyka je proste ve vyhode oproti kompilatoru dynamicky typovaneho jazyka, nebot ma informace navic.

S tím souhlasím. Jen sem chtěl vyvrátit vaše tvrzení z komentáře, že JavaScript bude bez statického typování "úmorně pomalý". Ztráta informace absencí typových deklarací vadí, ale nevadí tolik, jak se může na první pohled zdát.

Máte samozřejmě pravdu, že céčko není ultimátní cíl; zmiňované problémy s ukazateli se vysvětlují na každé přednášce z kompilátorů. Bral jsem to zde spíš jako referenci (vágní, ale často používanou).

Článek se mi zalíbil a jen tak dál, rozhodl jsem se do tohoto enginu upravit galeri.. téměř všechm se zalíbilo že by se mohli procházet po místnosti s fotkama... to se mi vše podařilo pomocí php generovat z Db, ale hlavní problém je s dekoracemi. Chtěl jsem přidat stůl vytvořený pomocí poloprůhledného PNG. Zobrazí se, ale místo průhledné barvy se zobrazí růžová... mělo by to být někde v nastavení, ale nikde se mi to nepodařilo najít. Poradí nekdo?

Mozna jsem uplne mimo, ale do zakladu dost IE bojuje s pngckama;)

http://www.wecko.net/clanky/1/138_transparent-24bit-png-v-ie

hmm?

No áno, pekné, ale - toto využíva DOM, nie canvas :). Takže by to išlo aj v IE... moment, skúsim... ide ;). Canvas verzia by samozrejme išla rýchlejšie :).

---
Špeciálne pre vrtákov a rypákov: áno, minimapu vykresluje canvasom...