DCS World 1.5, 2.0 und 2.5

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.

 

Genau das ist ja der Punkt, du hast Recht.

Da das aber natürlich ein irrer Aufwand wäre versucht man das bestehende anzupassen, was eben immer mit Kompromissen verbunden ist.

Eine Neuentwicklung ist technisch oft die bessere Wahl.

Finanziell aber seltenst machbar. Um beim Hausbau zu bleiben. Reiß mal ein Haus ab indem Mieter sind und sag, "Bald kommt ein neues besseres Haus".

Achja die Mieten werden dann viel teurer da wir den Abriss zahlen müssen.

Miete während der Arbeiten zahlt natürlich auch keiner...

 

Es ist halt eine Zwickmühle. Viele Menschen die nicht Programmieren verstehen die Problematiken nicht.

Wissen nicht was über Jahre/Jahrzehnte gewachsene Software bedeutet. Über Jahre/Jahrzehnte angesammeltes Expertenwissen.

Gerade bei alter Software gibt es keine/kaum Dokumentation was wie warum so programmiert wurde...

 

Wenn man beliebig viel Geld zur Verfügung hat, würde man parallel eine neue Software entwickeln. Die neusten Softwarekonsturktionstechniken verwenden etc.

Dann müssten man aber auch das Geld über haben um in X Leute Y Jahre zu investieren...

Eine Neuentwicklung ist technisch oft die bessere Wahl.

Finanziell aber seltenst machbar. Um beim Hausbau zu bleiben. Reiß mal ein Haus ab indem Mieter sind und sag, "Bald kommt ein neues besseres Haus".

Achja die Mieten werden dann viel teurer da wir den Abriss zahlen müssen.

Miete während der Arbeiten zahlt natürlich auch keiner...

 

Es ist halt eine Zwickmühle. Viele Menschen die nicht Programmieren verstehen die Problematiken nicht.

Wissen nicht was über Jahre/Jahrzehnte gewachsene Software bedeutet. Über Jahre/Jahrzehnte angesammeltes Expertenwissen.

Gerade bei alter Software gibt es keine/kaum Dokumentation was wie warum so programmiert wurde...

 

Wenn man beliebig viel Geld zur Verfügung hat, würde man parallel eine neue Software entwickeln. Die neusten Softwarekonsturktionstechniken verwenden etc.

Dann müssten man aber auch das Geld über haben um in X Leute Y Jahre zu investieren...

 

 

Da geb ich dir zu hundert Prozent recht.

Aber in unserem speziellen Fall hier, möchte ED doch sicher DCS noch weit über 10 Jahre betreiben. Und sie hätten im Moment ja auch ein laufendes System mitdem die "Mieter" arbeiten können, also wäre es doch sinnvoll eine Neuprogrammierung zu starten, zumindest in meinen Augen.

Da du ja auch sagtest, dass die Umprogrammierung sehr schwer und auch zeitaufwendig sei.

So seh ich das zumindest.

Vielleicht tun sie es ja mit 2.5 ...

so lange wie wir schon warten müssen ...

 

1.5 stabile Umgebung

2.1 Test neuer Engines und Maps

2.5 Zusammenschluß mit neue Architektur Multi Core, Multi Threads und Multi KI

 

Der Zeitpunkt wäre günstig wie nie :smilewink:

 

Und damit keiner Schiß bekommt haben sie es auch nicht 3.0 genannt :music_whistling:

 

Ach und noch etwas aus eigener Erfahrung:

man hat noch nie ein altes System modern umgestalten können ... es bleibt immer etwas altes störendes allastiges übrig ...

aber --- neue Systeme sind manchmal auch nicht besser :)

Edited November 21, 2017 by caponi

Was mann machen kann ist das Flugmodell getrennt berechnen zu lassen, sowie andere Dinge wie den Sound, die für sich oft schon eher in sich geschlossen sind.

Schwieriger ist es nachträglich dinge wie die Grafik zu splitten.

Für den Multiplayer könnte man darüber nachdenken die KI auf einen anderen Prozess auszulagern. In Spielen wie ARMA wird das schon lange über einen Headless Client gemacht.

