- Sweet.tv - internetes TV
- Milyen routert?
- Anyagi katasztrófára figyelmezteti az Apple-t a brit média
- Mesterséges intelligencia topik
- SkyShowtime
- foobar2000
- Aliexpress tapasztalatok
- Telekom otthoni szolgáltatások (TV, internet, telefon)
- Kodi és kiegészítői magyar nyelvű online tartalmakhoz (Linux, Windows)
- Windows 10
- bb0t: Gyilkos szénhidrátok, avagy hogyan fogytam önsanyargatás nélkül 16 kg-ot
- Luck Dragon: Asszociációs játék. :)
- antikomcsi: Való Világ: A piszkos 12 - VV12 - Való Világ 12
- GoodSpeed: Új alaplap, vagy BIOS frissítés után beállítandók III. PBO - Thermal Limit lvl2
- Lalikiraly: MSI Cyborg 15 - Tényleg Kiborg.
Új hozzászólás Aktív témák
-
Abu85
HÁZIGAZDA
Nem számít. A probléma abból adódik, hogy az alap kódot folyamatosan optimalizálják. Egyre több dolog kerül felhasználásra az NVAPI-ból és az AGS-ből. De az a Frostbite fejlesztési modell hátrányos, hogy ha valamiben nem tudnak dönteni a GeForce-nál, akkor elfogadják, hogy úgy működik a hardver, ahogy a GCN. Az ilyen döntések a Pascalnak helyenként hátrányosak lehetnek. A Maxwell ebből a szempontból csak szerencsés.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#30178
Abu85
HÁZIGAZDA
->Raizen<-
#30172
Abu85
HÁZIGAZDA
válasz
->Raizen<-
#30172
üzenetére
Több fejlettebb motor is van jelenleg a Frostbite-nál. A Nitrous, a Dawn Engine és az id tech 6 is az. A Frostbite viszont egy nagy fejlesztés előtt áll, tehát a BF1-be került verzió sok kényszerű döntést tartalmazott. Eredetileg az volt a terv, hogy csak WDDM 2.0 alatt lesz üzemképes, de aztán az EA visszakozott és nagyon sok olyan döntést kellett hozni, ami a hatékonyságot csökkentette. Valszeg a WDDM 2.0 only verzió majd a következő lesz, aminél végre jön a régóta várt light-tree leképező.
Technikailag egyébként messze a Nitrous a legjobb. Teljesítményben és skálázhatóságban a közelében sincs semmi. Ebben mondjuk nagyban segít az is, hogy egyetlen másik motor sem használ texel shadinget. A továbbfejleszthetőség szempontjából is a Nitrous alapja a legkellemesebb, mert függetleníthető az árnyalási fázis, amit ki lehet rakni async compute-ba. Ez lesz a Nitrous 2. A többi motor ezt nem tudja megoldani.
A Dawn Engine technikailag nagyon jól kezeli a geometriát. Ebben ver magasan mindent, és már készül a Deferred+ leképező hozzá, amivel még durvább lesz.
Az id tech 6-nak nincs igazi különlegessége. Egyszerűen csak marha gyors, tipikus KISS alap.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
A Nitrous eléggé terjed, hiszen a Stardock már 7 projektet futtat rajta. Komolyabb licencre nem számítanék, mert rendkívül drága. Az ipar 95%-a nem tudná megfizetni.
A Dawn nem licencelhető. Ezt az EIDOS Montreal magának csinálta. Kb. olyan a helyzete, mint a Frostbite-nak. Ez lesz az összes EIDOS Montreal játék alapja, de más nem kaphatja meg.
(#30179) szmörlock007: Azok túl PS4 specifikusak. Egy csomó olyan dolgot csinálnak, amelyek multiplatform szinten nem kedvezők.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#30185
Abu85
HÁZIGAZDA
huskydog17
#30184
Abu85
HÁZIGAZDA
válasz
huskydog17
#30184
üzenetére
Megkapta, de PC-hez, egészen konkrétan sok memóriához vannak tervezve az assettek. Ezekkel nagyon nehéz mit kezdeni. Emiatt mindegyik konzolon virtuális memóriával fut a játék, holott az AAA játékoknál egyáltalán nem ez a jellemző. Ezt a módot leginkább az indie játékok választják.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
Locutus
#30186
üzenetére
Ez előre látott helyzet volt. Régóta tudni lehet, hogy ilyen lesz a port. Egyszerűen nincs pénzük elölről kezdeni. Még arra sem volt pénzük, hogy befejezzék a játékot. Kiadták sima alpha állapotban.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#30189
Abu85
HÁZIGAZDA
huskydog17
#30188
Abu85
HÁZIGAZDA
válasz
huskydog17
#30188
üzenetére
Dehogynem gyorsabb. Azért kapta meg, mert kellett hozzá, hogy egyáltalán értékelhető sebességgel fusson a játék. Gyárival jó ha meglenne a 15-20 fps.
A virtuális memória ahhoz kell, hogy az OS kezelje a memóriát, mert az ARK motorja olyan régi, hogy nincs felkészítve arra, hogy közvetlenül kezelje azt, illetve nem elég az 5-6 GB közötti memória a futtatáshoz. Amikor elkezdték a játékot tervezni, akkor nem multiplatform projektként láttak hozzá, hanem PC-sként. Innen konzolra portolni két lehetőség van. Elfogadják, hogy szarul fog futni, vagy nulláról újrakezdik. Na most mi egy olyan stúdióról beszélünk, akik konkrétan alpha készültségi szinten adták ki a játékot PC-re is, mert elfogyott a pénz.
A fix hardver abból nyeri a hatékonyságát, hogy nem az OS kezel sok mindent, hanem maga az alkalmazás. Ha ezzel nem él a program, akkor a konzol előnye semmis. Ez független az API-tól.
A Microsoft és a Sony a közvetett memóriaelérést leginkább a pici indie címeknek szánja, ahol igazából mindegy, hogy az OS hatalmas többletterheléssel kezeli a hardvert, mert alig csinál valamit a program. Az AAA projektek szinte kivétel nélkül a közvetlen memóriaelérést használják.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#30191
Abu85
HÁZIGAZDA
huskydog17
#30190
Abu85
HÁZIGAZDA
válasz
huskydog17
#30190
üzenetére
Nem lehet lemérni, mert régi az ARK PC-s portja által használt leképező. Olyannyira, hogy akkor még a konzolokat nem is támogatta a motor. Azt alakítják folyamatosan és a motor más részeit cserélgetik a moddolhatóság miatt. Viszont a leképezőhöz nem nyúltak már lassan két éve, mert sok galibát okoz, és át kellene alakítani rengeteg dolgot miatta, amire se idő, se pénz. Ezért sem lett a beígért DX12-ből semmi, mert arra akarták cserélni a felhasznált RHI-t, csak közben kiderült, hogy nem lehet, ugyanis az UE4 annyira átalakult a DX12 támogatással, hogy nem lehetett egy szimpla pipával DX12-síteni, igen komoly munka kellene hozzá.
Xboxon és PS4-en csak azért fut, mert a Microsoft és a Sony átírta, hogy egyáltalán támogassa a gépeket. A Microsoftnak azért volt egyszerűbb a dolga, mert nekik van egy saját UE4 verziójuk, így sok kódot tudtak abból átemelni. Ha szimplán ráengednéd a PC-s ARK leképezőjét a két konzolra, akkor az meg sem nyikkanna rajtuk, annyira régi. Nem léteztek még ezek a gépek, amikor az érintett RHI-t elkezdte kidolgozni az Epic.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#30194
Abu85
HÁZIGAZDA
huskydog17
#30193
Abu85
HÁZIGAZDA
válasz
huskydog17
#30193
üzenetére
Annyi van, amit mondtak a HPG-n, de az nem konzolos mérés.
Csak azoknak egyszerű, akik a 4.7-es RHI-t használtak. Ezalatt igen komoly munka lehet a váltás. Ezért nen kapcsolgatják be a támogatást a régi UE4 játékokra. Annak a checkboxnak feltételei vannak.
A Caffeine modernebb RHI-n kezdett, neki egyszerű voltMint írtam, muszáj átírni a konzolokra, mert az UE4 az Xbox One és a PS4 támogatását egy későbbi RHI-ben vezette be.
Szerintem a Switch támogatása jelen formában nem megoldható. Ahhoz mindenképpen egy teljes engine update kell. Azt bevállalva még realitás is lehet egy Switch port, de komoly munka lenne.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#30198
Abu85
HÁZIGAZDA
cskamacska
#30197
Abu85
HÁZIGAZDA
válasz
cskamacska
#30197
üzenetére
Nem valószínű, hogy elbúcsúznak tőle. Raja a visszatérése óta nem volt hosszabb ideig szabadságon. 2013 tavasza óta az hosszú idő. Hiába a munkamánia, az ember négy és fél év után vágyik legalább két hónap pihenésre. Persze ezt egy nagy cégnél nehéz megtenni vezető szerepkörben, de a szabadság az jár. Most ez egy ideális alkalom, mert úgy sem jön semmi decemberig, amihez ő kellene. Az vesse rá az első követ, aki négy és fél év munka után nem menne el ennyi pihenőre. Nyilván a helyi blikkek számára ez szenzáció.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
solfilo
#30199
üzenetére
Megegyezés kérdése. Azért tegyük hozzá, hogy négy és fél évig nem volt hosszabb szabadságon.
Indiában esküvőn volt, illetve Bollywoodban ügyködött. Utóbbi munka volt igazából. Van egy indiai cége Raja-nak, ami a technológiát rakja Bollywood alá. Nyilván ha Hollywoodnak lesz AMD stúdiója, illetve London is kap majd sajátot, akkor Bollywood sem fog kimaradni. A bejelentés csak idő kérdése. Ez számít, hiszen maga a stúdió leginkább egy rakás Project 47 egymás mellett, amelyeket bérelni lehet. Ha valahol erre igény van az az indiai filmgyártás, ahol egy Project 47 dollármilliós ára nem éppen megfizethető.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
Raymond
#30204
üzenetére
Jó írás lett.
Még a Blikkben és a Borsban sem szokták az egyes mondatfoszlányokat így megmagyarázni.(#30205) Raggie: Szerintem Ockham borotvájának is jól megmutattuk. El is vonult a sarokba pityeregni.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
Raymond
#30207
üzenetére
Nagyon régen olvastam csak a Blikket és a Borsot, szóval az efféle mondatfoszlányokból kinyert magyarázatokhoz tényleg nem értek. De szerintem jó írást közöltél. Tisztán látszik, hogy ez a te tereped.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Volt is egy hír róla, amiben át van rágva az elejétől a téma. [link]
(#30213) Egon: Miért kellene magyarázni bármit is? Egyelőre sosem sikerült még rámutatni, hogy a kifogásolt hírekben mi nem tény.
Pedig annyiszor vitáztam volna róla, de sosem sikerült összehozni. 
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
FLATRONW
#30216
üzenetére
Ez ellen egyszerűen lehet tenni. Konkrétan meg kell mutatni az adott hírben, hogy mi nem tény. Azt nem lehet kimagyarázni.
(#30218) Egon: [link] - iit válaszoltam a linkelt hsz-edre. Persze el is kell olvasni.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Most is így lesz. A DXIL 1.0-t nagyon gyorsan követi majd az 1.1 és az 1.2. Szóval a shader modell 6.0 befutásával gyorsan jön a 6.1 és a 6.2. A boldog békeidőknek hamarosan újra vége. Azért lassult le az egész, mert leváltották az fxc-t és a D3BC-t. Teljesen új alapokra helyezték az infrastruktúrát. Annyira jó alapokra, hogy az új dxc sokkal több dolgot támogat. Akár SPIR-V-be is befordítja a HLSL kódod.
Akinek anno a shader modellek gyors fejlődése nem tetszett, annak a PC-s közeljövő sem fog tetszeni.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#30374
Abu85
HÁZIGAZDA
huskydog17
#30369
Abu85
HÁZIGAZDA
válasz
huskydog17
#30369
üzenetére
Ebben semmi csoda nincs. A Project Cars 2 az egy az egyben a Project Cars. Semmit sem fejlesztettek rajta technikailag. Persze ennek az oka a Bandai Namco Entertainment. Ők döntötték el, hogy kiadják ugyanazt még egyszer.
Eredetileg egyébként ez a Madness Engine új verziójával jött volna, amit anno nagyon ígérgettek, hogy DX12 leképezőt is támogat, de nem lett belőle semmi. A Bandai Namco a technikát háttérbe helyezte, és csak tartalmat kért. Emiatt a korábbi motor korlátjai ugyanúgy megmaradtak, így továbbra is tudna jó 30-40%-ot hozni a DX12, ahogy azt korábban ígérték, csak sosem adták ki.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
namaste
#30350
üzenetére
A mai gyári meghajtókban mindben van többszálú optimalizáció. Nem a gyártóknál keresendő a kihasználás hiányának problémája. Ebből még az explicit API előtt tartott egy elődadást Repi. Ő mondta, hogy elméletben nagyszerű az egész, de a gyakorlatban nem működik. A driver elveszi az erőforrást a programtól, kritikus szituációkban lassít, még akkor is, ha enyhébb terhelés mellett gyorsabb, stb. És persze a gyártók implementációja eltérő.
Aki többszálú rendert ír ma az eleve nem választ már DX11-et és OpenGL-t, mert a Vulkan és a DX12 sokkal hatékonyabb megoldást kínál a problémára.
A cégek próbálkoznak sokfelé. Az AMD és az NV is. Csak az AMD úgy gondolta, hogy a DX11 után kialakult egy olyan fejlesztői támogatás, amit ki tudnának használni arra, hogy behozzák PC-re az explicit API-kat. Az NV valószínűleg átgondolta ezt is, csak ők azt hitték, hogy még ha csinálnak is egy új explicit API-t, akkor sem tudnák átverni az akaratukat a Microsofton. Az AMD csak kockáztatott, és bejött nekik. Gondolom maguk lepődtek meg rajta a leginkább.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
Puma K
#30357
üzenetére
A GeekBench GPU-ra annyira nem érdemes hallgatni. A Vega 64 1 840 921 pontot hoz benne.[link]
Elég komoly technikai problémái vannak a programnak a háttérben. Még házon belül sem igazán pontos.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#30379
Abu85
HÁZIGAZDA
Petykemano
#30378
Abu85
HÁZIGAZDA
válasz
Petykemano
#30378
üzenetére
Úgy értem, hogy ma a Microsoft és a Khronos is explicit API-t kínál. Ez eléggé bejött így, mert lehetett volna úgy is, hogy az AMD prototípus kódját nem veszi át a Microsoft a DirectX 12 alapjaként, és a Khronos sem volt köteles a Mantle specifikációjából Vulkan API-t csinálni.
Ezekből rendkívül sokat fognak profitálni, miután a DirectX 12 programok átváltanak a bindless-re és ezzel lezárják a GeForce-ok fast path-jainak elérhetőségét. Kevesen tudják, de a GeForce igazából azért gyors DX11 alatt, mert bizonyos rajzolási parancsok nem a main path-on közlekednek. Ezáltal ezeknek a rajzolási parancsoknak a kiadás gyorsabb. A DX12 azonban ezt a lehetőséget elveszi, mert ennél az API-nál a meghajtó nem küldhet grafikai parancsot a hardverbe (ezért is a sebességcsökkenés sokszor a DX11-hez képest). Ezt csak az OS teheti meg, és az OS nem ismeri ezeket a gyorsabb adatutakat. A Microsoft elsődleges célja ezzel pont az, hogy a hardverek a parancsmotor szempontjából legyenek egységesebbek. Amint ez a váltás megtörténik hozzák majd a további OS fejlesztéseket, és akkor a gyártóknak ezek után kell menni. Például dupla általános parancsmotor, ami az Xbox One sajátja, de a Microsoft idővel le fogja hozni PC-be is. Azzal, hogy innentől kezdve a bemenetet ők kontrollálják teljes mértékben meghatározhatják, hogy milyen legyen a hardvere általános parancsmotorja. Vagy felel az igényre egy gyártó, vagy lemarad. A gyártói innovációt teljesen kiveszik az egyenletből az általános parancsmotorra vonatkozóan. Hiába épít akárki akármilyen jót, nem tudja etetni, mert a WDDM 2.x ezt megtiltja.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#30436
Abu85
HÁZIGAZDA
Petykemano
#30389
Abu85
HÁZIGAZDA
válasz
Petykemano
#30389
üzenetére
A fast path-okat igazából a fejlesztők is utálták. Nem volt egységesség a gyártók között a parancsmotor képességei szempontjából. Amit a Microsoft csinál az egy régebbi felvetés megtétele. Az OS fogja a jövőben meghatározni, hogy milyen parancsokat hova küld be a hardvernek, így mostantól mindegyik adatutat ugyanolyan gyorsra célszerű tervezni. Lesz egy kialakított irány ebből a szempontból, amire a fejlesztő tervezhet, és a Microsoft biztosan nem fog kiadni egy Windows frissítést pont egy programok kiadása előtt, ami hirtelen -20%-os teljesítményt eredményez. Aztán jöhet a "game ready" driver.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
namaste
#30391
üzenetére
Itt elég jól elmagyarázzák, hogy nem olyan egyszerű ez, hogy marad idő a CPU drivernek. [link]
Bizonyos sűrűn használt dolgokra az NV egy speciális fast path-ot használ. Ennek az előnye, hogy az általános path-nál gyorsabban oldja meg ugyanazt a munkát. Az NV például régebben mondta egy prezentáción, hogy viszonylag sokat nyernek a konstans pufferre vonatkozó fast path-jukon, amelyet DX11-ben nagyon sokan használnak, de DX12-ben ez nem létező opció. Az OS nem ismeri, hogy van egy ilyen lehetőség a hardverben így nem is használja. Emiatt a DX11->DX12 váltásnál már csak emiatt is sebességet vesztenek, mert lassabban érik el a konstans puffert. Ez a DX12 egyik nagy újítása, hogy a Microsoft betervezte azt, hogy minden pufferelérés ugyanolyan gyorsnak kell lennie. Ez nem hangzik rosszul önmagában, csak ez sok hardvernél azt jelenti, hogy a DX11-hez képest bizonyos pufferelérések lassulnak. Az apró betűs rész ugye.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Igazából nem sok stúdió köt már kizárólagos szerződést. Persze a Bethesda pont ilyen, de az NV és az AMD is inkább a franchise szerződésekre ment rá. Ezért lett és lesz minden Final Fantasy, Mirror's Edge, The Withcer és Metro játék NV-s cím. Az AMD-nek is van ilyen szerződése csak nekik az Alienre, a Star Warsra, a Battlefieldre és a Dragon Age-re.
A Forza 7 nem támogatja majd egyik gyártót sem. Olyan lesz, mint a korábbi címek. A Microsoftnak aktív reklámszerződése van az NV-vel, az AMD-vel és az Intellel is.A következő fél évben így alakulnak a támogatások:
NV:
Final Fantasy XV (*)
Middle-earth: Shadow of Mordor (*)
Assassin's Creed Origins
Destiny 2
Pro Evolution Soccer 2018
Call of Duty WWII
King of Wushu (a kínaiaknak)AMD:
Far Cry 5 (*)
Wolfenstein II: The New Colossus (*)
Quake Champions
The Evil Within 2
FIFA 2018
Star Wars Battlefront 2
Treacherous Waters (a kínaiaknak)Csillaggal jelölve azok a címek, amelyek komolyabb fókuszt kapnak.
Az NV-nél még halottam pletykát a Need for Speed Paybackről, és az AMD-vel kapcsolatban is van egy pletyka valami a Vampyrről. Ezeket nem tudtam ellenőrizni, de valszeg igazak.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#30447
Abu85
HÁZIGAZDA
cskamacska
#30445
Abu85
HÁZIGAZDA
válasz
cskamacska
#30445
üzenetére
Biztos nem használ év eleje óta Vegákat a LiquidSky. Április végén kezdték el nekik szállítani. Nagyjából augusztusra álltak át ezekre, mert van ám tesztidőszak is.
Az OnLive és a Gaikai semmire nem vitte, mert rendkívül drága volt a szerverek fenntartása, és képtelenség volt ezt megoldani az egy user/GPU modellel. A LiquidSky azért vált Vegára, mert átállnak a több user/GPU konstrukcióra, így egy szervert akár 16x több előfizető is fenntarthat. Ez így sokkal olcsóbb számukra, mert nem direkt, hanem virtualizált erőforrást kapsz. Ehhez kellett a Vegából pár új virtualizációs képesség. [link]Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#30455
Abu85
HÁZIGAZDA
cskamacska
#30451
Abu85
HÁZIGAZDA
válasz
cskamacska
#30451
üzenetére
De itt a fenntarthatóság kulcskérdés. Egy Sony vagy egy NV megteheti, hogy nem üzleti szinten tekint erre, hanem egy jövőt potenciálisán meghatározó dologként. A LiquidSky ezt nem teheti meg. Nekik fenntartható üzleti modell kell fenntartható szerverekkel.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
namaste
#30457
üzenetére
Nem az a lényeg, hanem az, hogy az a zöld paca egy kihasználhatatlan CPU idő. Láthattad, hogy ahogy átléptek deferred contextre egy picit javult a sebességük (azt is elmondták, hogy sokan veszítenek egy ilyen lépéstől), de még mindig használhatatlan volt a CPU jelentős része. Amint pedig átléptek explicit API-ra elkezdett a programjuk működni. Magát a gondolatmenetet a demós rész után folytatják itt. [link]
Nem az számít, hogy van-e dedikált cache a hardverben. Az NV korábban többször hangsúlyozta az előadásain (főleg a gyorsabb DX12-es meghajtót bemutatón), hogy óriási különbség van aközött, hogy a hardver mire képes és az API mit enged meg. Például a D3D12-nek a kötött implementációja nem engedi meg, hogy egy compute shader közvetlenül a konstans pufferbe írjon, ezért a fejlesztőknek erre strukturált puffert kell használni. Ugyanakkor a GeForce-on csak a konstans pufferre van fast path, míg egy strukturált pufferre nem, tehát ennek az írása és olvasása lassabb. Például a Hitmanre van egy külön kidolgozott meghajtórutin a 384.76-os drivertől kezdve, amely a strukturált puffer tartalmát mindig átmásolja egy fast pathot lehetővé tevő pufferbe, és azzal dolgozik a hardver (persze ezt csak a Hitmanre tudják használni, mert feltételei vannak ennek meghajtó oldali trükknek, de ennél a játéknál tényleg használ). Ezzel egyébként az a gond, hogy egy ilyen optimalizálást akkor lehet használni, ha a játékot alapját képző leképezőt már nem fogják frissíteni, illetve a kidolgozása is hónapokat vett igénybe. Az NV is mondta, hogy kockázatos a módszer, mert ha jön egy leképezőbe nyúló patch, akkor onnantól kezdve lőttek a Hitman futtatásának, amíg nem veszik ki a meghajtóból a gyorsulást biztosító trükköt.
Az tök jó, hogy van driver csak az a baj, hogy a Microsoft az implementáció egy kis részét maga oldja meg. Egyfajta univerzális meghajtót ír, és azt kell használnia mindenkinek. Igazából nem sok indoka van annak sem, hogy a compute shader közvetlenül ne írhasson a konstans pufferbe. Ez a limitáció a Qualcomm és az ARM miatt lett meghúzva, de az Intel, az NV és az AMD is támogatná ezt a lehetőséget, ha meglenne. Viszont így, hogy nincs meg, azok a hardverek hátrányt szenvednek a DX11-hez képest, amelyek meghajtója kifejezetten épített arra, hogy a hardver gyorsabban tud olvasni a konstans pufferből, mint egy strukturáltból. A GCN-nek és az Intel cuccainak ez amúgy nem számít, mindegyik pufferből ugyanolyan gyorsan olvasnak.
Az NV-nek egyébként a vertex fetch-re és a statikus bindingre van még fast path-ja. Előbbi nem számít, mert a hiánya elég kevés veszteséget okoz, míg utóbbi még nem számít, mert a hiányát akkor fogja megérezni a hardver, amikor bindless bekötést használ a program.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#30474
Abu85
HÁZIGAZDA
huskydog17
#30472
Abu85
HÁZIGAZDA
válasz
huskydog17
#30472
üzenetére
Igazából a Quake Champions esetében az is gond, hogy még nincs kész. Azért nem törődnek vele ma a cégek, mert a kiadás előtt a mostani leképezőjét lecserélik. A Rainbow Six Siege azt az AnvilNextet használja, amit az AC: Unity kapott meg. A PuBG nem annyira rossz, csak nem rakták még bele az új UE verziót, így nagyon le van maradva technikailag. De előbb-utóbb lesz egy nagyobb frissítés. Valszeg az EPIC 4.19-es verziójára várnak, ami hozza a mainline Vulkan támogatást. Esetleg a 4.20-as verzióra is frissíthetnek a többszálú RHI miatt.
Amit írtam ott az nem jóslat volt. Konkrétan egy gyártói mérés a BF1-gyel medium grafikán, és pár szintetikus teszttel. Ha megnézed a GT 1030 ma sem erős BF1-ben. Lásd cain69 hsz-e.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Nem igazán számít már ez egy Ryzen 3-mal. Nem lesz igazán nagy különbség. A legtöbb eltérés abból ered, hogy a tesztjátékok egy része korai hozzáférésű, lásd például a Quake Champions vagy a PuBG. Ezekről tudni lehet, hogy még komolyabbat fognak változni a megjelenés előtt, mert mindkettő játéknál tervben van a Vulkan API-ra való váltás. Tehát teljesen mindegy, hogy mit mérsz most, mert megközelítőleg sem azt fogod mérni később. A gyártók a meghajtókat nem is tervezik nagyon rá úgy a játékokra, hogy az egyes kiadások között folyamatos változtatások jönnek.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
Raymond
#30505
üzenetére
A Broadwell óta azok is APU-k. Igazából a Haswell óta is, csak a Haswellben maradt egy hardverbug, ami miatt le lett kapcsolva pár képesség. Emiatt van az, hogy a Haswell a Windows 10-nél még 64 bites OS-sel is a 32 bites címzési módokat támogatja a WDDM 2.0-ban. A hardverbug megakadályozza, hogy a kiterjesztett címzés működjön.
Amúgy az Intel sosem szerette, ha ezeket APU-nak hívják, mert az AMD-vel kötötték össze a vásárlók ezt a jelzést. Még a Haswell érában nekünk is szóltak, hogy ha lehet ne APU-zzuk le az ő megoldásaikat. Leírhatjuk, hogy miképp működik, de akkor se írjuk rá, hogy APU.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Nem teljesen. Ez gyakori tévhit. Maga a szerződés bonyolult, de nemrég volt lehetőségem rákérdezni, és ha az AMD-t megvenné valaki, akkor az Intelnek automatikusan megmaradnának a kritikus lincencek használatára a jogok, míg az AMD új tulajdonosának ezek elvesznének. Ugyanígy, ha az Intelt megvenné valaki, akkor az AMD-nek maradnak meg ezek a jogok, míg az Intel új tulajának vesznének el. Ez egyébként nem lépne azonnal életbe, ugyanis a felvásárlás után a konkurens félnek nyilatkoznia kell, hogy életbe akarja-e léptetni, vagy inkább megegyezik az felvásárlóval.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
A VGA-khoz is kellhet esetleg x86/AMD64 licenc. Elvégre másképp aligha tudja a GPU közvetlenül elérni a CPU laptábláját, ahogy például a Vega. Ez az egyik kritikus komponense a HBCC-nek. Persze lehet nélküle is élni, csak akkor a megoldás kevésbé általános. Némileg hasonló például a Pinned Memory a Pascalon, de PC-s szinten ez a maximum, ameddig el tud jutni az NV, így nekik külön CUDA API kell ahhoz, hogy egy ilyen modellt alkalmazzanak. A Volta továbbfejlesztette ezt nagyjából arra a szintre, amit kínál a Vega, de az újítások csak IBM Power procival használhatók, mert a multiprocesszorokba épített ATS nem támogat más ISA-t. Az AMD HBCC-je annyiban más, hogy API-tól függetlenül működik, de egy x86/AMD64-es host proci kell neki, mert a GCN CU-iban az ATS ezt az ISA-t támogatja.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#30523
Abu85
HÁZIGAZDA
cskamacska
#30521
Abu85
HÁZIGAZDA
válasz
cskamacska
#30521
üzenetére
A HBCC-nek az előnyét leírtam az alábbi két oldalon: [link] és [link]
Az általános előnye ma annyi, hogy megszüntet minden memóriatörlésből keletkező akadást.
A másodlagos előny, hogy lényegében a VRAM-ot mint tényezőt megszünteti. Innentől kezdve a GPU fedélzeti tára csak egy gyorsítótár lesz. Ez lehetővé teszi a fejlesztőknek, hogy az amúgy is elkészült legjobb minőségű tartalmat le is szállítsák, és ne az döntsön a minőségi szintről, hogy a célzott VGA-knak mennyi fér a VRAM-jába. Ehhez egyébként jobban illik az inkluzív cache mód, ami még nincs benne a meghajtóban, de állítólag úgyis csak a Far Cry 5 használja először, tehát van idő behegeszteni.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
namaste
#30552
üzenetére
Egyszerű, csak meg kell hallgatni, amit mondanak. A kernel meghajtó server szálai rengeteg stallt eredményeznek, ami a processzoridő jelentős részét kihasználhatatlanná teszi. Látható, hogy deferred context mellett több aktív szerver szál van, és bár ez az Oxide esetében picit pozitív változást eredményez, azt is elmondták, hogy többen negatív változást tapasztaltak. Emiatt hibás a deferred context koncepciója. Ahogy átváltottak explicit API-ra hirtelen elkezdett az egész skálázni.
Mindenki fejlesztett többszálú drivert, és ezeket használják is. Amikor ezt a munkát elkezdték, akkor még nem tudták, hogy ez az egész nem sokat ér. A tapasztalat hozta meg a kijózanító pofont és erre volt reakció az explicit API-k fejlesztésének elkezdése.Nem tudom, hogy az NV meddig tárolja a korábbi press előadásait, de azt tudom, hogy mindenképpen press engedély kell hozzá, tehát ha nem vagy regisztrálva az NV-nél újságíróként, akkor nem engedik ezekhez a hozzáférést. Ezt nagyon komolyan veszik, még a PDF-eket is titkosítva nézhetem meg, benne lesz a letöltött állományban a neved és az azonosítóm, illetve online kapcsolat kell a megnyitáshoz.
Az rendben van, hogy a hardver így működik, de az NV pont ezt magyarázta, hogy nem ezt kell nézni, hanem azt, hogy az API mit enged meg.
A konstans puffer a GPU számára írható. Ugyanolyan pufferként kezeli a hardver, mint egy másikat. Az API nem engedi meg az írását, és mivel a meghajtó sem tudja ezt felülbírálni a D3D12-ben elvesztik erre a trükközést, hacsak nem csinálnak minden alkalmazásra speciális hacket, ami nyilván nem realitás. Eddig csak a Hitmanre vállalták be, mert az nagyon rosszul futott.Ahogy a strukturált puffer is cache-elt a GCN-en, tehát mindegy, hogy egy puffer konstans vagy strukturált. Az elérése ugyanolyan gyors. A GeForce-oknak ez nem mindegy.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
[link] - egyébként megtaláltam a PDF-ben ezt a linket. Itt az NV ecseteli a fejlesztők számára beépítendő trükköt, ami gyorsítja a feldolgozást a GeForce-on némi extra másolás mellett. DX11-ben az egészet driverből kezelik. DX12-ben a fejlesztők egy része használja a javaslatot, míg egy másik része nem. Nyilván pro-kontra érv van mellette. Az előnye az, hogy a GeForce úgy ~10%-ot is gyorsulhat tőle a teljes képszáímtásra levetítve, de hátrány az extra másolás, ami GPU stallt okoz, tehát az Intel és az AMD hardverei buknak pár százalékot, ahogy a GeForce is, csak itt összességében előny a gyorsabb hozzáférés.
Emiatt egyébként nincs is egyetértés a javaslatokban. Az NV a másolós megoldást javasolja, míg az Intel és az AMD ellenzi, mert számukra ugyanolyan gyors a strukturált pufferek elérése is.
Driverből DX12-ben ezt nem lehetetlen alkalmazni, de időigényes megvalósítani. Lásd a Hitman című játékot, ahol meg kellett várni, hogy a fejlesztők már ne nyúljanak a leképezőhöz, de amint belőtték hozott is ~10%-ot.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
namaste
#30578
üzenetére
Ugyanez volt Windowson a DX11 és OpenGL alatt is. Teljesen kiszámíthatatlan a viselkedése. Hiába fejlesztik, ezen a gyártók átmentek és ugyanezt tapasztaltál. Hol javít, hol nem.
Írtam, hogy az NV trükközik, csak játékra építenek profilt rá. A Hitman csak ezért gyorsult. De mindegyik játékra ezt megcsinálni nem túl célszerű, mert sok erőforrást visz el, és meg kell várni azt a kódot, amikor a játék már nem változik. Ezt konkrétan elmondták a nyáron. Emiatt inkább a hardveren fognak változtatni ... utalás a Voltára? Lehet. Elképzelhető, hogy a Volta már ugyanolyan gyorsan fogja kezelni a konstans és a strukturált puffereket. Ez logikus előrelépés lenne elvégre a GCN és az Intel Gen9 is így működik.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Azt nem tudom, hogy miképpen lesz a jövőben. Azt tudni, hogy ma hogy van. Az explicit API-t használó játékok közül az NV javaslatára csak a Rise of the Tomb Raider épít. A többiek inkább nem másolnak.
Lehet "if"-felni, csak az megnöveli a költségeket. Egyszerűen nem éri meg ezzel foglalkozni. Célszerűbb az elején lemérni, hogy az adott rendszer mivel jár jobban, és utána a tényeket ismerve dönteni valamelyik irány mellett. Az is fontos szempont, hogy ezt a problémát általánosan csak önmagában lehet vizsgálni, de egy motorban már lehetnek olyan tényezők is, amelyek eleve eldöntik a kérdést.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Még annyi, hogy az NV-t különösen ez a kis probléma nem érdekli. Itt viszonylag keveset vesztenek. Sokkal jobban érdekli őket a statikus bekötésre tervezett fast pathok elvesztése a bindless játékokba. Olyannyira, hogy a 384-es meghajtók DX12 implementációját megváltoztatták, és az eddigi hardveres megoldás helyett inkább leemulálják egy külön CPU oldali API-val a bekötést.
Ez is pro/kontra dolog. Az eredeti implementációval oda lettek volna a fast pathok, de a processzor terhelése alacsony maradt. Az új implementációval elérhetők a fast pathok, viszont a processzor terhelése magasabb. Utóbbi igazából nem rossz irány, mert eredetileg a négymagos tötyögés volt a legfőbb ellenérv, de ma már olcsón szerezhetők hat-nyolcmagos procik. Az új implementáció azzal számol, hogy ha valakinek van pénze egy 500+ dolláros VGA-ra, az nem egy négymagos proci mellé fogja rakni. Egy hatmagos procival pedig már kedvezőbb egy külön CPU oldali API-t használni a bekötés emulálására.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Épp kaptam egy tippet, hogy a Warhammer 2-ben a DX12 módnál a static bindingről áttértek bindlessre. Szóval végre látható lesz a DX11 és a DX12 összehasonlításánál, hogy az egyes architektúráknak ez a váltás mit okoz. Az alapjaiban Tier3-as bekötéshez tervezett hardvereknek elvileg pár, úgy 2-3-4 százalékkal gyorsulniuk kell. A többi hardver viselkedése nagy kérdés, főleg az NV-nek az emulációs megoldása kiszámíthatatlan.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
#85552128
#30606
üzenetére
Uh, erre azért nem számítottam, hogy a bindless ennyire bedarálja a nem tier3-as hardvereket.
Lehet, hogy az NV-nél a tier3-as szint emulációja sem valami hatékony még, talán lehet ezen javítani.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
#85552128
#30608
üzenetére
A sebességesés normális a 3-4 GB-os VGA-knál. A bindless kód sokban eltér, így több memóriát is igényel. 6-8 GB VRAM kell minimum, különben a kevés memória miatt esni fog a teljesítmény.
Érdemes lenne átnézni az emulációt az NV-nek, mert nekik a 6-8+ GB-os VGA-ik sebessége is esik, ami elvileg nem megmagyarázható a kevés memóriával. Már csak azért is lényeges ezt kielemezni, mert az Ubisoft is bindless motorokat hoz a következő körben. Azért -15-20-25% csak a bindlessre váltás miatt sok, a driverbe épített emuláció biztosan lehet hatékonyabb is.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
#85552128
#30612
üzenetére
A Polaris egy rakás olyan dolgot is támogat, amivel memóriát lehet spórolni, míg a régebbi hardvereket ezeket nem támogatják.
Akkor ne nézzék meg, de ez az első bindless játék, és az NV-nek régóta a bindless implementációjával van baja a DX12-ben. Nem véletlen, hogy a megvalósításuk még azelőtt változott, hogy az első játék megérkezett volna rá. Nem mondom, hogy rossz dolog a most használt emuláció erre a problémára, de hogy nem igazán hatékony az is biztos. Már csak az idő miatt sem lehet az, mivel az AMD bindless implementációja egy két éve optimalizált rendszer, míg az NV aktuális implementációja csak három hónapos, vagyis optimalizálással még nem is igazán élhettek. De ha nekik ez így jó lesz a jövőben, akkor lelkük rajta.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
FLATRONW
#30631
üzenetére
Tudtommal a Warhammer 2-t egyik cég sem támogatja. Amolyan árva játék ilyen szempontból.
Igazából a DX12-ben nem kellene ekkorát esnie az 1070-nek. Elvégre a bindless egy sebességnövelő funkció, aminek +1-3%-ot kellene hoznia. Ez megkérdőjelezi a bindless használhatóságát, és akkor tudjuk, hogy az Ubisoft is erre áll át a következő körben. Lehet, hogy korai még. Az is kérdés, hogy az NV jól tette-e, hogy a 384.76-os meghajtónál bindless emulációra váltott át. Nem-e jobban jártak volna, ha marad az eredeti megoldásuk? Esetleg arról van csak szó, hogy még kevés erről a tapasztalatuk és lehet, hogy úgy egy éves távlatban mégis ez a jó megközelítés.
Azért vártam az első bindless játékot, mert sok kérdést tisztázott volna, de mondjuk úgy, hogy csak még több kérdés merült fel. A Polaris és a Vega működik ez megállapítható, viszont más szempontból csak pislogni lehet az eredményeken.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
FLATRONW
#30641
üzenetére
Meggyőződésem, hogy most nem erre kutatják a választ, mert ezt könnyen el lehet érni a shaderekkel. Ezek viszont kicserélhetők, akár egy későbbi patch-ben, akár a driverben.
Én azért remélem, hogy ez az eredmény nem a bindless általános hatását mutatja, mert akkor csúnya lesz itt az AC: Origins és a Far Cry 5. Esetleg ha meghajtóban van a gond, akkor addigra megtalálják a probléma forrását. De elméletben nem kellene esnie a hardverek teljesítményének ennyit a bindlesstől. Kb. úgy kellene viselkedniük, mint a Vegának és a Polarisnek. A sample-ök sem mutattak eddig problémát, na persze az is igaz, hogy egy sample és egy játék között hatalmas a különbség.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
Crytek
#30681
üzenetére
Nem sok köze van a Vega eredményének a DX12-höz. Azért ennyivel gyorsabb, mert dupla olyan nagy a felhasználható LDS, mint a korábbi GCN-ekben. Mivel a Forza shaderjeit nem írják PC-re, hanem az Xbox One shaderekből konvertálják egy programmal, így már a korábbi részre is jellemző volt, hogy az LDS kapacitása limitálta a futtatható wave-eket lényegében minden architektúrán. A Vega azonban kezeli ezt a problémát, így ennél az architektúránál már több wave futhat, mint mondjuk a Polarison, még akkor is, ha ugyanaz a shader. Vagyis végeredményben a GPU kevesebb időt tölt el azzal, hogy vár az adatra. Az Xbox One-on ez azért nem probléma, mert ott ismerik azt a hardvert, amire fejlesztenek, és direkten képesek kontrollálni a GPU-n belüli erőforrás-allokációt. Ilyet PC-n nem lehet tenni. Túl sok az eltérő hardver, és nincs is olyan felület, amivel ez egyáltalán megoldható. Majd a Volta itt is jobb lesz, mert az NV összevonta az LDS-t és az L1-et, így a Vegához hasonlóan több LDS kapacitást ad.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
-
#30738
Abu85
HÁZIGAZDA
huskydog17
#30727
Abu85
HÁZIGAZDA
válasz
huskydog17
#30727
üzenetére
A demó régebbi verzió, mint a teljes játék. Szóval ahhoz nem, hogy patch nem lesz, de még rosszabbul is fut, mint ami kijött.
(#30731) TTomax: A G-Sync lehetséges, de ahhoz támogatni kell a drivernek a swapchain API-t, amin keresztül a Microsoft kezeli a variálható frissítési frekvenciát az UWP programokban. A Win32-es direkt elérés itt nem lehetséges, vagy a swapchain API vagy semmi.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#30741
Abu85
HÁZIGAZDA
huskydog17
#30739
Abu85
HÁZIGAZDA
válasz
huskydog17
#30739
üzenetére
Szerintem nagyon sokan nincsenek tisztában, hogy a demó elkészítése mekkora teher. Egy ilyen AAA címnél, ha nem vonnak be egy alternatív csapatot, akkor egy demó három hónappal tolja meg a teljes játék kiadását. Emiatt szokás azt csinálni, hogy kiválasztanak egy stabilan futó verziót a gold előtt két-három hónappal és arra csinál egy demót pár fő. Ezzel lesz próbaverzió és nem csúszik az eredeti játék sem. A másik lehetőség, hogy nem lesz demó, de az, hogy a demó is ugyanaz legyen, mint a teljes játék csak pár hónappal a teljes megjelenése után lehetséges.
(#30740) Crytek: Akár a Steamben is megvásárolható lenne, ha a Valve beépítené az UWP támogatását. Ha a technikai akadály elhárult, akkor onnantól kezdve az egész már egy üzleti kérdés.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
Crytek
#30740
üzenetére
Pont erről beszéltem. Nincs rálátásotok arra, hogy mekkora munkával jár egy demót kiadni.
Ellátható a teljes játék mondjuk időlimittel, de a problémát ilyenkor az jelenti, hogy le kell szedni a 100 GB-ot egy órás játékért, amit sokan nem tennének meg.
Miért baj az, hogy ez is egy opció az MS-nél? Sokan már demót sem adnak ki, mert borzalmasan időigényes elkészíteni. Akinek pedig nem kell a demó, megveszi a teljeset. Nem kötelező letölteni a próbaverziót.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#30746
Abu85
HÁZIGAZDA
huskydog17
#30745
Abu85
HÁZIGAZDA
válasz
huskydog17
#30745
üzenetére
Az indiek nem 100 GB-os programokat fejlesztenek, még csak ennek a tizedét sem. Egyébként nem a pénz a probléma, hanem az idő.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
Még a Blikkben és a Borsban sem szokták az egyes mondatfoszlányokat így megmagyarázni.
Pedig annyiszor vitáztam volna róla, de sosem sikerült összehozni. 
Lehet, hogy az NV-nél a tier3-as szint emulációja sem valami hatékony még, talán lehet ezen javítani.
Új hozzászólás Aktív témák
A topikban az OFF és minden egyéb, nem a témához kapcsolódó hozzászólás gyártása TILOS!
Megbízhatatlan oldalakat ahol nem mérnek (pl gamegpu) ne linkeljetek.
- Mobil flották
- Eredeti játékok OFF topik
- Apple iPhone 15 Pro Max - Attack on Titan
- Adóbevallás
- Kerékpárosok, bringások ide!
- Sweet.tv - internetes TV
- Spórolós topik
- Apple iPhone 13 - hízott, de jól áll neki!
- bb0t: Gyilkos szénhidrátok, avagy hogyan fogytam önsanyargatás nélkül 16 kg-ot
- Milyen routert?
- További aktív témák...
- Sony 55-210mm f/4.5-6.3 E OSS objektív
- AKCIÓ!! GAMER PC - RTX 3060Ti 8GB - RYZEN 5500 - 16GB DDR4 - 240GB SSD - 500GB HDD
- AKCIÓ!! GAMER PC - RTX 3060Ti 8GB - i5 10400F/11400F - 16GB DDR4 - 240GB SSD - 500GB HDD
- Apple watch S4 40mm - Space Gray
- Crucial 32GB KIT DDR4 3200MHz CL16 Ballistix Red RGB (Utánvétes Foxpost az árban!)
Állásajánlatok
Cég: Alpha Laptopszerviz Kft.
Város: Pécs
Cég: Ozeki Kft.
Város: Debrecen