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

amiga-news.de Forum > Programmierung > BitMap aus PixelArray erzeugen [ - Suche - Neue Beiträge - Registrieren - Login - ]

-1- 2 [ - Beitrag schreiben - ]

19.08.2006, 23:25 Uhr

bubblebobble
Posts: 707
Nutzer
Hallo Alle!

Ich habe ein PixelArray im Format ARGB, also einfach ein Speicherbereich mit den Pixeln drin.
Kann ich daraus eine Bitmap machen, die ich dann in Kombination mit einem RastPort für Rastport Operationen benutzen kann ?

Dabei will ich das PixelArray NICHT duplizieren, ich will also den vorhandenen Speicher nutzen.

Ansonsten könnte ich einfach AllocBitmap() machen, und mit WritePixelArrayA() die Daten rüberkopieren, so weit bin ich schon. Ich will aber den Speicherbereich nutzen, den ich schon habe.

Ich weiss, dass es gut sein kann, dass es unmöglich ist, weil je nach System gewissen Anforderungen an den Bitmapspeicher gestellt werden, der nur duch AllocBitmap sichergestellt werden kann.

Die Bitmap muss natürlich nicht angezeigt werden können.
--
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 - ]

20.08.2006, 00:03 Uhr

thomas
Posts: 7675
Nutzer

Nein, das geht nicht. Aher der umgekehrte Weg geht. Wenn du gar nicht erst ein Array, sondern direkt eine Bitmap mit ARGB-Pixelformat allokierst, dann kannst du den Speicher der Bitmap als Array benutzen.

Gruß Thomas

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

[ - Antworten - Zitieren - Direktlink - ]

20.08.2006, 10:17 Uhr

bubblebobble
Posts: 707
Nutzer
@Thomas

Ja, das ist mir klar. Aber gerade weil ich das NICHT kann,stelle ich hier die Frage.
Ich bekomme das PixelArray von der guigfx.library geliefert, und würde gerne drin herummalen (mit RastPort basierenden Funktionen), ohne das PixelArray dafür zu duplizieren, denn dann würde ich
1. doppelt so viel Speicher verbrauchen
2. guigfx hätte noch das alte, unmodifizierte Bild, und ich müsste mittels ReadPixelArray() nach jeder Operation das Bild zurückswappen, und das will ich natürlich auch nicht.

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.

Achja, noch eine Frage:
Ich habe im Moment die provisorische Lösung, dass ich eine Bitmap und einen RastPort mit gleicher Größe wie mein PixelArray erzeuge, mit WritePixelArray() das PixelArray in die Bitmap kopiere, meine Rastport Operationen ausführe, und das ganze wieder zurück kopiere.
Da stellte sich mir aber noch ein Problem: Nach InitRastPort() hat der RastPort als Layer einen NULL Pointer. Jetzt würde ich gerne einen Layer erzeugen, der genau die Bitmap abgrenzt, damit ich auch ordentlich Clippen kann. Wie geht das ?

Ich abe es mit NewLayerInfo() probiert, aber möglicherweise ist das Quatsch.
Meine Funktion sieht im Moment so aus:

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_ptr\Layer  = 0
    \rastport_ptr\BitMap = \ARGBbitmap_ptr
    \layerinfo_ptr       = NewLayerInfo_
    \rastport_ptr\Layer  = \layerinfo_ptr\top_layer
    cliprect.Rectangle\MinX = 0
    cliprect.Rectangle\MinY = 0
    cliprect\MaxX = \img_width-1
    cliprect\MaxY = \img_height-1
    *new_region.Region = NewRegion_
    If *new_region
      If OrRectRegion_(*new_region, &cliprect)

