Az új konzolok megjelenésével ismét előtérbe került a régi kérdés: 30fps-sel vagy 60fps-sel fusson a játék? Ezt a kérdést persze máshogy is meg lehet fogalmazni: feláldozzuk a játszhatóságot a grafikáért cserébe? Utóbbi persze már nem hangzik túl jól, így általában a különböző stúdiók inkább olyasmiket mondanak, hogy "filmszerű élményt akarunk", amikor azt próbálják megindokolni, miért is nem a minden tekintetben sokkal jobb játékélményt nyújtó 60fps-t választják. Mielőtt azonban jobban belemegyünk ebbe a problémába, ami sajnálatos módon egyre jobban átszövi az új játékokat, nézzük meg, miért fontos ez az egész.
Miért pont 30fps vagy 60fps? Nos, az egész a HDTV-k és modern monitorok képfrissítésére vezethető vissza. Alapvetően arról van szó, hogy egy modern megjelenítő, amire konzolt (vagy PC-t) lehet kötni jellemzően 16ms (milisec) időközönként tudja frissíteni a képet. Ha ennek megfelelően a játék is 16ms-esnként küld ki új képet a megjelenítőre, akkor az 60fps-t eredményez. A másik lehetőség, hogy csak 33ms-enként küldünk ki új képet, ilyenkor a végeredmény 30fps. A kettő közötti ingázás pedig több szempontból sem jó. Egyrészt, ha a frissítés pillanatában még nincs kész teljesen a következő kép, akkor a végeredmény csúnya screen tearing lesz, ami a legtöbb játékost zavarja. Ezen kívül pedig az ingadozó framerate bizonytalanná, kiszámíthatatlanná teszi az irányítást.
Az pedig viszonylag könnyen belátható, hogy ha egy fix hardveren (konzolon) a játék motorjának 16ms alatt kell végeznie egy teljes képkocka kiszámításával, a rajta található összes grafikai effektussal, textúrákkal, eseményekkel, mindennel, akkor nyilvánvalóan kevesebb csili-vili férhet bele egy képbe, mintha ugyanerre a műveletre 33ms állna rendelkezésére. PC-n persze a dolog nem ekkora "probléma": ha van pénzünk, akkor olyan erős hardvereket veszünk, hogy még a legdurvább grafikai beállítások mellett is tudjon végezni a gép 16ms alatt egy képkockával. Konzolon azonban nincs meg a hardverfejlesztés lehetősége, így a készítők egy dolgot tudnak tenni, ha jobb grafikát akarnak: feláldozzák a 60fps-t.
Ami probléma, ugyanis ez alapvetően vesz el a játszhatóságból, aminek pedig egy játék legfontosabb részének kellene lennie - hiszen azért hívják játéknak. Nem csak azért, mert adott idő alatt jóval kevesebb képkockát látunk, így kevésbé simák az animációk, kevésbé folyékonyak az effektusok, hanem azért, mert ez közvetlenül befolyásolja az irányíthatóságot. Nyolc általános matekkal szintén könnyen belátható, hogy ha egy képkocka 16ms helyett 33ms alatt készül el, akkor ha mi megnyomjuk a lövés gombot a kontrolleren, akkor azt leghamarabb 33ms múlva láthatjuk viszont a képernyőn. A gyakorlatban persze ez nem így működik, ugyanis az új képkocka késleltetése mellé bejön még a kontrollertől érkező késleltetés, és persze a tévé késleltetése is (amíg a beérkezett jelet a HDTV meg tudja jeleníteni a képernyőn).
Mivel a tévé késleltése nyilván készüléktől függően változik, erre nehéz egzakt számokat mondani, így egy játék teljes késleltetését a gomb megnyomásától szokták mérni addig, amíg a konzol ki nem küldi a jelet a tévére. Ez pedig egy 30fps-es játéknál a legjobb esetben körülbelül 133ms, míg egy 60fps-es játéknál egészen 67ms-ig mehet le. Vagyis a felére, ami marhára nem elhanyagolható. Amikor tehát egy stúdió azt mondja, hogy szebb grafikát szeretne, és ezért feláldozza a 60fps-t, akkor ezzel párhuzamosan rengeteg dolgot feláldoz, a legfontosabb, hogy a játékostól érkező input "feldolgozásának" gyorsaságát is.
Az Insomniac még a Ratchet and Clank Future: A Crack in Time fejlesztése után nyilatkozta, hogy valószínűleg ez volt az utolsó játékuk, ami 60fps-sel futott, ugyanis a 30fps-sel szemben nem mutatkoznak meg az előnyök a játékkritikákban, és persze nehezebben is tudják eladni a játékot, hiszen a screenshotokon nem mutatkozik meg a 60fps, az viszont igen, ha szebb a grafika. Sajnos tény, hogy a játékmagazinok tele vannak tróger kritikusokkal, akik semmilyen technikai felkészültséggel nem rendelkeznek, Egyedül azt képesek észrevenni, ha egy játék szép, azt viszont nagyon ritkán említik meg, hogy mennyire sima és közvetlen játszhatóságot ad a 60fps, így tehát nem csoda, ha a fejlesztők néha úgy érzik, feleslegesen dolgoztak.
Éppen ezért érdemes egy kicsit gondolkodni, mielőtt a Call of Duty grafikáját és engine-jét szidjuk. A Call of Duty ugyanis ellenállt ennek az egésznek. Az Infintiy Ward bevállalta, hogy a tudatlan kritikusok és a fikázó játékosok tömegei évről-évre szidják majd a játék grafikáját, cserébe azonban tükörsima, stabil 60fps-sel futott minden rész. Mielőtt tehát a Call of Duty motorját hordjuk el az anyjába, érdemes figyelembe venni, hogy az a motor 16ms alatt végzett minden új képkockával az Xbox 360-on és a PS3-on, és azért be kell látnunk, hogy messze nem volt olyan csúnya a grafika, mint amennyire azt sokan képesek felfújni. Az Infinity Ward ugyanis pontosan tudja, hogy egy olyan játék, mint a Call of Duty, egyszerűen nem lenne ugyanaz anélkül a gyors, pontos és válaszképes irányítás nélkül, amit a 60fps ad.
Sajnos ezt nem mindenki képes belátni. Éppen a múlt héten kaptuk meg az utóbbi idők egyik legdurvább, legérthetetlenebb magyarázkodását arra, miért fut a játék 30fps-sel 60 helyett. Igen, a Ready at Dawn stúdióról beszélek és a The Order: 1886-ról. A stúdió vezetője azt nyilatkozta, a fejlesztés során a legfontosabb prioritásuk a grafika, játékmenetet pedig "kénytelenek beletenni, ha már játékról van szó". Ezt követően kifejtette, hogy ugyan a 60fps nagyon jó, de nem filmszerű, a filmeknél használt 24fps azonban játszhatatlan, így inkább a 30fps-t választják. Ezután még hozzá tette, hogy 60fps-sel úgy nézne ki a játékuk, mint egy Discovery Channel-természetfilm.
Ugye nem kell mondanom, hogy ez a játékosok teljes hülyének nézése? Egy játékról beszélünk, ahol a játékos vezérel mindent, ahogy a játékélménynek és a játszhatóságnak kellene az elsődleges prioritásnak lennie. A játék nem film. Persze, ahogy már korábban említettem, az rosszul hangzana, ha azt mondanák, hogy "leszarjuk a játszhatóságot, mert szebb grafikát akarunk", de legalább ilyen szintű bullshittel ne etessék a népet. Főleg úgy, hogy egyébként a filmek esetében is csak egy rossz megszokás a 24fps - sok-sok évtizeddel ezelőtt pusztán azért választották ezt sztenderdnek, mert drága a filmszalag, és ez volt a legkisebb képkocka/másodperc, ami még nem teljesen nézhetetlen, de persze ehhez meg kell kínálni egy rakás motion blurrel és egyéb trükkel. Ahogy azonban a filmszalag végre kikerül a képből, és a digitális kamerák átveszik a helyüket, a filmesek is elkezdenek majd átállni - Peter Jackson már el is kezdte a 48fps-es Hobbittal, a következő pedig James Cameron lesz az Avatar folytatásaival.
Persze, akadnak olyan műfajok, amik nem feltétlenül követelik meg a 60fps-t. Például egy körökre osztott szerepjátéknál nem sokat számít az irányítás válaszképessége, így talán jogosan áldozzák fel a grafikai minőséget a sebesség oltárán - de azért az animációk, effektusok, képernyőn lezajló történések még így is folyékonyabbak, simábbak lennének 60fps-sel, ami azért számít. Amikor tehát valaki olyan marhaságokat próbál beadni a 30fps vs. 60fps vitában, hogy a 30fps "filmszerűbb" és "megfelelőbb a mi játékunk számára", akkor engedjétek el a fületek mellett, mert egy irgalmatlan baromság. Minden játék jobb 60fps-sel, ezen nem lehet vitatkozni, ez tény. Csak sajnos a modern AAA-kategóriás játékfejlesztésben egyre kevésbé fontos a játékélmény és a játszhatóság, és egyre fontosabb, hogy szép (kamu) screenshotokkal és trailerekkel beetessék a tömeget. Lassan az utolsó mentsvár a Nintendo lesz - bármennyit is bukdácsol manapság a japán cég, a Nintendónál mindig is a játékmenet volt az első, nem véletlen, hogy közel az összes játéka 60fps-sel fut.
Kapcsolódó cikkek
Akkor mit értesz az alatt, hogy látszólagos a folytonosság, mert órajel ciklusokra lehet bontani? Komolyan nem értem...
"Honnan szeded ezeket ezeket a baromságokat?"
Tőled, pontosabban az általad belinkelt leírásból. Ott azt írták, hogy amit én leírtam azért nem determinisztikus, mert gyorsabb gépen nagyobb frame-ratel fut. Emiatt nagyobb felbontásban történik a szimuláció is, ami azt jelenti, hogy többször végzed el a lebegőpontos műveleteket, ami meg valamennyire pontatlan. Ha ez nem elég, megjegyzésként még ilyet is írtak:
"Computers are naturally deterministic: they follow programs mechanically. Non-determinism appears when the messy real world creeps in. For example, networking, the system clock, and thread scheduling all rely on bits of the external world outside of the program’s control."
"Az is hülyeség, hogy lassú lenne. Két szál az kérlek nudli. Csak egy sima vindows legalább 150 szálon fut (csak önmagában a System, a gyermekfolyamatai nélkül).
Amúgy meg te kérdezted meg, hogy egy ilyen engine hogy futna el egy egymagos gépen. A válasz: tök egyszerűen."
ÁÁ értem. Tehát a szálak száma a fontos, nem az, hogy mit is csinálnak azok.
Nem hittem volna, hogy ezt le kell írnom...Így néz ki egy Windows ütemező:
Több prioritási szint van. Mindig a legnagyobb prioritású futásra alkalmas feladat fut, ha több is van akkor round rubin van. Egyik szálról a másikra nem szokás csak úgy átváltani: először el kell indítani az ütemezőt (contextus váltás, biztonsági mód váltás), majd az beütemez egy másik szálat (még egy kontextus váltás). Ez nem nulla idő, ha túl gyakran csinálnád, CPU időt veszítenél. Windows eseten 18-6 Quantum ideig fut egy szál (kivéve, ha le mond a CPU-ról), az 20-60 ms. Nálad van két szál, az egyik folyamatosan szimulálna (amikor írtam, hogy lassú, még nem volt szó timerről), a másik meg renderelne. A játék jellemzően egy előtérben futó folyamat, tehát 60ms-ot kapnak a szállak. Ez csak úgy fog normálisan futni, ha ha a renderelés, és az update végén és lemondanak a szállak a CPUról. Ekkor ott vagyunk, hogy jobb lett volna egy szálon futtatni, mert akkor legalább egy pár contextus váltás megúsztunk volna..
"Az asszinkron futásnak mint már írtam épp az a lényege, hogy nem szinkron."
Ezt nem úgy kell elképzelni, hogy elindít egy feladatot és utána szarni bele, nem kell vele foglalkozni. Abban a modellben pont az a lényeg, hogy apró részfeladatokat indítanak, a legtöbb olyan feladat aminek az eredményére szükség van. Ha ez nem készül el időben arra kapásból várni kell.
Le is van ám írva a működés: az aszinkron híváskor egy feladatot hoznak részre. Ezeket a feladatokat listázzák, és sorban elindítják a szabad magokon. Tehát egy lefutás alatt: 1 update, 1 simulate, 1 render feladat kerül be a listába (nyilván kicsit bonyolultabb de most itt ez a fontos).
" Ha egy lefutás alatt minden műveletből csak egyre van szükség, akkor fölösleges aszinkronizálnod."
Miért is? Van egy szál ami végez különböző feladatokat, köztük aszinkron hívásokat. Ha az nem aszinkron történne akkor blokkolná azt. Elérnéd, hogy a többmagos gépen egyszerre csak egyet használsz.
"Ami én leírtam csak abban különbözik attól amik itt le vanna írva, hogy nem tudtam mekkora a felbontás. De meséld csak be magadnak, hogy ez nem így van..."
Ja egy hét alatt eljutottunk oda, hogy végre sikerült linkeled valamit téged igazol. (Az első game loopos link még elég messze volt a leírásodtól)
Ha esetleg érdekel nézd meg a Unity és az Unreal működését.
Előbbi sorban elvégzi az említett műveleteket, csak az szimuláció lehet gyakoribb az fpsnél (az sem feltétlenül), de az input feldolgozás semmikép sem.
Unrealnál, meg ként fontosabb szál fut, az egyik a rendering thread a másik a game thread. Tehát egyszerre történik a szimuláció és a renderelés. A szimláció végén vagy megvárja hogy befejeződjön a renderelés is (ekkor egy "frame"-el jár előrébb a szimuláció), vagy meg lehet engedni, hogy akár 2 frame-el is elhúzzon. Ez is eléggé függ tehát az fps-től.
Ezt egy hete írtam, lehet még nem sikerült felfogni: "A szimulációs szál szinkronizál az abszolút idővel"
Azt csak úgy megjegyzem, hogy egy órajel ciklus alatt nem lehet egy egész szimulációt lefuttatni, mert egy i idő alatt egyetlen művelet kerül elvégzésre (egy magon). Eleve abszurd dolgokat akarsz a számba adni.
Az meg már egyenesen nevetséges, hogy az órajel-ciklusbontás nem determinisztikus. Honnan szeded ezeket ezeket a baromságokat? XD
Az órajel maga az egyenlő darabokra osztott idő (periodikus idő). Várj, szótagolom, hátha úgy megérted: óra-jel.
Ha igaz lenne amit írsz, akkor nem létezne olyan, hogy determinisztikus automata.
"Mert kell is, én továbbra is így látom. Azt meg tudom jól hogy az oprendszer ütemez.. Nem is tudom miből jött le hogy nem így gondolom..Írtam olyanokat, hogy az oprendszer elveheti a szál futási jogát. Azt is írtam, hogy a általad leírtak egy magon is elfutna, csak lassan.
Ezt is csak magadnak meséled be..."
Az is hülyeség, hogy lassú lenne. Két szál az kérlek nudli. Csak egy sima vindows legalább 150 szálon fut (csak önmagában a System, a gyermekfolyamatai nélkül).
Amúgy meg te kérdezted meg, hogy egy ilyen engine hogy futna el egy egymagos gépen. A válasz: tök egyszerűen.
"Attól, hogy aszinkron, hívja meg, még nem lesz gyakoribb a frame ratetől."
LOL, te elolvasod egyáltalán amiket leírsz? Az asszinkron futásnak épp az a lényege, hogy a nincs szinkronizálva más szállal. Ezért hívjuk a-szinkronnak szinkron helyett.
"Attól, hogy aszinkron, hívja meg, még nem lesz gyakoribb a frame ratetől. Egy lefutás alatt egy input feldolgozás, egy szimuláció, és render lesz beütemezve."
Hát ez nettó baromság. :D Az asszinkron futásnak mint már írtam épp az a lényege, hogy nem szinkron. Az igaz, hogy nem feltétlen gyorsabb a frame rate-nél. Lehet lassabb is. De az, hogy valami egyszerre történik ilyen végrehajtás során, annak elenyésző az esélye. Ha egy lefutás alatt minden műveletből csak egyre van szükség, akkor fölösleges aszinkronizálnod.
"Ja értem, szval amit te eredetileg leírtál az jobb? Szerintem még csak meg sem valósítható...Időközben ahogy utána olvastál, kiegészítetted, úgy hogy igazad legyen, de ettől eredetileg legalább annyira messze voltál a valóságtól mint én.."
XD Szánalmas vagy. Ami én leírtam csak abban különbözik attól amik itt le vanna írva, hogy nem tudtam mekkora a felbontás. De meséld csak be magadnak, hogy ez nem így van...
"Az fps csak azt adja meg, hogy ebben a "folytonos" (valójában itt is csak látszólagos a folytonosság, mert órajelciklusokra lehet bontani, de ezen ciklusok összehasonlíthatatlanul gyorsabbak még a 60fps-nél is) virtuális világból melyik pillanatokat látod."
Én itt csak egy időegységet látok az pedig az órajel. Innentől nem tudom mennyire valid azt mondani, hogy amit leírtam szar mert nem determinisztikus, miközben ez sem lehet az. Nem azért mert külön szálon fut...
"Vagy az, hogy egy szál futtatásához mindenképp dedikált mag kell."
Mert kell is, én továbbra is így látom. Azt meg tudom jól hogy az oprendszer ütemez.. Nem is tudom miből jött le hogy nem így gondolom..Írtam olyanokat, hogy az oprendszer elveheti a szál futási jogát. Azt is írtam, hogy a általad leírtak egy magon is elfutna, csak lassan.
Ezt is csak magadnak meséled be...
"Na, ezt hívják asszinkron feldolgozásnak, mert a különböző feladatok feldolgozása nem várja meg a másikat"
Van két modell is. Az egyiknél explicit leírja, hogy szinkronizálja a különböző feladatokat, a másiknál minden aszinkron történik.
Attól, hogy aszinkron, hívja meg, még nem lesz gyakoribb a frame ratetől. Egy lefutás alatt egy input feldolgozás, egy szimuláció, és render lesz beütemezve.
"Már ne is haragudjál, de a vitánk magját képezte az, hogy a szimuláció futhat-e az fps-től függetlenül. De igazad van, "csak" ezt bizonyítottam..."
Amit először linkeltél az nem független az fps-től...A szöveg, a kód és az ábra is ezt modja...Gondolom erre gondolsz, mert a most írtakról nem hiszem, hogy múlt időben beszélsz..
"Linkelhetek, de úgysem hiszed el"
Eddig, egyszer linkeltél, és amit ott sikerült igazolnod el is hittem. Ezt megint nem tudom miből gondolod...
"Én elismertem a tévedésem, rád ez eddig nem volt jellemző"
Megint, eddig egy állításodat igazoltad, azt el is ismertem...
"De elárulok valamit: nem nehéz egy olyannal szemben jobban tudni valamit akinek nagyjából évtizedes lemaradása van a game engine-ek működésével kapcsolatban."
Ja értem, szval amit te eredetileg leírtál az jobb? Szerintem még csak meg sem valósítható...Időközben ahogy utána olvastál, kiegészítetted, úgy hogy igazad legyen, de ettől eredetileg legalább annyira messze voltál a valóságtól mint én..
Szerintem zárjuk le a vitát, előrébb már nem hiszem, hogy jutni fogunk. Biztos igazad van, a háttérben fpstől függetlenül szimulál, dolgozza fel az input. Azt mondjuk nem látom, hogy miért is lesz kisebb így az input lag, szerintem az továbbra is az fps-től függ.
Ne találj már ki kérlek olyan dolgokat amiket én nem mondtam. :D
Én sosem mondtam, hogy a szimuláció órajelben mérhető. Már több helyen leírtam, hogy a valós idővel van szinkronizálva, de rugózzál még rajta, hátha akkor elhiszem, hogy tényleg ezt mondtam...
A folyamatosságban szerintem nem tévedtem, mert a szimulációs loop nem vár a frame frissítésére.
Abban igazad van, hogy én azt hittem gyorsabb a szimuláció üteme, nem értem miért hozod fel újra meg újra. Szerintem még így sem akkora tévedés, mint az, hogy szerinted a mai modern játékok amik sokmagos gépeken meg konzolokon futnak egy szálon renderelnek és szimulálnak.
Vagy az, hogy egy szál futtatásához mindenképp dedikált mag kell.
Vagy az, hogy a külön szálon futó ütemezett szimuláció nem determinisztikus.
Vagy, hogy te még sose hallottál olyan motorról ami asszinkron működ, tehát nincs is.
Mondtam hülyeséget valóban, de te meg már hevet-havat összehordtál.
"Én is belinkeltem egy könyvet, ott már több szálú működés is le van írva. Az ábra alapján ott is egy input feldolgozásra, egy szimuláció (gondolom fix időközökre bontva), egy renderelés jut."
Na, ezt hívják asszinkron feldolgozásnak, mert a különböző feladatok feldolgozása nem várja meg a másikat. Vannak olyan motorok ahol a renderelést, az input feldolgozását és a szimulációt is külön szálon végzik. De gyakran a szimulációt és az input feldolgozást egy szálra rakják, ha van egy kis sütnivalód kitalálod miért.
"Az általad leírtakból csak annyit tudtál igazolni, hogy az update lehet gyakrabban az fps-nél."
Már ne is haragudjál, de a vitánk magját képezte az, hogy a szimuláció futhat-e az fps-től függetlenül. De igazad van, "csak" ezt bizonyítottam...
"Viszont, nem folyamatosan fut"
Én nem láttam olyat, hogy várni kell a frame-re, tehát a loop folyamatosnak tekinthető.
"nem olyan felbontásban"
Igen, ezt már egy hozzászólással ezelőtt is leírtam (meg most is), hogy igaz, de írd le még párszor, hátha ettől mindenben igazad lesz...
"és az input feldolgozás is függ az fpstől."
Talán ha keményen gondolkozol, akkor rájössz, hogy miért érdemes minden szimulációs ciklus előtt kiértékelni az inputokat (egy kis segítség: az input laghoz van köze). Lehet azon az ábrán függ tőle, de reméltem át tudod gondolni, hogy miért jobb megoldás az amit én írok. Amúgy meg ahány engine annyi loop. Tudod jó páran fejlesztettek már motort, de a modern motorokra túlnyomórészt igaz amit írtam.
"Komolyan nem értem, miért nem tudsz bármit belinkelni ami igazolna téged. Annyira biztos vagy magadban, biztos olvastál róla valahol."
Linkelhetek, de úgysem hiszed el:
http://blog.slapware.eu/game-engine/programming/multithreaded-renderloop-part1/
http://www.researchgate.net/profile/Mark_Joselli/publication/236583142_A_Game_Loop_Architecture_with_Automatic_Distribution_of_Tasks_and_Load_Balancing_between_Processors/file/504635180e22bf2f94.pdf
Készségesen várom, hogy megmagyarázd, hogy ez mind baromság.
"Felőlem zárd le nyugodtan a vitát, könyveld el hogy mindent pontosan tudsz. Igazából nem is számítottam tőled semmi másra :)"
Én elismertem a tévedésem, rád ez eddig nem volt jellemző, de igazad van, biztos én szenvedek attól, hogy mindent tudok. Legyen, ha szeretnéd gondold nyugodtan ezt. De elárulok valamit: nem nehéz egy olyannal szemben jobban tudni valamit akinek nagyjából évtizedes lemaradása van a game engine-ek működésével kapcsolatban.
Ha a pszeudo kód és az ábra értelmezése nem megy, akkor legalább a szöveget olvassd el:
" At the beginning of each frame, we update lag based on how much real time passed. This measures how far the game’s clock is behind compared to the real world. We then have an inner loop to update the game one fixed step at a time until it’s caught up. Once we’re caught up, we render and start over again."
Én is belinkeltem egy könyvet, ott már több szálú működés is le van írva. Az ábra alapján ott is egy input feldolgozásra, egy szimuláció (gondolom fix időközökre bontva), egy renderelés jut.
"De mivel a többivel tévedtél, innentől kezdve már csak azon vitatkozhatunk, hogy mekkora volt a tévedésed mértéke."
Az általad leírtakból csak annyit tudtál igazolni, hogy az update lehet gyakrabban az fps-nél. Viszont, nem folyamatosan fut, nem olyan felbontásban, és az input feldolgozás is függ az fpstől.
Komolyan nem értem, miért nem tudsz bármit belinkelni ami igazolna téged. Annyira biztos vagy magadban, biztos olvastál róla valahol.
Felőlem zárd le nyugodtan a vitát, könyveld el hogy mindent pontosan tudsz. Igazából nem is számítottam tőled semmi másra :)
1. Ha a szimuláció folyton fix ütemben zajlik, mint ahogy azt a leírásban meg is adják, akkor az determinisztikus. Nem tudom hogy állíthatod, hogy nem, állítólag értesz hozzá.
2. A szimuláció az fps-től függetlenül, egy előre meghatározott fix ütemben történik, ergo külön szálon fut. A szimuláció ideje a valós idő szeletei, melyet minden processzor képes mérni. De ezt már írtam, nem tudom miért rugózol még mindig órajeleken.
3. Abban igazad van, hogy nem összehasonlíthatatlanul gyorsabb, de mindenképp gyakoribb mint a framek kirajzolása. De mivel a többivel tévedtél, innentől kezdve már csak azon vitatkozhatunk, hogy mekkora volt a tévedésed mértéke.
A Total War tényleg rosszul van optimalizálva. Bár azóta jött pár patch, ami javított az optimalizáláson.
Metro, Sniper Elite, BF4, Crysis 3, Rome Total War 2 stb. ott vannak a tesztek
Te azt a működést írtad le: fut egy nagy felbontású, folyamatos szimuláció, ami azonnal feldolgozza az inputot. A képek elkészítéséhez ebből mintavételez a játék. Tehát a szimuláció és az input feldolgozás teljesen független az FPS-től.
"...végére felvázolják az általam már többször leírt modellt."
Amit én ott látok az egy while ciklus, amiben egy ProcessInput(), Update() többszöri meghívása és egy Render() hívás történik. Ha ezeket sorban egymá után hívják meg akkor majdnem azt kapjuk amiről én beszéltem, annyi eltéréssel, hogy az eltelt időt nem egyben, hanem fix részekre bontva szimulálja le.
Ha ez a három művelet párhuzamosan fut, akkor még mindig ott vagyok, hogy meg kell várniuk egymást, hogy elkezdődhessen a következő ciklus. Tehát igenis függ a frame ratetől. (Kivéve ha mind3 művelet pontosan ugyanannyi ideig tart, ami nem túl valószínű)
"Az előbbi azért van mert nincsenek friss információid, utóbbi meg azért mert nincs elég szaktudásod, hogy belásd, hogy az általad lerít modell nem determinisztikus."
Tudnál esetleg példát adni rá, hogy melyik engineben valósul meg másként?
Vicces, hogy ahhoz elég szaktudásod van, hogy felismerd hogy amit leírtam az nem determinisztikus, de azt már nem veszed észre, hogy ez nálad is ugyanúgy probléma.
"valójában itt is csak látszólagos a folytonosság, mert órajelciklusokra lehet bontani, de ezen ciklusok összehasonlíthatatlanul gyorsabbak még a 60fps-nél "
Tehát a szimuláció felbontása az órajeltől függ? Mert akkor ez se determinisztikus. Vagy az "órajelciklus" a cpu sebességétől független? Valahogy nehezen hiszem el, hogy mondjuk 10us-os felbontás megvalósítható lenne...Pedig az még szerintem elég jól összehasonlítható a 60 FPS-el....
ha a játékok világát nézzük, akkor a fejlesztő felelőssége, hogy a játék hangulatának, típusának megfelelő hatást érjen el a játékos fejében. amennyiben multiplayer lövöldéről van szó, nyilván a magas framerate-et ajánlatos preferálnia, de teljesen helytálló lehet a Ready at Dawn érvelése, végül is az ő produktumuk interaktív mozinak készül.
szerintem.
en elvagyok az x360ommal :) mas nem is kell!!
pedig gamelesre alkalmas pcm van! (crysis 3 fullon megy!)
Nem mintha nem ez lett volna a reklám szöveg.. ...az első "kibaszott" naptól fogva.
Visszanyalt a fagyi.
Lehet le foglak törni, de a Sony is meg az Ms is egy középkategóriás APU-t rakott a konzolokba. Ez fog korlátozni a jövőre nézve nem a memória, ezt elhiheted."
Nem próbálom beigazolni, csak felhívni a figyelmed arra, hogy jelenlegi generáció is az volt, amikor indult pl. 360ban egy kicsiny 512es GDDR3 Ati...és lám GTA V megy rajta. Mutass nekem egy olyan 2006ban megjelent kártyát PC-hez, amin megy hasonló kaliberű játék manapság. Az optimizálás a lényeg még mindig ezt mondom...az meg szoftveres szintű, amin lehet javítani. PC-s változatokkal meg nem törődnek, mert ott a határ a csillagos ég...nem kell beleférni egy bizonyos szűk keretbe, mert lehet cserélni a dolgokat. Konzoloknál pedig mivel van ez a határ az optimizálás egyre jobb lesz és tévedésbe ne essünk...az optimizálás nem egyenlő grafikai külcsín vesztéssel. Elég, ha megnézzük 2005 végén milyen játékokkal jelentek meg az új konzolok, COD 2, GUN, Most Wanted és ahhoz képest most mik vannak...Forza, GTA V, RDR pedig a teljesítménye a konzolnak semmit nem változott, ennyit tesz az optimizálás és a jó soft. Régen az új konzolok megjelenésénél se volt hirtelen gigantikus ugrás, az is idővel érkezett el. Szóval én egyáltalán nem temetem az új generációt...mert idővel jönni fog minden a maga idejében, csak senki nem türelmes s mindenki szemorgazmust vár el az első naptól fogva...
Pontosan tudom, reméltem, hogy nem kell leírnom hogy mire gondolok mert magától értetődő: van kapásból két szálad: gpu api hívást végzi (neki kell a legnagyobb prioritás), meg egy ami a szimulálciót végzi. Innen már arra sincs nagyod helyed, hogy a szimulációban párhuzamosítsd. Ez így nagyon erőforrás pazarló, és már két magon is csak éppen elfutna.
"Olyan orbitális misskoncepcióid vannak, mint, hogy egy szál futtatásához szükséged van egy külön fizikai magra."
Mert szükség is van hozzá egy fizikai magra. Ha mondjuk I/O--ra vár akkor nem fut...
Abban valóban tévedtem, hogy az FPS-nél gyakrabban is megtörténhet a szimuláció, viszont még mindig nem látom amit te írtál.
Egyrészt az általad beidézett résznél nézd meg az ábrát is. Az ProcessInput csak Render után van, Update Game önmeghívásánal van egy kis óra ábra. Az a sleep akar lenni. Nem megállás nélkül fut, hanem 'often faster than 60 FPS'. Most e Ez minden csak nem "összehasonlíthatatlanul gyorsabbak még a 60fps-nél is".
"But be careful not to make it too short. You need to make sure the time step is greater than the time it takes to process an update(), even on the slowest hardware. Otherwise, your game simply can’t catch up."
http://forum.dronprogs.org/files_for_my_posts/books/GEA.pdf
Ebben a könyvben 120 HZ-es updatet hoznak fel példaként...
Valóban, én nem az input lagról beszéltem, mert szerintem az ebben a helyzetben nem fontos.
Most nem akarlak bántani, mert tényleg na, csak hát nem tudom hogy mondjam finoman. Te valami nagyon kókány-gyorstalpaló oskolában hallgattál informatikát. :D
Olyan orbitális misskoncepcióid vannak, mint, hogy egy szál futtatásához szükséged van egy külön fizikai magra. Elárulom, hogy csak azzal, hogy beizzítasz mondjuk egy Windows-t a gépeden szálak százai indulnak futásnak. És ennek ellenére egész jól elboldogulnak ezzel a feladattal még az egymagos gépek is.
Ennek oka roppant egyszerű, ugyanis a programszálak igen gyakran várnak például I/O műveletekre. Ilyenkor a processzor fogja magát és egy másik szálra vált. Persze ezen belül vannak nagyon finom eljárások, úgynevezett utilizációs rutinok amik meghatározzák a processzor szálkezelési stratégiáját. Ilyen például a priorizálás, az időosztás... stb. De a lényeg szerintem így is érthető.
"Ennek semmi értelme. Ezzel az erővel az általad leírt megoldásnál az órajeltől, és a szál tényleges futási idejétől függne a karakter sebessége."
A szimulációs szál szinkronizál az abszolút idővel, egy timer-nek nevezett eljárás segítségével.
"Gondolom sejted, hogy ha nem konzolon fut a játék, az oprendszer bármikor elveheti a szál futási jogát, a CPU órajele se feltétlenül állandó."
A játékok folyamatai általában magas prioritással futnak ezért nem szokta az oprendszer csak úgy elvenni a száltól a vezérlést, de ha ezt megteszi, akkor mindössze annyi történik, hogy megáll a játék.
"Legalább is én nem tudok olyan engine-ről ami nem így csinálná, meg értelmét se látom."
Az előbbi azért van mert nincsenek friss információid, utóbbi meg azért mert nincs elég szaktudásod, hogy belásd, hogy az általad lerít modell nem determinisztikus.
"Írd be google-ba h 'main game loop', gyakorlatilag arról beszélek."
Csak, hogy lásd én sem vagyok hajtatatlan megtettem. Rögtön az első találat ez volt:
http://gameprogrammingpatterns.com/game-loop.html
Ajánlanám neked olvasgatásra, mert sokat tanulhatsz belőle. Itt is először létrehoznak egy olyan primitív game-loopot mint amiről te is beszélsz. Majd elmondják, hogy ez miért nem működik a modern a játékokban és a végére felvázolják az általam már többször leírt modellt.
Kiemelem neked a lényeget:
"We’ll update the game using a fixed time step because that makes everything simpler and more stable for physics and AI. "
"Note that the time step here isn’t the visible frame rate any more. MS_PER_UPDATE is just the granularity we use to update the game. The shorter this step is, the more processing time it takes to catch up to real time. The longer it is, the choppier the gameplay is. Ideally, you want it pretty short, often faster than 60 FPS, so that the game simulates with high fidelity on fast machines."
Ha nem vagy még tag, regisztrálj! 2 perc az egész.