Battle royale-modus CoD: Black Ops 4 heeft frameratelimiet van 120fps bij launch

Ontwikkelaar Treyarch geeft de Blackout-modus van Call of Duty: Black Ops 4 op de pc een frameratelimiet van 120fps als het spel uitkomt. Tijdens de bèta was dat 90fps. Later wordt de limiet verhoogd naar 144fps en uiteindelijk moet de limiet verdwijnen.

Call of Duty: Black Ops 4 komt uit op 12 oktober en Treyarch geeft op Reddit details over de pc-versie. Tijdens de bèta had de Blackout-modus van een frameratelimiet van 90fps, naar eigen zeggen om de prestaties en stabiliteit van de servers in de gaten te houden.

De framerate heeft volgens de ontwikkelaar invloed op de belasting van de servers en ook als het spel definitief uitkomt, zal er nog een limiet zijn. Aanvankelijk is dat 120fps en 'zodra de servers stabiel zijn', wordt dat 144fps, zegt Treyarch.

Als alles probleemloos verloopt, verwacht de ontwikkelaar dat binnen enkele dagen alle limieten weg kunnen worden gehaald. De reguliere multiplayermodus en de zombiemodus hebben geen frameratelimiet.

Reacties (92)

[Scrtz]

Ik snap dit nooit zo, want de server heeft toch een bepaalde tickrate, wat heeft dat dan te maken met jou lokale FPS? Als de server dan bijvoorbeeld 100 tick is en jij hebt 1000fps, wat heeft dat dan voor invloed op de performance van de server?

[mikesmit]

Je beantwoord je eigen vraag. Blijkbaar zijn de tickrate en fps van de server en spelers nog niet onafhankelijk van elkaar

[Magic]

Ik voel me net een peuter, maar de vraag moet dan zijn: "Waarom dan?". Dit zijn 2 processen die prima parallel zouden kunnen lopen.

Daarnaast is de tickrate ook zelden gelijk aan de framerate (gelukkig maar). Ik zag zelfs geruchten langskomen dat de beta op een tickrate van slechts 10hz zou draaien. Misschien dat ze ergens in de interpolatie daarvan iets aan de framerate koppelen, maar kan met niet voorstellen dat dat een handige keuze zou zijn.

[HarryProtter]

Volgens Battle(non)Sense was de tick rate bij de start van een game 20Hz, waarna het zo'n 10Hz werd zodra de eerste spelers op de grond landden. Zodra iets minder dan de helft van de spelers dood waren, werd het weer zo'n 20Hz. Dus niet gedurende de hele game 10Hz, maar een tick rate van 20Hz is natuurlijk nog steeds een slechte zaak.

[thescorpi0n]

Dat is alsog wel echt heel laag. Bij CS:GO klagen mensen al dat de servers 'maar' op 64-tick draaien.

[Gamebuster]

CSGO heb je geen 100 man in de server

[djunicron]

Behalve dat Source prima 128tick rate kan draaien voor 64 spelers tegelijk.

UT, jawel, de eerste Unreal Tournament had serverside detection met een tickrate van 100. Dat ging prima over dail up en vergelijkbare verbindingen.

Moderne games en dan met name van de CoD en BF studio's, lopen hier al jaren in te snijden. En waarom toch de afgelopen 3 CoD games FPS limieten hadden... IW had ik een jaartje na release gekocht voor een prikkie, blijkt dat je eigenlijk gewoon weer een opgepoetste engine uit 2007 hebt draaien.

Ze hebben er toen bewust voor gekozen om de tickrate laag te houden en p2p networking te gebruiken. Hierdoor zijn spelers zo nu en dan zelf als host in het voordeel. Een killstreak halen voelt aldus de Devs des te lekker als je rondes daarvoor slecht hebt gepresteerd (lees; hebt kunnen presteren). Ze WILLEN juist skill compressie om zo mensen bij zich te houden. Zodat een goed potje als een "endorfine high" aanvoelt en je blijft spelen tot je dat weer haalt.

De MP gameplay is naar mijn mening sinds 5-6j terug simpelweg bedroevend in CoD games.

