Fragen zu Raster- und Blitterbeschränkungen

amiga-news.de Forum > Programmierung > Fragen zu Raster- und Blitterbeschränkungen

[ - Search - New posts - Register - Login - ]

-1-

[ - Post reply - ]

2008-05-09, 23:05 h

NoImag
Posts: 1050
User

Hallo!

In den RKRM steht, dass bei OCS ein Raster maximal 1024x1024 Pixel und bei ECS maximal 16384x16384 Pixel groß sein kann. Was ist hier mit Raster gemeint, Screens? Oder gilt dies auch für nicht sichtbare Rastports?

In den RKRM steht, dass der Blitter bei OCS maximal 992x1024 Pixel und bei ECS 32736x32768 Pixel handhaben kann. In den Autodocs bei BltBitMap() steht jedoch 976x1023 als maximale Größe. Was stimmt jetzt?

Bei ClipBlit() wird nur die minimale Größe (1x1) aber keine maximale Größe genannt. Gibt es eine Beschränkung? Bei den anderen Blit-Funktionen gibt es überhaupt keine Angaben.

Was gilt bei CyberGraphX und Picasso96?

Tschüß

[ - Answer - Quote - Direct link - ]

2008-05-10, 00:29 h

whose
Posts: 2156
User

Zitat:
Original von NoImag:
Hallo!

In den RKRM steht, dass bei OCS ein Raster maximal 1024x1024 Pixel und bei ECS maximal 16384x16384 Pixel groß sein kann. Was ist hier mit Raster gemeint, Screens?

Mit Raster ist soweit ich weiß die Menge der Pixel einer Plane gemeint und die da angegebene Pixelzahl ist die Menge, die der Blitter in einem Arbeitsgang verarbeiten kann. Das ergibt sich aus der "Breite" der BltSize-"Register", die bei ECS erweitert wurden. Steigt die Anzahl der Planes, die bei einem Blit zu bearbeiten sind, verringert sich das entsprechend in Bezug auf die Zeilenzahl (Zeilen / Anzahl der Planes, interleaved) oder es sind "Planes" Durchgänge nötig, die dann jeweils in voller Größe geblittet werden können.

Theoretisch können Raster beliebig groß sein, es macht aber in Bezug auf den Blitter bzw. dessen Fähigkeiten einfach keinen Sinn.

Edit: Mal eine Frage, wo hast Du die 16k * 16k Größe eines Raster gefunden? Entweder, das ist ein Fehler oder Du warst da wieder bei Funktionen der graphics.library, ohne es zu sagen

Dann wüßte ich aber jetzt auf Anhieb nicht, auf welche Funktion sich diese Angabe bezieht. Die Hardware kann 32k * 32k Pixel auf einen Rutsch bearbeiten.

Zitat:
Oder gilt dies auch für nicht sichtbare Rastports?

Das gilt für alle Daten, die sich im ChipRAM befinden, somit auch für "unsichtbare" Raster. Du solltest aber die Hardware-Beschreibung nicht mit den Funktionsbeschreibungen der graphics.libary verwürfeln, da gibt es schon noch Unterschiede.

Ein RastPort ist übrigens etwas anderes als ein Raster, RastPort ist eine Beschreibung für verschiedene Vorgänge, die auf einer BitMap durchführbar sind. Dazu zählen auch Angaben über aktive und inaktive Planes, weshalb oft ein RastPort als Ziel oder Quelle für die Blitfunktionen angegeben werden muß.

Zitat:
In den RKRM steht, dass der Blitter bei OCS maximal 992x1024 Pixel und bei ECS 32736x32768 Pixel handhaben kann. In den Autodocs bei BltBitMap() steht jedoch 976x1023 als maximale Größe. Was stimmt jetzt?

Das meinte ich, reine Hardwarefunktionalität ist schon noch klein wenig anders als die der graphics.library

Im Zweifel würde ich hier den AutoDocs Vorrang geben, vor allem, wenn die moderner als die RKMs sind. Die Limits habe ich selbst aber nie überprüft, in der Größenordnung mußte ich noch nie etwas blitten mit dem OCS.

Zitat:
Bei ClipBlit() wird nur die minimale Größe (1x1) aber keine maximale Größe genannt. Gibt es eine Beschränkung? Bei den anderen Blit-Funktionen gibt es überhaupt keine Angaben.

