DCS World 1.5, 2.0 und 2.5

[mwd2]

SoH wird wahrscheinlich die selbe Größe wie NTTR haben, aber da es mehr Wasser hat sollte es eigentlich besser laufen!?

Hängt natürlich von der Anzahl der 3D-Objekte ab, die zu Beginn schon auf der Karte sind.

[ben_der]

I mean this:

 

The DCS maps have a detailed portion, for SOH is 550x500, and a basic not detailed space. Terrain outside the detailed space is not useful because the low res and ugly looking BUT for SOH there is one thing different. THE SEA.

 

The sea has the same detail and aspect everywhere and because this map can be a Carrier Operations map you can place a fleet anywhere on the map. I dont care if is outside the detailed square, Is only sea.

 

This is de SOH editors map. You can se the Arabic Sea on the East. Place the 5th Fleet over there at some point.

 

 

Then start counting:

 

Start up, INS alignment, take off, rejoin, climb and ferry to the initial refuel point ( all outside the Iranian territorial waters ), refuelling, ferry to a point of descent before the Iranian sea border, low level apprach to Lar, attack, low level egress, climb outside the sea border, refuel, ferry back to the carrier, land.

 

 

This could be more or less 160 minutes or even more. An IMHO more than enough for any mission. Take offs, traps, two refuels, attacks, ferrys, climbs, low level ingress.

 

A 1800 km mission length is not a telephone both for me.

 

 

Das ist aus dem DCS Maps, SOH thread.

 

Als Referenz:

Nellis AFB - Tonopah Test Range Airport sind ~230km ca.

Abu Dhabi bis an die Spitze der Landzunge nord nord östlich davon sind 295km.

Edited November 17, 2017 by VFlip

[ram0506]

Wo kann ich mir ungefähr die Performance über dem "neuen". Kaukasus vorstellen? Was erwartet ihr? (Normandy habe ich nicht, deshalb kein Vergleich)

 

Sehr interessante Frage, die ich mir auch schon die ganze Zeit stelle.

Um ehrlich zu sein, erwarte ich keine besonders gute Performance der neuen Kaukasus-Karte. Einen kleinen Vorgeschmack gibt`s nämlich schon mit der Normandie-Karte, auf der man sehr schön erkennen kann, welchen Einfluss eine hohe Anzahl an Bäumen auf die Performance hat. Der überarbeitete Kaukasus könnte da mit den vielen Wäldern nochmal eins drauf legen.

Zu bedenken ist auch, dass künftig Deferred Shading zum Standard wird und nicht mehr abgeschaltet werden kann. Das DS wirkt sich, wie wir alle wissen, leider ziemlich fatal in Kombination mit dem MSAA auf die Performance aus. Und wie wir gestern in den Übersetzungen aus dem russischen Forum gelernt haben, wird ED das Anti Aliasing wohl nicht an das DS anpassen.

Das alles bereitet mir, gelinde gesagt, ziemlich Kopfschmerzen, wenn ich an die Kaukasus-Karte denke. Vor allem weil ich mittlerweile ausschließlich in VR unterwegs bin.

Aber warten wir`s ab, evtl. zieht ED ja doch noch einige Überraschungen aus dem Hut?:unsure:

[QuiGon]

Das ist aus dem DCS Maps, SOH thread.

 

Als Referenz:

Nellis AFB - Tonopah Test Range Airport sind ~230km ca.

Abu Dhabi bis an die Spitze der Landzunge nord nord östlich davon sind 295km.

 

Wags hat dort auch nochmal ein anderes Bild zur Map geposted:

To avoid any confusion and be as transparent as possible, this image shows most of the map.

 

The general operations area for the carrier groups would be in the Arabian Sea.

 

[FishDoctor]

Das alles bereitet mir, gelinde gesagt, ziemlich Kopfschmerzen, wenn ich an die Kaukasus-Karte denke. Vor allem weil ich mittlerweile ausschließlich in VR unterwegs bin.