Ik wacht wel weer af totdat ze een serieuse MP shooter maken met 250 tickrate en geen belachelijke hardware limitatie, zodat competetive play zonder lootbox rotzooi mogelijk wordt. Tot die tijd maar R6 Siege zo nu en dan opstarten vrees ik.

[voxl_]

Volgens mij is de max van Source servers 64 man (dat is iig de grootste server die ik gezien heb) maar die had daar geen probleem mee...

[Loggedinasroot]

Dit gaat vooral om 1 fysieke server die zoveel mogelijk servers moet draaien. Je kan natuurlijk wel bijvoorbeeld de csgo matchmaking servers op 128 tick laten draaien, maar dat betekend dat je per fysieke server minder csgo servers kan draaien.

[MSalters]

Waarom zou je de matchmaking uberhaupt op 128 ticks/second laten draaien? 5 is genoeg voor matchmaking; 200 milliseconden wachten op matchmaking is praktisch niet merkbaar. 200 milliseconde in game is een eeuwigheid, maar dat is hele andere netcode met andere servers.

[Loggedinasroot]

Ik bedoel de ingame servers als je een matchmaking game speelt?

[andorjensma]

"Matchmaking" = Competitive game, in CSGO. Hij bedoelt niet matchmaking als proces. Miscommunicatie

[voxl_]

Daar zit wat in. Ik denk wel dat de netwerkcode van de nieuwe CoD beter had kunnen zijn, tenzij ze dit doen vanwege eventuele trage verbindingen?

[J8S]

En in CS:GO is the time to kill wel heel laag, dus daar ga je lage tickrates ook veel sneller merken.

[BarnET]

call of duty heb je ook een lage time to kill. Daarnaast heb je met battle royaal geen respawns.
Dit gaat echt vervelend worden aangezien 10hz tickrate voor de eerste 30 gesneuvelden het praktisch een loterij maakt.

[DonnyL]

Jij hebt duidelijk beide beta's niet gespeeld. In de normale MP heeft iedereen nu 150HP ipv 100 vanwege het manuele healing systeem. In Battle Royal was dit nog veel erger aangezien er ook nog eens 3 levels aan armor zijn. Een kill in BR kon je zomaar een vol magazijn kosten (zonder te missen).

[BarnET]

dan nog als je een tickrate heb van 10 hz heb ik er ook nooit en te nimmer zin in het aan te raken.
Als de server elke 100 ms een update stuurt terwijl je eigen scherm elke 16ms ververst (in de meeste gevallen 60fps) dan snap jij ook wel dat er grote verschillen gaan zitten tussen wat ik dan zie op het scherm en wat de andere speler ziet op zijn scherm.

En dat leid automatisch tot veel BS deaths.

kogels die niet registreren.

Spelers die op afstand rubberbanden.

Oftewel wat we in Battlefield 4 zagen in de begin periode.
veel plezier laat maar zitten.

[DonnyL]

Helemaal correct, ben ook zeker wel wat gekke dingen tegengekomen tijdens de BR beta. Als je al achter een steen zit bijvoorbeeld, maar dat de enemy je nog steeds neerknalt. PUBG en Fortnite zijn ook met soortgelijk dramatische servers begonnen en hebben het opgebouwd. Hoop dat CoD dat ook gaat doen, maar je weet het nooit met ze. TTK blijft hoog dus dat geeft toch iets meer speelruimte.

[sjettepetJR.]

10Hz? dat is echt heel laag. vraag me af hoe dat speelt. Battlefield heeft ondertussen de meeste servers al op 60Hz draaien. Activision bespaard nu al jaren zoveel mogelijk op Call of Duty, want de verkoopcijfers blijven toch wel hetzelfde.

[Kinghassan]

https://www.youtube.com/watch?v=1T2ohLYKlkg

korte en duidelijke uitleg

[Reactie gewijzigd door Kinghassan op 24 juli 2024 14:32]

[Wotuu]

Dit verklaart waarom de tickrate 10-20hz is, maar niet de relatie met client FPS. Bij meer FPS worden je acties sneller geregistreerd, dat zeker, maar verklaart nog niet waarom je client side FPS moet limiteren omdat een server het niet bij kan houden.

