Woran scheitert die 64-Bit-Revolution bisher?

[Grestorn]

Warum muß ein Objekt im Adressraum liegen, wenn es noch nicht einmal geladen wurde? Ich glaub das präzisiert jetzt meine vorhergehenden Fragen recht gut.

Muss es nicht, das habe ich auch nicht geschrieben. Die Objekte müssen nur in der Objekttabelle verzeichnet sein (eben Deine Playlist), nehmen dort aber keinen nennensweren Platz ein.

Erst wenn sie geladen werden, nehmen sie Platz im Adressraum ein - bis sie daraus wieder gelöscht werden, dann wird der von ihnen belegte Adressraum wieder frei.

Wie gesagt, stell Dir das Inventory in Diablo vor: Du packst Sachen rein, und verkaufst sie teilweise wieder. Dadurch entstehen Lücken im Inventory, die Du mit anderen Dingen belegen kannst. Es ist aber sehr einfach möglich, dass die noch vorhandenen Items so ungünstig im Inventory verteilt sind, dass das neue, große Objekt keinen Platz findet - erst wenn Du das Inventory aufräumst, sprich alle Items möglichst platzsparend anordnest, passt das neue, große Objekt wieder hinein.

Wem man in einer Diskussion mehr zutraut sollte man übrigens möglichst nicht von Sympathien sondern bessern von den Argumenten abhängig machen...

[Kriton]

Könnte man über eine dynamischere Programmierung hinsichtlich des Aufräumens die Ruckler umgehen (klar, dass das aufwendiger ist)? Denn wenn ich das richtig verstehe entstehen die doch dadurch, dass die Aufräumarbeiten in regelmäßigen Abständen komplett durchgeführt werden und dann soviel Zeit benötigen, dass das Spiel kurzzeitig steht.

[Exxtreme]

Könnte man über eine dynamischere Programmierung hinsichtlich des Aufräumens die Ruckler umgehen (klar, dass das aufwendiger ist)? Denn wenn ich das richtig verstehe entstehen die doch dadurch, dass die Aufräumarbeiten in regelmäßigen Abständen komplett durchgeführt werden und dann soviel Zeit benötigen, dass das Spiel kurzzeitig steht.
Das ist halt die Problematik. Alles wird aufwändiger weil man andauernd um technische Limits herumprogrammieren muss. "Löcher" im RAM wieder zumachen, indirekt addressieren etc. Müsste alles nicht sein wenn man mehr Adressraum hätte.

[Grestorn]

Das ist halt die Problematik. Alles wird aufwändiger weil man andauernd um technische Limits herumprogrammieren muss. "Löcher" im RAM wieder zumachen, indirekt addressieren etc. Müsste alles nicht sein wenn man mehr Adressraum hätte.
Genau so ist es, und das ist das Kernstück dieser Diskussion, der Hauptpunkt wieso man so schnell es geht die 32 bit hinter sich lassen sollte.

@Kriton:
Das Problem ist, dass bei der Reorganisation des Speichers ja kein Zugriff auf eben diesen Speicher erfolgen kann, zumindest nicht auf die Teile, die gerade verschoben werden. Man kann das schon parallel machen, muss dann aber bei jedem Zugriff auf ein Objekt sicherstellen, dass dies nicht gerade verschoben wird. Also auch wieder zusätzliche Kontrollen und Abfragen, die das Gesamtsystem nicht schneller machen.

Und natürlich auch fehleranfälliger, zumindest in C++, wo ich dem Programmierer erst mal nicht verbieten kann, direkt auf den Speicher zuzugreifen. Macht er das einmal, ohne sich vorher die "Erlaubnis" zu holen, dann kann es krachen - zwar nur sehr selten, dafür aber um so schwerer zu finden.

[BlackBirdSR]

Genau so ist es, und das ist das Kernstück dieser Diskussion, der Hauptpunkt wieso man so schnell es geht die 32 bit hinter sich lassen sollte.



Dann wieder zu einem Punkt den ich bereits angesprochen habe:
Auch durch Vista x86 werden wir auf Jahre hin eine große 32Bit-Basis haben. Vielleicht sogar die größere.

