Probleme mit dem Vollbildmodus F11

  • Hallo,

    ich hab mir eine Szene eingerichtet wo ein Zug per Blueprint und Triggern zum Bahnhof fährt und dort stoppt. Auch der Sound wie Brems und -Laufgeräusche der Drehgestelle werden per Trigger gesteuert. Funktioniert auch, doch sobald ich in den Vollbildmodus gehe funktionieren die Trigger entweder gar nicht oder verspätet. Versteh ich nicht. Ist das ein bekanntes Problem das der Vollbildmodus irgendwie sich negativ auf Blueprints auswirkt?

  • Eigentlich sollte sich da nichts in den BPs ändern, oder im Ablauf, oder wie auch immer.


    Das Einzige, was ich mir jetzt spontan vorstellen könnte, wenn du die Szene ausprobierst, der Zug arbeitet halt gerade seine Trigger ab, und dann schaltest du auf den Vollbildmodus um, wenn dein Rechner dann etwas schwach auf der Brust ist, arbeitet er die Trigger vielleicht alle nachträglich ab. Das wäre jetzt so meine spontane Analyse. Oder vielleicht ist dein Rechner allgemein etwas schwach für den Vollbildmodus. Aber grundsätzlich sollte der Windowedmodus eher mehr Rechenleistung erfordern als der Vollbildmodus.


    Also so ganz erschließt sich mir jetzt kein Zusammenhang zwischen Vollbild und Windowed und den BPs.

  • Wenn du zwischen Windowed und Fullscreen wechselst kann es für einen kurzen Moment zu einem massiven Drop und nachträglichem Spike an FPS kommen. Dementsprechend werden die Tick-Events anders ausgelöst.
    Wenn du die verwenden solltest ohne die Delta-Time zu berücksichtigen, könnte es daran liegen.

  • Delta-Time, noch nie gehört

    Hoffentlich wenigstens schon gelesen oder nur überlesen?


    Das ist die Zeit, die zwischen 2 Bildern (Frames) vergangen ist ^^


    Bei 60 FPS dauert ein Tick: 0,01667 Sekunden.

    Bedeutet also, sofern dein Spiel stabil auf 60 FPS läuft, vergehen zwischen jedem Bild das du auf dem Bildschirm siehst, eben diese 0,01667 Sekunden.

    Da dein Spiel aber höchstwahrscheinlich nicht immer genau 60 FPS hat, sind es mal mehr, mal weniger.


    Berechnung:

    1/60 = 0,01667

    (1 geteilt durch 60)

  • Dazu ist ein wenig umdenken nötig.


    Ich weiß ja nicht wie du jetzt im Einzelnen deine BPs umgesetzt hast.


    Aber grundsätzlich würde ich erst einmal eine Variable anlegen mit dem Namen DeltaTime, als Long (muss das glaube ich sein).


    Diese Variable setzt du gleich nach dem TickEvent, also du setzt dann eine Node Set DeltaTime und verbindest dann das Ganze mit der TickNode sowohhl den Execute- als auch den Werteausgang von DeltaTime.


    Und da wo du es dann benötigst, sagen wir, du möchtest, dass dein Zug eine Entfernung von 200 Einheiten zurücklegt in, sagen wir 5 Sekunden, dann musst du das mit der DeltaTime-Variblen berechnen.


    In diesem Fall (Distanz / Zeit) * DeltaTime. Und das dann an die Bewegungsnode heften, zum Beispiel SetPosition.


    So bewegt sich dein Zug immer um 200 in 5 Sekunden, egal wie lahm oder schnell der Rechner gerade dabei ist zu berechnen. Bei einem sehr langsamen Rechner ruckelt es dann natürlich entsprechend, weil er muss die Position ja in der vorgegebenen Zeit erreichen.

  • In meinen verwendeten Blueprints (Rail, Train Plugin vom Marktplatz) scheint die Delta Time berücksichtigt zu sein. Funktioniert aber irgendwie nicht oder wahrscheinlicher, es ist mir noch zu hoch. Ich hab aber eine Lösung gefunden. Ich fixiere die Bildrate einfach mit "t.maxfps 30". Egal wie viel ich jetzt im Level rumlaufe oder mit F11 umschalte, der Zug kommt immer genau auf der richtigen Stelle zum stehen.

  • Ich benutze ein Spline-basierendes Plugin (Train, Rail & Roller Coaster System). Das ist natürlich nichts für Anfänger wie mich, obwohl ich schon gute Fortschritte gemacht habe. (Drehgestelle geändert, ein weiteres Drehgestell hinzugefügt usw.) Mit meiner Lösung kann ich vorerst leben, da ich das Level eh erstmal nur zum anfertigen von Videos (Machinimas) benutze.

  • Funktioniert aber irgendwie nicht oder wahrscheinlicher, es ist mir noch zu hoch.

    Es ist auch etwas schwierig zu erklären. Aber vielleicht hilft ja ein Beispiel. Ich hoffe zumindest, dass es ist gut.


    Nehmen wir mal zum Beispiel ein Spiel wie Minecraft. Minecraft basiert ja darauf, das ein Terrain immer wieder und immer weiter erstellt wird. Hier arbeitet Minecraft mit Ticks. Weil, das Terrain soll ja auf jeden Fall, so schnell wie nur möglich, generiert werden. Und wenn der Computer des Spielers dann halt einen schlechten Tag hat, dann ist das halt so. Dann siehst du wie sich die Chunks und Blöcke langsam aufbauen bis hin zum Horizont. Die Vorgabe ist jedoch nicht, innerhalb von 5 Sekunden so und so viel Terrain zu generieren, egal ob der Spieler jetzt einen schnellen Highendrechner hat oder irgend einen gebrauchten Bürorechner. Es soll einfach Stumpf so schnell wie möglich Terrain generiert werden.


    Bei, zum Beispiel Bewegungen, ist das ja anders. Stell dir mal vor, du hast zum Beispiel eine Schiebetür im Spiel. Diese soll 3 Sekunden benötigen, um sich zu öffnen. Der Bürorechner würde dann vielleicht 20 Sekunden brauchen bis die Tür auf ist, der Highendrechner vielleicht 0,1 Sekunde. Der Spieler würde also plötzlich vor einer Öffnung in der Mauer stehen. Deswegen benutzt man hier halt Deltatime. Und Deltatime enthält halt den Wert, der angibt, wie lange ein Frame zum Berechnen benötigt.


    Deswegen gilt die Formel halt wie folgt (Hatte ich oben ja schon angedeutet.


    Wir haben folgende Variablen.


    Aktion = Die Aktion die ausgeführt werden soll

    Zeit = Die Zeit die diese Aktion in jedem Fall benötigen soll

    Deltatime = Ist halt Deltatime


    Mit der Form (Aktion/Zeit) berechnest du die Aktion innerhalb der Zeit. Also eine der bekanntesten Formen wo dies so dargestellt wird, ist wohl km/H also Kilometer pro Stunde. 100/1 wäre dann einhundert Kilometer pro Stunde. Also Aktion innerhalb dieser Zeit.


    Da aber die Berechnungszeit sich ständig ändert, je nachdem wie viel die Grafikkarte oder CPU zu tun hat musst du das halt mit Deltatime Multiplizieren. Das wäre dann halt die Formel...


    (Aktion/Zeit)*Deltatime.


    Damit weiß das Programm dann halt wie viele Frames benötigt werden, um diese Aktion in exakt der vorgegebenen Zeit auszuführen. Ein Berechnungsbeispiel wäre dann zum Beispiel.


    Etwas soll 200 Kilometer in einer Stunde fahren. Ich rechne die Stunde jetzt mal nicht in Sekunden oder so um, damit es einfach bleibt und kürze die 1 auch nicht weg, denn eigentlich ergibt etwas durch 1 zu teilen gar keinen Sinn. Für Deltatime benutze ich mal die Werte von Butterfly, weil die ja realistisch von ihm gemessen wurden.


    (200/1) * 0,01667 = 3334 Frames die benötigt werden, um diese Aktion in der vorgegebenen Zeit darzustellen. Vorausgesetzt ich bin jetzt nicht mit der Kommaverschiebung durcheinander gekommen :D

  • Danke noch mal für deine Erklärung, es macht das Grundprizip nochmal deutlich. Ich hab eher Probleme das in's Blueprint einzubinden, auch weil ich die Blueprints nicht selbst erstellt habe und mir vieles noch unverständlich ist. Ein Informatiker hat's da deulich leichter. Ich hab in den Blueprints des Plugin z. B. so etwas gefunden.


    Man hat die Delta Time also mit berücksichtigt. Es funktioniert halt nicht. Beim bewegen im Level schwankt meine Bildrate deutlich und deshalb bleibt der Zug immer an einer anderen Stelle stehen. Je geringer die Bildrate ist, um so länger ist der Bremsweg. Aber ich hab jetzt die Bildrate fixiert. das reicht erstmal. Wenn ich erfahrener bin kümmer ich mich noch mal um die Delta Time.

  • Da kann ich nur Vermutungen anstellen.


    Diese Node scheint eine zu sein, die vom Programmierer des Plugins selber erstellt wurde. Und wenn man den Sourcecode nicht einsehen kann, dann ist es natürlich auch schwierig nachzuverfolgen was innerhalb dieser Node passiert.


    Der Namensgebung nach kann ich aber nur vermuten, dass er DeltaSeconds wieder in Ticks umwandelt. Wenn dem wirklich so sein sollte, warum auch immer er das tun sollte, dann hast du natürlich wieder dein altes Problem.


    Eine andere Vermutung ist, dass er einfach alles, was das Event Tick mitbringt, in seinen Code übernimmt. Würde wesentlich mehr Sinn ergeben als meine erste Vermutung, wenn er das als Parameter in eine Funktion übergibt.


    Aber wie schon gesagt, da verfalle ich jetzt in reine Spekulation.

  • Ist doch ne ganz normale Function...

    Was heißt bei dir normale Funktion? Eine Funktion die aus BP-Nodes besteht? Du kannst sie ja auch in C++ programmieren. Ich kenne das Plugin ja nicht. Und ich bin jetzt einfach mal ganz frech davon ausgegangen, dass die Funktion auch in C++ geschrieben sein könnte.


    Ich weiß, ist etwas anmaßend. Aber da ich mich momentan mit C++ und der Engine beschäftige war das halt mein erster Gedanke. :D