Előre legyártja a headshotot.

Végül is ennel lenne értelme a mikrotranzakciók világában.

Ilyen nincs hogy negatív késleltetés.

Azért fejlesztik, hogy legyen.
Tényleg elég bután hangzik amúgy..

Vagy csak marketing, hogy felfigyeljenek rá az emberek: az túl egyszerű leírni és értelmezni, hogy "gyorsítják", így meg mindenki vadul gondolkozik, hogy mi a fütty az a negatív késleltetés.

25 eve ID-ek hasonlo problemara csinaltak a client-side prediction-t. Nyilvan ez most server-side prediction, de az otlet teljesen hasonlo, csak 25 ev a lemaradas. Persze, ertem, hogy nem fejlesztenek felhos jatekot 25 eve, tehat nem lehet elvarni, hogy mar akkor ok is csinaljak, de azon csodalkozom, hogy ez ilyen keson kerul elo, kb. a felhos jatek otletenek feltalalasakor tudtak, hogy latency problemat kell kezelni, es mar volt ra megoldas korabban.

[ Szerkesztve ]

"egy vagy két éven belül a felhőben futtatott program késleltetését jobbnak érezheti majd egy felhasználó a lokális gépen futó verzióhoz viszonyítva, legyen a helyi rendszer akármilyen erős."

Hát persze.

Aztán meg a kezük a biliben. Tippel... Mennyit...? Tippel párat, hogy vagy így mozdul vagy úgy...? És ha mégsem...?

Mutathatnanak egy grafikont hogy hany kepkocka/eloreszamolas-hoz hanyszoros teljesitmeny szukseges, mert gyanus hogy otletnek jo, csak a megvalositas kivitelezhetetlen.

[ Szerkesztve ]

" hogy egy vagy két éven belül a felhőben futtatott program késleltetését jobbnak érezheti majd egy felhasználó a lokális gépen futó verzióhoz viszonyítva, legyen a helyi rendszer akármilyen erős."

Mintha a lokalis predikcio nem lenne lehetseges. Sot meg koltseghatekonyabb is, mert nem kell idoben annyit elore megjosolni, mint tavoli eseten, tehat a hardverigenye is alacsonyabb vagy tobb variaciot engedhet meg maganak.
Marketing bullshit az egesz.

[ Szerkesztve ]

Egyreszt ugye lehetseges lasd #6, masreszt ahhoz nem eleg egy vekony kliens ami csak streamet kap, hanem akkor lokalban kene kepet is szamolni, tehat ezzel a felallassal nem lehetseges.

Legalább valamire jó lenne az SLI / CF

Ezt a reszet nem csak Abu talalgatta hozza szokas szerint? Amugy a valosagban nem a grafikaban van logikusan a predikcio, hanem az allapotterben, abbol kell kepet szamolni, es van egy valosag, ami a mar valos user inputokat tartalmazza, es a kettot kell probalni szinkronban tartani, lasd quakeworld. Kepet ertelemszeruen egyet kell szamolni, amugy is fura lenne ha gop-os streamben tobbfele kep is lenne, kepkockankent mondjuk 4 fele agazna.

[ Szerkesztve ]

Itt mindenki sokkal okosabb, mint a Googlenél meg a Microsoftnál! Akárhány felhős játék hír van, mindenki kutyázza, hogy egy szar lesz, játszhatatlan stb... Igaz a Stadia jövő hónaptól használható, a Project xCloud meg 2 héten belül már tesztelhető lesz. Nyílván ők egy világösszeesküvésben hisznek, hogy mindenki hazudozik össze vissza, rombolva a saját hírnevüket, csak nem tudom mit fognak akkor néhány hét múlva csinálni, amikor Halozni fognak felhőben meg Red Deadezni Stadián...

[ Szerkesztve ]

Ez gyakorlatilag a CPU-beli spekulatív végrehajtás leképezése a 3D-s jelenetbeli mozgásokra, nem?
Mivel sokkal több képkockát kell számolni a szerver oldalán és pontos predikció szükséges, hogy a kliensnek csak a legvalószínűbbeket küldje el, így a CPU-beli elágazásbecslőt is mintázniuk kell (~merre fog legvalószínűbben mozdulni).

[ Szerkesztve ]

Az a fránya fizika, ez a bajok forrása. Mert akárhogy is számolom, amit ők állítanak az fizikai képtelenség...

Konkrétan melyik része és miért?