Designer und Programmierer müssen das nicht nur berücksichtigen, 32 und 64-Bit Versionen müssen ja auch identisch sein was Levels, KI, Skripts etc anbelangt.

Sieht es dann nicht so aus, dass wir auch Jahre hin auf dem jetzigen Niveau gefangen sind, und die Probleme nicht besser sondern immer schlimmer werden?

Ich sehe das zumindest so, und Ausweg gibt es nur wenn jemand mutig genug ist die 32er auszusperren.

[mekakic]

Sehe ich eigentlich nicht ganz so apokalyptisch, sicher wäre es besser gewesen Vista wäre nur als 64bit Version erschienen, aber sobald man durch den Einsatz eines 64Bit BS einen deutlichen Vorteil hat, wird eine freiwillige Migration einsetzen von Leuten, die sonst keinen Vorteil in 64bit hatten. Bei komplexeren Spielen kann ja eine parallele 64Bit Version erscheinen, insbesondere wenn man nicht so viele Anpassungen braucht und vieles eigentlich nur leichter wird. Und die 64Bit Version muß ja im Bereich Sichtweite zum Beispiel nicht gleich sein, wenn die Leute diese Vorteile sehen wird auch ein 64bit OS gleich in Betracht gezogen.

Solange es konsequent bei komplexeren Spielen eben x64 Versionen mit Vorteilen gibt, wird der Anteil steigen und irgendwer kann dann auch mal 32bit aussperren. Nur Gothic hätte ja schon als x64 Version erscheinen müssen...

[Exxtreme]

Designer und Programmierer müssen das nicht nur berücksichtigen, 32 und 64-Bit Versionen müssen ja auch identisch sein was Levels, KI, Skripts etc anbelangt.

Nö, müssen sie nicht. Wird bei anderen technischen Limits doch auch nicht gemacht.

[Grestorn]

Solange es konsequent bei komplexeren Spielen eben x64 Versionen mit Vorteilen gibt, wird der Anteil steigen und irgendwer kann dann auch mal 32bit aussperren. Nur Gothic hätte ja schon als x64 Version erscheinen müssen...

Leider kommen ja nur PC-Only Spiele dafür überhaupt in Frage. Und da die meisten Spiele heutzutage ja nur noch Konsolen-Konvertierungen sind, sehe ich da leider schwarz.

G3 wäre ein guter Kandidat gewesen... aber die hatten glaube ich einfach andere sorgen. Und die 32bit Version ist auf alle Fälle derzeit und auf absehbare Zeit noch viel wichtiger.

Crysis gibt es ja in 64 bit, und es ist sicher auch kein Zufall, dass in der 64bit Version das Streaming per Default abgeschaltet ist ... :) Leider läuft Crysis in 32bit noch zu gut (weil weder Level noch Weitsichtigkeit soooo groß sind), so dass 64bit hier zu wenig Vorteil bringt, als das die Leute sich alleine deswegen ein 64bit OS installieren würden...

[BlackBirdSR]

Nö, müssen sie nicht. Wird bei anderen technischen Limits doch auch nicht gemacht.

Du kannst das Level für 64er jedoch nicht größer machen. oder die KI intelligenter Man müsste Skripts anpassen, nach neuen Bugs suchen und mehr Geld aufwenden. Zusätzlich müssten Multiplayer-Spiele weiter vollständig kompatibel bleiben.

Wer bitte gibt Geld aus, für 2 Versionen eines Spiels? EA oder Ubisoft garantiert nicht.

[Exxtreme]

Du kannst das Level für 64er jedoch nicht größer machen. oder die KI intelligenter Man müsste Skripts anpassen, nach neuen Bugs suchen und mehr Geld aufwenden. Zusätzlich müssten Multiplayer-Spiele weiter vollständig kompatibel bleiben.

