Privilegverletzung bei FreeBitMap()

amiga-news.de Forum > Programmierung > Privilegverletzung bei FreeBitMap()

[ - Suche - Neue Beiträge - Registrieren - Login - ]

1 -2- 3

[ - Beitrag schreiben - ]

08.11.2004, 21:44 Uhr

bubblebobble
Posts: 707
Nutzer

Ich glaube, du wirfst da eine ganze Menge durcheinander.

Wie werden denn die Bilder "falsch" angezeigt ?
Wenn du mit 8 Bit auskommst, dann sind die Bilder
vermutlich Farben Indiziert. Dann muss die Palette
stimmen oder die Bilder müsssen geremapped werden.
Wenn die Farben falsch sind, dann wirds wohl daran liegen.

Evtl. stimmt auch die Maske nicht.

Beschreibe doch mal was du da eigentlich machst, ich
denke mal es gibt eine viel einfachere und systemfreundlichere
Lösung dafür. Vermutlich ist es ganz einfach, und jeder hier
hat Codebeispiele dafür. Ich glaube du brichst dir unnötig
einen ab mit den UByte Feldern.

--
Thilo Köhler, Author von:
HD-Rec, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, UDM, TKPlayer, TKUnpacker
Homepage: http://www.hd-rec.de

[ - Antworten - Zitieren - Direktlink - ]

08.11.2004, 21:59 Uhr

Reth
Posts: 1858
Nutzer

@bubblebobble

Mach eigentlich nix besonderes.

Ich hab Bilder mit PPaint gemalt, mit ArtPro die benötigten Teile herausgeschnitten und abgespeichert.
Das lief alles auch schon ganz gut, solange ich planare BitMaps verwendet habe und die PlanePointer von Hand zuwies (in ArtPro hab ich die Daten entsprechend gespeichert und die UBYTE-Felder bekommen).
Dann hab ich angefangen die BitMaps mittels AllocBitMap() zu allokieren, anstatt

struct BitMap bitMap;

weiterzuverwenden.

Mit AllocBitMap hab ich anfangs die Planepointer auch von Hand zugewiesen. Dann gingen zwar die Grafiken noch, aber es gab dann Probleme beim Freigeben der BitMaps, die Privilegverletzung!

Dann bin ich dazu übergegangen, die DAten mittels TempRastPort und TempBitMap wie aus einem Beispiel von Thomas in die BitMaps zu schreiben. Das gab dann keine Fehler mehr bei FreeBitMap() dafür waren die Grafiken zerschossen.

Also probierte ich in ArtPro die Grafikdaten in anderen Formaten zu speichern. Erst als Interleaved BitMaps, dann im Chunkyformat.

Nix half. Um die Maske als Fehlerquelle auszuschließen hab ich die Grafiken zum Test ohne Maske geblittet.

Die Farben stimmen zwar, aber die Darstellung nicht!

Die Farben lade ich mit LoadRGB4(). Die Palette habe ich mir von PPaint geben lassen.

Ich benutze ausschließlich 8Bit Tiefe Screens und Grafiken.

Das wars im großen und ganzen.

[ - Antworten - Zitieren - Direktlink - ]

08.11.2004, 22:30 Uhr

bubblebobble
Posts: 707
Nutzer

Dann schicke mir doch mal einen Screenshot, wie die
Grafiken aussehen.
Das Problem ist, Teife 8 kann verschiedene Pixelformate haben.
Wenn du eine Bitmap Initialisiertst, kannst du da das Pixelformat
angeben ? Wenn ja, dann Allociere doch einfach eine Bitmap
im selben Format wie deine Bilder und lade sie direkt drauf,
oder mittels copymem_. Wichtig ist auch, dass
die BytePerRow identisch sind, sonst verschiebt sich alles.
Wenn die Daten dann in der Bitmap sind,
könntest du sie bereits blitten. Wenn du aber maximale Performance
haben willst, dann allociere eine zweite Bitmap als Friend Bitmap
zum Screen, und Blitte deine Bitmap erstmal in die Friend Bitmap.
Ab dann verwendest du die Friend Bitmap zum blitten für maximale
Speed.
Evtl. gibts auch eine bessere Methode, die Bitmap fürs
Blitten auf den Screen zu optimieren, weiss ich nicht. Ich glaube
das AmigaOS erlaubt sich, Bitmaps durch die gegend zu swappen und
auch das Format zu ändern, ohne dass du das mitkriegst. Deshalb
musst du auch eine Bitmap locken wenn du direkt drauf zugreifen willst.
Korrigert mich wenn ich da falsch liege.

