36921
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!
-
#29263 Igen, nekem régi rinyám, hogy a DCS rakéta modellezése mennyire fosch. Amraam főleg. Emlékszem, hány olyan képet láttam már, hogy a kabinból a rakéta oldalán lévő serial szám is leolvasható volt, persze a gyújtó az nem működött. -
Krokoliszk #29262 A proximety valahogy a pilóta fejétől van számolva, meg szerintem nem minden irányból működik. Elég gyakran van olyan, hogy a kabin mellett repülnek el rakéták, vagy akár még a gépen is keresztül mennek. A másik nagy hiba, hogy az ARH-knak nincs semmi memóriája, sokszor elég a másodperc töredékéig a notchba kerülni, egy laza U fordulóval is simán kukázhatóak még 2-3 G-vel is ami röhely.
Meg amikor notchon keresztül rádfordul és nincs semmilyen TWS memória a gépben és kukázza a tracket és üres a radarkép, mert a kitartott Gs fordulót cold-hot aspect között marha nehéz extrapolálni 2 másodpercre..
Mondjuk a boresight az utóbbit orvosolja, csak az sok mindent limitál. :)
Utoljára szerkesztette: Krokoliszk, 2018.10.11. 13:58:24 -
#29261 Közelségi gyújtó sehol? -
#29260 DCS rakéta modellezés. Qrvajó. Ja, nem
https://clips.twitch.tv/ColdbloodedPolishedNightingaleEagleEye -
wolfhgb #29259 Az a megatalkodott spermahader! :) -
Solt #29258 Árpád apánk tehet róla! :D -
wolfhgb #29257 Na tessek, mameg mit muveltel Hercegszanton Zsotiiii!!! :)
-
#29256 EDe nyugodtan elmehet a picsába. -
#29255 Köszi! -
gantus68 #29254 Na kiderült. Az összes ED modulban megváltoztatták a keybind-et. Ezért szavaztatták a (l)(j)úzereket, hogy milyen hotas-t használnak. A mentések visszatöltése sem működik. A 3rd party, pl. RAZBAM nem érintett. De legalább egy mapping-ot adtak volna. -
#29253 Boldogot
Utoljára szerkesztette: repvez, 2018.10.10. 20:57:14 -
#29252 Kössz Tom! -
#29251 A jó múltkorában jártam hasonlóan és először csak kamilláztam, hogy most miért nem működnek a beállított dolgok.
-
#29250 Boldog szülinapot Leon! -
#29249 Gondolhatod, hogy Edéék és teljes rokonságuk számára voltak szubtrópusi övezeti programajánlataim egész télre, miután először azt hittem, megint a joy szaraxik, elkalibrálódott valamelyik tengely (csinált már ilyet), DCSből kilép, reboot (úgyis várakozott egy WIndows update), joystick kihúz-bedug, eszközökben lecsekkolva minden OK, DCS megint elindít, másik géppel ugyanez.
Nyilván, pont a MiG-29-nél nem rakták oda a trimmet… -
gantus68 #29248 hornet, nws nem működik nekem, úgy azért elég nehéz felszállni. -
#29247 Na én ettől kapok agyfaszt nem a mikrolagtól... utálom, amikor belepiszkálnak a beállításokba. -
#29246 Elvileg a mai béta update-ben kijött a MiG-29 új FM-je
...és másnál is beletúrtak a billentyűzet/joystick beállításokba? Nálam minden gépnél rákerült a trim a POV hat-re alapértelmezetten, ami eddig a kabinban körbenézés volt.
Oké hogy béta, de azért írhatnák legalább a changelogban, hogy helóka, az update belenyúl a gomb/tengely stb. leosztásodba, nézd át mielőtt küldetést indítasz, vagy valami...
Utoljára szerkesztette: sure, 2018.10.10. 18:37:02 -
Solt #29245 Üdv Urak!
Ha esetleg valakit, vagy valakinek az ismerősét érintheti a dolog,
SPOILER! Kattints ide a szöveg elolvasásához!AUTÓBUSZVEZETŐT keresünk!
A Smart Bus Kft. budapesti telephelyére (Óbuda / XIII.-kerület) 1 fő autóbuszvezető kollégát keres 20 fős Mercedes Sprinter autóbuszra.
Amit kínálunk,
- bejelentett munkaviszony
- nettó 1300.-Forintos kezdő órabér egyedi óraelszámolás alapján
- fix munkák egész évben (idegenforgalom / dolgozói járatok)
- AETR szabályok betartásával történő munkavégzés
- családias légkör
Amit a fentiekért cserébe kérünk,
- pontos, megbízható, a szakma iránti alázattal történő munkavégzés
- igényes megjelenés
- érvényes „D” kategóriás jogosítvány
- GKI kártya
- érvényes PÁV II.
- EÜ alkalmasság (102-s kód)
Ami előnyt jelent,
- alapfokú angol vagy német nyelvismeret
- többéves szakmai gyakorlat
- budapesti helyismeret
- III. / XIII. kerületi lakhely
A jelentkezéseket írásban várjuk a [email protected] email címen!
Köszönöm! -
Solt #29244 Abban a pillanatban, hogy nincs meg a 99%-s GPU kihasználtságod CPU limitbe ütköztél. Ez lehet szoftveres, illetve lehet hardveres. Lehet még vegyes limit is, de nem akarom tovább bonyolítani. Szoftveres esetén azt látod amit felvázoltál (alacsony CPU terhelés), hardveres esetén kb ezt,
Ez egyébként DCS 2.5 alatt készült egy 4770K-l amin kikapcsoltam a HT-t.
Ami szöveget bemásoltam az attól releváns, hogy taglalja mitől lesz szoftveres limit DX11 alatt,
"a feldolgozás még mindig egyetlen processzorszálra van korlátozva(!), amin a DirectX 11-ben bevezetett deferred context funkció sem segít sokat, mert rendkívül sok szinkronizáció szükséges ahhoz, hogy a program egyáltalán fusson."
"a fejlesztők is inkább manuális többszálúsítást próbálnak(!!) megvalósítani, ami persze sokkal több időbe kerül, de legalább hatékonyabban fut, mint egy deferred context implementáció, mivel a mai driverek tartalmaznak különféle hackeket a többmagos processzorok erejének hasznosítására."
Tehát amit látsz, hogy több mag dolgozik az mind a driveres és fejlesztői varászlások eredménye, de ez messze van a normális több szálas kihasználástól. Ez a videó jól szemlélteti ezt,
Szemléltetésnek jó még az ArmA 3 mert ott csúszkával lehet állítani a látótávot. Felmész egy magas pontra, elnézel egy város felé és elkezded felhúzni a látótávot. Amikor a GPU kihasználtság elkezd csökkenni, akkor érünk el a szoftveres limithez... ilyenkor már annyi rajzolási parancs (draw call) érkezik amit a DX11 a felépítéséből adódóan nem bír kezelni. Ezek a határok erősebb CPU-l kitolhatóak, de az a plusz 10-20% CPU erő nem hoz annyit érdemben a konyhára, mert hulla mindegy, hogy 30 FPS-d van vagy 36.
Tehát amikor leesik nálad az FPS (pl "rákezdett a földi harc") és a GPU kihasználtság (alacsony CPU kihasználtság mellett), akkor abban a pillanatban túl sok rajzolási parancs, fizikai + AI számítás érkezik. A szimulátorok (főleg repülés) ugye itt vannak hátrányban, mert magas a látótáv (sok a rajzolási parancs), van "valós" fizika és az AI sem annyira hülye mint egy átlag játékban, csak ugye ez mind többlet számítás, ami már sok(k) a DX11-nek.*
Mivel azonban hardveres oldalról a géped jóval több számítást tudna elvégezni mint amennyit maga a DX11 elbír, ezért nem a géped a szűk keresztmetszet, hanem maga a DX11 felépítése, ami alkalmatlan arra, hogy valódi többszálas feldolgozás történjen. Próbálj meg ideiglenesen alacsonyabb Visible Range értékkel repülni, látni fogod, hogy nő a GPU kihasználtságod, mert a kevesebb rajzolási parancs miatt csökken az API terhelése. (Természetesen kikapcsolt V-Sync mellett, mert ugye minden tesztet így végzünk!) Ha nagyon leegyszerűsítve akarok fogalmazni, akkor olyan ez mint egy tölcsér... amíg annyit töltesz bele ami alul ki tud folyni addig nincs gond, ha többet, akkor jönnek a problémák...
A Mantle ajnározása azért van, mert drasztikusan kitolható vele ennek a szoftveres túlterhelésnek, limitnek a határa, magyarul jobban kihasználhatóak a hardverek képességei. Ezt az AMD arra szánta, hogy felhívja a figyelmet arra, hogy konzolon a jóval gyengébb hardveres komponensek mellett milyen komoly eredményeket lehet felmutatni. Plusz azért is jól jött nekik, mert a saját hardvereik jobb teljesítményt hoznak a DX12 / Vulkan API-k alatt mint DX11 alatt... a driveres rétegük érzékenyebb erre a szoftveres limitre mint a konkurenciáé.
Egyébként ha az AMD nem áll elő a Mantle-l, akkor a DX12 nagy valószínűséggel még mindig a fiókban pihenne, a Vulkan pedig sehol nem lenne... utóbbinak konkrétan a java része Mantle kód, szabványosítva a Khronos Group által, de az előbbinek egy része is Mantel másolat. :)
*A DX11 korlátai természetesen a képességek, szándék, ráfordított idő és pénz arányában függenek a fejlesztőktől is. Nyilván jobb eredmény érhető el akkor, ha a fentiek közül minden stimmel, lásd például a GTA V-t.
Utoljára szerkesztette: Solt, 2018.10.10. 12:52:20 -
gantus68 #29243 +1 dolog jutott eszembe, bezavarhat a 'mirror' is, érdemes azt is kikapcsolni.
A 29180-ban egy abszolút minimumot írtam le, ami nálam bevált ez alapján: Optimisation guide
A táblázatban benne vannak a különböző beállítások fps-re gyakorolt hatásai, ez alapján a shadows/terrain shadows a global cocpkit illumination az msaa/ssaa fps killer. Nálam is 1070-el inkább a gpu terhelődött, mint a cpu. 4k-ban esélytelen a shadows-t bekapcsolnom, még low-ban is elkezd microlaggolni.
-
#29242 Lehet már késő van, nem értem miben releváns ez ahhoz amiről beszéltünk? 2013-as cikk ajnározza a Mantle-t, meg hogy mennyire szar a Dx11 hozzá képest. Ok. Amit jósol, hogy AMD majd jól sakkot ad mindenkinek... nos, ez nem jött be, mondjuk AMD jól elvan a konzolokkal, PC-s piac talán nem is olyan fontos nekik már. Vulkan köszöni, elvan, de nincs az az áttörés, amit a cikk jósolt (vagy inkább remélt).
Közben megnéztem MSI afterburnerral szálankénti terhelést, 1. mag sosem ment 40% fölé, a többi meg maradt olyan 5-15%-on. Szép egyenletesen mind a nyolc szál. Egyik sem volt kiakadva, egyik sem terhelődött más ütemben mint a többi. Teszt közben a GPU terhelés volt 98% körül, néha leesett és akkor jöttek az akadások. Két alkalommal megállt az egész olyan 1-2 másodpercre is, valszeg ott kellett valamit winyóról töltenie. Amikor rákezdett a földi harc, akkor jöttek a rendszeres apróbb akadások is. Sakkay teszküldijében, amikor 100 földi cucc csépeli egymást, ott olyan egyenletesen jöttek az akadások, mintha egy metronom kattogna :) Akárhogy nézem, ez nekem nem CPU-nak tűnik, sokkal inkább GPU a bottleneck. 1080, 1080TI-vel tuti jobban futna. Nem? -
Solt #29241 A szoftveres limit esetén gyakorlatilag "mindegy" milyen CPU-d van, mert nem a CPU képességei jelentik a korlátot, hanem a szoftveres háttér (DX11),
A DirectX és OpenGL API-kra épülő alkalmazások esetében a feldolgozás még mindig egyetlen processzorszálra van korlátozva, amin a DirectX 11-ben bevezetett deferred context funkció sem segít sokat, mert rendkívül sok szinkronizáció szükséges ahhoz, hogy a program egyáltalán fusson. Ráadásul az NVIDIA implementációjában a szinkronizációhoz a grafikus driver egy processzormagot teljesen lefoglal a parancslista kezelésére, ami két maggal rendelkező processzorok esetében nem kedvező. Az AMD és az Intel pont ezért kerüli a parancslista implementálását, mert nem minden szempontból előnyös, ráadásul a fejlesztők is inkább manuális többszálúsítást próbálnak megvalósítani, ami persze sokkal több időbe kerül, de legalább hatékonyabban fut, mint egy deferred context implementáció, mivel a mai driverek tartalmaznak különféle hackeket a többmagos processzorok erejének hasznosítására. A helyzet azonban az, hogy az így nyert sebesség az egyszálú feldolgozáshoz képest nem túl nagy, viszont ettől függetlenül rengeteg optimalizálást igényel. Ezt a nagyobb stúdiók megteszik, de aránytalanul sok a befektetett munka pár százalékos gyorsulásért. A Mantle eltérő működése azonban technikailag lineáris skálázást tesz lehetővé, ráadásul tényleg rengeteg szál futhat párhuzamosan. Ez a jövő szempontjából még kedvezőbb, mivel ha a mai nyolcmagos processzorok után esetleg lesznek 10-12-16 magos opciók, akkor abból a DirectX leképző tulajdonképpen nem profitál, miközben a Mantle kód folyamatosan gyorsul.
LINK
-
#29240 Ja, hogy a régi gépek feljavítására gondolsz. Igen, azokhoz aktualizálni kellene ezeket mapokat, amit még nem csináltak meg. -
#29239 Milyen olyan függesztő van a Viggen, F-5, F-18-on, amit más gép is használhatna? -
#29238 A texturázás lehet ,hogy szabványos, de valamilyért nem ugyan az a szint a kulönbözö gépeknél, mert mig az uj modellek szinte valósághű kinézettel birnak a szu25 és a ka50 még mindig eléggé rajzfilmszerü és temperával festett kinézete van.Pedig ezek nem is külsös modulok, csak régebbi kiadások, ugyan ugy mint az FC3as.
Nem tudom , hogy melyik map , de az ami azért felel, hogy ne egységes csillogás legyen a gépek felületén , az hiányzik róluk.
Persze kis részét teszik ki , de ha minden gépnek külön el kell késziteni az AMRAAM meg AIM 9es stb...pilonokat , az azért összeadódik, amikor be kell tölteni .Én ugy gondoltam ami külön szeparált modell annak nem kéne egy lapon lennie a gép többi részével.
Utoljára szerkesztette: repvez, 2018.10.09. 20:31:48 -
sakkay #29237 Nagyon sok dolgot amit most a hornet hoz és hozni fog, használják és használni fogják más gépek is. Harrier pl ilyen. -
#29236 - Textúrázás szabványa biztos, hogy egységes. Felbontás, texel méret, fájltípusok, mapok, layerek. Hogy ki milyen eredményre jut ezekkel, az már a művészektől függ.
- A pilonok gépspecifikusak, a festésüket tekintve mindenképp, Azoknak is azon az UV-n kell lenni, amelyik textúra a festésre váltani tud. Dolgozhatnak sablonból is, de egy pilon annyira kis része a gépnek, hogy modellezés, textúrázás szempontjából jelentéktelen, hogy megkapják előre vagy sem.
- Pilóta modell méret az biztos szabványos, az egyenruhák kiegészítők változatossága miatt viszont tuti nem közös könyvtárból dolgoznak.
- A füst, gőz és kondenzációk és hasonló részecske effektek valószínűleg központi könyvtárból dolgoznak, bár itt lehet gép specifikus dolog is. Hogy mennyi részecske és milyen felbontású textúrával dolgozzon, az biztos, hogy előírt maximumot kell tartani.
- FM, CEM, DM-ről nem mondanék semmit, nem tudom DCS pontosan hogy épül fel. Biztos, hogy amit lehet, azt központosítanak ők is, de nagyon sok mindent a géphez kell programozni. -
#29235 A függesztmények pilonok, a pilota modelje, ezeket bármelyik amcsi vagy nyugati tipusu gépre használhatnák a EDe verziót.De akár a katapult ülés is lehet ilyen, ha azonos tipust használ .
Meg a régiek ha jól tudom texturát használtak az utánégetőre, de a tomcat mintha már inkább practicle effektel operál mint a pára kiválásnál.
Meg természetesen a texturázás az egyedi, de az már lehetne egységes, hogy mindegyik ugyan azokat a layereket tudják használni esetleg a PBR is elérhető legyen mindre.
Meg a háttérben a hajtómű specifikus dolgok. elvégre mindegyik hajtómű azonos elven működik, igy az alap mindnek lehetne ugyan az csak a tipusra jelemmző adatokkal kéne kiegésziteni.
DE mig mondjuk egy FC3as gépen mondjuk 5 adatbol számol addig a tomcatnél meg 100 adatot vesz figyelembe és sokkal nehezebb kezelni , hogy ne pompázsoljon be mint egy rosszabbul modellezettet. -
#29234 Mi az ami nem típus specifikus szerinted?
Az, hogy a 3D modell és a textúra hogy néz ki, az elsősorban attól függ, hogy mennyire ügyes és tehetséges a modellező és a textúrázó. Az előzetes leírások, segédletek inkább csak a műszaki paramétereket tartalmazzák, adhat támpontokat, hogy mennyire legyen használt vagy új a modell, még mintaképeket is mellékelhetnek egy rakattal, de művészi vonatkozásban nem tudja a textúrázó helyett megmondani, hogy hova milyen koszt vagy rozsdát tegyen. Ilyenekre megtanítani nem a műszaki leírás fogja. Ráadásul Heatblur -osok mindent szkenneltek eredeti gépekről, nem kézzel festettek. Az megint egy másik kategória. -
#29233 talán , mert egy közös platformot használnak és edének is ez kellene hogy legyen a célja, hogy minden updatelve legyen ami nem tipus specifikus.
a 3rd party szerzödésben jó lenne ha lenne olyan kitétel, hogy a nem tipus specifikus dolgokat meg kell osztani.
De akár az is jobb megoldás lenne, ha ede csinálná ezeket és a külsösöknek ezeket kéne használni a saját modulokhoz.
Ez jobb megoldás lenne, mert a külsösöknek nem kéne minden részt ujra legyártani, gyorsabb lenne a fejlesztés és egységesebb a kinézet.Meg talán könnyebb lennne javitani a gondokat is. -
#29232 A modulok licencelése szerintem nem teszi lehetővé, hogy ide-oda másolgassanak cuccokat. Fegyverek, amiket kvázi ED biztosít, az lehet ugyanaz, de a külsős stúdiók tuti, hogy nem egy nagy közösbe dobják be a saját cuccaikat. Miért is tennék? -
#29231 Igen, láttam, csak azért írtam nehogy a terrain shadow-ot is visszakapcsolja. -
#29230 azért az nehéz elvitatni az EDÉtol hogy nagyon szép és részletes a látvány és azért ha nem is mindig, de nagy átlagban egész jol megy .
Nem is olyan régen még az átvezető animációk renderelt filmjei sem néztek ki igy vagy a mozik CGI jelenetei.
Némelyik képen mintha igazi fénykép lenne.
Nekem csak egyvalami nem tetszik, hogy azokat az ujitásokat amiket egy egy uj modul hoz nem kapja meg az osszes modul ami használhatná azokat.Ha végre minden gépet egy szintre tudnák felhozni az lenne az igazi, mmégha csak grafikailag is.
Gondolom a pilóta modellek sem kerülnek át másik modulokba, vagy a részletesebb fegyverek. vagy az utánégető és ezek csak a grafikai elemek, de a háttérben lévő egyéb dolgok is csak a tomcat sajátja lesz gondolom. ami még feltünt a videoban , hogy az éjszakai képeken nincs semmilyen világitás a gépen, se fluoreszkáló se kötelékfény. remélem azért mert változtatnak rajta, mert a mostaninál, olyan mintha valami nagy léggömb lenne a lámpák helyén. -
#29229 Az valóban, de a #29180-ban a sima Shadows is Flat only-n van, na az nagyon hazavágja a kabinban az árnyékokat, lehet, hogy a #29221-ben tapasztalt MiG-21 kabin megjelenítési problémát is ez okozza
Utoljára szerkesztette: sure, 2018.10.09. 18:32:28 -
#29228 Az a furcsa, hogy a CPU olyan 25-30%-on ketyeg, mondjuk lehet, hogy magonként kellene nézni, hátha csak valamelyik process akad ki. De i7 7700K-n 4.5 GHz-en nem hinném, hogy 1070-est ne tudná kihajtani, ha kellene... -
Solt #29227 99%, hogy szoftveres cpu limit... egyszerűen túl sok info a DX11-nek. -
#29226 Terrain Object Shadows fontos, hogy "flat" legyen, az rengeteg fps-t hoz. -
#29225 A HDD SSD normál esetben csak a betöltésnél kellene, hogy faktor legyen, mivel a programok alapvetően a rendszer memóriából futnak. Ha RAM-ból használsz kevesebbet, akkor többször nyúlhat a winyóhoz, az qrva nagy akadásokat okozhat, de azok egyszeri esetek. Jellemzően amikor valami nagyobb csomagot betölt, pár másodpercig álla a játék, utána fut tovább rendesen (memóriából).
Amikor 2-3 másodpercenként meg-megáll (épp nemrég linkelt erről egy videót Zotya) az más jellegű probléma, nálam a GPU terhelés ugrált, és amikor ott jelzett a kihasználtságban esést, akkor bezuhant az fps is (1070-esen). Ennek okát nem tudtam még pontosan behatárolni, de többnyire földi harcok környékén lesz nagyon zavaró.
A 2.x óta 16 GB RAM az ajánlott, de ha sok minden zajlana a küldiben, akkor 32 GB RAM. 8 GB -ot abszolút minimum grafikához írják csak.
Az SSD meg azért fontos, mert az egész a pályát és a missiont azelőtt kell feldolgoznia és memóriába töltenie, mielőtt időtúllépéssel kidobna. Azt megoldásnak szoktán írni, hogy ugyanazon a pályán indíts egy quick missiont, akkor mindent betölt és ezután az online belépés is gyorsabb lesz. -
#29224 Anizotróp szűrés még mehetne rá (videós beállítások, a kép a beállításaidról nálam nem jelenik meg)
(edit - közben megjelent, és ott már látom, 16x-on van)
oké, egy ezernyócvanas karival menjen is így...csak a VGA többet ér, mint jelenleg Balázs harminc háromszázer forintos gépe
Utoljára szerkesztette: sure, 2018.10.09. 17:54:16