!!! GEHT NICHT, WEIL \rastport_ptr\Layer=NULL !
   ;     *old_region.Region = InstallClipRegion_(\rastport_ptr\Layer, *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




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

20.08.2006, 10:45 Uhr

thomas
Posts: 7675
Nutzer
@bubblebobble:

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.

Eben nicht. Die Bitmap-Struktur ist nur ein Dummy, damit alte Programme was zum anschauen haben. Die eigentlichen Bitmap-Daten sind privat und undokumentiert, die kannst du nicht manuell anlegen, du weißt ja noch nichtmal wo sie liegen. Vermutlich sind sie auch bei P96 und CGX verschieden, vielleicht sogar bei verschiedenen Versionen des gleichen Systems unterschiedlich. D.h. dein Programm müßte abfragen, wo es läuft und alle verschiedenen Versionen berücksichtigen, oder e swürde abstürzen. Bei neueren, noch nicht existierenden OS-Versionen würde es mit Sicherheit abstürzen.


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


Diesen Rastport mußt du zum Zeichnen verwenden, keinen eigenen anlegen. Auf die Größe der Bitmap wird hierbei automatisch geclippt. Eine Region mußt du nur hinzufügen, wenn du auf einen noch kleineren Bereich eingrenzen möchtest. Beachte, daß bei CreateUpfrontLayer Koordinaten angegeben werden, deshalb breite-1 und hoehe-1 und nicht breite und hoehe.

Gruß Thomas

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

[ - Antworten - Zitieren - Direktlink - ]

20.08.2006, 14:39 Uhr

bubblebobble
Posts: 707
Nutzer
@Thomas

Vielen Dank für die promte Hilfe!
Ich hab jetzt einnen kleinen "Hack" drin, der nur temporär doppelten Speicher braucht, indem ich
1. eine Bitmap anlege,
2. die Bitmap mit dem GUIGFX picture fülle,
3. das GUIGFX picutre freigebe
4. und die Bitmapdaten wieder als GUIGFX picture wandle.
(das geht, ohne ein Duplikat zu erstellen)

Jetzt müsstest du mir nur noch verraten, wie ich das alles wieder sauber freigebe.

Muss ich z.B. nur LayerInfo freigeben, und der Layer und Rastport wird
automatisch zerstört oder alles einzeln ?
Und in welcher Reihenfolge ? Zuerst Layer, dann Bitmap ?

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

20.08.2006, 14:47 Uhr

bubblebobble
Posts: 707
Nutzer
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.



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

20.08.2006, 15:46 Uhr

DariusBrewka
Posts: 899
[Benutzer gesperrt]
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.


Das ist halt ein Problem, was ich hier irgendwann auch angesprochen habe, im RastPort alleine steht kein Pointer auf die Colormap, d.h. wenn du auf ein bis 8 Bit große Bitmap schreibst steht ja immer noch die Pen Nummer in der Map die wenn du diese 8 Bit Map auf den Screen Kopierst dann die Farbe des entsprechenden Pens des Screens annimmt, bei > 8 Bit ist das ein Großes Problem da WritePixel nichts mit dem Pen anfangen kann. Georg Steger sagte, dass P96/CGX irgendwo in der BitMap Struktur einen Zeiger auf die Colormap ablegen, aber ich habe das so nicht feststellen können.

Das gilt aber immer nur für RastPorts welche nicht an einen Screen/Window gekoppelt sind, sonst weiß graphics welcher PEN welcher Farbe entspricht, bei ungekoppelten Rastports gibt es nur wenige Möglichkeiten, z.B. uner MOS/OS4/AROS die Möglichkeit die Farbe nicht über Pens sondern über die Funktion SetRPAttrs() direkt zu setzen, mit AfA geht das aber auch über OS3.x, da du das ehe verwendest und es wohl Standard wird solltest du diese Möglichkeit nutzen.

[ - Antworten - Zitieren - Direktlink - ]

21.08.2006, 10:22 Uhr

thomas
Posts: 7675
Nutzer

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.

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

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);


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

Gruß Thomas

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

[ - Antworten - Zitieren - Direktlink - ]

21.08.2006, 11:00 Uhr

bubblebobble
Posts: 707
Nutzer
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.

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:
Aufräumen mußt du alles in ungekehrter Reihenfolge.
Danke!

Zitat:
Natürlich mußt du nach jeder Funktion auch prüfen, ob es geklappt hat und nur das freigeben, was angelegt wurde.
Ja, klar. Das mache ich natürlich grundsätzlich so.

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().

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

21.08.2006, 11:30 Uhr

DariusBrewka
Posts: 899
[Benutzer gesperrt]
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.


Wie Thomas schon angedeutet hat ist das Privat und sollte wirklich nicht benutzt werden, auch wenn es manchmal allzu Verlockend ist.

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().


Text() wird für a) Schwierig, für b) nicht, aber für a) kannst du ja auch die ttengine.library benutzen, habe ich damals ja auch. Ich würde aber b) Empfehlen.