Aber warten wir`s ab, evtl. zieht ED ja doch noch einige Überraschungen aus dem Hut?:unsure:

 

Da bist du nicht allein, und in letzter Zeit sinds keine schönen Überraschungen...

[Mking]

Ich glaube da ist viel im verborgenen was die aktuelle entwicklung betrifft! Ich hoffe das entlich mal das alt enter problem gelöst wird. Glaube das wir schon mit überraschungen rechnen können.

[caponi]

hoffentlich positiver Art :music_whistling:

ED hat aber auch immer wieder die Performance-Kurve bekommen, also abwarten und 2.5 geniessen

[Canadus]

Sehr interessante Frage, die ich mir auch schon die ganze Zeit stelle.

Um ehrlich zu sein, erwarte ich keine besonders gute Performance der neuen Kaukasus-Karte. Einen kleinen Vorgeschmack gibt`s nämlich schon mit der Normandie-Karte, auf der man sehr schön erkennen kann, welchen Einfluss eine hohe Anzahl an Bäumen auf die Performance hat. Der überarbeitete Kaukasus könnte da mit den vielen Wäldern nochmal eins drauf legen.

Zu bedenken ist auch, dass künftig Deferred Shading zum Standard wird und nicht mehr abgeschaltet werden kann. Das DS wirkt sich, wie wir alle wissen, leider ziemlich fatal in Kombination mit dem MSAA auf die Performance aus. Und wie wir gestern in den Übersetzungen aus dem russischen Forum gelernt haben, wird ED das Anti Aliasing wohl nicht an das DS anpassen.

Das alles bereitet mir, gelinde gesagt, ziemlich Kopfschmerzen, wenn ich an die Kaukasus-Karte denke. Vor allem weil ich mittlerweile ausschließlich in VR unterwegs bin.