[tinustate]

Servers kunnen het over het algemeen prima bij houden.
De internet verbinding van de speler is hier het probleem.

[PizZa_CalZone]

Er zijn zelfs games waar de gameplay logic gekoppeld is aan de FPS. Dat is leuk als je niet genoeg frames haalt, dan vertraagd de game met de frames mee. Deze games zijn dan ook vaak gelocked op 30 FPS. Unlock je die framerate dan gaat de game vele male sneller draaien dan bedoeld tot het onspeelbare aan toe.

Vergelijkbare effecten ga je krijgen als je framerate aan tickrate koppelt. Clients gaan dan mogelijk out of sync lopen met de server of ze moeten frames gaan skippen oid om weer in sync te komen. Ik kan me dan ook niet voorstellen dat een grote studio kiest voor een oplossing als deze.

Wat zou een goede reden kunnen zijn dat hiervoor gekozen is? Maak je het jezelf niet alleen maar moeilijker?

In het bericht wordt overigens niet gesproken over een koppeling met de tickrate, hoewel dit een logische gedachtengang is, hoeft dit niet de reden te zijn.

[Gropah]

Dit is een hele goede vraag. Als het goed is zijn de lokale FPS niet gekoppeld aan de server ticks, maar er zijn spellen die per frame een datapacket van de server willen hebben omdat dat makkelijker te implementeren is. Je zou kunnen zeggen dat het zinloos is om een nieuw frame te tekenen als er niets nieuws is om te tekenen en dat het misschien zelfs irritant is omdat er allemaal correctie's achteraf plaats moeten vinden.

[watercoolertje]

Denk niet dat je ewn frame niet wilt tekenen zondere nieuwe externe data, je eigen personage beweegt namelijk ook.

Wel hoef je de data van extern niet te herberekenen als je dat al eens gedaan hebt en er niks veranderd is.

[Niet Henk]

Het is vrij gebruikelijk dat de client alle nodige data heeft om, bij het bewegen van je personage en dus viewport, gewoon een nieuw frame te genereren, zonder input van de server. Je kan dus een vijand zien die je eerder niet zag op een nieuw frame door je viewport te bewegen, zonder server input.

Het probleem van een lage tickrate is met name dat als dit aanmerkelijk lager dan de framerate is, andere spelers merkbaar haperig bewegen (omdat hun positie elke server tick en niet elk frame ge-update wordt). Alles wat niet beïnvloed is door andere spelers zou in principe vloeiend moeten kunnen zijn.

Een oplossing voor haperen is extrapoleren (spelers blijven doen wat ze op dat moment doen, dus kunnen vloeiend van punt A naar B rennen zonder haperingen). Dan krijg je conflicten als ze iets onvoorspelbaars doen en conflict resolution, wat je liever niet hebt, maar mogelijk beter is dan een speler die elke 10 frames verspringt en de rest van de frames stil staat (100FPS met 10Hz tick rate)

Je krijgt sowieso al enige conflicten bij niet-verenigbare acties: bijvoorbeeld jij stapt in een tank maar iemand anders deed dat al eerder en je plek is al bezet.

[Boermansjo]

Zou dit een van de redenen zijn dat ik soms (in bf1 bv) dood ga via headshot terwijl ik zeker op dat moment nog achter een muur was (op mijn scherm dus). Bij sommige games waar je een killcam hebt valt het ook op dat ik meer zichtbaar was dan ik dacht. (Ik speel ook nog op een 59.9Hz scherm)
(Vrienden zeggen meestal dat ik gewoon te traag ben... Vind ik toch vreemd omdat ik tafeltennis doe als hobby en daar heb ik geen probleem om in een fractie van een seconde een deftige smash te blokken)

[LytsePier98]

Ja dat klopt inderdaad. Omdat de extrapolatie op een ander z’n scherm er voor zorgt dat jij nog zichtbaar bent en de hitreg zich op de shooter z’n pc initialiseert wordt jij gekilled.

[Boermansjo]

