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

amiga-news.de Forum > Programmierung > Bitmaps nur durch 16 teilbare Breite? [ - Suche - Neue Beiträge - Registrieren - Login - ]

1 2 3 -4- 5 6 [ - Beitrag schreiben - ]

05.09.2006, 19:15 Uhr

whose
Posts: 2156
Nutzer
Zitat:
Original von DariusBrewka:
Zitat:
Original von whose:
Zitat:
Original von bubblebobble:
Und benutzt jemand tatsächlich interleaved Bitmaps, oder ist das mehr eine teoretische Diskussion ?


Das ist wohl eher theoretisch. Benutzt wurde dieses Feature wohl hauptsächlich für Spiele, mit OS-Mitteln angelegte Screens sind nicht "von Haus aus" interleaved.


Also Ich kann hier bei PSI (MUIs Screen Tool) Interleaved einschalten,


Ist das nicht der MUI-eigene CustomScreen-Promoter? Benutzt den wirklich jemand? Aber mal davon ab: Damit kann mans dann doch prima testen, wenn man ein blittendes MUI-Programm gebaut hat oder die Quellen für so ein Programm hat.

Zitat:
aber außerhalb von Planaren Screens wird das keine Funktion haben.

Unwahrscheinlich :D Obwohls wohl mal zu Anfangszeiten eine GraKa mit Planar-Modus gab, ich weiß aber nicht mehr, welche das war... eine der ersten GVP-Karten, glaube ich. Aber ich glaube nicht, daß es dafür einen CGFX-/P96-Treiber gibt.

Grüße

--
---

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

[ - Antworten - Zitieren - Direktlink - ]

05.09.2006, 19:23 Uhr

Holger
Posts: 8089
Nutzer
Zitat:
Original von whose:
Nein, gar nicht. Beachte das (an und für sich unbedeutende) Wörtchen "Dimensions", dann kennst Du den Grund. Eine Interleaved-Bitmap von 4Bit Tiefe ist im Speicher 4 mal "höher" als die letztlich resultierende Pixelmenge. Die Maske paßt dann zwar in der Breite, aber die "Zwischenzeilen" würden fehlen, wenn die Maske nicht 4 mal "höher" wäre.

Das ist eine interessante neue Interpretation der bytesPerRow Eigenschaft. Ich hätte bislang immer vermutet, dass solche BitMaps, bzw. deren Planes, n mal breiter sind.
Zitat:
Da arbeitet der Blitter ja auch bei der Quellbitmap quasi auf Bitebene und nicht auf Byte- oder Halbbyte-Ebene, wie bei non-interleaved Bitmaps.
Hä?
Der Blitter arbeitet immer wortweise, meinethalben auch mit bitweiser Verknüpfung, aber definitiv immer auf die gleiche Weise.
Zitat:
Das ist wohl eher theoretisch. Benutzt wurde dieses Feature wohl hauptsächlich für Spiele, mit OS-Mitteln angelegte Screens sind nicht "von Haus aus" interleaved.
Also meine Workbench ist es.
Und ich tendiere eher zu der Meinung, dass dies bei OS3.0+/AGA der default ist.

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

[ - Antworten - Zitieren - Direktlink - ]

05.09.2006, 19:31 Uhr

Holger
Posts: 8089
Nutzer
Zitat:
Original von DariusBrewka:
Zitat:
Original von malte2:
@DariusBrewka:

Eine Maske für Interleaved BitMaps muß auch selber interleaved sein (daher Breite * Tiefe * Höhe) damit BltMaskBitMap() funktioniert.


Hmm, ich glaube nicht daran, denn dann würden viele Ältere ulktools die auf die WB mittels MaskenFunktionen blitten nicht funktionieren. Interleaved wurde mit 3.0? eingeführt.

Der Denkfehler liegt in der Eigenschaft Breite, die im Kompatiblitätsmodus nicht existiert. In der alten Struktur gibt es nur bytesPerRow, welches eben bei interleaved BitMaps depth Mal größer ist. Und genau darauf müssen alte Programme zugreifen, was auch gleich erklärt, wie sie mit 64Bit-Alignment klar kommen. Wenn z.B. der Workbench-Screen entsprechend aufgerundete bytesPerRow-Werte aufweist, muss die Maskenspeichergröße logischerweise ebenfalls aufgerundet werden.
Zitat:
Interleaved bezieht sich IMHO nur auf das Display nicht auf die Vorgehensweise wie man darauf malt, d.h. eine 4 Bit masken Zeichenop auf ein Interleaved Schirm wird dennoch 4 Mal durch den Blitter für jede Plane einzeln gemacht und nicht nur in einem Rutsch.
Im Kompatiblitätsmodus ja, d.h. man hat auch weiterhin den Nachteil des Flackern, zusätzlich aber eine Speicherverschwendung bei Masken.

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

[ - Antworten - Zitieren - Direktlink - ]

