Valve L4D2: 6 FPS-től 315 FPS-ig Linux alatt

Játék

A Valve linuxos fejlesztői nemrég kezdtek blogolni munkájukkal kapcsolatban. Az első technikai blogbejegyzésükben - amely tegnap született - rendkívül érdekes témával foglalkoznak. A teljesítménnyel. A Left 4 Dead 2-t (L4D2) portolják Linux-ra és közben méréseket végeznek. A portolási munka során egy baseline-t állítottak fel egy Intel Core i7 3930k, NVIDIA GeForce GTX 680, 32 GB RAM paraméterekkel rendelkező vason.

Windows 7-en, Direct3D driver használata mellett 270.6 FPS sebességet mértek a Left 4 Dead 2-vel. Ezután Linux-on mértek. A kezdeti verzióból mindössze 6 FPS-t tudtak előcsalogatni. Ahogy írták, ez teljesen normális egy új platformra való portolási munka elején. Nekiálltak optimalizálni.

Módosítottak a Source engine-en, csökkentették az OpenGL-lel kapcsolatos overhead-eket, kiegészítették a renderer-t. Ezután a játék 315 FPS sebességre gyorsult Linux alatt. Együttműködtek a munka során a hardvergyártókkal is. Érdekességként érdemes megemlíteni, hogy a munka hozadékaként Windows alatt is gyorsult az OpenGL implementációjuk, így a Left 4 Dead 2 (OpenGL) most 303.4 FPS-sel fut Windows alatt.

Felmerült a kérdés, hogy vajon miért fut Windows 7 alatt a játék OpenGL-es verziója gyorsabban, mint a Direct3D-s? A fejlesztők már tudják, hogy a hardver képes többre. Most azt keresik, hogy hogyan tudnák a D3D-s overhead-et kiküszöbölni.

A blogbejegyzés további jó hírt is hoz a játékosok számára. A Valve - ahogy az várható volt - együttműködik az NVIDIA, AMD és Intel mérnökeivel annak érdekében, hogy javuljanak a grafikus eszközmeghajtó-programok teljesítményei Linux alatt.

A részletek elolvashatók itt.

( trey | 2012. 08. 02., cs – 09:15 )

"After this work, Left 4 Dead 2 is running at 315 FPS"

Mindezt 32 biten, Linux alatt, OpenGL-lel, a fos X11-en????!!! Kihagytam valamit?

--
trey @ gépház

Az eredmenyek orvendetesek, de en nem ertem ezt a nagy csodalkozast. Mar 2004-ben egy olyan "sikertelen es nevesincs" jateknal, mint az UT2004 voltak hasonlo erdemenyek. A Linux/OpenGL kombinacio nagyobb FPS-t hozott, mint a Windows/D3D ill. a Windows/OpenGL. Biztos a fejlesztok nem toltak anno ezt a jatekot, vagy ha megis, akkor nem kulonbozo plattformokon ;)

A játékgyártásnál nem az az elsődleges köveletmény, hogy "több" FPS-t hozzunk ki a platformból, hanem az, hogy minél olcsóbban elfogadható FPS-t hozzunk ki belőle.

Egyelőre az van, hogy a DirectX egy átfogóbb, könnyebben használható, barátságosabb játékfejleszői platform, mint az OpenGL. Egyszerű példa: a DirectX-ben van hangkezelés is, az OpenGL-ben meg nincs.

Ez persze egyáltalán nem baj, meg lehet OpenAL-t használni, vagy SDL-t vagy akármit, de bonyolultabb (==költségesebb) így összelegózni valamit, mint a DirectX-et használni.

Azért én szurkolok a Valve-nak, hátha használhatóvá teszik a linuxot is előbb-utóbb :-p

Manapság már ott tartunk, hogy csak akkor csökkenthető elfogadhatóan egy fejlesztés kockázata, ha multiplatform fejlesztésben gondolkodsz az első pillanattól kezdve. Ehhez pedig az OpenGL+OpenAL sokkal jobb választás, mint a DirectX. Persze ha van pénz, idő az engine fejlesztésre, akkor lehet külön D3D, OpenGL renderert fejleszteni a különböző platformokra, de minek?!

