[ - Antworten - Zitieren - Direktlink - ]

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?

---

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. ]

[ - Antworten - Zitieren - Direktlink - ]

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.

---

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ß.

---

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.

---

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.

---

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

---

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.

---

[ - Antworten - Zitieren - Direktlink - ]

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."

---

Zitat:

---

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

---

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.

---

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.

---

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

[ - Antworten - Zitieren - Direktlink - ]

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.

---

[ - Antworten - Zitieren - Direktlink - ]