30fps vs. 60fps - filmeket akarunk vagy játékokat?

Az újgenerációs konzoloktól azt vártuk, hogy végre 1080p-s natív felbontásban játszhassunk, és a framerate tekintetében se kelljen kompromisszumokat kötnünk. Ez azonban nem így történt: az új jelmondat a filmszerűség és a 30fps!
  • Írta: InGen

Kommentek

#163
#162: "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). "
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.
#162
#161: "É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..."
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...
#161
#160: Akkor beidézem sokadjára is:
"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.
#160
#159: "Te egy folyamatos, órajelben mérhető szimulációról beszéltél. Abban én nem látom a fix ütemet :S."

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.
#159
#158: Te egy folyamatos, órajelben mérhető szimulációról beszéltél. Abban én nem látom a fix ütemet :S.

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 :)
#158
#150: Szeretném gyorsan 3 pontban rövidre zárni a vitát, mert mostanában nincs időm mint az látszik.

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.
#156
#154: metro1-2 ami érint, mindkettőt lazán vitte a hd6850esem.Nem ultra beállításokkal az tény, de 1920x1080 és nem tapasztaltam semmilyen fps zuhanást, vagy bármi más zavaró jelenséget. Grafikával is tökéletesen elégedett voltam. Szóval ha nem ragaszkodunk szigorúan a számokhoz, hogy 60 fps, vagy 50 akkor mindenki elégedett lehet.Őszintén kit érdekel, hogy van pár fps különbség, ha a játék folyamatos, nem akadozik, vagy töredezik a mozgása? engem tuti nem, így nem is ér semmilyen kellemetlenség.
#155
#154: Ezeknek a nagy részét a sok csoda-AA nyírja ki. 4xSSAA-nál már 3840x2160-nél rendereli a képet a videokártya, FullHD felbontás mellett. Ezek az effektek pont annyira jók, hogy az ember vegye a drága kártyát, mert ultimate grafikán rosszul fog futni a játék.
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.
#154
#153: http://ipon.hu/elemzesek/radeon_r9_290%28x%29_ar_teljesitmeny_bajnokok_a_csucskategoriaban/1915/5

Metro, Sniper Elite, BF4, Crysis 3, Rome Total War 2 stb. ott vannak a tesztek
#153
#152: Melyik játékot nem tudom futtatni 1920x1080 ban 60 fps-el ?
#152
#151: Egy annyit kifejeltettem, hogy tulajdonképpen nem is létezik olyan kártya a piacon...legalábbis közembereknek, amivel mindent lehetne futtatni 1080p 60fps kombóval...még a 2 konzol árába kerülő GTX TITAN se képes erre. Még az a benga nagy vadállat is leesik 50re egy egy játéknál uh tessék reálisan tekinteni a dolgokra és nem álom világban élni. Az állandó és stabil 1080p/60fps még elég távoli jövő...
#151
Annyi hozzáfűznivalót azért leírnék még, hogy bármit is mondanak a marketingesek, azért csodára senki ne számítson...ha figyelembe vesszük, hogy egy 130ezres készülékkel van lehetőség FULL HD-n 60fps-vel játszani már annak örülni kéne, a pár kivételes esetet meg elnézni és nem kiakadni rá...A legolcsóbb PCs videokarik, amik hozni tudják a 1080p 60fpst kompromisszumok nélkül, azok minim 85ezerbe kerülnek pl: R9 280 vagy a GTX 770 (és sajnos ezek se mindig... Crysis 3, Tomb Raider, "csak" 40-45) s ez csak egy kártya...hol marad még a többi alkatrész? Szóval úgy érzem, hogy ár/érték arányban igen is nagy szó, hogy csak pár játéknál kell kompromisszumot kötniük a konzolos fejlesztőknek.
#150
#134: Elolvastam a belinkelt leírást és ennek fényében még reagálok, ha nem gond.

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....
#147
#146: OFF:
seggeszki 2.0...
Jajj, de jó h neked van heavy rained meg rdr-öd...
PC-n meg van dota 2,LoL,CS:GO (Normálisan supportolt),TF2,WoW, SC2. stb
és ezek közül sok F2P és fut egy 70k-s gépen is.
de igazad van neked van rdr-öd...
On:
Hiába csak 30 fps-el megy az adott játék, ha nem tudja 60 fps-el kipróbálni. Mármint arra gondolok h nem látja a különbséget, mert nem fut neki 60 fps-el, csak 30-al. Meg úgy is rááll az ember szeme 10 perc után az alacsonyabb képkocka számhoz. akkor meg tökmindegy. Az a lényeg, hogy ne legyen nagy különbség a cutscene-ek és a játék közt fps-ben.
#145
minél magasabb a framerate, annál realisztikusabb a film képi hatása, de ezzel fordított arányban csökken a film álomszerű hatása. ez pediglen ÓRIÁSI ZAVART okoz az agyunkban, mert 2D-és film akarja elhitetni a képi elemeivel hogy valóságos, ugyanakkor minden más érzékszervünk – amúgy, látásunkat is csak félig-meddig sikerül ezzel a trükkel becsapni - tiltakozik ez ellen. a Hobbit is gyomorforgató volt sokaknak a 48p miatt.

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.
#144
#143: And This Is Why We Can't Have Nice Things...