[Yany]

Ezt a 25 fps-t hagyjuk már békén. *rva régi tévhit az egész. Egy laikus is észreveszi még az NTSC 30 és PAL 25 fps-e között is a különbséget. Ha akarom, folyamatosnak látok én 5 fps-t is. Játékoknál meg ráadásul ott van az a bizonyos diszkrét megjelenítés (értsd: egymástól teljesen elszeparált explicit állapotok, egymáshoz képesti elmozdulás információja nélkül), míg a mozifilmek és egyéb kamerás felvételek esetén a záridõ különbözõ beállításaitól függõ mértékû motion blur alakul ki a filmkockákon. Ezek a képkockák ezáltal sokkal több vizuális információt hordoznak, s igaz, hogy mondjuk 25 fps-sel vetítjük õket, de önmagukban is közlik a kép tartalmának elmozdulásait. Csodálnám, ha az itt írottak mindenkinek újat mondanának, csak szeretném elkerülni ennek a "bûvös" 25 fps-es határszámnak a felemlegetését... nincs ilyen, hogy 24 még szaggat, 25 meg már folyamatos. pont.

szerk.: annyiban pontosítanék, hogy ma már azért a játékok is élnek a gpu-k erre kihasználható teljesítményével és már látni hébe-hóba motion blur-os terméket (pl. crysis), de szvsz perpill épp annyi erõforrásba kerül a számítása, mint amennyivel több fps-t kaphatnánk helyette... de nyilván ez túlzás, különben nem sok értelme lenne (vagy nincs is? szabad pontosítani )

Szerkesztette: Yany 2009. 01. 29. 00:16 -kor

[sutyi^]

Idézet: vipisrac - Dátum: 2009. jan. 28., szerda - 23:48

Ja, alapvetõen ez igaz, ezt írom már 2 oldal óta.

De azt vegyük észre, hogy nincs olyan, hogy "általános interpoláció". Persze, van egy rakás dolog, amit tudsz így kezeli két keyframe között, ahogy te hívod. De van egy rakás, ami game engine függõ, akár irányítástól, akár fizikától, akármi mástól függ. Abból se te se a vga nem interpolál semmi értelmeset, ott a belsõ idõzítésen is gyorsítani kell, hogy finomítsd a mozgást, megjelenítést.

Mindig a leglassabb elemhez van igazítva az egész.


VGA-tól vonatkoztassunk már el banyeg. Amit Abu próbált elmagyarázni az az hogy ha a motor egy 25fps-es minimumhoz, tehát 40ms-os intevallumokra van ütemezve.

Ez alatt az idõ alatt a motor kitalálja neked hogy mire lõttél, ha lõttél, az AI melyik ajtófélfában akadt el, milyen hangokat kell megszólaltatni, közben ütemezi az egészet a menetközben renderelt kékkockákhoz. De az animációs rendszer, meg a hang, meg a fizika is mind saját ütemben ketyeg, remélhetõleg gyorsabban mint a sceneidõ. Az egész szarnak a sebességét pedig a leglomhább alkotó elem határozza meg.

Abu meg annyit akart mondani hogy játék mechanikai szempontból hót mindegy hogy 25fps-el, vagy 62fps-el játszol, mert ugyanakkorát ugrik, a láda/sörösüveg ugyanúgy gurul, stb.

Máskérdés hogy a szemednek ez közelsem nyújt elegendõ látványt. Ugyanakkor ott vannak a hatszázéve foltozott Q3 motoron alapuló CoD-ok amikben ez felborul ha retkes sok az fps mivel ahoz van idõzítve elég sok minden, mászhatsz falat, ugorhatsz magasabbra, salalala.

[vipi]

Idézet: Yany - Dátum: 2009. jan. 29., csütörtök - 0:07

Amit írsz, az hardware réteg. Annak nem sok köze van egy motor architektúrájához, hogy a fizaka alrendszert éppen cpu, gpu, vagy ppu számol. Ettõl még nem keveredik össze a render motorral a fizika. Más okok lehetnek, de ez nem olyan.