Dus iemand met een hoger Hz scherm heeft voordeel... Lang de ene kant leuk om de weten en juist niet.
Ik ga dus best ook een 144Hz scherm aanschaffen om dit probleem op te lossen.
Wel knap dat ze die tickrate al een stuk hoger kunnen krijgen dan bij de vroegere medal of honors

[Loggedinasroot]

Bij games als PubG werd er ook gebruik gemaakt van client side hit registratie. Dit betekent dat je je internet kabel eruit kon trekken. Iemand neer kon knallen en weer reconnecten en je de kill kreeg omdat je de andere persoon had gekilled volgens jouw client.

[BLACKfm]

Pff, hoe vaak ik wel niet zit te vloeken dat ik dood ga terwijl ik voor mijn gevoel al een seconden achter een object verscholen ben. In een killcam ben ik dan nog volledig in beeld.

Bij de moderne 'medal of honor' (die van voor 'warfighter') had ik hier echt mieters veel last van. Maar bij COD games had ik er ook last van. Kan natuurlijk ook gewoon aan lag hebben gelegen, maar ik houd het maar op het 'probleem' zoals jij het omschrijft. Aan mijn skills kan het niet gelegen hebben .

[Boermansjo]

Hehe, ik ga niet zeggen dat mijn skills hoog niveau zijn. Verre van, maar soms is dat gevoel toch te groot.
Een keer hebben we elkaars scherm opgenomen. Het resultaat was nogal verschillend. Ik zag de tegenstander veel later (1 seconde in fps is al veel ) Op het filmpje zag je ook mooi hoe ik achter het object zat, maar blijkbaar was dat maar voor de helft...
Of kan je dit al oplossen door gewoon continu van links naar rechts te waggelen ? (Zo telkens super kort) Dan moet de server meer werken om je positie up to date te houden

[PizZa_CalZone]

Dit helpt meestal niet, de meeste multiplayergames werken met een tickrate die eens in de zoveel tijd een update doet naar de server. Extra input genereren zorgt dan meestal niet voor een hogere tickrate met de server. Aan de hand van reacties op dit bericht lijkt het erop dat in de beta de tickrate slechts 10HZ is. Ofwel 10x per seconde wordt er een update van je client naar de server gestuurd. Dat betekent dus dat je 10x per seconde heen en weer kan bewegen. Voor twitchy shooters zoals COD/CS:GO/Quake/Overwatch etc is dit erg weinig. Tickrates van 60hz zijn vaak gewenst en is tegenwoordig misschien zelfs al de norm.

Daarnaast kan ik me voorstellen dat een update sturen van de client naar de server een verwerkingstijd met zich meebrengt. Het duurt immers eventjes voordat een packet bij de server is aangekomen, waar hij eerst geprocessed moet worden om vervolgens weer informatie terug te kunnen sturen naar de client. Dan kan je een tickrate van 1 briljoen hebben, maar toch vertragingen of rubberbanding ervaren. Veel van deze zaken worden opgelost door client- en server-side prediction/interpolation die ook niet altijd vlekkenloos werkt.

[Reactie gewijzigd door PizZa_CalZone op 24 juli 2024 14:32]

[watercoolertje]

Heb je toevallig op de verkeerde gereageerd? Je zegt hetzelfde als ik maar dan met veel meer woorden...

[Niet Henk]

Mijn punt is: je wil wel een frame tekenen zonder eterne data, want deze kan wel nieuwe informatie bevatten.

Je hebt alleen ook nadelen als je dat doet: of haperige bewegingen van andere spelers (sinds dit niet synchroon loopt met je framerate), of extrapolatie van bewegingen, daardoor conflicten, en daarom verspringende spelers.

[watercoolertje]

Dat is mijn punt ook

[.oisyn]

Volgens mij loopt het spaak door deze zin in je eerste post:

Wel hoef je de data van extern niet te herberekenen als je dat al eens gedaan hebt en er niks veranderd is.

Dat lijkt te suggereren dat bij geen update er niets verandert (behalve jezelf), maar dat is natuurlijk niet zo.

[HKS-Skyline]