05.09.2006, 19:38 Uhr

Georg
Posts: 107
Nutzer
Interleavte bitmaps wurden wenn ich mich richtig erinnere in OS 3.x eingeführt. Also vor allem für die AGA Maschinen. Bei Grafikkarten gibts keine interleavte bitmaps. Wie schon gesagt ist der Vorteil, daß statt für jedes Plane den Blitter einzel starten zu müssen, es ausreicht ihn nur einmal zu starten, weil im Speicher die BitMap praktisch so angesehen werden kann, als wäre sie nur ein Plane, halt entsprechend AnzahlPlanes mal höher. Das wurde von vielen guten hardwarenahen Spielen schon Jahre früher benutzt/erfunden.

Und BltMaskBitMapRastPort() braucht bei interleavten BitMaps in der Tat ne andere Mask, die praktisch auch interleavt ist. Jede Mask-Zeile muß AnzahlPlanes mal wiederholt sein.

Also statt

1111
1001
1111

müßte man bei einer 3 bit interleavt bitmap folgende Mask haben

1111
1111
1111
1001
1001
1001
1111
1111
1111

Höchstwahrscheinlich ist das wohl als Bug anzusehen, der übersehen wurde beim Einführen der interleavten BitMaps. Es gibt aber ne Workaround Funktion die Olaf Barthel mal erfunden hat, so daß ne stinknormale 1-Plane Maske auch bei interleavten BitMaps funktioniert:

code:
VOID MyBltMaskBitMap( CONST struct BitMap *srcBitMap, LONG xSrc, LONG ySrc, struct BitMap *destBitMap, LONG xDest, LONG yDest, LONG xSize, LONG ySize, struct BitMap *maskBitMap )
{
  BltBitMap(srcBitMap,xSrc,ySrc,destBitMap, xDest, yDest, xSize, ySize, 0x99,~0,NULL);
  BltBitMap(maskBitMap,xSrc,ySrc,destBitMap, xDest, yDest, xSize, ySize, 0xe2,~0,NULL);
  BltBitMap(srcBitMap,xSrc,ySrc,destBitMap, xDest, yDest, xSize, ySize, 0x99,~0,NULL);
}

ASM void HookFunc_BltMask(REG(a0, struct Hook *hook), REG(a1,struct LayerHookMsg *msg), REG(a2,struct RastPort *rp ))
{
  struct BltMaskHook *h = (struct BltMaskHook*)hook;

  LONG width = msg->bounds.MaxX - msg->bounds.MinX+1;
  LONG height = msg->bounds.MaxY - msg->bounds.MinY+1;
  LONG offsetx = h->srcx + msg->offsetx - h->destx;
  LONG offsety = h->srcy + msg->offsety - h->desty;

#ifdef __SASC
	putreg(REG_A4,(long)hook->h_Data);
#endif

  MyBltMaskBitMap( h->srcBitMap, offsetx, offsety, rp->BitMap, msg->bounds.MinX, msg->bounds.MinY, width, height, &h->maskBitMap);
}

VOID MyBltMaskBitMapRastPort( struct BitMap *srcBitMap, LONG xSrc, LONG ySrc, struct RastPort *destRP, LONG xDest, LONG yDest, LONG xSize, LONG ySize, ULONG minterm, APTR bltMask )
{
    if (GetBitMapAttr(srcBitMap,BMA_FLAGS)&BMF_INTERLEAVED)
    {
	LONG src_depth = GetBitMapAttr(srcBitMap,BMA_DEPTH);
	struct Rectangle rect;
	struct BltMaskHook hook;
		
	/* Define the destination rectangle in the rastport */
	rect.MinX = xDest;
	rect.MinY = yDest;
	rect.MaxX = xDest + xSize - 1;
	rect.MaxY = yDest + ySize - 1;
		
	/* Initialize the hook */
	hook.hook.h_Entry = (HOOKFUNC)HookFunc_BltMask;
#ifdef __SASC
	hook.hook.h_Data = (void*)getreg(REG_A4);
#endif
	hook.srcBitMap = srcBitMap;
	hook.srcx = xSrc;
	hook.srcy = ySrc;
	hook.destx = xDest;
	hook.desty = yDest;
		
	/* Initialize a bitmap where all plane pointers points to the mask */
	InitBitMap(&hook.maskBitMap,src_depth,GetBitMapAttr(srcBitMap,BMA_WIDTH),GetBitMapAttr(srcBitMap,BMA_HEIGHT));
	while (src_depth)
	    hook.maskBitMap.Planes[--src_depth] = bltMask;

	/* Blit onto the Rastport */
	DoHookClipRects(&hook.hook,destRP,&rect);
    } else
    {
	BltMaskBitMapRastPort(srcBitMap, xSrc, ySrc, destRP, xDest, yDest, xSize, ySize, minterm, bltMask);
    }
}

#endif



