Danke, es hat sich erledigt.
Das war ein Denkfehler von mir. Der entstanden ist, weil das falsch in den Dokus steht, die man so findet. Ich weiß ja nicht, wer die geschrieben hat. Die sind echt voller Fehler und locken einen auf einen falschen Weg.
Ich habe aber noch ein anderes Problem.
In der BMHD müssen damit ein Amiga das versteht Werte gedreht werden (Code ist angehängt).
Das geht auch ohne Problem. Nur bei der Speicherung werden diese Werte wieder zurückgedreht. Lasse ich die Drehung im Code weg, sind die Werte für einen Amiga richtig gespeichert. Das ist aber nicht wünschenswert, weil sichergestellt werden muss das die Werte auch korrekt gespeichert werden. Es könnte sonst sein das Werte gedreht werden, die nicht gedreht werden sollen.
Wie kann ich verhindern das sich beim Speicher die Werte gedreht werden?
Bei der Debuggen Ausgabe werden mir die Werte mir die Werte richtig angezeigt.
Ich fange mal einen neuen Beitrag an. Ich denke, das ist besser.
Ich mache gerade ein Programm das IFF ILBM 24 und 32 Bit Grafiken erstellen kann (Amiga Format). Das Projekt ist auch schon weit gekommen. Nur jetzt wo es um das Erzeugen von IFF ILBM Dateien geht, bin ich auf was gestoßen was ich mir nicht erklären kann. Dazu habe ich eine Bild angehängt von einen Hex Editor.
Der BMHD-Block in einer IFF ILBM Datei ist so aufgebaut.
Blocktyp: 4 Byte BMHD
Unbenutzt: 3 Byte
Bildbreite: 2 Byte
Bildhöhe: 2 Byte
x Versatz: 2 Byte
y Versatzt: 2 Byte
Bitplanes: 1 Byte
Und so weiter. Der Rest spielt hier mal keine Rolle. (Byte umkehr bei allen daten die in 2 Byte gespeichert werden.
Das heißt zwischen Bildhöhe und Bitplanes sollte 4 Byte liegen. Wie man im Hex Editor sieht, sind es 5 Byte (Datei wurde von einen original Amiga erzeugt). Speicherstelle 0x1C enthält, denn wert 0x018, was Dezimal 24 entspricht. Also, der Farbtief der Grafik. Laut des Aufbaus einer BMHD müsste der Wert 0x18 an der Speicherstelle 0x1B stehen, was er aber nicht tut.
Der Witz beim Auslesen der BMHD berücksichtigt mein Code nur 4Byte. Den noch wird sie richtig angezeigt. Das heißt da steht ein Byte mehr das nicht berücksichtigt wird. Warum auch immer.
Das Problem ist will ich eine IFF ILBM Grafik erzeugen müsste ich wissen, wie man das macht, das es dort ein Byte gibt das nicht berücksichtig wird.
Ist dieses eine "unsichtbare Byte nicht vorhanden wird die BMHD dann auch falsch ausgelesen.
Was auch komisch ist. Sieht man sich die Bildbreite an. Adresse 0x13 und 0x14 würde das Dezimal den Wert 1044 ergeben (Byte Umkehr bedenken). In meinen Code wird aber dann für Bildbreite 1024 angezeigt, was auch richtig ist. Bildhöhe, 0x15 und 0x16 stimmt allerdings so.
Ich habe mir das auch schon auf einen HEX Editor am Amiga anzeigen lassen. Sind die gleichen Werte.
Ich habe leider im Forum dazu nichts gefunden.
Ich schreibe gerade einen IFF Konverter. Bei dem sind eh nach Aktion die aufgeführt wird Button aktiv oder inaktiv. Das klappe sehr gut.
Mein Problem ist aber, es gibt auch einen Dark Mod. In dem Modus passen sich aber die inaktiven Button leider nicht an. Die bleiben auf ihre Grau. Das Problem ist halt das diese Grau für den Dark Mod zu hell ist.
Ich wäre schon glücklich wenn man die Hintergrundfarbe in eine neutralere Farbe bringen kann, die einigermaßen für bei Mod passt.
Nur habe ich dazu zu wenig Erfahrung wie man so was machen könnte, hat bitte wer für mich ein paar Tipps, oder Code Beispiel?
Sorry habe das mit der Auflösung ünersehen.
Erzeugt habe ich die Datei mit dem Picture Manager 5.5 am Amiga bei einer Auflösung von 1024 x 768 bei 24 Bit
Bei mir steht
X 44
Y 44.
Für was die gehören verstehe ich schon. Nur wie werden diese Werte beim erstellen der Grafik errechnet?
Was ich noch nicht verstehe ist wie der x und y Aspect errechnet wird.
Danke für dein Angebot, ich komme da sicher gerne mal zurück.
Das kann jetzt aber einige Zeit dauern.
Es gibt da noch einen Fehler im Code.
bitmapZaehlerBreite und bitmapZaehlerHoehe müssen auf 0 zurück gesetzt werden bevor die Daten eines neuen Body geladen werden.