Es wäre besser, wenn du die Bilder mit Datatypes direkt laden lässt.
Dann bekommst du direkt eine schöne Bitmap mit der du
sofort los blitten kannst. Dann benötigst du aber ein IFF-ILBM,
oder GIF oder sonstwas, keine RAW Data Bilder.
Beispiel Source dazu gibt in einem älteren Thread hier, der
von mir angefangen wurde.
Ich dachte zuerst Datatypes ist kompliziert, aber es ist
kinderleicht. Nur ein paar Zeilen Code, und schwupp hast
du deine Bitmap.

--
Thilo Köhler, Author von:
HD-Rec, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, UDM, TKPlayer, TKUnpacker
Homepage: http://www.hd-rec.de

[ - Antworten - Zitieren - Direktlink - ]

09.11.2004, 00:26 Uhr

whose
Posts: 2156
Nutzer

Irgendwie ist heut nicht mein Tag, falschen Beitrag gelesen und drauf geantwortet

Grüße

[ Dieser Beitrag wurde von whose am 09.11.2004 editiert. ]

[ - Antworten - Zitieren - Direktlink - ]

09.11.2004, 07:40 Uhr

Reth
Posts: 1858
Nutzer

@bubblebobble

Also an den BytesPerRow könnts evtl. liegen.
Hab Bilder in der Größe 100x80 und die Chunkydaten aber nicht mit 80 BytesPerRow gespeichert (ist mir gestern noch eingefallen).

Werde das mal proberen. Leider speichert ArtPro nur bis 99 BytesPerRow, so dass ich das manuell nachtragen muss.

Ansonsten werd ich wohl doch noch auf Datatypes zurückgreifen müssen, was ich eigentlich nicht wollte.

Die BitMaps, die ich für meine Bilder allokiere bekommen als FriendBitMap schon die BitMap des Fensters mit, in dem sie später erscheinen sollen!

Vielleicht komm ich heut abend dazu Dir nen Screenshot zu schicken.

Ciao

[ - Antworten - Zitieren - Direktlink - ]

09.11.2004, 08:29 Uhr

whose
Posts: 2156
Nutzer

Zitat:
Original von Reth:
@bubblebobble

Also an den BytesPerRow könnts evtl. liegen.
Hab Bilder in der Größe 100x80 und die Chunkydaten aber nicht mit 80 BytesPerRow gespeichert (ist mir gestern noch eingefallen).

Werde das mal proberen. Leider speichert ArtPro nur bis 99 BytesPerRow, so dass ich das manuell nachtragen muss.

Ansonsten werd ich wohl doch noch auf Datatypes zurückgreifen müssen, was ich eigentlich nicht wollte.

Die BitMaps, die ich für meine Bilder allokiere bekommen als FriendBitMap schon die BitMap des Fensters mit, in dem sie später erscheinen sollen!

Vielleicht komm ich heut abend dazu Dir nen Screenshot zu schicken.

Ciao

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.

Grüße

[ - Antworten - Zitieren - Direktlink - ]

09.11.2004, 09:21 Uhr

Reth
Posts: 1858
Nutzer

Hallo whose

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.

Das kann es allerdins. Es hat nen Saver im Raw-Format.
Ich find das Programm eh klasse! Du kannst bei den Savern und Loadern alles konfigurieren.
Du gibst die Sprache an, für die gespeichert werden soll, das Format, die BytesPerRow (da allerdings nur ein 2stelliges Eingabefeld) usw.

