Plattengeschraddel beim Spielen

Servus Robotfans,
mir ist gerade ein etwas sehr seltsames Verhalten meine Systems (Win2k) beim Spielen der Robot-Beta aufgefallen.. und zwar immer wenn meine Figur oder sonst
irgendwas auf dem Bild sich bewegt, ist meine Festplatte am schraddeln. Mache ich ein Menue auf oder halte das Spiel anderweitig an, hoert das Geschraddel auf.
Filemon hat mir dann verraten, dass Windows hier wie doof in der Auslagerungsdatei herumfuhrwerkt. Wirft natuerlich jetzt die Frage auf: Warum?
Bei 2GB RAM kanns ja wohl nicht daran liegen, dass Robot einfach zuviel Speicher verbraucht und wirklich geswappt werden muss. Kann es sein, dass Robot fuer
das Abspielen der Animationen eine Speicherzugriffsmethode benutzt, die eine hohe Zahl Seitenfehler verursacht? Ist da Windows einfach nur doof? Kann man das
evtl irgendwie wegkonfigurieren?
Ich krieg irgendwie Mitleid mit meiner Platte..

komisch. eigentlich sollten wiederholte lese-zugriffe irgendwann im festplatten-cache landen. hast du evtl den lese-cache deiner primären platte deaktiviert ?

Sorry, wenn ich das so sage, aber das kann eigentlich nicht am Robot liegen. Wenn das Spiel einmal geladen ist, passiert speichermäßig nicht mehr viel, außer
beim Raumwechsel oder Laden eines Spielstandes oder beim Öffnen eines Dialoges. Solange man herumrennt wird nirgends irgendwo neuer Speicher alloziert, welcher
stellenweise Aktivität bei der Swapdatei verursachen könnte (was bei 2Gig kaum passieren dürfte).
Was sagt denn der TaskManager über die Speicher-Auslastung? Hast Du die Kiste 'mal neu gebootet? Nicht, dass da irgendwelche Programm-Leichen noch Speicher
schlucken und kein MB mehr für Robot verfügbar ist...
Ansonsten produziert die aktuelle Beta noch eine Log-Datei in welcher Fehler von den DirectDraw-Schnittstellen protokolliert werden. Schau' doch 'mal
nach, wie groß diese Datei bei Dir ist. Eigentlich sollte die nur ein paar kByte groß sein...

Im Worst Case könnte auch deine Platte am Abkratzen sein.
Sicherheitshalber würde ich mal HDD Health ausprobieren:
http://www.chip.de/downloads/HDD-Health_29645220.html

@herc:
Den kann man deaktivieren? Ich kenn nur ne Option fuer den Schreibcache.. und die ist an.
@autofahrn:
- Die Kiste wird taeglich neu gebootet.. ich gehoer nicht zu den Leuten die ihren Rechner permanent an haben. Das Verhalten ist zu jeder Zeit gleich, egal ob
frisch nach dem Hochfahren oder nach nem ganzen Abend daddeln. Sobald ich eine Szene betrete in der sich Figuren bewegen, oder ich rumlaufe, schraddelt meine
Platte im Takt mit, Filemon listet tausende Zugriffe aufs Pagefile.
- von den 2GB RAM sind laut Taskmanager 1,6GB frei. Davon benutzt Robot immense 3MB oder so 😉
- wo gibts dieses Log? zumindest im Spielverzeichnis finde ich keins (bei meiner rc40). DirectDraw-Fehler wuerden mich ehrlich gesagt wundern.. zumindest
laufen bei mir aktuelle MMOs und 3D-Games etc fehlerfrei, dxdiag findet auch nichts ungewoehnliches.
@RobinSword:
Das Problem besteht ausschliesslich wenn ich Robot spiele. Das Geschraddel endet sobald ich das Spiel pausiere, in eine Szene ohne andere Figuren gehe oder
Robot beende. Die Platte wird auch anderweitig ausreichend beansprucht, der gehts glaubich gut. Smart meldet zumindest keine Fehler.
Wenn ich nicht wuesste, dass ein paar meiner anderen Spiele mit 2GB nicht ganz auskommen, wuerd ich eh das Swapfile deaktivieren.. aber so is das leider keine
Moeglichkeit. Ich werds aber bei Gelegenheit mal testweise tun.
/Edith sagt: Das Problem scheint doch irgendwie mit DirectX zusammenzuhaengen... im Vollbildmodus isses naemlich weg, im Fenstermodus da. Sogar die Laufschrift
im Startbildschirm reicht schon aus, dass die Platte losschraddelt. Vielleicht kann Andreas mit der Info etwas Ursachenforschung betreiben.
Hardwareinfos? Gefrosch 7600GT, nvidia forceware 94.24 (glaub die letzten die fuer win2k erschienen sind), DirectX 9.0c. Beides frisch installiert.
/Edith sagt weiterhin: Es wird immer kurioser. Das Problem tritt ausschliesslich im Fenstermodus in 1280x696 und 1280x870 auf. (Mein Desktop laeuft auf
1280x1024). Kann es sein dass DirectDraw irgendwie ne Macke hat, wenn das Spielfenster groesser ist als der Bildschirm? Zumindest der Rahmen steht mir ja
aussen ueber. Dann muesste ich aber zumindest bei anderen Spielen die ich gern im Fenster auf 1280x960 nutze das gleiche Verhalten sehen.. tu ich aber nicht.