Ich würde jetzt einfach mal so behaupten, daß sich die Maximalgröße für ClipBlit() aus den Größen ableitet, die für BltBitMap() in den AutoDocs genannt werden. Funktional ist ClipBlit() ein Blit mit Koordinatenclipping, das würde bedeuten, daß man das Koordinatenclipping maximal auf die Größe ausdehnen kann, die die Hardware (OCS) vorgibt. Ob das so pauschal stimmt kann ich aber nicht definitiv sagen.

Die Minimalgröße ergibt sich daraus, daß der Blitter nicht mit NIL arbeiten mag. Ein Pixel sollte man schon bearbeiten, wenn man das Biest weckt

Zitat:
Was gilt bei CyberGraphX und Picasso96?

Das ist eine gute Frage... wirklich Aufklärung darüber bekommt man ja leider nicht, genausowenig wie Informationen darüber, welcher Treiber welche Blits in Hardware unterstützt und welche Funktionalität rein in Software nachgebildet wird. Bei Softwarenachbildungen wäre die max. Blitgröße eigentlich unbegrenzt, aber aufgrund von Buslimits, Alignment-Vorteilen, Segmentierung usw. usf. wird das wahrscheinlich von Hardware zu Hardware variieren. Das dürfte auch der Grund sein, weshalb man nirgendwo definitive Limits findet.

Grüße

--
---

µA1 PPC 750GX-800

A4000 PPC 604e-233

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

[ - Answer - Quote - Direct link - ]

2008-05-10, 23:17 h

NoImag
Posts: 1050
User

Zitat:
Original von whose:

Zitat:
Original von NoImag:
Hallo!

In den RKRM steht, dass bei OCS ein Raster maximal 1024x1024 Pixel und bei ECS maximal 16384x16384 Pixel groß sein kann. Was ist hier mit Raster gemeint, Screens?

Mit Raster ist soweit ich weiß die Menge der Pixel einer Plane gemeint und die da angegebene Pixelzahl ist die Menge, die der Blitter in einem Arbeitsgang verarbeiten kann. Das ergibt sich aus der "Breite" der BltSize-"Register", die bei ECS erweitert wurden. Steigt die Anzahl der Planes, die bei einem Blit zu bearbeiten sind, verringert sich das entsprechend in Bezug auf die Zeilenzahl (Zeilen / Anzahl der Planes, interleaved) oder es sind "Planes" Durchgänge nötig, die dann jeweils in voller Größe geblittet werden können.

Theoretisch können Raster beliebig groß sein, es macht aber in Bezug auf den Blitter bzw. dessen Fähigkeiten einfach keinen Sinn.

Edit: Mal eine Frage, wo hast Du die 16k * 16k Größe eines Raster gefunden? Entweder, das ist ein Fehler oder Du warst da wieder bei Funktionen der graphics.library, ohne es zu sagen Dann wüßte ich aber jetzt auf Anhieb nicht, auf welche Funktion sich diese Angabe bezieht. Die Hardware kann 32k * 32k Pixel auf einen Rutsch bearbeiten.

Da ich nicht direkt die Hardware programmiere, beziehe ich mich immer auf die graphics.library. Die Angaben stammen aus dem Libraries-Manual, Graphics Primitives, About ECS, Determining Chip Versions: "The ECS Agnus can handle rasters up to 16,384 by 16,384 pixels."

Meine Frage, ob damit Screens gemeint sind, kommt daher, weil im ScreenMode-Voreinsteller alle AGA-Modes eine maximale Screengröße von 16384x16384 erlauben.

Zitat:
Zitat:
Oder gilt dies auch für nicht sichtbare Rastports?

Ein RastPort ist übrigens etwas anderes als ein Raster, RastPort ist eine Beschreibung für verschiedene Vorgänge, die auf einer BitMap durchführbar sind. Dazu zählen auch Angaben über aktive und inaktive Planes, weshalb oft ein RastPort als Ziel oder Quelle für die Blitfunktionen angegeben werden muß.

Ich habe in den RKRMs keine Definition für Raster gefunden, die mit den sonstigen Begriffen des AmigaOS (View, Viewport, Rastport, Bitmap, etc) verknüpft ist. Daher war mir nicht klar, was mir die Aussage, ein Raster kann maximal so und so groß sein, in der Praxis sagt. Wenn also ein Raster maximal 1024x1024 Pixel groß sein kann, kann ich dann einen Rastport (nicht sichtbare Bitmap mit manuell erzeugtem Rastport) mit einer Breite von 32768 erzeugen und immer noch mit den Funktionen der graphics.library dadrin zeichnen und blitten? (Bisher mache ich sowas, unten mehr)

