Új hozzászólás Aktív témák

• #49376 T.Peter őstag huskydog17 #49372

  Új Válasz 2025-07-18 09:30:58 #49376

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  T.Peter

  őstag

  válasz huskydog17 #49372 üzenetére

  Az indie fejlesztok is belenyulnak, ha fizetnek Epic Pro Support-ert akkor meg meg az Epic is segit nekik. Ehhez nem kell kimondottan motor programozo, nalunk sem volt, megis belenyultunk, mondjuk nem emiatt. [link] Ezt meg nezd meg ujbol, hogy lasd, mik a megoldasok arra, hogy csokkentsek vagy megszuntessek a stutter-t.

  A single-threaded kod sem mindenre ertendo, nem veletlen, hogy 5.6-ra atirtak egy csomo reszt ugy, hogy megjobban a worker thread-eket hasznaljak. Azzal egyetertek, hogy ide nem az 5.6-tal kellett volna eljutni.

  "Tehát az, hogy a traversal akadások nem a motor hibája, mint ahogy állítottad, szimplán nem igaz."
  Ilyet nem irtam. Azt irtam, hogy a megoldas a donteshozokon mulik. Ettol meg a problema az engine miatt letezik, de az, hogy ez nincs kezelve egy adott jateknal, az mar a studion mulik es az Epic is tudna ebben segiteni.

  Az egyaltalan nem oke, hogy ez az egesz idaig fajult, mert mindenkinek art, viszont objektiven nezve nem jelentheto ki, hogy mindenert az Epic a hibas. Viszont ezt az egeszet mar regen meg kellett volna oldaniuk, kozosen, a studioknak az Epic-kel.

• #49375 Abu85 HÁZIGAZDA huskydog17 #49372

  Új Válasz 2025-07-18 09:04:24 #49375

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Abu85

  HÁZIGAZDA

  válasz huskydog17 #49372 üzenetére

  Nem kell átírni a motort, egy sornyi kódot nem szükséges beleírni, mert az UE5 gyárilag szállított megoldásokat kínál bizonyos problémákra. Csak az Epic nem tudja, hogy az egyes stúdiók milyen játékot csinálnak, tehát a stúdióknak kell megválasztani azt a paraméterezést, amivel jól fog működni az UE5.

  Például a PSO cache egy véleményes dolog. A funkciót az UE5 támogatja, de automatikusan nem aktív, mert nem mindig jó, ha az. Viszont, ha azt akarod, hogy aktív legyen, akkor az r.ShaderPipelineCache.Enabled=1 és r.ShaderPipelineCache.StartupMode=3 parancsokkal bekapcsolhatod, majd a PSO Collectorral szabályozni kell a begyűjtés módját, végül pedig a PipelineCacheToollal gyorsan betölthető formátumra lehet konvertálni a kódot.

  Ezt a procedúrát az Epic sosem fogja default engedélyezni, mert nem tudja, hogy mit fogsz csinálni az UE5-ben. Ha mindenre gyárilag engedélyeznék, akkor az iszonyatosan sok PSO kombinációt jelentene, ami akár több gigabájt is lehet. Nagyon extrém esetben több 10 GB is. Gondolj bele, hogy ezt milyen sok idő lenne legenerálni. Nemhogy kávézni mehetnél ki a játék indításakor, vagy minden driverfrissítéskor, hanem megfőzhetnéd a teljes heti menüt, és jó eséllyel még várnod kellene.

  Bónusz gond, hogy fejlesztés közben egy ilyen működésű motor nagyon sokat rontana a helyzeten, mert folyamatosan változik a tartalom. Gyakorlatilag mindig újra kellene generálni az egészet, ami jól kibaszna a kisebb fejlesztőkkel, mert fel kellene szerelkezniük 192 magos EPYC procikkal, hogy a fejlesztési idő 80%-a ne abból álljon, hogy várják a generálást.

  A legjobb módszer a fentiek miatt az, ha egyénileg meg tudja határozni a fejlesztő, hogy mit gyűjtsön be a rendszer, mert így minden szempontból optimális lehet az eredmény. És erre szánniuk kell némi időt az életükből, mert az Epic sosem fogja megcsinálni helyettük. Az Epic csak eszközt tud adni nekik arra, amivel optimalizálhatják a készülő játékot minden aspektusból.

  Az Epic nem tud mit kezdeni a köztudattal, ami összekapcsolja az UE5-öt a stutterrel. Nyilván elkezdhetik elmagyarázni az embereknek, hogy miért van default így beállítva az UE5, de az emberek döntő többségének halvány fingja sincs arról, hogy mi az a shader, így nem értenék meg a döntéseiket. Egyszerűen az egyes akadásokat a játékot fejlesztő stúdiónak kell kezelnie. Erre az Epic nem és sosem lesz képes, amíg a grafikus API-k működése olyan jellegű, amilyen.

  És elárulom neked, hogy az Epic foglalkozik nagyon is a problémával. Az ARM-tól tudom, hogy olyan intenzíven benne vannak egy univerzális megoldás keresésében, hogy nagyon kardoskodnak azért, hogy legyen egy egységes vISA a gyártók számára, ami lehetővé teheti a mostani bonyolult shader fordítási rendszer mellőzését, és konzolszerűvé válna az egész működési modell. És ebben egyébként a Qualcomm és a Samsung eléggé támogatja őket, méghozzá úgy, hogy hajlandók lennének a HSAIL-t default vISA-jukká tenni. Csak az a gond, hogy az AMD, az Intel és az NVIDIA meg nem. Ebben nyilván az AMD állásfoglalása a szép, mert ők ezt úgy utasítják vissza, hogy közben HSA tagok. Jó persze megértem, hogy miért ez most a hozzáállásuk, ők a Sony-val dolgoznak egy saját megoldáson, amit a többiek nem kapnak meg.

• #49374 BerserkGuts addikt huskydog17 #49372

  Új Válasz 2025-07-18 06:56:27 #49374

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  BerserkGuts

  addikt

  válasz huskydog17 #49372 üzenetére

  Igen egy magos használat amikor már intel belépő szintje is lassan 10 magos lesz.
  Elő kéne venniük a tökeiket és bevállalni hogy húznak egy határt nem kell minden konfigon futnia terelni kellene a népet az új felé mert probléma az hogy mindenkinek meg kell felelni pedig ez nem fog menni.

  Na mindegy majd talán az új konzolok változást hoznak kb 2017 és a ps4 elmegy a pî. nyugdíjba.

Új hozzászólás Aktív témák