99.12 (Rev. 1122 dito) Hohe CPU-Auslastung

[blackbox]

System PII-400 W2k GDI mit 99.12 Original und Nightly mit Base64 und GermanPak
(256x256 Karte, 15 Städte, Verkehr 1, keine KI, alle Anzeigeoptionen deselektiert)

Nach längerer Zeit habe ich mir heute mal die aktuellen Versionen gezogen, um zu schauen, was ihr in den letzten Monaten so zustande gebracht habt.

Leider gab's gleich zu Beginn einen schweren Dämpfer, da ST auf meinem System alles andere als vernünftig spielbar war. Es war/ist bei mir praktisch unmöglich, mit den Standard-Einstellungen eine Karte fließend mit der rechten Maustaste zu bewegen. Kaum die Karte "angefaßt" brechen bei mir die Simloops gleich dermaßen ein, daß ST praktisch für ~1 Sekunde keine Benutzereingaben mehr annimmt.

Das war früher nicht so. Laut dem Changelog soll es aber immer mal wieder Verbesserungen an der Performance gegeben haben. Wen dem so ist, dann habt ihr sie wirklich gut versteckt. Sorry.

Ich habe noch mal zum Vergleich meine damalige letzte Versionen (99.01) installiert. Und ich habe mich nicht getäuscht - diese läuft tatsächlich nahezu geschmeidig. Hier habe ich noch bequem über 20 Simloops und selbst bei intensivem Scrollen, auch über dichten Waldgebieten, gibt es hier keine nennenswerten Performance-Einbußen. Bei kompletter Inaktivität meinerseits liegt hier die CPU-Auslastung bei rund 40%.

In der aktuellen Version (Original und Rev. 1122) ist es jetzt möglich, die FPS direkt in der simuconfig.tab selber einzustellen. Ich habe verschiedene Werte getestet und mit Werten von 5 oder 10 ist die Karte auch wieder problemlos zu bedienen, aber die CPU-Auslastung ist unter bestimmten Umständen einfach viel zu hoch.