Hat nemtom, ha en egyszerer fejleszthetnek win32re es xboxra (DirectX, ugye) az sokkal potensebb crossplatform strategianak tunik mint win32+linux crosspaltformsagot figyelni (tobbi OS/hw-t meg sztm bele se vegyuk, mert a PS3 meg tok mas.)
Bar lehet h xboxon az opengl is sima ugy, nem ertek a lovakhoz.

( Dgzt | 2012. 08. 02., cs – 09:31 )

Azért jó látni, hogy az eredmények nem roszabbak, főleg nem sokkal, mint Windows alatt.
---------------------------
Oszt jónapot!

12 fps ilyen nagysagrendnel mar nem szignifikans. Az lett volna fura, ha az nvidia binaris driverevel rosszabb erteket kaptak volna, mint windows-on. UDM ota nagyjabol ugyanaz a kodbazis van minden platformon az nv driverben. Ez a masik ok, h ha valaki hasznalhato gfx-et akar non-windows rendszeren, akkor ahhoz nvidia kell.

---
pontscho / fresh!mindworkz

Majd akkor jól rakunk egy bugot a kernelbe, az X-be, az opengl-be vagy valamelyik opensource játszótérbe, 2338 új feature címszóval! Ezeket a híreket én már úgy kezelem, hogy szerencsés véletlenek!

Szerinted mit használok? Wi... neeem! Na, na, na? Hát blackPanther OS v12.0(beta)-t * blackpantheros.eu

Mondjuk a fizika szimulációt nem kötelező 1-1ben a kirajzolt képkockákhoz kötni. Meg lehet csinálni, hogy a szimulációt végigfuttatod akkor is, ha a kirajzolásból kimarad 1-2 kocka. Így - elméletileg - reprodukálható minden futtatás - az input megfelelően időbélyegezett rögzítése mellett.

A monitorodnak is van egy "framerate-je" (nem pont az, de sok tekintetben olyan). Ha a játék framerate-je nem egész számú többszöröse ennek, akkor szaggatott lesz a gyors mozgás, kivéve, ha eléggé nagy a framerate, mert akkor eltűnik ez az effektus. Ezt a jelenséget egyébként a méregdrága cinemacity mozikban is meg lehet figyelni, ahol valami iszonyat gagyi vetítőket használhatnak, ugyanis minden filmben ugrabugrálnak a gyorsan mozgó dolgok.

Másrészről (bár ez kicsit source engine-specifikus), ha magasabb a framerate-ed, akkor jobbak az esélyeid multiplayerben, mert egységnyi idő alatt több parancsot tud a kliens a szerver felé továbbítani (vagyis például el tudsz ugrani a feléd repülő rakéta elől tf2-ben).

Van olyanja, ok, hivjuk ugy, de en mindig ugy gondoltam, hogy annak minnel nagyobb erteke csupan azert fontos, mert klasszikus CRT eseten zavarja a szemet a villogas, amivel a kepfelepites jar (ahogy az elektronsugar vegigfut ugye, 100Hz-es CRT-s TV sem attol jobb a szememnek mert "folyamatosabb" - ok ott eleve az adas is ua amit vesz -, csak nem villog annyira). Pont ezert pl LCD-nel mar nem is ertettem miert lenyeges ez egyaltalan, tekintve, hogy mas elven muxik mint a CRT es ilyen effekt nem lep fel, ami zavaro [kepfrissitesi frekvenciatol fuggetlenul].

A masodik reszt nem teljesen ertem: attol hogy X fps-sel jelenik meg a "scene", attol meg lehet ettol fuggetlen, hogy milyen latency-vel, sebesseggel stb tud a szerver es a kliens kommunikalni, az fps csak a megjelenites szempontjabol jon a kepbe, hogy jon ide a halozati kommunikacio?

