Gyurkity Péter

Megölheti a Flasht a HTML 5?

A HTML 5 fejlesztése, egyes funkcióinak korai megjelenése egyes böngészőkben számos kérdést felvet, amelyek között első helyen szerepel a Flash, a Silverlight, valamint a JavaFX technológiák jövője.

Nem véletlen, hogy az InfoWorld ebben a témában közölt a napokban egy hosszabb értekezést, hiszen a HTML 5 egyik legfontosabb újdonsága a különböző grafikák, a képi tartalmak és hanganyagok könnyű, szabványosított módon történő megjelenítése a weboldalakon. Amennyiben ez megvalósul, nagy kérdés, hogy mennyiben lesz szükség az olyan levédett, egy-egy cég által birtokolt megoldásokra, mint amilyen a fenti hármas.

Elemzők egy része úgy véli, hogy a HTML legújabb verziójának elkészülte idővel a halálos ítéletet jelenti majd a Microsoft, a Sun, illetve az Adobe által fejlesztett technológiák számára, mások azonban nem osztják ezen véleményt, kiemelve, hogy ehhez nyilván a vállalatoknak is lesz egy-két szavuk. Az nem meglepő, hogy a három nagy védi saját fejlesztéseit - szerintük ezek a technológiák egyrészt jobbak, másrészt pedig már most széles körben elérhetők, míg a HTML 5 a legjobb esetben is folyamatban lévő munkaként jellemezhető. A nyílt szabványt sem kell azonban félteni, hiszen egyes böngészők (így például a Firefox 3.5 vagy a Chrome) már most használják annak egyes elemeit, ami jól mutatja a várakozás mértékét.

A HTML 5 esetében a Canvas technológiát emelik ki, amely a 2D-s grafika megjelenítését egyszerűsíti le. Ez különösen a Microsoftnál vethet fel kérdéseket, amely maga is támogatja a szabvány elkészültét. Amennyiben ugyanis az Internet Explorer ezen technológiára alapozva önmagában megoldja meg a feladatot, megkérdőjeleződhet a Silverlight technológia szerepe és jövője, márpedig ez utóbbi fejlesztésével egy külön részleg foglalkozik a szoftvercégen belül, magát a platformot pedig nagyon erősen támogatják az utóbbi időben (nyilván a Flash és a JavaFX ellenében, igyekezvén csökkenteni azok népszerűségét).

Ezen kérdésekre természetesen csak a szabvány végleges változatának megjelenésekor, valamint az egyes böngészők hozzáállása láttán kapunk majd csak választ, erre pedig még várni kell.

Hozzászólások