[ - Antworten - Zitieren - Direktlink - ]

05.09.2006, 19:46 Uhr

Georg
Posts: 107
Nutzer
Zitat:
Original von whose:
Zitat:
Original von bubblebobble:
Und benutzt jemand tatsächlich interleaved Bitmaps, oder ist das mehr eine teoretische Diskussion ?


Das ist wohl eher theoretisch. Benutzt wurde dieses Feature wohl hauptsächlich für Spiele, mit OS-Mitteln angelegte Screens sind nicht "von Haus aus" interleaved.


Hmm ... also wenn ich mich nicht arg täusche ist auf AGA Maschinen der WB Screen generell interleavt. SA_LikeWorkbench screens dann wohl auch.



[ - Antworten - Zitieren - Direktlink - ]

05.09.2006, 19:58 Uhr

thomas
Posts: 7675
Nutzer

So gut wie jedes Szene-Demo benutzt interleaved Bitmaps, weil man da mit einem Blit alle Bitplanes ändert. Bei non-interleaved Bitmaps muß man für jede Bitplane einen Blit anstoßen und dabei kommen dann die lustigen bunten Blinkeffekte heraus. Das ist bei einer GUI vielleicht akzeptabel, aber bei Animationen äußerst störend.

Gruß Thomas

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

[ - Antworten - Zitieren - Direktlink - ]

05.09.2006, 20:04 Uhr

bubblebobble
Posts: 707
Nutzer
@Thomas

Wenn man doppelt puffert ist das egal mit dem flickern.


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


[ - Antworten - Zitieren - Direktlink - ]

05.09.2006, 20:08 Uhr

whose
Posts: 2156
Nutzer
Zitat:
Original von Holger:
Zitat:
Original von whose:
Nein, gar nicht. Beachte das (an und für sich unbedeutende) Wörtchen "Dimensions", dann kennst Du den Grund. Eine Interleaved-Bitmap von 4Bit Tiefe ist im Speicher 4 mal "höher" als die letztlich resultierende Pixelmenge. Die Maske paßt dann zwar in der Breite, aber die "Zwischenzeilen" würden fehlen, wenn die Maske nicht 4 mal "höher" wäre.

Das ist eine interessante neue Interpretation der bytesPerRow Eigenschaft. Ich hätte bislang immer vermutet, dass solche BitMaps, bzw. deren Planes, n mal breiter sind.

Im Speicher ja. Wenn man versucht, sich das "bildhaft" vorzustellen mit dem Interleaved, sehen einige Menschen das vielleicht etwas anders als Du. Ich z.B. sehe das lieber als "höher" (man beachte die ""), weil es so anschaulicher ist.

Zitat:
Zitat:
Da arbeitet der Blitter ja auch bei der Quellbitmap quasi auf Bitebene und nicht auf Byte- oder Halbbyte-Ebene, wie bei non-interleaved Bitmaps.
Hä?
Der Blitter arbeitet immer wortweise, meinethalben auch mit bitweiser Verknüpfung, aber definitiv immer auf die gleiche Weise.


Ich meinte auch die Art der Verknüpfung. Evtl. hätte ich ein "beispielsweise" einfügen sollen...

Zitat:
Zitat:
Das ist wohl eher theoretisch. Benutzt wurde dieses Feature wohl hauptsächlich für Spiele, mit OS-Mitteln angelegte Screens sind nicht "von Haus aus" interleaved.
Also meine Workbench ist es.
Und ich tendiere eher zu der Meinung, dass dies bei OS3.0+/AGA der default ist.


Autodocs, intuition/screens.h, Tag SA_INTERLEAVED. Defaults to: FALSE.

Wäre auch reichlich gemein, wo das doch ein "New for OS3.1/AGA"-Feature ist, wenn es Default wäre. Das würde alle Programme, die den Blitter benutzen und Bitmaps für Blitmasken auf dem OS1.x-Weg anlegen, vor die Wand rennen lassen.

Meines Wissens nach läuft die Workbench auch auf einem normalen Screen, wenn nicht dran "gedreht" wurde. Überprüfen kann man das mit Darius' Hinweis auf das "Flackern" (bei hoher Farbtiefe), ohne großen Aufwand. Flackert ein normalgroßes Piktogramm beim Anklicken (ggf. mal auf mehr als 32 Farben stellen), ist es definitiv nicht interleaved.

Grüße

--
---

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

[ - Antworten - Zitieren - Direktlink - ]

05.09.2006, 20:15 Uhr

whose
Posts: 2156
Nutzer
@Georg:

Ah, danke für den Code von Olaf. Den hatte ich bei meiner Verzweiflung bezüglich der Blitterei per Google mal gefunden und der war sehr hilfreich.

Soweit ich weiß, ist dieses Problem von AllocBitmap() mit OS3.9 (oder sogar 3.5? Weiß ich gar nicht so genau) behoben worden. Bei mir liefs jedenfalls ohne den Trick, und an einen Zufall glaube ich dabei nicht, auch wenn ich das nur ein Mal getestet habe.

