[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

code:

---

Function.l image_initrastport{image.l}
SHARED imagedat()
succ.l = False
If rastport_ptr Then image_free_rastport{image}
ARGBbitmap_ptr = AllocBitMap_(img_width,img_height,24,#BMF_MINPLANES|#BMF_SPECIALFMT|#F_ARGB32,0)
If ARGBbitmap_ptr
  rastport_ptr = AllocMem_(SizeOf.RastPort,#MEMF_CLEAR)
  If rastport_ptr
    InitRastPort_ rastport_ptr
    rastport_ptrLayer  = 0
    rastport_ptrBitMap = ARGBbitmap_ptr
    layerinfo_ptr       = NewLayerInfo_
    rastport_ptrLayer  = layerinfo_ptrtop_layer
    cliprect.RectangleMinX = 0
    cliprect.RectangleMinY = 0
    cliprectMaxX = img_width-1
    cliprectMaxY = img_height-1
    *new_region.Region = NewRegion_
    If *new_region
      If OrRectRegion_(*new_region, &cliprect)

!!! GEHT NICHT, WEIL rastport_ptrLayer=NULL !
   ;     *old_region.Region = InstallClipRegion_(rastport_ptrLayer, *new_region)
      End If
    End If
    succ=-1
    raw_ptr.l = image_get_rawptr{image}
    WritePixelArray_ raw_ptr,0,0,img_width*4,rastport_ptr,0,0,img_width,img_height,#RECTFMT_ARGB

  Else
    error {"image_initrastport{}: Unable to init rastport !"}
  End If
Else
  error {"image_initrastport{}: Unable to init ARGB bitmap !"}
End If
Function Return succ
End Function

---

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Eigentlich müsste ich nur eine BitmapStruktur anlegen, deren "planes" Feld auf das PixelArray zeigen. Allerdings gibt es da nocj jede Menge "private" Informationen, sodass es einem Hack gleichkommen würde. Ein manuelles ausfüllen einer Bitmapstruktur ist wohl nicht legal.

---

Zitat:

---

Jetzt würde ich gerne einen Layer erzeugen, der genau die Bitmap abgrenzt, damit ich auch ordentlich Clippen kann. Wie geht das ?

---

code:

---

bitmap = AllocBitMap (breite,hoehe,tiefe,eigenschaften,NULL)
layerinfo = NewLayerInfo()
layer = CreateUpfrontLayer (layerinfo,bitmap,0,0,breite-1,hoehe-1,0,NULL)
rastport = layer->rp

---

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von bubblebobble:
Achja, wenn ich jetzt noch die akutelle Screenpalette für die Rastport Operationen benutzen könnte, wäre ich (fast) wunschlos glücklich!

Wenn ich auf diesem RastPort z.B. Draw() anwende sind alle Linien schwarz, egal welche Pen Nummer.

---

[ - Antworten - Zitieren - Direktlink - ]

code:

---

bitmap = AllocBitMap (breite,hoehe,tiefe,BMF_MINPLANES,screen->RastPort.BitMap);
layerinfo = NewLayerInfo();
layer = CreateUpfrontLayer (layerinfo,bitmap,0,0,breite-1,hoehe-1,0,NULL);
rastport = layer->rp;

...

DeleteLayer (0,layer);
DisposeLayerInfo (layerinfo);
FreeBitMap (bitmap);

---

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von thomas:
Die Palette vom Screen bekommst du, indem du die Screen-Bitmap als Friend bei AllocBitMap angibst. Allerdings erbt die neue Bitmap dann nicht nur die Palette, sondern auch das Pixelformat der Screen-Bitmap.

---

Zitat:

---

Aufräumen mußt du alles in ungekehrter Reihenfolge.

---

Zitat:

---

Natürlich mußt du nach jeder Funktion auch prüfen, ob es geklappt hat und nur das freigeben, was angelegt wurde.

---

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von bubblebobble:
Ja, das ist eine gute Idee, aber ich will das PixelFormat ARGB erzwingen, weil es für ein Zeichenprogramm ist, und ich will ja
nicht in 16bit malen weil ich einen 16bit Bildschirm zum Anzeigen benutze, bzw. ich brauche unbedingt Kenntniss über das Pixelformat.

---

Zitat:

---

Also bleibt mir wohl nicht viel übrig als

a) eigene Zeichenroutinen schreiben
(was ja für RectFill und Line nicht unbedingt schwer ist,
zumal cih auch gerne Antialiasing hätte)

b) mit SetRPAttr() arbeiten, und AfA, OS4 oder MOS als Mindestvoraussetzung stellen.

Immerhin, bitmapoperationen wie BltBitmap() funzen ohne Pens.
Einzige Schwierigkeit wird Text().

---

[ - Antworten - Zitieren - Direktlink - ]

code:

---

SetRPAttrsA_ rp,Tags(#RPTAG_PenMode,False,#RPTAG_BgColor,$FFFFFF,#RPTAG_FgColor,$FFFFFF)
Move_ rp,10,10
Draw_ rp,400,400
RectFill_ rp,20,20,190,190

---

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von bubblebobble:
Ok, ich habe mal mit SetRPAttrsA() herumgespielt.
Funktioniert aber nicht (AfA OS), alle Pens bleiben schwarz.

Ich mache folgendes:

code:

---

SetRPAttrsA_ rp,Tags(#RPTAG_PenMode,False,#RPTAG_BgColor,$FFFFFF,#RPTAG_FgColor,$FFFFFF)
Move_ rp,10,10
Draw_ rp,400,400
RectFill_ rp,20,20,190,190

---

Hab ich was vergessen ?

---

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von bubblebobble:
An all eOS4 user:

Könntet ihr mir den Wert von

RPTAG_APenColor
RPTAG_BPenColor

---

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von bubblebobble:
Ok, es funktioniert NICHT.

Der obige Code funktioniert mit dem RastPort eines Fensters
auf einem 16/24bit screen (was einen Viewport hat).
Es funktioniert aber NICHT mit dem Rastport, den ich aus Thomas seinem Beispiel code erhalte. Hier wird trotzdem alles
in schwarz gezeichnet. Zumindest verhält sich AfA OS unter WinUAE so.

---

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von bubblebobble:
Ich glaube, ich weiss warum es nicht geht.
Wenn mich nicht alles täuscht, funktioniert Bernds AfA Penless Mode so:
Er merkt sich den RGB Wert irgendwo, den man mit SetRPAttrs() setzt.
Wenn jetzt eine Zeichenfunktion kommt, setzt er flux den Pen #1 auf den RGB Wert, zeichnet, und stellt den ursprünglichen RGB Wert des Pens #1 wieder her.
Bei 24bit Screens kann man diesen Trick machen, da sich eine Paletenänderung nicht auf die bestehenden Pixel auswirkt. Während der ganzen Zeit hält er den RastPort dann gelockt, so kann nichts passieren.

Ich denke das macht er so, weil ich keine andere Möglichkeit sehe. Wie soll AfA das sonst machen ? Für "echte" 24bit Grafikoperationen müsste man Picasso96 geändert werden, das kann man aus AfA heraus nicht machen.

Und weil eigentlich nur mit einem ganz normalen Pen gezeichnet wird, funktioniert das logischerweise auf einer Bitmap ohne Paletteninformation nicht.

Unter AROS, MOS und OS4 könnte es aber funktionieren.

---

P96/CGFX waren auch ursprünglich nicht dafür ausgelegt, voll kompatibel zum Paletten-System zu bleiben, daß bis dahin aktuell war. Man ging damals davon aus, daß sich für Modi >8Bit eins der P96/CGFX-eigenen APIs durchsetzt. Blöderweise hat das nicht so wirklich funktioniert, weshalb u.A. die P96-Macher auf die Idee der Emulation der cybergraphx.library gekommen sind.

Dieser Weg bliebe Dir auch noch offen, was aber mehr Arbeit mit sich bringen würde (u.A. eigene Verwaltung der Palette für Screens > 8Bit). Allerdings wärst Du damit auf einer relativ sicheren Seite, denn nicht jeder wird sich auch noch AfA installieren wollen (OS3.9-User z.B.). Unter MOS/OS4 funktionieren die RTG-APIs ja weiterhin wie in alten 68K-Zeiten, was Modi >8Bit betrifft.

Grüße

--
---

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

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

whose:
Man ging damals davon aus, daß sich für Modi >8Bit eins der P96/CGFX-eigenen APIs durchsetzt.

---

Zitat:

---

Blöderweise hat das nicht so wirklich funktioniert, weshalb u.A. die P96-Macher auf die Idee der Emulation der cybergraphx.library gekommen sind.

---

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von bubblebobble:
@whose

Was schlägst du nun konkret vor ?

---

Zitat:

---

Was meinst du mit eigener Palettenverwaltung ?

---

Zitat:

---

Ich brauche 24bit Grafik Funktionen auf eine Bitmap, die nicht mit einem Viewport verbunden ist.

---

...und leider auch die anderen benötigten Zeichenfunktionen selbst implementieren oder so etwas wie ttf.library z.B. benutzen. Bietet guigfx eigentlich keine anderen Zeichenfunktionen? Ich hab mich damit noch nicht tiefer beschäftigt.

Grüße

--
---

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


[ Dieser Beitrag wurde von whose am 22.08.2006 um 17:40 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von bubblebobble:
Das CGFX API bietet aber IIRC keine Funktionen für Linienzeichnen, Text schreiben in 24bit etc.

---

Das deckt sich auch mit meinen Erinnerungen

Du kannst aber in eine 256 Farb-Bitmap zeichnen und dann das Ergebnis mittels WriteLUTPixelArray in eine TrueColor-BitMap übertragen. Da kannst Du Deine ColorTable angeben.

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

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von gni:

Zitat:

---

whose:
Man ging damals davon aus, daß sich für Modi >8Bit eins der P96/CGFX-eigenen APIs durchsetzt.

---

IMO hat sich das CGFX-API "durchgesetzt".

---

Zitat:

---

Zitat:

---

Blöderweise hat das nicht so wirklich funktioniert, weshalb u.A. die P96-Macher auf die Idee der Emulation der cybergraphx.library gekommen sind.

---

Denen blieb gar nichts anderes übrig als diese Emulation anzubieten. Zum Zeitpunkt von P96 war CGFX bereits ein Standard (da von "offizieller" Seite nichts mehr kommen konnte), für den es schon eine gewisse Zahl an Programmen gab. Den aussen vor zu lassen wäre reichlich dumm gewesen.

---

Ja, die "offizielle" Seite war das Problem, weshalb es immer noch zwei leicht unterschiedliche APIs gibt. Meiner Meinung nach war die Emulation nicht zwingend notwendig (auch beim RTG-System gabs ja zwei Lager, nicht nur bei PUP/WOS), aber, wie Du schon sagtest, es wäre reichlich dumm gewesen, diese Nutzer nicht auch noch "mitzunehmen".

Grüße

--
---

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

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von bubblebobble:
Das mit dem LUT Array ist gar nicht mal so eine schlechte Idee, nur das ich dan leider AA Fonts verliere, da diese nicht auf LUTs gehen.

---

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

@bubblebobble:

Hm, dann verstehe ich Dein Problem aber nicht so ganz... direkte Unterstützung für 1>Bit-Alpha-Channels haben die älteren Versionen von CGFX/P96 doch sowieso nicht, mit oder ohne Blittereinsatz. Du müßtest also so oder so "von Hand" das Ergebnis ins sichtbare Bild bringen. 8Bit Offscreen-Bitmap (gleichzeitig Alpha-Channel), mittels eigener WritePixelArray()-Implementation unter Berücksichtigung der Transparenz ins sichtbare Bild bringen, fertig. Nicht so besonders schnell, aber halt nicht anders machbar. Oder habe ich da was verpaßt in Bezug auf P96/CGFX für 68K?

Grüße

--
---

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

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von bubblebobble:
Ich evaluiere nur die Möglichkeiten. Bis jetzt bleibt mir nur das Schlupfloch, dass die Text Operationen grundsätzlich funktionieren, nur eben schwarz. Für meine speziellen zwecke reicht mir schwarz, aber da ich alles in Funktionsbiblitheken packe (Wiederverwertbarkeit!) wäre es schön, wenn alles so funktioniert wie es soll.

---

Ah, jetzt habe ichs... nun ja, der Weg steht wohl nicht für alle Systeme offen. Spätestens beim Thema Alpha-Channel mußt Du für 68K (bzw. OS2.x/3.x) eigene Wege gehen, da P96/CGFX sowas dort nicht direkt unterstützen. 8Bit-Alpha bietet meines Wissens derzeit auch nur CGFX für MOS an, OS4 bekommt das erst noch. Wie dort die Implementation aussieht, wissen vorerst aber wohl nur die Beta-Tester, wenn überhaupt.

Die Arbeit mit Paletten für Offscreen-Bitmaps ist ähnlich gelagert. Penoperationen waren für Offscreen-Bitmaps >8Bit (bzw. für Bitmaps ohne direkten Bezug zur graphics.library/Intuition) einfach nicht vorgesehen, dort sollten die 16/24Bit-APIs der RTG-Systeme dienen.

Für 68K siehts also in der Hinsicht etwas düster aus, leider. Ich könnte Alpha-Channel-Unterstützung >1Bit fürs Blitten auf 68K-Maschinen auch ganz gut gebrauchen, aber da ginge das Theater leider bei den älteren GraKas weiter, die sowas nicht unterstützen, selbst wenn es gute Alpha-Channel-Unterstützung durch P96/CGFX eines Tages gäbe...

Grüße

--
---

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


[ Dieser Beitrag wurde von whose am 22.08.2006 um 18:40 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]