Mondjuk tenyleg soha nem jatszottam ilyesmikkel, szoval ezert van, hogy hulysegeket kerdezek :)

A játék élménye miatt. Nem mindegy, hogy pár tizedmásodperccel később vagy hamarabb veszed észre hogy valaki épp a sarokban sunyul. :)

Ugyanis, ha a géped le van foglalva a rendereléssel, akkor lelassul(hat) a bejövő adatok - pl. feléd repül egy rakéte - feldolgozása, ez pedig életbe kerülhet. :)

Sajnos mára teljesen elbutulni látszik a játék társadalom ezért manapság a konzolon dzsojsztikkel játszott FPS esetén bőven jó a 60fps is.

De voltak idők amikor az FPS játékot még igazi férfiak játszották és ott bizony minden miliszekundum számított :)
http://www.youtube.com/watch?v=jADCNfe_aYo

--
maszili

"A masodik reszt nem teljesen ertem: attol hogy X fps-sel jelenik meg a "scene", attol meg lehet ettol fuggetlen, hogy milyen latency-vel, sebesseggel stb tud a szerver es a kliens kommunikalni, az fps csak a megjelenites szempontjabol jon a kepbe, hogy jon ide a halozati kommunikacio?"

:)

Klasszikus játékfejlesztési modell, egyszerűsítve: 

while (true)
{
  Input();
  GameLogic();
  Render();
}

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

"attol hogy X fps-sel jelenik meg a "scene", attol meg lehet ettol fuggetlen, hogy milyen latency-vel, sebesseggel stb tud a szerver es a kliens kommunikalni, az fps csak a megjelenites szempontjabol jon a kepbe, hogy jon ide a halozati kommunikacio?"

Jó gondolod. Valóban nincs köze a network sebességének közvetlenül a renderelés sebességére, de még a game logic és a fizika részére sem mindig. Pl. ha egy FPS-ben a magas network latency miatt nem jön a többi játékostól új mozgásvektor, akkor egy motion predictionnek hívott dolgot alkalmazunk, aminek az a lényege, hogy az új pozíciót és orientációt a korábbi mozgásból próbáljuk meg megbecsülni. Aztán amikor megjön a szükséges info, akkor persze pontosítunk. Ez okozhat kisebb gondokat, de még mindig jobb, mintha szaggatna a játék a hiányos network információk miatt.

Aki kíváncsi arra, hogy ezt kódban hogy is lehet megoldani, annak nyugodt szívvel tudom ajánlani a Xonotic forrásának olvasgatását, ugyanis pontosan ezt csinálja az is.
Eredmény: 160-as pinggel is még viszonylag zavartalanul tudok USA-beli szervereken is játszani (és ez "verseny" helyzetben is jól működik, az első 1v1 kupán egy német és egy amerikai csapott össze a döntőben, az egyik pályát az amerikai srác vitte, szóval a rendszer szépen vizsgázott.)

----------------------------------------------------------
"One should strive to achieve; not sit in bitter regret."
www.xonotic.org

Gyors mozgások esetén (pl tenisz) amit látsz 30 FPS-sen és a valóságban:
* 30 FPS: 3 helyen felvillan a labda a képernyőn
* 60 FPS: 6 helyen felvillan a labda a képernyőn
* 60 FPS plusz motion blur: 6 helyen csík darabot látsz, amik nem illenek egymásba (közelítések miatt)
* 120 FPS plusz motion blur: 12 helyen csík darabok, amik jobban passzolnak, a valóságoshoz közeli az élmény
* valóság: elmosódott csíkot látsz, amit az agyad persze labdának érzékel a röppályájának az érzetével együtt
* film: a gyors mozgások "gyárilag" motion-blur-özöttek.
** kamera: a szemhez hasonlóan időben integrálja a látottakat
** CGI: Akár 120 FPS felett is renderelik a filmet, majd a 25-30 kockát ezekből mossák össze. Így a végső hatás közelebb lesz a valósághoz.

