Zitat:

---

Original von thomas:
@whose:

Ich habe gerade mal selber versucht, eine Maske per Datatypes zu laden. Unter MorphOS (also CGX) hat es auf Anhieb funktioniert, auf den anderen (P96 und native) muß man die Bitmap konvertieren.

---

Ich hoffe, es schockt Dich nicht zu sehr, daß es auf meinem WinUAE mit der Konvertierung nicht geht

Zitat:

---

Aber wenn man sich wortwörtlich an die Dokumentation hält, funktioniert es auf allen Systemen. Ich weiß nicht, was daran so schwer ist.

---

Zitat:

---

Hier ist mein Ergebnis: http://thomas-rapp.homepage.t-online.de/dtmask.lha

---

Danke für dieses Beispiel. Trotzdem hätte es genügt zu sagen: Ja, Deine 3 Punkte treffen zu. Dein Beispiel macht streng genommen genau das, was ich erfragt hatte

Danke noch einmal an alle, dank Eurer Hilfe müßte ich das Problem nun lösen können

Grüße

--
---

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


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

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von whose:

Ich hoffe, es schockt Dich nicht zu sehr, daß es auf meinem WinUAE mit der Konvertierung nicht geht

---

Zitat:

---

Wenn man sich wortwörtlich daran halten würde, dürfte (bzw. sollte) man AllocRaster()/InitBitMap() nicht einsetzen. Und genau das tue ich derzeit, die beiden nicht benutzen.

---

Zitat:

---

Original von malte2:
in convert_mask() muß Du als Blitgröße die Größe der oldmask nehmen und nicht des friends, weil der Friend größer ausfallen könnte als die alte Maske.

---

Zitat:

---

Achja und bei alloc_mask_bitmap() bleibt selbst für interleaved Masken die Tiefe bei 1. Nur der Modulo muß natürlich richtig gesetzt werden.

---

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von thomas:

Zitat:

---

Original von whose:

Ich hoffe, es schockt Dich nicht zu sehr, daß es auf meinem WinUAE mit der Konvertierung nicht geht

---

Warum sollte mich das schocken. Ich habe das Programm unter WinUAE entwickelt, bei mir läuft es da. Ich habe noch keine Konfig gefunden, bei der es nicht funktioniert.

Folgende Konfigs habe ich getestet:

WinUAE / OS3.9 / P96
WinUAE / OS3.1 / AGA
WinUAE / OS3.1 / OCS
A4000 / CVPPC / OS3.1 / CGX
A4000 / CVPPC / MorphOS / CGX
A4000 / Voodoo3 / OS3.9 / P96
A1XE / Radeon / OS4.0 / P96
Peg1 / Radeon / MorphOS / CGX

Vielleicht solltest du dein WinUAE mal neu aufsetzen.

---

Zitat:

---

Zitat:

---

Wenn man sich wortwörtlich daran halten würde, dürfte (bzw. sollte) man AllocRaster()/InitBitMap() nicht einsetzen. Und genau das tue ich derzeit, die beiden nicht benutzen.

---

In meinen Autodocs steht "pointer to the single bit-plane mask, which must be the same size and dimensions as the planes of the source bitmap". Zu der Zeit, als das geschrieben wurde, war AllocRaster die bevorzugte, wenn nicht vorgeschriebene Methode, Bitplanes zu allokieren. Und das habe ich auch gemacht.

---

Eventuell solltest Du (wenn es denn schon mal um RTG geht) auch einmal in modernere Autodocs schauen. In den CGFX-und P96-Autodocs wird von der Verwendung der "Handmade"-Methode abgeraten und ausdrücklich auf AllocBitMap() verwiesen. Daran habe ich mich gehalten und wollte das auch weiter tun (außer, es ginge nicht anders).

Es konnte allerdings auch keiner ahnen, daß ausgerechnet bei BltMaskBitMapRastPort() eine Ausnahme lauert. Dokumentiert wird es jedenfalls nicht, daß die 1Plane-Bitmap unter CGFX im Gegensatz zu AGA- oder P96-Systemen größer "herauskommen" könnte.

Meine P96-Systeme (inkl. µA1) verhalten sich jedenfalls alle gleich meinem AGA-1200er, nur der CGFX-4000er tanzt da aus der Reihe mit der 512 (statt 480) Pixel Maske.

