Lag (computerslang)

Den aktuelle version af siden er endnu ikke blevet gennemgået af erfarne bidragydere og kan afvige væsentligt fra den version , der blev gennemgået den 10. marts 2018; checks kræver 185 redigeringer .

Lag (fra engelsk  lag , [læɡ]  - "forsinkelse", "forsinkelse") - en forsinkelse i driften af ​​en computerapplikation, når den ikke reagerer på brugerinput i tide. Dets afledte "lag" bruges i vid udstrækning af internetbrugere til at angive forsinkelser i driften af ​​forskellige internettjenester og onlinespil. Spillere bruger også ordet "lag" i forhold til selve programmets forsinkelser. Findes ofte i online spil. Fra et teknisk synspunkt er det en manifestation af indflydelsen af ​​latensen af ​​datatransmission og behandlingsoperationer på kvaliteten af ​​realtidssystemet .

spilreaktionsforsinkelse

Analyse

Selv i et enkeltspillerspil består forsinkelsen mellem tryk og billedet af flere dele [1] [2] :

• Fysisk lukning af knappen.
• Tastatur/mus interface respons. Reaktion fra tastatur-/musbehandlingsundersystemet.
• Beregning af fysik af spilmotoren .
• Inaktiv tid i gengivelseskøer [2] .
• Rammegengivelse.
• En enkel færdig frame fra slutningen af ​​gengivelsen til at skifte buffere og derefter - før den passerer gennem videogrænsefladen.
• Hvis spillet er i vinduestilstand, selv uden ramme, er vinduesadministratorens arbejde kilet ind mellem dem [2] .
• Reaktionen af ​​enheder, der konverterer signalet i skærmen [3] [4] [2] (forstør billedet [3] [5] , forbedre kvaliteten [6] ) - især hvis der i stedet for en skærm er et tv, og det har ikke en "spil"-tilstand.
• Fysisk respons af LCD-pixels [3] .

I et netværksspil tilføjes den tid, det tager for pakker at rejse fra computer til computer .

Spiller også rollen som microlags eller stutters - frames, der er tegnet længere end andre [7] . Normalt sker der mikrolags, når tingene i spillet bliver alvorlige [7] (pistolkamp i FPS, tung trafik i et løb) - derfor påvirker mikrolags oplevelsen af ​​spillet endnu mere end den gennemsnitlige forsinkelse.

For at reducere forsinkelser skal du anvende følgende foranstaltninger:

• Fra spillerens side:
  • Højhastighedstastaturer og -mus - spillere bruger enheder med en busfrekvens på 1000 Hz, knapper med kort vandring og lineær respons , optomekaniske kontakter.
  • Forøgelse af billedhastigheden  - køb af en hurtig computer, hvilket reducerer billedkvaliteten.
  • At finde en flaskehals i spillet, der vil reducere ventetiden på en given computer.
  • Hurtig skærm. "Spiltilstande" i tv'er.
  • Hurtig netværksforbindelse. Deaktivering af husstande, der optager hele netværket - for eksempel download af store filer. QoS i routeren, konfigureret til fordel for spillet.
• Fra udvikleren og udgiveren:
  • Optimering af forskellige undersystemer af spillet - grafik, netværk, dataindlæsning ...
  • Spillere i onlinespil er opdelt i regioner (Europa, CIS, USA ...), og serveren er placeret tættere på dem.

Lag i online spil

Hvis forsinkelser fra en knap til et billede først begyndte at blive bekæmpet i 2010'erne, begyndte computernetværksforsinkelser at spille en rolle fra de første år med spil på internettet og er næsten altid mere signifikante end andre typer forsinkelser (undtagen særlige cases - eSports , det vil sige at spille på et ubelastet lokalt netværk). Især lys rejser langs Jordens ækvator på 130 ms - sådan et ping anses for uacceptabelt af moderne spillere, og dette er teoretisk set den mindste figur, når spillere befinder sig i forskellige dele af Jorden.

