Gerade die SDL Rev. 1122 getestet.
Insgesamt läuft sie besser. Auf "freiem" Gelände ist die FPS praktisch nicht auf 7 zu drücken und damit auch keine Anpassung der BFR zu erzwingen. Aber in einem (größeren) Waldgebiet gehts immer noch recht problemlos - nur läuft die SDl auch hier wesentlich geschmeidiger (fast kein Ruckeln). Aber in die Rechenschleife kommt auch die SDL (mit minimalen Abweichungen).
CPU-Belastung veilleicht 5% höher, aber dafür etwas mehr belastbar.
Mit den aktuellen Versionen hat sich das Problem hier weitesgehend gelöst. Derzeit verwende ich die r1268 newSDL-Version mit pak.german. Allerdings gibt es immer noch 2 Dinge, die ich gern nochmal ansprechen würde:
1. Große Waldgebiete
Wenn ich, wie oben schon geschrieben, die Karte auf ein solches fokussiere, habe ich grundsätzlich eine höhere CPU-Belastung. Normal habe ich ~27%, über Waldgebieten permanent ~70%. Minimiere ich die Bäume sinkt sie auf ca.42%. Die Simloops bleiben bei 4,7-5,1.
Wenn ich deine Äußerungen richtig verstanden habe (der Code dafür ist nur ein Dreizeiler), dann sollten Waldgebiete kaum Auswirkungen auf die Leistung von ST haben.
Tritt bei dir tatsächlich keine deutliche CPU-Belastung auf, wenn du auf Waldgebieten fokussierst?
Könnten 1 oder 2 andere bitte mal ihre Erfahrungen dazu schreiben. Ich kann mir nicht vorstellen, daß mein System das einzige sein soll, was mit diesem Phänomen zu tun hat. Ich habe dazu mal einen unbebauten Spielstand im Anhang hochgeladen, damit wir mal eine einheitliche Referenz haben.
Wenn ich zur Koordinate (36,136,4) gehe, habe ich wie gesagt mindestens 70% CPU-Belastung.
Ist bei euch ebenfalls eine deutliche Mehrbelastung festzustellen?
2. Manuelle Zeitbeschleunigung
Dank deiner Optimierungen, Prissi, läuft ST nun recht ausgeglichen und CPU schonend. Allerdings treten bei anderen Werten als T=1.00 doch CPU-Schwankungen auf, die ich erstmal so nicht unbedingt nachvollziehen kann. Es gibt regelrechte Lücken, wo die CPU-Belastung auf maximal springt, ein paar T-Schritte weiter aber wieder auf Normalniveau absinkt.
Ich hab' mir mal die Mühe gemacht und eine kleine Übersicht erstellt, wie sich das bei mir darstellt. Vielleicht hilft sie dir ja die Lage besser einzuschätzen.
Grundsätzlich spiele ich immer mit FPS=10.
Wie zu erkennen, ist 4,4 bei den Simloops die Marke, die darüber entscheidet, ob ST mehr Rechenzeit haben will.
Die Frage ist, geht das auch anders zu lösen oder muß ich mit diesen Einbrüchen bei T=0.75-0.81 und 1.13-1.63 leben? Siehst du noch Möglichkeiten, das etwas geschmeidiger hinzubekommen?
Anzumerken zu deinem Hinweis in einem anderen Beitrag "-fps 12 oder so" bliebe mir noch, daß mit FPS=12 die CPU bei mir, sobald ich einen Spielstand lade, permanent auf Anschlag ist. FPS 10 und 11 sind okay, selbst bei 20 bleibt die CPU auf Normalniveau. Für mich merkwürdig, daß ST so empfindlich reagiert...
Die CPU/Belastung ist nicht gleichmaessig uber der Zeit. Je nach Stadtgebiet muessen einmal wenig und einmal viele Passagiere erzeugt werden, was unterschiedlich dauert und daher eine schwankende Belastung hervorruft.
Die hoehere CPU/Last bei Waldgebieten ist vermutlich dem Rechenbedarf bei der Bildberechnung geschuldet (obwohl auch nur ein zehnzeiler). Die ALternative waere 30% mehr Speicherbedarf, was auch nicht weiterhilft, da Speicher in ausgebauten Spielen auch euin Problem werden kann.
Beim mir sehe ich bei Waeldern allerdings praktischen keinen Unterschied mit pak64. Eventuell sind auch einfach die grossen Grafiken die zigmal uebereinander gemalt werden muessen, der Bremser. Dann kann man da gar nichts machen.
Ich glaube, wir reden ein wenig aneinander vorbei. Mit Passagiererzeugung dürfte das überhaupt nichts zu tun haben, die Karte ist vollkommen unbebaut (auch keine KI), da passiert praktisch gar nichts. Die Liste dort oben ist keine Momentaufnahme, sondern zeigt die fortlaufende CPU-Belastung.
Vielleicht habe ich mich auch etwas unglücklich ausgedrückt. Schwankend meine ich nur auf die einzelnen Zeitstufen (z.B: T=1.06,T=2.00) bezogen. Auf so einer Zeitstufe läuft ST absolut stabil +-3% Schwankung vielleicht.
Also konkret (siehe obige Liste): Gehe ich mit Taste [.] auf T=1.06 bleibt ST weiterhin dauerhaft bei rund 27% (Normalniveau). Gehe ich auf T=1.13 geht ST dauerhaft auf 100% und bleibt da auch.
Erst wenn ich die Zeit zurück auf 1.06 stelle oder bis auf 1.69 erhöhe, kommt die CPU-Belastung wieder auf Normalniveau - vorher nicht.
Frage: Warum habe ich also z.B. bei T=1.13 immer 100% CPU-Belastung, hingegen bei der viel schnelleren T=2.00 (die ja rechenintensiver sein müßte) nur 27% (dauerhaft)? Das ist das, was mich noch irritiert.
Zu den Waldgebieten: Ich habs nochmal mit pak64 überprüft - gleiches Ergebnis. Aber ich geb mich da erstmal geschlagen, daß man da nichts machen kann.
Punkt 1:
Wieviele Prozesse zeigt der Taskmanager denn an?
Punkt 2:
Arbeitsspeicher
Verschiebt Windows Teile in oder aus der Auslagerungsdatei, geht die CPU-Belastung auch hoch.
Punkt 3:
Taktfrequenz - wohl die Hauptursache
Ich hab einen 2,2 GHz Athlon 64, Win XP Pro, 960 MB Ram.
leere Startkarte vom pak.german
T=1.38 hab ich CPU 0%. In Abständen gehts hoch auf 13%
T=1,31 Schwankungen zwischen 5% und 65%
T=1.25 Schwankungen zwischen 0% und 33%
T=1.19 Schwankungen zwischen 88% und 100%
T=1.13 Schwankungen zwischen 0% und 38%
T=1.06 starke Schwankungen zwischen 15% und 80%
T=1.00 Schwankungen zwischen 0% und 27%
T=0.94 hab ich CPU 0%. In Abständen gehts hoch auf 13%
Jeder Task bekommt ein Zeitfenster für seine Ausführung, bevor zum nächsten Task umgeschalten wird.
Nun scheint bei bestimmten T-Faktoren die Zeitspanne für die Ausführung besser zu sein als bei anderen.
Reicht die Zeit nämlich nicht für das Beenden der begonnenen Berechnungen, muss die CPU alle Register und Zwischenergebnisse sichern und wieder laden. Das führt zu einem viel höheren Datentransfer als wenn die Berechnungen bereits abgeschlossen wurden.
Wieviele Prozesse der Taskmanager anzeigt? Na 1, wenn du ST meinst. Keine Ahnung, aber der W2k-Taskmanager scheint nicht so auskunftsfreudig zu sein wie deiner. Es ist mir ein Rätsel, woran du erkennst, daß "zum nächsten Task umgeschalten wird" und daß Register gesichert werden müssen.
Naja, Hauptsache Prissi kann was damit anfangen.
Aber Danke, daß du meine Beobachtungen bestätigen kannst (sonst werd' ich hier noch als Dauernörgler abgestempelt ).
Zitat:Original von blackbox
...
Es ist mir ein Rätsel, woran du erkennst, daß "zum nächsten Task umgeschalten wird" und daß Register gesichert werden müssen.
...
das ist Basiswissen von Computertechnik
Multitasking-Systeme müssen zwischen den einzelnen Programmen umschalten, sonst könnten die ja nicht gleichzeitig laufen.
Wer einen Haufen Tray- und Hintergrundprogramme laufen hat, braucht sich nicht wundern, wenn Windows langsam läuft.
Vielleicht ist WIndows daran schuld. Neuere Versionen (ab 2k) ignorieren naemlich manchmal meine Nachfrage zur Pause und Simutrans kommt sofort wieder dran. Nur um festzustellen, dass die Ziet noch nicht um ist und wieder um eine Pause bittet. Damit kann man auch 100% CPU/Leistung erzeugen. Die ist aber nicht "echt", denn wenn es wirklich noch was zu tun gibt, Pausiert Windows Simutrans tatsaechlich.
Ansonsten ist je nach Version und Prozessor erst eine Pause ab 5ms wirkungsvoll, kuerzere werden ignoriert. Daher kommen vielleicht ide Stufen, erst 12 (5+5+ 2 ignotriert), dann 9 (5+4 ignoriert).
Ich werde nochmal ein Auge darauf werfen, kann aber nichts versprechen.
Prissi, ich kann deine Vermutung nicht bestätigen, daß es erst ab W2k auftritt. Ich habe es gerade auf W98 (absolut blankes System) ausprobiert, und es verhält sich dort praktisch identisch.
Ein weiterer Punkt ist der Schnellauf >>. Für mein Empfinden funktioniert dieser auch nicht sauber (auf beiden Systemen 98+2k).
Starte ich ihn, springt er für 1 bis 2 Sekunden auf sehr hohe Werte (~T=50, manchmal auch 70), fällt dann aber zurück auf T=1.76, steigert sich dann annähernd im Halbsekundentakt in 2er Schritten auf 1.78, 1.80,...,1.92,1.94 und dann erst springt er in den höheren Bereich, wo er unter starken Schwankungen bei ungefähr 20-35 verbleibt. Öfters wiederholt getestet, immer genau dieses Verhalten zu beobachten.
Das merkwürdige dabei: Die CPU-Belastung ist kaum merklich höher. Sie schwankt zwar mehr, die Spitzen gehen bei mir aber kaum über 40%. Sollte in diesem Modus nicht eigentlich alle Rechenzeit verwendet werden?
Der Schnellvorlauf versucht sich seit einigen Versionen an den Wert in der simuconf.tab zu nähern. Das ist der Eintrag fast_forward. fast_forward = 2500 sollte das ganze wieder auf Maximalgeschwindigkeit bringen. War Userwunsch.
).