Het zou kunnen zijn dat een hoge fps een oneerlijk voordeel kan geven mbt de tick rate en dat dat opgelost moet worden voordat ze de frameratelimiet verwijderen. Tick rate en fps zijn meer aan elkaar gebonden dan je zou denken. Het is dan ook ideaal om als je online fps games speelt er voor te zorgen dat je monitor refresh rate, fps en tick rate op elkaar zijn afgestemd en allemaal ongeveer gelijk of een meervoud van elkaar zijn.

[Jhinta]

tick rate en fps hebben niets met elkaar te make, na mij weten

[Reactie gewijzigd door Jhinta op 24 juli 2024 14:32]

[BarnET]

Tickrate bepaald hoevaak per seconde de server dat kan sturen naar jou client.
In deze modus lijkt dat respectievelijk 10-20hz in de huidige staat. Afhankelijk van het aantal actieve spelers.

Dat is langzaam bedroevend langzaam. Dat betekend dat je client maar 1 update krijgt per 100ms. Dat is gewoon veelste weinig voor een redelijk ervaring.

Verwacht dus dat je vaak geraakt wordt achter cover, dat je kogels niet registreren en dat je insta killed word op je eigen scherm.

Althans in deze speel modus. De normale multiplayer modus draait op 62hz en laat delays zien op het niveau van battlefield 1. Niet fantastisch voor een modus met weinig spelers maar zeker goed speelbaar.

bron: battlenonsense
https://www.youtube.com/watch?v=1T2ohLYKlkg

[mrkleise]

Volgens mij moet je het zo zien: Meer frames per seconde is meer ook meer mogelijke inputs per seconde om die vervolgens ook verwerkt moeten worden door de server.

Pubg draait bijv. op 60hz terwijl Unreal Engine 4 normaliter een tickrate/notify van 100hz heeft, maar gezien de grootte van de map en grote hoeveelheid spelers hebben ze dat teruggeschoeft omdat de datastroom en het verwerken daarvan teveel wordt.

Het komt simpelweg neer op de goede balans vinden tussen performance en de kosten voor de servers.

[ard1998]

Zodat ze over een paar weken wanneer de meesten het spel vergeten zijn een nieuwsartiekel kunnen publiceren waarin ze aangeven dat ze de fremerate verhoogt hebben. Meer kan ik er niet van maken.

[Armselig]

Ik zag dit op de reddit pagina staan, als iemand er wat aan heeft: https://www.reddit.com/r/...s_4_launch_on_pc/e780mkq/

[Cyclonic]

Hoezo kon dit vroeger wel al bij Quake 3 arena en Unreal tournament, en nu ineens kan het niet meer los van elkaar

[myskylinedrive]

Hangt de refresh rate van data updaten naar de servers dan aan de lokale framerate oid? ik zie nog even niet waarom de lokale FPS externe servers beïnvloed.
Lijkt me ook een slechte zaak, zo wordt het voordeel van mensen met dure computers dus groter?

[watercoolertje]

Lijkt me ook een slechte zaak, zo wordt het voordeel van mensen met dure computers dus groter?

Dat staat nergens zo beschreven dus waarom zou je daar meteen van uit gaan?

[Craimasjien]

Er staat inderdaad nergens dat het spelers met hogere framerates positief beïnvloed. Daarnaast is die stelling in zijn totaliteit natuurlijk incorrect; want als ik een slechte(re) computer heb en ik ga spelen in 1024x768 met alle settings op laag, kan ik in theorie ook een framerate van 144 FPS halen.

[Gamebuster]

Mijn theorie: De tickrate van de servers is de tickrate waarin de inputs van alle spelers verwerkt worden. Daartegen zullen PCs wel ieder frame de inputs naar de servers versturen. Hogere framerate houdt dus in dat er veel meer pakketjes per speler op de servers binnenkomen, waardoor je per "tick" dus meer data te verwerken hebt.

[Schuimpje]

Ik verwacht hoe hoger de FPS hoe meer beeldjes er verstuurd moeten worden naar je PC die ze vervolgens doorstuurt naar je scherm. Denk dat daar het stuk belasting in zit?

[snippiestgem]

Die beeldjes worden niet naar je PC gestuurd maar die rendered ze zelf

[Reactie gewijzigd door snippiestgem op 24 juli 2024 14:32]

[daan.timmer]

