Simutrans optimieren

[The Transporter]

Der Musikplayer von ST kann auch massive Performanceprobleme verursachen, alle paar Minuten bleibt alles für ein paar Sekunden stehen, und nichts geht mehr.
Über das Hauptmenü, Sound läßt er sich abschalten.
Während der Hänger wird der neue Titel geladen, das reine Abspielen ist dann wieder Problemlos.

[prissi]

Onboardgrafik:
Der gemappte Speicher ist vom Prozessor zugreifbar, denn sonst könnte der gar nichts anzeigen. Das ist wie beim C64 oder Atari ST schon - denn die einfachsten Onboardgrafikarten haben gar keinen nennenswerten 2D-Support, das muss alles der Prozessor machen. Versehentlich in den Speicher schreiben passiert aber schon deswegen nicht, weil die MMU das nicht erlaubt; etwas Fortschritt seit 1982 darf ja erlaubt sein.

Fullscreen:
Im fullscreen-Modus versucht Simutrans mit einer nicht ganz dokumentierten Funktion die Grafikauflösung auf 16Bit zu schalten. Jedoch ist der 16Bit-Support bei XP schlecht und bei Vista offiziell gar nicht mehr nötig für ein Works with Windows-Label, gleichwohl er bei den meisten Grafikkarten immer noch dabei ist. Eventuell macht das Probleme.

Es sollte im übrigen egal sein, welche Auflösung du wo einstellst. Mit nur -fullscreen nimmt Simutrans übrigens ganz automatisch die aktuelle Auflösung. Die Routine zum Einstellen der Auflösung wird auch nur einmal aufgerufen, daher sollte es eigentlich egal sein, wo sie die Parameter herbekommt.

[RHBaum]

Hab mir das WE Kubuntu aufn rechner neu installiert, und da war auch simutrans 101 in den repos. Muss sagen das laeuft um Welten "geschmeidiger" als Windows Version unter Vista ... keine ahnung wieso.
Rechner ist der gleiche und fullscreen und Auflösung auch.

@prissi
Ich kann mich noch an die CGA, EGA, VGA Zeiten erinnern, wo man direkt in den Speicher gemappten Speicher der Graka schreiben konnte ... B800:0000 und A000:0000 sollten da noch nen begriff sein :-) im realmode.
Das sind aber auch nur die Mapped Bereiche, also die Speicherfenster, wo sowohl die graka als auch der Prozessor drauf zugriff haben. Wobei die Grafik da doch noch keinen eigenen SPeicher wirklich hatte (warum auch).

Aber um den gemappten Speicher gehts doch gar ned ... du meintest doch den Quasi Arbeitsspeicher fuer die GPU, da wo die GPU ihre Texturen usw ablegen kann? Bei diesen Grakas mit "Shared memory" wird nen Teil des Phys. Speichers fuer die GPU reserviert (Wofuer "normale" Grakas meist sündhaft teueren(damals) DDRAM selber auf der Platine haben) ... auf den hat doch expliziet nur die GPU zugriff. Und schuetzen sollte den doch der Speichercontroller, bzw das BIos, das die CPU da ned draufkommt, was fatal waere.
Ansonsten funkt das ja wie bei anderen Grakas auch ... nur das zum besipiel ne Textur den Doppelten weg nimmt manchmal ... Also von der Anwendung (CPU) in den RAM geladen wird, dann uber den gemappten memory zur Graka geschickt, die ihn wiederum in ihrem eigenen Speicher ablegt, also in dem fuer die graka reservierten teil .... vorrausgesetzt die GPU laesst die textur so wie sie ist ^^
Dass 2 malige einlagern des Speichers laesst sich IMHO ned mit direktzugriffen durch die CPU vermeiden ....

Hab ehrlich auch noch nie gehoert, das diese Grakas mit shared memory in irgendewas schneller waeren, als wie ne graka mit eigenem Speicher ....

Ciao ...

[prissi]

Onboardgrafik:
Das einzige, was die Onboardgrafik macht, ist die Pixel auf den Monitor zu schieben. Das ist die GPU. Manche Onboardgrafik hat auch noch 3D-Chips. Aber diese können nicht immer Linien zeichnen (oder nur mit tricks) oder Buchstaben rendern. Solch mundane Sachen macht die CPU die darauf auch Zugriff hat. Per MMU kann ich aber allen Programmen verbieten, in diesen Bereich zu schreiben. Die Speicherbandbreite zu diesem SPeicher ist die gleiche wie zum Hauptspeicher, weil für die MMU kein Unterschied besteht.

CGA/VGA/... ist was anderes: Hier war der Speicher auf der Karte, nicht auf dem Board. D.h. Speicher ist physikalisch getrennt.

Shared Memory Grafikarten:
Das schlechteste beider Welten kombiniert: Die 2D Daten liegen auf der Grafikarte, d.h. der Prozessor muss sie immer über den AGP/PCI(x) Bus schicken. Im 3D Modus wandert auch noch Texturspeicher in Massen über das Interface und bremst den Prozessor aus.