Tehát: drága a hardver otthonra, futtassuk felhőben, mert úgy gazdaságosabb... persze ott a késleltetés gondja, ami miatt számoljunk többször annyit, legfeljebb drágább lesz... még mindig tuti gazdaságosabb? Vagy netán az egész lényege mégiscsak az, hogy havidíjat fizess, ne vehesd meg, és játssz vele amíg csak akarsz

A predikció persze, hogy az állapottérben van, de mennyivel vagy előrébb, ha nem számolsz több képet?

Ha jól értem akkor az user nyomja az fps-t és a szerver elküld egy rakás lehetséges képkockát amit feltehetően lépni fog és azt rakja elé amit ténylegesen meglépett. Így user örül mert minimális késleltetéssel folyamatosnak látja a játékot.
Elméletben jól hangzik, egy egyszerűbb cső fps-nél szerintem működhet jól. Viszont ott megbukik a dolog amikor egy bonyolultabb dolgot tesz, illetve ha nem talált megfelelő képkockát akkor lesz egy szép törés a késleltetésben mert a nem becsült képet kell kiküldeni.

[ Szerkesztve ]

Annyival, amennyire a predikcio jo. Szkeptikus vagyok a tobb kep szamolassal kapcsolatban, nem tudom elkepzelni, hogy az ertelmesen mukodjon, teszem azt 2-3 kep latencym van, szaladok egyenesen, akkor a szerver minden kephez szamol nekem olyat, hogy akkor fordulnek jobbra/balra/le/fel vagy mennek egyenesen, ez ugye 5 kep a kovetkezo frame-re, aztan onnan szamolna 5 kepet a mennek egyenesenre, illetve folytatna a masik negyre a fordulast (mert ugyesen tudna, hogy ha elkezdtem fordulni, akkor nem hagyom egybol abba), tehat 9 stream jonne egyszerre? Es akkor egy masik user meg meg sem jelent. Ertem, hogy ms-ek csinaltak egy ilyen kutatas-fejlesztes projektet, de ez szerintem gyakorlatban nem mukodik.
Ellenben olyan mindenkepp elofordul, hogy a valosag nem egyezik a predikcioval, es korrigalni kell, tehat azt egy vagy tobb kep eseten is meg kell csinalni, az egy kepes meg mar mukodott a quakeworld-ben, szoval amennyire 20-25 eve mukodott annyira most is fog.

Igen, nekem is ez a problémám. Elvileg jó ha minden jó, de vajon mennyire lesz érezhető ha valami nem jó? Sokkal rosszabb ha a ping ugrál 10 meg 200 ms között, mint ha konstans 150ms.

Pedig még most csak a technikai oldalával elégedetlenkednek, még nem is jött elő, hogy a Stadia a PC/konzol játéknak, és a magának a játékok birtoklásának a végét jelen..tené.

Én speciel nem látom technikai oldalról vészesnek a projektet, már 2012-2013 környékére a OnLive és a Gaikai teljesen használható volt. Nem hiszem hogy 8 évvel később egy Guglinak ez gondot okozna, mikor minden bokorban van egy szerverparkja, és saját netet szolgáltat.
Még a játékos hardver macerás megtérülését is helyre lehet billenteni, ha majd nem konzolra és PC-re, hanem a saját spéci vasukra fejlesztik a játékokat.

Csak hát pont ez a gond, ha a Gugli tényleg ránk tudja erőltetni a cuccát, és nem kerül a temetőjébe, akkor a PC játékot fogja kifingatni modostul, GoGostul, mindenestül.

[ Szerkesztve ]

Én ezt még el tudom úgy képzelni, hogy a látottnál nagyobb képet renderel és ha épp fordulsz, akkor a gépnek azon részét rakja eléd amerre fordulsz, nem a közepét. Ez is + terhelés, de nem kell több teljes képet renderelni. Illetve be van tárzava pár "effekt" amit nyomsz, elkezdesz lőni, akkor nem kell olyan kép is amin te lősz, hanem csak bevágja azt a rész amikor már jön a tűz.
Illetve ezt gondolom eleinte valamilyen konzolos irányításhoz tervezik, ahol nem tudsz túl gyorsan fordulni sem.

[ Szerkesztve ]

Nekem a gyakorlati tapasztalataim az OnLive és Gaikai jelenkori utódjaival. A GeForce NOW!, LiquidSky vagy épp Paperspace használatával elég más jellegű tapasztalataim vannak. Vannak olyan helyzetek amikor már-már játszható, de ez a play-anywhere nagyon-nagyon messze van még. De lehet, hogy az én igényeim magasak. Egyébként megint két lépéssel a tömeg előtt jársz a helyzet megértésében, de ezzel maximum az ellenszenvüket vívod ki... Legnagyobb sajnálatomra.