Es ist normalerweise nicht das Modell oder die Grafik die die fps sinken llassen sondern die KI. Darum macht es einen so großen Unterschied wenn man die Einheiten bis sie gebraucht werden nur als Modell auf der Map hat, im Vergleich zu aktiven Gruppen.

Da geb ich dir zu hundert Prozent recht.

Aber in unserem speziellen Fall hier, möchte ED doch sicher DCS noch weit über 10 Jahre betreiben. Und sie hätten im Moment ja auch ein laufendes System mitdem die "Mieter" arbeiten können, also wäre es doch sinnvoll eine Neuprogrammierung zu starten, zumindest in meinen Augen.

Da du ja auch sagtest, dass die Umprogrammierung sehr schwer und auch zeitaufwendig sei.

So seh ich das zumindest.

Deswegen haben sie ja diesen Prozess bereits durchlaufen und EDGE entwickelt, eine moderne Grafikengine die nicht mehr auf DX9 basiert. Deren Implementierung erleben wir gerade... Nur hat sich während der "Bauphase" die Technik weiterentwickelt.

Um beim Hausbeispiel zu bleiben, das Vorkriegsgebäude wurde durch ein Haus aus Beton mit Iso-Fenstern ersetzt, die Einbauten der Sanitäranlagen, Kabelfanschluss etc. läuft. Wir werden nun erstmal eine längere Zeit in dem "neuen" Haus leben müssen, bevor jemand beginnt das Geld in ein neues Niedrigenergiehaus, mit modernsten Techniken zu investieren?

 

Aber da ich letztens erfahren hab, daß auch ein Industrie CAD-Programm eines Namhaften Anbieters noch weit von "Multi-Core" Nutzung entfernt ist und auch dort einfach "mehr CPU Leistung" empfohlen wird, fürchte ich wenn es um grosse Umgebungen oder Hoch-Polygone Modelle geht, wird es alles andere als einfach, da was mit mehreren Cores an einem Frame zu rechnen... So ein Bild auf dem Monitor kann halt in Echtzeit nur angezeigt werden, wenn alle Teile des Bildes zur Verfügung stehen, die Probleme der Kollisionsabfrage in der Spielelogik, hatte ich oben ja schon erwähnt.

 

Fazit: es ist eben nicht damit getan "mal eben" Multi-Core zu machen...

 

Aber ich glaube fest daran, dass die ED Developer das nicht "übersehen" haben und von uns "Fachleuten für die Entwicklung komplexer Flugsimulationen" darauf hingewiesen werden müssen, dass es jetzt Multi-Core CPUs gibt. ;)

Ich gehe auch davon aus, dass die Jungs bei ED nicht ganz blöd sind, so wie sie hier gern mal hingestellt werden.

Kaum einer hier unter uns ist Informatiker und selbst Ahnung von Softwareentwicklung hat nur eine Minderheit. Irgendwas nachgeplappert, was irgendwo im Netz stand ist natürlich schnell...

Wenns so einfach wäre hätte man es bereits so gemacht.

Und mich nervt die Performance auch, aber entweder ich nehm das eben hin und vertrau drauf, dass ED das hin bekommt oder ich höre auf klug zu scheissen und machs besser.

Letzteres kann ich leider nicht und da ich nicht auf Battlefield als Sim wechseln will muss ich mich halt damit abfinden, dass ich eine Alpha spiele...

Was mann machen kann ist das Flugmodell getrennt berechnen zu lassen, sowie andere Dinge wie den Sound, die für sich oft schon eher in sich geschlossen sind.

Schwieriger ist es nachträglich dinge wie die Grafik zu splitten.

Für den Multiplayer könnte man darüber nachdenken die KI auf einen anderen Prozess auszulagern. In Spielen wie ARMA wird das schon lange über einen Headless Client gemacht.

Es ist normalerweise nicht das Modell oder die Grafik die die fps sinken llassen sondern die KI. Darum macht es einen so großen Unterschied wenn man die Einheiten bis sie gebraucht werden nur als Modell auf der Map hat, im Vergleich zu aktiven Gruppen.

