Digital Combat Series: World
A DCS World megszületésével a DCS sorozat egyetlen közös magra építve, egy felületről lesz elérhető. Az eddig egyenként telepíthető DCS részek helyett egyetlen közös felületről lesz elérhető, így sokkal könnyebben lehet váltani az egyes kiegészítők között, egyszerűbb és könnyebb lesz a frissítés is. A DCS World folyamatos frissítésekkel, a grafikus rendszer, az AI egységek, AI logika, effektek, stb. együtt fejlődik. Minden ami a szimuláción kívüli repülhető gép, térkép vagy más fizetős tartalom. A jelenlegi DCS World még béta verziós, nem végleges. Az első kiadás ingyen tartalmazza a Flaming Cliffs 2-ből származó repülhető Szuhoj Szu-25T Frogfoot típust.(THX by Sanyo)
*-------*
Nem jogtiszta játék letöltésében, telepítésében és használatában nem tudunk és nem is akarunk segíteni.
Az ilyen jellegű hozzászólások válaszolatlanul lesznek, vagy minden további értesítés nélkül törlésre kerülnek.
HUNAF nyílt facebook csoport KATT IDE!
DCS OFFICIAL fórum KATT IDE!
A DCS HuNAF weoldala KATT IDE!
Szimulátor történelem KATT IDE!
-
#21383
Értem mire gondolsz, de én is úgy vagyok vele, hogy bár a játékmenet a legfontosabb, de ha már itt a technológia, miért ne nézzen ki jól? :)
De a probléma mindig is a valós idejű számolásokkal van. Amikor játékhoz készít valaki grafikai engine-t, akkor mindig egyszerűsítésre van kényszerítve és minden mikroszekundum nyereség -interpolálva az összes használt textúrára és anyagra- hatalmas gyorsulást jelent. A .dds fájl formátumot például kifejezetten arra fejlesztették, hogy tömörítetlen formában tárolja a textúrákat úgy, hogy a videokártya a leggyorsabban be tudja olvasni. Elképzelhetetlen, hogy például jpg-n tároljanak bármit, hogy aztán a kicsomagolással menet közben kelljen foglalkozni. Pedig milyen jól hangzana, hogy egyetlen 4K-s textúra ne 12 MB-ot foglaljon videokártya memóriából, hanem csak 90KB-ot. Igen, csak amikor azt a fájlt ki kell csomagolni, akkor jönnének a hatalmas akadások, fps droppok. A néhány éve megjelent PBR anyagok elég látványos változást hoztak sebességben, rengeteg számolási igényt vettek le a videokártya válláról azzal, hogy egy-egy anyag összes, a valós életben mérhető fizikai vagy fény jellemzőit egy meghatározott szabvány szerinti map-okon tárolják (innen is a neve - Phisical Based Rendering).* Teljesen eltűntek a procedural anyagok, amiket meghatározott algoritmus alapján, de valós időben számolna ki a program. Helyette jöttek az engine-ben összeállított anyagok (shaderek), amik szintén lehetnek bonyolult, sok lépcsőből álló összetett anyagok is, a sebesség viszont sokkal gyorsabb lett (3DS Max vagy Maya-nál használható VRay renderelő már évek óta hasonló rendszert használ, de azt álló képekhez, vagy nem valós idejű mozgókép renderhez fejlesztették, és bár iszonyatosan szép, pontos és élethű - esélytelen bármit is valós időben megjeleníteni vele). Ma már azt mondhatjuk, hogy az Unreal, Unity, Cryengine közel fotoreal végeredményt tud valós időben. És ez hatalmas fejlődés. A speciális, custom video engine-t használó játékok, mint az Arma, Clod, DCS meg futnak utánuk, ahogy éppen tudnak. A DCS EDGE például egyértelműen elindult ebbe az irányba, talán egyszer a Clod is el fog ;) .
A sok pozitívum mellett viszont iszonyatosan megnőtt a foglalt terület igénye is. Most már nem csak egy rajzolt textúra lapot kell tárolni, hanem mindjárt hatot (alsó hangon). Úgyhogy már itt is trükközni kell, bevett eljárás, hogy fognak pár fekete fehér map-ot, ahol az anyag jellemzőit egyetlen fekete-fehér skálán elfoglalt értékkel jelölik (például AO map, roughness map, metallic map), és ezeket egyetlen RGB kép különböző csatornáira teszik rá. Vörös csatorna lesz az AO érték, Zöld a felület érdesség, a Kék a fényvisszaverés mértéke például). Hopp mindjárt három map elfoglalja el egyetlen map helyét (RGB-nél ha csak egyetlen fekete fehér képet tárolsz, akkor az összes csatornán ugyanaz az érték lenne tárolva). Bár a PBR mint szabvány elég gyorsan elterjedt, az ilyen trükközések még mindig a játék programozók hatáskörébe tartoznak. A shaderek megoldásai, bonyolultsága esetleg befolyásolhatják, hogy miket érdemes összevonni, és miket kell külön hagyni.
*A PBR anyagokkal már meg lehet csinálni azt, hogy normal mapokkal együtt (amit az anyag tulajdonságokhoz csapnak, de az alapvetően 3D geometriát módosító/szimuláló map) anyag-csomagokat netes boltokban áruljanak, amit egyszerűen a szerkesztőbe húzva pontosan ugyanezt az eredményt kapd. És ezek digitálisan beszkennelt anyagok, nem jó kezű festők rajzolgatják az anyagokat, hanem erre való kamerákkal, lencsékkel szkennelik őket. Quixel megascans például. A mapok tile-osak, ami azt jelenti, hogy -elvileg- nem látsz vágást ha a csempék egymás mellett ismétlődnek, de azért vigyázni kell, mert a minta ismétlődés ettől függetlenül látványos lehet, ha túl kis, túl sűrű mapot használsz. Néhány éve ez elképzelhetetlen lett volna (és ezért néz ki manapság már mindegyik ugyanúgy. Ezek után most mivel tudsz villantani grafika terén? Csak a részletességgel és a belepakolt content-el).
Szóval nem egyszerű. Kívülről csak a végeredményt látni, és sokszor nem tudni, hogy a fejlesztők miért kényszerültek egyszerűsíteni egyik vagy másik anyagon/effekten. Azt soha nem feltételezném, hogy ők nem látják vagy nem értenének hozzá. Csak lehet hogy teljesen más a prioritásuk.
Afranc, ez megint kisregény lett... Na, megyek vissza dolgozni, GDP-t kell termelni :)