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

amiga-news.de Forum > Programmierung > Dokumentation von Systemzusammenhängen [ - Suche - Neue Beiträge - Registrieren - Login - ]

-1- [ - Beitrag schreiben - ]

03.04.2011, 20:59 Uhr

Reth
Posts: 1858
Nutzer
Hallo zusammen,

leider fällt mir kein besserer Titel ein.

Derzeit arbeite ich immer noch an meinem Spiel mit AmigaOS-Funktionen, nutze allerdings C++. Da ich kein Framework o.ä. nutzen möchte, für mich aber die AOS-Funktionen "möglichst gut" in Klassen stecken möchte, bin ich gerade auf der Suche nach Hintergrund-Infos, darüber, wie die einzelnen Elemente des AmigaOS so zusammen arbeiten.

Konkret möchte ich gerade am Liebsten alle grafischen Funktionen in einer Klasse kapseln (ähnlich der Graphics-Klasse in Java). Allerdings verstehe ich den Zusammenhang zw. den wenigen Funktionen, die ich fürs Blitten nutze noch nicht: BltBitMap und BltBitMapRastPort (mit und ohne Maske) und auch das Zusammenspiel zw. RastPort und BitMap (nach meinem Verständnis hat jeder RastPort ne BitMap, in die dargestellt wird). Wird bei BltBitMapRastPort intern auch wieder in die BitMap des RastPorts geblittet?

Das Amiga Intern und das Profi KnowHow habe ich, ebenso die Developer CD 1.2. Bei den Büchern bin ich bisher leider noch nicht auf die Erläuterung der Zusammenhänge gestoßen, die ich so suche (also wie arbeiten die einzelnen Systembestandteile [Window, Layer, Intuition, Graphics und v.a. RastPort und BitMap) zusammen und was wird wofür genutzt). Einige Sachen auf höherer Ebene haben sich mir schon erschlossen, aber der Rest noch nicht, v.a. das Zusammenspiel bei RastPort und BitMap und den dazugehörenden Funktionen).

Einen guten Anhaltspunkt für eine Kapselung hat mir z.B. schon AFrame gegeben (wie gesagt, will kein Framework nehmen und keins selbst bauen, nutze aber gern Anregungen). Bin aber für weitere Hinweise auf Material, Bücher usw. dankbar!

So, mords Text für ein einfaches Anliegen! Hoffe, ich konnte es rüberbringen. Die erste Detailfrage ist wie gesagt der Zusammenhang zw. RastPort und BitMap und den damit verbundenen Blitfunktionen. Werde den Thread wohl aber auch für weitere Fragen zu dem Thema nutzen.

Danke schon mal vorab!

Ciao

[ - Antworten - Zitieren - Direktlink - ]

03.04.2011, 21:29 Uhr

thomas
Posts: 7716
Nutzer

ADCD_v1.2:reference_library/libraries_manual -> Graphics Libraries -> Graphics Primitives


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

[ - Antworten - Zitieren - Direktlink - ]

04.04.2011, 11:19 Uhr

Holger
Posts: 8116
Nutzer
@Reth:
Der RastPort ist im Grunde genau das, was die Graphics-Klasse in Java/AWT ist, nur eben nicht mit in der Notation, die man von der OOP her kennt. (Und nicht ganz so leistungsfähig)

Der RastPort hält den gesamten Status, der für die Grafikoperationen verwendet wird. Dementsprechend gibt es zwei Arten von Funktionen: diejenigen, die den Status verändern, und diejenigen, die Operationen ausführen.

Das Schema ist aber das Gleiche: willst Du eine Linie in einer bestimmten Farbe zeichnen, rufst Du sowohl bei Java/Graphics als auch bei AmigaOS/RastPort zuerst die Funktion auf, die die Farbe setzt und dann die Funktion, die die Linie zeichnet.

Für Raster-Grafiken ist das Prinzip ebenfalls ähnlich: man kann sie auch auf einer niedrigeren Ebene verarbeiten, da die meisten Kontext-Attribute keine Auswirkungen haben. Da es aber doch einige Features gibt, die im Kontext verankert sind, kann man mit der Lowlevel-Variante eine kleine Performance-Steigerung auf Kosten dieser Features erreichen.