Nem, nem hw-ról írok, hanem alapvetõen sw-rõl.

Arról beszélek, hogy ha van 1. állapotod és a 2. állapothoz fizikai számítás kell, akkor a játék motorod (vagy egy része, mondjuk a fizikai számítások - a lényeg, hogy egy idõzített folyamat és nem a relatíve szabadjára engedett megjelenítõ szál!!) fognak futni és nem a render réteg fog neked számolgatni köztes 3d állapotot.

(Az már más kérdés, hogy hw szinten is keveredni fog, ami szintén lehet szopás, hisz egymástól elvben független rétegek (ugyanazon hw-t érintve) fognak egymásra hatni.)

Idézet: Yany - Dátum: 2009. jan. 29., csütörtök - 0:14

Ezt a 25 fps-t hagyjuk már békén. *rva régi tévhit az egész.

Nem én jöttem ezzel elõ. Én épp azt mondom, hogy MB meg minden ellenre mgé egy mozifilm sem folyamatos, ha jól megnézed magadnak mondjuk 3 másodpercig. 

Idézet: sutyi^ - Dátum: 2009. jan. 29., csütörtök - 0:22

Mindig a leglassabb elemhez van igazítva az egész.


VGA-tól vonatkoztassunk már el banyeg. Amit Abu próbált elmagyarázni az az hogy ha a motor egy 25fps-es minimumhoz, tehát 40ms-os intevallumokra van ütemezve.

Ez alatt az idõ alatt a motor kitalálja neked hogy mire lõttél, ha lõttél, az AI melyik ajtófélfában akadt el, milyen hangokat kell megszólaltatni, közben ütemezi az egészet a menetközben renderelt kékkockákhoz. De az animációs rendszer, meg a hang, meg a fizika is mind saját ütemben ketyeg, remélhetõleg gyorsabban mint a sceneidõ. Az egész szarnak a sebességét pedig a leglomhább alkotó elem határozza meg.

Abu meg annyit akart mondani hogy játék mechanikai szempontból hót mindegy hogy 25fps-el, vagy 62fps-el játszol, mert ugyanakkorát ugrik, a láda/sörösüveg ugyanúgy gurul, stb.

Máskérdés hogy a szemednek ez közelsem nyújt elegendõ látványt. Ugyanakkor ott vannak a hatszázéve foltozott Q3 motoron alapuló CoD-ok amikben ez felborul ha retkes sok az fps mivel ahoz van idõzítve elég sok minden, mászhatsz falat, ugorhatsz magasabbra, salalala.

De szerinted én nem fogtam fel és nem ezt mondom?

Csak azt lássuk már be, amit te is írsz, hogyha van lassabb idõzítésû folyamat, akkor kirakhatok 1000 framet másodpercenként, kurvára ugyanaz lesz mind. Tényleg ugyanúgy gurul a láda, stb. Magyarul szart sem ér az egész.

A játékokban meg azé' mintha nem ez lenne. 25 helyett 80 fps és minnyá...
1. folyamatosabb a kép
2. jobb az irányítás
3. felmászol a falra

Szóval akkor hol az a kurvára fixen leszabályzott 25fps limit akármelyik részére motornak?
Sehol. És ezzel indítottam az egész hozzászólásom Abu felé... 25fps bámulni is kevés (Lásd Yani írását is), interakcióra meg pláne.

(a vga-tól és más egyébtõl meg épp azért nem lehet elvonatkoztatni, mert ezek egybefolynak, ahogy írtam. valahogy soha nem sikerült még teljesen fps független játékot gyártani. elég világos, hogy miért.)

Szerkesztette: vipisrac 2009. 01. 29. 00:37 -kor

[NetTom]

Mindenki leírta ugyanazt, csak a saját "ízlése" szerint....

Egyébként a felsõ limit meg tényleg a monitok képfrissítési frekvenciája.

Szerkesztette: ThomasS31 2009. 01. 29. 07:10 -kor

[NetTom]

Idézet: vipisrac - Dátum: 2009. jan. 29., csütörtök - 1:24