A 15-30-60-120 (monitoron is megjelenő) FPS között biztosan látod a különbséget. Olyat szerintem nem csináltak még kereskedelmi játékban, hogy a videokártya valódi kirenderelt képeket összemosott volna - pl 240->120 FPS formában. De talán az is érzékelhető javulást hozna.

( kmmk | 2012. 08. 02., cs – 09:59 )

Vegul is ilyen aprosagok mar trey szerint nem fontosak: Windows 7 Service Pack 1 64-bit vs. Ubuntu 12.04 32-bit. Micsoda meglepetes.
A jatekre nem irtak semmit. De azert nem mindegy, hogy 32 vagy 64-bites. Igy aztan lehet am osszehasonlitast csinalni.

"Windows 7 Service Pack 1 64-bit vs. Ubuntu 12.04 32-bit. Micsoda meglepetes.
A jatekre nem irtak semmit. De azert nem mindegy, hogy 32 vagy 64-bites."

Innen folytassuk, mert látszólag keményen érint téged ez a kérdés. Szerinted miért nem mindegy? Fejtsd ki. Arra utalsz, hogy csalás a Valve tesztje, mert a 32 bites Ubuntu alatt PAE-vel (vagy nélkül) gyorsabban fut a L4D2, mint a 64 bites Windows 7-en? Jól értem?

--
trey @ gépház

"látszólag keményen érint téged ez a kérdés"
Engem nem. Viszont te vagy az aki meg egy pontos bejegyzest se tud irni. Csak felhivtam a figyelmet erre. Ez nem egy ertekelheto teszt eredmeny.

"Arra utalsz, hogy csalás a Valve tesztje"
En ilyet nem irtam.

Azon kene elgondolkodni, hogy miert nem rogton a 64-bites ubuntu-t valasztottat 32gb ram-hoz.

Szépen kikerülted a kérdést. Utaltak itt többen arra, hogy a 64 bites Ubuntu valószínűleg gyorsabb lesz (de lassabb az majdnem kizárt). Ne akard, hogy azzal is teszteljenek, mert lehet, hogy még kormosabb pofa lesz az eredménye.

Ubuntu 12.04 LTS: 32-bit vs. 64-bit Performance

OpenArena-ban semmit sem számít, hogy 32 vagy 64 bit. A többiben meg a 64 elveri a 32 bitet.

--
trey @ gépház

Mi lenne, ha a kérdésekre válaszolnál és nem mellébeszélnél? Több teszt is azt mutatja, hogy vagy nem számít, hogy 32 vagy 64 bites az Ubuntu, vagy a 64 bites a gyorsabb.

OpenArena, Nexuiz, Unigine engine. Keress rá az interneten. Majd gyere vissza, ha sikerült.

Ráadásul rá se akarok mutatni a saját magaddal szemben megfogalmazott ellentmondásodra, miszerint "Aki meg 32gb memoria mennyiseghez 32-bites operendszert valaszt, az idiota." Azt választották és _még így is_ jobb eredményt csináltak.

--
trey @ gépház

A jateknal nem irtak oda, hogy hany bites. Pedig az is fontos lenne. Ha mar csinalunk egy osszehasonlitast, akkor vegyuk mar a faradtsagot, hogy a legminimalisabban terjenek el. Mert ugy lesz ertekelheto az eredmeny. Aki meg 32gb memoria mennyiseghez 32-bites operendszert valaszt, az idiota.

Technikai dolgot is fogsz említeni, vagy ezek csak afféle megérzések? Leírták, hogy hol a probléma:

"We have been doing some fairly close analysis and it comes down to a few additional microseconds overhead per batch in Direct3D which does not affect OpenGL on Windows."

Azt is, hogy dolgoznak rajta:

"Now that we know the hardware is capable of more performance, we will go back and figure out how to mitigate this effect under Direct3D."

--
trey @ gépház

