Zitat:

---

Original von Holger:
Genauso wie bei WPA8. Du gibst den RastPort an, er benutzt dessen BitMap und wenn vorhanden Layer. Du kannst also auch in eine friend-BitMap schreiben, und diese dann auf den Bildschirm schreiben.

---

Zitat:

---

Original von thomas:

Für Read/WritePixelArray8 muß die Anzahl Bytes pro Zeile durch 16 teilbar sein. Wenn ArtPro nur genau die Breite des Bildes abspeichert, funktioniert es evtl. nicht.

---

Zitat:

---

Ich habe auch schon gesehen, daß bei Bitmaps, die mit Datatypes geladen wurden, die Bytes pro Zeile durch 128 teilbar waren, obwohl das Bild selbst wesentlich kleiner war. Also ich vertraue solchen Programmen nicht so sehr, ich mache es lieber selbst (siehe dt2xxx), dann weiß ich genau, was rein geht und was raus kommt.

---

Zitat:

---

Original von thomas:

Ich vermute, dein Problem liegt darin, daß ArtPro die Daten immer noch planar ausgibt. Ich kenne das Programm nicht. Du hast irgendwo geschrieben, daß du zwischen long, word und byte wählen kannst. Das heißt aber noch lange nicht, daß die Daten auch von planar nach chunky umgerechnet werden.

Du kannst dein Bild ja mal mit dt2chunky umwandeln und dann mit deinen Daten vergleichen.

---

Werd ich mal tun. Hab ArtPro in dieser Hinsicht vertraut bekomme auch genausoviele Bytes wie Pixel in dem Bild sind.

Hier meine Einstellungen im Chunky-Saver:
Output: Source
Type: Byte
Byte Type: Right
Language: C
Width: Byte
LineEntries: 8

Bild: http://WizardGrounds.powerserver24.de/examples/ArtPro.png

Also soweit so gut.
Kann ja gern auch mal das UByte-Array posten, aber das würde zuweit führen.

Hier ein Link auf das Array:
http://WizardGrounds.powerserver24.de/examples/See_neu.h



Und hier das Bild:
http://WizardGrounds.powerserver24.de/examples/See.pic


Und hier das Ergebnis :
http://WizardGrounds.powerserver24.de/examples/Kaputt.png

Zitat:

---

Wenn du die Bitmaps dann an das Bildschirmformat anpassen möchtest, kannst du es auch so machen:

struct BitMap eingebauteBitmap = {...}; /* siehe huhn.c */

struct BitMap *arbeitsBitmap = AllocBitMap(...,friendBitMap);
BltBitMap (eingebauteBitmap,...,arbeitsBitmap,...);


Und später dann nur noch:

BltMaskBitMapRastPort(arbeitsBitmap,width,height,fensterRP,...);

---

Zitat:

---

Original von bubblebobble:
Also:

RAW Daten haben keine Bytes per row Information
gespeichert, das ist doch logich. Sonst wären
sie ja nicht "RAW".

---

Zitat:

---

Du musst aber dafür sorgen, dass die Bitmap, in die
du sie hineinkopiert, gleiche Dimensionen hat.
Bei einem Chunky Byte pro Pixel ist BytesPerRow=Breite in Pixeln.

---

Zitat:

---

Und nochmal:
DU DARFST KEINE ANNAHMEN ÜBER DIE BITMAPSTRUKTUR MACHEN.

---

Zitat:

---

Deshalb mein Vorschlag: erstelle erstmal eine temporäre
Bitmap, die auf jedenfall 8 Bit Chunky ist. Dann blitte
sie auf die Friend-Bitmap. Der BltBitmap Befehl macht
das dann schon richtig. Wenn du eine "Friend" Bitmap
allocierst, dann hängt das Format von der verwendeten
Grafikkarte ab.

---

Zitat:

---

Den ganzen Kram nehmen dir die Datatypes ab. Dafür sind sie
gedacht. Also wenn die Daten nicht UNBEDINGT Raw sein müssen,
dann verwende ein ordentliches Dateiformat mit Datatypes.
So ist das auch von AmigaOS gedacht.
Dann ist es auch wurscht, ob der Screen 8bit, 16 oder 24 bit hat,
es wird überall laufen.

---

Zitat:

---

Original von whose:
Hallo Reth

Das mit dem zweistelligen Eingabefeld ist aber bissi seltsam... immerhin konnten selbst die seligen 1000er-Amigas Auflösungen von 640 Pixeln per Zeile darstellen

---

Zitat:

