Nem hiszed el, hogy lehet HTML5-ben király játékot írni? Ezt nézd meg!

Nem hiszed el, hogy lehet HTML5-ben király játékot írni? Ezt nézd meg!
2015-03-09T10:35:22+01:00
2015-03-12T17:07:21+01:00
2022-10-21T18:35:36+02:00
  • Semmi extra nem kell hozzá.

    m_Thread = new System.Threading.Thread( ... ); m_Thread.Start();
    http://answers.unity3d.com/questions/357033/unity3d-and-c-coroutines..
    Mutasd a teljes hozzászólást!
  • Miert kell draga gep, ugy is nagyreszt csak a gpu dolgozik a gepeken, ott meg a csatolo felulet kb. 75%-at tudja a nativnak(es nem a javanak, vagy a .net-nek), akkor hol a problema ? Megint mas, hogy a webgl tamogatas meg kozel sem tokeletes.
    Mutasd a teljes hozzászólást!
  • Nekem ez uj, hogy csinalsz te Unity3d-ban szalakat ? Bar igazbol mindegy, a mondandom lenyege ugy sem az, hanem, hogy szalak nelkul az elet tobbnyire szebb. (kevetelek persze vannak)
    Mutasd a teljes hozzászólást!
  • Ez így nem pontos. Maga a Unity3d nem thread safe és csak egy dedikált szálból lehet elérni az API-t, de amellett annyi szálad lehet, amennyit szeretnél.
    Mutasd a teljes hozzászólást!
  • Lehet, hogy van webgl-re, de én nem is állítottam, hogy nincs. Csak annyit állítok, hogy igen drága gép kell a stabil 60FPS-hez.
    Mutasd a teljes hozzászólást!
  • Mindenki a JS-t szidja nemikepp jogosan, de a unity3d pl. eleve nem tamogat szalakat. Neha valoban hianyzik, de az esetek 90% ez inkabb hasznon mint hatrany.
    Mutasd a teljes hozzászólást!
  • Assassin's Creed tudtommal van webgl-re.
    Mutasd a teljes hozzászólást!
  • Egyszer megírod a játékot és olyan platformokon is futni fog (Linux, Mac, okostévé, táblagép esetleg), amikre alapból nem írtad volna meg a játékot és esetleg más sem nagyon ír.

    Ha a játéknak komoly teljesítményigénye van, a vas képességei erősen behatárolhatják a keresztplatformos fejlesztés lehetőségeit.  Egyszerűbb alkalmazásokhoz viszont remek lehet.
    Mutasd a teljes hozzászólást!
  • Háát... A mai nagy címekre ez sajnos nem igaz. A Call of Duty, Battlefield, Grand Theft Auto, Assassin's Creed, stb.. új részei esetén már igen drága gép kell egy stabil 60FPS-hez.

    De ott sem a C/C++-ban írt kód és pláne nem annak a játékfejlesztő által megírt része a szűk keresztmetszet, hanem a grafikus kártya feldolgozó egységeinek száma, a shaderek bonyolultsága, a textúrák mérete, stb. Pont emiatt nem számít alapvetően az, hogy maga a játék kódját miben írják meg. Utóbbinál a grafikus API és a mögöttes videóhardver mindig szűkebb keresztmetszetet fog képezni az általad említett játékok esetében (is).
    Mutasd a teljes hozzászólást!

  • Valóban nem néztem az utolsót. Jobban megnézve, az engine TypeScript-ben van írva, turbulenz/turbulenz_engine

    Másrészt a legtöbb mai játék nagyjából 300-3000 FPS-t is simán tudna produkálni egy mai átlagos hardveren

    Háát... A mai nagy címekre ez sajnos nem igaz. A Call of Duty, Battlefield, Grand Theft Auto, Assassin's Creed, stb.. új részei esetén már igen drága gép kell egy stabil 60FPS-hez. Esetleg a régebbi részek talán mennek 300-3000FPS-el. Pedig jó lenne, ha nem kellene gépigényre figyelni...
    Mutasd a teljes hozzászólást!
  • Egyszer megírod a játékot és olyan platformokon is futni fog (Linux, Mac, okostévé, táblagép esetleg), amikre alapból nem írtad volna meg a játékot és esetleg más sem nagyon ír.

    Böngészőben futó játékkal sokan játszanak, főleg gyerekek, vagy akik olyan helyen ülnek gép elé ahol nem lehet telepíteni, pl iskolában, könyvtárban, munkahelyen. Nem kell mindenkinek AAA minőség.

    Plusz nem csak játékra jó ez.
    Mutasd a teljes hozzászólást!
  • Azért a HTML5 nem egy programozási nyelv, abban aligha fognak játékot írni. De ezek a játékok még csak nem is JavaScriptben íródtak, hanem C/C++/Blueprint stb. -ben és Emscripten-el fordítódtak JavaScriptre, pontosabban Asm.JS-re.

    Tévedsz. Az utolsó játék pl. színtisztán HTML5+JavaScript+WebGL-ben került megírásra. De a Unity-s és Unreal-os játékok is éppen csak annyira íródnak C/C++-ben, mint amennyire JavaScript-ben is. A kód >99.9%-át ugyanis ezekben sem a fejlesztő írja, hanem a motor és a futtatóplatform adja - amiket nem a játékfejlesztő írt, és amivel összefüggésben amik a játékfejlesztő szempontjából (is) aztán lehetnek akármiben is írva, mert teljesen irreleváns számára, hogy konkrétan miben vannak írva.

    Nekem továbbra sem világos, hogy mi lesz a felhasználási területe ennek. Ki fogja bevállalni a legjobb esetben is fele teljesítményt egy játéknál? Ami mondjuk stabil 60FPS, abból lesz legjobb esetben 30...

    Egyrészt ki mondta, hogy "legjobb esetben is fele teljesítmény" lesz elérhető? Erről szó sincs. A sebesség szempontjából legkritikusabb részek gyakorlatilag ugyanolyan gyorsan fognak működni. Másrészt a legtöbb mai játék nagyjából 300-3000 FPS-t is simán tudna produkálni egy mai átlagos hardveren. Ha az történesen feledőzik, az még mindig bőven elég lesz nekik. Főleg, hogy így is már 60 FPS-es cappel futnak, ami nyilván ettől nem fog változni.

    Meg egyáltalán miért jó az, hogy böngészőben fut egy játék?

    Ugyanazért, amiért az jó, hogy fut Windows-on, Linux-on, Androidon, iOS-en és bármilyen másik platformon. Nem mintha itt feltétlenül arról lenne szó, hogy a játék a böngészőben fut - sokkal inkább arról, hogy a böngészőmotor, mint eszközfüggetlen univerzális alapplatform felett fut. Ami nem feltétlenül jelenik meg úgy a felhasználó számára, mint böngésző, előre meg hátra gombokkal, home ikonnal és címsorral.
    Mutasd a teljes hozzászólást!
  • Azért a HTML5 nem egy programozási nyelv, abban aligha fognak játékot írni.  De ezek a játékok még csak nem is JavaScriptben íródtak, hanem C/C++/Blueprint stb. -ben és Emscripten-el fordítódtak JavaScriptre, pontosabban Asm.JS-re. Ugyanakkor vannak még erős limitációk. pl. exception kezelés, 64 bites int kezelés lassú, illetve a szálkezeléshez tényleg nagyon kellene az a shared state, mert ami most van, az nem portolható hatékonyan.
    Emscripten - Code Portability and Limitations -> Portability Guidelines

    Az is szép lesz, amikor az Asm.JS és a sima JavaScript keveredni kezd később, mert lehet kézzel memóriát kezelni...
    Emscripten - Connecting C++ and JavaScript -> Interacting with code

    Nekem továbbra sem világos, hogy mi lesz a felhasználási területe ennek. Ki fogja bevállalni a legjobb esetben is fele teljesítményt egy játéknál? Ami mondjuk stabil 60FPS, abból lesz legjobb esetben 30... Meg egyáltalán miért jó az, hogy böngészőben fut egy játék?
    Mutasd a teljes hozzászólást!
Tetszett amit olvastál? Szeretnél a jövőben is értesülni a hasonló érdekességekről?
abcd