Stimmt es dann, was ich vermute:
Wenn ich die Grafik im Chunkyformat habe brauche ich bei 8Bit Tiefe soviel Bytes in einer Reihe des Feldes, wie ich Pixel in einer Zeile der Grafik habe?
(Ist allerdings komisch, da es ein normales UBYTE-Array ist, in dem alle Einträge mit Komma getrennt sind. Dann ist es doch egal, wieviel Bytes in einer Zeile dieses Arrays stehen oder? WritePixelArray8() nimmt sich doch für jede Zeile soviel wie es braucht, oder nicht?

Ciao

[ - Antworten - Zitieren - Direktlink - ]

09.11.2004, 09:55 Uhr

whose
Posts: 2156
Nutzer

Hallo Reth

Zitat:
Original von Reth:

Das kann es allerdins. Es hat nen Saver im Raw-Format.
Ich find das Programm eh klasse! Du kannst bei den Savern und Loadern alles konfigurieren.
Du gibst die Sprache an, für die gespeichert werden soll, das Format, die BytesPerRow (da allerdings nur ein 2stelliges Eingabefeld) usw.

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:
Stimmt es dann, was ich vermute:
Wenn ich die Grafik im Chunkyformat habe brauche ich bei 8Bit Tiefe soviel Bytes in einer Reihe des Feldes, wie ich Pixel in einer Zeile der Grafik habe?

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:
(Ist allerdings komisch, da es ein normales UBYTE-Array ist, in dem alle Einträge mit Komma getrennt sind. Dann ist es doch egal, wieviel Bytes in einer Zeile dieses Arrays stehen oder? WritePixelArray8() nimmt sich doch für jede Zeile soviel wie es braucht, oder nicht?

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?

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

Grüße

[ Dieser Beitrag wurde von whose am 09.11.2004 editiert. ]

[ - Antworten - Zitieren - Direktlink - ]

09.11.2004, 11:43 Uhr

Holger
Posts: 8116
Nutzer

Zitat:
Original von Reth:
Habe mir die Daten von ArtPro nun im Chunkyformat (UBYTES) speichern lassen und mittels WritePixelArray8() in die BitMap geschriebe.
Lediglich die Maske ist noch im planaran Format gespeichert was aber nichts machen sollte, da es eh nur eine BitPlane ist!
...
Schreibt WritePixelArray8() die Daten immer richtig in die BitMap, egal ob diese im Chunky oder Planar Format vorliegt?

Oder muss ich den temporären RastPort noch irgendwie anders initialisieren?

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.
Benutze WriteChunkyPixels und Du hast diese Probleme erst gar nicht. Keine logische Verknüpfung, keine temporäre BitMap/RastPorts, keine Probleme damit.

mfg
--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]

09.11.2004, 12:10 Uhr

Reth
Posts: 1858
Nutzer

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.

Das ist ne Menge Holz.

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

Also am besten 2 Routinen, eine für AGA und eine für Graka machen? Denn ich denke WriteChunkyPixels erzeugt unter AGA wieder mehr Overhead. Muss mir die Funktion nochmal anschauen. Aber mit WriteChunkyPixels() schreib ich dann die Daten in meine BitMap, nicht in den RastPort des Zielfensters, meinst Du hoffentlich - oder?

Ciao

[ - Antworten - Zitieren - Direktlink - ]

09.11.2004, 13:08 Uhr

Reth
Posts: 1858
Nutzer

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

Vielleicht nur an planare BitMaps gedacht?

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.

Die Anzahl der Byptes stimmt zumindest mit der Annzahl der Bildpixel überein.

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?

Das weiss ich nicht. Von der Anzahl der Bytes her kanns jedenfalls nicht sein.

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

Danke für das Angebot, kann ich gern mal tun! Hoffe, ich komme heut noch dazu!

Ciao

[ - Antworten - Zitieren - Direktlink - ]

09.11.2004, 15:05 Uhr

bubblebobble
Posts: 707
Nutzer

Also:

RAW Daten haben keine Bytes per row Information
gespeichert, das ist doch logich. Sonst wären
sie ja nicht "RAW".
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.

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

Wenn du das machst, dann funktioniert das nicht mehr überall.
Du musst dir vorstellen, dass deine Bitmap jederzeit
völlig von AmigaOS umgekrempelt wird. Deine Bitmap ist
eigentlich tabu für direkte zugriffe.

Einzige Möglichkeit ist
- Bitmap Locken
- Pixelformat ermitteln
- Wenn dir dieses Pixelformat bekannt ist, eine
Funtkioon darauf ausführen
- Bitmap unlocken

Eigentlich müsstest du eine Routine für jedes Pixelformat
zum draufkopieren schreiben. Es gibt aber viele Pixelformate...

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.

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.

--
Thilo Köhler, Author von:
HD-Rec, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, UDM, TKPlayer, TKUnpacker
Homepage: http://www.hd-rec.de

[ - Antworten - Zitieren - Direktlink - ]

09.11.2004, 19:24 Uhr

thomas
Posts: 7718
Nutzer

Ich habe mal ein paar Beispiele gemacht, vielleicht wird es dann etwas deutlicher:

dt2raw.c Liest eine Bilddatei mittels Datatypes und erzeugt daraus eine (planare) Bitmap als C-Quelltext
huhn2.iff Das Bild, das ich zum Testen benutzt habe
huhn.c Die Bitmap, die daraus erzeugt wurde
bitmap.c Ein kleines Programm, das die Bitmap anzeigt

dt2chunky.c Liest eine Bilddatei mittels Datatypes und erzeugt daraus einen Pixel-Array für WritePixelArray8.
huhn1.iff Das Bild, das ich zum Testen benutzt habe
array.c Der Array, der daraus erzeugt wurde
pixelarray.c Ein kleines Programm, das den Array anzeigt

dmakefile Die Zusammenhänge als Makefile für Dice C.

Gruß Thomas

--
Email: thomas-rapp@web.de
Home: home.t-online.de/home/thomas-rapp/

[ - Antworten - Zitieren - Direktlink - ]

09.11.2004, 20:21 Uhr

Reth
Posts: 1858
Nutzer

@bubblebobble

Danke für die Antwort.

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

GEnau das war auch meine Überlegung.

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.

Ich hab genau so viele Byte wie Pixel in meiner 8Bit Grafik und die Dimensionen der BitMap Stimmen auch.

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

Genau aus dem Grund hab ich meine Code ja geändert und hab nun das zuletzt beschriebene Problem!
Kann denn WritePixelArray8() nicht für alle Arten von BitMaps verwendet werden? In der Dokumentation dieser Funktion hab ich nix dazu gesehen.

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.

Wie geb ich denn beim Erstellen der BitMap deren Format an?
Mit AllocBitMap() oder InitBitMap geht das jedenfalls nicht.

Ich erstell ja ne leere BitMap und schreibe die Grafikdaten mit WritePixelArray8() hinein. Ich dachte, das ist ne saubere und sichere Sache. Ist sie nun doch nicht?

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.

Datatypes wären für mich nur das letzte Mittel. Muss doch auch so irgendwie gehen. Mit planaren BitMaps und struct BitMap Variablen (keine Zeiger!) gings immer und überall problemlos, egal ob AGA oder CGX.

Ciao

[/quote]

[ - Antworten - Zitieren - Direktlink - ]

09.11.2004, 20:27 Uhr

Reth
Posts: 1858
Nutzer

@Thomas

Herzlichen DAnk für die Beispiele.

Stimmt den mein Code zum lesen eines UBYTE-Arrays in eine BitMap, den ich hier gepostet hab (auch aus einem Deiner Beispiele)?

Wenn ja, kann ich das schon mal als Fehlerquelle ausschliessen.

[ - Antworten - Zitieren - Direktlink - ]

09.11.2004, 20:52 Uhr

thomas
Posts: 7718
Nutzer

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.

Und ich muß nochmal darauf hinweisen, daß du dir ernsthaft überlegen solltest, welcher Weg für dich am sinnvollsten ist. Wenn du die Daten im Programm einbauen möchtest, ist die planare Version vielleicht einfacher, da du das ja schonmal am Laufen hattest.

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,...);