Most az fáj akkor, hogy a binugzos portolásnak köszönhetően a win-es változatot is optimalizálták? Vagy csak a szokásos farokméregetésnél van most az, hogy a szőrszálakat egyenként nyálazgatod végig, hátha befolyásolták a mérést? Nemábazz...

Épp arról ment a múltkor a találgatás, hogy mennyivel lesz szarabb a portolt változat, hát ezek szerint versenyképes, amin persze lehet bosszankodni is.

Régi Windows-huszár FUD-ok látszanak megdőlni. Az látszik, hogy minimális akarattal lehet akár Linux-ra is játékot fejleszteni. Nem kell más ehhez, mint egy-két szakképzett programozó, egy elkötelezett fejlesztőcég és együttműködés a hardvergyártókkal.

Kíváncsi leszek, hogy mi lesz a vége ennek. Ha összejön a Valve-nak, azt hiszem, hogy sok hozzáértő Windows huszár próbálja majd elásni régi fórumkommentjeit ebben a témában.

--
trey @ gépház

A linuxos játékfejlesztés és karbantartás elsődleges akadályai nem a driverekben vagy azok teljesítményében keresendőek, hanem a "linux" sokszínűségében.

Ha elolvasod a korábbi bejegyzéseket a Valve linuxos blogjából, akkor láthatod, hogy egy konkrét Ubuntu verzióra (12.04 azt hiszem) készítették el a programokat. Ez azt jelenti, hogy egy adott driververziót, kernelverziót, glibcverziót, rosszabb esetben SDL meg hasonlóverziót használtak.

A rossz rész akkor fog jönni, amikor megjelenik a 13.04-es Ubuntu, és akár a felhasznált API-k, akár az ABI-k változnak. Ezekhez hozzá kell majd igazítani a programot (ami várhatóan nem nagy munka), és mögé kell tenni a kiszolgáló infrastruktúrát: új verziók a játékból, azok letölthetővé tétele, annak elmagyarázása a felhasználóknak, hogy pontosan melyik változatot töltsék le a játékból... Ez utóbbi a nagy falat, sok munkába kerül.

(Gondolj bele, hogy mennyit szenvedtek/szenvednek az Ubuntu honlapján azzal, hogy a telepítő CD-ből a 32 vagy a 64 bites változat legyen a default... Brr... Na, ilyen problémákból van sokkal-sokkal több egy játékkal.)

A Valve pont az, akinek a Steam képében ez rendelkezésre áll ehhez az infrastruktúra, úgyhogy hajrá nekik, de simán el tudom képzelni, hogy más cégek számára egyszerűen nem termelné vissza a költségeket egy-egy játék linuxos kiadása.

Igazandibol meg az lehet a kerdes, hogy ugyanolyan textura-reszletesseget, plusz effekteket, etc. hasznaltak-e a direct3d-nel mint a gl-nel.

Amugy az id mar regatota meg tudja csinalni kvazi szepen platformfuggetlenre a c kodjait, nem lehetlen ez. Nyomtam q3arenaval linuxon en is. Ami viszont gaz volt, hogy par dist-upgraddel kesobb az installer mar nem volt hajlando felpakolni a jatekot:P Ez is egy fontos aspektus, a bolondbiztos es idotallo installer/futtato kornyezet - erre kell meg ragyurni, pl repobol installalhato jatekok...ubuntu appstore? vagy most lesz valve appstore vegulis a steam-mel.

Így aztán a 64 bit nekik felesleges.

Igazabol nem felesleges itt sem a 64 bit, leven a vilag joforman egyetlen 64 bites architekturaja az x86, ahol a valtas ekkora teljesitmenynovekedessel jart, mert volt lehetoseg par tornazsak kirugasara, mint pl. az, h x86-on modern os alatt 5 szabadon hasznalhato regiszter van, mikozben a legputterebb arm-on is ott figyel a 2-3-szorosa.