Zitat:
Zitat:
In den RKRM steht, dass der Blitter bei OCS maximal 992x1024 Pixel und bei ECS 32736x32768 Pixel handhaben kann. In den Autodocs bei BltBitMap() steht jedoch 976x1023 als maximale Größe. Was stimmt jetzt?

Das meinte ich, reine Hardwarefunktionalität ist schon noch klein wenig anders als die der graphics.library Im Zweifel würde ich hier den AutoDocs Vorrang geben, vor allem, wenn die moderner als die RKMs sind. Die Limits habe ich selbst aber nie überprüft, in der Größenordnung mußte ich noch nie etwas blitten mit dem OCS.

Die Angaben stammen aus dem Libraries-Manual, Graphics Primitives, Drawing Routines, Performing Data Move Operations, Copying Rectangular Areas, Abschnitt mit der Beschreibung von BltBitMap(). Ich würde erwarten, dass dieser Abschnitt keine anderen Angaben enthält, als die Autodocs.

Zitat:
Zitat:
Bei ClipBlit() wird nur die minimale Größe (1x1) aber keine maximale Größe genannt. Gibt es eine Beschränkung? Bei den anderen Blit-Funktionen gibt es überhaupt keine Angaben.

Ich würde jetzt einfach mal so behaupten, daß sich die Maximalgröße für ClipBlit() aus den Größen ableitet, die für BltBitMap() in den AutoDocs genannt werden. Funktional ist ClipBlit() ein Blit mit Koordinatenclipping, das würde bedeuten, daß man das Koordinatenclipping maximal auf die Größe ausdehnen kann, die die Hardware (OCS) vorgibt. Ob das so pauschal stimmt kann ich aber nicht definitiv sagen.

In den Autodocs wird ja auf BltBitMap() verwiesen. Meine Überlegung war, ob ClipBlit() möglicherweise intelligenter ist und bei Bedarf mehrere Blits ausführt.

Zitat:
Die Minimalgröße ergibt sich daraus, daß der Blitter nicht mit NIL arbeiten mag. Ein Pixel sollte man schon bearbeiten, wenn man das Biest weckt

Schon klar. Ich fand es nur merkwürdig, dass zwar das Minimum, aber kein Maximum angegeben wird.

Zitat:
Zitat:
Was gilt bei CyberGraphX und Picasso96?

Das ist eine gute Frage... wirklich Aufklärung darüber bekommt man ja leider nicht, genausowenig wie Informationen darüber, welcher Treiber welche Blits in Hardware unterstützt und welche Funktionalität rein in Software nachgebildet wird. Bei Softwarenachbildungen wäre die max. Blitgröße eigentlich unbegrenzt, aber aufgrund von Buslimits, Alignment-Vorteilen, Segmentierung usw. usf. wird das wahrscheinlich von Hardware zu Hardware variieren. Das dürfte auch der Grund sein, weshalb man nirgendwo definitive Limits findet.

Und wie mache ich das Blitten dann in der Praxis, wenn ich nicht überprüfen kann, ob ein Blit möglich ist oder ob mehrere Blits nötig sind?

