efikkan

Av og til lurer jeg på hva dere går på når dere skriver konklusjonene. Hva er da problemet med at dette kortet lager et ytelsetrinn/pristrinn mellom GTX 960/R9 380 og GTX 970/R9 390 som Nvidia ikke konkurrerer direkte mot for øyeblikket? Med et ytelsegap på over 50% mellom disse to så burde det vel bare være rett og rimelig at noe plasserte seg i mellom?

 

Det er mye annet som kunne vært kritisert med produktet, men å kritisere det for å plassere seg mellom to produkter på denne måten blir rett og slett en skivebom.

Ja det kan være verdt et forsøk, der kan være mange kupp for den som er villig til å lete og vente litt.

Har du henvisning/link til PS/2 tastaturer som nevnt.

Filco Majestouch 2 er de beste tastaturene du kan få tak i, og de finnes i en rekke brytere. Men du må dessverre importere de. Das Keyboard "3" er også veldig bra, men det finnes ikke i norsk layout.

 

 

Hadde Logitech G19 og Corsair K95 Cherry MX Red før nåværende Logitech G910, enkelt kan man si at begge disse byttene var et syvmils steg i riktig retning på total opplevelsen.

Forskjellen med G910s "Romer-G"-knapper er at de har kortere gange som enkelte foretrekker, men ingenting tyder på at de så langt overgår Cherry MX i kvalitet.

 

Til skriving er taktile Cherry MX suverent best.

 

Men den Musa..... føler ofte det ikke skjer noe raskt nok når musa brukes og da spesielt venstre knappen som avtrekker, av og til tar det noen bitte små evigheter (report rate 1000Hz/sec), akkurat som med Logitech G9x/G402/G502/ og en billig mus fra netthandelen.

Jeg synest det er vanskeligere å finne gode muser enn tastatur. I mange år brukte jeg en god Razer Krait frem til ledningen ble dårlig, så Razer Abyssus som har vært OK. I fjor kjøpte jeg nye Abyssus og den virker mye mer ustyrlig og uresponsiv enn den gamle. Å finne en god mus uten ekstra knapper er noe jeg sliter med.

 

980ti går jo for 6200 som demovare på komplett litt nærmere da hvertfall.

Det kan være et kjempekupp, eller et kort som har vært sent i retur pga. hyling.

Hvis etterspørselen etter båndbredde for mobile enheter fortsetter å vokse så er en drastisk økning i basestasjoner eneste løsning i tettbebygde strøk.

 

-----

 

Hvis Californias byer dekkes av slike master så vil de kanskje endelig bli kvitt alle hippiene.

Jeg ser for meg at det blir mye hærverk på skoler fremover.

 

Men den som har legitime grunner til å destruere data bør nok heller skaffe en lagringsenhet som kan destruere seg selv, ikke datamaskinen. Det finnes SSDer som kan gjøre dette.

Et alternativ vil være å ha krypterte partisjoner og så kun slette nøkkelfilen ved behov.

I dag ble Steam machines tilgjengelig i noen land, og Valve har startet et lite salg på spill.

Gå for GTX 970 du, gode alternativer fra blant annet Asus, EVGA og MSI.

Burde vel gå an å rense støy som skurring vekk med moderne redigering vel?

Kanskje de skulle lage en parallell webside som har redigert (renset) lyden til originalkopiene?

Og samtidig vaskes alle detaljene i lydopptaket bort.

At produsenter leverer varer så mange år etter at markedet er dødt skyldes som regel at de har forpliktet seg til å levere rekvisita og reservedeler i x antall år til bestemte kundegrupper.

Et annet eksempel er Intel som produserte 80386(fra 1986) frem til september 2007.

 

At det skal være noen som TV-stasjoner eller lignende som har brukt slikt ustyr frem til nå tviler jeg ikke et sekund på. Det er heller ikke mange år siden jeg så en diskett i helsevesenet, og kanskje det fremdeles er i bruk noen steder.

Downsampling (Nvidia DSR eller AMD VSR) bruker samme anti-aliasing-teknikk som SSAA, men det er én forskjell som er verdt å bite seg merke i: Downsampling er støttet i skjermkortdriveren, i motsetning til SSAA som er implementert i selve spillet. Dette betyr at spillet faktisk tror det kjører på en skjerm med høyere oppløsning – og tekst og menyer blir derfor nedskalert i tillegg til selve grafikken. Dette skjer ikke med SSAA, da spillet kan velge å kjøre anti-aliasing på alt bortsett fra menyer.