Inkabb kodkompatibilitasi kerdesek miatt ragadtak le a 32 bitnel. Ki a halalnak van kedve idonkent tobb eves - sokszor szarul megirt kodokat - atfaragni, az endian vadaszat a legputterebb melo a vilagon.

---
pontscho / fresh!mindworkz

( wachag | 2012. 08. 02., cs – 10:37 )

Olyan édes, amikor valakinek az fáj, hogy az általa nem használt rendszerhez/rendszeren fejlesztenek valamit.
Mind Windows, mind Linux oldalról.

Avagy subscribe, jó kis flame lesz ebből a topicból, már várom :-).

( vomberg | 2012. 08. 02., cs – 11:21 )

A 30 versus 120 fps szálhoz egy gondolat, vagy inkább merengés.

Nem szimplán arról van szó, hogy ez az érték az egész rendszer teljesítményének a korlátja? Azaz ha 30 fps-t tud a vas/oprendszer a játékkal, akkor ott bármiféle plusz terhelés (pl. komolyabb fizikai számítások, hálózat kezelés, multiplayer, satöbbi) már érezhetően, szaggatósra terheli a rendszert, míg ha 120 fps-nél van a határ, akkor ha plusz terhelést kap, akkor még 60 fps-nél is komoly tartalékokkal, egyenletesen, jitter, ugrálás, kihagyás nélkül megy a rendszer?

( lazyone | 2012. 08. 02., cs – 13:46 )

Nagyszerű hír! Tegyenek bele framerate limitert is. Elég nekem 40-60 FPS is. Ne melegedjen és ne zabáljon a gép feleslegesen.

( zolti v | 2012. 08. 02., cs – 18:27 )

Végre ilyeneket is olvasni.
Remélem sikeres lesz ez a projekt, és folytatják gyengébb vasakon is a tesztelést.
Engem mondjuk az is érdekelne mit tudnak kihozni egy sima i5, i7 "gpu"-ból.

( salaud v | 2012. 08. 02., cs – 19:06 )

Nagy újdonság...
Annak idején (főleg)azért szoktam át a linux desktopra, mert a Quake3 Aréna több fps-sel futott debian woody/sarge alatt, mint windows xp-n. És pont az a különbség kellett a játszhatósághoz.

---
A Linux nem ingyenes. Meg kell fizetni a tanulópénzt.
Az emberek 66 százaléka nem tud számolni! Gondoljatok bele, ez majdnem a fele!!
Mindenki jó valamire. Ha másra nem, hát elrettentő példának.

( uid_19663 | 2012. 08. 03., p – 17:08 )

azt nem tudjátok hogy ezek az opengl-t érintő változtatásokat vajon már tartalmazzák-e az új patchek? mert kb hetente 2x szoktak frissítések jönni (nekem legalább is ilyen gyakorisággal frissíti a steam kliens a source motoros játékokat, és a hír óta már megint volt egy 200 mb-os frissítés)...

team fortress 2-t ugyanúgy source engine hajtja mint a L4D2-t
ha a L4D2-vel az engine portolásra kerül akkor a valve szakembereinek nem lesz nehéz az összes ilyen motoron futó játékot átírni
és nem kevésről van szó :D
http://en.wikipedia.org/wiki/Category:Source_engine_games
és akkor még a hl2 modokat és a source sdk-t nem is említettem:
http://store.steampowered.com/mods/220/
de ez még mindig nem az összes mert az "Age of Chivalry"-t, "Synergy"-t és még sok más modot nem listázza ki a steam (nem tudom miért) pedig ezek is húzó címek

( Vaddiszno | 2012. 08. 06., h – 15:49 )

LGB: "Nem szoktam jatszani, ezert nem is ertem ... igazabol ezt konkretan sose ertettem: mitol jo a 120fps? Az emberi szem nem kepes kovetni a kulonbseget - legalabbis _szerintem_ - ugy kb 30 ftps utan, teljesen felesleges tobbet. Vagy mit tudok rosszul, valaki arulja mar el."