[ - Antworten - Zitieren - Direktlink - ]

21.08.2006, 18:01 Uhr

bubblebobble
Posts: 707
Nutzer
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 ?

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

21.08.2006, 23:06 Uhr

DariusBrewka
Posts: 899
[Benutzer gesperrt]
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 ?


Ich habe das vor einiger Zeit auch gemacht und Bernd meinte das das auch ging, was bedeutet das Nummernzeichen denn?

[ - Antworten - Zitieren - Direktlink - ]

21.08.2006, 23:15 Uhr

bubblebobble
Posts: 707
Nutzer
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.

@Darius
das "#" beideutet, dass es eine Konstante ist.
C Progger können sich das einfach wegdenken.

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

21.08.2006, 23:21 Uhr

bubblebobble
Posts: 707
Nutzer
An all eOS4 user:

Könntet ihr mir den Wert von

RPTAG_APenColor
RPTAG_BPenColor

BMB_USERPRIVATE
BMF_USERPRIVATE

verraten ? Dann könnte ich auch OS4 supporten.

Bei den anderen Systemen heisst das

RPTAG_FgColor
RPTAG_BgColor

und das BMF_USERPRIVATE gibts wohl nicht.
Gibt es eine andere Methode/Flag, um eine Bitmap
als unswappable zu deklarieren ?

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

21.08.2006, 23:31 Uhr

DariusBrewka
Posts: 899
[Benutzer gesperrt]
Zitat:
Original von bubblebobble:
An all eOS4 user:

Könntet ihr mir den Wert von

RPTAG_APenColor
RPTAG_BPenColor


#define RPTAG_APenColor 0x80000009 /* get/set apen color 0xaarrggbb */
#define RPTAG_BPenColor 0x8000000A /* get/set bpen color 0xaarrggbb */

OS4 User mußt du nicht sein, das SDK kannst du dir auch so herunterladen.

[ - Antworten - Zitieren - Direktlink - ]

21.08.2006, 23:38 Uhr

DariusBrewka
Posts: 899
[Benutzer gesperrt]
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.


Dann solltest du dich an Bernd wenden, ich gebe bei meinem Programm immer eine Friendlybitmap an, aber damit konnte ich entgegen Thomas Aussage keine Pens setzen bei > 8 BIT Screens, erst als Bernd SetRPAttrs (..., PENColor), angefügt hat ging das.

Aber ggf. habe ich damals was Falsch gemacht.




[ - Antworten - Zitieren - Direktlink - ]

22.08.2006, 08:25 Uhr

bubblebobble
Posts: 707
Nutzer
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.

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

22.08.2006, 15:42 Uhr

whose
Posts: 2156
Nutzer
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

--
---

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

[ - Antworten - Zitieren - Direktlink - ]

22.08.2006, 16:22 Uhr

bubblebobble
Posts: 707
Nutzer
@whose

Was schlägst du nun konkret vor ?
Was meinst du mit eigener Palettenverwaltung ?
Ich brauche 24bit Grafik Funktionen auf eine Bitmap, die nicht mit einem Viewport verbunden ist.

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

22.08.2006, 16:54 Uhr

gni
Posts: 1106
Nutzer
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:
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.

[ - Antworten - Zitieren - Direktlink - ]

22.08.2006, 17:09 Uhr

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


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

22.08.2006, 17:28 Uhr

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

Was schlägst du nun konkret vor ?


Wenn Du palettenbasiert arbeiten musst, kann ich Dir nichts konkretes vorschlagen. Der Weg über AfA bzw. den finsteren "1 Pen für Alles"-Trick ist im Prinzip nicht schlecht, damit kannst Du viele Systeme abdecken, läßt aber die außen vor, die auf ihren alten 68K-Schätzchen nicht noch AfA installieren wollen. Das andere bedeutet halt mehr Arbeit und es ist die Frage, ob Dir der Weg gefällt. Aber mir fällt da gerade etwas auf: Hast Du einmal probiert, diesen "Trick" selbst anzuwenden? Wenn das auch auf 24Bit-Bitmaps ohne Viewport auf nicht AfA/MOS/OS4-Systemen anwendbar ist, wäre das doch die Lösung Deines Problems.

Zitat:
Was meinst du mit eigener Palettenverwaltung ?