Genau DAS kannst du NICHT auslagern, da das "Flugmodell" die Position des Flugzeugs und seiner Lage im Raum beeinflusst, und das in Echtzeit!

Ich möchte dich erleben, wenn deine Salve mit der Kanone am Gegner rechnerisch vorbei geht, während du sehen kannst, wie sie durch ihn durch geht... Sorry, Thread 2 kam erst kurz nach dem Schuss darauf, dass der Flügel woanders war.

 

Und dazu kommt die Interaktion mit der DCS World also Wind, Druck, Temperatur, Luftfeuchtigkeit, die direkt das Flugmodell beeinflussen (deswegen fühlt es sich so "realistisch" an).

 

Na klar kannst du es trotzdem auf mehrere Cores verteilen, nur warten dann eben alle Cores bei jedem Frame/Cycle auf die anderen die an der Scene beteiligt sind.

 

Ich Klaue da mal von mir selbst ein Beispiel aus dem Englischen Forum:

 

Eine Rechenaufgabe lässt sich besser lösen, wenn man sie auf mehrere Rechner verteilt, richtig?

 

10-2*2+8/2 = ? Nicht allzu schwer, es gibt auch praktische Regeln die Aufgabe in parallele Schritte aufzuteilen.

 

Step1) 8- Ergebnis von Step2

Step2) 2*4

Step3) Ergebnis von Step1 + Ergebnis von Step4

Step4) 8/2

 

Jeder Rechner nennen wir sie A,B,C und D bekommt einen der Steps.

Wie bei einer CPU darf aber jeder Thread (ABCD) nur einmal wenn er dran ist sein Ergebnis in das RAM liefern, sagen wir mal die Rechner dürfen immer nur einer an die Tafel und ihr Ergebnis Anschreiben.

 

Rechner A beginnt und kann ohne Ergebnis von B nichts machen und setzt sich wieder. B geht nach vorn und schreibt 8 auf.

C geht nach vorn hat weder das Ergebnis von Step1 noch das Ergebnis von Step4.

D geht nach vorn und schreibt 4 auf.

Endlich kann A wieder nach vorn und schreibt 6 auf.

B Wink kurz weiter und C steht auf der nun das Ergebnis 10 an die Tafel schreibt.

 

Zeit der ganzen Multi-Core Rechnerei ? Deutlich länger als ein Rechner gebraucht hätte, da er nicht auf die andern hätte warten müssen.

 

Das ist natürlich stark vereinfacht, aber beschreibt das ursächliche Problem.

Parallelisierung ist eine Lösung, die nicht zu jedem Problem passt.

Gutes anschauliches Beispiel!

 

10-2*2+8/2 = ? Nicht allzu schwer, es gibt auch praktische Regeln die Aufgabe in parallele Schritte aufzuteilen.

 

Step1) 8- Ergebnis von Step2

Step2) 2*4

Step3) Ergebnis von Step1 + Ergebnis von Step4

Step4) 8/2

 

Schlampig geschrieben, oder versteh ich das wirklich nicht?

Dass nicht Alles parallelisiert werden kann, ist offensichtlich, aber:

 

* Entscheidungsfindung der KI

* neue Position im Raum für alle Einheiten berechnen.

* LOS für alle Einheiten berechnen.

 

lässt sich gut parallelisieren.

Dass nicht Alles parallelisiert werden kann, ist offensichtlich, aber:

 

* Entscheidungsfindung der KI

* neue Position im Raum für alle Einheiten berechnen.

* LOS für alle Einheiten berechnen.

 

lässt sich gut parallelisieren.

Du meinst die Position der Objekte (Flugzeuge, Gebäude, Bäume, etc.) im Bezug zueinander, zum Terrainmesh und nicht zu vergessen alle Geschosse... dann wartest du auf dem Core der aus dem ganzen Kram die Kollisionen prüft?

Oder sollten die ED Devs das einfach nur nicht kapiert haben und das ist ganz einfach??? ;)

 

KI bietet sich an, Logistik, Warehouses, Schadensauswirkungen ebenfalls... Hatte ich weiter oben bereits erklärt.

