Testissä Suomen edullisimmat 144 hertsin pelinäytöt (1080p & 1440p)

[WanhaPatu]

Itsellä oli muinoin kolmen näytön Eyefinity, parhaimmillaan se oli kyllä Farcry/Crysis-miljöössä, eikä autopeleissä. Immersiostahan siinä on kysymys. Harva suostuu ottamaan kotiin niin montaa näyttöä, jos ei työn puolesta ole tarvetta. Siksipä kaupasta saa nyt ultrawidejä, ei tarvi edes säätää bezelien kanssa.

Kun on kerran Eyefinityllä/Surroundilla/Ultrawidellä pelannut, ei ole enää paluuta kapearuutupelaamiseen. Itselleni muutos oli samaa luokkaa kuin siirtyminen softarenderöinnistä rautakiihotettuun 3D-grafiikkaan.

Yli 60 Hz -hommiin eivät vielä rahkeeni riitä, katsotaan sitä sitten kun tästä nykyisestä näytöstä aika jättää.

 

[Snowman]

Kun on kerran Eyefinityllä/Surroundilla/Ultrawidellä pelannut, ei ole enää paluuta kapearuutupelaamiseen. Itselleni muutos oli samaa luokkaa kuin siirtyminen softarenderöinnistä rautakiihotettuun 3D-grafiikkaan.

Yli 60 Hz -hommiin eivät vielä rahkeeni riitä, katsotaan sitä sitten kun tästä nykyisestä näytöstä aika jättää.

Jännä, mulla just toisinpäin, just vaihdoin 100hz ultrawiden 32" 144hz paneeliin ja mulle tuo näytön kaventuminen ei ollut mikään dealbreaker, ennemmin hämmästyin siitä, miten iso ero tuli 100hz -> 144hz hyppäyksestä.

 

[L2K2]

Lähdetään virittelemään hiiren kytkimeen modattavaa lediä jota kuvataan yhdessä näytön kanssa 960 fps kameralla ja lasketaan aika ledin syttymisestä ruudulla näkyvään tapahtumaan.

Ah, oikein kunnon viritelmä, eli se ns. ”parsa” ratkaisu mittaamiseen.

Jos samaa ratkaisua on tarkoitus käyttää myös noille vielä nopeammille näytöillä, ja toki myös hieman halutusta mittatarkkuudesta tarkkuudesta riippuen: laittaa suosiolla sen ledin aina samalle korkeudelle sen (oletettavasti älypuhelimen) kameran kuva-alaa kuin mistä katsoo sen ruudun muutoksen. Noissa on yllättävän hitaasti sen sensorin skannaava sähköinen ”suljin”. Kuvan alareuna on sen puoli millisekuntia eri ajassa kuin kuvan keskikohta.

Kun tulokset ajaa samalla laitteistolla ja ohjelmistolla niin ne ovat vertailukelpoisia keskenään ja mielestäni on käytännönläheisempää testata todellisessa helposti ymmärrettävässä ympäristössä esim. CS:GO ja AWM:llä ampuminen vaikka pienellä mittausteknisellä virhemarginaalilla (esim. 10x ajon keskiarvo paras ja huonoin poistettuna), kuin tarkkojen arvojen hakeminen vaikkapa oskilliskoopilla ja fotosensorilla.

10 toistoa ei välttämättä riitä hyvään keskiarvoon, eikä jakauma muutenkaan välttämättä ole sellainen, että keskiarvo kuvaisi hyvin sitä mitä tapahtuu. Mutta tämän toki näkee sitten siitä datasta.

Hihasta: Miksi keskiarvo eikä suosiolla mediaani? (Tuon vaihteluvälin kun olettaisi olevan nätti parin tasajakauman summa: pelin FPS sille että peli näkee hiiren painalluksen + näytön virkistystaajuus siihen että se pelin reaktio näkyy uudessa kuvassa.)

Tavallaan ihan mielenkiinnosta onkin, että miten esim. XXX-sync vaikuttaa tuohon tyypilliseen puhumattakaan tuohon maksimiviiveeseen (jonka pitäisi järkeiltynä olla noin ”1 ms + 1/FPS + (N+1) × 1/virkistystaajuus”, missä N on näytön kuvapuskurin syvyys). Minimissään hyvällä tuurilla tuon 1/FPS osuuden saa tasan nollaan, samoin kuin tuon 1 ms (hiiren päivitystaajuus) ja kuvapuskuristakin säästänee yhden ruudun jos nuo on kivasti synkassa juuri sillä hetkellä. Keskimääräinen viive sitten olisi toki jotain näiden väliltä.

 

[Ormu]

Kun tulokset ajaa samalla laitteistolla ja ohjelmistolla niin ne ovat vertailukelpoisia keskenään ja mielestäni on käytännönläheisempää testata todellisessa helposti ymmärrettävässä ympäristössä esim. CS:GO ja AWM:llä ampuminen vaikka pienellä mittausteknisellä virhemarginaalilla (esim. 10x ajon keskiarvo paras ja huonoin poistettuna), kuin tarkkojen arvojen hakeminen vaikkapa oskilliskoopilla ja fotosensorilla.

