@Piktogramm gut, über das CPU Prefetching als analogie für HDD Zugriffe lässt sich streiten. Ich wollte damit sagen dass selbst bei etwas scheinbar so aussichtslosem wie Sprungvorhersage lohnt es sich. Dagegen ist die Entscheidung welche Assets in einem Spiel gebraucht werden doch geradezu simpel. Anders als die CPU hat der Spieleentwickler schließlich auch inhaltliche Kenntnisse über die Daten.
Nur weil ein Spiel Levelbasiert ist muss es doch auch noch lange nicht alle nötigen Daten im Speicher haben. Dass es praktisch darauf hinausläuft ist doch nur die praktische Umsetzung. Open World lädt unterteilt analog dazu quasi die Welt in angrenzende Level und lädt mehrere nach Bedarf. Skyrim passt als Beispiel, wobei auch Oblivion und Morrowind funktionieren.
Da gibts 'außenweltkacheln' um den Spieler herum die geladen werden. Prefetching könnte man Problemlos machen indem beim anvisieren einer Tür schon mal das innenlevel dahinter geladen wird falls gerade nichts wichtigeres zu laden ist. Oder schon bei der Annäherung so dass idealerweise das Innenlevel geladen ist sobald man in Aktivierungsreichweite ist.
Damit man nicht ständig nutzlos preloading macht brauchts noch eine bremse für enge Gassen mit vielen Haustüren. Die sind dann eben schwieriger als die einzelne Höhle/Turm/whatever in der Wildnis. Aber auch da kann man doch davon ausgehen dass Spieler die Türen meistens gezielt ansteuern und seltener urplötzlich eine 540° Drehung machen und die Tür aktivieren. Bei mehreren Möglichkeiten lädt man also nur die offensichtliche vor.
Genauso lässt sich ein bisschen Heuristik einbauen. Es sollte nicht soo schwer sein halbwegs zuverlässig zu erkennen ob ein Spieler gerade aktiv quests erledigt (Questgebiete priorisieren) oder nur frei herumläuft (mehr fokus auf Sicht und Laufrichtung) und wenn jemand beides macht wird eben neutral bewertet.
Wenn das System so sehr am limit ist dass ein paar Feuerbälle und Overlaytexturen (sind die nicht immer noch relativ generisch und nicht Oberflächenspezifisch?) die Performance killen ist eben keine Luft nach oben. Wenn das schnelle Medium zu klein ist gehts eben immer auf das nächste über. VRAM, RAM, SSD/HDD. Caching weglassen änder daran auch nichts. Aber es tut richtig weh wenn das Medium mal nicht so schnell ist wie erhofft.
Bislang wird eben andersrum gecached, man behält das was im Speicher war noch eine weile drin bis es verdrängt wird. Falls es verdrängt wird. Gab für Oblivion nicht umsonst Tools dafür. Ohne Streamline war mit Texturpacks und erhöhter Sichtweite schnell ende mit Spielspaß weil der Cache wichtiger war als neue Daten.
Aber ist es intelligent die gerade gesäuberte Höhle im Cache zu behalten statt das nächste Gebiet auf das der Spieler gerade zuläuft in den Cache zu schieben? Das ist aus meiner Sicht keine allzu anspruchsvolle Entscheidung sobald der Spieler sich ein Stück vom Höhleneingang fortbewegt hat.
Es ist sicher mehr Arbeit als nur reaktiv nach Bedarf zu laden, aber ich glaube nicht dass es im Vergleich zum Rest der Spieleentwicklung so ein schrecklicher Aufwand ist ein halbwegs gut funktionierendes preloading das auch auf Speichern mit hohen latenzen funktioniert zu bauen. Texturstreaming ist doch soweit ich das sehe recht ähnlich, denn der Weg vom RAM in den VRAM ist auch relativ weit im vergleich zu alles im VRAM. Dazu muss der Speicher da auch ausreichen.
Das dürfte in der Komplexität vergleichsweise harmlos sein gegenüber Multithreading auf 4+ Kernen.
Dazu fällt mir ein dass das vorraussetzen von schnellen SSDs als Spieleplatte noch mehr Probleme mit sich bringt als nur HDDs und langsamere SSDs auszuschließen. Denn dann muss die Geschwindigkeit und Latenz auch garantiert sein. Weniger Spielraum für parallele Zugriffe. Aber das eigene System in der Hinsicht optimieren war schon zu HDD Zeiten zu viel für die meisten, warum sollte das heute oder morgen anders sein? Dann ruckelts doch wieder weil Windows oder irgendein Launcher im Hintergrund updates macht, oder der Virenscanner durchläuft und die formal ausreichende SSD dann eben nicht mehr ganz reicht für nahtloses Asset streaming.
Das ist wie anzunehmen dass die CPU einem Programm allein vollständig zur verfügung steht und man direkt auf Cachegrößen und Latenzen optimieren kann. Hat der Anwender dann noch was parallel laufen ruckelts im zweifelsfall eben wieder weil Kontextwechsel nicht eingeplant waren. Ich dachte dass man das nicht merken würde, aber manche Anwendungen schaffen sowas. Nimm der einen Kern von 8 weg und es ruckelt. Lass eine nicht triviale Hintergrundanwendung was tun und es ruckelt. Dabei muss die CPU nicht ausgelastet sein. Ich denke zumindest dass das die Folge von einer überoptimierung in dieser Art ist. Oder man kann Windows dazu bringen Größenordnung 8-16 ms Zeitscheiben beim Scheduling zu verwenden.
) und schiebt den ungewollten Teil eher einfach in den cache. Oder irre ich mich da?