Strengt taget bliver hver transmitteret pakke leveret med en forsinkelse, men forsinkelser er normalt kun mærkbare forsinkelser, der forstyrrer et normalt spil. Samtidig afhænger spillernes opfattelse af lags af mange faktorer, primært relateret til nøjagtigheden og reaktionstiden, der kræves i et givet spilmoment [8] . Typisk er netværksforsinkelse forårsaget af netværkspakketab og den tilhørende gentransmission af tabte netværkspakker.

Arkitekturen i Doom (1993) var den enkleste: hver spiller har en komplet spiltilstand. Hver cyklus (35 cyklusser i sekundet, 1 cyklus = 28 ms) sender spilleren kontrolknapper ud til de andre. Så snart spilleren har samlet knapper fra alle deltagere i netværksspillet, bruger han en ny cyklus [9] . Det samme lys rejser hen over USA på 15 ms, og denne arkitektur er nok selv til et modemspil gennem flere amerikanske stater.

Der er så stor forskel på moderne spil og Doom .

1. En sådan arkitektur er mangelfuld i andre henseender: den er ustabil over for snyd , den giver dig næppe mulighed for at gå ind i det spil, du har startet, eller smide spilleren ud ...
2. Telefonen bruger kanalskifte  - PBX giver abonnenten en garanteret båndbredde med en stabil forsinkelse. På internettet , pakkeskift  - en deltager sender en besked ( pakke ) til en anden, og mellemliggende noder finder ud af, hvordan den skal afleveres. Dette øger kapaciteten af ​​kanalerne og internettets overlevelsesevne - men enhver af noderne på netværket kan løse overbelastning ved at droppe pakken, forsinke den, starte den ad en anden vej osv., hvilket også øger forsinkelsen.
3. Hvis pakkerne tager lang tid, er kontrollen forsinket. Det er derfor , at Doom ikke spiller godt ved forsinkelser, der overstiger spilcyklussen.

Normalt løses spørgsmålet om forsinkelser på denne måde. Spillet har to tilstande - "garanteret" og "avanceret" [10] . "Garanteret" er, hvad der skete på serveren og kan ikke ændres på nogen måde ved pludseligt ankommende pakker, og kan sakke betydeligt bagud - mere end 100 ms. "Forward"-tilstanden bestemmes af spillerens lokale kontrol og pakkerne for de spillere, der har god forbindelse. På trods af dårlige tilslutningsmuligheder har hver spiller således responsive kontroller. Stereotypiske netværkslags ser sådan ud:

• hvis en anden forbindelse mistes i kort tid, "fryser" hans karakter først (står stille eller bevæger sig i en lige linje), og hopper derefter over. Hvis forbindelsen konstant er dårlig, bevæger karakteren sig i ryk;
• hvis din forbindelse afbrydes i kort tid, stopper hele spillet (se tab af forbindelse og stopper med at beregne den avancerede tilstand), og springer derefter øjeblikkeligt til en ny tilstand.

Siden Dooms dage har der været to måder at skyde på i spil - øjeblikkelig beregning af en kugles bane ( hitscan ) og et langsomt projektil ( projektil ). (Intermediate - en hurtig kugle - implementeres ekstremt sjældent og i meget realistiske spil fokuseret på snigskytte- og artilleridueller, vil vi udelade det.) Med projektiler vil spillet ikke afvige synderligt fra sandheden, hvis spilleren sigter mod den avancerede tilstand, og hits beregnes i henhold til den garanterede [11] . Det er umuligt at beregne baner på denne måde - der er ingen avanceret tilstand på serveren overhovedet, de er forskellige for forskellige spillere, og der er kraftfulde typer af hitscan-våben som en snigskytteriffel , for hvilke "hit-miss"-spørgsmålet er arkiv . Derfor bruges i mange motorer ( Kilde ) den såkaldte forsinkelseskompensation  - serveren gør en antagelse om, hvilket billede klienten så på tidspunktet for skuddet [12] . Udadtil ser det sådan ud: spilleren lænede sig ud af dækket, gemte sig med succes og blev dræbt allerede der, på et sikkert sted [12] .

Indvirkningen af ​​forskellige videoadapterfunktioner på forsinkelse af enkeltspiller

