amiga-news ENGLISH VERSION
.
Links| Forum| Kommentare| News melden
.
Chat| Umfragen| Newsticker| Archiv
.

amiga-news.de Forum > Programmierung > Layers und Cliprects [ - Suche - Neue Beiträge - Registrieren - Login - ]

-1- [ - Beitrag schreiben - ]

21.08.2005, 23:39 Uhr

DariusBrewka
Posts: 899
[Benutzer gesperrt]
Ich habe ein für mich ganz Merkwürdiges Problem und zwar möchte ich meine WritePixelArrayAlpha() (nicht die von CGX, sondern meine da OS3.9 das ja nicht unterstützt) so umschreiben, dass ich kein Temporären Buffer mehr brauche (Hintergrund auslesen Per ReadPixelArray()), dazu muss ich wissen wo ich nicht hinzeichnen darf und wo der Speicher für die verdeckten Regionen ist. Das mit den Clippen klappt ja auch 100% nur wenn ich das Fenster über dem gezeichneten wegbewege ist nicht so wie es sein sollte.

Das Fenster wo hineingezeichnet werden soll ist ein SMART_REFRESH Fenster und wenn ich darüber ein sagen wir mal 100 Pixel breites Window lege, so sollte die Bitmap für den Backgroundbuffer einen BytesPerRaw Wert von 400 Bytes haben (alles in BGRA Format), ist aber bei mir grösser, Fülle ich diese Bitmap mit einem Rechteck der Dimensionen wie in der zu dieser Region gehörenden Cliprect->bounds angegebenen Grösse so fehlt Rechts exakt der Teil der dem BytesPerRow Wert entspricht, geteilt durch 4 abzüglich (bounds.MaxX-bounds.MinX), wenn ich das Rechteck rechtsbündig zeichne so fehlt am linken Ende dieser Teil.

Mir scheint das so, als ob bei dieser Bitmap irgendwo ein Teil existiert, der einfach übersprungen wird. Irgendwie habe ich keine Erklärung für dieses Merkwürdige verhalten.

[ - Antworten - Zitieren - Direktlink - ]

22.08.2005, 13:22 Uhr

Georg
Posts: 107
Nutzer
@DariusBrewka:

Bei cliprects die verdeckte Bereiche von Fenstern beschreiben (im Falle von smart refresh auf eine offscreen bitmap "zeigen") mußt du beim Zeichnen horizontal (ClipRect->bounds.MinX & 0xF) dazuzählen.

Der Grund ist, daß die offscreen bitmaps der ClipRects nicht genau für die Koordinaten der ClipRects bounds angelegt werden so wie sie dort drin stehen, sondern horizontal wird auf Vielfaches von 16 gerundet. Wenn ein ClipRect zum Beispiel die bounds Koordinaten 130,100 - 170, 200 hat, dann ist die Offscreen bitmap praktisch für Kooridnaten 128,100 - 143,200 "ausgelegt". Die Start-X Kooridnate ist also auf ein Vielfaches von 16 abgerundet. Die End-X Koordinate auf ein Vielfaches von 16 aufgerundet minus 1.

Der Grund dafür sind die Planaren BitMaps bei den Classic Amigas. Wenn die BitMaps so aligned sind wie beschrieben dann kann offscreen-bitmap bereich mit onscreen-bitmap bereich umgeblittet werden ohne horizontal shiften (0 ... 15) zu müssen was einfacher und schneller ist. Für den Blitter.


Die ClipRects selbst "durchzugehen" sollte man aber eigentlich nicht tun. Ist evil! Man kann cgfx/DoCDrawMethodTagList() verwenden, welches für jedes relevante ClipRect eine User Hook Funktion aufruft mit den notwendigen Daten.

Aber auch da sollte man nicht davon ausgehen, daß das überall und immer funktionert. Z. B. unter AROS hosted/Linux tut es da nicht, weil dort Direktzugriff auf Screen bitmaps/friend bitmaps von screen bitmaps nicht unterstützt wird.



[ Dieser Beitrag wurde von Georg am 22.08.2005 um 13:24 Uhr editiert. ]

[ - Antworten - Zitieren - Direktlink - ]

23.08.2005, 00:57 Uhr

DariusBrewka
Posts: 899
[Benutzer gesperrt]
Zitat:
Original von Georg:
Wenn ein ClipRect zum Beispiel die bounds Koordinaten 130,100 - 170, 200 hat, dann ist die Offscreen bitmap praktisch für Kooridnaten 128,100 - 143,200 "ausgelegt". Die Start-X Kooridnate ist also auf ein Vielfaches von 16 abgerundet. Die End-X Koordinate auf ein Vielfaches von 16 aufgerundet minus 1.


und wieso dann 143,200 ? und nicht 175,200 ?,

Zitat:
Der Grund dafür sind die Planaren BitMaps bei den Classic Amigas. Wenn die BitMaps so aligned sind wie beschrieben dann kann offscreen-bitmap bereich mit onscreen-bitmap bereich umgeblittet werden ohne horizontal shiften (0 ... 15) zu müssen was einfacher und schneller ist. Für den Blitter.

das ist aber auch etwas was ich nicht verstehe,ich habe früher als ich noch ASM schrieb den Blitter immer direkt benutzt (zum Demo schreiben), un da las ich im Intern immer das der Blitter einen sogenannten Barell-Shifter hat der keine zusätzliche Zeit zum schiften braucht, es ist weder Leichter noch schneller!

Zitat:
Die ClipRects selbst "durchzugehen" sollte man aber eigentlich nicht tun. Ist evil! Man kann cgfx/DoCDrawMethodTagList() verwenden, welches für jedes relevante ClipRect eine User Hook Funktion aufruft mit den notwendigen Daten.

Aber auch da sollte man nicht davon ausgehen, daß das überall und immer funktionert. Z. B. unter AROS hosted/Linux tut es da nicht, weil dort Direktzugriff auf Screen bitmaps/friend bitmaps von screen bitmaps nicht unterstützt wird.


dann nutzt mir das auch nicht viel, man könnte es aber so sagen Auf OS4, MOS & AROS gibt's so eine Art WritePixelArrayAlpha(), auf 68k gibt's das nicht, da kann man entweder DoCDrawMethodTagList() verwenden, oder die ClipRects direkt durchgehen, beides macht keinen Unterschied, da OS3.9 für 68k nicht weiterentwickelt wird und es somit unwahrscheinlich sein dürfte dass die Methode direkt über die ClipRects irgendwann einmal nicht mehr Funktionieren wird. Auf AROS macht das z.Z. ehe keinen Sinn, da LockBitmapTags() nicht funktioniert! Mal sehen, wenn DoCDraw... nicht allzu Kompliziert ist dann werde ich es wohl mal ausprobieren.

gruss

Darius

[ - Antworten - Zitieren - Direktlink - ]

23.08.2005, 02:53 Uhr

DariusBrewka
Posts: 899
[Benutzer gesperrt]
@Georg

durch ein

code:
if (cr->BitMap) _dx = cr->bounds.MinX & 0x0f; else _dx = 0;


wurde der Fehler behoben, danke hat super geklappt, d.h bounds.MinX ist relativ zur Bitmap nicht mehr 0 sondern _dx.

gruss

[ - Antworten - Zitieren - Direktlink - ]


-1- [ - Beitrag schreiben - ]


amiga-news.de Forum > Programmierung > Layers und Cliprects [ - Suche - Neue Beiträge - Registrieren - Login - ]


.
Impressum | Datenschutzerklärung | Netiquette | Werbung | Kontakt
Copyright © 1998-2024 by amiga-news.de - alle Rechte vorbehalten.
.