Ja, das Thema sagt eigentlich schon, wo der Haken ist. Meine Frage ist nun, ist es überhaupt möglich, eine Maske für BltMaskBitMapRastPort() per Datatype zu laden und den Blit auf allen bekannten Systemen korrekt durchzuführen?

Ich bin immerhin schon so weit, daß es auf meinem WinUAE-OS3.9-System funktioniert. Als Maske wird ein 1Bit-IFF-Bild geladen, die anderen Grafiken sind 24Bit (Format ist Nebensache, es geht mit allen Formaten, für die ich Datatypes habe).

Blöderweise ist das Ergebnis nur auf dem WinUAE-System korrekt, auf dem 4000er mit OS3.9/CGFX kommt Müll beim Blit heraus, auf einem anderen WinUAE-System (AmiKIT mit WB3.1-Unterbau) funktioniert es auch nicht, wie angedacht.

Die Dokumentation zum Thema Datatypes ist aber leider recht sparsam...

Kann mir da jemand weiterhelfen und mir ggf. Tipps geben, was ich dabei unbedingt zu beachten habe?

Grüße

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

@Blackbird:

Danke, leider bin ich ungefähr so weit gekommen wie Geit Ich habe das Problem, daß ich derzeit versuche, die Maske via Datatype zu laden und daß das bei einem System klappt, bei einem anderen nicht.

Blöderweis wird auch nirgendwo so richtig erwähnt, wie P96/CGFX tatsächlich mit solchen Bitmaps (1Bit) umgehen...

Grüße

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von geit:
Ich hab das Problem "umgangen" indem ich via PPaint jedes Bild auf 2 Farben reduziert habe und dieses Maskenbild als eigene Bitmap via Datentyp eingeladen habe und damit den Blit durchgeführt.

Die Maske kann man sehr einfach erstellen, in dem man die Transparente Farbe via PPaint-Maske blockiert und dann den Bildschirm füllt. Jetzt hat man nur noch zwei Farben und kann gefahrlos die Farbreduzierung nutzen.

Das Blitten funktioniert aber auch nicht mit MOS1.4.x. Erst mit MOS1.5 geht es. Unter Amithlon OS3.9 geht es auch.

---

Naja, diesen Weg bin ich im Grunde auch gegangen. Ich habe die Maske auf 2 Farben reduziert (hier allerdings mittels ArtEffect) und lade sie via Datatype. Trotzdem läuft es derzeit nur auf meinem WinUAE-System und nicht auf meinem 4000er. Den habe ich mir zu allem Überfluß auch noch "zerschossen", weil ich das CGFX-Update (rc6) ausprobieren wollte, ob das hilft. Es hat geholfen, die CVPPC nicht mehr zu erkennen, obwohl die definitiv funktioniert

Grüße

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von thomas:
- wenn swohl die Quell- als auch die Ziel-Bitmap BMF_INTERLEAVED gesetzt hat, muß die Maske in der Höhe an die Bildtiefe angepaßt werden (z.B. Bild mit drei Bitplanes -> Maske mit dreifacher Höhe).

---

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von thomas:

- beim Allokieren von eigenen BitMap mit AllocBitMap muß BMF_MINPLANES gesetzt werden (CGX ist da pingelieger als P96).

---

Hmm... ich hatte das bei der Masken-BitMap getan, unter P96 läufts dann gar nicht, da kommt nur Müll bei heraus. Ohne gehts, auch unter OS4 (Programm ist 68K). Unter CGFX gehts weder so noch so.

Die andere BitMap kann das gesetzt haben oder auch nicht. Ich hatte beide Möglichkeiten probiert.

Ich habe das Gefühl, daß das bei den Datatypes liegt, nur habe ich keinen Schimmer, was das sein könnte

Grüße

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233