Wenn man aber damit rechnet, sieht das Ganze schon wesentlich entspannter aus. Ich weiß ja nun, daß ich bei 1Plane-Masken mit "Erweiterungen" der Plane rechnen muß und offensichtlich gibt es keine plausiblen Gründe, die gegen eine "umgekehrte" Allozierungsreihenfolge sprechen.

Ich wollte mit meiner letzten Frage übrigens keine langatmige Diskussion um Begrifflichkeiten lostreten, das war nicht die Absicht. Ich wollte einfach nur fragen, ob bei der Vorgehensweise (siehe meine Angaben zur Allozierungsreihenfolge) mittels AllocBitMap() noch irgendwelche Fallen lauern.

Vom Ablauf her ist die Sache jedenfalls ok (es funktioniert inzwischen reibungslos) und von den Docs auch gedeckt (wo steht, daß man die Quelle nicht der Maske anpassen darf, wenn diese aus irgendeinem Grund mit "Alignment" in der Weite angelegt wird?).

Mein Problem, daß ich anfangs hatte, rührte vor allem daher, daß ich keine Kunststücke mit händischen BitMap-Allozierungen treiben und die Bilder (Bitmaps) per Datatype laden lassen wollte. Ich hätte natürlich auch die Grafiken den speziellen Eigenschaften von CGFX anpassen können (was dann hoffentlich auch auf P96-Systemen klappt), aber das war nicht Sinn der Sache oder gar meiner Frage.

Wie gesagt, für die Hilfe bin ich sehr dankbar und es hat auch geholfen. Es läuft wie angedacht.

Grüße

--
---

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

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von thomas:

Nein, muß ich nicht. Die Maske muß laut Doku (s.o.) die gleiche Größe haben, wie die Quellbitmap, nicht wie die geladene Maske. Das war ja das Problem in diesem Thread.

---

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Eventuell solltest Du (wenn es denn schon mal um RTG geht) auch einmal in modernere Autodocs schauen. In den CGFX-und P96-Autodocs wird von der Verwendung der "Handmade"-Methode abgeraten und ausdrücklich auf AllocBitMap() verwiesen. Daran habe ich mich gehalten und wollte das auch weiter tun (außer, es ginge nicht anders).

---

Zitat:

---

Es konnte allerdings auch keiner ahnen, daß ausgerechnet bei BltMaskBitMapRastPort() eine Ausnahme lauert. Dokumentiert wird es jedenfalls nicht, daß die 1Plane-Bitmap unter CGFX im Gegensatz zu AGA- oder P96-Systemen größer "herauskommen" könnte.

---

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von thomas:
@whose:

Zitat:

---

Eventuell solltest Du (wenn es denn schon mal um RTG geht) auch einmal in modernere Autodocs schauen. In den CGFX-und P96-Autodocs wird von der Verwendung der "Handmade"-Methode abgeraten und ausdrücklich auf AllocBitMap() verwiesen. Daran habe ich mich gehalten und wollte das auch weiter tun (außer, es ginge nicht anders).

---

Deshalb schrieb ich *wortwörtlich* an die Doku halten. Denn bei BltBitMapRastPort ist ausdrücklich von einer *Bitplane* die Rede, nicht von einer BitMap. Bitplanes allokiert man mit AllocRaster.

---

Zitat:

---

Daß wir die Bitplane an eine Bitmap anhängen, um darauf Grafikoperationen ausführen zu können, ist schmückendes Beiwerk und im Grunde nichts anderes als Trickserei.

---

Das lasse ich einfach mal so stehen, sonst führt das wieder zu nichts

Zitat:

---

Zitat:

---

Es konnte allerdings auch keiner ahnen, daß ausgerechnet bei BltMaskBitMapRastPort() eine Ausnahme lauert. Dokumentiert wird es jedenfalls nicht, daß die 1Plane-Bitmap unter CGFX im Gegensatz zu AGA- oder P96-Systemen größer "herauskommen" könnte.

---

Im Grunde doch. Gerade in den CGX-Autodocs steht, daß AllocBitMap die Anforderungen einer modernen Grafikkarte berücksichtigt und unter Umständen unerwartet große Alignments vornimmt.

---

Ich fände es halt brillianter, wenn diese Umstände dann mal näher erläutert würden. Da wird nämlich nicht erklärt, wieso CGFX die 1Bit-Bitmap in der "Breite" erweitert, während P96 (auf dem gleichen System, die gleiche GraKa!) das nicht tut. Ist die CV64 unter P96 auf einmal nicht mehr modern?