Grüße

--
---

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

[ - Antworten - Zitieren - Direktlink - ]

05.09.2006, 20:21 Uhr

DariusBrewka
Posts: 899
[Benutzer gesperrt]
Zitat:
Original von whose:
Meines Wissens nach läuft die Workbench auch auf einem normalen Screen, wenn nicht dran "gedreht" wurde. Überprüfen kann man das mit Darius' Hinweis auf das "Flackern" (bei hoher Farbtiefe), ohne großen Aufwand. Flackert ein normalgroßes Piktogramm beim Anklicken (ggf. mal auf mehr als 32 Farben stellen), ist es definitiv nicht interleaved.


??? Also da ist mir schon der Aufwand zu hoch den ScreenSelector aufzurufen um einen AGA/ECS Screen zu öffnen. Wie Georg schon erwähnt hat, wird es wohl so vorgesehen sein dass man die Zeilen doppelt für Masken, aber glücklich ist das IMHO nicht insbesondere dann wenn man Systemfunktionen hat, die Masken liefern (z.B. IconControl()).
Damit brauchen Masken für Interleaved Images ebenso viel Speicher wie das Image selber, dann lieber ARGB.

[ - Antworten - Zitieren - Direktlink - ]

05.09.2006, 20:32 Uhr

whose
Posts: 2156
Nutzer
Zitat:
Original von DariusBrewka:
Zitat:
Original von whose:
Meines Wissens nach läuft die Workbench auch auf einem normalen Screen, wenn nicht dran "gedreht" wurde. Überprüfen kann man das mit Darius' Hinweis auf das "Flackern" (bei hoher Farbtiefe), ohne großen Aufwand. Flackert ein normalgroßes Piktogramm beim Anklicken (ggf. mal auf mehr als 32 Farben stellen), ist es definitiv nicht interleaved.


??? Also da ist mir schon der Aufwand zu hoch den ScreenSelector aufzurufen um einen AGA/ECS Screen zu öffnen. Wie Georg schon erwähnt hat, wird es wohl so vorgesehen sein dass man die Zeilen doppelt für Masken, aber glücklich ist das IMHO nicht insbesondere dann wenn man Systemfunktionen hat, die Masken liefern (z.B. IconControl()).


Die sollten normalerweise die korrekten Masken liefern. Ich hab mich mit den Icon-Funktionen noch nicht beschäftigt. Haben die denn kein Argument alá Friend bei AllocBitmap()? Also eine Angabe, für welchen Screen man die Maske gerne hätte?

Wenn nicht, was spricht dagegen, die Maske in eine dem Screen angepaßte Bitmap "vorzublitten", bevor man sie benutzt? Dabei sollte sie ins passende Format konvertiert werden (unter OS3.5+ oder 3.9). Okay, ist mehr Aufwand, aber den hat man eigentlich immer, wenn man die älteren OS-Versionen noch berücksichtigen möchte...

Zitat:
Damit brauchen Masken für Interleaved Images ebenso viel Speicher wie das Image selber, dann lieber ARGB.

Naja, einen Nachteil muß die Methode haben. Es gibt halt eher selten etwas, das nur Vorteile hat. Abgesehen davon muß man ja nicht zwingend mit Interleaved-Screens arbeiten, wenns ums Speicher sparen geht. Im Grunde hast Du aber Recht, die Planargrafik war letztendlich nicht der Weisheit letzter Schluß. Und AAA sollte ja Chunky-Grafik bringen, die wir nun mit den GraKas haben.

Grüße

--
---

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

[ - Antworten - Zitieren - Direktlink - ]

05.09.2006, 20:39 Uhr

Holger
Posts: 8089
Nutzer
Zitat:
Original von whose:
Autodocs, intuition/screens.h, Tag SA_INTERLEAVED. Defaults to: FALSE.

Ja, aber Du kannst der AOS3.x Workbench ruhig zutrauen, das Tag mit einem anderen Wert an OpenScreen zu übergeben. Oder hast Du nur das mit dem default (für die Workbench!) missverstanden?
Zitat:
Wäre auch reichlich gemein, wo das doch ein "New for OS3.1/AGA"-Feature ist, wenn es Default wäre. Das würde alle Programme, die den Blitter benutzen und Bitmaps für Blitmasken auf dem OS1.x-Weg anlegen, vor die Wand rennen lassen.
Da würde ja lediglich Blits mit dem Screen als Quelle betreffen (die eher die Ausnahme sind). Und wenn man bytesPerRow korrekt berücksichtigt, gibt es die Probleme ja gar nicht. Aber CustomScreens haben trotzdem den default {SA_INTERLEAVED, FALSE}.
Zitat:
Meines Wissens nach läuft die Workbench auch auf einem normalen Screen, wenn nicht dran "gedreht" wurde. Überprüfen kann man das mit Darius' Hinweis auf das "Flackern" (bei hoher Farbtiefe), ohne großen Aufwand. Flackert ein normalgroßes Piktogramm beim Anklicken (ggf. mal auf mehr als 32 Farben stellen), ist es definitiv nicht interleaved.
Bei mir flackert nichts. Aber ich verlass mich trotzdem lieber auf das, was ich aus der BitMap auslese: interleaved.

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

