'Tickrate multiplayer Black Ops 4 buiten battle royale om verhoogd naar 62Hz'

Volgens tests van een gebruiker op Reddit is de tickrate van de multiplayer van Call of Duty: Black Ops 4 verhoogd van 20Hz naar 62Hz. Dit geldt schijnbaar niet voor de battle royale-modus Blackout, die nog steeds op 20Hz draait.

De tests zijn uitgevoerd door gebruiker soja92 van /r/Blackops4, die melding maakt van de upgrade bij zowel de Windows-versie als de PS4-versie. Een week geleden bleek dat de verversingssnelheid ten opzichte van de bèta van de game verlaagd was van 60Hz naar 20Hz. Ontwikkelaar Treyarch ging niet specifiek op de tickrate in, maar zei in een reactie wel dat updates die de 'ervaring verbeteren' op het gebied van netwerkprestaties in de maak zijn. Spelers doen hun beklag over de lage tickrate.

Een lagere tickrate betekent dat updates tussen clients en server minder vaak per seconde verstuurd worden. Dit zorgt ervoor dat de partijen een lichtelijk verschillend beeld van een slagveld kunnen hebben; de ene speler is al achter een muurtje gedoken en de andere speler heeft hem toch nog net in het zicht en lost een schot, bijvoorbeeld. De server moet hierin dan een kant kiezen en zal in de ogen van een van de spelers onterecht een miss of een hit communiceren.

Tickrate is vaker een vraagstuk bij multiplayergames. Overwatch draait tegenwoordig op 63Hz maar vroeger was dat ook lager, Destiny 2 draait op 30Hz en Fortnite op 30Hz. Bij PUBG hangt het weer af van hoeveel spelers overblijven, met een maximum van 60Hz.

Nieuwe Wireshark-metingen bij de PS4 - links Blackout (battle royale) en rechts Team Deathmatch

Reacties (77)

[Jerryy]

Heel leuk natuurlijk, maar tickrate zegt nog lang niet alles. Tickrate wilt gewoon zeggen hoeveel packets er per seconde vanaf de server naar de client worden gestuurd en vice versa.

Wat er dan in die packets staat, is echter een raadsel. Dit betekend dus niet altijd dat hogere tickrate = betere hitreg.

[Ayporos]

Het lijkt mij, vanuit een programmeurs standpunt, logisch om enkel gewijzigde data door te sturen naar je clients vanaf je server.. Anders is het een verspilling van resources.

Ja, je hebt gelijk, het blijft een aanname.. maar het is toch wel een redelijk betrouwbare aanname dat (buiten malafide intent/obfuscatie) de tickrate gelijk zou moeten staan aan de world-state update rate.

[Anoniem: 58485]

Ja en wat gebeurd er in een open wereld met 100+ spelers? Constant data & beweging. Zet gewoon fatsoenlijke servers neer en pomp daar een 60hz tickrate voor games zoals Pubg doorheen.

[jaenster]

Denk niet dat het veel te maken heeft met hun kant, maar met de spelende kant.

Al heb je nog zn dikke internet pijp @ de server's kant, de snelheid is altijd de zwakste schakel tussen de client en de server.

[Power2All]

Client's krijgen een stabiele stream.
Het is de server die last heeft, aangezien die naar 100 spelers moet pompen van updates.
PUBG werkt bijvoorbeeld met een Server <-> Client systeem.
Sommige spellen die een Client als Server flaggen, moeten dat kunnen bijbenen, zoals een aantal spellen waar er ineens lag ontstaat omdat iemand een slechte internet connectie heeft. Dat soort zaken wil je niet hebben in een FPS.

[Reactie gewijzigd door Power2All op 23 juli 2024 02:41]

[Martinspire]

Het is niet zeker dat het er beter van wordt, maar het wordt er in ieder geval niet slechter op

[madcow22]

In beta toen het op 60hz stond scheelde het bijna 50% is ms voor hitreg vergeleken met 20hz.

[johnkeates]

In dit geval wel. Het gaat om de world update ticks, dit in dit geval is de tickrate de kwantiteit van state updates per tijdseenheid.

Packets per second staat inderdaad niet gelijk aan ticks per second. Een packet stream (of enkele packet) kan world updates of lokale ticks bevatten, maar ook iets anders.

[FireDrunk]