(#17) E.Kaufmann
Késleltetés, képminőség. Egyiket sem képes ugyanazon a szinten produkálni. Lenyomom a gombot és 30-50 ms múlva elsül a fegyver és sebződik a delikvens a másik oldalon. Ez persze optimális eset, de kizártnak tartom, hogy ezt a nagyságrendet a komplett kép küldésével lehetne tartani, míg az előző esetben csupán kbyteok fordultak meg a szerver és a kliens között. A képminőség részéről meg csak annyit, hogy 1080p-60Hz-8bit az majdnem 4Gbit sávszélességet igényel, ezt nem lehet látható minőségromlás nélkül átültetni 50Mbitre.

[ Szerkesztve ]

Igy van, ezt en is el tudom kepzelni, voltak is ilyen kiserletek, hogy egy kepet ugy torzitani, mintha mas szogbol/helyzetbol latnad, eggyel jobb, mint az ugras.

Szvsz siman megoldjak... a masik, hogy ott nem a hc gamer az elsodleges piac, de ha senki sem vesz videokartyat, ok is at kell hogy szokjanak, mert nem fognal egy szuk retegnek fejleszteni.

Egy okostelefonnyi kliens elott fogunk csucsulni, a cegeknek ez a jo, biztos beveteli forras sw oldalrol.

Male: De ebben hol van a fizikai törvények meghágása?

bunfi: Biztos lesz minőségromlás, de abban is biztos vagyok, hogy nem is árultak el minden részletet és majd felhasználás közben dől el, tud-e segíteni a késleltetésen a projekt vagy sem.
Valamint lehet hogy van valami jó tömörítési módszerük, hogy azt az x darab legvalószínűbb képet ne x szeres adatmennyiséggel kelljen átküldeni.
Ezen felül, ha sok az fps és bizonyos minőségbeli problémákat jobban meg tudnak oldani központilag, mint egy otthoni GPU-n, fotórealisztikusabb az élmény pl, az lehet ellensúlyozza a tömörítés minőségvesztését, valamint ha nincsenek a játékmenetet zavaró hibák, akkor egy játékos inkább fogja nézni, hogy ne lőjék agyon, minthogy a tömörítés minőségén filózzon.

[ Szerkesztve ]

leirva ez egy timewarp variansnak tunik. proof-of-concept szinten lattam mar egyszerubb jatekot gyonyoruen futni 60Hzn 150kmre levo szerverrel es kb 200mses roundtrippel, szoval meglepoen sok mindent el lehet fedni. a dontesi fabol parat elore szamolni pedig szinten nem pelda nelkuli, bar az tenyleg draga.

a jatek engine es a jatek design szinten olyan, ahol eleg sokat lehet nyerni. pl a WoWnal volt egy csomo olyan game design dontes amik egyertelmuen azert lettek olyanok, hogy elmaszkoljak a TCP miatti potencialis latency varianciat.

mindenesetre kivancsi leszek. par eve mar volt egy ilyen irany, akkor nagyon nem lett semmi belole, viszont most ugy nez ki vannak nagyobb jatekosok a technologia mogott. par tekintetben egyebkent a gyakorlatban megoldhatatlan feladat kozeliteses megoldasarol van szo, szoval erdekes lesz latni a whitepapereket a technologiarol.

(6) lenox: egyaltalan nem lett elfelejtve a technika, jellemzoen egy masodeves jatekprogramozo le fogja tudni implementalni kurzus kereteben. foiskolai tananyagrol beszelunk.

ilyen vagy olyan formaban gyakorlatilag az osszes nagyobb AAAs jatek hasznalja bizonyos helyzetekben, plusz a VR headseteknel az asynchron timewarp is hasonlo elven mukodik.

ami miatt nagyon senki nem hasznalta, mert celhardver kell hozza, a felhos GPUgyorsitas meg par eve meg irdatlanul draga volt hogy megerje vele jatekszolgaltataskent is foglalkozni.

[ Szerkesztve ]

Te is úgy gondolod, nem fog kelleni ennyi idö beépíteni a standalone kódokba a késleltetö algoritmusokat?

#11 E.Kaufmann: Nem, engem az tört le, ami holnap történt.

#13 lenox: És akkor majd A) filmnézés lesz mindenkinek a játék, mert midnent kiprediktál a rendszer, B) Még ki se nézel a fedezék mögül, már fröccsen a vér és kapod a heccsát.

[ Szerkesztve ]

Ez egészen addig jópofa ötlet, amíg egy darab nem determinisztikus szereplőt próbál előre kiszámolni a rendszer. De ha egy helységben többen tartózkodnak, akkor ugye a probléma exponenciálisan növekszik.

A diplomás, évtizedes tapasztalattal rendelkező szakembereik biztos kevésbé értenek hozzá, mint te.

Mi van akkor ha a scriptek,fix effektek helyett elkezdünk áttérni a valós időben számolt szimulációkra(rombolás,komplex sérülésmodellezés,particle physx,folyadék szimuláció stb)?
Ha jól értem a számolandó adat mennyiséggel arányosan nő a döntési fa.

[ Szerkesztve ]

Igen, több kép előreszámolása halmozottan handicapes, én nem is gondoltam egy lépésnél többre. A korrekciós dologban meg segít, hogy ha sűrű a képfrissítés, mert így csak kicsit lehet tévedni.

egyaltalan nem lett elfelejtve a technika, jellemzoen egy masodeves jatekprogramozo le fogja tudni implementalni kurzus kereteben. foiskolai tananyagrol beszelunk.

Hat ez az.

ami miatt nagyon senki nem hasznalta, mert celhardver kell hozza

Itt kikerultunk a szinkronbol, amirol en beszeltem ahhoz nem kell celhardver, quake/duke nukem koraban sem volt, tehat valami masra gondolsz. De mire akkor?

kimaradt a fel mondat . ami miatt senki nem hasznalta a felhot jatekra az az, hogy ahhoz GPU gyorsitas kell, ami felhoben draga.

Máris megtaláltuk hol lehet bevetni a kvantum számítógépeket a játékoknál Az elvileg erre is jó, hogy sok lehetséges kimenet közül "megsejti" mi lesz a helyes (vagy legalább is eléggé leredukálja a lehetőségeket).
Kár hogy bármi ilyen alkalmazástól még fényévekre van. De majd egyszer.

Esetleg ha valaha lesz kvantum összefonódásos adattovábbítás és az felett internet kapcsolat zéró késleltetéssel, akkor teljesen megszűnik a probléma is

Unokáink talán még megélik.

[ Szerkesztve ]

Szerintem az sem sejtené meg, hanem legjobb esetben is egyszerre számolhatná az összes lehetőséget, de még az is fényévekre van.

Nyilván érdemes lehet bedobni egy elágazásbecslés algoritmust, ami azonosítja a játéktér kritikus pontjait (akár gépi tanulással) és a kritikus pontok közelében a képet a normálisnál jóval nagyobb részleges látószögekre rendereli néhány képkockával előre le, küldi le az adatot, majd a kontroller/egér tényleges pozíciója szerint a kliens kiszedi a látószögnek azt a részét amit ténylegesen meg kell jeleníteni, illetve jelenti vissza a kliens a szervernek, hogy melyik út vált be.

A hagyományos elágazásbecsléshez hasonlóan itt is az lehet a gáz, amikor éppen nem vált be semennyire az elágazásbecslés, a kiszámolt és leküldött adatok érvénytelenek és szükség van egy teljes oda-kiszámol-vissza ciklusra.

Na ezeket a tüskéket majd megérzi a játékos.

=====

A szükségesnél nagyobb képet előre kiszámítani hogy annak csak egy része legyen megjelenítve (a maradék megy a süllyesztőbe) majd hatékonyan tömöríteni és azt a nagy képet átküldeni egy korlátos sávszélességű csatornán kicsit hurráoptimistán hangzik, ha azt várják, hogy meg is érje és a user ne vegyen észre ebből semmit.

[ Szerkesztve ]

Ugy latom, itt sokan kicsit mintha lebecsulnek, milyen mennyisegu adata es milyen minosegu AI-ja van a guglinak.
Arra celzok, hogy siman azzal, hogy a nep jatszik, osszegyulik irgalmatlan mennyisegu adat, es az alapjan mar lehet AI-t betanitani, igy a szukseges predikciok mennyisege drasztikusan csokkentheto, persze ha a megfelelo minosegu es mennyisegu telemetria adott.
Innentol kezdve adott szituaciora mar ertelmezheto mennyisegu predikcio eleg az esetek 90%-ban. A kerdes inkabb az, hogy a maradekot hogy oldjak meg, mert ha fel-le ugralni fog a kesleltetes, es pont akkor ugrik meg, amikor valami varatlant csinalsz, plane ha direkt, az szvsz enyhen szolva irritalo lesz.
Tehat szerintem ez ugy fog kinezni, hogy minel tobben, minel tobbet jatszanak egy adott jatekkal, annal jobb es olcsobb lesz a predekcio.

Sehol nincs benne, nem válasz akart lenni neked, csak félrenyomtam

#43 opr: Igazából akkor tovább is léphetnénk, minek egyáltalán bármit csinálni, elindítod az autóversenyt, és kiírja, 3. lettél, kikapcsolhatod

[ Szerkesztve ]

Ugy latom, itt sokan kicsit mintha lebecsulnek, milyen mennyisegu adata es milyen minosegu AI-ja van a guglinak.

Én erre speciel nem pozitívumként szoktam tekinteni.

Tehat szerintem ez ugy fog kinezni, hogy minel tobben, minel tobbet jatszanak egy adott jatekkal, annal jobb es olcsobb lesz a predekcio.

A predikció nagyon szép, de már az Intelnek sem annyira jött be az utóbbi időben. Az nVidia is erre építette fel a DLSS-t, hogy spóroljunk valamin, csak az ár amit ki kellett érte fizetni (a szó átvitt és tényleges értelmében) az kissé túlzás volt.

Ezt a kerdest kizarolag technologiai szemszogbol vizsgalom, kizarolag a cikkben szereplo alkalmazas celjabol, illetve a megvaloszithatosag szemszogebol. Innen nezve pedig a sok adat es a jo AI pozitiv dolog.

Predikcio: Ez teljesen mas struktura, teljesen mas technologia es teljesen mas kornyezet. Persze, ismet, nem penzugyi szempontbol nezem a dolgokat, kizarolag technologiai oldalrol, hogy mennyire megvalosithato. Egyertelmu, hogy maga a nev, hogy negativ kesleltetes akkora orbitalis naprendszer-meretu bullshit, hogy valami marketinges bonuszt kapott erte, de amugy a stream technologia egyik hatranyat tobbe-kevesbe orvosolhatja.

Át kell állni quantum számítógépekre és az kiszámolja egy pillanat alatt az összes lehetséges opciót egy hónapra előre még World of Warcraft-ban is. Azt már nem Delorean hanem Dr. Strange módszernek fogják nevezni.

A szükségesnél nagyobb képet előre kiszámítani hogy annak csak egy része legyen megjelenítve (a maradék megy a süllyesztőbe) majd hatékonyan tömöríteni és azt a nagy képet átküldeni egy korlátos sávszélességű csatornán kicsit hurráoptimistán hangzik,

Ez biztos kisebb eroforrast igenyel, mint tobb kepet szamitani es kuldeni, de amugy is skalazhatonak kell lennie az egesznek, tehat ha a szerver kevesebbet tud szamolni, akkor kisebb felbontast es reszletesseget renderel, ha a savszel kicsi, akkor meg kisebb bitrate-et es esetleg felbontast hasznal.

Vegyünk egy egyszerű esetet. Fps, megyek egyenesen előre. A következő képkockán nagyjából az alábbi variációk képzelhetők el:
- továbbra is megyek egyenesen (W),
- megállok ( ),
- hátrálok (S),
- ugrok előre egyet (W+Space),
- állva felugrok (Space),
- hátraugrok (S+Space),
- ugyanez guggolással (három különböző képkocka),
- a további 6 mozgási irány (jobbra, balra, és srégen 4 irányban) szorozva a 3 mozgási lehetőséggel (megyek, guggolva haladok, ugrálok), az 18 további lehetőség, ha jól számolom (és akkor az olyan esetleges apróságokat nem is említettem, hogy ha van sétálás a játékban; valamint a fegyverváltás, lövés, gránátdobás stb. jelentette további variációkat, amivel bőven 100 db felett van a szükséges képkockák száma - pl. sima előremenetel helyett lövök is miközben szaladok előre stb.). Természetesen az ellenfelek mozgását is bele kell kalkulálni, akiknél szintén előre kell gondolkodnia a rendszernek, ami már egy közepes csatánál is ezres nagyságrendet eredményez a variációk tekintetében.

Ebben természetesen nincs benne az egérmozgás jelentette plusz (azt szerintem is lehet kezelni nagyobb látószögű képek átküldésével, és az adott pozíciónak megfelelő vágásával, ahogy fentebb írta valaki).

Summa summarum: gépi tanulás ide, tutkó tömörítési algoritmusok oda, elég nehezen hihető, hogy ez a probléma kezelhető a jelzett módon.