- A Watch7-tel debütálhat a Samsung vércukormérője
- Fotók, videók mobillal
- iPhone topik
- Garmin Forerunner 165 - alapozó edzés
- Samsung Galaxy S24 Ultra - ha működik, ne változtass!
- Telekom mobilszolgáltatások
- Samsung Galaxy S23 és S23+ - ami belül van, az számít igazán
- Bemutatkozott a Redmi új szériája
- Oppo Find X5 Pro - megtalálták
- Bluetooth-headsetekről általában
Hirdetés
-
Miniképernyős, VIA-s Epomaker billentyűzet jött a kábelmentes szegmensbe
ph A megfizethető, szivacsokkal jól megpakolt modell ötfajta kapcsolóval és kétféle színösszeállítással/kupakprofillal szerezhető be.
-
Rövid előzetesen a S.T.A.L.K.E.R. 2: Heart of Chornobyl
gp Továbbra is szeptemberi premierrel számolnak a fejlesztők, reméljük több halasztásra már nem kell számítanunk.
-
Toyota Corolla Touring Sport 2.0 teszt és az autóipar
lo Némi autóipari kitekintés után egy középkategóriás autót mutatok be, ami az észszerűség műhelyében készül.
Új hozzászólás Aktív témák
-
Yany
addikt
Ejh, de hiányzik is a jó öreg 17-es CTX monitorom 160 Hz-es frissítése. Akkortájt igencsak kompromisszummentes volt ez, hiába beszélünk 800x600 vagy 1024x768-as felbontásról. Anno ez nem számított alacsonynak, tehát az akkor elérhető közép és felsőkategóriás készülékek simán hozták ezt a top frekvenciát akkori viszonyok szerint magasnak számító felbontáson.
Ma vagy nagy felbontásod van (4k @ 60 Hz) vagy magas frissítési freki (165 Hz). Sajnos még 2019-ben is extrémnek számít bármi ami a kettőt együtt hozza (pl. 4k @ 75 Hz, mint mondjuk a 38uc99, de az is ilyen "csonka" 4k: 1600p), de legalább már folyik a fejlesztés.
Építs kötélhidat - https://u3d.as/3078
-
Yany
addikt
Egyrészt Dobrika is rávilágított egy dologra a #61-esben: vagyis, hogy a kliens oldalon (vagyis a te gépeden) a server nélkül is történhetnek változások, amiből épp a legfontosabbat ki is emelte: nézelődsz. A másik, hogy habár a szervertől ugyan nem kapsz információt, de a géped gyönyörűszépen interpolálja a csomagok közti változást, tehát valójában igenis látsz olyan új információt, 1-1 képkockával, ami a szerverről érkező adatokon alapul. Olyannyira, hogy az interpoláció miatt a te géped pont hogy sosem látja a legfrissebb információkat, mert egy jól bekonfigolt környezetben mindig éppen akkor láthatod csak meg, amely pillanatban megjött az újabb csomag, tehát pontosan 1/tickrate mp-nyi lemaradásban vagy, ahol minden egyes interpolált képkocka újabb és újabb információkkal szolgál. Ha nem így lenne, akkor faszán darabos képet látnál egy 30 tickes szerón, ami csak akkor valósul meg, ha egyrészt elfogadod, hogy 30 fps darabos egy 100+ Hz-hez szokott szemnek, illetve kikapcsoltad az interpolációt (amit néhány játékban meg tudsz tenni).
Építs kötélhidat - https://u3d.as/3078
-
Yany
addikt
válasz Döglött Róka #110 üzenetére
Abszolút nincs igazad. Ha nagyon érdekel, hogy miért, keress rá arra a hszre, amiben elmagyarázom.
Építs kötélhidat - https://u3d.as/3078
-
Yany
addikt
válasz Döglött Róka #126 üzenetére
Egy ilyen cikk elolvasása rád is ráférne. Egy szerver mióta rendereli a játékot? Másrészt a kliensoldali interpolációt mire találták ki? A tickrate a kijelző sebességével semmiféle függőségben nincs a mai játékokban.
Építs kötélhidat - https://u3d.as/3078
-
Yany
addikt
válasz Döglött Róka #186 üzenetére
A lag kompenzációnak megint az égvilágon semmi köze ehhez a témához. Miért gondolnék arra?
Olyan egyszerű ez az egész monitor frissítési freki kérdés, nem tudom, hogy miért ilyen hihetetlen, hogy a 20-as tickrate-es szerverek esetén is gyakorlatilag éppolyan értelmes és hatásos gyorsabb monitort használni, mint egy 60-ason. És igen, bőven 60 fölött. Amíg a kliens (ergo az engine) képes a két "tick" közti állapotot megjeleníteni (ld. interpoláció), addig ez nem is kérdés. Nos, perpillanat nem hiszem, hogy van olyan elterjedt engine, amelyik ezt ne tenné meg, vagyis nincs miről beszélni.
A lagkompenzáció a szerveren történik a kliens által küldött adatokat dolgozza fel a kliens latency-jének megfelelő idősávval hátratolva. Ez totál másik témakör. Ez most a szezon és a fazon esete. Kicsit olyan vagy, mint aki egy beszélgetés közepébe csöppen és gyorsan elhadonászik 1-2 fogalommal, ami érintőlegesen kapcsolódhatna a témához, hátha betalál valamivel, hogy részt vegyen a beszélgetésben.
szerk.: Ha valaminek még lehet köze a frekihez, akkor az az input-kezelés. Ha az szinkronban történik a megjelenítés sebességével, vagyis az input state-ek vizsgálata minden képkocka megjelenítés előtt megtörténik, akkor már nem is csak a felfogási sebességed, de a reakcióidőd is jobbá válik. Nem fogom ezt külön megmagyarázni, mert láthatólag valamit eldöntöttél, amihez nem értesz, ahelyett, hogy utána olvasnál, mielőtt kinyilatkoztatsz. Ha mégis érdekel a téma, az input state handling fps engine és hasonló szavak bevetését ajánlom a gugliban.
szerk2.: csak felsorolás szintjén, hogy a kliens működésében még miken múlhat, hogy mennyire hat a teljesítményre a kijelző frissítési frekvenciája:
- Input state handling
- Client network send rate / command rate
- Buffering (input/frame/network)
- Frame Interpolation / extrapolation: itt a jóslás pontossága is nagyon fontos, mert alapvetően egy extrapolált képkockához történik az interpoláció, ha nem akarja a motor, hogy minden játékos a múltban játsszon, vagyis akkor tökéletes, ha az extrapolált állapotok nem csak nem tévesek, de pont akkorra történik meg az interpoláció befejezése, mire az új csomag megérkezik a szervertől.
- És még sokminden más.[ Szerkesztve ]
Építs kötélhidat - https://u3d.as/3078
-
Yany
addikt
válasz #16939776 #219 üzenetére
Elvileg ezt oldaná meg az LFC, de sajnos az is csak 2x szorzóval dolgozik, ami minden, csak nem finom átmenet. A 38uc99-esemen még az 55 és a 75 között is sajnos elég jól látható fénysűrűség-varianca van, picit zavaró, amikor kvázi álló helyzetben változgat az fps. Mozgás közben szerencsére ebből semmi nem látszik.
Építs kötélhidat - https://u3d.as/3078
-
Yany
addikt
Ahogy A-ból B-be jutsz egy autóval, annak is vannak kényelmi, esztétikai paraméterei... és van a teljesítmény: mennyi idő alatt. Na épp ilyen teljesítmény-specifikus kérdés a frissítési frekvencia is. Vannak persze hatásai, amit megszoksz és nem azon ámulva ülsz 0-24-ben előtte, hogy azta, ez 144, nem 60, de ettől még a teljesítménye adott lesz, ami mindenképpen hat rád, akkor is, ha nem foglalkozol vele. Előbb látod azt, amit látnod kell és előbb tudod lereagálni, amit reagálnod kell. Ha egy ember reakcióideje mindennel együtt mondjuk fél másodperc, akkor az a fél másodperc nem ugyanarra az időre kerül rá a 60 Hz-es játékmenet előtt, mint a 144-es esetében. Ez szimpla matematika. Mindenkinél okoz különbséget, csak van, aki észreveszi és foglalkozik vele, van, aki meg nem. Hangsúlyozom: ez a különbség akkor is adott lesz, ha valaki nem látja a 60 és 144 fps közti különbséget. Persze csak akkor, hogy a játék amúgy képes is annyi fps-sel futni.
Építs kötélhidat - https://u3d.as/3078
-
Yany
addikt
Igen, sajnos nosync esetén (főleg stabil fps-sel) irgalmatlanul fellép a "stuttering", vagyis a kadenciahelytelen megjelenítés. Hiába lesz eszméletlen gyors extrém alacsony input laggal, a ritmikát igencsak elrontja és habár ez szubjektív, de engem legalább annyira zavar, mint az alacsony Hz. Szóval részemről is a freesync/g-sync a nyerő, akár egy picit alacsonyabb frekivel is, mint az eszetlenül magas, de nem sync-elt megjelenítés. De ez már-már szubjektív territórium. Főleg, hogy a frekiváltás sajnos nem nyomtalan az LCD-ken még. Talán nem is lesz (ld. kristályok lassú visszarendeződéséből adódó képvillogás).
@Döglött: rendben, igazad van, tényleg picit nyers voltam. Azonban fenn tartom az objektív előnyök meglétét a korábban részletezett okok miatt. Fejlesztő is vagyok, játékokkal is foglalkozom, netcode-dal is variáltam már, nagyjából képben vagyok, hogy mi mire hat, de engine szinten nem vagyok spíler, ennél mélyebben tudna mesélni ezekről a dolgokról néhány ismerősöm.
szerk.: Unityben pl. elég sokan rosszul kezelik az inputokat összekuszálva a fizikai számítások ciklusával, ott pl. kényesen szoktam ügyelni arra, hogy ne kövessem el a szokásos hibákat.
[ Szerkesztve ]
Építs kötélhidat - https://u3d.as/3078
-
Yany
addikt
Az ultimate szvsz a 38" 3840x1600 21:9 ívelt microled kijelző 160+ Hz-es frissítéssel. Mindegyik már létező dolog, már csak várni kell, mire addig evolvál a technológia, hogy elérhető legyen mindez együtt.
Ha nem fejlesztenék / hobbi videóznék, akkor én is most egy 3440x1440 @ 100~120 Hz-es ívelt kijelzőre szavaztam volna, de így a 75 Hz-es 3840-esre esett a választásom. Tartalomgyártóknak extrém jó egy ilyen 38-as monstrum.
Építs kötélhidat - https://u3d.as/3078
-
Yany
addikt
Aztaaaa beszabehu...
Láttátok, hogy mivel érkezik az LG?Gyakorlatilag az általam vágyott frissítési frekivel toldja meg a 38-asát. Csak azt nem tudom, hogy tudja átvinni a kijelzőig a jelet ekkora sebességgel. Ha jól tudom, ez a jelenlegi hdmi/dp portokba nem fér bele. 2 külön bemenettel?
[ Szerkesztve ]
Építs kötélhidat - https://u3d.as/3078
-
Yany
addikt
válasz SchumiBácsi #425 üzenetére
Azért a teljes képhez hozzátartozik, hogy egy CRT esetén sokkal rosszabb élményt jelent a 60 Hz-es képfrissítés, mint LCD-k esetén. Technológiából adódóan jól látható vibrálás/villogás (kinek hogy tetszik) az eredménye a CRT kijelzőkön az alacsony képfrissítésnek. Alanytó (és gondolom a foszfor alapú vegyületen is) múlt, hogy mennyire volt látható, én jellemzően 85 Hz-től kezdve keztem érezni, hogy szép homogén a kép. 72-nél még egyértelműen láttam a vibrálást. No, LCD-ken "csupán" az aktuális képtartalom kirajzolásának sebességére hat, mert a háttévilágítás (a hál istennek gyorsan lecsengő PWM mánia óta) kellően magas frekin frissül ahhoz, hogy ne okozzon gondot. A képtartalom ugyebár LCD-k esetén abszolút nincs összefüggésben a háttérvilágítással, kivéve talán a BFI-képes modelleket.
Van viszont új gond. A képtartalom frissítési sebessége is meghatározza a képjellemzőt. Arról van szó, hogy az LCD kristályait ugyebár katonasorba rendezik a kijelzők az RGB alpixelek előtt, hogy egyfajta színszűrés (kitakarás/átengedés) jöjjön létre. Nos, az a baj, hogy ez a rendezett állapot szép lassan feloszlik. Viszont annyira nem lassan, hogy ne okozzon látható eredményt. Egy-egy pixel vizslatva persze nem tűnik fel, de mivel a teljes kép minden egyes pixele egyszerre kezd el oszlani, ezért azt lehet látni, hogy változik a fénye a monitornak. Méghozzá ezt is csak akkor látni, amikor változik(!) a frissítés sebessége, ugyanis konstans frissítésnél mindig pont ugyanannyi ideje van a kristályoknak elmászni, vagyis állandó átlagfényerőt biztosítanak, de amikor ez a frissítési sebesség változik, akkor nem egyforma mértékben romlik el az eredetileg belőtt szűrés. Talán van olyan firmware egyes monitorokban, ami ezt kompenzálja, de azt gondolom, hogy mivel fizikai jelenségről van szó, ez az idő haladtával változhat, ezért (hacsak nem baromi okosan kigyúrt, öregedést figyelő algoritmusról van szó) csak ideiglenesen, vagy változó mértékben képes eliminálni a jelenséget.
Erre talán az OLED jó megoldás lesz, mivel ott a pixelek válaszideje nagyon jó, legalábbis nagy jelerősség esetén, majd kiderül.
Építs kötélhidat - https://u3d.as/3078
-
Yany
addikt
válasz SchumiBácsi #432 üzenetére
A leddel egyáltalán nem csak a PWM a gond. Főleg, hogy mostanában figyelnek rá, hogy ne villogjon. Még a legalja monitoroknál is megadják, hogy szembarát, pl. egy 30e Ft-os Benq-nál. Érdemes utánaolvasni, hogy milyen spektrumban adnak ki fényt a különböző ledek és milyet a CCFL-ek. Pl. hiába azonos színhőmérsékletű egy CCFL és egy LED, a kibocsátott fénytartományokban óriási különbségek lehetnek.
Építs kötélhidat - https://u3d.as/3078
-
Yany
addikt
Nem kell 5 év. Ez a monitor papíron nálam a 'debasz: [link]
Igaz, "csak" 1600 függőleges felbontás, de... huhh... 175 Hz-es frissítéssel? Az árára kíváncsi leszek persze, de ha az $1000-1500 közötti résbe még befér, akkor nagyon kellemes darab lesz.
Építs kötélhidat - https://u3d.as/3078