@Jerryy
Het een sluit het ander wel uit. Bij een lage tickrate kan je nog zo veel info in het pakketje hebben staan, je hebt altijd de transporttijd als afwijking. Hoe hoger het aantal updates hoe hoger de kans dat de afwijking kleiner is.

In absolute zin heb je gelijk, als er onzin in staat, heb je nul hit registration.

[Reactie gewijzigd door FireDrunk op 23 juli 2024 02:41]

[houtig]

Wat ik mij wel afvraag. Ik speel(de) Cod:WW2 en daar had je soms ook hele vreemde hitregistratie. Zal dat ook met de tickrate te maken? Los van dat je soms een slechte host had en dan alles scheel ging.
Niet dat veel uitmaakt want sinds BO uit is zijn de servers van WW2 zo goed als leeg voor mijn gevoel. Is gewoon niet meer leuk spelen. Cod WW2 is ook de laatste Cod die ik gekocht heb. Had vorige versies al overgeslagen maar had ijdele hoop dat deze weer ouderwets leuk was. In begin nog wel maar boy was i wrong...

[RoaDHouse]

Ben ik nu de enige die veel last heeft van lag in deze versie van cod, ik heb een constante fps van 144 maar ik heb het gevoel of ik op een server speel met een ping van 200.

Er is in ieder geval iets goed mis met de pc versie, in de vorige versies heb ik dit nog nooit gehad. Normaal eindig ik altijd in de top 3 maar nu mag ik blij zijn als ik een k/d heb van 0.90.

Als het nu 60 tickrate is merk ik er in ieder geval helemaal niks van.

[RAYDIVER]

Hier het zelfde

[Kevinio]

Hmm ik ervaar hetzelfde. Gelukkig niet de enige zo te zien, maar ben benieuwd wat dan het probleem is.

Edit: en daarnaast wordt ik na nagenoeg iedere game uit de lobby gegooid

[Reactie gewijzigd door Kevinio op 23 juli 2024 02:41]

[NLsandman]

Ik begrijp dat tickrate belangrijk is maar voor mij is het sinds ik glasvezel heb sinds 2014 het ping verschil een groter probleem.
BV in battlefield heb ik vaak de laagste ping, 6 ms en het gemiddelde ligt tussen 40 en 60 ms, als er dan ook nog wat 100+ ms ping spelers mee doen dan maak ik hele rare dingen mee, one shot deaths, spelers die uit een hoek schieten waar daarvoor nog niemand was.
Voorheen met adsl2+ speelde ik bf2 en bf3, die hadden een tickrate van 10 hz en bf3 zat tussen 10 hz en 30 hz en had veel minder problemen dus mijn mening is dat niet alle problemen met een verhoging van tickrate opgelost kunnen worden.

[laue]

De technische kant ken ik ook niet helemaal maar het schijnt dat als je sneller internet hebt je in het nadeel bent. Ik merk het ook op de glasvezel

[Holmindeboks]

ah dat verklaard een hoop.. erg jammer dit. heb vet goed internet maar hitreg zuigt. en anderen killen me zo makkelijk. en maakt niet uit wat ik voor perks neem.

[computerjunky]

Ik speel sinds kort BF1 en die is wel veel beter als iedere COD sinds mw3 zij het dat het voor mij extreem wennen is om een non hardcore game te spelen aangezien ik gewent ben alleen maar hardcore te spelen en dus de overstap naar 3 tot 10 bullets per kill best wel een frustratie is. maar qua hits speelt het lekkerder en je heb tenminste het gevoel dat je een kans maakt.
Dat is als je niet in een sniperfest terecht komt.
Een limiet van 8 snipers van de 32 teamgenoten had wel een plus geweest en eerlijk gezecht geen overbodige luxe aangezien spawnkillen gewoon een optie is in BF1..
Het gras is groener aan de overkant zwker als je vaak gespawnkilled word want dan kan je het van dichtbij bekijken.

[kevz]

Multiplayer games maken tegenwoordig allemaal gebruik van 'Unlagged netcode'. Developers pakken de gemiddelde ping van een speler (zeg maar 60-85ms) en bouwen daar hun netcode omheen. Wat jij merkt merk ik ook en dan hoef ik niet eens 6ms te hebben, je krijgt 't zelfde effect op 15-25ms.

Tickrate is sowieso altijd beter als het hoger is, mensen kunnen wat stotterend overkomen maar dat zit dan puur in de kwaliteit van de lijn (wat dan weer gecompenseerd kan worden door client smoothing ea).