Ok, danke für die Infos, aber die machen die Sache nicht unbedingt verständlicher...
Also, wenn das nur im Fenstermodus auftritt, hat das absolut nichts mit DirectDraw zu tun. DirectDraw benutze ich nur im Vollbild-Modus, ansonsten läuft's
Zeichnen über die normale GDI-Schnittstelle von Windows (StretchDIBits)...
Wie sieht's denn aus, wenn eine kleinere Auflösung gewählt wird und dann das Fenster ein Stück über den Rand geschoben wird? Ich kann mir nämlich nicht
vorstellen, dass das irgendwie an der Auflösung liegt, das ist letztendlich nur ein Skalierungs-Faktor bei der Anzeige, programmtechnisch ändert sich ansonsten
gar nichts... Ändert sich etwas, wenn man das 1280er Fenster etwas verschiebt, dass nur eine Seite herausragt?
Mangels echtem Win2k-System habe ich das eben nochmal unter VmWare getestet (natürlich ohne den nVidia-Treiber). Da war in allen Auflösungs-Kombinationen
absolute Ruhe auf der Platte. Nunja, so kenne ich das...
Was mich nach wie vor irritiert ist, dass die Plattenaktivität offensichtlich von den Bewegungen auf der Oberfläche abhängt. Kann es sein, dass da irgendein
Capture-Programm im Hintergrund werkelt? Aber dann müsste die Aktivität bei kleineren Fenstergrößen nur weniger werden, aber nicht ganz verschwinden...
Welchem Prozess werden vom FileMon denn die Aktivitäten zugeschrieben? Du schreibst nur etwas von "Windows"... Apropos: Welches ServicePack ist da
installiert (nicht dass das einen Unterschied machen sollte...).
Es ist auf alle Fälle sehr, sehr merkwürdig...

Noch ne doofe Frage meinerseits: Bist du dir sicher, dass das "Schraddeln" auch wirklich von der Festplatte kommt?
Und nicht etwa von einer anderen Komponente wie z.B. der Grafikkarte?
Blinkt die Festplatten-LED dann auch wie verrückt?
Nur, um sicher zu gehen...

Naja, wenn FileMon deutliche Aktivitäten beim Swapfile anzeigt, liegt das wohl kaum an der GraKa...