Ein wichtiges Feature, das einen RastPort benötigt, ist das Clipping. Die BitMap-Struktur hat keine Referenz auf den Layer, d.h. alle Blit-Operationen, die auf BitMaps arbeiten, ignorieren die Layer-Constraints, während alle RastPort-Operationen den Layer respektieren, wenn der zugehörige Eintrag im rp nicht null ist.

Deshalb müssen systemkonforme Blits bei der Verwendung von Fenstern immer im RastPort erfolgen, es sei denn, man lockt die Layer und a) clipt selber oder b) hat vorher überprüft, dass es keine Überlappungen gibt. Das ist aber nur dann sinnvoll, wenn man sehr viele Blit-Operationen durchführen will.

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

[ - Antworten - Zitieren - Direktlink - ]

04.04.2011, 23:19 Uhr

Reth
Posts: 1858
Nutzer
@Thomas:
Danke!

Zitat:
Original von Holger:
Der RastPort ist im Grunde genau das, was die Graphics-Klasse in Java/AWT ist

So ungefähr hatte ich das auch aufgefasst!

Zitat:
Original von Holger:
Für Raster-Grafiken ist das Prinzip ebenfalls ähnlich: man kann sie auch auf einer niedrigeren Ebene verarbeiten, da die meisten Kontext-Attribute keine Auswirkungen haben.

...

Ein wichtiges Feature, das einen RastPort benötigt, ist das Clipping. Die BitMap-Struktur hat keine Referenz auf den Layer, d.h. alle Blit-Operationen, die auf BitMaps arbeiten, ignorieren die Layer-Constraints, während alle RastPort-Operationen den Layer respektieren, wenn der zugehörige Eintrag im rp nicht null ist.

Diesbezüglich hatte ich auch gedacht, in welcher Beziehung die beiden wohl stehen, damit man die Operationen fürs Blitten irgendwie mit OO- (z.B. Vererbung) und/oder C++-Konzepten (z.B. Templates) an RastPort und BitMap bringen kann. Da ist mir noch nichts eingefallen.
Vielleicht sollten beide eigene, unabhängige Blitoperationen bekommen, und als Klassen unabhängig voneinander bleiben.

Zitat:
Original von Holger:
Deshalb müssen systemkonforme Blits bei der Verwendung von Fenstern immer im RastPort erfolgen, es sei denn, man lockt die Layer und a) clipt selber oder b) hat vorher überprüft, dass es keine Überlappungen gibt. Das ist aber nur dann sinnvoll, wenn man sehr viele Blit-Operationen durchführen will.

Allerdings kann man das BitMap-Blitting ja offscreen verwenden, wenn man z.B. seine Grafiken manipulieren will. Dann bräuchte man auch die Blitoperationen auf den BitMaps direkt.

[ - Antworten - Zitieren - Direktlink - ]

05.04.2011, 16:42 Uhr

Holger
Posts: 8116
Nutzer
Zitat:
Original von Reth:
Vielleicht sollten beide eigene, unabhängige Blitoperationen bekommen, und als Klassen unabhängig voneinander bleiben.

Natürlich. RastPort hat eine BitMap, aber RastPort ist keine BitMap.
Zitat:
Allerdings kann man das BitMap-Blitting ja offscreen verwenden, wenn man z.B. seine Grafiken manipulieren will. Dann bräuchte man auch die Blitoperationen auf den BitMaps direkt.
Dafür sind die Operationen sinnvoll, aber von brauchen würde ich nicht reden. Schließlich kann man auch für Offscreen-BitMaps RastPorts anlegen.

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

[ - Antworten - Zitieren - Direktlink - ]

05.04.2011, 19:01 Uhr

Reth
Posts: 1858
Nutzer
Zitat:
Original von Holger:
Natürlich. RastPort hat eine BitMap, aber RastPort ist keine BitMap.

Das ist klar. Es gibt ja aber noch andere Konzepte, wie z.B. Interfaces oder Templates, die hier ne Rolle spielen könnten und bei denen ich nicht sicher bin, ob sie genutzt werden könnten.