Rainbow 6 Siege heeft tot 2 jaar na launch precies de netcode gehad waar iedereen een hekel aan heeft; Wanneer iemand met 200 ping voordelen haalt icm agressief spelen (peekers advantage) dan werkt die unlagged netcode tot hele hoge pings. Wat meer realistisch is is dat het effect van die netcode verminderd word naar mate de pings hoger worden, maar de meeste games hebben nou eenmaal niet die kwaliteit, waaronder BO4.

Lage ping hebben geeft je gewoon nul peekers advantage, je bent in synch met de server, dat is een nadeel wat komt met die techniek en ik ken maar weinig moderne games die dat eerlijk houden.

[computerjunky]

Precies vroeger (1999 tot 2004) had je nog voordelen bij het hebben van de beste verbinding en snelste hardware nu is het echter omgekeerd en kan je beter je netwerk adapter zo afstellen dat jet je ping verziekt tot rond de 150 MS.
Belachelijk natuurlijk maar het werkt wel degelijk. o kan je klooien met zend en recieve buffers waardoor je lage zend buffers heb je je pakketten sneller verzonden worden maar extra grote recieve buffers waardoor je minder snel de pakketten ontvangt en dat geeft je dan weer een voordeel en zo zijn er nog meer reg tweaks en netwerk tweaks.
Als games het goed op orde zouden hebben zou iedere pc gewoon gelijk zijn op de paar hele slechte systemen na dan.

Ik moet bijna al mijn gameplay hebben van supersnel zijn met de muis aangezien als linkshandige ik geen goede layout kan realiseren waar ik kan sprinten,kruipen, liggen, granaten kan gooien, tools kan gebruiken, healen en ga zo maar door. Games hebben tegenwoordig teveel knoppen om in te drukken en dat is gewoon een drama dus die lui die supersnel liggen staan springen on om hoekjes kijken kan ik zo niet veel tegen beginnen.

[Reactie gewijzigd door computerjunky op 23 juli 2024 02:41]

[Boermansjo]

Ben ik blij dat er nog andere mensen zijn met exact hetzelfde probleem.
Tijdens de beta van battlefield 5 was dit stukken beter. Eindelijk deftige kill-streaks zonder rare dingen.
Met de COD games heb ik hier toch het meeste last van. Vooral omdat de maps kleiner zijn en veel meer gebouwen en hoeken.

[Centropy]

Hopen dat de update snel naar Blackout komt. Ondervind af en toe wel last van deze lage "tickrate" op de Ps4-pro

[Martinspire]

Mja al denk ik niet dat je af komt van het lag-voordeel wat sommigen lijken te hebben als ze spelen op het Wifi van de overburen

[Vlizzjeffrey]

Dat zijn ze niet van plan, dat kost ze teveel geld

[Armada651]

Fortnite op 20Hz

Fortnite draait sinds 4.2 op 30Hz en niet op 20Hz zoals in dit artikel genoemd wordt.

Bron

[Reactie gewijzigd door Armada651 op 23 juli 2024 02:41]

[Anoniem: 334725]

Fortnite heeft een gemeten tickrate van over de 60. Hoe ze dat doen met 30 pakketjes per seconde is waarschijnlijk een leuke algoritme maar het is een van de beste performante servers die er zijn momenteel.

[Reactie gewijzigd door Anoniem: 334725 op 23 juli 2024 02:41]

[t link]

Hoe kan je een tickrate van over de 60 hebben als je niet meer dan 60 updates per seconden krijgt? Dat klinkt voor mij onmogelijk.

[mikesmit]

Dat klinkt onmogelijk omdat het dat ook is

[SuperDre]

Nee hoor, als de netcode met prediction goed genoeg is, is dat perfect mogelijk.

[graey]

Dan is het alleen geen tickrate meer, want er wordt server-side geinterpoleerd, en die interpolatie is niet noodzakelijkerwijs 100% accuraat. Een goeie oplossing voor het oplossen van conflicten tussen clientdata, maar geen hogere resolutie van daadwerkelijke harde data.

[SuperDre]

Maar het gaat ook niet of het om de tickrate gaat, het gaat om percievable tickrate.. Om maar met het seizoen te praten, de gevoelstemperatuur, ondanks dat het mogelijk werkelijk 5 graden is, voelt het alsof het vriest...

[graey]

T link zijn reactie gaat over een gemeten 'tick rate'. Dat gaat gewoon over data per seconde, data'ticks' per seconde. Perceptie staat daarbuiten.

