ZFX + Developia

• 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

schreib dir eine Funktion, die die Werte per Bitgefummel selbst ver- bzw. entpackt

wird es nervig

Spiele Programmierer hat geschrieben:In C++ gibt es halt keine Properties

Spiele Programmierer hat geschrieben:Gibt es wirklich keine andere Möglichkeit?

Spiele Programmierer hat geschrieben:Wofür gibt es dann in C(++) überhaupt Bitfelder?

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.

Ja, gottseidank is C++ von Properties verschont geblieben... ;)

Die Frage ist, ob du die Daten programmintern auch wirklich so speichern willst und wenn ja: warum?

Spiele Programmierer hat geschrieben:

Die Frage ist, ob du die Daten programmintern auch wirklich so speichern willst und wenn ja: warum?

Weil das Einlesen dann einfach und schnell ist.
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.

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".

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?

Dann mach das einfach, wo liegt das Problem?

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;
} ;

dot hat geschrieben:Gehen wir das mal aus Sicht des Compilers durch:

• 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

Die Lösung wäre, std::uin16_t zu verwenden.

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...

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.

dot hat geschrieben:

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.

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:Ich hatte vermutet, dass der Compiler trotz größerem Datentyp da auf 8 Bit runterregelt. Daher auch die Verwirrung meinerseits.