Új hozzászólás Aktív témák

• #19 b. félisten Redneck #18

  Új Válasz 2018-10-29 17:35:31 #19

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  b.

  félisten

  válasz Redneck #18 üzenetére

  vagy nem tudja mit nem lát

  "A számítógépek hasznavehetetlenek. Csak válaszokat tudnak adni." (Pablo Picasso) "Never underrate your Jensen." (kopite7kimi)

• #24 Abu85 HÁZIGAZDA Redneck #18

  Új Válasz 2018-10-29 17:54:16 #24

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Abu85

  HÁZIGAZDA

  válasz Redneck #18 üzenetére

  Nem a kijelző oldalán nagy a késés. Ezt csak a monitorgyártók akarják veletek elhitetni. Valójában a legtöbbet a szoftverben késel, méghozzá azért, mert az API-k, illetve maguk a grafikus meghajtók alapértelmezetten úgy működnek, hogy minimum egy, vagy akár több frame lesz előre prezentálva, és ezek számítása is rendkívül kiegyenlítetlen. Attól, hogy ilyen 144 Hz-es gamer kijelzőre váltasz ezt a problémát nem oldod meg, csak a kijelző felé kiküldött kép jelenik meg egy nagyon picikét hamarabb. De ugye a driverek eléggé speciálisan vannak ma már beállítva, így nem ritka, hogy a frame present konfigurálása a beállított képfrissítéshez igazodik, vagyis minél nagyobb ez az érték, annál nagyobb lesz a frame present is (ami szvsz baromság, de így lehet sebességet nyerni, csak közben bukó a response time ).

  A problémát nem a kijelzők oldalán lehet megoldani, hanem azzal, hogy olyan módot kapna akár API-ban a rendszer, hogy 0 legyen az előre presentált frame, vagyis a GPU mindig csak azt a scene-t kapja meg, ami éppen következik. Persze ezt lehet bolondítani sok extra dologgal, például pacinggel, egyedi ütemezéssel, de a lényeg az, hogy a szoftveres ok, amitől nagy a késleltetés, az legyen kiütve. Konzolon ilyen megoldások konkrétan vannak építve az egyes játékokba. Állítólag a Microsoft is dolgozik egy szabványos megoldáson a WDDM-be. Van mérés is a Chillből, de ugye ez egy driveres hack, és ha köré vonnánk egy API-t, akkor ez jobban is működhetne. [link] - így is látszik, hogy mennyi előnyt ad, de ez direkt támogathatóság mellett még többet biztosíthatna.

  Összességében tehát ez egy szoftveres probléma. A hardver csak segíthet, de messze nem fogja megoldani, mert nem a kijelző oldalán keletkezik a gond. Alapvetően nem igazán lenne szükség 60-75 Hz-nél jobban frissítő kijelzőre, ha a szoftveres háttér nem lenne annyira elbaszarintva, amennyire el van. Régen sem vettünk például 120 Hz-es CRT-t, pedig lehetett volna, viszont akkor nem volt bonyolult a szoftveres rész, és nem érezted a szükségét ennek. Ettől függetlenül vehetitek a 144 Hz-es kijelzőket, de olyan dologra veszik az emberek, amelyeket nem ezzel lehet a leghatékonyabb módon kezelni.

  [ Szerkesztve ]

  Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

• #27 lezso6 HÁZIGAZDA Redneck #18

  Új Válasz 2018-10-29 18:09:59 #27

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  lezso6

  HÁZIGAZDA

  LOGOUT blog

  válasz Redneck #18 üzenetére

  Ugyanazzal a monitorral van különbség a 75 és a 144 között? Kb így jön össze a késleltetés:

  1. egér input (jobbaknál 1-2 ms)
  2. frame render (fix 144 fps esetén ~7 ms)
  3. monitor input lag (nagyon jóknál 1-2 ms)
  4. LCD válaszidő (gamer monitor 2-5 ms)
  5. emberi válaszidő (F1-es pilótáknak 200 ms...)

  Szerintem itt simán csak a monitor input lag meg ilyesmi okozza a jobb élményt. Vagy a kognitív disszonancia. A 60 vs 75 Hz váltásnál lévő hatalmas ugrás tipikusan attól szokott lenni, hogy azok 60 Hz-es monitorok nagyon régiek.

  A RIOS rendkívül felhasználóbarát, csak megválogatja a barátait.

Új hozzászólás Aktív témák