[mikesmit]

Prediction betekent enkel dat de server data aan het gokken is. Dit verhoogt de tick rate niet, enkel de foutmarge word versoepelt. Dus de tickrate kan dan net zo goed laag zijn

[SuperDre]

En daar gaat het dus om, het voelt aan als een tickrate van 60 omdat de prediction dus goed is.

[mikesmit]

Prediction blijft gokken. De server kan net zo goed een hitregistratie missen omdat hij dit verkeerd gegokt heeft. Daarom zijn echte ticks beter dan voorspelde ticks en is dit een net zo grote marketing illusie als de 1000Hz lcd tv die in de mediamarkt staat

[mjz2cool]

Dat is in theorie wel zo, maar als die prediction zo goed werkt dat het als een tickrate van 60 aanvoelt, dan maakt het niet veel uit of het realtime of voorspelde ticks zijn.

[t link]

Ja dat hele sterke vermoede had ik wel al maar ik weet niet genoeg over dit soort dingen om iets te labelen als bullshit, ookal rook het er wel naar.

[mikesmit]

Ik zal niet pretenderen dat ik een kenner ben maar als jij zegt dat jij elke minuut informatie over 2 dingen krijgt dan krijg je niet ineens magisch elke 30 seconden informatie over 1 ding

[johnkeates]

Door bijvoorbeeld twee ticks in een packet te stoppen. Een tick is niet een zelfstandig packet.

[DataBass]

Jij hebt het niet begrepen als je dit als een oplossing ziet...

[johnkeates]

Jij hebt het niet goed gelezen als jij denkt dat ik het een goede oplossing vind.

Er zijn mensen die stellen dat je niet meer ticks dan packets kan hebben, maar dat kan prima. Of dat handig is of niet is een ander verhaal, maar het kan prima.

Wat dan wel weer een praktische implementatie zou kunnen zijn is een UDP stream gebruiken, en dan bijv. 3 ticks per packet gebruiken en ze constant door laten rollen.

Dus bijv:

packet[0][0] = tick a
packet[0][1] = tick b
packet[0][2] = tick c

packet[1][0] = tick b
packet[1][1] = tick c
packet[1][2] = tick d

packet[2][0] = tick c
packet[2][1] = tick d
packet[2][2] = tick e

Dan kan je dus 3 ticks per packet verwerken. Als je dan 60pps doet kan je in feite 180 ticks per seconde halen, heb je geen round-trips nodig en kan je zelfs met 2 van de drie corrupte packets je hele state achterhalen.

Als je dit reduceert naar een theorie van 60Hz, dus 60tps, dan kan je als je elke 1s 2 ticks doet heb je met 30Hz aan packets 60Hz aan tickdata. Als je origineel al elke tick twee keer verstuurde ter controle heb je eigenlijk niet zo veel verlies qua tickspeed. Ik zou dan zelf eerder gaan voor een stream waarbij elke tick drie keer binnen komt, of elke even of oneven tick hetzelfde resultaat als z'n voorganger kan bieden maar dan met differentiële data zodat je niet hoeft te interpoleren. Zolang de tijdspanne van een tick kleiner is dan je roundtrip (dus je ping) en dus twee of drie keer in je ping past maakt het qua lag, hit/miss enz niks uit.

Nu is dit een schets waarbij een tick misschien wel te groot is voor een packet, of dat een tick uit meerdere packets gaat, maar we gebruiken hier de analogie van een tick als zelfstandige unit voor het gemak. Stel dat een tick meerdere packets is, dan kan je dit gewoon vermenigvuldigen.

[Reactie gewijzigd door johnkeates op 23 juli 2024 02:41]

[mikesmit]

Als je 3 ticks per packet verwerkt is je effectieve tickrate 1/3 van wat je opgeeft.
De hoeveelheid ticks per pakket bepalen de verlaging van de tickrate, niet de werkelijke tickrate

[johnkeates]

Nee, de rate (of dat nou over ticks of wat anders gaat) betekent hoevel units je per tijdseenheid krijgt.

Dus hoeveel ticks je per seconde hebt is een kwestie van tellen. van 0ms tot 1000ms tellen en dan kijken hoeveel ticks je gezien hebt (dat is ook hoe je dat met wireshark doet). Maar dat is dan ook weer onderhevig aan de manier waarop je ticks verwerkt worden. Stel dat je by default de helft van alle ticks weggooit, of voor elke tick een verificatie doet om dat je TCP gebruikt, dan kan je wel een hoge tickrate hebben maar dan weet je nog niet hoe veel ticks er daadwerkelijk relevant waren.