Jos kaikki muu laitteisto pysyy samana ja softa on lyhytviiveinen ja ennustettavasti käyttäytyvä (nopeatahtinen ja hyvin koodattu räiskintäpeli lienee parhaasta päästä), niin ledi + suurnopeuskamera on hyvä ja yksinkertainen tapa.

Hiiren simuloiminen ja kirkkausmuutoksen mittaaminen Arduinolla ei nähdäkseni tuo juurikaan lisäarvoa testiin. Siinä on edelleen kuitenkin tietokone softineen välissä ja Arduinon koodin toimintaakin joutuu miettimään. Lisäksi valoanturin käyttö asettaa omat haasteensa, ja jos sen takia pitää käyttää jotain erityistä testisoftaa kun esim. CS:llä ei onnistukaan, sen laatuun pitää kiinnittää huomiota.

CRT-näyttöön vertaaminen on ihan mielenkiintoinen idea, mutta miten onnistuu korkeampien virkistystaajuuksien tai varsinkin G-syncin/Freesyncin testaus?

Tarkempi mittaaminen vaatisi tarkoitukseen tehdyn signaalilähteen, jossa olisi integroituna mittaus tai lähdöt oskilloskoopille.

 

[pomk]

Jos kaikki muu laitteisto pysyy samana ja softa on lyhytviiveinen ja ennustettavasti käyttäytyvä (nopeatahtinen ja hyvin koodattu räiskintäpeli lienee parhaasta päästä), niin ledi + suurnopeuskamera on hyvä ja yksinkertainen tapa.

Hiiren simuloiminen ja kirkkausmuutoksen mittaaminen Arduinolla ei nähdäkseni tuo juurikaan lisäarvoa testiin. Siinä on edelleen kuitenkin tietokone softineen välissä ja Arduinon koodin toimintaakin joutuu miettimään. Lisäksi valoanturin käyttö asettaa omat haasteensa, ja jos sen takia pitää käyttää jotain erityistä testisoftaa kun esim. CS:llä ei onnistukaan, sen laatuun pitää kiinnittää huomiota.

CRT-näyttöön vertaaminen on ihan mielenkiintoinen idea, mutta miten onnistuu korkeampien virkistystaajuuksien tai varsinkin G-syncin/Freesyncin testaus?

Tarkempi mittaaminen vaatisi tarkoitukseen tehdyn signaalilähteen, jossa olisi integroituna mittaus tai lähdöt oskilloskoopille.

Toisaalta etuna arduino+valosensoriratkaisussa on merkittävästi parempi temporaalinen resoluutio kuin juuri missään suurnopeuskameroissa, hinnan pysyessä todella pienenä. Mitään erityistä testiohjelmaakaan tuskin tarvitsee jos valoanturin asettaa vaikkapa aseen suuliekin kohdalle, lokittaa arvot vaikkapa miljoona kertaa sekunnissa ja katsoo niistä jälkikäteen tarkan hetken kun valon määrä alkoi muuttua. Ajan mittaamisenkin saa hoitumaan aidosti siitä hetkestä kun se klikkauksen sisältävä HID paketti lähtee liikenteeseen tietokoneelle päin. Ledillä ja 1000fps suurnopeuskameralla tulee vähintään 2ms jitteriä jo päivitysnopeuksien takia.

Bonuksena tällä setupilla voidaan verrata viiveen osalta keskenään myös vaikkapa prosessoreja ja/tai näytönohjaimia, kunhan vastaavasti näyttö pidetään vakiona. Myös joku ”nollataso” voidaan tälle järjestelmälle kalibroida näyttöjen osalta näyttämällä sille kertaalleen crt näyttöä.

 

[Sampsa]

Jos täältä löytyy joltain kiinnostusta toteuttaa esim. tuollainen arduino+valosensoriratkaisu + softa näytön inputlagin mittausta varten niin maksan mielelläni kulut.

 

[pomk]

Jos täältä löytyy joltain kiinnostusta toteuttaa esim. tuollainen arduino+valosensoriratkaisu + softa näytön inputlagin mittausta varten niin maksan mielelläni kulut.

Tosta sais varmaan hyvän AMK lopputyön aikaiseksi. Tiedä sitten että onko täällä paljonkin asiasta kiinnostuneita sopivassa vaiheessa opintoja olevia ihmisiä.

 

[Grizzle]

Näytöissä kun on useita valmiita väriasetuksia (yleensä tyyliin media, pelit, esitys tms.) niin olisi kiva tietää, mitä asetusta käytettiin mittauksia tehdessä.

 

[mehari]

Näytöissä kun on useita valmiita väriasetuksia (yleensä tyyliin media, pelit, esitys tms.) niin olisi kiva tietää, mitä asetusta käytettiin mittauksia tehdessä.

Tarkoitus on, että kaikki mittaukset tehdään näytön tehdasasetuksilla eli myös väriprofiilina käytetään sitä joka näytössä on oletuksena valittuna. Yhden näytön kanssa tähän piti tehdä poikkeus, koska oletuksena oli profiili, joka sotki mm. väritarkkuuden mittaamisen täysin ja tällöin asiasta mainittiin artikkelissa erikseen.

 

[Foxy]

Noi Sampat näyttäs olevan aina kehnoja >_<