Dette er helt feil. SSAA har vært implementert i driveren siden GeForce 3 eller før.

Hvis en bruker stiller inn AA fra driveren så vil normalt alle framebufre bruke denne innstillingen. Hvis et spill skal tegne deler i en annen type AA så må spillet eksplisitt overstyre driveren, noe som gjøres ved hjelp av native API.

 

Hvis du kjører 4xSSAA på en skjerm med oppløsning på 1920 x 1080, vil det i praksis bety at du får samme FPS (bilder i sekundet) i spillet som om du hadde spilt med oppløsning på 3840 x 2160. Skjermkortet må tegne fire ganger flere piksler, og gjøre omtrent fire ganger mer arbeid.

Dette er feil. 4xSS betyr skalering med en faktor på 4. Dvs. 4x i x-retning og 4x i y-retning som gir 16 ganger så høy oppløsning.

 

For å vise at dere tar feil har jeg for moro skyld testet dette med et tomt OpenGL-vindu på 1024x1024 (for enkelhets skyld) i ulike AA modi:

            Samples:    RAM:
Normal      1           12 MB
2xMS        2           28 MB
4xMS        4           41 MB
8xMS        8           70 MB
8xMS 8xCS   8           72 MB
4xSS 4xMS   16+4        135 MB

Hvis 4xSS var 4 samples så skulle minneforbruket vært betydelig lavere.

 

MSAA er også en form for supersampling, men fungerer ved at MSAA detekterer kantene på objekter og kun øker oppløsning der. I det nest øverste illustrasjonsbildet i denne saken betyr det i praksis at MSAA først finner ut hvor kantene til firkanten og rektangelet er, og deretter tegner kun denne delen av bildet med høyere oppløsning. Fordelen med MSAA er at metoden unngår unødvendig prosessering ved å kun kjøre supersampling på steder hvor det sannsynligvis er nødvendig, men resultatet blir ikke like bra som SSAA. 2xMSAA bruker to stikkprøver per piksel for å bestemme fargen og 15-20 % redusert ytelse, mens 4xMSAA bruker fire stikkprøver og så videre.

Hadde dette vært sant så hadde SS vært like bra som MS. Dere har totalt misforstått hvordan MS fungerer i forhold til SS.

 

Hovedoptimaliseringen med MSAA er at samples er spredt i stedet for et rutenett, som gjør at få samples kan eliminere aliasing langt mer effektivt.

2xSS - 4 samples i rutenett

4xMS - 4 samples spredt

4xSS - 16 samples i rutenett

Ulempen med rutenett er at det faktisk forblir mye aliasing igjen med 2xSS, og 4xSS begynner å bli veldig tungt.

Av denne grunn vil f.eks. 8xMS gi langt mer effektiv antialiasing per ressurs enn 4xSS, selv om 4xSS vil bli noe skarpere. Dette er grunnen til at SS er bedre; fordi SS bruker flere samples mens MS prøver å optimalisere bruken av samples.

 

Enhance Quality AA (EQAA) fra AMD og tilsvarende Coverage-Sample AA (CSAA) fra Nvidia er begge forbedringer av MSAA. Disse teknologiene utnytter muligheten skjermkort har for å sjekke om et objekt, som en firkant, dekker et stikkprøvepunkt. Da det krever mye mindre av skjermkortet å sjekke dette kontra å finne den spesifikke fargen til punktet, er det mulig å gjøre en bedre tilnærming av fargen til en piksel.

CS/EQ krever lite ekstra fordi coverage tar opp lite minne i forhold til farge. ref.

Kjøping på kreditt er noe du aldri bør gjøre, du sparer ikke mye penger på tilbud da.

For et GTX 970 i 1440p så vil GPU-ytelse være et mye større problem enn minnekapasitet.
Ved kjøring som enkeltkort vil både GTX 970 og GTX 980 først støte på flaskehals ved GPU-ytelse, så minneytelse og til slutt minnekapasitet. At noen spillere klarer å fylle hele GPU-minnet og ytelsen blir dårlig trenger ikke å være et kapasitetsproblem, ren matematikk vil fortelle deg at dersom du prøver å bruke f.eks. 4 GB per bilde i 196 GB/s vil aldri tillate over 49 FPS. Og siden en GPU aldri bruker minnet 100% optimalt så vil i praksis minnebussen bli et problem lenge før kapasiteten. I praksis får du i beste fall 30-40 FPS som Nizzen sier, selv om kortet hadde hatt 16 GB minne.