Da Du erwähntest, daß das für ein Zeichenprogramm sein soll, gehe ich davon aus, daß Du dem Benutzer eine Palette für die Farben der jeweils gewählten Zeichenfunktion anbieten willst. Bei Modi bis 8Bit kannst Du dafür relativ problemlos die OS-Funktionen nutzen, bei Modi >8Bit halt nicht. Du müßtest also in diesem Fall für die vom Benutzer aus der angebotenen Palette gewählten Farbe den korrekten RGB-Wert selbst aus dem von Dir selbst angelegten und verwalteten Paletten-Array lesen, fürs Zeichnen setzen, (ich weiß, schlecht) das WritePixel()-Äquivalent von CGFX/P96 benutzen...

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

--
---

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


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

[ - Antworten - Zitieren - Direktlink - ]

22.08.2006, 17:35 Uhr

Holger
Posts: 8090
Nutzer
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 - ]

22.08.2006, 17:35 Uhr

whose
Posts: 2156
Nutzer
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".

Was man halt so "durchgesetzt" nennt. Es war verbreiteter, nichts desto trotz gabs für viele Programme eine Extra-P96-Unterstützung...

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

--
---

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

[ - Antworten - Zitieren - Direktlink - ]

22.08.2006, 17:43 Uhr

bubblebobble
Posts: 707
Nutzer
Also CGX und Picasso sind die letzen beiden "Lager" die am Ende doch noch (dank einsehen der Macher) zu 99% kompatibel wurden, sodass man
als Progger nicht auch noch diese Suppe auslöffeln musste.

Aber lasst dieses Thema hier bitte. Ich versuche eine Lösung zu erarbeiten, die auf allen System funktioniert, ohne dass ich Extra Würste braten muss.

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.
Ich werde es vermutlich so machen, dass ich eine weisse Bitmap nehme, dann mit schwarzem Pen zeichne (die Funktionen gehen ja, nur eben immer schwarz), und dann das ganze beim rüberblitten in das eigentliche Bild einfärbe. Da bekomme ich auch gleichzeitig den Alphachannel (invers) gratis geliefert.

Achja, ich will nur 24bit unterstützen, keine farbindizierten Screens oder Bilder.


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

22.08.2006, 17:55 Uhr

Holger
Posts: 8090
Nutzer
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.


Wer sagt denn, dass Du Text und die anderen Grafikprimitive gleich behandeln musst? Wenn Du AA-Fonts haben willst, kannst Du sie doch direkt z.B. via TTEngine in das TrueColor-Bild rendern.

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

[ - Antworten - Zitieren - Direktlink - ]

22.08.2006, 18:03 Uhr

bubblebobble
Posts: 707
Nutzer
@Holger

Ich schere gerne alles über einen Kamm. Dann muss ich nur eine Funktion Debuggen, Optimieren usw. anstatt von vielen.

Wenn ich Fonts über TTengine mache, bleibt ja nicht mehr viel.
Linien ziehen und Rechtecke malen hat man in 5min implementiert.(ohne AA).

Ich will natürlich nicht direkt in das Bild zeichnen, da ich ja auch den Alpha Channel updaten muss. Es soll ein Programm mit Layern werden.
Ich muss also wissen, welche Pixel wie stark gesetzt werden von der Zeichenoperation. Wenn es einmal ins Bild gemalt ist, kann ich das nichtmehr herausfinden. Ich komme also nicht drumerhum, einmal mit schwarz auf weiss zu Printen/Drawen/Rectfillen etc. Das nehme ich dann um den Alpha channel im Layer zu updaten und färbe das ganze beim Swappen ein (je nach DrawMode, auch abdunkeln, transparent, Effekte etc.)


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

22.08.2006, 18:17 Uhr

whose
Posts: 2156
Nutzer
@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

--
---

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

[ - Antworten - Zitieren - Direktlink - ]

22.08.2006, 18:23 Uhr

bubblebobble
Posts: 707
Nutzer
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.


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

22.08.2006, 18:38 Uhr

whose
Posts: 2156
Nutzer
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

--
---

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


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

[ - Antworten - Zitieren - Direktlink - ]


-1- 2 [ - Beitrag schreiben - ]


amiga-news.de Forum > Programmierung > BitMap aus PixelArray erzeugen [ - Suche - Neue Beiträge - Registrieren - Login - ]


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