Gruß Thomas

--
Email: thomas-rapp@web.de
Home: home.t-online.de/home/thomas-rapp/

[ - Antworten - Zitieren - Direktlink - ]

09.11.2004, 21:07 Uhr

Reth
Posts: 1858
Nutzer

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,...);

Auch nicht schlecht die Idee. Zwar ein kleiner Umweg, aber machbar.
Danke!

[ Dieser Beitrag wurde von Reth am 09.11.2004 editiert. ]

[ - Antworten - Zitieren - Direktlink - ]

10.11.2004, 00:50 Uhr

whose
Posts: 2156
Nutzer

Ich hab mir das zerschmetterte Bild grade mal angesehen. 2 Möglichkeiten:

1. Es ist planar gespeichert worden. Scheint aber nicht wirklich so zu sein,
da die Farben wie es aussieht korrekt angezeigt werden.

2. Möglichkeit: Das UBYTE-Array ist aus irgendeinem Grund im Speicher
um etliche Pixel verschoben angelegt. Dafür spricht der graue
"Zwischenraum" zwischen den farbigen Pixeln.

Wenn ich morgen etwas Zeit finde, schaue ich mir das genauer an, dann kann
ich Dir vielleicht sogar sagen, um wie viele Pixel das Array verschoben ist.

Mühsam ernährt sich das Eichhörnchen

Grüße

[ - Antworten - Zitieren - Direktlink - ]

10.11.2004, 08:12 Uhr

thomas
Posts: 7718
Nutzer

Zitat:
Das UBYTE-Array ist aus irgendeinem Grund im Speicher
um etliche Pixel verschoben angelegt.

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.

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.