Waar heb je het over? "beeldjes er verstuurd moeten worden". Gevalletje de klok horen luiden maar weet niet waar de klepel hangt.

Framerate en Tickrate zijn twee totaal verschillende, hopelijk ongerelateerde, zaken.

Daarbij worden er geen beeldjes verstuurd van de server -> PC -> scherm. De server houdt de global state bij van alles wat er om je heen gebeurd. Dit doet hij in vaak niet-gespecificeerde en maar wel gegarandeerde tick-rate. Dit is dus de snelheid waarmee het spel om je heen bijgehouden wordt en op welke snelheid user-input wordt geaccepteerd van alle spelers.

De server stuurt vervolgens deze gamestate (via incremental updates/batch updates/volledige game state (zijn verschillende manieren van transfer voor)) op deze gegarandeerde frequentie naar jouw PC.
De enige zaken die voor jou hier van invloed zijn is jouw latency van en naar de server.

De latency van jouw machine naar de server bepaalt wanneer de server jouw user input accepteert.
De latency van de server naar jouw machine bepaalt wanneer jij de updates van alle andere spelers ontvangt.

De framerate is jouw perceptie van deze spel wereld. En hoe vaak deze wordt ververst op jouw scherm. Echter de game-state wordt bepaald door de tick-rate van de server.

[batjes]

Framerate en tickrate zijn niet ongerelateerd.

Want wat is er te drawframen als je systeem geen instructies krijgt van enemy/teammate zit daar, kijkt deze kant op, schiet met X wapen.

Als de tickrate 20 is en je fps 60, loopt je GPU 2/3de van de tijd dezelfde frames te tekenen. Nu klopt dat niet helemaal want je eigen beweging staat los van de tickrate (of naja los, soort van). Maar als jij je point of view stilhoudt, zijn je daadwerkelijke FPS en de server tickrate gelijk.

[3raser]

Ik hoop dat dit niet zo is, want dan zouden je medespelers wel heel houterig bewegen. De tickrate stuurt nieuwe data waarmee de positie, snelheid en richting van de spelers wordt aangegeven. Die data wordt verwerkt in een vloeiend beeld zodat als je even geen nieuwe data krijgt de speler gewoon in dezelfde richting blijft door bewegen. Dus zelfs als jij volkomen stil staat en je krijgt geen nieuwe ticks dan nog kan het beeld veranderen omdat er een speler door je beeld komt lopen. Dit effect zag je vooral goed in oude games waarbij spelers doelloos tegen een muur aan liepen. Dan waren er blijkbaar verbindingsproblemen.

[batjes]

Tot iemand lagged en je ziet dat de bewegingen helemaal niet zo vloeiend zijn als ze lijken.

Vanaf een framerate of 20 kunnen dingen al snel vloeiend lijken.

[MSalters]

Klopt - er is een reden dat films historisch op 24 fps gedraaid werden. Dat was genoeg voordat de marketing-hype ermee vandoor ging.

Bij gewone verlichting (lamp) wil je geen effect van beweging of verandering. Dat moet contant zijn, net zoals de zon. Vandaar dat het lichtnet met 50 hz werkt - dat is meestal voldoende om in de meest moeilijke situatie (stationaire verlichting) nog de illusie van verandering weg te nemen. Toegegeven, dat is 50 hz wisselspanning, dus 100 keer per seconde positief of negatief, maar 100 FPS is dus zo'n beetje de bovengrens wat mensen nog kunnen zien.

Ik denk dan ook niet dat in een dubbelblinde test er een statistisch significant verschil gevonden gaat worden tussen 120 hz en 144 Hz schermen. 50% van de kijkers zal verkeerd gokken.

[MitchellHearth]

En toch heeft dat naar mijn weten niks met elkaar te maken. Dit vanwege de tickrate die wordt aangehouden.

"Tick rate is the frequency with which the server updates the game state. This is measured in Hertz. When a server has a tick rate of 64, it means that it is capable of sending packets to clients at most 64 times per second. These packets contain updates to the game state, including things like player and object locations. The length of a tick is just its duration in milliseconds. For example, 64 tick would be 15.6ms, 20 tick would be 50ms, 10 tick 100ms, etc."