[ Dieser Beitrag wurde von whose am 23.11.2006 um 14:06 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Hmm... ich hatte das bei der Masken-BitMap getan, unter P96 läufts dann gar nicht, da kommt nur Müll bei heraus. Ohne gehts, auch unter OS4 (Programm ist 68K). Unter CGFX gehts weder so noch so.

---

Zitat:

---

Ich habe das Gefühl, daß das bei den Datatypes liegt, nur habe ich keinen Schimmer, was das sein könnte

---

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von thomas:

Zitat:

---

Hmm... ich hatte das bei der Masken-BitMap getan, unter P96 läufts dann gar nicht, da kommt nur Müll bei heraus. Ohne gehts, auch unter OS4 (Programm ist 68K). Unter CGFX gehts weder so noch so.

---

...

Hast du vielleicht eine Friend-Bitmap angegeben ? Dann bekommst du natürlich das gleiche Pixel-Format wie die Friend-Bitmap, alle anderen Angaben zu Tiefe und Flags werden ignoriert (sofern BMF_MINPLANES dabei ist). Das wäre für die Maske tödlich, weil du ja eine planare Bitmap mit genau einer Bitplane haben möchtest.

---

Argh! Ja, genau das hab ich getan... verdammter Wald, da sieht man die Bäume nicht

Danke für den Augenöffner, da dürfte das Problem liegen.

Ich melde mich dazu dann nochmal hier, ob es tut, wenn ich das geradegerückt habe.

Grüße


--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233

[ - Antworten - Zitieren - Direktlink - ]

Jup, die Friend-Bitmap wars... allerdings beim NewDTObject(). Da hatte ich (aus blanker Gewohnheit) Screen.BitMap übergeben, das war natürlich nicht Sinn der Sache.

Nun gehts auch auf dem anderen WinUAE-System, nur CGFX konnte ich noch nicht testen, weil mein 4000er noch seiner Wiederherstellung harrt. Sollte aber gehen, schätze ich.

Vielen Dank nochmal!

Grüße

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von whose:
Jup, die Friend-Bitmap wars... allerdings beim NewDTObject(). Da hatte ich (aus blanker Gewohnheit) Screen.BitMap übergeben, das war natürlich nicht Sinn der Sache.

---

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von malte2:

Zitat:

---

Original von whose:
Jup, die Friend-Bitmap wars... allerdings beim NewDTObject(). Da hatte ich (aus blanker Gewohnheit) Screen.BitMap übergeben, das war natürlich nicht Sinn der Sache.

---

Übrigens gilt Screen->RastPort.BitMap und nicht &Screen->BitMap verwenden.

---

Ja, das war hier n Tippfehler aus Hektik... sry.

Screen->RastPort.BitMap sollte das auch heißen.

Grüße

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233

[ - Antworten - Zitieren - Direktlink - ]

Hm, also unter CGFX gehts leider nicht so schön trivial wie auf dem WinUAE-System mit P96. Unter CGFX ist die geblittete Grafik verschoben. Gehe ich Recht in der Annahme, daß mir da BYTESPERROW in die Quere kommt?

Es läuft also darauf hinaus, daß ich mir sämtliche Attribute der zu blittenden Farbgrafik "ansehen" muß, bevor ich die Mask-BitMap alloziere?

Ganz schon kompliziert, wenn man nicht auf die Spezialitäten des verwendeten RTG-Systems zurückgreifen mag...

Grüße


--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von malte2:
@whose:

Wenn die Quelle nicht interleaved, dann gilt für die Maske einfach:

Width = GetBitMapAttr(Quelle, BMA_WIDTH);
-> BytesPerRow = Width / 8;
Height = GetBitMapAttr(Quelle, BMA_HEIGHT);

---

Jain. Ich habe mir jetzt mal die Ergebnisse von ->BytesPerRow der jeweiligen Bitmaps nach dem AllocBitMap() angesehen.

P96 gibt die tatsächlichen Werte aus, CGFX nur Werte für eine Plane, obwohl sich das Ganze auf einem 16Bit-Screenmode abspielt bei CGFX.

Beispiel:

P96: Quellbitmap = 1920 BPR (488 Pixel, ARGB)
CGFX: Quellbitmap = 61 BPR (488 Pixel, 1 Plane !!!)

P96: Maske = 61 BPR (488 Pixel, 1 Plane)
CGFX: Maske = 64 BPR (1 Plane und Alignment anscheinend, gibt 512 Pixel -> Chaos)

Welchen Weg gibt es, diese Ungereimtheiten zu umschiffen? Wenn möglich, ohne auf CGFX resp. P96 zu testen? Der Witz daran ist ja, daß das Programm sowohl auf P96- als auch AGA-Screenmodes (wahrscheinlich dann auch ECS/OCS) klaglos seinen Dienst verrichtet (nachdem ich die Dussligkeit mit der FriendBitMap für die Maske beseitigt hatte).

Nur mit CGFX wills nicht wirklich

Grüße

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233

[ - Antworten - Zitieren - Direktlink - ]

Hmm, ich habe gerade mal etwas nachgedacht... prinzipiell müßte es dann doch sowohl als auch funktionieren, wenn ich die Quellbitmap nach den Ausmaßen der Masken-Bitmap alloziere, oder? Die BytesPerRow müßten dann ja für den Blit passen. Oder denke ich da schon wieder falsch?

Ich meine, ich "verlasse" mich da zwar auch wieder auf Eigenheiten des jeweiligen RTG-Systems, aber irgendwie scheint das ja nicht anders möglich zu sein, oder?

Grüße

Edit: Ja, ich habe richtig gedacht, habe gerade von daheim die Bestätigung bekommen, es läuft nun auch unter CGFX, nachdem ich die Quellbitmap den Größen-Attributen der Maske angepaßt habe.

Vielen Dank nochmal an alle für die Tipps!

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233


[ Dieser Beitrag wurde von whose am 25.11.2006 um 01:03 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

Eine Frage ist doch noch offen (Entschuldigung, falls ich damit zu nerven anfange ):

Wenn ich das richtig sehe, kann es mir aber trotz der veränderten Allozierungsreihenfolge passieren, daß die Quellbitmap interleaved "herauskommt", korrekt? Das müßte ich dann noch einmal überprüfen und ggf. die Maske reallozieren, mit einer Höhe von Quelle->Tiefe * Maske->Höhe?

Kann man sich dann darauf "verlassen", daß CGFX die Masken-Bitmap weiterhin mit Alignment in der Weite alloziert? Oder ist das keineswegs gesichert? Ich meine, wenn das nicht gesichert ist, hat man dann ja sowas wie einen Deadlock, man müßte die Quellbitmap reallozieren, die dann theoretisch wieder anders ausfallen könnte als beim ersten AllocBitMap(), worauf man die Maske dem anpassen müßte usw. usf.

Kann dieser Fall eintreten? Und wenn ja, welche Lösung gäbe es dafür? "Handarbeit" beim Allozieren der Masken-oder Quell-BitMap?

Wenns irgendwie machbar ist, wollte ich alle Systeme mit einem Programm "beglücken", also nicht auf das jeweils verwendete RTG-System testen...

Grüße

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von malte2:
Ignorier den BytesPerRow Wert in der BitMap Struktur! Für alle BitMaps, außer Interleaved, funktioniert folgendes unabhängig vom GFX System.

struct BitMap maskbm;
PLANEPTR mask;

if (mask = AllocRaster(GBA(bm, BMA_WIDTH), GBA(bm, BMA_HEIGHT)))
{
InitBitMap(&maskbm, 1, GBA(bm, BMA_WIDTH), GBA(bm, BMA_HEIGHT));
maskbm.Planes[0] = mask;
...
}

GBA = GetBitMapAttr

---

Hm, also "Handarbeit"... ok, ich werde das dann testen. Auffällig ist halt nur, daß CGFX die Maske offensichtlich mit Alignment anlegt. Oder kann man das als "Vorsichtsmaßnahme" von CGFX werten, damit das auch im Falle von planaren BitMaps als Quelle hinhaut? Wenn ja, ist die "verkehrte" Reihenfolge bei der Allozierung doch eigentlich ausreichend, solange kein Interleaved ins Spiel kommt?

Die "Handarbeit" hätte dann den Vorteil, daß man die Quelle auf Interleaved testen kann, bevor die Masken-BM alloziert wird, richtig?

Grüße

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von whose:
Eine Frage ist doch noch offen (Entschuldigung, falls ich damit zu nerven anfange ):

Wenn ich das richtig sehe, kann es mir aber trotz der veränderten Allozierungsreihenfolge passieren, daß die Quellbitmap interleaved "herauskommt", korrekt? Das müßte ich dann noch einmal überprüfen und ggf. die Maske reallozieren, mit einer Höhe von Quelle->Tiefe * Maske->Höhe?

---

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von malte2:
Ein Mindestalignment von 16 Pixel hast Du immer. Wenn die Quelle interleaved ist, so müsstes Du halt Breite * Tiefe * Höhe Pixel allozieren.

---

Ja, die 16 Pixel ergeben sich aus dem, was an Dokumentation zu finden ist. Das erklärt aber noch nicht, wie CGFX auf die Idee kommt, auch bei 480 Pixeln Breite (die Maße haben sich ein klein wenig verändert, ergibt 30 * 16 Pixel bzw. 60 BPR) die Maske mit 512 Pixel (64 BPR) zu allozieren, während P96 das bleiben läßt.

Die "Erweiterung" der Maske bei einer Quell-BitMap in Interleaved ist soweit auch klar.

Meine Frage ist aber, ob man nun darauf bauen darf, daß sich CGFX immer so verhält, daß bei einer Planar-Bitmap z.B. von ursprünglich 480 Pixeln Breite auf 512 Pixel Breite "erweitert" wird oder ob es z.B. passieren kann, daß sich diese Erweiterung z.B. bei einer Reallozierung der Maske (da die Quelle aus irgend einem Grund interleaved angelegt wurde) in interleaved Form auf einmal wieder ändert. Denn das wäre ziemlich fatal, wenn man darauf nicht gefaßt ist.

Grüße

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von Holger:

Also nach meinem Verständnis dient genau dazu die Angabe der "friend BitMap". Also, wenn Du Deine QuellBitMap nun nach den Dimensionen der MaskenBitMap anlegst, gibst Du auch noch die MaskenBitMap als friend-BitMap an, woraus das System messerscharf schließen sollte "friend-BitMap non-interleaved => neue BitMap non-interleaved".

---

Naja, schon... aber bezieht sich das nicht auf alle Attribute der FriendBitMap? Dazu zählte ja auch z.B. Plane-Anzahl bzw. Farbtiefe. Bei einer Quelle, die für z.B. 24Bit ausgelegt ist, wäre 1Bit Planar etwas sehr weit entfernt vom erwünschten Ergebnis, oder nicht? Oder fasse ich das falsch auf und die Farbtiefe zählt nicht zu den von der FriendBitMap "übernommenen" Attributen?

Den Ärger hatte ich ja umgekehrt, als ich die Maske mit FriendBitMap allozierte. 1Bit wollte ich, 16Bit (vermute ich wenigstens) bekam ich (bzw. mein Tester, bei mir funktionierte das ja in einem ARGB-Modus, warum auch immer).

Prinzipiell mache ich das jetzt ja so, wie Du vorschlägst. Die Quelle wird nach den Dimensionen (via GetBitMapAttr()) der Maske alloziert, was ja auch funktioniert.

Aber funktioniert das auch auf jeden Fall, wenn die Quell-BitMap ebenfalls per Datatype gefüttert wird und der spätere maskierte Blit in eine sichtbare Bitmap (genauer: Fenster) zu einem noch anderen Format führt?

Ich bin mir da halt nicht 100% sicher, deswegen frage ich. Rein von der Dokumentation her sollte sich der Datatype ja an das halten, was die von mir allozierte BitMap als Format vorgibt. Wenn das auf alle Fälle gilt und ich mit der (nicht dargestellten) Quellbitmap nur im Hintergrund arbeite, dann dürfte ich mein Problem bzw. meine Frage wohl als geklärt betrachten, oder?

Grüße

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von whose:
Naja, schon... aber bezieht sich das nicht auf alle Attribute der FriendBitMap? Dazu zählte ja auch z.B. Plane-Anzahl bzw. Farbtiefe.

---

Zitat:

---

Prinzipiell mache ich das jetzt ja so, wie Du vorschlägst. Die Quelle wird nach den Dimensionen (via GetBitMapAttr()) der Maske alloziert, was ja auch funktioniert.

---

Zitat:

---

Aber funktioniert das auch auf jeden Fall, wenn die Quell-BitMap ebenfalls per Datatype gefüttert wird und der spätere maskierte Blit in eine sichtbare Bitmap (genauer: Fenster) zu einem noch anderen Format führt?

---

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von Holger:

Zitat:

---

Original von whose:
Naja, schon... aber bezieht sich das nicht auf alle Attribute der FriendBitMap? Dazu zählte ja auch z.B. Plane-Anzahl bzw. Farbtiefe.

---

Natürlich nicht alle. Größe und Farbtiefe stammen von Dir, falls sie mit dem Format der friend-BitMap vereinbar sind. Also z.B., wenn die Friend-BitMap 8Planes interleaved wäre, müsste die resultierende BitMap auch 8 Bits/Pixel haben, unabhängig von der gewünschten Farbtiefe. Und wenn die friend BitMap RTG ist, und dort minimal 8bpp chunky möglich ist, kann man natürlich auch keine 1 Bit/Pixel bekommen...
Aber non-interleaved BitMaps sind auch in unterschiedlichen Farbtiefen kompatibel.

---

Zitat:

---

Zitat:

---

Prinzipiell mache ich das jetzt ja so, wie Du vorschlägst. Die Quelle wird nach den Dimensionen (via GetBitMapAttr()) der Maske alloziert, was ja auch funktioniert.

---

Na ja, Breite, Höhe, Tiefe, aber eben nicht zwangsläufig auch das Alignment.

---

Zitat:

---

Zitat:

---

Aber funktioniert das auch auf jeden Fall, wenn die Quell-BitMap ebenfalls per Datatype gefüttert wird und der spätere maskierte Blit in eine sichtbare Bitmap (genauer: Fenster) zu einem noch anderen Format führt?

---

Wenn die Quell-BitMap RTG ist, ist sie nicht unbedingt zu der vorher angelegten Maske kompatibel. Das Format der sichtbaren Ziel-BitMap ist egal, es ist schlimmstenfall nicht sehr effizient, zwischen zwei völlig unterschiedlichen BitMap zu blitten.

---

Hmm... über unterschiedliche Farbtiefen mache ich mir da weniger Sorgen, an diese Informationen käme man (über eine FriendBitMap) ja dran.

Prinzipiell könnte ich für die Quelle eine FriendBitMap angeben (in diesem Fall das Ziel) und speziell die Dimensionen denen der Maske anpassen, für den Fall, das diese "breiter" wird als vorgesehen (also genau das, was ich derzeit mache).

Das sollte doch auf allen Systemen dann einigermaßen (bis auf ggf. unterschiedliche Breite der Maske) gleich ablaufen, oder?

Wie gesagt, experimentell ist diese Vorgehensweise nun bestätigt, ich frage aber lieber nochmal nach, als daß ich später von einem "ungewöhnlichen" System überrascht werde, auf dem es dann doch nicht so funktioniert.

Grüße

Edit: Mir fiel gerade auf, daß ich da wohl wieder etwas zu kompliziert denke.

Die Vorgehensweise müßte folgendermaßen korrekt sein:

1. Test, ob Ziel interleaved ist.
2. Maske allozieren, 1Bit tief, falls Ziel Interleaved ist, Maske in der "Höhe" anpassen.
3. Quellbitmap in der "Breite" der Maske allozieren, FriendBitMap->Ziel (die Quelle sollte dann auch interleaved angelegt werden).

Dann müßten der maskierte Blit (und der ganze Rest) auf allen bekannten Systemen funktionieren (einschließlich AGA) und Unterschiede im Pixelformat auf die Maske beschränkt werden (was ja, außer bei 1Bit Ziel und Quelle, sowieso der Fall ist).

Richtig?

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233


[ Dieser Beitrag wurde von whose am 26.11.2006 um 00:05 Uhr geändert. ]

[ Dieser Beitrag wurde von whose am 26.11.2006 um 11:35 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von whose:
Also ich meinte Alignment, was die Ausmaße der Bitmap angeht (die ja bei CGFX anders ausfallen als unter P96), nicht die Lage im Speicher. Bei der 1Bit-Maske ergibt sich ja schlimmstenfalls eine andere "Breite" als geplant (sprich: mehr oder weniger BytesPerRow).

---

Zitat:

---

Prinzipiell könnte ich für die Quelle eine FriendBitMap angeben (in diesem Fall das Ziel) und speziell die Dimensionen denen der Maske anpassen, für den Fall, das diese "breiter" wird als vorgesehen (also genau das, was ich derzeit mache).

---

Zitat:

---

Die Vorgehensweise müßte folgendermaßen korrekt sein:

1. Test, ob Ziel interleaved ist.
2. Maske allozieren, 1Bit tief, falls Ziel Interleaved ist, Maske in der "Höhe" anpassen.
3. Quellbitmap in der "Breite" der Maske allozieren, FriendBitMap->Ziel (die Quelle sollte dann auch interleaved angelegt werden).

---

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von Holger:

Zitat:

---

Original von whose:
Also ich meinte Alignment, was die Ausmaße der Bitmap angeht (die ja bei CGFX anders ausfallen als unter P96), nicht die Lage im Speicher. Bei der 1Bit-Maske ergibt sich ja schlimmstenfalls eine andere "Breite" als geplant (sprich: mehr oder weniger BytesPerRow).

---

Also Du gibst bei AllocBitMap nur eine Breite an, die Funktion entscheidet darüber, wieviele bytes/row die BitMap hat. Darauf hast Du halt nur indirekt Einfluss...

---

Das habe ich gemerkt

Zitat:

---

Zitat:

---

Prinzipiell könnte ich für die Quelle eine FriendBitMap angeben (in diesem Fall das Ziel) und speziell die Dimensionen denen der Maske anpassen, für den Fall, das diese "breiter" wird als vorgesehen (also genau das, was ich derzeit mache).

---

...aber eigentlich willst Du eine Maske, die zur Quelle kompatibel ist und nicht umgekehrt.

---

Zitat:

---

Zitat:

---

Die Vorgehensweise müßte folgendermaßen korrekt sein:

1. Test, ob Ziel interleaved ist.
2. Maske allozieren, 1Bit tief, falls Ziel Interleaved ist, Maske in der "Höhe" anpassen.
3. Quellbitmap in der "Breite" der Maske allozieren, FriendBitMap->Ziel (die Quelle sollte dann auch interleaved angelegt werden).

---

Warum legst Du dann nicht einfach die QuellBitMap zuerst an, und legst dann die passende Maske dazu an, wie es die normale Vorgehensweise wäre?

---

Zitat:

---

Ich seh da für den Punkt 2 keinen wirklichen Unterschied. (Mal abgesehen davon, dass die Maske auch weiterhin in der bytesPerRow-Eigenschaft, also letztendlich der Breite und nicht der Höhe angepasst wird)

---

Ja, speichertechnisch. Logisch wird sie in der Höhe angepaßt, wenn ich sie z.B. dreimal so "hoch" alloziere, weil die Quelle interleaved und 3Planes tief ist (Beispiel). Darüber hatten wir uns aber schon einmal unterhalten, das ist eine Frage der Betrachtungsweise.

Grüße

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233

[ - Antworten - Zitieren - Direktlink - ]