exakt.. FileMon berichtet von Zugriffen IRP_MJ_WRITE nach Z:\pagefile.sys von der Prozess-ID 8 aus ("system"), jeweils 64k-Bloecke unbekannten
Inhalts, je nach Anzahl der dargestellten Roboter/Menschen/Tiere und Spielgeschwindigkeit eine Handvoll bis einige Hundert pro Sekunde.
Servicepack ist 4, und soweit ich weiss auf den aktuellsten Stand gepatcht.
Ich hab jetzt extensiv herumexperimentiert um einzukreisen was da wann passiert, und zwar am Beispiel des Titelbildes (Episodenauswahl).
Erkenntnis war, dass sobald ich das Fenster weit genug nach links vom Bildschirm schiebe, dass die Figuren auf den Episodenknoepfen nicht mehr sichtbar sind,
das Geschraddel aufhoert. Ziehe ich es wieder nach rechts, auch wenn nur eine Pixelreihe der Figuren sichtbar ist, habe ich wieder die permanenten Zugriffe ins
Pagefile.
(Ich geh ja eigentlich davon aus, dass es sich bei den Figuren auf den Knoepfen um statische Bilder handelt, genau wie bei den Fotos die rechts eingeblendet
werden. Ansonsten wuerd ich's wirklich irgendwie auf die Sprite-Zeichenroutinen schieben.)
Ich hatte auch schon Fehler im Grafiktreiber o.ae. in Verdacht, in Bezug auf die im 1280er-Modus ausserhalb des Bildschirmes liegenden Rahmen etc, aber dann
muesste das bei meinen diversen anderen Spielen auch auftreten - ich spiele fast alles in 1280x960 Fenstermodus, wegen dem einfacheren rein- und raustabben.
Ich hab leider keinen Debugger/Profiler o.ae. greifbar, sonst wuerd ich mich da mal dranhaengen.. meine programmieraktive Zeit ist leider Geschichte.

autofahrn wrote:

---

Naja, wenn FileMon deutliche Aktivitäten beim Swapfile anzeigt, liegt das wohl kaum an der GraKa...

Ja, ja.
Ich denk da halt immer gleich an das Spulenfiepen der Geforce-Karten. Gebranntes Kind. 😉

Also das Verhalten ist ja wirklich völlig absurd. Klar, die Grafik auf den Buttons sind feste Bitmaps. Allerdings ist die Bitmap größer als nur das Bild, die
ganze Schrift der Buttons ist in der gleichen Bitmap enthalten. Und gemalt werden die Tasten "natürlich" nur, wenn sich die Farbe ändert.
Das einzige, was in dem Screen ständig gezeichnet wird, ist natürlich die Laufschrift am unteren Rand. Vielleicht kannst Du ja nochmal das Fenster
herumschieben und achtest einmal auf die Position der Laufschrift.
Dennoch hat das kaum etwas unmittelbar mit Robot zu tun, wenn da ein System-Dienst permanent im Pagefile herumschreibt. Wenn das bei anderen Programmen nicht
passiert, kann das z.B. auch bedeuten, dass die andere Funktionen für den Bildschirm-Zugriff verwenden. Bei 3D-Spielen dürfte das z.B. die
Direct3D-Schnittstelle sein. Die von Robot benötigte StretchDIBits Funktion ist da sicher eine eher selten benutzte Variante.
Wie sieht es denn bei anderen Fenstergrößen aus, also z.B. die nächst kleinere Größe?
...es bleibt komisch...

Bei allen Spielgroessen unter 1280 Breite tritt das Problem nicht auf, egal wo ich das Fenster hinlege. Zumindest habe ich es bisher noch nicht provozieren
koennen.
Bei 1280x870 muss ich das Bild rausschieben bis nur noch 936 Breite sichtbar bleiben, damit die Plattenzugriffe aufhoeren. Auffaelligerweise ergibt das inkl.
Titelleiste und Rahmen genau eine Fenstergroesse von 938x938, also exakt quadratisch.
Bei 1280x696 muss ich das Bild rausschieben bis nur noch 1172 Breite sichtbar bleiben, damit die Plattenzugriffe aufhoeren. Hier seh ich kein auffaelliges
Seitenformat etc.
Zum Zustand der Laufschrift etc kann ich keinen Zusammenhang erkennen.
Was mir auffaellt, ist dass bei beiden Aufloesungen die sichtbare Zeichenflaeche 815.000 px (plusminus n paar zerquetschte) betraegt, d.h. sobald mehr als
diese Flaeche sichtbar ist, schraddelt das Swapfile los. Irgendwie riecht das danach, wie wenn da irgendeine Grenze in einem DirectDraw Zeichenpuffer o.ae.
ueberschritten wird und das System dann anfaengt, das wegzuswappen. Also eher ein Fehler in DirectX (bzw. meiner Installation) als in Robot. Aber DX neu
installieren aendert nix daran.

Also das ist wirklich alles sehr merkwürdig. Die Schlußfolgerung, dass das irgendwie an der Gesamtfläche liegt, macht dabei als Einziges einen Sinn. Verhält
sich das auch im Spielgeschehen in dieser Weise?
Falls das der Fall ist, liegt's trotzdem nicht am DirectX, weil ich DirectX im Fenster-Modus ja gar nicht verwende. Da läuft das über's normale GDI und
da kann dann eigentlich nur noch der GraKa-Treiber der Übeltäter sein. Eine andere Idee habe ich dann eigentlich auch nicht mehr...
Als "Lösung" fällt mir dann eigentlich nur ein, im Vollbild oder mit einer geringeren Auflösung zu spielen.

Zu der "Lösung" mit der reduzierten Auflösung bin ich schon gekommen.. wär ja schlimm wenn ich wegen dem "Bug" gar kein Robot mehr spielen
könnte. In 960x696 isses ja auch genauso schön.
Im Spiel selbst is das Verhalten identisch zum Titelbild.. Rausschieben unter die 815k-Pixel-Grenze beendet das Geschraddel.
Muss mal meine Spielesammlung durchgucken ob ich da noch ein anderes finde, das ein so grosses Spielfeld mitbringt und über GDI zeichnet.. (sollten eigentlich
die meisten älteren/billigeren Desktopspielchen tun, oder?)
Was mir grad bissl komisch vorkommt, is, dass mir das frueher nie aufgefallen ist. Ich hab allerdings auch nen Monat oder zwei kein Robot mehr gespielt. In der
Zwischenzeit habe ich aber meinen Grafiktreiber mal neu installiert (den gleichen!).. wär bissl komisch wenn damit ein Fehler reingekommen wär der vorher nicht
da war. Neueren gibts ja leider keinen mehr, den ich testen könnte.

Im Spiel selbst is das Verhalten identisch zum Titelbild.. Rausschieben unter die 815k-Pixel-Grenze beendet das Geschraddel.

ok, das klingt aber wirklich nach einer Speicher-Begrenzung irgendwo bei der StretchDIBits Funktion. Robot weiss ja eigentlich nicht, wie viel
vom Client-Bereich nun letztendlich wirklich sichtbar ist. Ok, könnte man herausbekommen, aber ich überlasse das Clipping augenblicklich dem System (würde in
diesem Fall ja auch nichts ändern).
Da kommt mir natürlich noch 'ne Idee: Was passiert eigentlich, wenn man den Task-Manager auf "Immer im Vordergrund" stellt und damit Teile
abdeckt? Dann muss Windows das Zeichnen nämlich auf kleinere Bereiche unterteilen. Wenn das Geschraddel dann auch weg ist, wäre das für mich ein weiteres
Indiz, dass an der Stelle irgendetwas faul ist...

Muss mal meine Spielesammlung durchgucken ob ich da noch ein anderes finde, das ein so grosses Spielfeld mitbringt und über GDI zeichnet.. (sollten
eigentlich die meisten älteren/billigeren Desktopspielchen tun, oder?)

Also mit "älter" oder "billig" hat das schon einmal gar nichts zu tun. DirectDraw für eine Fenster-Applikation einzusetzen ist
halt aufwendiger, um das Clipping richtig in den Griff zu bekommen. Und die Stretch-Funktion dürften auch nur sehr wenige Applikationen einsetzen, und
wahrscheinlich auch nicht zur Skalierung des gesamten Fenster-Inhaltes (die Bitmap wird ja komplett von Robot gerendert). Von daher würde ich da eher bei
irgendwelchen Bild-Betrachtern suchen, als bei Spielen...
Ich kenne halt auch nicht die genaue Interaktion zwischen der Stretch-Funktion und dem GraKa-Treiber, also ob das Skalieren von der CPU oder der GraKa erledigt
wird. Aber wenn es die CPU (und damit eine Windows-Funktionalität) wäre, sollte ich das hier auch feststellen können. Von daher habe ich schon irgendwie den
GraKa-Treiber im Verdacht, kann mir aber beim besten Willen nicht erklären, warum der ständig auf's Pagefile zugreifen sollte.
Es bleibt komisch!

War es beim Speicher nicht so das jedem Programm / Task nur maximal 2 GB unter Windows zur Verfügung gestellt werden? Jedenfalls auf 32 Bit Windosen? Hatte das
vor kurzem im Faq eines der größeren Spiele gelesen, das die Eigenart hatte sich nach ner Weile immer mangels Speicher (selbst bei 8 GB Ram) zu beenden.
Theoretisch könntest du den Swap also abstellen.
Du nutzt auch nicht zufällig eine OnBoard Grafikkarte? Diese nehmen ja einen Teil des Ram für sich in Anspruch, und diverse Exemplare tun dies auch dynamisch.
Nun weiß ich nicht was passiert wenn der Grafikspeicher voll ist und die Graka denkt, sie müsse mehr Speicher vom Ram nehmen (den Windows ja zu diesem
Zeitpunkt schon längst am Verwalten ist). Aber ich denke mal nicht, das die Graka sich hier mit Swapspeicher zufrieden gibt 😄 oder Robot den Grafikspeicher
irgendwie "fordert".
Vielleicht hilft auch Swap von dynamisch auf eine festgelegte Größe zu stellen?
Ansonsten fällt mir da auch nüx mehr ein. Schließlich läuft Robot hier auf nem 500Mhz Lappy mit 8 MB Grafikspeicher und W2k ohne zu Murren.

Ich nutze eine Gefrosch 7600GS im AGP-Slot, die ihren eigenen RAM mitbringt.
Bezueglich den 2GB pro Task.. das ist nicht ganz korrekt so. 32bit-Windows koennen pro _Thread_ nur 2GB zuweisen, aber gerade Spiele die ihr Grafikrendering an
DirectX auslagern, sind fast immer multithreaded, und koennen damit deutlich mehr als 2GB nutzen - und da 32bit-Windows nur 3GB gesamten RAM verwalten kann,
kommt der Rest halt aus dem Swapfile. Ich spiele leider das eine oder andere Spiel regelmaessig, die rechte Speicherfresser sind (z.b. Vanguard Saga of
Heroes).. wenn ich da den Swap abschalte, raucht mir das nach einer halben Stunde mit einem Speicherfehler ab. Ich habs daher momentan auf dynamisch 1-2GB
eingestellt, und komm damit recht gut hin. Wenns nicht jedes Mal einen Reboot brauchen wuerde, den Swap zu aendern, koennt ichs ja mal eben testen.. aber
Windows ist da bissl arg scheibe programmiert.
Fensterteile abdecken hab ich noch ned probiert, mach ich gleich mal eben. Ich lass dann Edith ausrichten was rausgekommen ist. 😉
//Edith meint: Keine Veraenderung. Geschraddel bleibt, auch wenn das gesamte Bild von dauergevordergrundeten Programmen verdeckt wird. Es wird also u.U. gar
nichts dargestellt aber trotzdem gerendert. Bei der Gelegenheit ist mir auch aufgefallen, dass das Geschraddel mit 100% CPU-Auslastung einhergeht.. was bei
einem 2,8GHz Athlon relativ heftig ist. Andererseits braucht Robot auch im Normalbetrieb 40-60%.

Sorry, das ist zwar etwas off-topic, aber ich kann das so nicht stehen lassen:

Bezueglich den 2GB pro Task.. das ist nicht ganz korrekt so. 32bit-Windows koennen pro _Thread_ nur 2GB zuweisen, aber gerade Spiele die ihr Grafikrendering
an DirectX auslagern, sind fast immer multithreaded, und koennen damit deutlich mehr als 2GB nutzen - und da 32bit-Windows nur 3GB gesamten RAM verwalten
kann, kommt der Rest halt aus dem Swapfile.

Ein 32-Bit-Betriebssystem benutzt zur Adressierung nunmal 32-Bit Zeiger, und damit lässt sich ein Adressraum von 2^32=4GB darstellen. Das gilt
grundsätzlich pro Prozess. Threads eines Prozesses nutzen alle den gleichen Adressraum, sind also ebenfalls auf maximal 4GB beschränkt.
Aufgrund einer uralten Design-Entscheidung teilt sich dieser Adressraum normalerweise in zwei gleiche Teile auf, einer reserviert für's System, in welchem
sich z.B. die Treiber tummeln, und der untere Teil ist für die Applikation fast vollständig verfügbar. Und das sind Eure 2GB, die eben üblicherweise pro
Prozess gelten.
Aktuellere Windows-Versionen lassen sich durch einen Schalter in der boot.ini überzeugen, nur 1GB für's Sytem zu reservieren und damit 3GB für die
Applikation nutzbar zu haben. Das setzt allerdings voraus, dass die Applikation damit auch umgehen kann, weswegen in der Exe ein entsprechendes Flag gesetzt
sein muss.
Windows selber könnte locker mit deutlich mehr Speicher umgehen, das Problem ist, dass dieser von 32-Bit-Treibern nicht mehr direkt adressiert werden kann. Von
daher gibt's für (alle) 32-Bit Betriebssysteme nun einmal eine physikalische Grenze von 4GB verbautem RAM. Davon wird all zu häufig von der Hardware noch
etwas abgezwackt, also z.B. das Mainboard-BIOS oder gemappter Speicher der GraKa. Meist ist dieser reservierte Bereich 1GB, wodurch man auf ein Limit von 3GB
kommt. Das kann bei älteren Chipsätzen auch bei 2GB liegen und bei modernen jedoch auch darüber.
Ganz moderne CPUs (IA32) und Chipsätze können per PAE aber auch unter 32-Bit-Systemen durchaus bis zu 64GB physikalisches RAM adressieren. Davon profitieren
einmal viele parallel laufende Applikationen, oder welche, die EMS-like Teile davon in ihren virtuellen Adressraum einblenden.
So, kommen wir zum Swapfile. Wenn ein Applikation irgendwie auf Speicher zugreift, das kann sowohl Programmcode oder eben Daten sein, dann liegt dies
immer im physikalischen RAM. Da der Adressraum allerdings virtuell ist (= kein linearer Zusammenhang mit physikalischen Adressen), ist es möglich,
dass an der Stelle gerade gar kein RAM eingeblendet oder die Seite gerade ausgelagert ist. Dann gibt's 'ne ganz ordinäre Speicherschutzverletzung, das
Betriebssystem übernimmt die Kontrolle und sorgt dafür, dass da erstmal RAM eingeblendet wird. Ist das geschehen, wird die Instruktion einfach wiederholt.
Jetzt kann es eben vorkommen, dass gerade kein physikalisches RAM mehr frei ist, und dann wird eben ggf. eine länger nicht mehr benutzte
Speicher-Seite in die Auslagerungs-Datei geschrieben und diese nun freie Seite in den Adressraum des "anfragenden" Prozesses gemappt.
Oder andersherum: Wenn das System über 3GB Arbeitsspeicher verfügt und eine Applikation ihre gesamten 2GB verwendet, wird die Swapdatei ruhig sein. Eventuell
wird beim Start erstmal alles Mögliche ausgelagert und nach Beenden des Prozesses wieder eingelagert, aber während die Applikation läuft, sollte im Swapfile
nicht viel passieren.
Das war früher, als der verfügbare Speicher deutlich kleiner als der virtuelle Adressraum war, ganz anders. Da konnte ein Prozess, der sehr viel virtuellen
Speicher genutzt hat, in der Tat massive Aktivität beim Swapfile provozieren...
Soviel in Kürze. Ich weiss, da fehlen einige Details, aber das muss jetzt reichen... 😉
Ok, zurück zum Thema. Wenn auch bei abgedecktem Fenster das Geschraddel weitergeht, liegt der Hund irgendwo im GDI begraben. Denn bei abgedecktem Fenster
bekommt der Grafik-Treiber vom Zeichen-Wunsch gar nichts mehr mit. Damit steht für mich die StretchDIBits-Routine als Verursacher ziemlich fest. Wobei ich nach
wie vor nicht verstehen kann, warum da das Swapfile einspringen muss. Mit Speicher-Knappheit hat das sicher nichts zu tun...
Dass da die CPU-Last auf 100% hochgeht ist den ganzen Schutzverletzungen und Kontext-Wechseln zwischen Ring 3 (Applikation) und 0 (System) geschuldet, das
kostet halt tierisch Performance. Die sonstigen 40-60% gehen definitiv auf die Kappe von StretchDIBits, welches nicht die effizienteste Routine ist, um Bitmaps
gedehnt darzustellen. Das ginge per DirectX deutlich effizienter (ein weiterer Beleg dafür, dass der GraKa-Treiber hier nichts mit zu tun hat). Das war ja eine
der Sachen, die ich eigentlich noch ändern wollte... 😉