Natuurlijk kan je er in dit soort conversaties van uit gaan dat een tick gelijk staat aan een world update of input feed update (als je bijv. je synchronisatie op basis van een input stream + world updates per X aantal inputs doet om eventuele gemiste ticks van je normale stream glad te strijken).

Een tick is in een real world situatie natuurlijk niet slechts een packet, daar is een tick veel te groot voor. Dus als je een pcap pakt ga je eerst een tick reconstrueren van begin tot eind en daarna de hele tick optellen per seconde om aan je Hertz te komen. Dat iets een X aantal Hz is betekent natuurlijk nog niet dat ze allemaal precies even groot zijn of even lang duren. Stel dat een kleine tick uit 3 packets bestaat en 3ms duurt, en en grote tick uit 10 packets bestaat en 12ms duurt, dan kan je wel een Hz uitrekenen, maar de vraag is dan of dat wel rekening houdt met de distributie van de ticks over tijd.

In het geval van dit artikel is dat niet heel duidelijk of misschien niet eens zo relevant, om dat de console gamer generatie zo breed is dat er te weinig mensen met low-level kennis gebruik van maken om de relevantie of details te zien. Dat is niet perse verkeerd (dat is iets wat nou eenmaal gebeurt als een product brede commercie trekt), maar voor een simplistische vergelijking van meer vs.minder ticks verlies je wel een boel informatie die toch wel belangrijk is.

Aan het eind van de rit kan je wel stellen dat het belangrijk is om tijdig informatie van de status van de speelwereld te hebben zodat een hit een hit is en een miss een miss is. En als meer ticks (of dat er nou meer per transfer of meer per tijd of meer per bytes-on-the-wire zijn) in de server en client implementatie dat voor elkaar krijgt zit je goed. Nadeel is wel dat met zo'n simplistische benadering de marketing afdeling er in no-time op springt en je bij de eerstvolgende release een "100Hz tickrate!!!1!!1oneone" banner kan verwachten, die dan feitelijk klopt maar realistisch niks waard is.

[freaq]

Je kan geen pakket over de toekomstige situatie versturen.
Een tickrate van 2 states per packet betekent dus dat je altijd alsnog 1 of 2 states achter loopt, in plaats van 1 state continue.

[johnkeates]

Niet perse, stel dat een update (een set packets) bijvoorbeeld 2 ticks bevat, en de eerste tick bevat voor de speler een update 'je stapt in de auto' en daarna een update 'je zit nu in de auto'. Die worden sequentieel doorgevoerd. Als je in-game kijkt zie je jezelf instappen en daarna in de auto zitten, in plaats van dat je eerst naast de auto staat en er dan op eens in teleporteert.

Stel dat je een rate in Hertz uit wil drukken, dan krijg je dus een eenheid per seconde, en stel dat de meeste updates in ticks zitten aan het eind van die seconde (bijv. rond de 900ms) dan krijg je dus eerst 900ms helemaal niks, en daarna opeens allemaal ticks.

[freaq]

Ja behalve dat,
Om tick 2
In hetzelfde pakket als tick 1
Te versturen,
Je tick 1 dus nog niet verstuurd kan hebben.

En daar zit de crux....
Dat betekent dat je dus 1 tick achterloopt, en dus moet de client voorspellen wat er gebeurt, en ziet persoon a je naast de auto staan terwijl je “al ingestapt was”

Kortom nee je kan niet zomaar 2 ticks in 1 pakket versturen, dat is niet hetzelfde als 2 ticks.

Dat is gewoon 1 grotere tick.

[johnkeates]

Een tick is niet hetzelfde als een packet. En een tick komt niet bij de client aan op het moment dat het vanaf de server verstuurd is. als je om 0010ms een tick maakt, en om 0020ms nog een tick, en dan tegen een socket zegt, rag die ticks even naar client 1.2.3.4:35432 dan is er totaal geen garantie dat die ticks op volgorde na elkaar aankomen. Bovendien maakt het niet uit, want je ticks worden client-side verwerkt in een queue en gesorteerd op order of timecode.

Dus als de game elke 100ms een state refresh doet en in die 100ms bijvoorbeeld tick 3 als eerste binnen komt, dan tick 1 en dan tick 2, dan kan in die 100ms prima gewacht worden en daarna de ticks in-order als world update of input stream gebruikt worden.

