Keresés

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

  • Abu85

    HÁZIGAZDA

    válasz TTomax #41 üzenetére

    A CF-nél láttam, hogy működik a másik kártya is, de nem hajtja ki a belét. Igazából mindegy, mert nem nagy az igénye a játéknak, hiszen egy belépőszintű VGA elbánik a max grafikával. A gondot a textúrák átmásolása jelenti ott is, a VRAM és a rendszermemória között.

    Egyre több játék lesz jelenetlimittel szinkronizálva. Ez egy nagyon egyszerű és hatékony módja annak, hogy a komplex rendszerek egymással szinkronban működjenek. A kérdés a jelenetlimit sebessége, de szerintem a 60 fps az bőven jó, láttunk már 30 fps-t is limitként.

    Nem a szinkron miatt bukott a Rage, egyszerűen Carmack elszámolta magát. Ez volt a probléma. A megatextúrázás szoftveres formában nem működik jól PC-n. Konzolon még elmegy, mert ott nagyon mély hozzáférést kapsz a hardverekhez, de PC-n iszonyatosan nehéz ezt a rendszert megfelelően működtetni. Az új IDTech 5-be már épített PRT-t, és fogadkozik, hogy azzal minden rendben lesz.

    (#42) siriq: Függetlenül az iróniától, az szerintem már évek óta világos, hogy a konzol a játékfejlesztők szemében a PC előtt van. Aki azt mondja, hogy csak a PC-s port számít hazudik, szimplán azért, hogy elnyerje a PC-sek szimpátiáját, ezzel a teljes bevételből nem csak 2-3%-ot, hanem 5-6%-ot is kitesz majd a PC-s eladás. A gaming biznisz egy bazi nagy üzlet, és minden üzletben a legjobban tejellő területek az elsődlegesek, jelen esetben a konzol.

  • Abu85

    HÁZIGAZDA

    válasz huskydog17 #38 üzenetére

    Az IDTech 5-tel is lehet alkotni majd, mert látod, hogy amit Carmack kitalált már ott van a DX-ben Tiled resources fedőnéven. Tehát ez a jövő valóban, csak nem olyan formában, ahogy a Rage-ben van megoldva, de az elv az zseniális. Az IDTech 5-tel viszont nem sokan fognak alkotni, mert a Zenimax nem engedi licencelni. Házon belül használják majd fel. Lényegében ezért vették meg az ID-t.

    (#39) TTomax: A Rage-nél az SLI és a CF nem működik jól. Ezt már az elején lehetett tudni. De egyre több ilyen játék lesz.
    A 60 fps a szinkronizációhoz kell. Carmack így csinálja, illetve maga ez a fix érték határozza meg, hogy a motor csökkentse-e a felbontást pár frame erejéig, ha lassulás van. Ez a koncepciós működés nyilván fontos, ha esetleg nincs elég erőforrás a Rage futtatásához, mert jelenetlimites a játék.

  • Abu85

    HÁZIGAZDA

    válasz huskydog17 #35 üzenetére

    Nem hiszem, hogy a motor maga butább lett, hiszen csak kiegészült. Arról lehet szó, hogy a játékhoz nem építették be a napszakváltást, és a többit, ami butult. Ez biztosan valami játékdizájnra vonatkozó döntés volt. Ettől a motor még tudja.

    Az OpenGL-nek már vége a fejlesztők szemében. A DX sokkal gyorsabban fejlődik, és sokkal jobb fejlesztőkörnyezetek is vannak hozzá. Csak azt érdekli az OpenGL, aki Linuxra is elkészíti a játékot. Egyébként jellemző, hogy a mai motorokba raknak egy OpenGL rendert is, de nem dolgozzák annyira ki, mint a DX-et, így azt a végtermékeknél letiltják.
    Az OpenGL az sosem fog akkorát előrelépni, mint a DX a 9->10 váltásnál. Ez a fejlesztők gondja. Az OpenGL 3 volt nagy ígéret és semmi nem lett belőle. Azóta egy vegetálás van, és aki az OpenGL 3-ra még vért, az az eredmény láttán megértette, hogy a DX-szel az MS be mer vállalni sokkal radikálisabb újításokat, még úgy is, hogy a kompatibilitás megszűnik. Az OpenGL ilyet sosem fog bevállalni. De a Khronost nem is hiszem, hogy érdekli, hogy a játékfejlesztők nem számolnak az OpenGL-lel.
    Az, hogy a DBT a DX-ből még mindig hiányzik, nyilván nem jó, de ezt bőségesen ellensúlyozza mondjuk az új Tiled Resources, meg még pár extra az OpenGL-hez képest.

    (#36) morgyi: A Rage-nek teljesen más gondja volt. Carmack elnézte a hardverek fejlődését, és arra számított, hogy mire kész lesz a Rage, addigra már mély integráció lesz mindenhol. Figyeld meg majd a Kaveri APU-t. A sample-ökön nulla pop-up van és nagyon gyors az egész (a VGA-k messze vannak tőle). Az a titka, hogy nem kell a kikódolt textúrákat másolni a rendszermemóriából a VRAM-ba, mert a Kaveri esetében a driver képes egy olyan módot használni, amikor az IGP nem használ külön VRAM-ot a rendszermemóriából, hanem szimplán abba dolgozik. Teljesen koherensen megosztott rendszermemória kell igazából a Rage-nek, nem speckó OpenGL driver. Maga a pop-up is azért van, mert a tile-ok előtöltését is a processzor próbálja intézni, csak egyszerűen még, ha gyorsan meg is határozza, hogy milyen adatokra van szükség, azokat még ki kell kódolnia, és át kell másolni a VRAM-ba. Az adatmásolás, ami nagyon fáj.

  • Abu85

    HÁZIGAZDA

    válasz huskydog17 #31 üzenetére

    A Far Cry 3-nak a motorja nagyon speciális. Erre a motorra nem épít több Ubi játék. Az SC Blacklist is egy UE2.5 még az alapokat tekintve, míg a többi játék az Anvilt használja. Kivéve a Watch Dogs, az kapott egy sajátot. Disrupt lett a kódneve, de azt next-genre tervezték.
    Az Ubi az új címeket eleve úgy tervezi, hogy a PC-re a nextgen konzolos effektek ne legyenek átemelve. Ha esetleg valami nem oldható meg időre, akkor az az effekt szimplán kimarad PC-n, és helyette használnak valami mást. Ez nem rossz dolog. Az Ubi a nagy átlagot nézi. Mégis hány embernek van GCN-es Radeonja, ami elbír 64 UAV-t is a futószalagon? A játékosok kis része jön így számításba. Most, ha elkezdik lehozni a compute shadereket a Watch Dogs PS4-es verziójáról, akkor kb. 15 effektből jó, ha hármat be tudsz kapcsolni DX11-es kódban. Persze lehet DX11.1-re építeni, csak kevés felhasználónak van ezzel kompatibilis hardvere, még Keplert is igen kevesen vettek ahhoz képest, hogy mennyien használnak még, valami előző generációs Radeont, vagy GeForce-ot. Persze ez az egész egy kompromisszum lesz, de aki a legjobb grafikát akarja, az vesz egy PS4-et és kész. Aki PC-n akar maradni, az meg valahol elvárja, hogy ne kelljen már egy játékért a legújabb VGA-ért rohanni. Az Ubi számára ez koncepció, és nem kicseszés a felhasználókkal. Amíg nem kínál az NV normális DX11.1-es VGA-t, addig mindenképp opció kerülni a komplex shadereket.

    Az Ubi nem fog senkit sem előtérbe helyezni. Nekik elsősorban a reklámpénzek kellenek. Üzletileg kellemes, ha a játékodat egy VGA-gyártó reklámozza. Ez egy nagyon szimpla egyezmény. Persze benne van azért olyan üzleti érdek is, hogy az Ubi tesz majd szívességet az NV-nek, így nyilván nem csak saját akaratból próbálják a PC-s portokból eltávolítani a compute shadereket, de például a Nixxesnél ugyanígy megvan, csak ott mindent compute shaderre írnak át. Ettől mindig érdek, hogy a program jól optimalizált legyen minden lehetséges hardveren.

    A partnerprogramokat nem favorizálják, de most van két cég, akik szánnak egy bizonyos büdzsét a partnerprogramokra. Nagyon valószínű, hogy egyik cég sem költ annyit, hogy mindent le tudjanak fedni, tehát az AMD és az NV most kötött egy csomó szerződést a jövőre, de nyilván nincs se pénzük, se erőforrásuk az összes kiadóval komplett reklámszerződésre és stratégiai egyezményre. A fejlesztői támogatás az egy külön dolog itt. Mindenki támogat mindenkit, de a reklámba pénz kell, így ott dönteni kell, hogy kivel jársz jobban. A nagy kiadók tekintetében az AMD az EA-t választotta (a Square Enix mellé), míg az NV az Ubisoftot (a Capcom mellé). A kevésbé nagy kiadók tekintetében pedig vegyes a dolog. Egyszerűen nincs reklámpénz mindenkire egyik oldalon sem. Most azt meg nem mondom, hogy ezek az üzletek mi alapján születtek meg. Nyilván osztottak-szoroztak és tető alá hozták őket.

    (#32) huskydog17: Sajnos a DX API-ban ez a DBT egy hányattatott sorsú dolog. A DX9-be bekerül a DX10-ből eltűnt, aztán semmi egy darabig, majd most az AMD csinált rá egy igen specifikus kiterjesztést a GCN-es Radeonokhoz, hogy más ezt ne is támogathassa. Ezen nincs mit szépíteni, ez egy problémás dolog, és az MS-nek már rég szabványossá kellett volna tennie, akár csak opciós lehetőséggel is. Valószínű, hogy a következő, esetleg DX11.3-as frissítésben lesz egy szabványos megoldás rá.

  • Abu85

    HÁZIGAZDA

    válasz huskydog17 #28 üzenetére

    A Far Cry 3 az speciális esett. Nekik annyira sok problémájuk volt a sebesség/minőség aránnyal, hogy mindenképp szükségük volt a compute shaderben írt effektekre. Ezért nem TWIMTBP játékról volt szó, mert az NV ezekben nem segített nekik. Az új játékoknál erre nem lesz majd szükség.

    Eddig rengeteg effektet átmentettek a cégek a konzolról. Azokat egészítették ki új effektekkel. A jövőben a konzoljátékokhoz compute shadereket írnak, mert sokkal gyorsabb a feldolgozás, de ezt az Ubi nem hozza majd át a PC-re, hanem más effektekkel helyettesíti azokat. Ez egyfajta stratégia. A konzolon a számos next-gen játék a teljes futószalagra minimum 40, de inkább 100 körüli UAV-t használ. PC-n a DX11 8 UAV-t enged meg. Vagy DX11.1-hez kötik az egyes effekteket, vagy virtuális UAV-kkel trükköznek, vagy más algoritmust keresnek ugyanannak az effektnek az implementálására. A leggyorsabb megoldás a DX11.1-hez kötni az effektet, de nem mindenkinek van DX11.1-es VGA-ja. A virtuális UAV szintén korlátokat szab, ráadásul lassú is. Ha már dolgozni kell, akkor PC-re érdemes új alapokra építeni az effektet. Nem valószínű, hogy eléri a konzol minőségi szintjét, de legalább a legtöbb hardveren futni fog. Ez az Ubi koncepciója. Tekintve, hogy a partnerük az NV, nekik mindenképp olyan elven kell majd dolgozni, hogy a PC-s port ne használjon sok UAV-t. Ennek gyökeres ellentéte lesz majd a Square Enix Nixxes csapatának a koncepciója, ők lementik a konzolos effekteket PC-re. Ha kevés lesz hozzá egy DX11-es API-t használó hardver, akkor az effektek aktiválásánál limiteket szabnak.

  • Abu85

    HÁZIGAZDA

    válasz huskydog17 #25 üzenetére

    A HBAO+ is elég jó. Nem mellesleg az Ubisoft nem rak compute shadereket a játékaiba, és a HDAO compute shadert használ. Az Ubi PC-s portok esetében más eljárásokat használ majd, mint a nextgen konzoljátékokra.

  • Abu85

    HÁZIGAZDA

    válasz Xirtam #11 üzenetére

    Tök mindegy a dolog. Mellesleg valakinél nem üti ezeket a BF4, akinél meg igen az vesz Radeont. Igazából ami fontos az NV-nek, hogy a gyártók az x86-ot váltsák le ARM-ra. Ez a következő év legfontosabb marketingszempontja, mert az érkező Maxwell nagy újítása az ARMv8-as virtuális memória elérése a grafikus vezérlő oldaláról. A komplett NV platform kap majd IOMMU-t, és a grafikus vezérlő kap egy elég komoly MMU-t, amihez lesz ARMv8-as TLB. Az ARM alapvetően ott jön szerephez, hogy ilyen host processzor szükséges a Maxwell összes új képességének kihasználáshoz. A rendszer működni fog x86 processzor mellett is, csak minden extra képesség, amit beépítettek inaktív lesz.
    Ami látszik, hogy az NV a Parker SoC és a Maxwell párosításával lemásolja a nextgen konzolokat, így összejön egy olyan komplett platform, ami képes majd minden új funkciót megoldani a játékokban. Az MS ARM-hoz húzása mellett ez opciós lehetőség a kitörésre. A másik párosítás pedig a Kaveri és a GCN lesz, ami szintén ugyanazt kínálja, mint a konzolok, csak az x86 kompatibilitás mellett. A nagy kérdés, hogy utóbbi a játékosoknak mennyit ér.

  • Abu85

    HÁZIGAZDA

    válasz rocket #20 üzenetére

    A FrostBite 3 úgy használja a DX11.1-et, ahogy írod. Repi már mondta, hogy semmi képminőségbeli hátrány nem lesz a DX11-es kódhoz képest, csak valamivel gyorsabb lesz a kód DX11.1-ben (egyes funkciókat DX11-es hardverrel is el lehet érni). A Dx10-es kódban lesz képminőséghátrány, de ez nem probléma manapság.
    Ami extra, hogy használja az AMD DX11.1-es DBT kiterjesztését is, amit csak a GCN hardverek érhetnek el. Egyébként szinte mindegyik hardver támogatja ezt az elmúlt 5 évből (OpenGL alatt ez a GL_EXT_depth_bounds_test, és az OpenGL 1.3 specifikáció része), csak nagyon specifikusan van megírva az egész. Úgy, hogy kihasználja azt a képességet, hogy a GCN a 24 bites depth formátumokat belsőleg 32 bitesként reprezentálja. Ezzel kizártak minden hardvert, ami nem így működik. Ez eleve egy megkérdőjelezhető döntés, hiszen lassan 6 éve erre a funkcióra vágynak a fejlesztők a DX-ből (ugye a DX9-ben implementált kiterjesztés nincs meg a DX10-ben), és egyelőre csak specifikus kiterjesztést kapnak. Most lehetőség lett volna, hogy ez a kiterjesztés mindenki által támogatott legyen, csak ilyen specifikusan implementálva nem lesz az. Ez már eleve egy szemétkedő fegyver. És ez észrevehető a nemrég kiadott GE játékokon is, mert nekem ne mondja senki, hogy az UE3-at évekig sikerült jól paraméterezni, és lagok nélkül megy minden hardveren, és most véletlenül annyira rosszul paraméterezték, hogy az NV-seknek nem árt init szerkeszteni, ha nem akarnak néha 50 ms fölötti frame időt. Ez bullshit egy olyan motortól, aminél ilyen hülye működést még nem láttunk. És tök véletlen, hogy pont akkor, amikor Roy Taylor, meg az átcsábított régi TWIMTBP kollégái munkába álltak.
    A másik extra, amit az FrostBite 3 használ az a CDB. Ez csak egy opcionális funkció a DX11-től kezdve, tehát nem kötelező támogatni. Tudtommal eddig csak a Dragon Age 2 használta. Ezt az AMD DX10.1-es hardverektől kezdve támogatja. A többiek driveres emulációt használnak rá.
    A többi dologról még nincs adat a FrostBite 3 kapcsán, de Repi tart majd egy előadást novemberben az APU13 konferencián. Azt nem tudni, hogy miről beszél majd, de gaming fókuszú. Tulajdonképpen idén ő lesz a HSA-nak a független szakértője és elmagyarázza mire tudná, vagy esetleg már tudta használni. Gyakorlatilag azt teszi majd, amit a múlt évben Tom Malloy az Adobe-tól.

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

Hirdetés