Wer bitte gibt Geld aus, für 2 Versionen eines Spiels? EA oder Ubisoft garantiert nicht.
Du kannst aber anstatt grösserer Sichtweite eine animated Bitmap hinklatschen und woanders auch sparen. Wenn jemand den vollen Overkill will dann muss er ein 64-Bit-System haben.

[BlackBirdSR]

Du kannst aber anstatt grösserer Sichtweite eine animated Bitmap hinklatschen und woanders auch sparen. Wenn jemand den vollen Overkill will dann muss er ein 64-Bit-System haben.

Ich rede aber leider nicht von Sichtweite, sondern Designentscheidungen die direkt mit dem User interagieren. Es wird ja nicht nur bei der Sichtweite knapp. Speziell wenn wir jetzt von großen Multiplayerspielen oder zusammenhängenden dynamischen Levels reden.

[DerRob]

könnte man da nicht am ehesten an den texturen sparen? dann gibt es halt "high details" nur noch bei 64 bit, unter 32 bit muss man sich hat mit "medium" begnügen. das leveldesign, ki, usw. könnte bei beiden versionen die gleiche bleiben, so da es spielerisch keine unterschiede gibt.
oder ist der anteil der texturen am benötigten speicher zu gering? welche "komponenten" benötigen denn überhaupt wie viel speicher bei einem computerspiel?

[Gast]

könnte man da nicht am ehesten an den texturen sparen? dann gibt es halt "high details" nur noch bei 64 bit, unter 32 bit muss man sich hat mit "medium" begnügen. das leveldesign, ki, usw. könnte bei beiden versionen die gleiche bleiben, so da es spielerisch keine unterschiede gibt.
oder ist der anteil der texturen am benötigten speicher zu gering? welche "komponenten" benötigen denn überhaupt wie viel speicher bei einem computerspiel?
Das mit den Texturen stimmt schon, beim Leveldesign geht das nur bedingt. Weltgeometrie, meshes usw. brauchen auch Platz. Wenn dann noch komplizierte (=große) Datenstrukturen dazukommen um eine glaubwürdige Welt zu simulieren dann stößt man schnell an die Grenze. Das ist die Designentscheidung von der BlackBird redet. Und das macht dann spielerisch sehr wohl einen Unterschied.

[Wuzel]

Was hat den eigentlich diese komische Problematik (Spielwelten und so) mit 32/64bit Adressraum zu tun?
Ich kratz mir gerade am Kopf, über was sich diese Diskusion dreht.
Extern grössere Bereiche direkt zu adressieren? Das 32bit DPTR's (indirekte Adressierung) am Ende sind? (Sind sie übrigens nicht).
Speedverlust beim Pagen?
:conf2:

Aber vieleicht wieder so ein xy86 Problem, mit nem 8052'er und aufgebrezeltem DPTR/Counter krieg ich ~2Tb ohne mucken Adressiert (St. 8bit und 2x 16bit DPTR, gebrezelt 8bit / 32 + 24 bit).

[N0Thing]

Das ist halt die Problematik. Alles wird aufwändiger weil man andauernd um technische Limits herumprogrammieren muss. "Löcher" im RAM wieder zumachen, indirekt addressieren etc. Müsste alles nicht sein wenn man mehr Adressraum hätte.


Ist es beim Zugriff auf den RAM nicht möglich die Daten, wie bei einer Festplatte defragmetiert abzulegen? Bzw. wenn es möglich ist, aufgrund welcher Nachteile wird es nicht gemacht?

[Grestorn]

Ist es beim Zugriff auf den RAM nicht möglich die Daten, wie bei einer Festplatte defragmetiert abzulegen? Bzw. wenn es möglich ist, aufgrund welcher Nachteile wird es nicht gemacht?

Das entspricht einer GarbageCollection mit allen hier besprochenen Einschränkungen und Nachteilen.

[Ectoplasma]

Was hat den eigentlich diese komische Problematik (Spielwelten und so) mit 32/64bit Adressraum zu tun?
Ich kratz mir gerade am Kopf, über was sich diese Diskusion dreht.
Extern grössere Bereiche direkt zu adressieren? Das 32bit DPTR's (indirekte Adressierung) am Ende sind? (Sind sie übrigens nicht).
Speedverlust beim Pagen?
:conf2:

Aber vieleicht wieder so ein xy86 Problem, mit nem 8052'er und aufgebrezeltem DPTR/Counter krieg ich ~2Tb ohne mucken Adressiert (St. 8bit und 2x 16bit DPTR, gebrezelt 8bit / 32 + 24 bit).

Es geht um den zu kleinen virtuellen Adressraum in 32-Bit. Du bekommst in diesem oft keine großen Objekte unter, die du an einem Stück im Speicher halten kannst. Dabei kann es schon passieren, selbst wenn du 2GB Speicher im Rechner hast, dass du 100 Mega Byte schon nicht mehr am Stück reservieren kannst, wenn der Speicher stark fragmentiert ist. D.h. du hast Entwicklungsaufwand ohne Ende, der zu dem noch sehr viel Geld kostet, um solche Probleme zu lösen.

Mit einem virtuellem Adressraum in einem 64-Bit System, ist das alles kein Problem mehr. Der Adressraum ist so groß, dass du immer einen zusammenhängenden Bereich findest, in dem große Objekte hinein passen. D.h. du hast sehr viel weniger Entwicklungsaufwand.

Das zum Thema Spielwelten in 32/64 Bit. Es geht nicht darum, wie viel Speicher man tatsächlich im Rechner hat, sondern nur um die Größe des virtuellen Adressraums und dessen Auswirkung auf die Entwicklung einer Software.

[BlackBirdSR]

Um es klarzustellen:
Wir sind nicht an dem Punkt, wo die 32-Bit Adressierung Probleme erzeugt die unmölglich zu lösen sind. Wir sind allerdings an einem Punkt, wo Probleme spürbar werden. Ein 64-Bit OS samt 64-Bit Applikationen wäre an sich die einfachste Lösung. Man müsste sich mit diesen Probleme nicht herumschlagen, und es spricht theoretisch kaum etwas dagegen. Nein man bekommt auch noch ein paar Vorteile der AMD64-Architektur.

Allerdings... und das ist ein großes allerdings: Die Userbasis ist bei 32-Bit dermaßen groß, dass es sehr schwer sein wird den Umstieg schnell oder scharf zu gestalten. Wir haben quasi die Musterlösung für das Problem vor uns, scheitern aber daran, dass nicht jeder die nötigen Werkzeuge hat sie einzusetzen.

Und ich denke darum geht es ingesamt in diesem Thread: Zu Beginn scheitert die "Revolution" am noch recht kleinen Bedarf, zur Mitte hin an der recht kleinen Userbasis. Bis eben die kritische Masse überschritten ist.

[Gast]

etwas ketzerische frage: angenommen auf der gothic3 dvd wär neben der 32 bit version auch eine 64 bit version gewesen, die ohne crash to desktop, korrupte saves und den ganzen anderen freuden der 32bit version einfach nur funktioniert hätte... würdet ihr dann über jowood meckern oder würdet ihr das eher als bestätigung sehen das 32bit langsam nich mehr reicht und man dringend auf 64bit umsteigen sollte ?

[ilPatrino]

um mal wieder auf die ausgangsfrage zurückzukommen: bei mir an den beschissen zusammengeklickten programmen, die ohne grund nicht laufen, weil sie der meinung sind, kein windows vor sich zu haben.

aktuelles beispiel: fotoup. der installer bricht auf xp64 mit dem hinweis auf "9x/ME, 32Bit-Window" ab. der compatibility-modus bringt nichts. das programm - von xp32 rüberkopiert - an sich funktioniert übrigens hervorragend.

[HOT]

Hm, KI usw. frisst doch sowieso nicht allzuviel RAM. Was wirklich frisst, sind die riesigen Texturen, gepaart mit grosser Sichtweite und komplexen Levels. Ich sehe da kein Problem, bei Konsolenumsetzungen spürbare Vorteile in 64Bit zu erzeugen. Das wird eh nur optisch passieren, die Grafik ist das Zugpferd für 64Bit.