tick 1 en tick 2 (en tick 3) kunnen prima tegelijkertijd bestaan, want een tick die al gebeurd is hoeft niet dezelfde ms verwerkt te zijn.

[freaq]

Sure prima, maar het betekent we dat je dus een enorme toename in lag hebt.

En dus is een lagere “packet rate” even erg als een lage “tick” rate.

[robvanwijk]

Wat dan wel weer een praktische implementatie zou kunnen zijn is een UDP stream gebruiken, en dan bijv. 3 ticks per packet gebruiken en ze constant door laten rollen.

Dus bijv:

packet[0][0] = tick a
packet[0][1] = tick b
packet[0][2] = tick c

packet[1][0] = tick b
packet[1][1] = tick c
packet[1][2] = tick d

packet[2][0] = tick c
packet[2][1] = tick d
packet[2][2] = tick e

Dan kan je dus 3 ticks per packet verwerken. Als je dan 60pps doet kan je in feite 180 ticks per seconde halen, heb je geen round-trips nodig en kan je zelfs met 2 van de drie corrupte packets je hele state achterhalen.

Als je op 60 packets/sec en 3 ticks/packet werkt, dan heb je nog steeds 60 ticks/sec... je stuurt namelijk elke tick drie keer (kijk in je eigen voorbeeld maar naar "tick c"). Als ik in elk packet de data van dezelfde tick drie keer verstuur, dan gaat de tick rate toch ook niet omhoog? Waarom dan wel als je de data in drie verschillende packets stopt?

Als je dit reduceert naar een theorie van 60Hz, dus 60tps, dan kan je als je elke 1s 2 ticks doet heb je met 30Hz aan packets 60Hz aan tickdata. Als je origineel al elke tick twee keer verstuurde ter controle heb je eigenlijk niet zo veel verlies qua tickspeed.

Dit hele verhaal heeft niet te maken met een hogere tick rate, wat je hier uitlegt is error-correctie (of, om preciezer te zijn, packet loss compenseren).

En om heel in het algemeen uit te leggen waarom jouw theorie niet kan werken: het gaat niet over het aantal updates, het gaat over het aantal momenten waarop updates verwerkt worden. Dus als je op 30 packets/sec werkt en in elk packet de data van 2 ticks verstuurd, dan krijgt de server nog steeds maar 30 keer per seconde een update van wat er op de client gebeurt. Volgens jouw theorie zou een spel dat elke keer een seconde lang alle ticks opspaart en vervolgens de data van 60 ticks in één keer doorstuurt hetzelfde moeten werken als een spel dat 60 keer per seconde de data van 1 tick naar de server stuurt. Het lijkt me duidelijk dat dat onmogelijk het geval kan zijn. Maar als het met een factor 60 niet werkt, dan natuurlijk ook niet als je het met een factor 2 of 3 doet (zoals in jouw voorbeelden).

[johnkeates]

Ik stel niet dat alle games altijd alles opslaan, bufferen o.i.d. maar dat onze meting van X ticks per seconde niet spannend is om dat binnen die seconde zeeen van tijd zijn om ticks te verwerken. Wij zien misschien X ticks per seconde, maar de client en server zien X ticks per miliseconde.

De manier waarop ik het omschrijf is ruwweg hoe idTech3 (Quake 3 engine) en de source engine het doen, en het werkt prima:

https://developer.valveso...ce_Multiplayer_Networking

http://fabiensanglard.net/quake3/network.php
+
https://github.com/id-Sof...I-Arena/blob/master/code/

[Reactie gewijzigd door johnkeates op 23 juli 2024 02:41]

[encryped]

Hier hebben ze iig geen tickrate van 60hz gemeten.
https://www.youtube.com/watch?v=u0dWDFDUF8s

[Mark_88]

Zelfde bron, maar een oudere video. Het lijkt er m.i. op dat het dan idd toch 30Hz is.

[Armada651]

Die video die jij linkt gaat over 4.1 en is een maand ouder dan degene die ik als bron vermeld heb.

[Reactie gewijzigd door Armada651 op 23 juli 2024 02:41]

[rickboy333]

Mooi. Nu is het spel dus weer speelbaar. Gelukkig maar. Tja jammer van Blackout, maar daar ga je me dus ook niet zien. Echter is bij Blackout nooit 60 hrz beloofd terwijl bij de multiplayer dat wel is beloofd. Zo zie je maar wat een krachtige community kan doen.