Du meinst die Position der Objekte (Flugzeuge, Gebäude, Bäume, etc.) im Bezug zueinander, zum Terrainmesh und nicht zu vergessen alle Geschosse... dann wartest du auf dem Core der aus dem ganzen Kram die Kollisionen prüft?

Oder sollten die ED Devs das einfach nur nicht kapiert haben und das ist ganz einfach??? ;)

 

KI bietet sich an, Logistik, Warehouses, Schadensauswirkungen ebenfalls... Hatte ich weiter oben bereits erklärt.

 

Was glaubst du dauert länger: Position für 1200 Objekte sequenziell auf einem core berechnen, dann für 1200 Objekte die Kollisionsabfrage auf einem core machen, oder Position für 1200 Objekte parallel auf 4, (8 oder 16 cores, dahingehend werden ja derzeit CPUs weiterentwickelt) berechnen, dann die Kollisionsabfrage für 1200 Objekte auf einem core machen?

 

Ich hoffe, dass ED sich mit den Möglichkeiten beschäftigt, wie sie die GHz vs. Multicore Thematik angehen.

 

Was war mit deinem Beispiel, kannst du darauf eingehen?

Nur mal so (ich arbeite in der Qualitätssicherung Software Entwicklung von großen Systemen im safety Bereich) : identifizieren der gebiete ist eins, aber hört auf diejenigen, die sagen, dass es kompliziert ist.

 

 

Probiert mal auf einer vorhandenen Code Basis sowas zu verändern.

Das Beispiel mit Fundament unter dem Haus ändern stimmt hier ziemlich gut. Ich behaupte mal, dass sich hier gerade mal 5% vorstellen können was das ein verfluchter Aufwand ist....

 

Gesendet von meinem F5121 mit Tapatalk

So einfach, wie du dir die Positionsbestimmung gerade vorstellst ist es einfach nicht, das sind recht komplexe Rechnungen, die dahinter stehen und die bei der geringsten Asynchronität völlig aus dem Ruder laufen würden.

Bei deinem Beispiel hast du zB das Problem, dass der zweite Core, der die Kollisionsabfrage macht, auf den ersten warten muss, weil er die Daten braucht. Das führt schon zu einer kleinen, aber doch vorhandenen Desynchronisation. Das kann sich über die Zeit dann hochschaukeln.

Hinzu kommt, dass du dann jedes Objekt mehrfach anfassen musst. Erst berechnest du die Position, dann evtl die vektoriellen Kräfte durch Schub, Schwerkraft,..., dann machst du die Kollisionsabfrage, dann wieder was neues, vlt Windeinfluss...

Und jeder Core muss wieder auf das Objekt zugreifen. Da stellt sich mir die Frage, ob du damit wirklich Geschwindigkeit gewinnst, oder den Prozess nicht sogar verlangsamst.

Das übersteigt weit meine recht einfachen Fähigkeiten, was Development angeht, aber wie schon gesagt, ich gehe davon aus, dass ED gute Gründe dafür hat, warum es so gemacht wird, wie es passiert und nicht anders.

Mit der Einführung von EDGE ist ja schon einiges passiert und einige Prozesse tatsächlich parallelisiert worden.

So einfach, wie du dir die Positionsbestimmung gerade vorstellst ist es einfach nicht, das sind recht komplexe Rechnungen, die dahinter stehen und die bei der geringsten Asynchronität völlig aus dem Ruder laufen würden.

Bei deinem Beispiel hast du zB das Problem, dass der zweite Core, der die Kollisionsabfrage macht, auf den ersten warten muss, weil er die Daten braucht. Das führt schon zu einer kleinen, aber doch vorhandenen Desynchronisation. Das kann sich über die Zeit dann hochschaukeln.

Hinzu kommt, dass du dann jedes Objekt mehrfach anfassen musst. Erst berechnest du die Position, dann evtl die vektoriellen Kräfte durch Schub, Schwerkraft,..., dann machst du die Kollisionsabfrage, dann wieder was neues, vlt Windeinfluss...

