C++, MSVC10, Bitfelder packen
Code: Alles auswählen
struct TextureColor16
{
std::uint8_t R : 5;
std::uint8_t G : 5;
std::uint8_t B : 5;
std::uint8_t A : 1;
};
static_assert(sizeof(TextureColor16) == 2, "Wrong size");
In C++ gibt es halt keine Properties das heißt, ich muss auf die Daten immer als Funktion zugreifen. Des Weiteren brauche ich einen Getter und einen Setter. Gibt es wirklich keine andere Möglichkeit?schreib dir eine Funktion, die die Werte per Bitgefummel selbst ver- bzw. entpackt
Nicht nerviger als komplizierte Loader schreiben oder Getter und Setter entwerfen und vorallendingend auch zu benutzen.wird es nervig
Ja, gottseidank is C++ von Properties verschont geblieben... ;)Spiele Programmierer hat geschrieben:In C++ gibt es halt keine Properties
Die Frage ist, ob du die Daten programmintern auch wirklich so speichern willst und wenn ja: warum? Warum intern nicht einfach mit 8 Bit RGBA arbeiten und nur beim Speichern/Laden konvertieren? Die Platzersparnis bezahlst du natürlich mit Performance...Spiele Programmierer hat geschrieben:Gibt es wirklich keine andere Möglichkeit?
Weil es sie in C gab und man C++ mit C kompatibel halten wollte...Spiele Programmierer hat geschrieben:Wofür gibt es dann in C(++) überhaupt Bitfelder?
Bitfelder sind für praktisch alles völlig ungeeignet... ;)Spiele Programmierer hat geschrieben:Wenn die Bitfelder nicht richtig gepackt werden sind sie sowohl von der Platzersparnis als auch als Dateninterface wie bei mir vollkommen ungeeignet.
Hm? Was hast du den gegen Properties?Ja, gottseidank is C++ von Properties verschont geblieben... ;)
Weil das Einlesen dann einfach und schnell ist.Die Frage ist, ob du die Daten programmintern auch wirklich so speichern willst und wenn ja: warum?
Und wie genau sollte das passieren? Um was für eine Art Verarbeitung geht es da? Ist die Gefahr, dass, aufgrund der mangelnden arithmetischen Genauigkeit, Artefakte durch Rundungsfehler entstehen, nicht viel realer?Spiele Programmierer hat geschrieben:Weil das Einlesen dann einfach und schnell ist.Die Frage ist, ob du die Daten programmintern auch wirklich so speichern willst und wenn ja: warum?
Außerdem habe ich damit eine Garantie, dass Daten die nicht verändert werden, auch nach der Verarbeitung exakt genauso wieder zurück in die Datei geschrieben werden. Wenn ich Anfange beim Laden und Speichern die Daten zu verarbeiten, dann besteht die Gefahr das das eine oder andere Bit "unter die Räder" kommt. Sollte zwar nicht sein, aber ich sehe die Gefahr das es passieren könnte.
Dann mach das einfach, wo liegt das Problem?Spiele Programmierer hat geschrieben:Außerdem gibt es auch einige Daten im Format deren Zweck unbekannt ist. Diese möchte ich auch genau wieder schreiben können und ich kann nicht den gesamten Daten auseinander nehmen und dann "intern sauber speichern".
Wenn ich eine wirklich saubere interne Datenrepräsentation will, wie auch im restlichen Programm, so müsste ich einen Gleitkommatypen wählen. Gut ok, hier kein Problem weil nur 0 bis 31 sollte sich in einen Floatingpoint exakt abspeichern lassen. Es gibt aber natürlich auch größere Integer bei denen das nicht mehr ginge und außerdem sind exakte Gleitkommawerte immer problematisch.Und wie genau sollte das passieren?
Nun, es gibt einen Leveleditor, der leider aber nicht alle Features der Spielengine unterstützt. Im Editor lassen sich Dinge zum Beispiel nur mit rechteckigen Texturausschnitten texturieren, was heutzutage nicht mehr schön ist. Im Levelformat lassen sich aber beliebige Texturkoordinaten angeben, deshalb möchte ich die Daten aus dem Leveleditor in meinen Programm weiterverarbeiten.Um was für eine Art Verarbeitung geht es da?
Nein, weil keine Berechnungen in der Binärrepresentation der Spieldaten vorgenommen werden.Ist die Gefahr, dass, aufgrund der mangelnden arithmetischen Genauigkeit, Artefakte durch Rundungsfehler entstehen, nicht viel realer?
Dafür ist das Beispiel oben nicht so optimal.Dann mach das einfach, wo liegt das Problem?
Code: Alles auswählen
struct RoomFlags
{
bool Water : 1;
std::uint8_t Unknown000 : 2;
bool SkyVisible : 1;
bool Unknown001 : 1;
bool BlowHair : 1;
bool Unknown002 : 1;
bool Quicksand : 1; //NL-Flag, Unknown effect
bool Mist : 1; //Unknown effect
bool WaterReflectivity : 1; //R-Flag
bool Unknown003 : 1;
bool FlagD : 1; //No effect
bool FlagP : 1; //No effect
std::uint8_t Unknown003 : 3;
} ;
Also mal abgesehen davon, dass du Recht hast mit deinem Rat, ist unter Windows / MSVC eigentlich die Grenze 16 Bit (geprüft: von VS2008 bis VS2013 ist das immer noch so: http://msdn.microsoft.com/de-de/library ... 20%29.aspx). Das heißt die 16 Bits sollten auch vom Compiler in 16 Bits verpackt werden. Daher ist das Verhalten durchaus verwunderlich. Jedenfalls beim genannten Beispiel.dot hat geschrieben:Gehen wir das mal aus Sicht des Compilers durch:Die Lösung wäre, std::uin16_t zu verwenden.
- R: 5 Bit Bitfeld vom Typ uint8_t => R kommt in die ersten 5 Bits
- G: 5 Bit Bitfeld vom Typ uint8_t => die übrigen 3 Bit von R bieten keinen Platz für G => G kommt in die ersten 5 Bits von einem neuen uint8_t
- B: 5 Bit Bitfeld vom Typ uint8_t => die übrigen 3 Bit von G bieten keinen Platz für B => B kommt in die ersten 5 Bits von einem neuen uint8_t
- A: 1 Bit Bitfeld vom Typ uint8_t => die übrigen 3 Bit von B bieten Platz für A => A kommt in Bit Nummer 6 des dritten uint8_t
Gut gemeinter Rat: Der Code ist so nicht portabel, denn das genaue Layout von Bitfeldern ist zu einem großen Teil davon abhängig, wie der Compiler gerade aufgelegt ist. Auch wenn es in der Regel funktionieren wird, gibt es keinerlei Garantie. Vergiss Bitfelder, lies das Zeug in einen std::uint16_t und schreib dir eine Funktion, die die Werte per Bitgefummel selbst ver- bzw. entpackt oder gleich eine Klasse für R5G5B5A1 Farben oder sowas...
Was genau meinst du damit? Wenn sein Bitfeld vom Typ std::uint8_t ist, dann ist die Grenze 8 Bit. Hätte er stattdessen std::uint16_t verwendet, würde es, wie gesagt, funktionieren...BeRsErKeR hat geschrieben:Also mal abgesehen davon, dass du Recht hast mit deinem Rat, ist unter Windows / MSVC eigentlich die Grenze 16 Bit (geprüft: von VS2008 bis VS2013 ist das immer noch so: http://msdn.microsoft.com/de-de/library ... 20%29.aspx). Das heißt die 16 Bits sollten auch vom Compiler in 16 Bits verpackt werden. Daher ist das Verhalten durchaus verwunderlich. Jedenfalls beim genannten Beispiel.
Achso ok da war ich wohl blind. Bin davon ausgegangen, dass er 16Bit-Werte verwendet hat. Naja dann ist es natürlich kein Wunder. ;) Ich hatte vermutet, dass der Compiler trotz größerem Datentyp da auf 8 Bit runterregelt. Daher auch die Verwirrung meinerseits.dot hat geschrieben:Was genau meinst du damit? Wenn sein Bitfeld vom Typ std::uint8_t ist, dann ist die Grenze 8 Bit. Hätte er stattdessen std::uint16_t verwendet, würde es, wie gesagt, funktionieren...BeRsErKeR hat geschrieben:Also mal abgesehen davon, dass du Recht hast mit deinem Rat, ist unter Windows / MSVC eigentlich die Grenze 16 Bit (geprüft: von VS2008 bis VS2013 ist das immer noch so: http://msdn.microsoft.com/de-de/library ... 20%29.aspx). Das heißt die 16 Bits sollten auch vom Compiler in 16 Bits verpackt werden. Daher ist das Verhalten durchaus verwunderlich. Jedenfalls beim genannten Beispiel.
Das wäre natürlich in der Tat verwunderlich... ;)BeRsErKeR hat geschrieben:Ich hatte vermutet, dass der Compiler trotz größerem Datentyp da auf 8 Bit runterregelt. Daher auch die Verwirrung meinerseits.