Mulig jeg da går for et 970 ventekort til jeg skal oppgradere hele riggen. Synd Cannonlake ikke kommer samtidig som Pascal.

Vel, når Pascal kommer og du ønsker en "big pascal" så bør vel du vurdere en "Broadwell-E" som CPU?

Enig, de to alternativene er GTX 970 og GTX 980 Ti. GTX 980 blir "for nær" GTX 970 ytelsemessig men fremdeles en del dyrere.

For 1440p så er GTX 980 Ti et klart valg.

 

GTX 980 6 GB? Har jeg sovet i timen nå? Den var ny for meg.

Tenkte nå jeg skulle koble musa til PS/2 via en overgang fra USB som fulgte med HK. Vil dette gi en teoretisk forsinkelse på ca 0.73 ms?

Teoretisk vil det være 0.73 ms (per event) + en eventuell liten prosesseringsforsinkelse i musen/tastaturet. Dette er basert på studering av seriellprotokollen som brukes i PS/2.

 

Det er ikke garantert at alle tastatur og muser støtter PS/2-modus.

 

Ville først koble musa til mitt Logitech G910 tastatur, og så via nevnte overgang til PS/2 porten, men den gang ei siden tastaturet ikke har ekstern tilkobling for USB.

Hvis du forsøker å koble musen via tastaturet så vil ikke det fungere med PS/2. Det er bare å gi opp med et slikt tastatur.

 

Såpass dyre tastaturer bruker å ha relativt gode kontrollere, men dessverre gir ingen produsenter ut nok informasjon om hva som faktisk skjer.

 

Standard USB HID-tastatur støtter egentlig bare opptil 6 frie tastetrykk og sender de i kombinasjoner i USB 1.1-hastighet som gir opptil 10 ms forsinkelse pga. verifisering i protokollen. Det som er vanskelig å forstå er at en rekke dyre tastaturer har i flere år jobbet rundt dette med å avvike fra standarden eller bruke helt egne protokoller, som kan medføre noen kompatibilitetsproblemer. Men det største problemet er at vi har ingen måte å vite hvor raskt tastatur A er i forhold til tastatur B uten spesialutstyr, for det er ikke sikkert at de utnytter hele hastigheten til "USB 2.0" eller "USB 3.0". Så det er vanskelig å finne ut hvor raskt ditt G910 er sammenlignet med f.eks. et DasKeyboard 4 eller med et billig Dell-tastatur. På grunn av denne problematikken har mange av oss sverget til dyre PS/2-tastaturer fordi vi vet at de er bra. Men hvor bra de er i forhold til dit G910 aner vi ikke. Kanskje til og med noen tastaturer er raskere, men det burde vi hatt testprotokoller for å måle.

 

Har en Acer XB270HU "IPS" skjerm med 4ms, snakkes mye om denne kontra den opprinnelige Rog skjermen som har 1 ms og pga dette egner ROG skjermen seg bedre til FPS spill.

Hvis jeg da kan spare inn ca 9 ms på og koble litt om på ting, ville det i hvert fall bety noe psykisk om ikke i praksis.(?)

Vel, nei du snakker her om noe helt annet. Input lag (forsinkelsen frem til det skjer forandring) er svært bra på din XB270HU med sine 3 ms som er nær CRT-nivå, men gray-to-gray-reponstid på 4 ms som din har (kontra ned i 1 ms på TN) er noe som hovedsaklig påvirker hvor mye etterslep du får.

Jeg har innimellom stusset på hvorfor det er så vanskelig for enkelte spillutviklere å la spillet kjøre i så mange frames som brukerens PC klarer. Som med Skyrim for eksempel. Men også fremdeles leser man om spill som blir cappet på 30 eller 60 fps selv på PC. (De er vel utviklet på konsoll først da.) Er dette grunnet for treg game loop?

Det er en mulig forklaring ja, at spillets interne logikk er såpass krevende at de må legge slike begrensninger, uten at jeg har analysert det spillet på denne måten. Alternativet må vel være at de med vilje har prøvd å synkronisere bildeflyt på en dårlig måte.

 

Siden slutten av nittitallet så har vel PC-spill stort sett hatt 100Hz eller mer, men i konsollverdenen har spills ytelse og timing vært nøye kontrollert opp gjennom årene. I NES, SNES og mange flere var klokkefrekvensen justert i forhold til utgangssignalet slik at spill kunne bruke CPUens klokke som timing, som av naturlige årsaker var "nødvendig" den gangen for å få grei bildeflyt. Også en rekke DOS-spill var kodet på en måte som gjorde de for raske på kraftigere maskiner.

 