A játékokban meg azé' mintha nem ez lenne. 25 helyett 80 fps és minnyá...
1. folyamatosabb a kép
2. jobb az irányítás
3. felmászol a falra

Szóval akkor hol az a kurvára fixen leszabályzott 25fps limit akármelyik részére motornak?
Sehol. És ezzel indítottam az egész hozzászólásom Abu felé... 25fps bámulni is kevés (Lásd Yani írását is), interakcióra meg pláne.

Az animációs rendszerben, vagy nem tudom hogy hívják pontosan egy motorban.
Ott van ez a limit/ütemezés, ha tetszik. Úgy ahogy Yani irta. De ez csak ugymond a"key-frame"-eket számolja ki (ez még nem a megjelenítés!). Ezt a CPU és a GPU együtt állítja elõ attól függõen melyikre melyik része esik vagy bízza a motor írója (a fizikát, a tárgyak elmozdítását a térben, stb stb ahogy te is írod). Ezután jön a megjelenítõ rész ami viszont már nem limitált, hanem amennyire tudja kiszámítja a "key-frame"-ek közötti állapotokat is és lerendereli a frame-bufferbe az egyes képkockákat ahány FPS-el csak tudja. A monitorra meg innen kikerül 60/75/85/100 kép (Hz) attól függõen mit támogat (ezért jó, ha ez a kettõ szinkronban van, kölönben itt is framedrop/tear lehet). A másik framedrop meg a "key-frame"-nél lehet, ha a CPU/GPU páros nem tudja a minimális 25-öt sem elõállítani.

A mejelenítés/irányítás/mozgás "érzete" lesz folyamatosabb a nagyobb fps miatt, mert sokkal több átmeneti frame-ed lesz két "key-frame" között. Ha nagyon intenzív az elmozdulás (pl multiplayer õrület ) akkor nagyon nagy lesz a "key-frame"-ek közötti különbség és a köztes kiszámolt és megjelenített frame-k számán múlik mennyire folyamatosnak fogod "érezni". Ha kicsi az elmozdulás a két "key" között (pl egy mozdulatlan fal, tárgy), akkor meg tökmindegy hogy 5/50/500 fps, mert nem lesz jobb (folyamatosabb) érzetre sem.

A moziban ezt az érzetet a blur (ahogy sutyi és te is említetted) és egyéb trükkök (a kép 3x megszakítása/ismétlése) stb teszi folyamatosabb "érzetté", de attól még nem lesz több a "key-frame"... az marad 24.
PC-n nincs blur, mivel mindennnek pontos x,y,z helye van a térben és a képen (az elmosott valami ugye nem lenne pontosan meghatározható helyen ) ezért itt csak a "key-frame"-ek közötti frame-ek száma tudja az érzetet növelni. A jelenlegi blur megoldások pedig tényleg nem segítenek sokat általában, mert ugynolyan számításigényesek, mintha több fps-t tennének ki (ahogy Yani is irta).

Természetesen motion blur-ra gondoltam mindenütt.

Egyébként a konkrét "key-frame"/s tervezõi döntés, és biztos hogy változhat minden egyes motornál. Lehet 30, 60, 15...stb Pl egy stratégiai játéknál lehet kevesebb, autós vagy sport programnál lehet több... stb. Ami minimum kell a motor által hajtott játék céljához/folyamatosság érzetéhez. Az UT3 mivel általános motor, lehet hogy tényleg 25/40ms ahogy Abu tudja.

Szerkesztette: ThomasS31 2009. 01. 29. 08:10 -kor

[vipi]

Csak még két megjegyzés... újra.

Keyframe-ek. Inkább hívjuk idõzítésnek, ne keyframe-eknek. Ha két keyframe-ed (én ez egy teljes frame-nek értelmezem, vagyis egy komplett 3d pillanatképnek) lenne legyártva, akkor az a közötti állapotot meghatározni render interpolációval teljesen nem lehet. Egy rakás dolgot lehet, régi játékokban még többet lehetett, de mostanság a fizika miatt már nem igazán. Pl. van egy pálmafád. Nyilván a fizikai motor nem fogja számolgatni a saját ütemezése mellett a hajlongását. Ezt vehetjük úgy, hogy a fizikai motor mondjuk 40ms idõzítése közben a render szál interpolál valami köztes mozgást, hogy mondjuk 10ms ütemezéssel hajladozzon a fa. De egy komlex mozgásba jó eséllyel nem fog beleinterpolálni, mert az nem az õ dolga.