Gruß Thomas

--
Email: thomas-rapp@web.de
Home: home.t-online.de/home/thomas-rapp/

[ - Antworten - Zitieren - Direktlink - ]

10.11.2004, 09:36 Uhr

whose
Posts: 2156
Nutzer

Zitat:
Original von thomas:

Zitat:
Das UBYTE-Array ist aus irgendeinem Grund im Speicher
um etliche Pixel verschoben angelegt.

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.

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.

Verdammt! Daran hatte ich gar nicht mehr gedacht! *mitdemKopfvordieWandhau*

Das ist wohl des Rätsels Lösung. Reth, erweitere das UBYTE-Array doch mal von Hand derart, daß Du pro Zeile auf eine durch 16 teilbare Pixelzahl kommst (112 Pixel bspw.) und teste es dann noch mal. Mit ein bißchen Glück brauchst dann nicht mehr nach dem Fehler zu suchen!

Grüße

[ - Antworten - Zitieren - Direktlink - ]

10.11.2004, 11:37 Uhr

Reth
Posts: 1858
Nutzer

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.

Danke! Das wird des Rätsels LÖsung sein!

Wie füllte man denn UBTYE-Arrays von Bildern auf, deren Breite nicht durch 16 teilbar ist? Mit 0-Bytes? Links dran in der Zeile, oder rechts?

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.

Den Code schau ich mir auch nochmal an!

Danke!

[ - Antworten - Zitieren - Direktlink - ]

10.11.2004, 12:18 Uhr

whose
Posts: 2156
Nutzer

Auffüllen von der niedrigeren zur höheren Adresse, bei C also rechts
anhängen. Nullbytes sollten problemlos tun

Allerdings könnte es sein, daß Du Schwierigkeiten mit der Bitmap
bekommst, in die Du hineinschreibst. Auf Anhieb kann ich jetzt nicht
sagen, ob WPA8() die komplette Zeile überträgt oder die Grenzen der
Zielbitmap berücksichtigt. Letzteres könnte möglicherweise zu Gunsten
der Geschwindigkeit ignoriert werden, dann müßtest Du u.U. noch eine
Clipping Region für Deine Bitmaps einrichten, damit WPA8() nicht ins
Blaue schießt.

Dazu müßten bubblebobble oder thomas eigentlich mehr aus dem Stegreif
sagen können. Ansonsten kann ich Dir heute Abend mehr dazu sagen, ich
muß mich langsam startklar für die Maloche mache, da langt die Zeit
nicht mehr für Recherche.

Wenn alles nichts hilft, müßtest Du ggf. auch Deine Bilder ein klein
wenig umarbeiten, damit Du auf 112 bzw 96 Pixel kommst. Dann brauchst
Du auch nix auffüllen.

Grüße

[ - Antworten - Zitieren - Direktlink - ]

10.11.2004, 12:42 Uhr

Holger
Posts: 8116
Nutzer

Zitat:
Original von Reth:
Also am besten 2 Routinen, eine für AGA und eine für Graka machen? Denn ich denke WriteChunkyPixels erzeugt unter AGA wieder mehr Overhead.

Nein, ob Du WritePixelArray8 oder WriteChunkyPixel benutzt, ist in dem Fall egal. Beide erwarten chunky Pixel und müssen sie im Falle von planarer ZielBitMap konvertieren. Letztere Funktion unterstützt aber keine Verknüpfung, sondern nur reines Kopieren. Dafür kann beim CD³² spezielle Hardware zum Konvertieren genutzt werden.
Der einzige Haken: benötigt mindestens OS3.1.

Zitat:
Muss mir die Funktion nochmal anschauen. Aber mit WriteChunkyPixels() schreib ich dann die Daten in meine BitMap, nicht in den RastPort des Zielfensters, meinst Du hoffentlich - oder?

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.

mfg
--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]

10.11.2004, 12:42 Uhr

Reth
Posts: 1858
Nutzer

@whose

Danke für Deine Tips und Hilfen.
Hoffentlich kann ichs heut noch ausprobieren.

Wenn alles nix hilft, bleibt ja noch der(Um-)Weg

, den Thomas gestern aufgezeigt hat, laden mit Datatypes oder WriteChunkyPixel.

Ciao

[ - Antworten - Zitieren - Direktlink - ]

10.11.2004, 12:44 Uhr

Reth
Posts: 1858
Nutzer

@Holger

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.

Danke!