[ - Antworten - Zitieren - Direktlink - ]

05.09.2006, 20:42 Uhr

Holger
Posts: 8089
Nutzer
Zitat:
Original von whose:
Die sollten normalerweise die korrekten Masken liefern. Ich hab mich mit den Icon-Funktionen noch nicht beschäftigt. Haben die denn kein Argument alá Friend bei AllocBitmap()? Also eine Angabe, für welchen Screen man die Maske gerne hätte?

Wozu?
Die Maske muss korrekt an die QuellBitMap angepasst sein, also die des Icons.

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

[ - Antworten - Zitieren - Direktlink - ]

05.09.2006, 20:44 Uhr

Holger
Posts: 8089
Nutzer
Zitat:
Original von thomas:
So gut wie jedes Szene-Demo benutzt interleaved Bitmaps, weil man da mit einem Blit alle Bitplanes ändert.

Aber Szene-Demos benutzen selten OS-Funktionen. Na ja, und wer explizit interleaved BitMaps anlegt, sollte sich auch der Konsequenzen bewusst sein.

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

[ - Antworten - Zitieren - Direktlink - ]

05.09.2006, 20:47 Uhr

whose
Posts: 2156
Nutzer
Zitat:
Original von Holger:
Zitat:
Original von whose:
Autodocs, intuition/screens.h, Tag SA_INTERLEAVED. Defaults to: FALSE.

Ja, aber Du kannst der AOS3.x Workbench ruhig zutrauen, das Tag mit einem anderen Wert an OpenScreen zu übergeben. Oder hast Du nur das mit dem default (für die Workbench!) missverstanden?

Anscheinend. Ich dachte, Du meintest als Screen-Default.

Zitat:
Zitat:
Wäre auch reichlich gemein, wo das doch ein "New for OS3.1/AGA"-Feature ist, wenn es Default wäre. Das würde alle Programme, die den Blitter benutzen und Bitmaps für Blitmasken auf dem OS1.x-Weg anlegen, vor die Wand rennen lassen.
Da würde ja lediglich Blits mit dem Screen als Quelle betreffen (die eher die Ausnahme sind). Und wenn man bytesPerRow korrekt berücksichtigt, gibt es die Probleme ja gar nicht. Aber CustomScreens haben trotzdem den default {SA_INTERLEAVED, FALSE}.

Hm, das würde also bedeuten, daß Programme, die auf der WB laufen und innerhalb ihres Fensters mittels Blitter und Blitmaske z.B. Grafik "verschieben", versagen, sofern sie auf "altväterlichem" Weg die Maske anlegen? Wenn ja, sollte ich mir das dringend notieren, weil ich so ein Programm in Arbeit habe, das evtl. auch auf OS3.0/3.1 laufen soll...

Grüße

--
---

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

[ - Antworten - Zitieren - Direktlink - ]

05.09.2006, 20:48 Uhr

DariusBrewka
Posts: 899
[Benutzer gesperrt]
Zitat:
Original von thomas:

So gut wie jedes Szene-Demo benutzt interleaved Bitmaps, weil man da mit einem Blit alle Bitplanes ändert. Bei non-interleaved Bitmaps muß man für jede Bitplane einen Blit anstoßen und dabei kommen dann die lustigen bunten Blinkeffekte heraus. Das ist bei einer GUI vielleicht akzeptabel, aber bei Animationen äußerst störend.


Das auch, aber ein anderer Grund ist das man mit Interleaved Maps Asynchron arbeiten kann, d.h. ich stoße den Blitter einmal an und arbeite weiter mit der CPU, das geht mit Non-Interleaved nicht, da man mindestens zwischen den einzelnen Planes warten muß, bei Interleaved braucht man nur vor der nächsten Blitter-OP zu testen ob der Blitter fertig ist. Ich denke das war mit ein Grund dafür diese Art von Maps einzuführen, man denke nur wie langsam AGA ist bei 8BIT, so kann die CPU wenigstens zwischenzeitig was machen.

Ich habe anfang der 90er auch Demos etc. gemacht wenn auch schlechte, aber ein wenig Ahnung hatte ich schon.


[ - Antworten - Zitieren - Direktlink - ]

05.09.2006, 20:50 Uhr