Ezer féle ilyen dolog van egy motorban, van amivel így trükköznek, vagyis a megjelenítõ motor a játék motor segítsége nélkül "beleemulál" egy köztes állapotot a motor idõzítésétõl függetlenül. És vannak amivel nem lehet/kell trükközni, mert a megjelenítõ szál nem tud vele mit kezdeni... ami meg tudna, mondjuk a fizikai szál, azzal meg feleslegesen nem számoltatnak dupla olyan idõzítéssel. Szóval ezek már logikai szinten sem különülnek el egymástól teljesen.

A második megjegyzés pedig az, hogy a fizikai, vagyis a hw szintet is bele kell keverni. Az a letisztított elméleti mûködés, hogy logikailag mindent el tudunk szeparálni. Amit látható fent, az sem megy a gyakorlatban, de ha menne akkor sem f*sza, mert ha fizikailag mondjuk a vga-ra bízol mást is, mint a megjelenítõ szál, akkor a megjelenítés lassúsága miatt a másik szál is szívni fog.

Vagyis összefoglalva:
1. Ha szétbontunk mindent logikai szinten külön szálakra: játék motor, irányítás, fizika, megjelenítés, stb... akkor is gáz van, ha ezek hw szinten nincsenek szeparálva. Mármint a megjelenítés az összes többitõl, mert ugye errõl folyt a vita, a megjelenítés (fps) és a játék folyamata (jelenet/feldolgozási sebesség) kapcsolatáról.
2. Tovább bonyolítja, hogy még logikailag sem bontunk szét minden folyamatot, mert ahhoz meg nem elég erõs a hw úgy összességében. Pl. a fizikai motor nem fog minden szart lekezelni, a fûszál lengedezés meg hullámzás egy sima interpoláció lesz, amit a megjelenítés függetlenül kezel, vagy 20fps-sel, vagy 220-al, ahogy tudja. A hordók meg mondjuk a fizika motor 50fps számítása szerint robbannak fel, oda nem interpolál semmit a megjelenítés, ha 250fps-sel fut akkor sem.

Az idõzítés meg idõzítés. Van, mert a legtöbb feladatnál szükség van rá, és az is látszik, hogy a fizikai és logikai egymásra hatások miatt nem egyszerû kezelni. De ez látszik is a játékokon, mint ahogy írtam. Alig találni olyat, ahol ne okozna problémát ez a függõség.

Ezzel én magamban le is zártam a témát.

[NetTom]

Idézet: vipisrac - Dátum: 2009. jan. 29., csütörtök - 13:26

A második megjegyzés pedig az, hogy a fizikai, vagyis a hw szintet is bele kell keverni. Az a letisztított elméleti mûködés, hogy logikailag mindent el tudunk szeparálni. Amit látható fent, az sem megy a gyakorlatban, de ha menne akkor sem f*sza, mert ha fizikailag mondjuk a vga-ra bízol mást is, mint a megjelenítõ szál, akkor a megjelenítés lassúsága miatt a másik szál is szívni fog.

Ez a rész szerintem nem ennyire gáz manapság. a GPU mostmár sokszáz/ezer "thread"-el dolgozik és mindegy neki hogy az épp megjelenítés vagy fizika. És nem is feltétlen lassítja a dolgot, sõt akár gyorsíthatja is. Ott van pl a CUDA-s PhysX-es játékok, ezek nem belassulnak attól, hogy mást is számol a GPU, mint megjelenítés.

Sõt a GPU/CPU konvergencia miatt (Larrabee féle architektúrák), egyre inkább többmindent fog egyszerrre csinálni. Csak a programozón múlik majd milyen motort ír és az erõforrásokat mire és hogy osztja be. Ezért haladunk a teljesen programozható GPU/CPU felé.