Ezért próbálják magyarázni azok, akik szoktak játszani és értik.
Szerinted nem képes az emberi szem követni a különbséget 30FPS fölött. Ez már önmagában is megdöbbentő, mert a 30 FPS olyan triviálisan kevés, hogy éppen hogy elfogadható, az alatt már kifejezetten szaggatós, szar.
Ha 60FPS-t írtál volna, akkor azt mondom, hogy csak tapasztalatlan vagy, mert sokak szerint annál nem kell több, mert nem látható.
Ha jól látom a hozzászólók közül többen meg tudnak erősíteni abban, hogy a 60 FPS fölött is érezhető a különbség (=javulás), én magam egészen biztosan a 100 FPS-t jelölném meg, ami fölött már (TALÁN) tényleg nincs jelentősége, de hadd mondjam el neked, hogy én nem csak a 60 és 72 vagy 80 FPS között látok lényeges különbséget, hanem a 90 és 100 FPS között is érezhető a javulás.
Hogy mi a javulás? Írták mások is kicsit konkrétabban: 3 labda helyett 6-ot vagy 10-et látsz, nem igazán értetted miért jó ez. Ennek az az oka, hogy olyan játékokkal játszottál, vagy olyan kezdő módon játszottál (és ez nem lenézés, nem pejoratív itt, és nem bántás, mert mindenki ilyen míg nem ér el egy bizonyos szintet egy csomó idő után), szóval olyannal és/vagy úgy és/vagy olyanokkal játszottál, ahol lényegtelen. Amíg az átjárókban akadozol, vagy kerülgeted azt amit át lehet ugrani addig mindegy. Észre sem veszed.
Ha elég jó játékos vagy és elég jó ellen játszol, akkor észre fogod venni, hogy egyforma erősen is nagyon kikapsz, mert előbb lát meg, előbb lő: ennyi elég: mindig kicsit előbb lát - nagyon megver. Mellesleg folyamatosabb és szebb is az élmény.
Ha érdekel még érdekességként: ha komoly játékos vagy, akkor nem 30 ms (30 ezredmásodperc = 0.030 mp) késleltetésbeli különbséget, hanem 5 azaz öt ms (0.005 mp) késleltetésbeli különbséget érzékelni lehet, az érzékelni lehet padig azt jelenti, hogy ha 5-10 ms-mal nagyobb a késleltetés akkor érezhetően szarabbul tudsz játszani mások ellen.
Hidd el ezek nem csúsztatások, nem túlzások, csak van aki még ezeket nem fedezi fel, és persze nem pasziánsz-versenyről beszéltem és nem pókerről.
30 FPS esetén 33 ms-omként jönnek a képek. 100 FPS esetén 10 ms-mal. 23 (!!!) ms - óriási különbség már önmagában. Persze ehhez tartozik még 500 vagy 1000 Hz-es mintavételi frekvenciával dolgozó egér is.
Nézd csak meg a valaki által belinkelt Quake3 CTF videókat: ezek nem a véletlen, vagy szerencse művei, bár nyilván a szebb részek vannak a videóban, de (nekik) egy átlag meccs hasonló (volt).
Ezért jobb egy 100-120Hz-es CRT monitor a 60 Hz-es LCD/TFT-nél játékra (hiába a 2 és 5 ms, amit ráírnak, ha 60 vagy 72 Hz a képfrissítési frq).

Amit meg hozzatennek a CRT vs LCD temakorhoz: ami szerintem meg igen hangsulyos, az az input lag, ami nem keves tud lenni. Pl. ott a Dell 2408WFP-m, nagyon jo kis monitor, de azert erezhetoen van input lagja. (Talan teszteken 2 fps-t irtak anno...) Ezt anno, mikor Half-Life-ban toltam DM-et, elegge eszre is vettem.

Azonban miutan egy jatekbol sem kivanok versenyszeruen jatszani, csupan kikapcsolodasbol, inkabb egy jo TFT, mint egy CRT.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™