Aber warten wir`s ab, evtl. zieht ED ja doch noch einige Überraschungen aus dem Hut?:unsure:

 

Da bin ich voll bei dir; die vielen Bäume machen mir schon etwas Sorgen, im neuen Kaukasus. Bei SoH sind es dann die riesen Städte mit den vielen Gebäuden. Das DS nicht mehr abschaltbar sein wird, kann ich aus Entwicklersicht zwar verstehen, doch nutze ich auf der NTTR DS zZ gar nicht, weil mir das zu hell ist und ich dann das HUD nicht mehr ablesen kann.

 

Ich habe immer noch die leise Hoffnung, dass die Entwickler (auch bei den zivilen Sims) endlich verstärkt auf MultiCore setzen. Da schlummern noch 3 weitere Kerne in meinem Prozessor. Von Hyperthreading rede ich da noch gar nicht.

 

Die 1070 hat mir erstmal Luft verschafft; aber 2018 muss der Prozessor noch dran glauben. :music_whistling:

[tintifaxl]

Wegen der Performance würd ich die nächsten Jahre eher auf die Hardwarehersteller setzen, als auf ED. Sie basteln jetzt schon ewig an der neuen Engine rum und werden die sicher nicht so schnell auf multithreading umbauen.

[Manitu03]

Wegen der Performance würd ich die nächsten Jahre eher auf die Hardwarehersteller setzen, als auf ED. Sie basteln jetzt schon ewig an der neuen Engine rum

und werden die sicher nicht so schnell auf multithreading umbauen.

 

Das glaube ich leider auch...Frei nach Dante, *Ihr, die ihr hier eintretet, lasst alle Hoffnung fahren*. :(

[shagrat]

Wegen der Performance würd ich die nächsten Jahre eher auf die Hardwarehersteller setzen, als auf ED. Sie basteln jetzt schon ewig an der neuen Engine rum und werden die sicher nicht so schnell auf multithreading umbauen.

Basteln trifft es nicht so ganz. Mit 2.0 wurde die Engine (EDGE) implementiert. Damit ist es nun möglich, neue Effekte, Techniken zu nutzen und es wurde begonnen diese Techniken auf den neuen Maps einzusetzen. In der aktuellen Alpha Phase werden gerade jede Menge der alten Effekte durch neu-entwickelte ersetzt oder komplett neue eingeführt.

Im Rahmen der Alpha Phase muss das natürlich noch auf Performance optimiert werden.

Parallel werden weitere Maps entwickelt (SoH) und die neue Effekte mit den aktuellen Maps auf Performance optimiert und Bugs gefixt.

 

Ein normaler und langwieriger Prozess, der in eigentlich jedem Software Development existiert, nur dass wir als Endkunden in der Vergangenheit eher selten etwas davon mitgekriegt haben, weil es hinter geschlossenen Türen passierte.

 

Was Performance anbelangt, ist das Genre der Flugsimulation seit jeher berüchtigt die Hardware an ihre Grenzen zu bringen, auch vor DCS oder LOMAC war das "normal"...

 

Wir werden wie eigentlich immer, seit ich PC Spiele spiele, Upgraden und tunen müssen. Das war bei Wing Commander 2 so, bei Flight Unlimited (die Slideshow vor dem Herren, damals) und IL-2 Sturmovik als es rauskam, oder FSX der erst Jahre später so wirklich in voller Pracht fliegbar war, als die nötige Hardware dann entwickelt war.

Der Glaube ED muss nur ein bißchen Software-Magie tun und "Multi-Core" nutzen und dann habe ich in VR oder 8K 120fps (weil jetzt 30fps * 4 Kerne macht 120) wird sich nicht erfüllen.

 

Man kann sicher mit viel Arbeit Teile auslagern, erhöht aber das Risiko das die Synchronisation der Teile nicht glatt läuft...

 

Aber das ist Zukunftsmusik und wir werden abwarten müssen, was jetzt tatsächlich mit DCS 2.5 erreicht wird.

 

Danach wird die Entwicklung sicher nicht aufhören.

[funkyfranky]

Ich habe immer noch die leise Hoffnung, dass die Entwickler (auch bei den zivilen Sims) endlich verstärkt auf MultiCore setzen.

Ich habe vor nicht allzu langer Zeit von einem ED Tester in einem anderen Forum gehört, dass stark an Multithreading gearbeitet wird:

However, they're working hard under the hood with multithreading and the like so we will start seeing those changes coming in soon.

Und auch hier tauchte das schon des Öfteren auf. Wieviel da dran ist, kann ich nicht sagen. Aber ich denke, es besteht Grund zu mehr als "leiser" Hoffnung :)

Allerdings ganz bestimmt kein leichtes Unterfangen.

[easy_ci]

Da bin ich voll bei dir; die vielen Bäume machen mir schon etwas Sorgen, im neuen Kaukasus. Bei SoH sind es dann die riesen Städte mit den vielen Gebäuden. Das DS nicht mehr abschaltbar sein wird, kann ich aus Entwicklersicht zwar verstehen, doch nutze ich auf der NTTR DS zZ gar nicht, weil mir das zu hell ist und ich dann das HUD nicht mehr ablesen kann.

 

Vielleicht eine dumme Frage aber: die Gamma-Einstellung ist dir aber bekannt oder?

Weil wenn du da nen wert um 1.5 rum hast, finde ich das ausreichend. Es

wird halt auch das menschliche Auge simuliert,dass sich erst an die Helligkeiten anpasst. Wenn du längere Zeit im Cockpit rumschaust und dann raus dann siehst was ich meine

 

Ich kann von 2.1 nicht mehr auf 1.5 zurück... bin da mittlerweile bissl verwöhnt.

Edited November 18, 2017 by easy_ci

[schroedi]

Bis jetzt ist es ja so, dass man als Client bessere FPS hat als im Singleplayer, also die AI vom Server übernommen wird. Ich denke mal, dass versucht wird diese Servertasks auf einen anderen Thread zu bringen, damit man ein ähnliches Ergebnis im reinen Singleplayer Betrieb hat.

[Canadus]

Vielleicht eine dumme Frage aber: die Gamma-Einstellung ist dir aber bekannt oder?

Weil wenn du da nen wert um 1.5 rum hast, finde ich das ausreichend.

 

Jepp; habe da 1.5 eingestellt. Mgl. muss ich da noch etwas spielen. Habe ja erst mit der 1070 DS überhaupt wieder aktiviert.

 

Was Performance anbelangt, ist das Genre der Flugsimulation seit jeher berüchtigt die Hardware an ihre Grenzen zu bringen...

 

...bei Flight Unlimited...

 

Hach, Flight Unlimited, das hatte ich schon fast ganz vergessen... :D

 

Klar müssen wir bei Simulatoren immer in der Aufrüstungsspirale bleiben. Ich bin da ja auch schon fast 21 Jahre drin (oje... ich werd alt :cry:).

Ich hatte aber verstanden, dass die großen Schritte bei Prozessoren wohl erstmal ausbleiben und hoffe eben darauf, dass Entwickler eben erkennen, dass da in 99,9% der Rechner mehr als 1 Prozessorkern schlummert.

Aber beim Rest bin ich ja voll bei dir. Jedes Jahr wird eben was anderes ausgetauscht und aufgerüstet. Dieses Jahr eben die GraKa, nächstes Jahr wieder der ganze andere Rest. :music_whistling:

[f4l0]

Die Leistung eines einzelnen Kerns wird sich nicht mehr stark ändern. Da sind wir an physikalische Grenzen gestoßen. Die Richtung ist ganz klar Multi/Manycore. Problematisch ist es nur gute Software für solche Architekturen zu entwickeln.

Viele Programmierer denken sequentiell, ist ja auch nahe liegend. Erst mach A dann B und wir erhalten C. Möchte man nun parallelisieren müssen wir schauen ob es Abhängigkeiten zwischen A und B gibt. Falls dies der Fall ist, können sie ggfs nicht parallel ausgeführt werde...

 

Möchte man nun eine über Jahre/Jahrzehnte gewachsene Software parallelisieren muss man zu aller erst alle Abhängigkeiten aufdecken. Je nach Programmiersprache, -praktiken, -design ist es sehr schwer...

 

Wenn wir nun davon ausgehen, dass wir wissen welche Abhängigkeiten im Code bestehen geht es nun darum zu ermitteln welche Art von Parallelisierung überhaupt möglich ist.

 

Nachdem man theoretisch weiß was man machen müsste, gehts ans Implementieren. Hier muss man z.B. sicherstellen dass immer nur eine parallele Instanz Daten im Speicher verändert. Dies kann man z.B. durch so Barrieren sichern. Falls diese schlecht/fehlerhaft sind kann es aber sein dass sich alle parallelen Instanzen an den Barrieren mit warten beschäftigen und die parallele Anwendung langsamer als die sequentielle ist...

 

Ihr seht wie kompliziert es wird. Die Forschung versucht zwar schon seid Jahrzehnten mit einem 'automatischen' Ansatz die Sache zu lösen. Aber das klappt immer nur für spezielle Fälle...

[Ganesh]

Genau so ist es, mit unserer Lieblingssoftware :yes:

Danke Olaf, sehr schön erklärt! :thumbup:

[shagrat]

Yup, im Prinzip sind alle Tasks die irgendwie von Positionen/Kollisionen in Relation zu anderen Objekten oder dem World Mesh abhängen (sowas wie "landen", "Fahren", "Geschoss trifft Objekt/Boden", "Flugzeug/Fahrzeug kollidiert mit Objekt/Boden", "Radarstrahl kollidiert mit Objekt/Boden/Wolken"usw. und sofort), kaum zu parallelisieren.

 

Man möchte ja nicht, dass das "Ziel" mal etwas mehr rechts/links, mal etwas mehr vor/zurück erscheint, bis es beim nächsten Sync der Tasks wieder "korrekt" positioniert ist. Besonders wenn dabei die Kollision zwischen deinem Geschoss und dem Gegner aus versehen verpeilt wird...

 

Davon abhängige "Systeme" wie HUD-Anzeige von Positionen, Feuerleitrechner berechnet Trefferpunkt, Radar erfasst Objekte, fallen in die gleiche Kategorie.

 

Wäre schon doof, wenn das HUD den Vorhalt erst ne Sekunde später "korrekt" anzeigt, oder der Auslöseimpuls bei CCRP Bombing sich bei der Terrain-Höhe um ein paar Meter vertut und die Bombe daneben geht...

 

Soweit ich aus dem englischen Forum weiss, sind die auch schon dran, Teile der Sim, die nicht in Abhängigkeit zu Echtzeit sind auszulagern (Sound ist das erste gewesen). Da kann zum Beispiel die Ermittlung von Schadensauswirkungen bei der KI gut auch 1-10 Sekunden out-of-sync sein, explodiert der Motor beim Gegner eben erst 2-5 sekunden nach dem Treffer. oder das Warehouse/Logisitk System, solche Dinge halt.

 

Mal sehen was sie da so entwickeln. Klar muss auch sein, dass das nicht in 2-3 Monaten mal eben nebenbei passieren kann. Da steckt richtig viel Arbeit drin.

[f4l0]

Mal sehen was sie da so entwickeln. Klar muss auch sein, dass das nicht in 2-3 Monaten mal eben nebenbei passieren kann. Da steckt richtig viel Arbeit drin.

 

Genau. Noch eine Metapher die mir gerade eingefallen ist:

Habt ihr schon einmal ein Haus aus den 50/60igern renoviert? Oder einfach mal ein Loch gebohrt?

So in etwa ist es auch mit der Softwareentwicklung/weiterenwicklung von altem Code. Manchmal hat man Glück und der Handwerker/Architekt ist noch da und kann einem sagen dass die Wasserleitung quer durch die Wand geht. Manchmal aber nicht, man bohrt und steht unter Wasser :D.

Achja, und dann gibt es noch die Mieter des Hauses die ständig was neues wollen und sagen 'können Sie mal eben schnell?', 'das kann doch nicht so schwer sein' :D

 

 

Aber KI/Sound auslagern ist sicherlich gut, aber manchmal gibt es vielleicht querschneidene Seiteneffekte die das ganze dann wieder verkomplizieren...

Edited November 20, 2017 by f4l0

[shagrat]

:D

 

"...und als erstes das brüchige Fundament erneuern, bitte! Wie da steht das Haus drauf? Na und sooo schwer kann das ja nicht sein." :smartass:

[Einherjer]

:D

 

"...und als erstes das brüchige Fundament erneuern, bitte! Wie da steht das Haus drauf? Na und sooo schwer kann das ja nicht sein." :smartass:

 

 

 

Ja , schon mal versucht bei einem fahrenden Auto die Reifen zu wechseln? Ich will nicht sagen das es nicht geht, aber es ist sicher etwas kompliziert...

[caponi]

wenn wir über Parallelisierung reden, reden wir aber in einer Zeiteinheit von einem Frame ...

und bei vsync haben wir 60 davon pro Sekunde.

also reden wir noch noch um eine zeitliche Nichtsynchronität von 1/60 Sekunde

da darf das alles etwas ungenauer sein :music_whistling:

 

aber ja, ein Programm nachträglich zu parallelisieren nennt man heutzutage eine "Challenge" auf neudeutsch

[FishDoctor]

wenn wir über Parallelisierung reden, reden wir aber in einer Zeiteinheit von einem Frame ...

und bei vsync haben wir 60 davon pro Sekunde.

also reden wir noch noch um eine zeitliche Nichtsynchronität von 1/60 Sekunde

da darf das alles etwas ungenauer sein :music_whistling:

 

aber ja, ein Programm nachträglich zu parallelisieren nennt man heutzutage eine "Challenge" auf neudeutsch

 

1/60s wird aber spätestens dann zum Problem, wenn ein Prozess auf Variablen zugreifen will, die ein parallel laufender noch nicht oder nur veraltet gerechnet hat...

[f4l0]

Naja das inkorrekte 'Zugreifen' kann dann aber auch dazu führen dass das Programm abstürzt. Oder es zu einer stillen Datenkorruption kommt. Durch unzulässigen Zugriff überschreibt ein früherer Prozess einen aktuelle Daten. Fällt aber erst nach einer Zeit X auf und dann knallts...

 

Und über 1/60 oder irgendwelche anderen Frames zu argumentieren ist auch gefährlich.

 

Aber wir sollten zurück zu DCS und nicht eine Vorlesung zu Grundlagen der Programmierung...

Edited November 20, 2017 by f4l0

[Steph-JJ]

Die Leistung eines einzelnen Kerns wird sich nicht mehr stark ändern. Da sind wir an physikalische Grenzen gestoßen. Die Richtung ist ganz klar Multi/Manycore. Problematisch ist es nur gute Software für solche Architekturen zu entwickeln.

Viele Programmierer denken sequentiell, ist ja auch nahe liegend. Erst mach A dann B und wir erhalten C. Möchte man nun parallelisieren müssen wir schauen ob es Abhängigkeiten zwischen A und B gibt. Falls dies der Fall ist, können sie ggfs nicht parallel ausgeführt werde...

 

Möchte man nun eine über Jahre/Jahrzehnte gewachsene Software parallelisieren muss man zu aller erst alle Abhängigkeiten aufdecken. Je nach Programmiersprache, -praktiken, -design ist es sehr schwer...

 

Wenn wir nun davon ausgehen, dass wir wissen welche Abhängigkeiten im Code bestehen geht es nun darum zu ermitteln welche Art von Parallelisierung überhaupt möglich ist.

 

Nachdem man theoretisch weiß was man machen müsste, gehts ans Implementieren. Hier muss man z.B. sicherstellen dass immer nur eine parallele Instanz Daten im Speicher verändert. Dies kann man z.B. durch so Barrieren sichern. Falls diese schlecht/fehlerhaft sind kann es aber sein dass sich alle parallelen Instanzen an den Barrieren mit warten beschäftigen und die parallele Anwendung langsamer als die sequentielle ist...

 

Ihr seht wie kompliziert es wird. Die Forschung versucht zwar schon seid Jahrzehnten mit einem 'automatischen' Ansatz die Sache zu lösen. Aber das klappt immer nur für spezielle Fälle...

 

 

Ich hab ja keine Ahnung, aber ist es da nicht besser das Ganze komplett neu zu programmieren?

Ich meine auf lange Sicht hat das "ein Kern" System ja keine Zukunft.