Jeg vil anta at PC-spill i dag ligger et sted mellom 120 og 1000 Hz.

 

Game loop er for meg et nytt uttrykk. Er det slik å forstå at om en game loop er på 16,7ms, så vil et skjermkort som rendrer en frame på 3,3ms lage ett bilde, og så komme tilbake til, hva skal man kalle det? Enden på game loopen? Som fremdeles består av samme informasjon, og dermed blir neste bilde også identisk med det forrige? Altså man får 5 identiske bilder etter hverandre, og det vil man få også på en hypotetisk 300Hz skjerm? Og dersom man får game loopen ned i 5ms, så blir høyeste mulige fps med unike bilder 200? Jeg bare prøver å se om jeg har forstått riktig.

"Game loop" har kanskje flere navn, men det går enkelt og greit ut på den biten av programmet som får ting til å skje, altså den koden som tar all input, følger spillets regler og genererer en output som renderingen kan begynne på.

 

Frem til dobbeltkjerner ble vanlige så brukte faktisk spill å gjøre tegningen i game loop. Nå vet ikke jeg hva du kan av koding, men logisk sett så det slik ut pseudo-kode:

while (true) {
    if (diff(last, now()) > threshold) {
        read_input();
        game_logic();
    }
    render();
}

Dette er altså en bit med kode som kjører om og om igjen så lenge spillet kjører; leser input, gjør spill-logikken og tegner. Hvis du forstår snutten over så ser du at dette åpenbart vil medføre at rendering og spill-logikk vil kunne påvirke hverandre, altså tunge rendering-partier gjør spill-logikken uresponsiv og tung spill-logikk får rendering til å henge(mest problematisk for strategispill). Som du sikkert forstår er dette grunnen til at nesten alle spill gjør dette i separate threads i dag.

 

Hvis du tenker deg om så forstår du sikkert at det er ønskelig at spillets logikk skal gå så jevnt som mulig. Det vil være ganske dumt om du kjører et bilspill og så varierer spillets hastighet med hvor tunge ulike partier av løpet er. Det er ennå viktigere i spill som spilles over nettverk, f.eks. ville det vært rimelig dumt om det var best å spille Starcraft på en tregest mulig maskin. Det er naturlgvis til en viss grad mulig å lage en loop som ikke er kontrollert av en timer, men dette går på bekostning av presisjon og gjør det nær umulig å lage en fungerende kompleks spill-logikk. Hvis du skulle laget et spill som ikke er tidsbasert så kommer du unna med det, men om du skal lage Tetris så må du åpenbart time nøyaktig.

 

Slik ting fungerer i moderne spill blir spillets logikk utført før en tilstand blir overført til rendering-thread, ellers ville "spillbrettet" forandret seg mens skjermkortet tegnet, så spill lager derfor "snapshots" av spillets tilstand slik at renderingen blir korrekt. Hvis en game loop er ferdig hvert 5.ms så vil det alltid ta minst 5ms pluss tiden renderingen tar før et museklikk hos operativsystemet har blitt til en reaksjon i et bilde (i tillegg kommer forsinkelsene til punkt 1, 4 og 5 fra forrige innlegg).

Hypotetisk eksempel:

(museklikk)

Forsinkelse i hardware: 10 ms

Køing i operativsystemet: 5 ms

Intervall til game loop: 5 ms (200 Hz)

Rendering: 10 ms (100 FPS)

(vi sier du kjører uten V-sync)

Input lag på skjermen din: 5 ms

Totalt: 35 ms fra museklikk til reaksjon på skjermen (dette er mye bedre enn du får i praksis).

Så bytter du skjermkort slik at rendering tar 7 ms, nå er total responstid 32 ms.

 

Så for å svare på spørsmålet, hva skjer når du tegner raskere eller tregere enn spillets interne klokke? Se nøye på tegningen:

(nummereringen er bare for å indikere hvilken spilltilstand som tegnes)

Rendering thread vil hente siste ferdiggenererte spilltilstand, uavhengig av om forrige bilde var det samme.

Nå er der selvfølgelig hull i mine kunnskaper også. Et av dem blir avdekket her, og det er at jeg ikke vet nøyaktig hvordan et skudd i FPS spill registreres. Jeg har forsøkt å google det, men informasjonen jeg har funnet har som regel ikke virket helt troverdig (besservissere på forum ), eller over mitt hode (for teknisk). Så jeg er på litt tynn is her.

La meg forsøke en teknisk forklaring.