---

Deine Vermutung stimmt teilweise, sofern die Pixel tatsächlich fein säuberlich nacheinander als Bytes ohne Zusatzinformationen gespeichert wurden. Die Anzahl der Einträge pro Zeile des Arrays hat letztendlich keine Bedeutung, da ein C-Compiler für AmigaOS dieses freundlicherweise "am Stück" im Speicher ablegt. So lange "BytesPerRow * Bildzeilen = Arraygröße" gilt, paßts. Ich hab aber immer noch den Verdacht, das all dies nicht passiert, wenn Du den Source mittels ArtPro erzeugst.

---

Zitat:

---

Das ist korrekt, so lange das Format der Pixel mit dem übereinstimmt, was gemeinhin als "Chunky" bezeichnet wird. Also Bytes, deren Zahlenwert dem gewünschten Palette-Index entspricht, sonst nix. Und auch keine weiteren Informationen in dem UBYTE-Array untergebracht werden. Kann es sein, das ArtPro auch die Palette in dem Array ablegt?

---

Zitat:

---

Mach doch mal folgendes:

Erstelle ein Bild. In der ersten Zeile setzt Du jeweils ein Pixel mit Palette-Index 1, dann eins mit Index 0 und dann wieder eins mit Index 1 (die tatsächlichen Farben spielen keine Rolle). Die zweite Zeile
bemalst Du mit drei Pixeln mit dem Palette-Index 255.

Ist ein winziges Bild, aber das ist dafür einfacher zu durchschauen

Das Bild behandelst Du dann mit ArtPro, so wie Du Deine anderen Grafiken auch umgewandelt hast und das Ergebnis schickst Du mir dann mal per Mail. Dann schaue ich mir das mal an und werde dann sehen, ob die Pixel so in dem Array abgelegt werden, wie sie sollten (BytesPerRow = 3, Chunky).

Sollte bei der Aktion ein UBYTE-Array mit mehr oder weniger als 6 Einträgen herauskommen dann ist etwas faul

---

Zitat:

---

Original von Holger:
Was WritePixelArray8 ursprünglich macht: Deine chunky-Daten nach planar konvertieren, mit den planaren Daten der Ziel-BitMap verknüpfen, gemäß der im RastPort eingestellten Modi.
Was es demzufolge auf Grafikkarten macht: Deine chunky-Daten nach planar konvertieren, die Chunky-Daten der Ziel-BitMap nach planar konvertieren, die planaren Daten logisch verknüpfen und danach wieder nach chunky konvertieren.
Abgesehen davon, daß dieses hin- und kerkonvertieren für das, was Du willst, absolut unnötig ist, folgt daraus, daß das (vermutlich) nur funktionieren kann, wenn die temporäre BitMap planar ist.

---

Zitat:

---

Benutze WriteChunkyPixels und Du hast diese Probleme erst gar nicht. Keine logische Verknüpfung, keine temporäre BitMap/RastPorts, keine Probleme damit.

---

Zitat:

---

Original von whose:

Ich hätte da noch ne Idee:

Kann ArtPro die Bitmaps auch als Binärdatei (RAW) im Chunky-Format speichern? Dann könntest Du diese Datei mit nem passenden Konverter wieder zu Source machen und die BytesPerRow stimmen dann automatisch. Wenn die Grafik dann immer noch zerhackt ist, liegts an ArtPro.

---

Zitat:

---

Original von Reth:
Nun ja, ArtPro schreibt die Daten in UBYTE-Felder und für das Einlesen von Bildern in BitMaps hab ich kein Codebeispiel gefunden und die Sache mit planaren BitMaps und UBYTE-Feldern schien prima zu funktionieren!

---

Zitat:

---

Original von GolfSyncro:

Hi hast du von dem device name auch das 040 entfernt? es darf nacher nur noch x-surf.device heisen..
Nur so als tipp

---

Zitat:

---

Original von whose:
Ich denke mal, der simpelste Weg ist, die Daten als RAW zu speichern,
PPaint hat (glaube ich) einen passenden Operator, der die Daten auch
gleich im Chunky-Format schreibt.

Ansonsten mal die Konverter-Tools im Aminet ansehen, da war glaube
ich auch was von wegen IFF2Chunky oder so drin.

---

Zitat:

---

Wenn alles nichts hilft, lade die Bilddaten mittels Datatype und
schreibe die selbst wieder im Chunky-Format als Sourcecode auf Platte.
Ist zwar aufwändig, aber wenns nu gar nicht anders geht...