Und jeder Core muss wieder auf das Objekt zugreifen. Da stellt sich mir die Frage, ob du damit wirklich Geschwindigkeit gewinnst, oder den Prozess nicht sogar verlangsamst.

Das übersteigt weit meine recht einfachen Fähigkeiten, was Development angeht, aber wie schon gesagt, ich gehe davon aus, dass ED gute Gründe dafür hat, warum es so gemacht wird, wie es passiert und nicht anders.

Mit der Einführung von EDGE ist ja schon einiges passiert und einige Prozesse tatsächlich parallelisiert worden.

Zur Veranschaulichung kann man sich in DCS mal ein Replay einer umfangreichen Mission anschauen. Da sieht man dann oft sehr eindrucksvoll was für einen Unterschied so eine kleine Asynchronität haben kann und wie sich das über Zeit hochschaukelt :D

Edited November 22, 2017 by QuiGon

Exakt, der alte Gauß und sein Fehlerfortpflanzungsgesetz lassen herzlich grüßen :D

 

Allerdings, um direkt ins nächste Thema zu schlittern, ist es mir nach wie vor ein Rätsel, warum die Replays auf diese Art gespeichert werden und nicht einfach mit der Fluglage der Geräte, unabhängig von anderen Gegebenheiten, wie das zB bei X-Plane der Fall ist. Müsste das nicht sogar speicherschonender sein, als die DCS-Lösung?

Welchen Grund hat ED für dieses sehr fehleranfällige System, weiß das wer, kann mir eventuell sogar Vorteile nennen?

So einfach, wie du dir die Positionsbestimmung gerade vorstellst ist es einfach nicht, das sind recht komplexe Rechnungen ...

 

Und profitieren daher von der Parallelisierung.

 

Die Komplexität ist selbstverständlich hoch und ein nachträgliches Einbauen potenziert das Ganze noch. Die Chancen das die bestehende Engine grundlegend verändert wird, sind dementsprechen niedrig und das ist auch vernünftig.

 

Aber ich denke auch, dass ED über kurz oder lang eine neue Engine entwickeln muss, die mit der Hardware Entwicklung (statt schnellerer cores, einfach mehr davon) besser harmonisiert.

So schlimm am Limit sind die Prozessoren doch gar nicht...

So schlimm am Limit sind die Prozessoren doch gar nicht...

Nee, höchstens einer ;)

Aber positiv sehen. Sind noch genug Threads frei, so dass man während einer ruhigen Flugphase auf dem zweiten Monitor mit Photoshop an seiner Livery für den nächsten Flug arbeiten kann :)

 

Die Jungs von ED machen dat schon mit dem Multithreading. Potential dafür hat DCS. Warum das nicht einfach wird, wurde schon gut erklärt.

Aber positiv sehen. Sind noch genug Threads frei, so dass man während einer ruhigen Flugphase auf dem zweiten Monitor mit Photoshop an seiner Livery für den nächsten Flug arbeiten kann :)

.

 

Hey, daran hab ich noch nie gedacht...! :thumbup:

Von meiner Seite sei noch anzumerken, dass die Version 2.5 nichts anderes ist als eine 2.1 plus eine zusätzliche Karte in Form der überarbeiteten Kaukasuskarte, plus die üblichen Bugfixes. Die ganze Grafikgeschichte ist schon gelaufen.

 

Gesendet von meinem GT-I9505 mit Tapatalk

@Borin - stimmt so nicht ganz, da unter 2.5 u.a. noch eine ganze Menge ueberarbeiteter Effekte kommen werden, was der Performance auch zugutekommen wird.

@Borin - stimmt so nicht ganz, da unter 2.5 u.a. noch eine ganze Menge ueberarbeiteter Effekte kommen werden, was der Performance auch zugutekommen wird.

Da gebe ich dir recht, wobei die Effekte in erster Linie besser aussehen werden, gleichzeitig aber mit Sicherheit mehr Rechenschritte benötigen werden.

 

Gesendet von meinem GT-I9505 mit Tapatalk

Wurde nicht gesagt das die Performance quasi gleich bleibt, da die Engine besser optimiert ist(?)