Måten spill får input på er at de leser en kø med IO events fra operativsystemet. Så med et fast tidsintervall tar spillet alle statusendringene og genererer en ny spilltilstand, dette kalles en "game loop". Det er her all spill-logikk skjer; bevegelser, kollisjoner, skyting, osv. For at et spill skal være spillbart må game loop kjøre uten problemer på minstekravene til spillet, og minstekravet setter derfor restriksjoner for hvor kompleks spill-logikk kan være. I nettverksspill (f.eks. skytespill) så utføres selve spill-logikken på serveren, mens klientene bare sender sine events til serveren og får ferdige spilltilstander tilbake. Normalt må altså serveren behandle alle events før spillet får en ny tilstand det kan tegne. Derfor blir latency mellom spillere og host svært viktig, som enhver spiller har erfart. En rekke spill har gjort noen "jukseløsninger", som f.eks. WoW hvor klienten selv også gjennomfører spill-logikken, men får med jevne mellomrom korreksjoner fra serveren som gjør beregningene parallelt. Dette medfører at spillet plutselig får "hopp" der spilleren plutselig er i en annen situasjon. Det er forøvrig ikke uvanlig at spill lar deg snu på kamera eller lignende, selv om all handling i spillet må genereres av server.

 

Latency i spill er et mye større problem enn mange er klar over, og det er en lang kjede av problemer: (dette har vært nevnt før av meg)

1) Hardware input: Forsinkelsen fra kontrolleren din til operativsystemet. For PS/2 ~0.73 ms per trykk, USB HID opp mot ~10ms(pga. verifisering), Bluetooth opp mot ~30ms med HID. I tillegg finnes det ikke-standardiserte protokoller.

2) Operativsystem- og driverhoverhead: Operativsystemet driver med scheduling av threads, venter på kall fra drivere, køer opp IO events, osv. Kan typisk legge på ~1-3ms på IO events, ~1ms på threading, mutex, osv., ~1-2ms på skjermkortdrivers synkronisering av frames, switching, osv. Løsningen her er en "semi-realtime" kernel som øker kjernens interne scheduler og timer slik at forsinkelser blir rundt 0.01ms på bekostning av med CPU-last. Kun Linux tilbyr dette i dag av desktop-opertivsystemene.

3) Spillmotoren:

a) Her kommer spillmotorens interne flyt og styring inn, hvordan events leses av og hvordan game loop gir tilstandene sine videre til rendering. Forsinkelsen kan være helt opp mot 15-20 ms, men gjerne mye lavere også. Jeg tror 5-10 ms er vanlig her. I spill som kommuniserer med en server kan forsinkelsen her være betraktelig høyere.

b) I tillegg kommer tiden det tar å tegne selve bildet. Ved 60Hz er det 16.67 ms, så raskere tening kan gi kortere forsinkelse i dette leddet, men da trenger du en skjerm som kan følge med eller vil risikere tearing, eller du må hoppe over bilder.

4) Buffering: Brukere som har V-sync aktivert vil få et ekstra ledd med forsinkelse ettere tegning av bilde, som er opptil ett bildes forsinkelse (16.67ms ved 60 Hz). Løsningen er adaptiv synkronisering eller deaktivering av V-sync.

5) Skjermens input lag: Skjermer bruker i dag en del tid fra de får et bilde til det vises. Denne forsinkelsen er normalt konstant for en skjerminnstilling. Dette kan gi ~2-35 ms ekstra forsinkelse.

I praksis kan et bra spill gjerne ha 50ms fra museklikk til piksel på skjermen, som referert til her (denne sammenligningen tar ikke med hardware input).

 

Alt dette gir et par viktige observasjoner:

- Høyere skjermfrekvens gir bare bedre bildeflyt hvis spillet genererer nye tilstander raskt nok, ellers vil skjermen tegne flere like bilder.

- Men, raskere tegning kan gi kortere forsinkelse selv om game loop ikke er rask nok* og/eller skjermen ikke er rask nok(uten sync). Eks. 300 FPS på et spill med game loop i 60 Hz gir fem like bilder etter hverandre, men forsinkelsen i rendering(steg 3b) 3.33 ms mot 16.67 ms ved 60 FPS.

*) Under forutsetning at den er implementert non-blocking.

 

Men slik jeg har tolket det, så må koordinatene for hvor siktet befinner seg i det du trykker inn museknappen registreres på et bilde tegnet av skjermkortet.