whose
Posts: 2156
Nutzer
Zitat:
Original von Holger:
Zitat:
Original von whose:
Die sollten normalerweise die korrekten Masken liefern. Ich hab mich mit den Icon-Funktionen noch nicht beschäftigt. Haben die denn kein Argument alá Friend bei AllocBitmap()? Also eine Angabe, für welchen Screen man die Maske gerne hätte?

Wozu?
Die Maske muss korrekt an die QuellBitMap angepasst sein, also die des Icons.


Argh... ja, ich mal wieder... :D

Dann verstehe ich Darius' Probleme mit den Icon-Masken allerdings nicht.

Grüße

--
---

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

[ - Antworten - Zitieren - Direktlink - ]

05.09.2006, 20:58 Uhr

DariusBrewka
Posts: 899
[Benutzer gesperrt]
Zitat:
Original von whose:

Wenn nicht, was spricht dagegen, die Maske in eine dem Screen angepaßte Bitmap "vorzublitten", bevor man sie benutzt? Dabei sollte sie ins passende Format konvertiert werden (unter OS3.5+ oder 3.9). Okay, ist mehr Aufwand, aber den hat man eigentlich immer, wenn man die älteren OS-Versionen noch berücksichtigen möchte...


das VOID in der Funktion
code:
VOID DrawIconStateA(struct RastPort *rp,struct DiskObject *icon,
	                    STRPTR label,LONG leftEdge,LONG topEdge,
	                    ULONG state,struct TagItem *tags);


spricht für Mich eindeutig dagegen. Schliesslich will man wenn man etwas aufruft auch wissen dass es entweder Funktioniert oder zumindestens einen Fehler zurückliefert, so erwate ich es jedenfalls und für mich erfordert ein vorblitten etwas worein ich es Blitte: Speicher!

[ - Antworten - Zitieren - Direktlink - ]

05.09.2006, 21:03 Uhr

whose
Posts: 2156
Nutzer
@DariusBrewka:

Ich glaube, nun hab ichs, worauf Du hinauswillst. Die Tatsache, daß die Vor-OS3.5-Icons keine Maske "transportieren", oder?

Grüße

--
---

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

[ - Antworten - Zitieren - Direktlink - ]

05.09.2006, 21:19 Uhr

DariusBrewka
Posts: 899
[Benutzer gesperrt]
Zitat:
Original von whose:
@DariusBrewka:

Ich glaube, nun hab ichs, worauf Du hinauswillst. Die Tatsache, daß die Vor-OS3.5-Icons keine Maske "transportieren", oder?


Nee, wie kommst du darauf? Ich wollte mit dem Icon zeux nur zeigen das Funktionen Quark sind die Masken liefern, da die Masken wie es wohl sein wird Ursprünglich verschieden sind ob man Interleaved Targets oder nicht hat. Wenn ich jetzt eine solche Maske habe und Beispielweise auf eine 3.x WB (defaultmäßig Interleaved) blitte müßte ich ein anderes Resultat erhalten als wenn ich auf einen NON-Interleaved Screen blitte. Daraus habe Ich den Schluß gezogen dass die Masken gleich sein müssen, ansonsten müsste man immer mit angeben ob man Interleaved oder Nichtinterleaved Masken haben will, das Kann ich NICHT, d.h. die Maske wird in einem beider Formate geliefert. Ich kann das Image aber mit DrawIconStateA() etc malen und diese Funktioniert auf jedem Screen / RastPort, da diese Funktion nichts umblitten kann (s.o.) und BltMaskBitMapXXX() auch nicht funktioniert, muß diese das Bild irgendwie per Hand maskieren.

[ - Antworten - Zitieren - Direktlink - ]

05.09.2006, 21:30 Uhr

Holger
Posts: 8089
Nutzer
Zitat:
Original von DariusBrewka:
Ich wollte mit dem Icon zeux nur zeigen das Funktionen Quark sind die Masken liefern, da die Masken wie es wohl sein wird Ursprünglich verschieden sind ob man Interleaved Targets oder nicht hat.

Die Masken sind aber nicht vom Target abhängig, somit kann man doch Funktionen implementieren, die eine Maske zurückliefern.

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

[ - Antworten - Zitieren - Direktlink - ]

05.09.2006, 21:33 Uhr

whose
Posts: 2156
Nutzer
Zitat:
Original von DariusBrewka:
Zitat:
Original von whose:
@DariusBrewka:

Ich glaube, nun hab ichs, worauf Du hinauswillst. Die Tatsache, daß die Vor-OS3.5-Icons keine Maske "transportieren", oder?