[vipi]

Idézet: ThomasS31 - Dátum: 2009. jan. 29., csütörtök - 13:09

Ez a rész szerintem nem ennyire gáz manapság. a GPU mostmár sokszáz/ezer "thread"-el dolgozik és mindegy neki hogy az épp megjelenítés vagy fizika. És nem is feltétlen lassítja a dolgot, sõt akár gyorsíthatja is. Ott van pl a CUDA-s PhysX-es játékok, ezek nem belassulnak attól, hogy mást is számol a GPU, mint megjelenítés.

Sõt a GPU/CPU konvergencia miatt (Larrabee féle architektúrák), egyre inkább többmindent fog egyszerrre csinálni. Csak a programozón múlik majd milyen motort ír és az erõforrásokat mire és hogy osztja be. Ezért haladunk a teljesen programozható GPU/CPU felé.

De a CUDA-s physx nem azért nem lassú, mert a GPU még foglalkozik vele plusszban, hanem mert nem egy lassabb egység foglalkozik vele.

Összességében azért fut jól, mert úgy van méretezve a fizika és a megjelenítés, hogy megférjenek egymás mellett. Az álalános célú hw ilyen szempontból jó irány, mert leveszi a programozóról az ilyen jellegû terhelés-optimalizáció problémáját.

Szerkesztette: vipisrac 2009. 01. 29. 13:22 -kor

[Breakbeat]

Fatal1ty nevével népszerûsíti 9400GT kártyáját az XFX

Hogy oda ne rohanjak.

Szerkesztette: Breakbeat 2009. 01. 30. 13:03 -kor

[NetTom]

Idézet: Breakbeat - Dátum: 2009. jan. 30., péntek - 14:03

Fatal1ty nevével népszerûsíti 9400GT kártyáját az XFX

Hogy oda ne rohanjak.

Épp terveztem venni egyet holnap... kell az irodai übergém gépbe egy, mert a fafality az csak jó lehet... :Р
Remélem van 1.5GB-os változat.

Szerkesztette: ThomasS31 2009. 01. 30. 13:27 -kor

[Breakbeat]

Idézet: ThomasS31 - Dátum: 2009. jan. 30., péntek - 13:26

Épp terveztem venni egyet holnap... kell az irodai übergém gépbe egy, mert a fafality az csak jó lehet... :Р
Remélem van 1.5GB-os változat.

Amivel majd menni fog a GTA4 is szépen.
Annak aztán kell a sok-sok VRAM, meg Fatal1ty neve is. :Ð

[Abu85]

HD4830 CF vs. HD4870
Elképesztõ milyen hatékony a CrossfireX, ha kiütjük a CPU limitet.

[SATAN]

Idézet: Abu85 - Dátum: 2009. febr. 2., hétfõ - 12:25

HD4830 CF vs. HD4870
Elképesztõ milyen hatékony a CrossfireX, ha kiütjük a CPU limitet.

jah ez a 4830 CF jo konstrukcio. Foleg hogy realative olcson lehet venni 4830 at.
Csak meg mindig az a baj hogy felnek sokan a 2 gpus rendszerektol.

[-Turbo-]

ja, ez nagy baj... miben is érint téged?    egyékbént továbbra is szar a multi gpu, a cpu limitet "csak úgy" nem lehet kiütni    arról nem is beszélve hogy az új játékok többsége szarik az sli-re/cf-re és ugyanúgy megy mint egykártyán. 

[gemini]

Idézet: SATAN - Dátum: 2009. febr. 2., hétfõ - 11:53

jah ez a 4830 CF jo konstrukcio. Foleg hogy realative olcson lehet venni 4830 at.
Csak meg mindig az a baj hogy felnek sokan a 2 gpus rendszerektol.

egy másik probléma: egy jó kétkártyás rendszerhez intel alá is alaphangon 35k-s alaplap kell. amd mellé persze van olcsóbb, de ott meg nehezebb kiütni a cpu limitet. mire összehozol egy jó duplakártyás gépet ott vagy, hogy egy sima lapba veszel egy gtx280-at