En rekke spill bruker bare muskoordinatene og kamera til å generere en 3D-vektor og sjekker hvilke objekter denne treffer. Alternativt kan såkalt 3D picking brukes, hvor dybdebuffer og en fargebuffer fra forrige bilde brukes til å finne ut hva musen pekte på. Men det trengs ikke tegne et nytt bilde for å finne dette ut.

 

Om skjermkortet bruker 15ms på å tegne det bildet, må du nødvendigvis vente 15ms på det. Om skjermkortet bruker 5ms, så har du potensielt kortet inn din da i praksis reaksjonstid med 10ms. Reaksjonstiden din er jo selvfølgelig egentlig akkurat den samme, men tiden det tar før informasjonen kan sendes til spillserveren er kortet inn.

Riktig tenkt, bortsett fra at tiden det tar å tegne bare er en liten del av hele kjeden.

 

Og her kommer da videre innkorting av ms ping med "spill-routere" og "spill-nettverkskort" inn i bildet. Men også for eksempel at det er 1ms polling rate fra mus og tastatur. 1000Hz mus kalles det kanskje? Jeg regner med de fleste spillmus har det. Men om man gamer med ei "kontormus" fordi den kjennes god ut i hånda, så kan det være at man snyter seg selv for et par millisekunder.

Ja her er du inne på mitt punkt 1. 1000Hz mus betyr vel bare hvor raskt sensoren leses av, men det kunne vært interessant hvor raskt bevegelsene sendes. Men nå antar jeg at dyre spillmuser "tweaker" HID og kanskje sender raskere enn protokollen skulle tilsi.

 

Angående nettverksutstyr så kan det selvsagt spille en stor rolle. Selv alle "gigabit"-nettverkskort, -switcher og -routere yter ikke det samme. Her får du akkurat hva du betaler for. Hvis du bryr deg om latency så styrer du åpenbart unna trådløst nett. Men du skal i tillegg være klar over at selve nettverksstrukturen din kan spille inn. Hvis du f.eks. deler nettverk med noen som belaster et trådløst tungt eller har dårlig signal og du er koblet på kabel gjennom dette aksesspunktet så kan ytelse/stabilitet påvirkes av andres belastning. Derfor foretrekker jeg å bygge et internt nettverk av bare "dumme" switcher av god kvalitet, og så koble aksesspunkt ut fra dette slik at ustabile trådløse aksesspunkt med haugevis av crap-firmware ikke påvirker resten av nettverket.

 

Om dette er riktig, er det viktig å ha høy fps. Så 300fps på en 1080p skjerm er dobbelt så raskt som 150fps på en 1440p skjerm. Skal du rettferdiggjøre kjøpet er det altså denne 200Hz skjermen du skal ha.

Vel, ja og nei. Svart på under observasjoner^^.

 

Men så kommer vi også til et punkt der det kanskje er like greit å si at; "disse siste millisekundene er nok ikke de som avgjør om jeg vinner eller ikke.". Dersom du kan gi skjermen din 165fps, så er vi nede i 6,06ms, en stor og klar forbedring over de 16,7ms en skjermoppdatering på en 60Hz skjerm gir. Men si at du spiller mot en "galning" som har skrudd av V-Sync på sin 144Hz skjerm, og får 300fps. Han har jo bare ~2,7ms fordel på deg. Men sitter han i Brasil, så har han sikkert 20ms lenger ping.

 

Poenget med å vite hva man kan gjøre for å korte inn den effektive reaksjonstiden vår mot spillserveren. Er at når alt annet ellers er likt, så vet man at man ikke kunne gjort noe mer. Noen av oss ønsker imidlertid å fremdeles kunne legge skylden på utstyret, og da er det altså bare å skru på V-Sync.

Vel, lokalt så har nok spillet ~50ms, og over Internett til et annet kontinent så snakker du fort om 100ms eller mer på toppen av det. Noen få ms mindre er selvsagt fint, men skjermfrekvensen alene vil ikke løse det du snakker om.

Jeg kunne godt tenkt meg en test av ulike spill som tester med høyhastighetskamera hvor høyt bilderaten kan gå før vi får to like bilder. Da har du svaret på om skjermen har noe for seg.

 

Bedre farger?

http://www.tftcentral.co.uk/reviews/asus_rog_swift_pg278q.htm

DeltaE på under 1.0 er jo praktisk talt umerkelig for de fleste.

Forskjellen på skjermene er innsynsvinkler og etterslep.

 

Ja IPS er kjent for å ha bedre farge gjengivelse enn TN, og noe alle som tester disse skjermene skriver om. Om man merker det i praksis er noe annet. Jerg har aldri hatt en TN skjerm, så der kan jeg ikke si noe.

 