[fre0n]

hebben ze 60hz beloofd ? imho is voor de hele cod lijn altijd de slogan geweest 60fps stabiel op alle platformen. niet de 60hz tickrates...

[computerjunky]

Dit is precies waarom ik bijna geen shooters meer speel online. Je kan de pc hebben die het meest vloeiend speeld en de beste internet verbinding maar onder de streep ben je vaak gewoon benadeeld tegenover andere spelers doot allerlij rare compensaties en belabberde tick rates.

In een ideale wereld is he tick rare gewoon even hoog of hoger als je fps. En is er geen lag compensatie. Pas dan krijg je een echt accuraat gevoel.

[Reactie gewijzigd door computerjunky op 23 juli 2024 02:41]

[Anoniem: 368306]

Uiteindelijk winnen de betere toch wel.

[computerjunky]

Nou ja als je ziet hoe vaak ik schiet en er gewoon geen hit registratie is gan ke nog zo snel mikken en klikken maar als de server je 'negeert' gat de beste of snelste nooit winnen.
En ik heb vaak zat gehad dat ik al 3 meter voorbij een muur was en toch nog even dood neer viel. Gewoon onspeelbaar.

[Anoniem: 368306]

Was te kort door de bocht, maar zie me reactie onder die van Natrox hieronder.

[Anoniem: 761361]

Ja, maar het verschil tussen goed en beter wordt ietswat vager als de "server" (p2p of dedicated) slechts 20 keer per seconde gaat kijken naar de situatie. Het is goed genoeg voor de meeste spelers, maar de echte goede mensen hebben er alleen maar nadeel mee omdat hun snelle reactievermogen simpelweg niet geregistreerd wordt op dezelfde snelheid. E.g. Je reactie snelheid gaat gecapped zijn op 50ms, ongeacht persoonlijke framerate en input polling.

[Anoniem: 368306]

