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-07-22T11:21:18+02:00
  • Sting leírása alapján inkább magát a böngészőt kellene frissíteni, illetve másikat elindítani, azt nem tudtam, hogy asm.js kompatibilis kell hozzá

    Nem kell. Ez az asm.js lényege. Csak az a böngésző, ami nem ismeri az asm.js-t, az értelemszerűen sokkal kevésbé hatékony tárgykódot generál mögé, mint az, ami igen.
    Mutasd a teljes hozzászólást!
  • Sting leírása alapján inkább magát a böngészőt kellene frissíteni, illetve másikat elindítani, azt nem tudtam, hogy asm.js kompatibilis kell hozzá. (vélhetően Firefox legújabb verziója) Ez máris rávilágított 1-2 nehézségre ezzel a futtatási módszerrel kapcsolatban.

    @gr8lIr
    A példámban az UT legújabb verzióját emlegettem, ami szép is jó is meg piacképes is.
    Mutasd a teljes hozzászólást!
  • Ha jól megfigyeled, @M.Seal-nek válaszoltam, konkrétan arra, hogy

    Szerintem a vita egyszerűen eldőlne, ha ugyanazt a játékot ki lehetne próbálni natív és HTML5-ös böngészős változatban is.


    Ezen túl, egyrészt szerintem a "jót" és "szépet" annyira szubjektív fogalmak, hogy erről vitatkozni nem sok értelme volna, ezért megy a vita arról, hogy lehet-e "piacképeset" és "eladhatót" írni, illetve, hogy lehet-e annyira jót írni mint natív eszközökkel.

    Szerintem - bár kétségtelenül natívkód párti vagyok, és gyakorlatilag meggyőzhetetlen arról, hogy scriptnyelvben (főleg mindenféle frameworkökkel kiegészített scriptnyelvben) programozni nem az erőforrások bűnös pazarlása - arról, hogy a JavaScript vagy a HTML5 alkalmas-e piacképes programok (játékok) fejlesztésére, már fölösleges vitatkozni, hiszen az említett eszközöket aktívan használják erre a célra.

    A kérdés tehát az, hogy a WebGL (ami kevésbé elterjedt a játékfejlesztők között) mint technológia versenyképes-e a natív technológiákkal, illetve, hogy az így előállított termék piacképes-e egyáltalán.
    Mutasd a teljes hozzászólást!
  • Viszont a felvetes nem is az volt, hogy lehet-e ugyanolyant csinalni, mint binaris kodbol. hanem, hogy lehet-e jot es szepet, ami mar eleg gyors weben is.
    Mutasd a teljes hozzászólást!
  • Mondjuk az a 0..1 fps az durva. En egy driver frissitest kiprobalnek, hátha.

    Az a gond szerintem az OpenGL-el amugy, hogy csak a 2 nagy gyártó erolteti meg magát annyira, hogy jó legyen a driver minôsége/teljesitmenye. ôk kénytelenek ezt tenni pl. a cad programok miatt. A tobbi kis gyarto (pl. Intel HD graphics) meg megelegszik azzal, ha a Direct3D drivert megcsinalja jóra, mert azzal lefedte a felhasznaloi kor tulnyomo reszet. (A nagy jatekoknal csak opcionalis az OpenGL, pl ha van OSX verzio is. Amiatt kenytelenek megirni OpenGL-re is de Windows-on a jó hardver lefedettseg miatt marad a Direct3D defaultnak).

    Egy multiplatform dolog, mint a JS meg a browserek viszont az elveik miatt nem hasznalhatnak Windows only api-t, pedig M.Seal gépén lehet, hogy pont ez lenne a megoldas.
    Mutasd a teljes hozzászólást!
  • Én most a babylonjsoldalon néztem az instanceddemót, de gyakorlatilag 0-1 FPS-t hozott. Ezen gépen pedigennél azért jóval komolyabb jelenetek is futnak.

    Az én lassan 5 éves, akkor közepkategóriás gépemen (Core i5 750, GeForce GTS 250) FullHD, tehát 1920x1080-as felbontásban is 51-53 FPS-t produkál Chrome 41-ben és Firefox 37-ben is. IE11-ben csak 5 FPS-t, de ez érthető is, mert abban még nincs benne az asm.js-támogatás.
    Mutasd a teljes hozzászólást!
  • Én a viszonylag erős munkahelyi gépen néztem (amiben - értelemszerűen - nincs "gyilkos" videókártya), és olyan 25-30 fps-t hoztak a demók. (16Gb RAM, i7-es proci)
    Mutasd a teljes hozzászólást!
  • Jó de ne egy integrált krumplin nézd! :D

    Itt elso inditas 60fps. (Végre van már vsynch is, jó lenne, ha a youtube is használná a videoiban)
    Aztan az ablak bezarasa utan beragad valami es a Chrome osszessegeben 20% cpu-t eszik.
    Ujboli elinditasra emiatt leesik 30fps-re.
    Mutasd a teljes hozzászólást!
  • Én most a babylonjsoldalon néztem az instanceddemót, de gyakorlatilag 0-1 FPS-t hozott. Ezen gépen pedigennél azért jóval komolyabb jelenetek is futnak. Ez persze nem reprezentatív mérés, csak egy próba volt, hátha megjön a kedvem a webes 3D-hez, de eddig még nem jött meg.
    Mutasd a teljes hozzászólást!
  • A high-end játékok HTML5 átiratai amikkel eddig találkoztam mind "lebutított" illetve "minigame" jellegűek voltak, mint pl. a lentebb már említett (azt hiszem) HTML5+Js+WebGL Assassins creed (ami - megjegyzem - egész csinos volt, simán hozta az AAA játékoktól 4-5 évvel korábban elvárt színvonalat). Ez persze nem azt bizonyítja, hogy "full" high-end játékot bizony nem lehet HTML5+Js+WebGL platformra írni, csak azt, hogy senki sem gondolja komolyan, hogy ilyesmit tegyen. Ennek persze egy egész sor oka lehet a technológia (vélt-vagy-valós) korlátosságán túl, de mindenképp lehetetlenné teszi az efféle összevetést.
    Mutasd a teljes hozzászólást!
  • Szerintem a vita egyszerűen eldőlne, ha ugyanazt a játékot ki lehetne próbálni natív és HTML5-ös böngészős változatban is. Eseleg elméleti bizonygatások helyett láthatnánk 1-2 ilyen Unreal/Unity linket, ahol ezeket ki is lehetne próbálni és összehasonlítani a sebességet, grafikát stb. Persze nem 2D Mario-ra gondoltam, hanem egy komolyabb 3D játékra. (UT legújabb változata stb.) HTML5 esetben még akár a különböző böngészőkön való futást is meg lehetne nézni már amelyiken egyáltalán elindul a program.
    Mutasd a teljes hozzászólást!
  • Nem mintha értelme lenne jönni az AAA játékokkal - ha csak nem a szabályt erősítő kivételre akarunk példát hozni bennük.

    Az volt a kérdés, hogy hol használnak C++-t. , pontosabban:

    hol fejelsztenek ma c++-ban jatekot ?!

    Amúgy egyetértek, a játékok 99%-a nem AAA.
    Mutasd a teljes hozzászólást!
  • Na megvan az okossag ;)
    Mutasd a teljes hozzászólást!
  • Valóban használnak vizuális eszközöket, de igazából minden C++ objektumot lehet szerkeszteni vizuálisan is. Szóval elmosódik a határ valahol. A C++ azért népszerű, mert konzolokon aláírt bináris kell. A nem sebesség igényes játékokat persze akármiben meg lehet írni.
    Mutasd a teljes hozzászólást!
  • Az Unreal, Unity3d nem AAA játék, hanem játékmotor. Amúgy az Unreal C++, Blueprint, Unity3d C#.
    Mutasd a teljes hozzászólást!
  • A legtöbb AAA játék C++.

    Ez úgy igaz, hogy a legtöbb AAA játék motorjának nagy részét anno C++-ban kezdték el megírni. Magukat a játékokat viszont már nagyon rég óta nem C++-ban írják. Sőt, nem is a hagyományos értelemben írják, hanem vizuálisan, modellezőeszközökkel tervezik, meg tetszőleges másik nyelveken (köztük szkriptnyelveken is) írogatnak viszonylag egyszerű rutinokat, programokat benne és hozzá. Már a shadereket is így csinálják manapság.

    És ezen nem változna semmi akkor sem, ha a játékmotor assembly-ben, C64 Basic-ben, vagy JavaScript-ben lenne. Sőt, igazából ez már így is van - hiszen az eredetileg C++-ban elkezdett játékmotorok közül azok, amik még relevánsak maradtak, ma már számtalan nyelvi reprezentációban és adaptációban léteznek. Pont ezért lehet a rájuk épített játékokat akár HTML5-be is exportálni, mindössze pár kattintással.

    Szóval nem, a legtöbb AAA-s játék manapság már semmilyen értelemben sem C++. Vagy csak annyira, amennyire JavaScript, Java bájtkód meg ARM gépi kódú is. Meg amennyire a fejlesztő dönt amellett, hogy C++-ban akarja a saját kódjait megírni hozzá - amiket viszont akármilyen másik nyelven is megírhatna.

    Nem mintha értelme lenne jönni az AAA játékokkal - ha csak nem a szabályt erősítő kivételre akarunk példát hozni bennük. Mert elég evidens, hogy sem a játékok 99%-a nem AAA kategóriás, sem a játékfejlesztők 99%-a nem AAA kategóriás játékokat gyárt. Így általánosságban az, hogy az AAA kategóriás játékokra mi jellemző, nagyjából teljesen irreleváns, még a játékfejlesztés berkein belül is. Ami maga is csak a programozás egy igen szűk rétegterülete, megint csak mind a projektek, mind az azokban foglalkoztatott emberek számát tekintve is.
    Mutasd a teljes hozzászólást!
  • Unreal, Unity3d ?
    Mutasd a teljes hozzászólást!
  • Azert ne rohanjunk annyira elore, hol fejelsztenek ma c++-ban jatekot ?!

    A legtöbb AAA játék C++. Eleve konzolokon csak aláírt binárisok futhatnak, így ott nem lehet JIT-elni sem.
    Mutasd a teljes hozzászólást!
  • Hagyd rá, nem érdemes vele vitatkozni!

    Szerinte az, hogy a natív kód (futtatáskor) egy-az-egyben "CPU-ul" íródott, míg a JavaScriptet még értelmezni is kell, nyilvánvalóan éppúgy nulla (sőt, negatív) erőforrásnyereséggel jár, mint az, hogy az interpreternek/JIT compilernek az interpretált nyelvekben használt adattípusokat kódelemzéssel kell kikövetkeztetni, míg a natív kódban ezek az adattípusok adottak.

    Az is, hogy a garbage collector - itt már nem is az interpretált- "csak" a menedzselt nyelveknél tartunk, amik teljesítménykritikus (pl. játék-)fejlesztésnél a rosszabbik megoldást képviselik - mikrociklusok százait (akár a futásidő 5-15%-át) azzal tölti, hogy "futkos a szétgurult változók után", amely költség natív kódban egyszerűen nem létezik.

    A JavaScript gyorsabb, mint a natív kód, mert Sting úgy gondolja. Sluszpassz!
    Mutasd a teljes hozzászólást!
  • Azert ne rohanjunk annyira elore, hol fejelsztenek ma c++-ban jatekot ?! Nem sok helyen. Meg miota van ARM-on SSE ?
    A sebesseget meg leginkabb ket dolog szabalya meg, az algoritmus, meg a libek amiket hasznalsz. Irhatod asm-ben is a kodot, de ha meghivsz egy matlibet, ami lassu, az hiaba az erofeszites. .Net-el is az a baj, hogy lassuak a libek sajna, igazbol nincs tuti megoldas.
    Mutasd a teljes hozzászólást!
  • Hát most amit linkeltél az mondjuk egy 2ds kockákra épülő kb max 100 egységgel mahináló rts-szerűség....

    Ezek szerint akár háromszor annyi egységgel is simán operál, mint amennyi esetében te az előbb már a JavaScript elvérzését vízionáltad. Tehát még így is bőven cáfol téged. Ha tényleg "max. 100 egységgel mahinál" - amely számhoz gondolom a hasadra ütéssel jutottál el.

     Hol van ez egy sc2-höz képest?? Sehol..

    Pont ugyanott van az SC2-höz képest, mint ahol a gépigénye is van ahhoz képest.

    Hát pedig eléggé ez a helyzet.

    Csodálom a kitartásod, amivel a nyilvánvaló tények, bizonyítékok (adott esetben a videókon látható, nyilvánvalóan kiváló színvonvalú és megfelelő sebességgel futó játékok) ellenében is ragaszkodsz ahhoz, amit igaznak szeretnél tudni - bár nem az.

    Hol fogsz te mondjuk js-ben kiszámolni 300 különbözőn animált karaktert, mindegyiket mondjuk 50-60 csonttal?

    Bárhol, bármikor. Nem mintha létezne olyan valós játék, amiben 300 darab, egyenként 50-60 csonttal rendelkező karaktert animálnának egyszerre.

    Jsben senki nem fog neked SSE utasításokkal mátrixokat szorozni....

    Nem tudom miért kell osztani az észt olyan témában, amihez nyilvánvalóan lövésed sincs.

    Sem mondjuk 100000 részecskét szimulálni fizikai tárgyakkal való ütkötéssel együtt (cpu-n).

    Mivel a fizikai szimulációk egy ideje már nem a CPU-kon futnak, illetve mivel az ilyen szimulációs motorok a korábban említett API-k mögött vannak elrejtve, és natív játékok esetében sem a játék kódjában/-ból vannak implementálva, ezért a felvetésed nem csak irreleváns, de értelmetlen is. Mert hogy a gyakorlatban nincs szükség arra, hogy a CPU-n szimuláljuk 100.000 részecske ütközését, és mert az nem a játék kódjából történik - így ebből a szempontból is tök mindegy, hogy a játék kódja milyen nyelven lett megírva, és hogy ezzel összefüggésben az milyen vélt vagy valós sebességkorlátot jelent.
    Mutasd a teljes hozzászólást!
  • Egyrészt mivel az asm.js is JavaScript, azért semmi értelme annak, hogy megpróbálod attól külön kezelni. Illetve maximum annyira értelmes, mint ha mondjuk a C-t külön kezelnéd a C++-nál. Amit viszont magad sem teszel ezen vita vonatkozásában, hiszen közvetkezetesen magad is C/C++-ként, kvázi egyként hivatkozol rájuk.

    Másrészt az sem igaz, hogy asm.js "fordítótt C/C++ kód" lenne. Nem az. Az asm.js kód éppen annyira fordítótt C/C++ kód, mint amennyire a Linux kernel fordított BASIC kód. Asm.js kódot rendkívül sokféle úton lehet generálni - amik között lehetőségként ott van az is, hogy a C/C++ kódból generált köztes bájtkódot fordítunk át rá. De számtalan másik nyelvet is át lehet fordítani rá, illetve az asm.js/JavaScript kód is átfordítható C/C++ kódra. Lényeg a lényeg: az asm. nem fordított C/C++ kód.

    A harmadik dolog, hogy itt lehet elméleti szinten okoskodni, hogy mennyire lassú - kellene, hogy legyen - a JavaScript meg a böngészős környezet, de a puding próbája az evés. Ez pedig azt mutatja, hogy bizony ezek manapság már bőven elegendően sebesek tudnak lenni a legkomolyabb játékok futtatására is. Lásd mellékelt videók!
    Mutasd a teljes hozzászólást!
  • Hát most amit linkeltél az mondjuk egy 2ds kockákra épülő kb max 100 egységgel mahináló rts-szerűség....
    Hol van ez egy sc2-höz képest?? Sehol..

    Felejtsük már el ezt a hülyeséget, hogy JavaScript=lassú, natív=gyors!

    Hát pedig eléggé ez a helyzet. Hol fogsz te mondjuk js-ben kiszámolni 300 különbözőn animált karaktert, mindegyiket mondjuk 50-60 csonttal? Jsben senki nem fog neked SSE utasításokkal mátrixokat szorozni....
    Sem mondjuk 100000 részecskét szimulálni fizikai tárgyakkal való ütkötéssel együtt (cpu-n).
    Mutasd a teljes hozzászólást!
  • Felejtsük már el ezt a hülyeséget, hogy JavaScript=lassú, natív=gyors!

    Ezzel azért vitatkoznék, habár szerintem csak trollkodsz ilyenkor és csak azt szeretnéd, ha sok hozzászólás születne egy cikkhez. Max az asm.js esetén beszélhetünk natív kódot megközelítő sebességről, de ott is csak egyes esetekben. Az Asm.JS meg ugye lényegében fordított C/C++ kódot jelent manapság. Sima JS sebességben távol van a natívtól. Pont most akarják a Chromosok X+1-ére megreformálni a JS-t.

    Strengthening JavaScript
    Mutasd a teljes hozzászólást!
  • Itt adódik az, hogy a webes js tesztekben szépen szerepel, de ha már valami bonyolultabb tömbcímzéses matekos lebegőpontos számítást kell csinálni, akkor totál elvérzik.

    Mint azt láthatjuk a cikkbe fűzött videókon is, és még számos más böngészős játék esetében is. Igen, stratégiai jellegűekben is. Amik döccenésmentesen futnak a böngészőben, annak ellenére, hogy a grafikai megvalósítás, kidolgozottság, stb. tekintetében is simán összemérhetők a natív játékokkal.

    Felejtsük már el ezt a hülyeséget, hogy JavaScript=lassú, natív=gyors! Nem igaz, és soha nem is volt az. Ami igaz volt valamikor, jó régen, az az volt, hogy a JavaScript futtatómotorok és kódgenerátorok közel sem voltak annyira kidolgozottak, mint mondjuk a C++ fordítók, amiket már évtizedek óta csiszoltak. Meg az volt igaz, hogy a JavaScript-ben és a böngészőkben korábban nem álltak rendelkezésre olyan magasszintű API-k, mint a natív környezetekben - így minden adatot, grafikát, stb. sokkal szűkebb keresztmetszeteken kellett átpasszírozni, illetve a hardverarchitektúra sajátosságait megismerni és kihasználni képtelen alkalmazáskódban kellett (re)implementálni.

    Ezért aztán a böngészőkben futó, JavaScript-ben írt/ábrázolt programok valóban lassabban működtek - ugyanolyan lassan, mint amilyen lassan működtek volna akkor is, ha ugyan C++-ban lettek volna megírva/ábrázolva, de ugyanilyen béna fordítókkal fordítottuk volna le őket és API-k szempontjából ugyanilyen korlátos környezetben kellett volna futniuk.

    Az igazság az, hogy imperatív, általános célú nyelvek esetében a futási sebességnek nagyjából semmi, illetve maximum marginális köze van ahhoz, hogy az adott program konkrétan milyen nyelvben van megírva. Ehelyett a sebességet elsődlegesen az határozza meg, hogy a tárgykódot generáló fordító (legyen az különmenetes, vagy JIT) mennyire kiforrott, mennyire jól tud optimalizálni, illetve, hogy a program a futása során mennyire tudja a műveleteit ténylegesen végrehajtó hardver sajátosságait kihasználni, azokhoz igazodni. Pl. úgy, hogy magasszintű API-kon át programozza azt, amik mögött a hardver mindig úgy "varázsol" ahogy tud és akar, illetve ahogy esetében a legoptimálisabb.

    Ezek voltak azok a faktorok, illetve lehetőségek, amik tekintetében sokáig nem hogy egy szinten nem voltak a böngészős és az úgymond natív környezetek, de fényévekre voltak egymástól - mert az egyikbe sokkal több energiát öltek , mint a másikba. És ezek azok a faktorok és lehetőségek, amikben ma, ahogy a böngészős környezetekbe is egyre több energiát ölnek (sőt, már lassan többet, mint natívba), kezd a két platformtípus fej fej mellé érni egymással. Ennek következményeként pedig a bennük működő programok sebessége is ugyanezt teszi.
    Mutasd a teljes hozzászólást!
  • Azt azért tegyük hozzá, hogy nagyon nem játékfejlesztésben utazom

    Ez látszik a hozzászólásodból.

    Sajnos igenis sokat kell a játékokban a CPU-n számolni. Vegyük csak pl animációt alapul. A gpu skinnelni tud, de a mátrixokat pl a cpun kell kiszámolni hozzá.
    Ráadásul a gpunak minden felületnél át kell adni egy csomó paramétert: shader, renderstate változások, textúra váltások, ezeket mind rendszerhívások, ami rengeteg cpuidőt felemészt. Ezek minimalizálása pedig szintén egy csomó számolás.
    Továbbá a gpu sem tud mindent kirajzolni, tehát egyszerüsíteni kell, LOD szintek számítása, frustum culling vagy további láthatósági vizsgálatok, mind a cpu-t terhelik.
    De persze ne menjünk el a játék számításai mellett sem: pl egy rts-ben elküldessz A-ból B-be a teljes mapon keresztül 30-egységet, akkor azok útvonalszámítása, a domborzatot, a többi egységet figyelembe véve igencsak számításigényes feladat.
    Szóval a cpunak is vannak kemény feladatai bőven a mai játékokban. Itt adódik az, hogy a webes js tesztekben szépen szerepel, de ha már valami bonyolultabb tömbcímzéses matekos lebegőpontos számítást kell csinálni, akkor totál elvérzik. Kis demókat lehet írni benne, de kb ezzel ki is fújt a lehetőségek száma.
    Mutasd a teljes hozzászólást!
  • A Chrome fejéesztő csapat pont most állt elő a SoundScript-el, mivel:

    Performance. Optimising JavaScript is hard. Contemporary VMs use runtime profiling and many smart heuristics to optimise dynamically - and they have gotten very good at it. Ironically, the smarter they get, the harder it becomes for programmers to predict performance. Falling off a performance cliff with seemingly innocent changes is common, and preventing it a black art.

    Szóval a JS optimalizálását egynesen fekete mágiához hasonlították, mert egy ártatlan, vagy annak látszó változtatás is drasztikus teljesítmény csökkenéssel jár.
    developers.google.com/v8: Strengthening JavaScript
    HN:
    https://news.ycombinator.com/item?id=9178765
    Mutasd a teljes hozzászólást!
  • 40 fôs WOW raid. Na ott a rengeteg player szinkronizaciojatol megizzad a cpu.
    Vagy pl. RTS-nel elkezd husz tank egyszerre raketazni. -> World in conflict. Es nem 24x21 felbontasu spriteokkal vannak megoldva a robbanasok :D
    Minel tobb csillivilli latszik, annal tobb lathatosagvizsgalat, lod-ozas is kell: pl. Arma, amiben 2 km a latotavolsag.

    Es nem muszaj a legujabb i7-et valasztani. Nekem egy 20ezres phenom 2-om van 2ghz ramokkal, na az eppenhogy 60hz-el megbirja a PS3 szintu jatekokat. A GTA 5-nel meg majd meglássuk :D
    Mutasd a teljes hozzászólást!
  • Nekem egy tisztán CPU számításokra támaszkodó programnál (a Mandelbrot-halmazt számolta) a GCC -o3-as kapcsolóval kétszer olyan gyors kódot fordított, mint a Chrome, az -o3-as kapcsoló nélkül ugyan az volt a két idő. Ez volt egy éve. A mérést nem ismételtem most meg, de valószínűleg a Chrome faragott már ebből a lemaradásból.

    Egy játékban tudtommal a processzorra nem marad túl sok dolog:
    * ütközésvizsgálat (amire azért elég optimalizált algoritmusok vannak és egy 10 éves játékban sem az ütközések bénák)
    * fizikai szimulációk (ami lehet trükkösebb, de láttam már meggyőző szimulációkat JS-ben)
    * MI és interakció, amit egy "natív" játékban is kiszerveznek valamilyen scriptnyelvbe

    Ami a csili-vili grafikus részt illeti, ahhoz a böngészőnek nincs sok köze. Ugyanúgy átad minden feladatot a grafikus kártyának, ahogy azt egy natív alkalmazás tenné. Ha bejön az WebCL, akkor még az ütközésvizsgálat és a fizikai szimuláció nagy része is átmegy GPU-ra, a CPU-n meg tényleg alig marad valami. Nem hiszem, hogy a kétszeres lassulás lenne az üvegnyak.

    Más történet, hogy a JS-t nem szeretem túlzottan, de ez nem szeretem-nemszeretem kérdése. Meg vannak akármi -> JS fordítók is. (Bár azokat még annyira sem szeretem. )

    Azt azért tegyük hozzá, hogy nagyon nem játékfejlesztésben utazom.
    Mutasd a teljes hozzászólást!
  • Szerinted egy 2GHz core2 duo  + gtx980 ugyanazt nyújtja majd, mint egy 4 magos i7 4GHz + gtx980? Szerintem vannak játékok, amiknek kell az erős CPU is, de persze nyilván nem mindnek.
    Mutasd a teljes hozzászólást!
abcd