Nee, wie kommst du darauf? Ich wollte mit dem Icon zeux nur zeigen das Funktionen Quark sind die Masken liefern, da die Masken wie es wohl sein wird Ursprünglich verschieden sind ob man Interleaved Targets oder nicht hat. Wenn ich jetzt eine solche Maske habe und Beispielweise auf eine 3.x WB (defaultmäßig Interleaved) blitte müßte ich ein anderes Resultat erhalten als wenn ich auf einen NON-Interleaved Screen blitte. Daraus habe Ich den Schluß gezogen dass die Masken gleich sein müssen, ansonsten müsste man immer mit angeben ob man Interleaved oder Nichtinterleaved Masken haben will, das Kann ich NICHT, d.h. die Maske wird in einem beider Formate geliefert. Ich kann das Image aber mit DrawIconStateA() etc malen und diese Funktioniert auf jedem Screen / RastPort, da diese Funktion nichts umblitten kann (s.o.) und BltMaskBitMapXXX() auch nicht funktioniert, muß diese das Bild irgendwie per Hand maskieren.


Ach so... ja, in die Falle laufe ich auch dauernd. Holger sagte es mir ja schon: Wichtig ist die Auslegung der Quell-Bitmap, nicht die des Ziels. Also sind die von den Icon-Funktionen gelieferten Masken schon korrekt und sollten die richtigen Ergebnisse beim Blitten bringen.

Das Problem "Interleaved" stellt sich immer dann, wenn man innerhalb einer Bitmap "herumblittet" und die Quelle sowie die dazugehörige Maske nicht "selbst gebaut" hat bzw. die Maske zu der "fremden" Quelle bauen muß.

Grüße

--
---

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

[ - Antworten - Zitieren - Direktlink - ]

05.09.2006, 21:39 Uhr

Holger
Posts: 8089
Nutzer
Zitat:
Original von whose:
Hm, das würde also bedeuten, daß Programme, die auf der WB laufen und innerhalb ihres Fensters mittels Blitter und Blitmaske z.B. Grafik "verschieben", versagen, sofern sie auf "altväterlichem" Weg die Maske anlegen? Wenn ja, sollte ich mir das dringend notieren, weil ich so ein Programm in Arbeit habe, das evtl. auch auf OS3.0/3.1 laufen soll...


Nur, wenn die BltMaskBitMapRastPort-Funktion nicht so arbeitet wie früher, bzw. spezifiert.

Anders gesagt:
Georg schrieb:
Zitat:
Und BltMaskBitMapRastPort() braucht bei interleavten BitMaps in der Tat ne andere Mask, die praktisch auch interleavt ist. Jede Mask-Zeile muß AnzahlPlanes mal wiederholt sein.

Also statt

1111
1001
1111

müßte man bei einer 3 bit interleavt bitmap folgende Mask haben

1111
1111
1111
1001
1001
1001
1111
1111
1111


Genau das wäre inkompatibel. Aber wenn man sich stur an die Spezifikation und OS1.x/2.x Vorgehensweise halten würde, würde man die bytesPerRow-Zahl beachten und statt,

1111
1001
1111

eine Maske anlegen, die so aussieht:

1111
....
....
1001
....
....
1111
....
....

Also eigentlich so:

1111........
1001........
1111........

Die Punkte sind dabei Bits mit ignorierbaren Inhalt. Wenn die BltMaskBitMapRastPort() Funktion kompatibel arbeitet, müsste das auch funktionieren.

Der von Georg gepostete workaround wäre dann weiterhin sinnvoll. Nämlich genau dann, wenn man Masken benutzen will, die keinen Speicher verschwenden.

Ich vermute, dass die Funktion kompatibel arbeitet, weil das einfach zu implementieren wäre. Aber ich habe es nicht ausprobiert.

mfg
--

