spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Zitat von »TrikkieMikkie«

Hm joa oder auch nicht!? -> http://msdn.microsoft.com/de-de/library/…28VS.80%29.aspx

Oh oke. Danke das wusste ich nicht.

Bezüglich Bitlänge der Typen gibt es verschiedene Datenmodelle. Visual Studio nutzt LLP64 und hat 32 Bit long. Der gcc nutzt LP64 und hat 64 Bit long. Ansonsten bleibt es aber gleich: int 32, long long 64, Pointer 64 usw.

Bei x64 sind auch neue Register dazu gekommen. Das kann zu etwas Geschwindigkeitszuwachs führen. Außerdem kann man bei 64 Bit Prozessoren etwas mehr Funktionalität voraussetzen. So könnte man standardmäßig SSE nutzen und ähnliches.

Da ich das Thema gerade zufällig gesehen habe:
In der Regel solltest du lediglich eine 64-Bit-Config zu deinem Projekt hinzufügen müssen und es sollte... eigentlich... sofort funktionieren, ggf. noch mal die Übersicht der Erstellungskonfig für alle Projekte anschauen, ob dort auch alles jeweils auf 64-Bit steht.

Zum Nutzen generell:
Ich erstelle seit Jahren immer beides und unterm Strich sind die x64-Varianten von sich aus erstmal meistens minimalst langsamer und brauchen etwas mehr Speicher (dadurch dass Pointer halt gleich 8 Byte brauchen).
Wenn man den Vorteil von 64-Bit aber sinnvoll nutzt, sind je nach Anwendungsfall locker 30-40% höhere Performance drin, da man halt extrem großen Spielraum hat Daten einfach zu halten, die man auf 32-Bit-Sytemen mangels Speicher immer wieder freigeben müsste, seien es Daten einer Landschaft, 3D-Modelle, die man wieder von der Platte holen müsste usw. usw..

LG
Alyx

das thema ist schon etwas älter, aber trotzdem...

bei 64bit / 32bit muss man beim programmieren immer aufpassen. es gibt z.b. unterschiedliche int's (uint32_t, uint64_t), was dann bei funktionen wie printf() zu problemen führen kann (z.B. "%016lX" vs. "%016llX" für long). und selbst da muss man dann nochmals aufpassen, weil das bei MS wieder anders ist (da wäre es dann "%016I64X"... fragt mich nicht, weshalb).

ein beispiel, wie so eine config dann aussieht, wenn man für die unterschiedlichen compiler und zielplattformen (jetzt nicht nur amd64 und x86) unterscheiden will, sieht so aus (ACE wrappers 5.6.6): http://github.com/mangos/mangos/blob/mas…e/Basic_Types.h

wenn man nicht aufpasst, kann es dann zu solchen fehlern führen: http://github.com/mangos/mangos/commit/8…adbefd069e3fdc9
ich hatte dort "%u" verwendet, was auf 32bit systemen auch funktionierte. aber auf 64bit systemen hat es dann natürlich nur die ersten 4 bit genommen, was dazu führte, dass dort immer 0 stand. nach einer änderung auf UI64FMTD (was bei ACE definiert ist und je nach plattform "%u", "%lu" oder "%llu" ist) hat das ganze dann funktioniert.

von daher: immer auf allen plattformen testen, wenn ihr was macht
(und vorallem auch mit unterschiedlichen compilern...)

Oder Datentypen nutzen die Plattform unabhängig sind. Gerade bei Netzwerkspielen von vorteil wenn ein 32 bit immer lang ist egal wo

hat den Vorteil, das mensch sich gleich Gedanken über portable Programmierung macht

klar, ich arbeite wenn immer möglich nur mit den ACE datentypen bei dem projekt (d.h. da hast du dann uint32, int32, uint64, int64, etc.), aber es gibt halt auch datentypen, wie z.b. time_t, die plattformabhängig sind :/

Diese sollte man dann aber wenn möglich nicht verschicken und wenn möglich auch die entsprechenden Verarbeitungsmethoden nehmen (z.B. asctime oder eben in eine time struct umwandeln). Außerdem, wer nutzt in zeiten von std::stringstream noch sprintf, wenn es um größere/portable Projekte geht ?