Beiträge von runner78

  • Wie groß ist das Universum in KSP und wo ist das Ende?

    Ich habe den jetzt nur auf meinem Firmen Rechner im Büro, hier ist aber der C# Code, die Java Variante ist im Grunde das selbe:


    Code
    1. var w = new Stopwatch();
    2. w.Start();
    3. var two = new BigInteger(2);
    4. for (int i = 0; i < 1000000; i++)
    5. {
    6. var bi = new BigInteger(i);
    7. var result = two * bi;
    8. }
    9. w.Stop();
    10. Console.WriteLine($"BigInteger: {w.ElapsedMilliseconds / 1000f}");

  • Wie groß ist das Universum in KSP und wo ist das Ende?

    Zitat von Mr. Maxwell

    Jede Zahl egal ob Integer, double, long, Fließkommazahlen oder BigInteger muss vor jeder Berechnung erst in ein binäres Format umgerechnet werden. Also so was hier: 01010110101010110101010101010101...
    Stimmst du so weit zu?

    Warum sollte das vor jeder Berechnung geschehen? In der Regel Arbeitet man mit Variablen, die schon binär im Speicher liegen. Da braucht nicht viel Umgerechnet zu werden, außer z.B. bei Ein und Ausgaben (GUI usw.), das in Summe der ganzen Logik eines Programmes nicht ins Gewicht fällt. Und die CPU kann direkt mit den Binärdaten aus dem Speicher Rechnen.
    Bei einem BigInteger in C# werden die Bits intern als uint Array gespeichert. Da kann man den Prozessor nicht eben mal sagen, addiere Speicher X mit Speicher Y.


    Bei Java ist das nicht viel anders, ich habe das heute aus Interesse mal getestet, hatte im Grunde ein ähnliches Ergebnis, eigentlich schon sogar langsamer.
    In einer Schleife mit 1.000.000.000 Durchläufen einen Wert mit dem incrementierten schleifenzahl multipliziert
    c#
    double ca. 2,3 - 2,8 Sekunden,
    BigIneger ca. 26 - 29 Sekunden


    Java
    double ca. 2,4 - 2,9 Sekunden,
    BigIneger ca. 28 - 33 Sekunden


    Wenn man jetzt annimmt man hat in KSP 500 Orbitobjekte (Müll, Planeten usw.)
    Jeder Position besteht aus 3 Werten sind schon 1500 verschiedene Werte
    Nimmt man pro Physic-Frame 50 Rechenschritte pro Orbitobjeten an, sind das 75.000 Berechnungen
    bei 50 Physics-Frames in der Sekunde wären das 75.000 * 50 = 3.750.000 Berechnungen Pro Sekunde, bei meinem Test waren das 0,76 Sekunden, also bereits 76% der Verfügbaren Zeit verbraucht, kaum noch Luft nach oben, da ich auch einen Schnellen PC habe.
    Und 50 Rechenschritte pro Orbitobjekt ist vermutlich viel zu niedrig gehalten. Bei einer Orbitvorausberechnung könnte das auch locker 600-1000 Schritte sein.

  • Wie groß ist das Universum in KSP und wo ist das Ende?

    Wenn du jetzt dann mit der Genauigkeit von double rechnen willst, dann wird aus 1 = 100.000.000.000.000.000.
    Kerbin hat dann eine Apoapisis von 1.359.984.025.600.000.000.000.000.000
    Damit ist man schon weit über einen 64bit integer, man muss also BigInteger nehmen, aber dann hast du keine Hardware Unterstützung mehr.
    Ich habe das mal getestet, dabei waren floats am schnellsten, double am zweitschnellsten, dann int und long knapp dahinter. Mit ca. Faktor 10 langsamer als double weit abgeschlagen BigInteger.


    Und wenn man dann Berechnungen auf die GPU auslagert, dann ginge das mit BigInteger erst gar nicht, und GPUs sind wahre Fließkomma-Rechenmonster.

  • Wie groß ist das Universum in KSP und wo ist das Ende?

    Fließkommazahlen haben ein Komma, steht ja auch im Namen. Man braucht aber keine Komma-bit, da das Komma bei einer Fließkommazahl immer an der gleichen Stelle ist.


    Erkläre mir mal, wie du mit Ganzzahlen eine genaue Berechnung machen willst?
    Als simples Beispiel (10 / 3) * (3 / 101) ist mit einer Ganzzahl 0, als Kommazahl 0,0990


    Eine CPU kennt keinen BigInteger deshalb kann eine CPU auch keine Berechnungen damit Anstellen, das muss das Framework/Bibliotek wie oben schon gesagt selbst erledigen, und das kostet Performance die besonders bei Spielen sehr kostbar ist.

  • Wie groß ist das Universum in KSP und wo ist das Ende?

    Kleiner Korrektur von mir, ich bezog den Bereich auf den Basisdatentype "long", es gibt in .Net Framwork auch den Type BigInteger, aber erst ab Version 4.0 und somit mit Unity erst mit dem derzeit Experimentellen .Net updrade verfügbar.


    Dazu ist aber zu sagen, dass Berechnungen mit Basistype wie float, double, int, long usw. nativ auf der CPU durchgeführt werden, bei Objekten wie BigInteger muss das Framwork es selbst erledigen und ist damit um einiges langsamer.
    Und Physikalisch korrekte Berechnungen wie Orbits usw. ohne Kommastellen geht sowieso nicht.

  • Wie groß ist das Universum in KSP und wo ist das Ende?

    Zitat von Thomas P.

    Was passiert wenn man diese Grenze überschreitet? Keine Ahnung. Die obitalen Berechnungen könnten komplett versagen, aber ich würde es KSP zutrauen, dass einfach nur die Anzeige ausflippt und das Schiff trotzdem weiterfliegt.

    Bei einer Orbitalen Berechnungwirst du niemals den wert des maximalen Wert eines Double überschreiten... diese Zahl ist ... groß:


    179.769.313.486.232.000.000.000.000.000.000.000.000.000.000.000.000.000.000.000.000.000.000.000.000.000.000.000.000.000.000.000.000.000.000.000.000.000.000.000.000.000.000.000.000.000.000.000.000.000.000.000.000.000.000.000.000.000.000.000.000.000.000.000.000.000.000.000.000.000.000.000.000.000.000.000.000.000.000.000.000.000.000.000.000.000.000.000.000.000.000.000.000.000.000.000.000.000.000.000.000.000.000

  • Wie groß ist das Universum in KSP und wo ist das Ende?

    Unity benutzt für das Koordinatensystem Float (32bit, einfache Genauigkeit) Schlicht weil Grafikkarten darauf ausgelegt sind.
    KSP geht allerdings den Weg, dass für die Simulation im Hintergrund ein Koordinatensystem mit Doubles (64pit, Doppelte Genauigkeit) benutzt wird und dann für die Darstellung auf das normale Koordinatensystem umgerechnet und skaliert wird.
    KSP benutzt einige Tricks, z.B. mehrfache synchronisierte Kameras, z.B wenn man um einem Planeten fliegt wird das Raumschiff mit einer Kamera aufgenommen, Der Planet mit seinen Monden als Miniatur von einer anderen. Kerbin ist glaube ich dabei nur c. 100m im Durchmesser.


    Ein Biginteger in C# (64bit) hat einen Bereich von -9.223.372.036.854.775.808 bis 9.223.372.036.854.775.807, ist zwar schon einiges, aber Ganzzahlen haben hier nichts zu Suchen. Außer du gibst dich mit einem Spiel zufrieden wo sich die Objekte in Ein-Meter schritten bewegen. Und bei Berechnungen wir es dann extrem ungenau, weil jede Berechnung auf eine Ganzzahl gerundet wird.


    KSP wird wohl dann ein Problem haben, wenn ein Raumschiff so weit weg ist, dass es selbst in der skalierten Miniatur zu ungenau wird.


    KSP hält das Raumschiff nicht konstant auf der 0 Position, sondern wenn das Raumschiff Physikalisch berechnet wird, bewegt sich mit der realen Geschwindigkeit durch den lokalen Koordinatensystem und wird ab einen gewissen Abstand auf 0 zurückgesetzt. Das gab vor allem am Anfang einige Probleme, der Kraken lässt grüßen. Und wenn das Raumschiff dann zu schnell wird, dann geht geht halt gar nichts mehr.

  • Infos, Bilder und Kritik zu zukünftigen Updates

    War auch nicht ernst gemeint, sage aber niemals nie. Ich hätte damals auch nie für Möglich gehalten dass sie sich den Aufwand angetan haben, die Gesamte GUI mit dem neuem UI System neu zu Programmieren.
    Bezogen auf Entity Component System und das c# Jobsystem müssten sie im Grunde das gesamte Spiel umprogrammieren. Wäre vermutlich Weihnachten 2021 fertig...

  • Infos, Bilder und Kritik zu zukünftigen Updates

    Dass 1.3 kaum neuen Content brachte ist eigentlich kaum verwunderlich.
    Ein Spiel mal eben Multilingualtauglich zu machen ist sicher kein Zuckerschlecken und viel Arbeit unter der Oberfläche.
    Vermutlich gab es auch viele Anpassungen an der API als Vorbereitung des DLCs, außer nicht mehr laufende Mods merkt man als spiele davon natürlich nichts.


    Spiele wie KSP, oder auch Minecraft, die nach dem Release weiterentwickelt werden, werden immer breaking changes haben,
    aber von API-Programmierung haben Spieleentwickler generell kaum eine Ahnung habe ich das Gefühl.


    In der Regel werden bei APIs veraltete oder umbenannte Funktionen in vorherigen Versionen als deprecated gekennzeichnet, Änderungen werden dokumentiert usw.

  • KSP 1.1 Pre-Release veröffentlicht

    Hm, nach dem letzten Update wurde KSP fast anspielbar bei mir.


    VAB: Die Fairing machen bestimmte Parts darunter komplett unsichtbar:


    Am schlimmsten:
    In der Map fehlt öfters das Icon meines aktiven Vessels und man kann nicht darauf fokussieren. Stattdessen wird der nächste Planet/Mond fokussiert, oder er scrollt von alleine immer weiter weg.

  • Infos, Bilder und Kritik zu zukünftigen Updates

    Als damals die Ankündigung kam, dass man KSP auf Unity 5 Upgraden will, dachte ich mir noch "wäre nicht schlecht, wenn sie die GUI auf das neue System umstellen würden, aber der Aufwand wäre dann doch VIEL zu groß"
    Umso Überraschter war ich dann doch, als sie das tatsächlich machten. Der ganze bisherige GUI-code war so nur mehr für die Tonne, da das neue System mit dem alten nicht kompatibel ist. Die neue GUI musste von 0 an komplett neu erstellt werden.
    Dabei wäre die alte GUI unter Unity 5 auch noch lauffähig (Und das neu GUI System gibt es auch in der Unity-Version, die 1.0.x verwendet). Ein simpler Unity 5 port wäre mit Sicherheit schon im Herbst fertig gewesen.


    Andere Spiele, die noch im letzten Moment vor dem Releas auf Unity 5 upgedatet wurden, waren reine Ports, ohne Funktionalen umstellen wie bei KSP 1.1


    Ich frage mich, ob SQUAD sich den enormen Aufwand, den sie sich mit der GUI Umstellung aufgehalst hatten, auch bewusst war. Ich schon, deshalb Überraschen mich die Verzögerungen eigentlich überhaupt nicht und hatte fest mit ihnen gerechnet. :wink:

  • Infos, Bilder und Kritik zu zukünftigen Updates

    Zitat von Master_of_disaster

    Ich schließe mich Allan an. Ich habs mir aber schon bei 0.90 gedacht das KSP bald den Bach runter geht, aber eine Portierung auf eine Konsole? Das ist wohl echt der Todesstoß für KSP. Das Spiel hat so schon genug Probleme und Squad kommt auch nur schleppend voran. Und was ist jetzt mit 1.0.3 oder mit Unity 5 ?

    Unity 5 ünterstützt unter anderem auch die PS 4, nur zur Info. Also sollte eine Portierung nicht allzugroße Probleme machen.

  • Infos, Bilder und Kritik zu zukünftigen Updates

    Soweit ich das verstanden habe, benutzen sie das System, nicht das Raumschiff bewegt sich, sondern das Universum (so grob umschrieben), sonst würde das auch nicht funktionieren, da die Darstellung der Geometrie nur mit den float vectors von Unity funktioniert. Allerdings ist mein Englisch nicht das beste.
    Dazu ist die Weltraumkarte auch massiv scalliert und Kerbin nur 100 Meter groß :D

  • Infos, Bilder und Kritik zu zukünftigen Updates

    Zitat von seb-eisdrache

    bin mal gespannt wie sie den Multiplayer umsetzen Unity kann bis heute nicht den Datentyp "Double" (Basieren alle Koordinaten von KSP) per netzwerk übertragen, ggf. muss Squad dann auf eine andere Netzwerk Engine als die Unity interne zurückgreifen oder eine Eigene entwickeln.

    Wo Verwendet KSP Double als Koordinate? Das Koordinatensystem kommt von der Engine und Unitys Verctor3d besteht aus floats (wie auch in allen Anderen Engines), was aber von den normalen Grafikkarten vorgeben wird, da diese auf Berechnungen mit floats optimiert sind.


    Allerding bekommt Unity bald eine neue Netzwerkengine ( ich weiß jetzt nicht ob schon mit 5.1 oder 5.2)