Zur Erklärung: Ich benutze immer ClipBlit(), zum einen fürs Scrolling im Fenster (ist schneller als ScrollRaster() und sieht genauso gut aus). Dabei sind bisher nie Probleme aufgetreten, auch nicht zu den A500 Zeiten (lang ist's her). Zum anderen Zeichne ich in einem nicht sichtbaren Rastport, dessen Größe ich zur Laufzeit berechne. Einen Teil des Rastports blitte ich dann mit ClipBlit() in einen anderen nicht sichtbaren Rastport oder in ein Fenster, wo ich sozusagen die Ergebnisse zusammenführe. Auch dabei sind bisher nie Probleme aufgetreten. Allerdings habe ich das erst geschrieben, als ich bereits AGA und Grafikkarte (CGFX) hatte und ich kann nicht ausschließen, dass das nur Zufall war, weil ich zufällig innerhalb der Grenzen geblieben bin. Mir war bis vor kurzem nicht bewusst, dass es da Limitierungen (insbesondere bei OCS) geben könnte (in den Autodocs zu ClipBlit() wird ja kein Maximum angegeben).

Tschüß

[ - Answer - Quote - Direct link - ]

2008-05-11, 04:56 h

whose
Posts: 2156
User

Zitat:
Original von NoImag:

Da ich nicht direkt die Hardware programmiere, beziehe ich mich immer auf die graphics.library. Die Angaben stammen aus dem Libraries-Manual, Graphics Primitives, About ECS, Determining Chip Versions: "The ECS Agnus can handle rasters up to 16,384 by 16,384 pixels."

Ah, nu hab ichs. Ok, das ist auch wieder bedingt durch die Registerbreite, hat aber mit dem Blitter eher wenig zu tun.

Zitat:
Meine Frage, ob damit Screens gemeint sind, kommt daher, weil im ScreenMode-Voreinsteller alle AGA-Modes eine maximale Screengröße von 16384x16384 erlauben.

Das ist mehr eine Copper-Sache. Also, Screens an sich sind damit nicht gemeint. Schlicht ein Schwung Pixel in einer Plane.

Zitat:
Die Angaben stammen aus dem Libraries-Manual, Graphics Primitives, Drawing Routines, Performing Data Move Operations, Copying Rectangular Areas, Abschnitt mit der Beschreibung von BltBitMap(). Ich würde erwarten, dass dieser Abschnitt keine anderen Angaben enthält, als die Autodocs.

Würdest Du, aber schon mal daran gedacht, daß die RKMs sich noch auf Kickstart 2.0 beziehen? Letztendlich bedeutet es, daß die AutoDocs für z.B. OS3.9 die aktuellsten Angaben beinhalten und als bindend betrachtet werden dürfen, wenn es da Unterschiede zu den RKMs gibt.

Zitat:
In den Autodocs wird ja auf BltBitMap() verwiesen. Meine Überlegung war, ob ClipBlit() möglicherweise intelligenter ist und bei Bedarf mehrere Blits ausführt.

Eigentlich ist es recht einfach: Wenn in den Autodocs oder RKMs nichts davon steht, daß ClipBlit() große Einzelblits ggf. in mehrere kleinere aufteilt, dann wirds das mit hoher Wahrscheinlichkeit auch nicht tun.

Zitat:
Und wie mache ich das Blitten dann in der Praxis, wenn ich nicht überprüfen kann, ob ein Blit möglich ist oder ob mehrere Blits nötig sind?

Ich schätze, da machst Du Dir zu viele Gedanken... das BltBitMap()-Limit ergibt sich aus dem, was die Hardware zuläßt. Somit solltest Du davon ausgehen, daß dieses Limit einen Sinn hat und größere Blits ggf. selbst stückeln. Dann gibts kein Vertun.

Für RTG-Funktionen wiederum werden keine Maxima spezifiziert, was den Schluß nahelegt, daß es wohl keine gibt (theoretisch). Andererseits verwenden diese Funktionen auch eher selten Hardware, die Limits bedingen könnte, und die gepatchten Funktionen der graphics.library werden dort nicht mit irgendwelchen Erweiterungen spezifiziert, bedeutet, das Limit für z.B. BltBitMap() besteht weiterhin -> ggf. selbst stückeln.

Grüße

--
---

µA1 PPC 750GX-800

A4000 PPC 604e-233

[ - Answer - Quote - Direct link - ]

2008-05-11, 21:17 h

NoImag
Posts: 1050
User

Zitat:
Original von whose:

Zitat:
Die Angaben stammen aus dem Libraries-Manual, Graphics Primitives, Drawing Routines, Performing Data Move Operations, Copying Rectangular Areas, Abschnitt mit der Beschreibung von BltBitMap(). Ich würde erwarten, dass dieser Abschnitt keine anderen Angaben enthält, als die Autodocs.

Würdest Du, aber schon mal daran gedacht, daß die RKMs sich noch auf Kickstart 2.0 beziehen? Letztendlich bedeutet es, daß die AutoDocs für z.B. OS3.9 die aktuellsten Angaben beinhalten und als bindend betrachtet werden dürfen, wenn es da Unterschiede zu den RKMs gibt.

Daran habe ich schon gedacht, aber die Autodocs zu BltBitMap() haben sich seit V36 nicht mehr geändert. Daher halte ich Schlamperei bei Commodore für genauso möglich. Zur Sicherheit werde ich dann aber stückeln.

Tschüß

[ - Answer - Quote - Direct link - ]

-1-

[ - Post reply - ]

amiga-news.de Forum > Programmierung > Fragen zu Raster- und Blitterbeschränkungen

[ - Search - New posts - Register - Login - ]