Bevor Fragen kommen: Aufgrund dieser Komplikationen habe ich meinen alten 1200er reaktiviert, da sind beide Systeme drauf.

Naja, auf jeden Fall weiß ich jetzt, wo es haken kann, wenn solche Ergebnisse ins Bild kommen.

Grüße

--
---

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

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von whose:
Ich fände es halt brillianter, wenn diese Umstände dann mal näher erläutert würden. Da wird nämlich nicht erklärt, wieso CGFX die 1Bit-Bitmap in der "Breite" erweitert, während P96 (auf dem gleichen System, die gleiche GraKa!) das nicht tut.

---

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von Holger:

Zitat:

---

Original von whose:
Ich fände es halt brillianter, wenn diese Umstände dann mal näher erläutert würden. Da wird nämlich nicht erklärt, wieso CGFX die 1Bit-Bitmap in der "Breite" erweitert, während P96 (auf dem gleichen System, die gleiche GraKa!) das nicht tut.

---

Nun, wenn Du eine RTG-BitMap anlegst, darfst Du gemäß der Spezifikation auf kein Feld der BitMap-Struktur zugreifen, geschweige denn annehmen, dass diese Feld einen sinnvollen Wert enthält. Somit ist es ziemlich wurscht, was in den BytesPerRow drinsteht.
Wenn Du dagegen eine non-RTG BitMap anlegst, hängt das Alignment davon ab, ob DISPLAYABLE und/oder INTERLEAVED angegeben wurden, sollte aber unabhängig davon sein, ob CGX oder P96 installiert sind.

---

So weit waren wir ja schon... nur ist es halt doch nicht unabhängig davon, ob CGFX oder P96 im Spiel sind. Die Ergebnisse sprachen eine recht eindeutige Sprache.

P96->OK, CGFX->verschoben.

Die Ergebnisse aus BytesPerRow habe ich programmtechnisch auch nicht ausgewertet (nur ausgegeben, um zu sehen, was sich dort so ergibt) und u.U. hatte ich einfach Glück, daß da was sinnvolles drin stand (etwas, was die Verschiebung unter CGFX halt erklärte).

Ich habe das Beispiel von thomas inzwischen aufgegriffen (inklusive Test, ob die Quellbitmap zufälligerweise größer als die alte Maske ist) und es tut seinen Dienst. AGA sollte nun auch funktionieren (obwohls für die Grafik nicht sinnvoll wäre), habs aber noch nicht getestet

Grüße

--
---

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

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von thomas:
@whose:

Es ist in sofern unabhängig, als daß du von AllocBitMap ein Objekt zurück bekommst, über das du keine Annahmen machen darfst, außer daß man es in einem RastPort oder Screen verwenden kann. Eine Black-Box sozusagen.

Wenn du eine Bitmap nach deinen Vorstellungen benötigst, z.B. mit einem bestimmten Alignment, dann mußt du sie selbst allokieren. Allerdings mußt du dann mit Performanceeinbußen bei Grafikoperationen rechnen, weil die Grafikkartensoftware die Bitmap u.U. in das richtige Format konvertieren muß.

---

Ja, das ergibt sich ja aus der Dokumentation. Bei einer Maske für BltMaskBitMapRastPort() bleibt einem aber nichts anderes übrig, als die BitMap wenigstens in einer bestimmten Größe anzulegen. Da kann man schlicht keine Rücksicht auf irgendwelche Alignment-Vorstellungen der RTG-Software nehmen, da das Ergebnis sonst nicht brauchbar ist.

Ich finde es jedenfalls weiterhin merkwürdig, daß P96 und CGFX sich genau in diesem Punkt unterscheiden. Welche Aspekte sich hinter der Entscheidung von CGFX verstecken, die Masken-Bitmap in dieser speziellen Größe anzulegen, kann ich aber nicht beurteilen. Einen Sinn wird das schon haben, aber leider wird man darüber in der Dokumentation wenig bis gar nicht aufgeklärt.

Nun ja, dieses Problem ist nun umschifft, dank u.A. Deiner Hilfe und der Erläuterungen von malte2 und Holger. Für andere wirds hoffentlich auch nützlich sein

Grüße

--
---

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

[ - Antworten - Zitieren - Direktlink - ]