Oftewel: ook al draai jij strak 144fps op jouw scherm, de server updatet maar 64 keer per seconde. Staat los van elkaar.

[Verwijderd]

In de mmo fps planetside 2 is framerate ook gebonden aan maximale rate of fire. Met zeer hoge fps kan je dan een paar procent meer kogels afvuren

[myskylinedrive]

Ja dit is hoe je verwacht dat het normaliter zou werken, maar dat verklaard niet waarom z dan een limiet op FPS zetten om de servers niet over te belasten. Ik vind het een aparte redernatie

[mikesmit]

De informatie over de server en andere spelers horen gebonden te zitten aan de tickrate. De tickrate hoort onafhankelijk te werken van de fps van de spelers.

[Waltro]

Maar ben ik de enige die gewoon niet zo'n lekkere fps had in de beta? Haalde met een i5 6500 en een 1070 op 1080P rond de 70-80FPS met alle settings op low.
Naar mijn mening heeft dan de fps cap van 120hz naar 144hz niet heel veel nut, omdat 99% van de spelers niet eens 144fps gaan halen?

[MaestroMaus]

De release zou beter kunnen draaien dan de beta. Ik begrijp eigenlijk sowieso niet dat jij maar 70 of 80 fps had. Misschien houdt de CPU betere prestaties tegen?

[Waltro]

Of couse zal de echte game beter draaien dan de beta, maar zal geen +150% zijn toch?

En ja, is vaak m'n cpu. Ook aan het denken over een upgrade

[andreboy70]

Raar... Ik had met een i5 3450 en een gtx 1070 + 16 gig ram rond de 80-90 fps,
Moet er wel bij zeggen dat ik fullscreen optimalisatie van Windows uigezet hebt in de properties van de .exe.

Ben wel benieuwd hoe het spel draait a.s. vrijdag.

[MaestroMaus]

Dat klinkt allemaal leuk en aardig maar het neemt niet weg dat de beta (en waarschijnlijk de release) op 10 tot 20Hz draaien (bron). Zolang dit niet verbeterd betekend die hogere framerate slechts dat we alleen maar de server interpolatie beter kunnen zien. Ik hoop dat ze hier verbeteringen voor brengen bij of na de release.

[Reactie gewijzigd door MaestroMaus op 24 juli 2024 14:32]

[RoaDHouse]

Ik denk dat er sowieso weinig gamers 144fps kunnen renderen in de Blackout-mode

[Gamebuster]

Je zal maar ieder jaar een nieuwe game uitbrengen en dezelfde engine verder optimaliseren, en dan nog steeds dit soort issues hebben

[Loggedinasroot]

Wat zat CS toch goed in elkaar. Geen rare dingen gekoppeld aan de framerate oid.

[Nolimit89]

Wat? 'Geen rare dingen gekoppeld aan de framerate oid' is de meest inhoudsloze zin die ik ooit heb gelezen.

[Toettoetdaan]

Als je in de oude CoD engine meer dan 120FPS had, dan kon je net iets hoger springen. Dat was erg gunstig om te glitchen .
Er zijn meer engines die vreemd gedrag hebben bij hoge FPS.

[Byte]

Sterker nog, bij een oude FPS genaamd WarRock was het zo dat je met een overclock je FPS kon verhogen. Met deze hogere framerate kon je sneller schieten waarmee je meer kogels schoot binnen een kortere tijd. Je kon sneller rennen, herladen en sommige glitches werden mogelijk.

Helaas werd er nagenoeg weinig tegen gedaan. Mensen die overlockten hun pc soms net genoeg om nét dat stuk voordeel te hebben zonder dat je het daadwerkelijk goed kon bewijzen dat deze personen dit deden. Hierbij kwam ook dat je geen deadcam had, hierdoor kon je ook moeilijk zien hoe je precies dood ging.

Tot slot was dit niet het enige probleem De meeste handelingen werden niet door de server bepaald, maar door de client kant. Hierdoor was het hacken erg makkelijk.

[HarryProtter]