Ik was ook veels te kort door de bocht, doelde meer dat als je een spelletje speelt waar je lekker kan respawnen dat je toch als hoogste zal eindigen als je kwaliteiten eenmaal het beste zijn over het algemeen.
In een spel als PUBG zal het een andere wending krijgen:(

[Sissors]

Dat is het hele probleem van de obsessie met tick rate bij sommige groepen. Ja, tick rate is relevant. Maar het is maar een klein gedeelte van hoe de online ervaring aanvoelt. Een tick rate van 20 is zeker niet laag genoeg om een 'laggy as hell' ervaring te krijgen.

[Mr Pingu]

Om jouw standpunt "tickrate bepaald niet alles" kracht bij te zetten kan ik volgende video erg aanraden: https://youtu.be/u0dWDFDUF8s

[rickboy333]

Omdat CoD een competitief spel is, een E-sport titel zelfs. In een (E) sport titel wil je zo weinig mogelijk factoren hebben op de cliënt die je negatief kan beïnvloeden in het spel. Als jij achter een muurtje staat dan hoor je niet meer dood te gaan, maar bij 20 tickrate ga je wel dood.

Ik weet nog goed in de Overwatch beta hadden ze ook een tickrate van 20. Als je als Genji een Reaper duelt en je wil deflecten dan ging je alsnog dood terwijl de deflect animatie op jouw computer gewoon zichtbaar is.

60 is echt een minimum om goed competitief te spelen naar mijn mening. 120 is zelfs nog beter.

[Sissors]

Ja, die 20 tickrate kan net het verschil maken. Maar we hebben het nog steeds over minieme verschillen tussen 20 tickrate en 60 tickrate met in hoeverre jouw voorbeeld kan gebeuren. En het is onmogelijk dat jij ruimschoots achter een muur staat en dan nog dood wordt geschoten door de 20 tickrate. Als dat gebeurd dan zijn er hele andere problemen.

En dat is mijn probleem dan ook met die obsessie over tick rate. Mensen klagen nog dat de BF 60 tickrate te laag is, en dat het minimaal 120 moet zijn. Terwijl 60 zat is, en veel snellere spellen met veel lagere tickrate prima spelen. Maar goed, doordat dus alleen naar die tickrate wordt gekeken, worden daadwerkelijke problemen met de netcode compleet genegeerd, danwel 'opgelost' door maar een hogere tickrate ertegenaan te gooien.

[rickboy333]

Het punt is alleen dat de netcode in CoD multiplayer gewoon in orde is. Toe de beta op een tickrate van 60 draaide had ik nergens problemen mee, maar toen hij naar 20 ging wel. Een paar keer maakte ik headshots die niet gedetecteerd was. Dat dit maar een stuk of 3 keer is gebeurd maakt verder niet uit. In een competitieve game wil je alles zo eerlijk mogelijk maken.

In Blackout is zowel de netcode als de tickrate een grote ramp. En r/Blackops 4 staat er vol mee.

[watercoolertje]

Als iedereen dezelfde tickrate heeft is dat toch eerlijk, niet perse leuk natuurlijk, maar wat jou kan overkomen (headshot niet geregistreert of dood gaan terwijl je al dekking hebt) kan de tegenstander ook overkomen

[True]

Eigenlijk niet, door de lage tickrate hebben spelers met een hogere ping meer profijt. Zeker door de clientside prediction die het spel bevat.

[Holmindeboks]

ja ik vind het nog steeds debiel hoe het speelt, ene potje schiet je met een gun iemand snel neer, en ga je andere server en schiet je even veel kogels raak en er gebeurd niks. en ik weet niet hoe mensen die golden camo zo snel hebben maar ik doe mn uiterste best om die headshots te maken en met of zonder high kaliber het maakt geen verschil. ook al aim ik en schiet ik op de kop hij teld em niet als headshot.
het lijkt alsof de helft van wat ik hit niet eens aankomt. mijn verbinding is 50 down en 50 up en glasvezel.
heb alle graphics als low gezet in de hoop dat dat iets uitmaakt maar dat zou niet moeten met een 1070ti
en 6700k.

en die killcam klopt ook niks van. soms zijn mensen zo snel dood en zelf kost et me een paar seconde van raken. soms best frustrerend hoe easy mensen me killen en als ik eerder op ze schiet en ik dood ga
mja iig beter dan battlefield 1. mja zal wel bepaalde manier van spelen zijn in cod want tempo ligt veel hoger maar dit is wel wat ik leuk vind

[Wim-Bart]

Je hebt gedeeltelijk gelijk net zoals @rickboy333 gedeeltelijk gelijk heeft. Tickrate is heel belangrijk, maar we in combinatie met sending en receiving van client info. Wanneer ik met bijvoorbeeld Netlimiter de send van mijn client op half tickrate zet en ik schiet op de persoon die achter de muur sprint, dan is de kans dat mijn client een hit registreert 50% groter.Reden? Lag compernsation.

[speedhaste]

Probleem bij COD 4 met de tickrate is dat het erg in het voordeel van de person werkt die lag heeft.
Hierdoor kan het regelmatig voorkomen dat mensen die beschoten worden terwijl ze buiten bereik zijn alsnog geraakt worden door de person die lag heeft.
Mooi stukje uitleg ook op battlenonsense op YouTube: https://www.youtube.com/watch?v=1T2ohLYKlkg
en ook nog een mooie vergelijking op https://www.youtube.com/watch?v=V9kzQ9xklyQ

[Tijmenn]

De tests zijn uitgevoerd door gebruiker soja92 van /r/Blackops4, die melding maakt van de upgrade bij zowel de Windows-versie als de PS4-versie

Eerste zin van het artikel.

[kevz]

De tickrate is één onderdeel van het probleem. Ja, 60hz is de absolute minimum waar je FPS games op wil spelen, maar de vertraging in de engine of server zelf heeft ook zo'n ~100ms waardoor je zelfs met 0 ping die vertraagde effecten zal zien. Wellicht verbeteren ze dat als volgende stap, en pas dan zal de game echt reactief aanvoelen.

[Jack Flushell]

Op de pc waarschijnlijk niet,,, het is nog steeds laggy als hell.

Lag en tickrate hebben heel weinig met elkaar te maken. Geroeptoeter.

[Reactie gewijzigd door Jack Flushell op 23 juli 2024 02:41]

[RoaDHouse]

Ja, daar ben ik nu ook achter... het hele gelul over tickrate is dus allemaal zwaar overdreven. Dat neemt niet weg dat ik met een hi-end pc zit waar de bo4 game niet normaal op kan draaien zonder vreselijke lag.

De game is van de grond af opgebouwd voor de pc beweren ze van Treyarch pffffff.... wat een stelletje prutsers.

[fre0n]

hier loopt ie prima stabiel, >120FPS alles op max, op een i5/20gb en een gtx1080/8gb