Ersatzweise könnte man auch die Bilddaten per Datatype direkt in eine
Bitmap schreiben lassen. Im Moment habe ich aber noch nicht so die
Ahnung, ob das auch mit Offscreen-Bitmaps geht. Technisch sollte das
machbar sein. Bei mir klappts zumindest, wenn ich direkt in einen
Screen rendern lasse, dank Thomas Hilfe sogar mit den korrekten Farben
Wenn Du willst, kann ich Dir den Code mal zukommen lassen.

---

Klaro! Immer her damit, bin für jedes Beispiel dankbar!

Auch noch mal Dank an alle andern hier, die mit geholfen haben und mit Beispielen viel zum Fortschritt beigetragen haben, z.T. auch aus anderen Threads (danke Thomas )

Ciao

Zitat:

---

Original von whose:

Also, wie ich Dir schon per Mail schrieb, kannst Du den RastPort als eine Art "Seitenbeschreibung" verstehen. Darin findest Du Information über z.B. Größe der Bitmap, wo diese sich befindet, Layer, Stiftfarben etc. pp.

Die Bitmap als solche ist nicht im RastPort enthalten sondern nur ein Zeiger darauf. Genau das passiert in obigem Beispiel. Die Layer-Information im temrp-Rastport wird auf Null gesetzt und per AllocBitMap() ein Zeiger auf eine allozierte und initialisierte Bitmap in temprp eingetragen. Nicht mehr und nicht weniger.

...

Streng genommen könntest Du jetzt per WritePixel() und ähnlichen Funktionen, die einen RastPort als Parameter erwarten, in temprp hineinmalen. Das macht allerdings nicht viel Sinn bei einer einen Pixel hohen Bitmap

Normalerweise benutzt man dieses Konstrukt für die temporäre Bitmap, mit der WritePixelArray8() bei der Chunky-zu-Planar-Konversion arbeitet. Die temporäre Bitmap braucht nämlich nur ein Pixel hoch zu sein und benötigt natürlich auch keinen Layer, es wird ja nichts wirklich dargestellt

---

Zitat:

---

Original von thomas:

WritePixelArray8 braucht zwei RastPorts. Einen, auf dem gearbeitet wird und einen für temporäre Daten.

InitRastPort(&rp);
rp.BitMap = bitmap;

etabliert den ersten RastPort und

temprp = rp;
rp.Layer = NULL;
rp.BitMap = AllocBitMap(width,1,depth,0,NULL);

ist wortwörtlich aus den Autodocs für Read/WritePixelArray8 abgeschrieben.

Daß es in diesem Fall, wo der erste Rastport nur rudimentär initialisiert wurde, nicht unbedingt notwendig ist, Layer zu löschen, tut der Funktion keinen Abbruch.

---

Zitat:

---

temprp = rp;
rp.Layer = NULL;
rp.BitMap = AllocBitMap(width,1,depth,0,NULL);

---

Zitat:

---

Original von Holger:

(Mußte korrigieren) Dein Code ist sehr schwer lesbar, wieso initialisiert Du einen RastPort, kopierst ihn danach, um dann in der Kopie die Initialisierung wieder zu überschreiben? Bin selbst nach dem dritten Lesen nicht ganz sichern, ob ich jetzt weiß, was passiert.
tmp-rastport soll auf einen RastPort zum Zwischenspeichern einer Zeile zeigen, Du brauchst keine BitMap mit der kompletten Höhe anzulegen. Aber die ganze Operation dient zum Konvertieren chunky zu planaren Daten, Du legst aber eine friend-BitMap an, die vermutlich nicht planar ist. Und hast planare Daten, also komplett umgekehrt.

Wieso sind Deine Grafikdaten dann in UBYTE-Felder? Schreibt PPaint oder ArtPro bevorzugt UBYTE-Felder weg?
Wieso liest Du nicht einfach Bilder ein?

---

Zitat:

---

Original von whose:

WritePixelArray8() ist denke ich nicht die richtige Funktion, wenn Deine Ausgangsdaten in einem Planar-Format vorliegen und nicht Chunky. Du weißt ja, ich hab bisher nur mit WPA8() gearbeitet, daher weiß ich nicht genau, welche Funktion da besser geeignet wäre, aber ich tippe mal auf WritePixel() und Ähnliche. Vielleicht kann Dir einer der anderen hier mitschreibenden mehr dazu sagen. Ich hab mich gerade an der SDl festgebissen, da bleibt wenig Zeit für anderes

Grüße

---