29
-
#1
Szégyen, hogy a teljesítménynövelés fmindenképpen ogyasztásnöveléssel jár. Úgy könnyű. A hatalmas árat pedig semmi nem indokolja, hiszen épp a komoly fejlesztések maradtak el, ha csak fogyasztásnöveléssel érték el a "fejlődést". -
robogo81 #2 Most jöhetne az hogy régebben minden jobb volt,de tényleg az ment évekig hogy az előző csúcskártya teljesítményét hozta a következő generáció majdnem csúcskártyája(980 vs 1070) de kisebb fogyasztással.Az hogy nagyobb teljesítmény oké mert azért fejlettebb,de sokkal nagyobb fogyasztás az annyira nem oké,amikor dupla gpu-s volt pár kártya,akkor tényleg volt fogyasztás,de ez most inkább lustaságnak tűnik. -
Kissssss0 #3 "viszont ezt a hatalmas teljesítményt jóval magasabb fogyasztás egészíti ki, az új kártyák ugyanis 450 wattnál tetőznek."
kifognak "gyulladni" a vezetékek a ház falában... -
dyra #4 Nem jó az új irány. A CPU-k is meg a VGA kártyák is brutál fogyasztást csinálnak. 1000 wattos tápok kellenek majd? -
Ender Wiggin #5 Meg a rezsiszámla a kezedben... -
Kissssss0 #6 az már feb 24-óta ég, jó reggelt. -
Sir Cryalot #7 Teljesen szétfog válni a datacenter meg a home vonal, az RTX-ük meg nem pixelbe fog dolgozni hanem egy streamelt textúrába amit tömörít meg leküld kliensnek. Az hogy ezt most eladják mint életképes vonal hogy se látótáv nincs raytracelt játékba se semmi az meg egy menedzserizmus. -
Gabbbbbbbbbbbb #8 Nyilván a magas árat semmi sem indokolhatja a pénzéhes részvényeseken kívül, de a nagyobb fogyasztás a fizikailag nagyobb chip következménye és azt sokkal drágább gyártani. (minél nagyobb egy chip, annál több megy a kukába a gyártási folyamat során) -
#9
Mivel jelenleg ekkora teljesítményre (és ilyen áron) a játékosok többségének valójában nincs szüksége, ezért egyre életképesebb megoldásnak tűnnek a felhős játékszolgáltatások. -
#10
450 WattaFcuk -
#11
Arról van szó, hogy az a legolcsóbb fejlesztés, ha növelik a chip méretét és az órajelet. A bevált architektúrával a kihozatal sem lehet rossz a nagyobb méret ellenére. -
#12
A felhős játék szerintem halott ügy. Olyan spétje lehet, hogy borzalmas. És azon nem segít semmi, ugyanis fizikai korlátok eredményezik. -
Sir Cryalot #13 ...amitől a PS4 generációs ugrás volt, hogy játékokban 90% prerender volt a grafika azt a prerendert ugyanúgy elő lehet készíteni szerveroldalon és meg lehet kapni szerverről, csak épp kliensfüggőbbet meg aktuálisabbakat. És nem lesz leszámolva kliensenként ugyanaz.
És akkor már nincs input lag ha nem pixelt küld hanem prerender formátumokat (textúra) . -
Sir Cryalot #14 https://www.gamesindustry.biz/ubisofts-scalar-cloud-technology-aims-for-larger-game-worlds-and-smoother-development
" leszámolva (kliensenként) ugyanaz."
ez az ami halott ügy, mert nem tud átmenni szimulációba mert az szerverteremnek is túl sok de az talán kicsit átmegy (szimulációba).
Utoljára szerkesztette: Sir Cryalot, 2022.09.21. 19:57:45 -
Sir Cryalot #15 https://www.gamesindustry.biz/ubisoft-scalar-aims-to-make-games-more-like-the-web
EZT akartam linkelkni. -
kvp #16 "ez az ami halott ügy, mert nem tud átmenni szimulációba mert az szerverteremnek is túl sok"
En a 2002 utan jatszottam egy MMO/PFS/RPG-vel, amit Neocron-nak hivtak. Ez egy FPS nezetu, FPS iranyitasu, MMO RPG volt, particionalt, on demand betoltott pariciokkal. Anno meg nem tudtak megoldani a seamless particionalast, ezert a valtasoknal volt egy par masodperces szinkronizacio, ami akkor meg eleg gyakran szinkronizacios hiba miatti disconnect-el ert veget, de amikor mukodott, akkor jo volt.
Maga a jatek szerver oldali FPS motort hasznalt, a ballisztikai es mozgas szamitasokhoz is, csak a kevesbe fontos modellek, pl. a kidobott toltenyhuvelyek visszapattanasa a tereptargyakrol mentek kliens oldalon. De a lovedekek kilovesi iranyat a felhasznalo egere hatarozta meg, a pontossagot a karakter skill-je es az adott fegyver tipusa es szazalekos tulajdonsagai, mig a becsapodasi pontjat a lovedekek utjat kovetve a szerveren is jelen levo tereptargyak 3D modelljei. Nem azonnali hitscan alapon futott, igy egy mesterlovesz puska lovedekenek becsapodasa tavolsagtol fuggoen tovabb tartott es virtualis lolapon (pl. egy tetszoleges sik falon) tesztelve a becsapodasi nyomok statisztikailag helyes szoraskepet hoztak. Ugyanigy lehetett a kornyezo tereptargyakon visszapattintva granatot bedobni egy hazsarok vagy egy ladahalom moge.
Hogy oldottak meg? Egy particion belul a szerveren lokalis FPS jatek futott, rendes fizikaval, de csak a fizikai modell-t futtatva, rendereles nelkul. A jatekosok csak bekuldtek a parancsaikat, majd a fizikai motor kimeneteit update csomagokban atkuldte az osszes kliensnek, akik igy szinkronizacional par masodperc alatt be tudtak gyujtani az osszes aktiv objektum allapotat. A fizikai modell nem kulonboztette meg a jatekosokat, az npc-ket es a mob-okat, a jarmuveket, stb. mindegyik csak egy mozgo objektum volt. A jateklogikaban sem volt kulonbseg, minden mob es npc ugyanolyan fps jatekos volt, tehat a sikatorban futo csotany is ugyanugy volt kezelve mint egy jatekos, csak szinkronizalo adatkapcsolat helyett egy buta MI iranyitotta. A vendor npc-k pedig tamadas eseten fegyvert ragadtak es hasonlo algoritmusra valtottak mint a biztonsagi orok. (A fegyvertelen civilek meg elfutottak vagy elbujtak egy kitoro utcai lovoldozes hatasara, mar ha tuleltek.) A fentiek miatt a vendor-okat allandoan potolta a jatekmotor ujakkal, a fontos quest npc-k meg vagy ott voltak vagy varni kellett amig ok is respawn-oltak es visszamentek a helyukre.
Hogy mukodott ez 20 eve? Nehezen. Atlagosan 10-16 jatekosonkent kellett egy fizikai szerver, igy osszesen kb. 32 mozgo jatekos+mob+npc fert el egy szegmensben. Az evek alatt ez csiszolodott, amikor utoljara neztem 2 eve mar az egesz cluster egyetlen berelt szerver sarkaban elfert es meg igy is tobb tucat aktiv jatekos volt a teljes vilagban (amit eredetileg tobb ezer parhuzamos jatekosra terveztek) Ez tobb szaz szektort jelent, mind nagymeretu felszini terkepeket jarmuvekkel, mind kis szuk varosi szektorokat, 1-2 utcasaroknyi terulettel az instance-kent futo dungeon-ok es a jatekosok szabadon berendezheto lakasai nelkul. Minden szektor csak akkor futott, ha eppen volt benne valaki, egyebkent befagytak. Visszatolteskor pedig elore tekertek az idot, a leallitva toltott ido kompenzalasara. (mivel a foldre rakott targyak is megjelentek a kozos fizikai modellben, ezert ezek eltunese ido fuggo volt, jatekos lakasokban a butorok es a szekrenyekben levo dolgok nem tuntek el)
Milyen hibak voltak a szinkronizacio miatt? Movement lag es rubber banding, azaz ha nagyon elmaszott a player lokalis szimulacioja a szervertol, akkor a player visszarantodott a szerver szerinti helyere. Az osszes tobbi mozgo objektum (jatekosok, npc-k, mob-ok) pedig a szerver szinkron szerint mozgott, tehat a tobbi player kisse lemaradva a szerver allapottol, de a jatekosok a szerver fizikai szimulacioja szerinti helyukon lattak oket, ami a kepernyon mindig egy fel ping-nyit le volt maradva a szerverallapothoz kepest. Csomagvesztes eseten pedig predikcios algoritmussal tert el, majd ugrott vissza. Gyakorlatilag a quake 3 fele logika szerint. (a motor egyebkent binary space partitioning-et hasznalt mind a megjelenitesre, mind a fizikai motorhoz) Mindez a kisebb csuklasokat leszamitva mar jatszhato volt 20 eve.
Ehhez kepest a szerver oldali rendering meg gyorsabb es egyszerubb is. Megszunik ugyan a kliens oldali predikcio altal elert mozgas simitottsag csomagvesztes eseten, de en mar jatszottam google stadia-n fps-el es teljesen jol kezelheto, ha alacsony az ember ping-je. A nagy savszelesseg csak a nagyobb felbontashoz kell, de a jo iranyitashoz csak a ping szamit. Mig a zokkenomentes streaming-hez a kis csomagvesztes a fontos, mivel nincs buffer-eles es nincs ujrakuldes (osszesen 1 fame mely a streaming buffer), ha csomagvesztes van, akkor a kepkocka egyik darabja nem jon meg es ott vagy az elozobol tolti ki a kliens 2D mpeg predikcioval vagy sehogy. (lasd muholdas stream-ek mpeg hibait) Progressziv kepek es valamennyi baseline redundancia eseten csak az adott folt kepminosege esik vissza a 8...64-edere, a csomagvesztes merteketol fuggoen.
A fenti streaming kombinalva egy grid vagy BSP alapu dinamikus szektor kezelessel siman tudna biztositani egy nagymeretu jatekvilag szerver oldali kezeleset, szerver oldali fizikaval es ma mar akar tobb szaz vagy tobb ezer mozgo entitassal egy szektorban. Mindezek melle szerver instance-ban futtatva a dungeon-oket es a player houseing-ot mar siman skalazhato lenne a rendszer egy FF14 meretu vagy nagyobb vilagra is, teljes mertekben szerver oldalon futtatva mindent. A trukk, hogy a szerver nem szinkronizal senkivel, csak player input-okat kap, ezert egyszerubb sokkal tobb mozgo objektum kezelese es akar a terep is rombolhato lesz. (lasd multiplayer minecraft csak mondjuk pl. a fent emlitett FF14 szintu grafikaval) -
Sir Cryalot #17 " jatszottam google stadia-n fps-el es teljesen jol kezelheto, ha alacsony az ember ping-je. "
ez vállalhatlatlan képminőség és zajos képet nem lehet tömöríteni, és mindig lesz zaj mert erőforráspazarlás supersamplinges képet számolni, az alias meg zajszerű amit nem lehet se kenni se tömöríteni.
Nem szeretem az mmo-kat, nekem elég lenne ha egy Mass Effect Andromeda-t nem kaszáltak volna el egy még csúfosabb Anthem MMO javára, hanem az Andromedahoz lett volna content, meg az kb szerintem etalon is hogy PS4-en az mit hozott ki a hardwareből, az egy elég jó lightmap render volt és gyors meg vertikális gameplay. Ráadásul Titanfall helyett is lett starwars, ami totális kreativitás csőd. -
Vanek úr #18 Majdnem (vagy pontosabban: még nem). Az NVIDIA hivatalos ajánlata az új VGA mellé a 850W-os tápegység. Bár ha így emelkednek a procik fogyasztásai is, akkor viszont hamar elérhetjük ezt a szintet is. -
#19
![]()
-
#20
450W
Baszki, ebből megvan a téli fűtés :D -
#21
![]()
-
kvp #22 "ez vállalhatlatlan képminőség és zajos képet nem lehet tömöríteni, és mindig lesz zaj mert erőforráspazarlás supersamplinges képet számolni, az alias meg zajszerű amit nem lehet se kenni se tömöríteni."
Eloszor is a kepminoseg a savszelesseg fuggvenye. Nekem egesz jol elment 1200p-ben, bar maodpercenkent kozel 40 megabitet hasznalt folyamatosan a downlink iranyban.
Masreszt az mpeg tomorites es minden hasonlo (ideertve a google vp9-et ami a stadia alatt van) alapvetoen a tomorites mellekhatasakent egy full scene antialias-t tesz minden kepre, marmint ha a tomorites soran a saveszelesseg hianya miatt adatot dob el. Egyebkent meg annyi tortenik, hogy a szerveren generalt kepeket vp9 stream-be tomoriti, majd a bongeszo kesleletes nelkul dekodolja, mintha egy sima videokonferencia lenne. Ha menet kozben csokken a savszelesseg, akkor a rendszer adaptivan csokkenti a kepminoseget is, egeszen 1/64-ed kepminosegig. Az mar tenyleg ronda, de konnyu ellene vedekezni, stabil es vesztesegmentes szelessavu kapcsolat kell, konstans ping-el.
Tehat:
- alacsony ping: alacsony input es display lag
- alacsony csomagvesztes: keves kephiba
- magas savszelesseg: magas kepfelbontas es framerate -
Sir Cryalot #23 "Nekem egesz jol elment 1200p-ben,"
Nem valószínű hogy annak sok köze van a monitorkábeles 1200p-hez. Főleg ami a single pixeleket illeti, amitől 1200 az 1200. "mellekhatasakent egy full scene antialias-t," aligha teszi rá ha nincs subpixel detail amit MSAA meg SSAA tud.
Egy ilyen mosást tesz rá amitől a single pixel odalesz (pedig az aliasos kép két képkocka közt össze tud adódni ha nincs szétmosva, de utána nem tud összeadódni)
és az a mosás is 2D.
Utoljára szerkesztette: Sir Cryalot, 2022.09.22. 22:11:17 -
bdzsana #24 Hát ezen a területen már nagyon ráférne egy szabályozás az iparra. Ha a porszívók fogyasztását le tudták korlátozni, akkor ezt is ideje lenne már. Meddig lehet vajon még ezt az irányt folytatni? -
Sir Cryalot #25
Játékfejlesztőspécé, unreal5, 36fps olyan jelenetben ahol semmi nem történik, és alias (pixel shimmer) LOL. -
#26
Ilyen elkent homályban éppen a fényeket és árnyékokat nem lehetett jól szemügyre venni. -
Sir Cryalot #27 Nem is kell mert garantáltan rosszabb mint a prerenderes. Meg azt is ki kéne használják ha félhomály van mégis szarul fut. 2011-es RAGE hangulatosabb meg 120+ fps MSAA-val.
Utoljára szerkesztette: Sir Cryalot, 2022.09.24. 18:25:52 -
Sir Cryalot #28 -
Sir Cryalot #29 Szerintem ez még a CD projekt üdvöskéjét is üti, rtx ide oda.