A témához csak regisztrált és bejelentkezett látogatók szólhatnak hozzá!
Bejelentkezéshez klikk ide
(Regisztráció a fórum nyitóoldalán)
  • Sir Ny #100
    még mindig kezeli a dicektxet meg az openglt, még mindig működik a saját fizikai motorja, és még mindig megy az a multipléjer is. és nem fog kihalni, az ótókás játékok, de inkább a 3d játékok zöme shockwave-ben van. (meg van néhány java-ban (szegény, jól ki fog halni) meg néhány 3dvia-ban (szegény, el sem fog terjedni)
  • Komolytalan #99
    Ne keverjük a szezont a fazonnal, ez shockwave, nem pedig flash.
    Shockwave szegény jól ki fog halni, mert bonyolult benne feljeszteni, de ami a nagyobb baj, a playere is egy halál volt régen telepítés szempontjából. Más kérdés hogy kezelt asszem directx-et (vagy openglt, nem tudom), meg volt saját fizikai motorja is. Sőt, a multiplayer is ment rajta jól, mert ez már rég tudott udpt, meg mindent.
  • Komolytalan #98
    Packet loss 0 (tcp/ip socketnél nem lehet), stabilitással nincs gond, hibakezelés meg mint a javaé, tehát jó. De maga a flash sebessége még messze nincs ott ahol a C++-é, sőt még ott se mint a javaé, mivel pl futás időben még elérhetőek a változók nevei, szóval kicsit még ma is interpreter a lelkem. Igaz, verzióról verzióra rengeteget gyorsul.
    Latency annyi, mint kliens-szerver kapcsolatoknál szokott lenni. Nyilván a szerver sebességétől is függ, de mindenképpen több mint egy direkt kapcsolatnál, és ami igazán gáz, az egyes feleknél eltérő.
    Itt lép be a képbe a 15-16 msec pontosságú timer - latency korrekcióhoz azért ennél pontosabb kéne szerintem. És ami a nagy különbség c++ és flash között, hogy ami flashben nincs, azt nem is mindig tudod megírni, így pl pontosabb timert se.
    Szóval látszólag minden megoldható, de jó sok problémát kéne kezelni, ami más nyelven eleve nem is jelentkezne, ezért szerintem nem optimális eszköz. Próbálkozni persze ettől még lehet, meg akár sikerülhet is.
  • passatgt #97
    canvas nem újdonság, mindig is volt, csak senkinem használta:)

    viszont ha felkapják, tuti lesz hozzá rengeteg keretrendszer, amiben beírod hogy circle:10, és rajzol egy 10px átmérőjű kört....vagy valami ilyesmit:)
  • Lazarus #96
    Köszi, tehát mostmár ugyan olyan lehetőségek vannak a kommunikációra mintha c++ban valósítanám meg ugyan azt. Miért nem optimális célzós lövöldözős játékra? Pocketloss, magas latency, nem elég stabil, kiforratlan hibakezelés... mit értesz az alatt hogy a körülmények még nem optimálisak?
  • Sir Ny #95
    tessék, itt egy célzós (lövöldözős) játék és szerver nélkül kapcsolódnak a játékosok (asszem):
    http://www2.rasterwerks.com/game/phosphor/beta1.asp

    bár a multipléjer részét nem próbáltam (valahol azt olvastam, hogy nem sikerült nekik) mivel nem találtam senkit, aki jött volna játszani, és lehet, hogy már nem is működik alapból a játék sem (rég játszottam vele, akkor, amikor még volt shockwave playerem).
  • Yv@n #94
    "Mégis mi a rák haszna volna egy 64 bites flash playernek?"

    Nálam desktop gépen amd64-es linux van épp, és nem hátrányos, ha nem egy wrapper húzza be a 32bites plugint. Mellesleg van 64bites flash player plugin, éppen emiatt. :)

    Cikkhez meg, HTML5:
    A html 5 inkább a korábbi verziók racionalizálása. Megszüntetnek elég sok redundanciát, lásd minek anchor tag, ha egyszer minden elem kattintható, így hát szépen belecsaptak egy href attributtumot mindenbe, és bármi lehet link. Jellemzően ilyen és ehhez hasonló változásokat takar legfőképpen a html5.

    Az érdekesség/újdonság benne a már említett canvas. Jelenleg ugyebár, ha valami kliens oldalon rajzolni kíván, akkor azt max úgy teheti meg, hogy 1x1px div-eket rak ki egy területen belül, olyan háttérszínnel, amilyen színű pixelt szeretne az alkotó kapni. Nyilván ez roppant primitív megoldás, és kellően erőforrás igényes is. A canvas egy sima vászon, amire javascript kóddal pixelgrafikázhat az ember, ha elég perverzió szorult bele(2010 környékén azért elég elvetemültnek kell lenni, hogy valaki erre érezzen késztetést).
  • Komolytalan #93
    Flash multiplayer támogatása annyi, hogy flash 5 óta kezel tcp/ip socketes kliens-szerver kommunikációt. Asszem AS3 (vagyis 9-es verzió) óta már egész jól boldogul a bináris adatokkal is, azokat is szépen lehet küldözgetni a szerver és a kliens között. Direkt kliens-kliens kapcsolat 10-es flashtől van, asszem ez már lehet UDP is, de még elég korlátozott, úgyhogy nagyon nem ástam bele magam.
    Ha ezt az UDPs kommunikációt nem számoljuk, akkor multiplayernél olyasmibe kell gondolkozni, aminél a 2 (több) játékos közé be van ékelődve a szerver is. Célzós, lövős játékra nem optimális még.
  • Komolytalan #92
    Mégis mi a rák haszna volna egy 64 bites flash playernek? Le tudna foglalni több mint 4G memóriát? A video lejátszásról meg annyit, hogy On2 vagy MP4 formátumot használ (esetleg sorensont, bár azt inkább csak webkamerához). Az a player van benne, amit a gyártótól meg lehetett kapni, szóval nem igazán értem miért zabálna ez többet, mintha ugyanazt a felbontású videot bármi más videolejátszóval néznéd meg.
  • Sir Ny #91
    hát elárulom neked a nagy titkot, hogy nem a youtube flash része dögleszti meg a gépet, hanem az, hogy miközben nézed, közben tölti le. szerintem próbáld ki a netbookodon, hogy elindítasz öt videót vinmédiapléjerrel, és közben letöltesz öt videjót (tömörítetlenül) (egyszerre) és nézd meg, melyik terheli le jobban a gépedet...