Og der sier du nøkkelen "IPS er kjent for å ha bedre farger", uten at folk forstår hva det dreier seg om.

Det stemmer at grafikerpaneler har bedre farger (og ofte bedre prosessering) enn de beste TN-panelene, men det betyr ikke at alle IPS-paneler har bedre farger enn TN-paneler. Når du finner to paneler som har samme fargerom, samme fargegradering, samme fargefeil og gammakruve og er jevne og fine, hva er det det da som gjør at IPS-paneler har bedre farger?

 

Faktum er at folk flest mistolker IPS-panelers kraftigere lysstyrke som "bedre farger" siden de gir mer intense farger. Men saken er at paneler som fremstår slik er garantert feilkalibrert. Bedre farger handler om høyere presisjon og gradering, ikke i lysintensitet. Så forskjellen på fargene for et godt og et dårlig panel ser du i detaljene.

</grunnkurs i skjermteknologi>

Antar at du kan spille alle spill som kommer i Linux versjon.

Om steam Box blir en suksess kommer nok flere spill som bruker standard engines men Linux støtte til å komme for den.

Unntaket er Steam konkurenter og spill som bruke egene engines som Bethesda

Men det er ingen problem med dual boot og Windows på den.

Mange populære spillmotorer har støtte eller kommer med støtte.

Source: støttet

Unreal: støttet

Unigine: støttet

Unity: støttet

Id tech 4: støttet

Id tech 5: på vei(?)

Cry Engine: på vei

Frostbite: på vei(?)

Forøvrig støtter alle Blizzard-spill OS X, så de er en smal sak å porte.

 

Så hvis Valve beviser at de er seriøse så kan mengden av spill forbedre seg over et par års tid.

Hva med SLI\crossfire, 3dvision, Gsync, Freesync, oppskalering etc.

Kanskje linux har mere stabile drivere, men tviler på en linux kan konkurere mot windows på drivere med mindre jeg sitter på ganske gamle drivere.

 

Etter min erfaring får man bedre FPS i windows enn linux.

SLI, 3D vision, G-Sync er støttet i Linux. Hva mener du med oppskalering?

 

Som sagt er Nvidias Linux-drivere utmerket, men det er ikke tilfellet for de øvrige.

 

Tror du virkelig det er så mye mer ytelse å hente at markedet beveger seg over fra maskiner de synes er helt grei, kjenner godt til fra før, med et dramatisk mye bedre spillutvalg og priser som allerede er ganske nedpresset og vanskelig å konkurrere mot da de får kjempeavslag for masseproduksjonen Sony og Microsoft driver med?

Nå handler SteamOS-satsingen til Valve også om å nå ut til nye kundegrupper. Det er langt flere som er interessert i en spillemaskin som de kan bruke foran TVen enn en dedikert spille-PC til Battlefield eller lignende. Steam Machine vil derfor i stor grad handle om "casual gamers", og til det er spillutvalget allerede halvgreit, med 1500 titler å velge blant.

 

Nå vil nok Steam Machines i første omgang konkurrere mer med Nintendo enn Sony og Microsoft.

 

Spillkonsollene har riktig nok godt sponsede priser på maskinvaren, men til gjengjeld så koster spillene betraktelig mer. Mange vil nok velge Steam Machines som koster noe mindre enn $999, og det vil naturligvis ta flere år før markedet omstiller seg.

 

Spillutviklere tjener ingenting på å bruke mye tid og ressurser til å utvikle og optimalisere spill til Linux/SteamOS

I mange situasjoner er kostnaden av å porte et spill til Linux (og eventuelt OS X) marginal i forhold de totale utviklingskostnadene. Og om det øker salget med bare 2% så kan det fint være verdt det.

 

og massene beveger seg ikke over før både spillutvalget er lignende og ytelsen bedre.

I forhold til hva? Steam Machines skal ikke primært konkurrere mot stasjonære spill-PCer.

 

Den eneste måten jeg kan se hvor dette kan bli en suksess, er hvis Valve lager en kontrakt med hardware-tilbyderne hvor de betaler en enorm antall enheter for egen regning, uavhengig av salg, for å kunne være konkurransedyktig med de andre konsollene og PCene, eventuelt selge med tap en stund i håp om at det slår an og de kan tjene det tilbake på fremtidige generasjoner. Samtidig må de inngå avtaler, hvor de sannsynligvis må betale store summer, med flere store utviklerstudio. Men det er en enorm risiko som de sannsynligvis ikke er villig til å ta.