Zitat:
Original von Holger:
Dafür sind die Operationen sinnvoll, aber von brauchen würde ich nicht reden. Schließlich kann man auch für Offscreen-BitMaps RastPorts anlegen.

Deine Tendenz wäre dann eher, die BitMap-Blitoperationen wegzulassen, oder höchtens der Vollständigkeit halber anzubieten?

Für die Zuordnung der Operationen hab ich bei den RastPort-Blitoperationen meine RastPort-Klasse genommen und ihr (bisher nur eine) BlitMethode verpasst.

Die BitMap-Blitfunktionen kämen dann bei mir an eine BitMap-Klasse. Bisher hatte ich mich gefragt, ob ich eine BitMap-BlitMethode für die BitMap eines RastPort-Objektes aufrufen muss, wenn die BlitMethode des RastPort-Objektes gerufen wurde (also delegieren). Nachdem, was Du (Holger) aber oben angeführt hast sind das wirklich zwei Paar getrennte Schuhe!

[ - Antworten - Zitieren - Direktlink - ]

06.04.2011, 10:53 Uhr

Holger
Posts: 8116
Nutzer
Zitat:
Original von Reth:
Das ist klar. Es gibt ja aber noch andere Konzepte, wie z.B. Interfaces oder Templates, die hier ne Rolle spielen könnten und bei denen ich nicht sicher bin, ob sie genutzt werden könnten.

Ja, man könnte natürlich eine Abstraktion der Art "Blit-Ziel" machen, um dann bestimmte Funktionen von der Frage, ob sie in einen RastPort oder direkt in eine BitMap blitten, zu entkoppeln.
Die Frage, die Du Dir dabei stellen solltest, ist: brauchst Du diese Möglichkeit?

Ich tendiere eher zu nein, denn Blitten ohne Clipping kann man auch mit einem RastPort, dazu muss nur der Layer-Pointer auf null stehen. D.h. es gibt bereit eine Möglichkeit, beides mit demselben Code ganz ohne Polymorphie zu erschlagen.

Zitat:
Bisher hatte ich mich gefragt, ob ich eine BitMap-BlitMethode für die BitMap eines RastPort-Objektes aufrufen muss, wenn die BlitMethode des RastPort-Objektes gerufen wurde (also delegieren). Nachdem, was Du (Holger) aber oben angeführt hast sind das wirklich zwei Paar getrennte Schuhe!
Delegation als "Komfortfunktion" ist an sich nicht schlecht. Würde ich hier aber von abraten, da der RastPort-Wrapper dann zwei verschiedene Arten von Blit-Funktionen anbieten würde, die man durcheinanderbringen könnte.

Und wenn man versucht, Eindeutigkeit beispielsweise über den Namen zu erzielen, sind die Funktionen auch nicht mehr komfortabler, als beispielsweise, rastport->bitMap->blit statt rastport->bitMapDirectBlit zu schreiben.

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

[ - Antworten - Zitieren - Direktlink - ]

06.04.2011, 19:22 Uhr

Reth
Posts: 1858
Nutzer
Zitat:
Original von Holger:
Ja, man könnte natürlich eine Abstraktion der Art "Blit-Ziel" machen, um dann bestimmte Funktionen von der Frage, ob sie in einen RastPort oder direkt in eine BitMap blitten, zu entkoppeln.
Die Frage, die Du Dir dabei stellen solltest, ist: brauchst Du diese Möglichkeit?

Derzeit nicht, da ich nur im RastPort blitte. Die BitMaps, die meine Grafiken enthalten werden nicht "beblittet".

Zitat:
Original von Holger:
Und wenn man versucht, Eindeutigkeit beispielsweise über den Namen zu erzielen, sind die Funktionen auch nicht mehr komfortabler, als beispielsweise, rastport->bitMap->blit statt rastport->bitMapDirectBlit zu schreiben.

Der zweite Fall wäre ja auch nicht so sinnvoll, da diese Methode eine der BitMap-Klasse sein würde (zumindest nach meiner Ansicht).
BltBitMapRastPort (auch mit Maske) für die RastPort-Klasse, BltBitMap (auch mit Maske) für die BitMap-Klasse (so mal die Idee).