[ - Antworten - Zitieren - Direktlink - ]

10.11.2004, 13:27 Uhr

thomas
Posts: 7718
Nutzer

Zitat:
Allerdings könnte es sein, daß Du Schwierigkeiten mit der Bitmap
bekommst, in die Du hineinschreibst. Auf Anhieb kann ich jetzt nicht
sagen, ob WPA8() die komplette Zeile überträgt oder die Grenzen der
Zielbitmap berücksichtigt. Letzteres könnte möglicherweise zu Gunsten
der Geschwindigkeit ignoriert werden, dann müßtest Du u.U. noch eine
Clipping Region für Deine Bitmaps einrichten, damit WPA8() nicht ins
Blaue schießt.

Nein, brauchst du nicht. WPA8 schreibt immer nur so viel, wie du mit SizeX und SizeY angegeben hast. Das Alignment ist nur für die chunky-nach-planar-Umrechnung notwendig und da dient die Bitmap des TempRP als Puffer, die muß ja auch auf 16 Bits aufgerundet werden (AllocBitMap macht das automatisch).

Gruß Thomas

--
Email: thomas-rapp@web.de
Home: home.t-online.de/home/thomas-rapp/

[ - Antworten - Zitieren - Direktlink - ]

10.11.2004, 21:12 Uhr

Reth
Posts: 1858
Nutzer

Irgendwas stimmt leider immer noch nicht!
Habe nun das Bild 112 Pixel breit und 80 Pixel hoch von ArtPro in Chunkydaten ausgeben lassen (von denen ich denke, dass sie OK sind).

Im Porgramm lass ich aber nur bis zur Breite 100 WP8() arbeiten mit folgendem Code:

struct RastPort rp, rpTemp;
struct BitMap *tempBitMap;

bitMap = AllocBitMap(100, 80, 8, BMF_DISPLAYABLE, friendBitMap);
tempBitMap = AllocBitMap(100, 1, 8, 0, bitMap);

InitRastPort (&rp);
rp.BitMap = bitMap;
rpTemp = rp;
rpTemp.Layer = NULL;
rpTemp.BitMap = tempBitMap;
WritePixelArray8 (&rp, 0, 0, 99, 79, data, &rpTemp);

FreeBitMap(tempBitMap);

friendBitMap ist dabei die BitMap des 1024x768 Fensters, in das geblittet werden soll.

Oder darf ich letztere nicht dazu nehmen, weil sie ne andere Größe hat?

Ciao

[ - Antworten - Zitieren - Direktlink - ]

10.11.2004, 22:40 Uhr

Reth
Posts: 1858
Nutzer

Was allerdings mit demselben Array wunderbar funktioniert ist:

WriteChunkyPixels (&rp, 0, 0, 99, 79, data, 100);

Also muss ich irgendwo bei WPA8() noch nen Fehler haben!
Aus Performancegründen würd ich schon gern WPA8() nehmen!

Ciao

[ - Antworten - Zitieren - Direktlink - ]

11.11.2004, 09:58 Uhr

Holger
Posts: 8116
Nutzer

Zitat:
Original von Reth:
Also muss ich irgendwo bei WPA8() noch nen Fehler haben!
Aus Performancegründen würd ich schon gern WPA8() nehmen!

Nochmal: WPA8 ist nicht schneller, es ist günstigstenfalls genauso schnell, wahrscheinlich aber langsamer. Der einzige Vorteil von WPA8 ist, daß es schon ab OS2.0 existiert.
Die temporäre BitMap dient zum Zwischenspeichern von planaren Daten, deshalb muß sie =wie schon gesagt= wahrscheinlich grundsätzlich planar sein, was bei einer friend-BitMap nicht unbedingt der Fall ist, insb. bei Grafikkarten.

mfg
--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]

11.11.2004, 10:28 Uhr

Reth
Posts: 1858
Nutzer

@Holger

Danke für den Hinweis, werde die FriendBitMap bei der temporäre BitMap weglassen und wenn das noch nicht hilft, die Breite der temporären BitMap beim Alloc() auf ein Vielfaches von 16 anpassen um zu sehen wo der Fehler lag.

Verwenden werde ich dann erstmal weiter WriteChunkyPixel().

Ciao

[ - Antworten - Zitieren - Direktlink - ]

1 -2- 3

[ - Beitrag schreiben - ]

amiga-news.de Forum > Programmierung > Privilegverletzung bei FreeBitMap()

[ - Suche - Neue Beiträge - Registrieren - Login - ]