[SATAN]

hat igen az alaplap az tenyleg problema.Nekem csak egy PCI-E van az lapomon es nem szeretnem egyenlore lecserelni. majd csak a Core procikhoz. addig marad nekem ez a 3200Mhz re huzott E4300 as.
Most talan sikerul melot talalnom es ha tenyleg bevalik akkor valszeg lesz VGA upgrade. De meg en is tanakodok hogy ruhazzak e be egy 4850X2 re vagy maradjak egy GTX260 nal.
Az uj tesztekben meggyozoek a 2 GPUs megoldasok de valahol ott van bennem hogy az nem biztos hogy igy lesz mindig.
Nah mind1. egyenlore meg nincs penz. ezen majd meg tanakodok ha meglesz ra a penz.

[Abu85]

Idézet: -Turbo- - Dátum: 2009. febr. 2., hétfõ - 13:04

ja, ez nagy baj... miben is érint téged?    egyékbént továbbra is szar a multi gpu, a cpu limitet "csak úgy" nem lehet kiütni    arról nem is beszélve hogy az új játékok többsége szarik az sli-re/cf-re és ugyanúgy megy mint egykártyán. 

Felnyomod a felbontást és a CPU limit máris egyre kisebb problémát jelent. Ennél jobbat nem nagyon lehet csinálni a multi GPU-val. Nekem már nagyon ritka, hogy nem mûködik ... teljesen kiforrott a technika, ahogy a teszt is mutatja.

[sebgutkopf]

Egy kötetlen topicban lenne egy kötetlen kérdésem vga karikkal kapcsolatban (ati).
A mai vga-k elvileg mind 2 monitort tudnak kezelni egyszerre. Eddig tiszta. Viszont szintén általános, hogy a 2 dvi csati között ott figyel valamilyen video/tv kimenet. Tehát fizikálisan akár 3 megjelenítõt is rá lehet kötni egy videó karira. Ilyen esetben mi történik?
Egyáltalán érzékeli, hogy 3 eszköz van rákötve és lehet 2 aktívat választani, vagy összeakad az egész és lutri melyik kettõ megy?

[Yany]

Idézet: Abu85 - Dátum: 2009. febr. 2., hétfõ - 10:25

HD4830 CF vs. HD4870
Elképesztõ milyen hatékony a CrossfireX, ha kiütjük a CPU limitet.

Tényleg jól mutat minden, csak ha valaki új cuccot vesz, akkor nem éri meg: egy 1 GB-os 4870-es 51-52-ért beszerezhetõ, míg 2 db 4830 az legalább 55 rugó. Igaz gyorsabb is... néha. Egyrészt az 512 VRAM nem túl hosszútávú a nyújtott teljesítmény fényében, ráadásul a CF-et vagy támogatja valami, vagy nem, míg az 1 GB-tal felvértezett 4870 mindig nyújtja, amit kell... és még kevesebbet is fogyaszt.

Vagy szép, jó -- én is így gondolom -- de egy 4870 számomra nyerõbb lenne. Inkább lemondanék pár képkocka teljesítményrõl, ha azt viszont mindig megkapom, az AMD kedvétõl és támogatásától függetlenül.

szerk.: azért a teljes igazsághoz hozzátartozik, hogy ahol mûködik a cf rendesen, ott az a "pár fps" különbség igencsak szignifikáns. Tehát ha a vásárló jelenlegi kedvenc játékaiban már támogatja a driver a CFX-et, akkor biztosra mehet a vásár és más a szitu, de ha valaki tutira akar menni ~hosszútávon, akkor a crossfire sajnos rizikós. (Abu, ha ezt meg tudnád cáfolni, akkor csak örülnék, de perpill úgy látom, hogy mindig a cf-es konfigokkal van a baj a driverek terén).

Szerkesztette: Yany 2009. 02. 02. 13:45 -kor

[gemini]

a CF vagy bármilyen 2 kártyás rendszer mindig is rizikós marad.