[ - Antworten - Zitieren - Direktlink - ]

06.04.2011, 19:41 Uhr

Holger
Posts: 8116
Nutzer
Zitat:
Original von Reth:
Derzeit nicht, da ich nur im RastPort blitte.

Dann ist ja alles klar.
Zitat:
Der zweite Fall wäre ja auch nicht so sinnvoll, da diese Methode eine der BitMap-Klasse sein würde (zumindest nach meiner Ansicht).
Ja klar, aber Du hattest die Frage angesprochen, ob die RastPort-Klasse Methoden anbietet, die an die BitMap delegieren.
Zitat:
BltBitMapRastPort (auch mit Maske) für die RastPort-Klasse, BltBitMap (auch mit Maske) für die BitMap-Klasse (so mal die Idee).
Ich halte es nicht für sinnvoll, den Begriff RastPort noch mal extra im Methodennamen zu haben, wenn das Ziel des Aufrufes schon ein RastPort ist.
Und da es momentan eher so aussieht, als ob Du die Blit-Funktionen auf BitMap überhaupt nicht brauchst, lass sie doch einfach weg.

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

[ - Antworten - Zitieren - Direktlink - ]

06.04.2011, 22:54 Uhr

Reth
Posts: 1858
Nutzer
Zitat:
Original von Holger:
Ja klar, aber Du hattest die Frage angesprochen, ob die RastPort-Klasse Methoden anbietet, die an die BitMap delegieren.
...
Und da es momentan eher so aussieht, als ob Du die Blit-Funktionen auf BitMap überhaupt nicht brauchst, lass sie doch einfach weg.

Das werde ich auch erst einmal. Allerdings möchte ich gern einen möglichst guten strukturellen Ansatz finden.

Eine weitere Überlegung von mir dazu ist z.B. eine BitMap-Klasse mit zwei Blit-Methoden auszustatten. Eine fürs Blitten des jew. BitMap-Objektes in einen RastPort und eine fürs Blitten in eine andere BitMap.

Aktuell habe ich die struct BitMap in einer Frame-Klasse gekapselt, die etwas profan Breite und Höhe, sowie Daten für das Bild und eine Maske im Konstruktor mitbekommt (zusätzlich kann eine FriendBitMap übergeben werden, für das Alignment usw.).
Über Getter sind die Breite, Höhe, Maske, Daten und die BitMap zugänglich. Die RastPort-Klasse kann Frames an eine X-/Y-Position blitten und nutzt dafür die Getter für Breite, Höhe, BitMap und Maske der BitMap, indem intern dann BltBitMapRastPort bzw. BltMaskBitMapRastPort aufgerufen wird (eine Übergabe von Mintermen hab ich derzeit nicht).

[ - Antworten - Zitieren - Direktlink - ]

07.04.2011, 11:12 Uhr

Holger
Posts: 8116
Nutzer
Zitat:
Original von Reth:
Eine weitere Überlegung von mir dazu ist z.B. eine BitMap-Klasse mit zwei Blit-Methoden auszustatten. Eine fürs Blitten des jew. BitMap-Objektes in einen RastPort und eine fürs Blitten in eine andere BitMap.

Wozu?
Soweit ich das erkennen kann, hast Du bislang den Ansatz verfolgt, dass Zielobjekt mit Methoden zu versehen, die das Quell-Objekt als Argument übergeben bekommen. Da ist es nicht sehr sinnvoll, jetzt das BitMap-Objekt (also die Quelle) mit einer Methode zu versehen, die in einen RastPort blittet. Und die zweite Methode gehört ja offensichtlich in die Kategorie, Methoden, die Du laut eigener Aussage nicht benutzt. Bringt also gar nichts.

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

[ - Antworten - Zitieren - Direktlink - ]


-1- [ - Beitrag schreiben - ]


amiga-news.de Forum > Programmierung > Dokumentation von Systemzusammenhängen [ - Suche - Neue Beiträge - Registrieren - Login - ]


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