Zoiets was ook het geval in de CoD van vier jaar geleden, Advanced Warfare. De EM1 Laser Rifle "schoot" 1 bullet per frame. Vanwege de 60 FPS cap op consoles schoot dit wapen voor iedereen op dat platform 60 bullets per seconde. Maar als je niet 91 FPS kon halen op PC (de PC FPS cap in AW destijds) had je een groot nadeel, want dan schoot jouw wapen veel langzamer.

[Craimasjien]

Sterker nog; de eerste game in de serie spellen waar jouw avatar vandaan komt was ook bijzonder geïmplementeerd. Als je namelijk in de eerste Rayman game de FPS unlockte ging de game ook sneller lopen. Alles, van animaties tot aan natuurkundige berekeningen was gekoppeld aan de framerate. Destijds was dat heel normaal, maar tegenwoordig not-done.

[Desiler]

125fps, 250fps en 333fps op cod2/4

[SPOXYWOXY]

333 fps werd zelfs verboden op ClanBase omdat je dan stil kon lopen

[MaestroMaus]

Als je bij CS:GO op een server zit met een update rate van 128Hz in plaats van 64Hz dan moeten sommige granaat worpen opnieuw geleerd worden omdat de verhoogde update rate ervoor zorgt dat de baan die granaten afleggen anders wordt. Ik weet de technische verklaring hiervoor niet maar ik weet dat het zo is uit instructie filmpjes voor rook granaten en de positionering hiervoor.

[Reactie gewijzigd door MaestroMaus op 24 juli 2024 14:32]

[Craimasjien]

Waarschijnlijk is de berekening voor zwaartekracht gekoppeld aan de tickrate. Waarschijnlijk daalt de granaat sneller met een hogere tickrate dan met een lage.

[JEROENrgfgf]

Dit fenomeen komt bij CS:GO alleen voor wanneer er gebruikt wordt gemaakt van een zogenaamde jump-throw. Een normale stilstaande throw of run-throw is nagenoeg hetzelfde. Waardoor het met een jump-throw wel anders is omdat je positie en snelheid ook ruwweg 2 keer zo snel geüpdatet wordt. Dit zorgt er voor dat wanneer je gebruik maakt van een jump-throw je opwaartse snelheid net iets hoger is dan op een 64 tick server waardoor je smoke/nade/flash net iets verder vliegt omdat zijn baan ook afhankelijk is van de snelheid waarmee je je beweegt.

[snippiestgem]

Ah, de goede oude CoD4 waarbij 120fps goed voor parallel springen is, 250fps voor afstand (bounce bijv.) en 333 fps voor hoogte als ik het me goed herinner.

[batjes]

En in CSGO kun je bij 120 FPS sneller de map door bunnyhopen of strafejumpen.

[J8S]

Dat is de tickrate van de server, niet de FPS van je client.

[CH4OS]

Klopt, al is het afkomstig uit de id Tech engine.

[batjes]

Wat een onzin, verdiep je er eens in. Heel dat spel zit gekoppeld aan de framerate

Welk spel heeft baat bij bepaalde FPS hoeveelheden? 60/90/120.

Welk spel heeft strafejumping om sneller het level door te komen wat geholpen wordt door bovenstaande FPS. Wat weer een resultaat is vanwege het feit dat alles gekoppeld is aan de drawframe, de tijd+physics draaien niet apart zoals moderne engines als UE4 dat wel doen. (UE destijds ook niet, wel beter dan Q3)

Oh ja.. Counterstrike.

De Source engine is een fork van de IoQuake3 engine. Zie ook Q3's rocket jumping en RCTW:ET's trickjumpen.


Oh en in CS:GO heb je ook van die custom trickjump maps, dit is enkel en alleen mogelijk omdat de physics en de framerate aan elkaar geknoopt zijn. De trickjump maps in CS is de legacy van Quake 3 en RTCW:ET

[Loggedinasroot]

Er is een verschil tussen de tickrate van de server en de FPS van de client.

[Anck]

Beetje raar verhaal dit. Server tick rate en FPS zouden sowieso niet aan elkaar gelinkt moeten zijn. Zou het probleem zijn dat input per frame gesampled en naar de server verzonden wordt?

[Anoniem: 508592]

120 is zat op