Basislinjen er et enkeltspiller- eller LAN -spil (netværksforsinkelser er ubetydelige), dobbeltbuffering er slået fra, spillet er konfigureret, så systemets billedhastighed er stabil og overstiger skærmens.

• Forringelse af billedkvalitet - reducerer latens, selvom ydeevnen er begrænset af en anden komponent (CPU/videokort), og den samlede billedhastighed ikke øges [2] .
• Dobbeltbuffering  - Øger forsinkelsen markant [13] .
• Triple buffering  - øger latensen endnu mere [13] .
• nVidia G-Sync , AMD FreeSync  - under sådanne forhold (systemets billedhastighed er højere end skærmens) er meningsløse. Hvis den er mindre, øger de forsinkelsen lidt [13] .
• Højhastighedssynkronisering (triple buffering, som fortsætter med at udfylde off-screen buffere i stedet for at vente på synkronisering) - under sådanne forhold øger forsinkelsen lidt [13] . Hvis systemets billedhastighed er mindre end skærmens, er det meningsløst.
• Vinduestilstand, selv et vindue uden rammer, øger latenstiden sammenlignet med fuldskærmstilstand [2] [14] .
• Kunstig billedhastighedsbegrænsning - reducerer latens, hvis ydeevnen er begrænset af videokortet [15] .
• nVidia Ultra-Low Latency / AMD Anti-Lag  - meningsløs, billedhastighedsbegrænsning er mere effektiv [15] .

Historie

I lang tid blev reduktion af spilforsinkelse reduceret til stigende billedhastigheder . Samtidig havde spilkonsoller i starten en fordel - fra de første generationer producerede de en høj billedhastighed (50/60 Hz), dette blev opnået ved specialiserede løsninger, der begrænsede spildesignet [16] , men gjorde systemet billigere: f.eks. Eksempelvis er Sega Mega Drive 16-bit med en frekvens på 7,6 MHz og lignende i ydeevne 80386 allerede 32-bit [17] og 12…40 MHz.

I begyndelsen af ​​2000'erne begyndte spil på pc'en konsekvent at give de samme 60 Hz som på konsoller, og gennem 2000'erne blev billedkvaliteten forbedret ved at programmere videokortet ved hjælp af shaders . Det tog adskillige gengivelsesgennemgange at tilføje belysning, refleksioner osv. [18] , og for at forhindre processoren i at vente, blev gengivelsen gjort forsinket [19] . Denne teknologi har spillet en grusom joke: Hvis videokortet er indlæst til det yderste, øges forsinkelsen fra klik til billedet. Begrænsning af billedhastigheden, endda op til 95 %, hvilket gør spillet nærmest "CPU-afhængigt", reducerer latenstiden [15] .

Latency har været i skyggen hele denne tid, fordi det er svært at måle - det kræver en modificeret mus (et tryk på knappen lyser en LED op ) og et højhastighedskamera [2] . Forskerne kunne måle et tal op til 120 ms, og selv ved en billedhastighed på 120 fps er det omkring 40 ms [13] [15] . En sådan forsinkelse kaldes nogle gange for "kiggefordelen" - at kigge ud bag en forhindring ved på forhånd, at forsvareren er på et givet punkt, og kan skyde foran, men forsvareren kan ikke [2] . I 2020 dukkede nVidia Reflex -teknologi op  - det giver spillet mulighed for at overvåge indlæsningen af ​​videokortet, og dette reducerer forsinkelsen betydeligt [2] . Teknologien er tilgængelig med enhver skærm og endda på relativt gamle videokort (startende med GeForce 900 ), men spillet skal understøtte det. (Den anden del af nVidia Reflex, latenstidsberegning, kræver en specifik skærm og tager højde for alt undtagen musehastighed og skærmpixel.)

Hundrededele af et sekund er vigtige i rytmespil , alle begivenheder er fuldstændig forudsigelige, og de afspilles normalt på konsoller, hvor outputenheden er et tv med sine egne billedforbedringsalgoritmer. Det er derfor, Guitar Hero og lignende spil har forsinkelseskalibrering [20] .

se også

• Vertikal synkronisering
• Læg på

Noter