Du har ikke forstått hensikten du.

Valve har forøvrig avtaler med flere utviklerstudioer, og har bistått i porting av en rekke spill allerede.

 

De skal ha kudos for å prøve, men jeg er ytterst skeptisk til dette. Bedre å utvikle SteamOS og lisenser det ut til andre aktører for fri bruk av det.

Er det ikke akkurat det som de gjør da?

er det mulig og bygge dene konsoll-pcen skjøl? bare kjøpe operativ systemet og kontrollene osv?

Ja, faktisk!

Det geniale med Valve er at de ikke tvinger deg til å kjøpe en pakkeløsning. Så enten du vil bygge maskin selv, bruke en vanlig feridgbygd, bruke en "Steam machine", og/eller en tredjeparts håndkontroller så kan du gjøre det fritt. Hensikten med "Steam machines" er at det finnes mange som ønsker en stue-PC som ikke ønsker å bygge en selv. De som foretrekker å bygge selv vil selvsagt kunne fortsette med det

 

SteamOS i seg selv vil også være gratis. Det har vært snakk om at maskinene skal kunne leveres med Windows også, og du vil alltid kunne legge det inn selv.

 

Må ikke spillene være kompilert for Steam OS for at dette skal fungere? Hva da med de store titlene som GTA V, Fallout 4 osv. Utviklere på disse plattformene har jo optimalisert kode i mange år på PC plattform. Greit at Steam OS krever mindre ressurser, men vil ikke en optimalisert kode på PC plattform kjøre bedre enn uoptimalisert kode på Steam OS. Hva vil det eventuelt koste ekstra å utvikle et storspill for to plattformer?

 

Er ikke så sikker på at Steam OS blir den store suksessen.... Så gjelder det kontrolleren. Er den bedre enn big screen gaming med Ps4, Xbone kontroller?

Ja spillene må manuelt portes, en rekke spillmotorer støtter allerede OpenGL som gjør jobben ganske enkel. Så langt er det over 1500 spill som er portet til Linux, men mange store titler gjenstår.

 

Kode som er optimalisert for "PC"(jeg regner med du mener Windows-spill) vil være optimalisert CPU- eller GPU-kode. Denne skal kunne kjøre uavhengig av operativsystem. Den største jobben vil være konvertering fra Direct3D til OpenGL, som kan variere i vanskelighetsgrad.

 

Så hva er fordelen med dette fremfor å koble til en PS4/Xbox-kontroller på PCen? Er det virkelig så mye mer kraft å hente ut gjennom et Linux-basert system? Hva er sannsynligheten for at utviklere vil kaste seg på og utvikle og optimalisere spillene sine for dette OSet?

For det første handler det om at Valve trenger et operatvisystem de kan tilpasse. Teknisk sett er det åpenbare fordeler med å velge Linux, som tillater både bedre ytelse, lavere latency(med bestemt kjerne) og kontroll over plattformen. Den ene og veldig store ulempen er at Nvidia er den eneste leverandøren med gode drivere for Linux, men til gjengjeld er de på mange vis bedre enn Windows-driverne.

 

Eneste alternativ hadde vært BSD (som f.eks. PS4 er basert på), men Linux er mye mer utstyrt og har betraktelig bedre drivere.

 

Linux har i dag OpenGL og i fremtiden Vulkan. Mantle er lagt død av Direct3D 12, men så var det bare en mellomløsning.

Takk til deg og

 

Prøver å nøste opp litt for meg selv her... Vulkan både til AMD og Nvidia? Eller får ikke det grønne laget lov til å leke med ilden?

 

Se her, side 3.

Av spillselskaper så er det hovedsaklig Valve, EPIC og Unity som har uttalt at de kommer til å bruke det, uten at vi vet i hvilken grad.

Det grønne laget er ventet å være de første som kommer med støtte.

 

]DirectX 12 er på plass i Windows 10.

I frykt for å spore totalt av nå, men har linux (eller hva det nå er Steam OS) ekvivalent til Dx(12), Mantle etc?

 

Spørsmålet er helt kurant.

Linux har i dag OpenGL og i fremtiden Vulkan. Mantle er lagt død av Direct3D 12, men så var det bare en mellomløsning.

Siden Zotac har bekreftet at den ikke kommer til Norge, så har de vel en begrunnelse?

 

Høres spennende ut, men tviler på DX12 eller 3d Vision 2 eller

Noe slik er på plass ennå.

DirectX 12 er på plass i Windows 10.