Beispiel mit 10 FPS: Ich lade meine Karte und öffne nur das Anzeigefenster. In aller Regel pendeln sich bei mir die Simloops bei 5,x ein und ST belastet die CPU teilweise sogar nur mit unter 30%. Sow eit so gut. Bewege ich aber die Karte ca. 3 Sekunden über einem Gebiet (über Waldgebieten macht's sich natürlich am schnellsten bemerkbar), muß ST dermaßen extreme Berechnungen anstellen, daß es den Anschein hat, das will gar nicht mehr enden, obwohl überhaupt keine Aktivitäten (meinerseits) mehr stattfinden. Ich habe es mehrfach ausprobiert und ST manchmal sogar mehrere Minuten Zeit gegeben, um wieder auf Normalzustand zu kommen - keine Chance.
Erst wenn ich die Karte in eine andere Region bringe, schafft es ST nach ein paar Sekunden wieder "runter" zu kommen. Sonst scheint mir würde es ewig in dieser Schleife hängen und was weiß ich berechnen. Das Spiel läßt sich gut bedienen in diesem Zustand, zumindest reagiert es auf Benutzereingaben, nur die CPU-Auslastung ist permanent auf Anschlag.

Prissi, ist es jetzt tatsächlich so, daß ich auf meinem System mit FPS-Werten von unter 10 spielen muß, damit ich ST noch bedienen kann? Gibt es noch andere Möglichkeiten?
Als Startoptionen nehme ich derzeit: simutrans.exe -refresh 2 -nomidi -nosound -singleuser -screensize 1008x752 -log 1 -debug

[Andy386]

laut
Spiel stockt in abständen
könnte das Abschalten des midi etwas bringen:
simutrans -nomidi

[prissi]

Ansonsten bin ich ratlos. Verwende mal das letzte nightly, das sollte ca. 50% weniger Rechnezeit brauchen.

Welche Linuxdistribution ist es denn? Es gab da mal Probleme mit der allerneusten Ubuntu.

Das Problem beim Scrollen ist, dass jetzt die Simulation weiterläuft. Vorher wurde die Simulation angehalten und nur gescrollt. Das Problem ist aber erkannt und in Arbeit.

[goalie]

wo gibts die nightlys

[prissi]

http://asuka.clanintern.de/gp/simutrans/simutrunk.html

Ansonsten versucht sich Simutrans soviel Rechnezeit zu schnappen, wie möglich, wenn es hinter den Simloops zurückfällt.

[blackbox]

Hallo?
Wieso Linux? Steht doch oben in der 1. Zeile: W2K GDI verwende ich.

"Das Problem ist aber erkannt und in Arbeit."
Das hört sich gut an. Werde mir eine neue Nightly besorgen, sofern jemand eine neue GDI-Version zusammenbaut. (Sehe gerade, kierongreen hat eine neue Rev. 1149 gebaut - soll es mit dieser version schon funktionieren - oder was heißt bei dir gerade "letzte nightly"?

Was heißt "wenn es hinter den Simloops zurückfällt". Ich bekomme nie höhere Simloops als 5,x angezeigt. Selbst wenn die CPU-Auslastung auf Anschlag ist (wenn ich mit FPS=10 spiele), bekomme ich noch Simloops von 3,x angezeigt...
Ist es normal/gewollt, daß auf meinem System die Simloops grundsätzlich nicht mehr über 5,x hinausgehen? Früher hatte ich wie schon oben geschrieben Werte von über 20.


@Andy386
Schau mal in die letzte Zeile von meinem ersten Beitrag...


@goalie

Für Linux findest du hier welche:
http://asuka.clanintern.de/gp/simutrans/simutrunk.html

Für Windows mußt du derzeit hier schauen:
http://forum.simutrans.com/index.php?&board=155.0

[Andy386]

ups....
dann könnte es dasselbe Problem sein, was auch mein Laptop hat
(200Mhz MMX, allerdings Debian 3.1 drauf)
Welche Version auf 200MMX mit 92MB Ram (Linux)?

ich kann morgen oder übermorgen mal die swap-partition vom USB-2.0-Stick vergrössern, mal schauen ob's am RAM liegt (ja, ich habe eine usb-2.0-pcmica-karte)

[prissi]

Also ich habe eine Pentium 120 zum testen zu Hause. Früher ruckelte er mit -refresh 4 (also ca. 8 FPS), jetzt kann man darauf mit FPS 5 spielen.

-refresh 2 konnte auch früher schon -fps 5 sein, kam ganz auf die Auslastung an. Jetzt versucht simutrans, sich stärker an die FPS-Werte zu halten. Und wenn nötig, auch alle angeforderte Rechenzeit zu nutzen. Du sagst ja selbst, dass es bedienbar bleibt.

Außerdem gab es früher ziemlich viele sinnlose simloops. Mehr als 5 pro Sekunde sind aber nicht mehr nötig. Daher sollte die Rechenzeit deutlich reduziert sein.

Was anders ist: Früher hatte ich mit 15 Bit die GDI-Versionen gebaut, jetzt sind es 16Bit. Kann sein, dass dein Grafikblitter das nicht mag. Die SDL-Version kann helfen, muss aber nicht.

Früher hat auch die Pauseoption nicht wirklich funktioniert, da maximal 2ms Pause. Somit hat schon die Startkarte 100% Rechenleistung gefressen, zumindest auf Win2k und neuer, wo der Idle-Task erst bei 5ms aufgerufen wird. (Ehrlich gesagt, war simutrans in den 82.xx Versionen das Programm, was die CPU am meisten belastete, thermisch.)

Bei dem Waldgebieten passiert eigentlich gar nichts, außer dass die Bäume ihr Bild selbst berechnen. Das ist aber ein Dreizeiler. Gehen die Simloops über den Waldgebieten zurück?

[prissi]

Ok, beim Scrollen mit der rechten Maustaste wurde für jedes Pixel Verschiebung das Bild komplett neu gezeichnet. Ab sofort wird es das erst beim nächsten Bildschirmupdate machen (wenn es eh fällig war), das sollte die CPU ganz gehörig entlasten.

[blackbox]

Ich hab' mich nochmal hingesetzt und die Angelegenheit genau beobachtet - so langsam habe ich verstanden, wie dein System jetzt funktioniert.
Laß uns mal davon ausgehen, ich habe in der simuconf FPS=10 gesetzt. Lade jetzt meinen Spielstand und schau mir die Anzeige an. Unter optimalen Bedingungen sieht die dann bei mir so aus:

BFR: 100 ms
UNT: 100 ms
FPS: 10
SIM: 4,8-5,1 schwankend
CPU: ~22%

Wenn ich die Karte ca. 3 Sekunden lang minimal mit der RMT kreisen lasse, sinken natürlich in dem Moment alle Werte etwas. Fällt bei mir die Bildrate auf 7 oder tiefer, beginnt ST gleichzeitig die BFR abzusenken.
Laß ich jetzt die RMT nicht früh genug los, und fällt die BFR auf unter 90 ms, hebt ST sobald er Rechenzeit dafür bekommmt die FPS an. Die FPS kann dann bei mir kurzzeitig Werte von bis zu 14 annehmen - 11 reichen aber schon aus, um zum Problem zu werden.

Bei einer BFR von unter 90 ms setzt ST die FPS also kurzzeitig auf mindestens 11, erhöht damit die BFR wieder, aber leider soweit, daß ich Werte von über 100 ms bekomme. Sobald ST aber merkt, daß die BFR bei über 100 ist, reduziert er die FPS wieder - aber leider nicht auf 10 (was optimal wäre), sondern auf 9 und beläßt sie dort.

Damit kann ST aber anscheinend nicht richtig umgehen, denn nur bei einer FPS von exakt 10 gibt ST wieder Rechenzeit ab und entlastet dann die CPU . Das ist bei einer BFR von 90-100 der Fall. Sowie sie bei 101 oder höher steht, fällt ST auf 9 FPS zurück und damit in eine unendliche Rechenschleife.

Hilft dir das weiter?


Zu deiner Frage mit den Simploops in Waldgebieten: Nein, die Simloops bleiben erstmal stabil (4,8-5,1), zumindest bei völliger Inaktivität meinerseits. Nur habe ich eine deutlich höhere CPU-Auslastung (über 60-75%) wenn ich bloß den Focus auf ein Waldgebiet setze (normal wie schon geschrieben unter 30%). Auch das Scrollen der Karte ist mehr ein einziges Ruckeln - demzufolge brechen dann natürlich auch die FPS schneller weg. Minimiere ich die Baumgrafiken, geht es deutlich besser (CPU bei 30-33%)
Ich werd's aber alles nochmal mit der SDL-Version ausprobieren...