[ Dieser Beitrag wurde von Holger am 05.09.2006 um 21:51 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

05.09.2006, 21:57 Uhr

whose
Posts: 2156
Nutzer
@Holger:

Sorry, so ganz kann ich das nicht nachvollziehen mit der "Inkompatibilität" von BltBitMapRastPort(). Für mich klingt es logischer, daß auch die Maske etwas anders aussehen muß, wenn der Blitter auf andere Art arbeitet.

Es würde z.B. für mich keinen echten Sinn ergeben, wenn der Blitter für jede Quellplane stur die jeweils erste Zeile (also quasi nur Plane 0) der Maske benutzen würde, das wäre eher ein Nachteil. Auf dem anderen Weg kann man "ganz nebenbei" noch andere (nicht nur unerwünschte) Effekte erzielen, indem man die "überflüssigen" Zeilen der Maske verändert. So muß man nicht an der Quelle "schrauben", bevor man den Blit einleitet.

Die Inkompatibilitäten kommen ja eigentlich "nur" dadurch, daß man beim OS zu spät daran gedacht hat, daß es auch andere Bitmap-Formate geben könnte als Planar non-interleaved.

Soweit ich das gelesen habe damals ist dieser Workaround auch nur für ein Problem mit AllocRaster()/AllocBitmap() gedacht, die es "verschlafen", die gewünschte Bitmap interleaved anzulegen (falls falsch, möge man mich korrigieren).

Die Speicherersparnis wird ja auch mit einem gewissen Flicker-Risiko erkauft, da immer noch drei Blits fällig sind.

Grüße

--
---

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


[ Dieser Beitrag wurde von whose am 05.09.2006 um 22:21 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

05.09.2006, 22:52 Uhr

DariusBrewka
Posts: 899
[Benutzer gesperrt]
gelöscht, jetzt hab Ich's verstanden.

[ Dieser Beitrag wurde von DariusBrewka am 05.09.2006 um 22:54 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

05.09.2006, 23:12 Uhr

DariusBrewka
Posts: 899
[Benutzer gesperrt]
@Holger

Irgendwie verstehe Ich nicht was du mit deinem letzten Posting sagen willst.

Wenn man Hardwaretechnisch mit einem einziegen Blitt auskommen will, muß eine Maske für Interleaved Maps genau das gleiche Format haben wie das Image selber, bzw. solange man einfach nur dafür nicht mehr als die Adresse dieser Maske angibt, d.h. jede Zeile muß auf Wortgrenze liegen und für jede Plane muß für jede Zeile eine Zeile in der Maske vorhanden sein, die in jeder Zeile gleich ist.

Vieleicht meinst du auch Folgendes, wenn man die Blitter Register vernünftig setzt, dann ist eine Normale Maske gleich einer Maske die DEPTH mal so viele Zeilen, bzw Spalten hat, die überflüssigen Bytes würden einfach nicht berücksichtigt. Dass heißt aber das BltMaskBitMapXXX() funktioniert sowohl mit Interleaved als auch mit NonInterleaved maps, kommat aber Hardwaremäßig nicht mit einem einzigen Blitt aus.

[ - Antworten - Zitieren - Direktlink - ]

06.09.2006, 10:01 Uhr

gni
Posts: 1106
Nutzer
Zitat:
whose:
Obwohls wohl mal zu Anfangszeiten eine GraKa mit Planar-Modus gab, ich weiß aber nicht mehr, welche das war... eine der ersten GVP-Karten, glaube ich. Aber ich glaube nicht, daß es dafür einen CGFX-/P96-Treiber gibt.

Der Grafikchip der PIV (CL5446) hat einen Planarmodus und den kann man mit P96 auch problemlos benutzen.

[ - Antworten - Zitieren - Direktlink - ]

06.09.2006, 10:56 Uhr

whose
Posts: 2156
Nutzer
@gni:

Ah so, das wußte ich nicht. Immerhin... aber einen Interleaved-Modus wirds da eher nicht geben, denke ich?

Grüße

--
---

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

[ - Antworten - Zitieren - Direktlink - ]

06.09.2006, 14:38 Uhr

Georg
Posts: 107
Nutzer
Zitat:
Original von gni:
Der Grafikchip der PIV (CL5446) hat einen Planarmodus und den kann man mit P96 auch problemlos benutzen.


Planare Modi müßten eigentlich bei allen Grafikkarten da sein. Der standard 640 x 480 x 16 Farben VGA Modus ist so ein planarer Mode. Die Planes sind im Speicher dabei auch so wie beim Amiga (also nicht z. B. wie beim Atari ST oder bei diesen komischenen Planaren Chunky Modes). Der AROS vga.hidd Treiber benutzt den Modus (weil er immer vorhanden sein sollte). Im Treiber intern wird aus Geschwindigkeitsgründen und wohl auch ein wenig Faulheit alles in nen RAM chunky buffer gerendert und Änderungen dann per chunky 2 planar ins VRAM übertragen.

[ - Antworten - Zitieren - Direktlink - ]

06.09.2006, 14:47 Uhr

Georg
Posts: 107
Nutzer
Zitat:
Original von Holger:

Also eigentlich so:

1111........
1001........
1111........


Nein. Wenn alle Planes auf einmal geblittet werden sollen, dann geht das nicht. Denn alle Blitterquellen zählen ja alle jedesmal um ein WORD hoch und die Masken-Quelle würde dann in die "." reinlaufen und für die Planes [2 bis Anzahlplanes] nicht richtig sein.

Wenn die Planes einzeln geblittet werden, was natürlich auch bei interleavten BitMaps möglich ist, dann könnte die Maske ruhig so sein, aber sie muß es nicht. Die "." brauchts nicht, weil die einzelnen Blitterquellen jeweils eigene Blitter Moduli (wie viele Bytes nach jeder Zeile überspringen) haben. Für die Grafikdaten Blitter Quelle würde man den Modulo so setzen, daß die anderen Planes übersprungen werden. Aber für die Maskdaten Blitter Quelle würde der Modulo kleiner sein, weil es diese interleavten anderen Planes nicht gibt.



[ - Antworten - Zitieren - Direktlink - ]


1 2 3 -4- 5 6 [ - Beitrag schreiben - ]


amiga-news.de Forum > Programmierung > Bitmaps nur durch 16 teilbare Breite? [ - Suche - Neue Beiträge - Registrieren - Login - ]


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