1. ↑ Udforsker inputforsinkelse inde og ude . Hentet 28. april 2022. Arkiveret fra originalen 28. april 2022. (ubestemt)
2. ↑ 1 2 3 4 5 6 7 8 9 Introduktion til NVIDIA Reflex: Optimer og mål latens i konkurrerende spil | NVIDIA . Hentet 20. november 2020. Arkiveret fra originalen 19. november 2020. (ubestemt)
3. ↑ 1 2 3 Minute Science: Input Lag vs. Svartid - YouTube . Hentet 28. april 2022. Arkiveret fra originalen 28. april 2022. (ubestemt)
4. ↑ Faktorer, der påvirker pc-skærmens reaktionsevne | PC skærme . Hentet 28. april 2022. Arkiveret fra originalen 25. april 2022. (ubestemt)
5. ↑ Duck Hunt på et HDTV 2 på YouTube
6. ↑ Indstillinger for spiltilstand på dit Samsung TV | Samsung Australien . Hentet 28. april 2022. Arkiveret fra originalen 12. november 2020. (ubestemt)
7. ↑ 1 2 Sådan rettes stammen i spil - Billedhastighed, billedtid og RTSS - YouTube . Hentet 29. april 2022. Arkiveret fra originalen 29. april 2022. (ubestemt)
8. ↑ Mark Claypool, Kajal Claypool. Latency can kill: præcision og deadline i onlinespil  //  Proceeding MMSys '10 Proceedings af den første årlige ACM SIGMM-konference om multimediesystemer. - New York, NY: ACM, 2010. - S. 215-222 . - ISBN 978-1-60558-914-5 . - doi : 10.1145/1730836.1730863 .
9. ↑ Doom netværkskomponent | Doom Wiki | fandom . Hentet 8. maj 2022. Arkiveret fra originalen 7. juli 2022. (ubestemt)
10. ↑ Forudsigelse på klientsiden og serverafstemning - Gabriel Gambetta . Hentet 8. maj 2022. Arkiveret fra originalen 5. maj 2022. (ubestemt)
11. ↑ Lagkompensation - Officiel TF2 Wiki | Officiel Team Fortress Wiki . Hentet 8. maj 2022. Arkiveret fra originalen 8. maj 2022. (ubestemt)
12. ↑ 1 2 forsinkelseskompensation - Gabriel Gambetta . Hentet 8. maj 2022. Arkiveret fra originalen 27. april 2022. (ubestemt)
13. ↑ 1 2 3 4 5 Nvidia Fast Sync bedre end G-Sync og V-Sync? - Youtube . Hentet 29. april 2022. Arkiveret fra originalen 25. marts 2022. (ubestemt)
14. ↑ (Borderless) Windowed Mode Skal du bruge det? - Youtube . Hentet 29. april 2022. Arkiveret fra originalen 29. april 2022. (ubestemt)
15. ↑ 1 2 3 4 NVIDIA Reflex Low Latency - Sådan fungerer det, og hvorfor du vil bruge det på YouTube
16. ↑ James Hague. Stumbling Into the Cold Expanse of Real Programming Arkiveret 11. november 2020 på Wayback Machine . Oversættelse
17. ↑ For eksempel blev Disneys Aladdin og Løvernes Konge kun udgivet i beskyttet tilstand 80386.
18. ↑ Unreal's Rendering Passes - Unreal Art Optimization . Hentet 28. april 2022. Arkiveret fra originalen 19. april 2022. (ubestemt)
19. ↑ Multiple-Pass Rendering - Win32 apps | Microsoft docs . Hentet 28. april 2022. Arkiveret fra originalen 28. april 2022. (ubestemt)
20. ↑ Sådan rettes forsinkelsen i Guitar Hero på YouTube

Links

• Definition af lag i jargonfilen
• Definition af lag på webstedet for computerspil TASVideos.org
• Begyndende udvikling af iPhone-spil - PJ Cabrera, Peter Bakhirev, Ian Marsh, Ben Smith, Eric Wing, Scott Penberthy - Google Books . books.google.ru Hentet: 11. oktober 2012. (ubestemt)