Gothic 3 und SSD - hats schon jemand probiert?

[Doomi]

Hat schon jemand G3 auf ne SSD installiert ?( Vorzugsweise was schnelles wie zB Intel X-25 oder Gskill Falcon/ OCZ Vertex )

Würde mich interessieren wie sich sowas auf Folgendes Auswirkt:

- Ladezeiten
- Laderuckler
- Spielstandspeicherungszeit

[reunion]

Forgot it. Selbst auf einer RAM-Disk ruckelt das Spiel noch. Da wurde irgend was an der Engine verhunzt, eine schnellere Platte nützt nichts.

[mekakic]

Nee, mit Ram Disk läuft es schon wesentlich flüssiger. Für die letzten minimalen Ruckler braucht man dann einfach ganz viel Single Core CPU Leistung - aber der Unterschied zum Spiel von Festplatte ist schon sehr deutlich.

[Gouvernator]

Ich habe G3 auf SuperTalent 64Gb laufen. WinXp x64 liegt auf einer normalen 7200 U/min und das Spiel auf der SSD.

- Ladezeiten = schnell, kommt mir nicht viel schlechter als bei G2 vor.
- Laderuckler = ca. 5Min lang am Anfang, danach wird sehr smooth.
- Spielstandspeicherungszeit = k.a. es wird auf die normale Festplatte gespeichert. Geht eigentlich.

Es ist mit einer SSD spielbar geworden. Früher habe ich als versucht mit G3 anzufangen und dann immer aufgehört wegen ständigen Nachladerucklern die niemals aufhören wollten. Mit einer SSD ist es sehr sehr erträglicher geworden. G3 ist praktisch damit zu einem ganz gewöhnlichem Spiel geworden ohne horrende Anforderungen und Ruckler.

[sapito]

Ich habe G3 auf SuperTalent 64Gb laufen. WinXp x64 liegt auf einer normalen 7200 U/min und das Spiel auf der SSD.

- Ladezeiten = schnell, kommt mir nicht viel schlechter als bei G2 vor.
- Laderuckler = ca. 5Min lang am Anfang, danach wird sehr smooth.
- Spielstandspeicherungszeit = k.a. es wird auf die normale Festplatte gespeichert. Geht eigentlich.


aktueller patch? wenn ja, wird es weniger an der ssd als am patch liegen (ladezeiten, nachladeruckler). bitte noch mal mit instalation auf normaler hd vergleichen.

[Doomi]

klingt ja schon alles nicht schlecht.

[Spasstiger]

Ich hatte es mal auf der Ramdisk, aber es lief genauso wie von HDD. D.h. immer noch gelegentlich Nachladeruckler.

[reunion]

Ich hatte es mal auf der Ramdisk, aber es lief genauso wie von HDD. D.h. immer noch gelegentlich Nachladeruckler.

Detto bei mir.

[Grestorn]

Die "Nachladeruckler" entstehen ja nicht nur durch das Laden von der Platte sondern

a) auch durch das Kopieren der Texturen und der Geometrie in das VMem der GPUs.
b) durch die GarbageCollection des MemoryManagers (nicht mehr benötigten Speicher freigeben und den Speicher so umorganisieren, dass wieder große Adressblöcke am Stück frei werden).

Und da hilft nun mal keine schnellere Platte. Problem b) kriegt man ausschließlich nur mit einer 64bit Architektur in den Griff.

[Doomi]

meinst du jetzt das der User das Problem mit einem 64 Bit OS in den Griff bekommen könnte oder allgemein das das Spiel für 64 Bit optimiert werden müsste ?

[OC_Burner]

Ich hatte es mal auf der Ramdisk, aber es lief genauso wie von HDD. D.h. immer noch gelegentlich Nachladeruckler.

Dito, da hilft wirklich nur pure Rechenkrafterhöhung der CPU und deutlich schnellere Anbindungen für die Komponenten um der CPU.

meinst du jetzt das der User das Problem mit einem 64 Bit OS in den Griff bekommen könnte oder allgemein das das Spiel für 64 Bit optimiert werden müsste ?

Das Spiel müsste allgemein als 64-Bit Version daherkommen. So sollte das wohl gemeint sein.

[Grestorn]

Das Spiel müsste allgemein als 64-Bit Version daherkommen. So sollte das wohl gemeint sein.

Korrekt. Unter 32 bit gehen dem Spiel die virtuellen Adressen aus ("nur" 2 bzw. 3 Gigabyte mit dem LAA-Flag), was dazu führt, dass der Adressbereich schnell fragmentiert und deswegen ständig neu aufgeräumt werden muss, ganz ähnlich wie eine Festplatte, die reorganisiert werden muss. Dieser Reorg kostet Zeit und das sind die immer wieder auftretenden, längeren Ruckler.

Nur dass die Konsequenz der Fragmentierung beim Speicher schlimmer als bei einer Platte ist: Eine Platte wird nur langsamer, wenn sie fragmentiert, beim Adressbereich haben größere Speicherblöcke auf einmal keinen Platz mehr und das Spiel stürzt ab. Mit die wichtigste Ursache m.E. für die Stabilitätsprobleme von Gothic 3.

Man kann den Speichermanager schon besser machen, z.B. in dem man den Reorg in einen eigenen Thread verlagert und permanent im Hintergrund laufen lässt. Das hat aber Auswirkungen auf das ganze Programm und wie auf den Speicher zugegriffen wird (man braucht generell Locking-Mechanismen, damit nicht ein Speicherbereich gerade umorganisiert wird, während man darauf zugreift).

Das ist wohl nicht mehr im Nachhinein in G3 reinzubringen.

Unterm Strich bleibt: Je schneller wir 32 bit endgültig zu den Akten legen, desto besser für alle! :)

[mekakic]

Wird bei G3 wirklich der Heap defragmentiert? Dann müßte man ja alle Objekte über Doppelpointer oder ähnliches auf eine Memory Manager Schicht zeigen lassen, die dann bei Zeiten Objekte sperrt und da rumzuwühlen beginnt. Und dann müßte man sich noch aussuchen, wann man es macht.

[Grestorn]

Ja, der Heap wird fragmentiert. Und ja, es gibt bereits virtuelle Pointer, das bringt eine automatische Speicherverwaltung immer mit sich (und davon war des öfteren in den Patchnotes die Rede), aber offensichtlich wurde kein konsequentes Lock und Unlock der Speicherbereiche im Code verwendet, sonst wäre ein Defrag (bzw. Garbage Collection) des Heaps in einem eigenen Thread kein Problem.