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

amiga-news.de Forum > Programmierung > Kreis Zeichnen ohne graphics.library [ - Suche - Neue Beiträge - Registrieren - Login - ]

1 -2- 3 4 5 [ - Beitrag schreiben - ]

26.03.2008, 21:56 Uhr

Der_Wanderer
Posts: 1229
Nutzer
Das ist tatsächlich ein Problem, das auch ich noch nicht lösen konnte:

Unter OS3.x kann man nicht farbig auf eine Bitmap/Rastport zeichnen, der nicht mit einer Colmap verbunden ist, d.h. die Bitmap wurde mit einem friendly screen initialisiert.
Man kann nur in schwarz drauf zeichnen, egal was man anstellt. logischerweise bringen die Pens, die man via intuition bekommt, auf solch einer Bitmap nichts, weil beim zeichnen auf die Bitmap ja die Colmap nicht bekannt ist. Woher eine Bitmap seine Colmap kennt, ist in den Tiefen von Picasso/CGX versteckt, und nicht für den Programmierer erreichbar.

Allerdings glaube ich, MaikG hat das Konzept der Pens noch nicht verstanden.

Also:

1. Es gibt eine Farbtiefe, die ist z.B. bei OCS 12bit, bei AGA 24bit, bei Grafikkarten normalerweise 24bit, d.h. eine RGB Farbe ist in 24bits aufgelöst, macht also 256 Stufen pro Farbkomponente, zusammen 16,7 Mio Farbmischungen.

2. Eine Bitmap besitzt auch eine Tiefe, nicht zu verwechseln mit der o.g. Farbtiefe. Die kann unter OCS 1...6 bit sein, also 2 bis 64 Farben, bei AGA bis 8bit, also 256 Farben. Grafikkarten können normalerwiese 8, 16, 24 und 32 bit, wobei die Farbtiefe bei 8bit Bitmap 24bit ist, bei 16bit 16bit und bei 24/32bit 24bit.

3. Farb-Indiziert vs. True/Hi Color
Bei Colormap/Farb-Indiziert basierenden Bitmaps ist jeder Pixel eine Index Nummer (=Pen unter AmigaOS). Welche Farbe dieser Pixel tatsächlich hat, wird bei jedem Monitor Refresh dann aus einer Colormap herausgelesen. Ändert man die Colormap, ändert sich sofort auch die Farbe auf dem Bildschirm bei jedem Pixel, der den selben Index hat. So kennen wir das von OCS/AGA oder 8bit Graka Screens.

Bei True/Hi color ist das gaaanz anders. Da representiert ein Pixel direkt den RGB Wert, bei 16bit in 5-6-5bit Farbtiefe und bei 24/32bit als 8-8-8bit, wobei 32bit noch ein 8-bit Alpha Channel besitzt.
Hier mit Pens zu arbeiten macht nicht so viel Sinn, ist aber aus Kompatibelitätsgründen notwenig, da die graphics.library Befehle nunmal Pen basierend arbeiten.
Es gibt nach wie vor 256 Pens als hätten wir einen 256 Farb Screen(man könnte natürlich auch mehr machen aber dann gäbe es möglicherweise Kompatibelitätsprobleme, und 256 Pens sind ne Menge). Doch eine Änderung eines Pens lößt keine sichtbare Veränderung auf dem Screen aus, weil die Pixel ja keinen Index auf die Colormap sind, sondern direkt ihren echten Farbwert tragen, man müsste also die gesamte Bitmap durchkämmen, um eine Farbänderung zu erreichen.

4. Möglichkeiten zu malen
Als Pen kann man sich nun einen EINZIGEN Index exclusiv reservieren (ObrainPen) und ihn mittels SetRGB auf die gewünschte Farbe setzen, dann malen. Den Pen kann man immer wieder ändern und weitermalen, weil sich ja auf dem True-Color Screen nix ändert. Das geht natürlich nur auf True/Hicolor Screens, auf Farb-Indizierten Screens würde die Farbe wie wild herumspringen und man würde alles mit der gleichen Farbe (Pen) malen.
Wenn wir mit dem malen fertig sind, kann man den Pen wieder frei geben.

Oder man lässt sich vom OS einen ähnlichen Pen geben, und malt damit herum. So ist man kompatibel zu Farb-Indizierten Screens, bekommt aber nicht 100%ig die Farbe, die man will. Dafür läuft das Prog dann aber auch auf allen Screens, von 1...32bit. Das macht man normalerweise für GUI elemente oder Font farben, wo es nicht so genau sein muss. Für Bilder ist das natürlich nix.

Als drittes könnte man mit SetRPAttrs arbeiten, wie ich weiter oben gepostet habe. OS4, MOS, AROS und AfA OS kenn den sog. "penless mode",wo man statt mit SetAPen einen RGB Wert direkt setzen kann. Unter OS3.x braucht man dann aber AfA OS. Funktioniert allerdings auch nicht mit Bitmaps, die keinen friendly Screen haben. ;-)

Ich hoffe, das hat etwas Licht ins Dunkel gebracht.





--
Thilo Köhler, Author von:
HD-Rec, Sweeper, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ScreenCam, PerlinFX, MapEdit, TK AB3 Includes und viele mehr...
Homepage: http://www.hd-rec.de


[ - Antworten - Zitieren - Direktlink - ]

27.03.2008, 01:20 Uhr

NoImag
Posts: 1050
Nutzer
Zitat:
Original von Der_Wanderer:
Das ist tatsächlich ein Problem, das auch ich noch nicht lösen konnte:

Unter OS3.x kann man nicht farbig auf eine Bitmap/Rastport zeichnen, der nicht mit einer Colmap verbunden ist, d.h. die Bitmap wurde mit einem friendly screen initialisiert.
Man kann nur in schwarz drauf zeichnen, egal was man anstellt. logischerweise bringen die Pens, die man via intuition bekommt, auf solch einer Bitmap nichts, weil beim zeichnen auf die Bitmap ja die Colmap nicht bekannt ist. Woher eine Bitmap seine Colmap kennt, ist in den Tiefen von Picasso/CGX versteckt, und nicht für den Programmierer erreichbar.


Das gilt aber nur für Bitmaps mit mehr als 8 Bit. Ansonsten wird natürlich die gesetzte Pennummer in die Bitmap geschrieben. Welche Farbe sich hinter der Pennummer verbirgt, spielt beim Zeichnen noch keine Rolle, sondern erst bei der Darstellung. Wenn man die Bitmap z.B. drucken möchte, dann kann man die Colormap dem printer.device "nachreichen".

Tschüß



[ - Antworten - Zitieren - Direktlink - ]

27.03.2008, 01:37 Uhr

jochen22
Posts: 1139
[Benutzer gesperrt]
@Der_Wanderer:

Trivial scheint wohl zu stimmen. Von Computergrafik habe ich keine
Ahnung und mir deshalb auch noch nie über einen Kreiszeichenalgorithmus
Gedanken gemacht. Wenn ich mich aber recht entsinne ist mir diese
Vorgehensweise von SimonsBasic vom C64 bekannt.

Gruß Jochen


[ - Antworten - Zitieren - Direktlink - ]

27.03.2008, 11:09 Uhr

Der_Wanderer
Posts: 1229
Nutzer
@NoImag
Ja, ich meinte natürlich, dass auf 16/24/32bit Bitmaps nicht ohne verbundene ColorMap gezeichnet werden kann. Bei Farb-Indizierten Bitmaps wird natürlich die Pen Nummer eingetragen.

Der einzige Weg den ich kenne, eine 16/24bit Bitmap mit einer Colormap zu verbinden, ist sie mit einem Friendly Screen zu initialisieren. Dann kann man allerdings das Pixelformat nicht mehr kontrollieren und darf keine Annahmen darüber machen, darf also nicht mit eigenen Routinen hineinzeichnen und verliert auch möglicherweise an Qualität, wenn es z.B. ein 16bit Screen ist.
Und das will man ja nicht. Wäre ja blöd, z.B. ein Bild auszudrucken, und das Ergebnis wäre abhängig von dem Screen, den man gerade offen hat.



--
Thilo Köhler, Author von:
HD-Rec, Sweeper, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ScreenCam, PerlinFX, MapEdit, TK AB3 Includes und viele mehr...
Homepage: http://www.hd-rec.de


[ - Antworten - Zitieren - Direktlink - ]

27.03.2008, 18:08 Uhr

MaikG
Posts: 5172
Nutzer
>Was soll denn 10,0,0 sein?



0x0A
0x00
0x00



>Wenn Du ein sattes Rot haben willst, dann mußt Du das schon so
>machen:


Ja, schon klar. Ich drücks im bereich von 0-255 aus, weil man
das so überall einstellt. Bei Obtain gebe ich das immer in korrekter
weise an. Ich kann auch ein grelles rot, grün blau etc. bekommen.
Aber keine große anzahl von z.B. rottönen.

[ - Antworten - Zitieren - Direktlink - ]

27.03.2008, 18:59 Uhr

kev
Posts: 56
Nutzer
@MaikG:

Man hat dir doch schon breit und lang das Penkonzept erklärt. Also nochmal Du musst nur *einen* Stift allozieren (nicht für jeden Rotton) und dessen Farbe dann mittels SetRGB32() ändern. Das kann doch wirklich nicht so schwer zu verstehen sein.

[ - Antworten - Zitieren - Direktlink - ]

27.03.2008, 21:02 Uhr

NoImag
Posts: 1050
Nutzer
@Der_Wanderer:

Dass Dir das klar ist, war mir bewusst. Es ging mir darum, die Sache für Mitleser, die das Penkonzept vielleicht noch nicht richtig verstanden haben, vollständig zu beschreiben.

Wie man das Problem bei den Bitmaps mit mehr als 8 Bit lösen kann, habe ich auch keine Idee.
Was Dein Beispiel zum Drucken betrifft. Ist die Qualität bei einer 16-Bit-Vorlage soviel anders als bei einer 24-Bit-Vorlage? (Ich habe mich damit noch nicht so auseinandergesetzt.)

Tschüß



[ - Antworten - Zitieren - Direktlink - ]

27.03.2008, 22:12 Uhr

Mad_Dog
Posts: 1944
Nutzer
Zitat:
Original von kev:
@MaikG:

Also nochmal Du musst nur *einen* Stift allozieren (nicht für jeden Rotton) und dessen Farbe dann mittels SetRGB32() ändern. Das kann doch wirklich nicht so schwer zu verstehen sein.


Das ist EINE Möglichkeit. Aber man kann auch mehrere Stifte anfordern und sich die Stiftnummern in einem Array merken. So hat man auch auf einem Hi/Truecolor-Screen eine quasi-Palette.

Das habe ich auch in dem Mandelbrot-Beispiel in meinem C-Kurs so gemacht.

Aber wenn man schon explizit mit 24/32 Bit Farbtiefe Arbeiten möchte, dann kann man doch gleich die CybergraphX-Funktionen dazu benutzen. Das war ja auch die Eingangsidee von Mike. Für CybergraphX gibt es ja z.B. die Funktion WriteRGBPixel:

Zitat:
ULONG WriteRGBPixel(struct RastPort *rp, UWORD x, UWORD y, ULONG argb);

Zeichnet einen Pixel mit dem Farbwert argb (jeweils als 8 Bit AARRGGBB-Wert definiert) an der Position x,y in den RastPort.


Und wenn es unbedingt sein muß, kann man auch den guten, alten Bresenham aus der algorithmischen Mottenkiste holen, um Linien und Kreise zu zeichnen. Ich habe ja bis jetzt geglaubt, wenn man ein Betriebssystem mit diversen Grafikbibliotheken, von denen manche sogar Hardwarebeschleunigung anbieten, bräuchte man solche Low-Level Dinge (zumindest in der Anwendungsentwicklung) nicht mehr... ;)

Wenn WriteRGBPixel auch noch zuviel ist, kann man ja auch direkt in den Speicherbereich des Bitmaps schreiben, um die Farbwerte der Pixel zu setzen. Aber das wäre wieder mal komplett am Betriebssystem vorbei programmiert.


--
http://www.norman-interactive.com

[ - Antworten - Zitieren - Direktlink - ]

28.03.2008, 00:40 Uhr

MaikG
Posts: 5172
Nutzer
>Wie man das Problem bei den Bitmaps mit mehr als 8 Bit lösen kann, habe ich auch keine Idee.
>Ist die Qualität bei einer 16-Bit-Vorlage soviel anders als bei
>einer 24-Bit-Vorlage? (Ich habe mich damit noch nicht so auseinandergesetzt.)


Kommt vollkommen auf das Bild an. Wenn man viele, sehr änhliche
Töne hat merkt man es. Ansonsten ist es schwer zu unterscheiden.


Ich überlege grade ob man die Colormap von einen 24 Bit Screen
nicht einfach speichern kann und dann ohne Screen verwenden.
Weiss nur nicht ob die dann z.B. auch auf P96 und anderen Grafikkarten
die selbe ist. Möchte sagen Turboprint, Photogenics und Arteffect
z.B. drucken ja auch in 24 Bit ohne einen 24 Bit Screen Modus zu haben.

[ - Antworten - Zitieren - Direktlink - ]

28.03.2008, 09:03 Uhr

Holger
Posts: 8116
Nutzer
Zitat:
Original von NoImag:
Was Dein Beispiel zum Drucken betrifft. Ist die Qualität bei einer 16-Bit-Vorlage soviel anders als bei einer 24-Bit-Vorlage? (Ich habe mich damit noch nicht so auseinandergesetzt.)

Angesichts der Tatsache, wie die Mehrheit der Grafikkartentreiber (systemübergreifend) die 24->16Bit Konvertierung durchführt: ja, der Unterschied ist eklatant. Die Alternative sind auf 16Bit angepasste eigene Routinen. Was die Programmierung nicht einfacher macht.
Zitat:
Original von Mad_Dog:
Das ist EINE Möglichkeit. Aber man kann auch mehrere Stifte anfordern und sich die Stiftnummern in einem Array merken. So hat man auch auf einem Hi/Truecolor-Screen eine quasi-Palette.

Dann kommen wir aber schnell zu dem bereits diskutierten Problem, dass trotz truecolor keine Pens mehr frei sind, womit selbst der eine Pen für den zeichne-in-beliebiger-Farbe workaround nicht mehr vorhanden ist.
Zitat:
Aber wenn man schon explizit mit 24/32 Bit Farbtiefe Arbeiten möchte, dann kann man doch gleich die CybergraphX-Funktionen dazu benutzen. Das war ja auch die Eingangsidee von Mike. Für CybergraphX gibt es ja z.B. die Funktion WriteRGBPixel:
Du willst definitiv nicht Linien, Kreise, etc. mit Write...Pixel zeichnen.
Zitat:
Ich habe ja bis jetzt geglaubt, wenn man ein Betriebssystem mit diversen Grafikbibliotheken, von denen manche sogar Hardwarebeschleunigung anbieten, bräuchte man solche Low-Level Dinge (zumindest in der Anwendungsentwicklung) nicht mehr... ;)
Jetzt hast Du das Problem verstanden. a) OS-Funktion mit der potentiellen Beschleunigung/Optimierung aber den Limitierungen und b) Eigene Funktion ohne Limitierungen, aber definitiv ohne Beschleunigung.
Zitat:
Wenn WriteRGBPixel auch noch zuviel ist, kann man ja auch direkt in den Speicherbereich des Bitmaps schreiben, um die Farbwerte der Pixel zu setzen. Aber das wäre wieder mal komplett am Betriebssystem vorbei programmiert.
Wenn man das Datenformat der BitMap kennt, sollte man da hineinschreiben, und nicht den Overhead eine Funktionsaufrufs pro Pixel nehmen (sonst kannst Du Minuten auf den Kreis warten). Denk dran, wir reden von einer Offscreen-BitMap...
Zitat:
Original von MaikG:
Ich überlege grade ob man die Colormap von einen 24 Bit Screen
nicht einfach speichern kann und dann ohne Screen verwenden.
Weiss nur nicht ob die dann z.B. auch auf P96 und anderen Grafikkarten
die selbe ist. Möchte sagen Turboprint, Photogenics und Arteffect
z.B. drucken ja auch in 24 Bit ohne einen 24 Bit Screen Modus zu haben.

Du verwechselst da etwas. Zum Drucken einer TrueColor BitMap braucht man keine ColorMap. Jeder Pixel enthält ja seine TrueColor Farbe. Man braucht die ColorMap nur für die Zeichenbefehle, die auf einer Palette basieren.

ColorMaps sind, nebenbei gesagt, Strukturen, die man durchaus auch von Hand erzeugen kann. Das nützt nur nichts, da man sie nicht mit einer BitMap verknüpfen kann. Diese Verknüpfung entsteht im AOS3.x nur dadurch, dass ColorMap und BitMap im selben Screen verwendet werden. Deshalb geht ohne Screen nichts.

(Kleiner Tip am Rande: man kann Screens auch nicht-ziehbar, angeklebt hinter dem Screen, auf dem man das GUI laufen hat, öffnen. Ist aber auch nicht perfekt...)

mfg

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

[ - Antworten - Zitieren - Direktlink - ]

28.03.2008, 10:13 Uhr

Der_Wanderer
Posts: 1229
Nutzer
Wie Holger bereits erwähnt hat, mit Write...Pixel sollte man eigentlich nur Pixel zeichnen, keine Linien oder Kreise, da bei jedem Aufruf durch das ganze Layer-System gegangen wird. Das ist ein riessen Overhead. Minuten wirds wohl nicht dauern, aber ich schätze mal 100x so langsam wie direkt zeichnen könnte es schon sein.

Das eigentliche Problem was hier diskutiert wird (neben MaikG's Lern-Resistenz) ist, wie lege ich eine Offscreen Bitmap an, die 24bit hat, egal welcher Screenmode die Workbench hat, ausserdem soll es nicht im Graka RAM liegen damit sie auch schön gross sein kann. Und wie zeichne ich darauf herum ?

Genau diese Problem hatte ich bei der image.include von Amiblitz3. Dort kann man 24bit Bilder verwalten und anzeigen. Daraus will ich auch ein gescheites Grafikprogram entwickeln, und ich glaube kaum dass irgendjemand einsehen wird, dass seine Bilder getrashed werden, wenn er in einem 16bit modus arbeitet.

Da das OS hier keine Lösung anbietet, würde ich in deinem Fall tatsächlich dazu raten, alles per Hand zu machen.
Alos eine 24bit Bitmap allocieren, ohne friendly screen, und dann darauf zugreifen mit Peek&Poke. Am besten eine ARGB Bitmap, dann kannst du ummer per Langwort zugreifen, 24bit ist ein bisschen ekelig.

Text musst du dann per ttengine.library machen.
Als alternative kannst du auch einen temporären RastPort/Bitmap anlegen, ihn komplett weiss füllen (FillPixelArray), dann mit OS Funktionn draufzeichen, die sind ohne Colormap immer schwarz. Das ergebnis kannst du dann on-the-fly einfärben und auf deine Bitmap übertragen. So werde ich das wohl machen.


--
Thilo Köhler, Author von:
HD-Rec, Sweeper, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ScreenCam, PerlinFX, MapEdit, TK AB3 Includes und viele mehr...
Homepage: http://www.hd-rec.de


[ - Antworten - Zitieren - Direktlink - ]

28.03.2008, 10:24 Uhr

MaikG
Posts: 5172
Nutzer
Du verwechselst da etwas. Zum Drucken einer TrueColor BitMap braucht
>man keine ColorMap.


code:
POKEW pio& + IODRPReqio_Command%, PRD_DUMPRPORT&
				POKEL pio& + io_RastPort%, rp&
				POKEL pio& + io_ColorMap%, cm&   <------ !!!!????
				POKEL pio& + io_Modes%, modeID&
				POKEW pio& + io_SrcX%, x%
				POKEW pio& + io_SrcY%, y%
				POKEW pio& + io_SrcWidth%, x1%
				POKEW pio& + io_SrcHeight%, y1%



>Jeder Pixel enthält ja seine TrueColor Farbe.

Woher weiss das printer.device dann das?


>(Kleiner Tip am Rande: man kann Screens auch nicht-ziehbar,
>angeklebt hinter dem Screen, auf dem man das GUI laufen hat,
>öffnen. Ist aber auch nicht perfekt...)

Ich weiss auf graka geht das.

[ - Antworten - Zitieren - Direktlink - ]

30.03.2008, 20:16 Uhr

Holger
Posts: 8116
Nutzer
Zitat:
Original von Der_Wanderer:
Da das OS hier keine Lösung anbietet, würde ich in deinem Fall tatsächlich dazu raten, alles per Hand zu machen.
Alos eine 24bit Bitmap allocieren, ohne friendly screen, und dann darauf zugreifen mit Peek&Poke. Am besten eine ARGB Bitmap, dann kannst du ummer per Langwort zugreifen, 24bit ist ein bisschen ekelig.

Das hängt natürlich alles vom Anwendungsfall ab. Natürlich kann man auch mit anderen BitMaps hantieren, wenn es passt. Für einen 256-Farbverlauf reicht auch eine CLUT-basierte BitMap, da man da auch seine eigenen Farben benutzen kann.
Natürlich ist es so, dass einen BitMap, die im FastRAM, also weder Chip-RAM, noch Grafikkarten-RAM liegt, ohnehin von keiner hardwarebeschleunigten Zeichenfunktion profitieren kann. Somit ist das manuelle Zeichnen auch kein Problem.
Zitat:
Text musst du dann per ttengine.library machen.
Als alternative kannst du auch einen temporären RastPort/Bitmap anlegen, ihn komplett weiss füllen (FillPixelArray), dann mit OS Funktionn draufzeichen, die sind ohne Colormap immer schwarz. Das ergebnis kannst du dann on-the-fly einfärben und auf deine Bitmap übertragen. So werde ich das wohl machen.

Für welche Funktion? Ich meine, welche Funktion kann das OS so gut ausführen, dass ein manuelles Übertragen des Ergebnisses in eine Fast-RAM BitMap dadurch gerechtfertigt wird?

mfg

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

[ - Antworten - Zitieren - Direktlink - ]

30.03.2008, 20:21 Uhr

Holger
Posts: 8116
Nutzer
Zitat:
Original von MaikG:
code:
POKEL pio& + io_ColorMap%, cm&   <------ !!!!????


Was soll uns das sagen? Wir wissen alle, dass das API des printer.device zu einem Zeitpunkt definiert wurde, wo es noch keine TrueColor-BitMaps gab. Somit gibt es logischerweise einen ColorMap-Eintrag im IORequest. Und?
Zitat:
>Jeder Pixel enthält ja seine TrueColor Farbe.

Woher weiss das printer.device dann das?

Entschuldige, aber vielleicht solltest Du mal versuchen, Dir selbst folgende Fragen zu beantworten:
  • Was ist eine TrueColor-BitMap?
  • Was genau soll das printer.device mit einer ColorMap anfangen, wenn es eine TrueColor-BitMap drucken soll?

    Zitat:
    >(Kleiner Tip am Rande: man kann Screens auch nicht-ziehbar,
    >angeklebt hinter dem Screen, auf dem man das GUI laufen hat,
    >öffnen. Ist aber auch nicht perfekt...)

    Ich weiss auf graka geht das.

    Das geht selbstverständlich auch mit AGA.

    mfg

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

    [ - Antworten - Zitieren - Direktlink - ]

  • 30.03.2008, 22:41 Uhr

    MaikG
    Posts: 5172
    Nutzer
    >Was soll uns das sagen? Wir wissen alle, dass das API des printer.device
    >zu einem Zeitpunkt definiert wurde, wo es noch keine
    >TrueColor-BitMaps gab. Somit gibt es logischerweise einen
    >ColorMap-Eintrag im IORequest. Und?


    Gebe ich keine ColorMap an bekomme ich einen Enforcer Hit
    vom printer.device.
    Erstaunlicher weise sind die farben korrekt. Muss mal sehen
    was passiert wenn ich den modeid eintrag auch wegnehme.


    >Entschuldige, aber vielleicht solltest Du mal versuchen, Dir selbst
    >folgende Fragen zu beantworten:

    > o Was ist eine TrueColor-BitMap?
    > o Was genau soll das printer.device mit einer ColorMap anfangen,
    > wenn es eine TrueColor-BitMap drucken soll?

    Gegenfrage, woher weiss das printer.device das die
    Pixel in der BitMap im Format ARGB sind? Könnte auch RGBA sein
    oder RGB.
    Ich kann auch nicht sagen ob es da draussen irgendwo eine Graka
    gibt die bei 24 Bit noch mit einen Pen artigen Format arbeitet.


    >Das geht selbstverständlich auch mit AGA.

    Schon, aber nicht mit 24 Bit.

    [ - Antworten - Zitieren - Direktlink - ]

    31.03.2008, 09:07 Uhr

    Holger
    Posts: 8116
    Nutzer
    Zitat:
    Original von MaikG:
    Gegenfrage, woher weiss das printer.device das die
    Pixel in der BitMap im Format ARGB sind? Könnte auch RGBA sein
    oder RGB.

    Das originale printer.device weiß es natürlich nicht, kann aber sowieso mit keinem dieser Formate etwas anfangen. Das erweiterte oder gepatchte printer.device fragt einfach P96 oder CGX, in welchem Format die BitMap vorliegt. Andernfalls würde das Drucken komplett fehlschlagen.
    Zitat:
    >Das geht selbstverständlich auch mit AGA.
    Schon, aber nicht mit 24 Bit.

    Worum ging es eigentlich?
    Ursprünglich ging es um die Frage, wie man eine BitMap mit einer ColorMap verbindet. Und das kann man mit einem unsichtbaren Screen machen => auch unter AGA.
    Eine solche BitMap mit bis zu 256 Farben kann man dann auch auf eine TrueColor-BitMap blitten, womit sich der Kreis schließt. Das setzt natürlich trotzdem die Präsenz von CGX oder P96 oder vergleichbarem im System voraus, andernfalls kann man ja gar keine TrueColor-BitMap anlegen, weder im GraKa- noch im Fast-RAM.

    mfg

    --

    [ Dieser Beitrag wurde von Holger am 31.03.2008 um 09:10 Uhr geändert. ]

    [ - Antworten - Zitieren - Direktlink - ]

    31.03.2008, 09:48 Uhr

    Mad_Dog
    Posts: 1944
    Nutzer
    Ich habe jetzt mal den Bresenham in einer Pen-basierten Version implementiert:
    c code:
    /*
     *  bresenham.h
     *
     *  Grafikfunktionen zum Zeichnen von Linien und Keisen mit Hilfe des
     *  Bresenham Algorithmus.
     *
     *  Autor: Norman Walter
     *  Datum: 30.3.2008
     *
     */
    
    #ifndef BRESENHAM_H
    #define BRESENHAM_H
    
    #include <exec/types.h>
    
    #include <proto/exec.h>
    
    #define SGN(x) (x > 0) ? 1 : (x < 0) ? -1 : 0
    
    /*
     *  struct raster_bitmap
     *
     *  In dieser Struktur sind die Parameter für das Bitmap zusammengefasst.
     *  Nachdem mit Hilfe der Funktion AllocRasterBitmap eine Instanz dieser Struktur
     *  erzeugt wurde, zeigt der Zeiger *data auf den Speicherbereich, in dem das
     *  eigentliche Bitmap mit der Größe size Byte liegt.
     *
     *  Die Funktionen ClearRaster, setpixel, rasterLine und rasterCircle schreiben
     *  ihre Daten in diesen Speicherbereich. Der Zeiger *date kann anschließend
     *  mit Hilfe der Funktion WritePixelArray8 aus der graphics.library in einen
     *  RastPort geschrieben werden.
     *
     */
    struct raster_bitmap
    {
      unsigned int width;   // Breite des Bitmaps
      unsigned int height;  // Höhe des Bitmaps
      UBYTE color;          // Aktuelle Pen Nummer
      ULONG size;           // Größe des bitmapy in Byte
      UBYTE *data;          // Bilddaten des Bitmaps
    };
    
    /*
     *  AllocRaster
     *
     *  Legt eine raster_bitmap-Struktur an und initialisiert diese
     *
     *  Eingabe:	 unsigned int width  - Breite des Bitmaps in Pixel
     *           	 unsigned int height - Höhe des Bitmaps in Pixel
     *
     *  Rückgabe:    ein Zeiger auf eine raster_bitmap Struktur
     *
     */
    struct raster_bitmap * AllocRasterBitmap(unsigned int width, unsigned int height);
    
    /*
     *  FreeRasterBitmap
     *
     *  Gibt den Speicher einer raster_bitmap Struktur wieder frei.
     *
     *  Einganbe:	struct raster_bitmap *bm - Zeiger auf raster_bitmap Struktur
     *
     */
    void FreeRasterBitmap(struct raster_bitmap *bm);
    
    /*
     *  rasterLine
     *
     *  Zeichnet eine Linie von xstart, ystart nach xend, yend in der angegebenen
     *  raster_bitmap Struktur bm.
     *
     *  Eingabe:	struct raster_bitmap *bm - Zeiger auf raster_bitmal Struktur
     *		int xstart,ystart - Koordinaten des Anfangspunkts der Linie
     *              int xend, yend - Koordinaten des Endpunkts der Linie
     *
     */
    void rasterLine(struct raster_bitmap *bm,int xstart,int ystart,int xend,int yend);
    
    /*
     *  ClearRaster
     *
     *  Löscht den Inhalt des raster_bitmap bm mit der Farbe col.
     *
     *  Eingabe:	struct raster_bitmap *bm - Zeiger auf raster_bitmal Struktur
     *		UBYTE col - Pen Nr.
     *
     */
    void ClearRaster(struct raster_bitmap *bm,UBYTE col);
    
    /*
     *  SetColor
     *
     *  Stellt die Zeichenfarbe des raster_bitmap für Zeichenoperationen ein.
     *
     *  Eingabe:	struct raster_bitmap *bm - Zeiger auf raster_bitmal Struktur
     *		UBYTE col - Pen Nr.
     *
     */
    void SetColor(struct raster_bitmap *bm, UBYTE col);
    
    /*
     *  setpixel
     *
     *  Setzt den Bildpunkt x,y in der Farbe des eingestellten Pens.
     *
     *  Eingabe:	struct raster_bitmap *bm - Zeiger auf raster_bitmal Struktur
     *		unsigned int x,y - Koordinaten des Bildpunkts
     *
     */
    void setpixel(struct raster_bitmap *bm, unsigned int  x, unsigned int y);
    
    /*
     *  rasterCircle
     *
     *  Zeichnet einen Kreis mit Radius radius um den Kreismittelpunkt x0,y0.
     *
     *  Eingabe:	struct raster_bitmap *bm - Zeiger auf raster_bitmal Struktur
     *		int y0,y0 - Koordinaten des Kreismittelpunks.
     *              int radius - Radius des Kreises
     *
     */
    void rasterCircle(struct raster_bitmap *bm, int x0, int y0, int radius);
    
    #endif

    c code:
    /*
     *  bresenham.c
     *
     *  Autor: Norman Walter
     *  Datum: 30.3.2008
     *
     */
    
    #ifndef BRESENHAM_H
    #include "bresenham.h"
    #endif
    
    struct raster_bitmap * AllocRasterBitmap(unsigned int width, unsigned int height)
    {
       struct raster_bitmap *bm;
    
       bm = (struct raster_bitmap *)AllocVec(sizeof(struct raster_bitmap),NULL);
       bm->width = width;
       bm->height = height;
       bm->size = width * height;
       bm->color = 1;
       bm->data = (UBYTE *)AllocVec(bm->size, MEMF_CLEAR);
    
       return bm;
    }
    
    void FreeRasterBitmap(struct raster_bitmap *bm)
    {
       FreeVec(bm->data);
       FreeVec(bm);
    }
    
    void ClearRaster(struct raster_bitmap *bm,UBYTE col)
    {
       ULONG i;
       
       for (i=0; i < bm->size ; i++)
       {
    	bm->data[i] = col;
       }
    
    }
    
    void SetColor(struct raster_bitmap *bm, UBYTE col)
    {
        bm->color = col;
    }
    
    void setpixel(struct raster_bitmap *bm, unsigned int x, unsigned int y)
    {
        if (x >= 0 && x < bm->width && y >= 0 && y < bm->height)
        {
    	bm->data[bm->width * y + x] = bm->color;
        }
    }
    
    void rasterLine(struct raster_bitmap *bm,int xstart,int ystart,int xend,int yend)
    {
       int x, y, t, dx, dy, incx, incy, pdx, pdy, ddx, ddy, es, el, err;
     
    /* Entfernung in beiden Dimensionen berechnen */
       dx = xend - xstart;
       dy = yend - ystart;
     
    /* Vorzeichen des Inkrements bestimmen */
       incx = SGN(dx);
       incy = SGN(dy);
       if(dx<0) dx = -dx;
       if(dy<0) dy = -dy;
     
    /* feststellen, welche Entfernung größer ist */
       if (dx>dy)
       {
          /* x ist schnelle Richtung */
          pdx=incx; pdy=0;    /* pd. ist Parallelschritt */
          ddx=incx; ddy=incy; /* dd. ist Diagonalschritt */
          es =dy;   el =dx;   /* Fehlerschritte schnell, langsam */
       }
       else
       {
          /* y ist schnelle Richtung */
          pdx=0;    pdy=incy; /* pd. ist Parallelschritt */
          ddx=incx; ddy=incy; /* dd. ist Diagonalschritt */
          es =dx;   el =dy;   /* Fehlerschritte schnell, langsam */
       }
     
    /* Initialisierungen vor Schleifenbeginn */
       x = xstart;
       y = ystart;
       err = el/2;
       setpixel(bm,x,y);
     
    /* Pixel berechnen */
       for(t=0; t<el; ++t) /* t zaehlt die Pixel, el ist auch Anzahl */
       {
          /* Aktualisierung Fehlerterm */
          err -= es; 
          if(err<0)
          {
              /* Fehlerterm wieder positiv (>=0) machen */
              err += el;
              /* Schritt in langsame Richtung, Diagonalschritt */
              x += ddx;
              y += ddy;
          }
          else
          {
              /* Schritt in schnelle Richtung, Parallelschritt */
              x += pdx;
              y += pdy;
          }
    
          setpixel(bm,x,y);
       }
    } /* gbham() */
    
    void rasterCircle(struct raster_bitmap *bm, int x0, int y0, int radius)
    {
        int f = 1 - radius;
        int ddF_x = 0;
        int ddF_y = -2 * radius;
        int x = 0;
        int y = radius;
     
        setpixel(bm, x0, y0 + radius);
        setpixel(bm, x0, y0 - radius);
        setpixel(bm, x0 + radius, y0);
        setpixel(bm, x0 - radius, y0);
     
        while(x < y) 
        {
          if(f >= 0) 
          {
            y--;
            ddF_y += 2;
            f += ddF_y;
          }
          x++;
          ddF_x += 2;
          f += ddF_x + 1;
     
          setpixel(bm, x0 + x, y0 + y);
          setpixel(bm, x0 - x, y0 + y);
          setpixel(bm, x0 + x, y0 - y);
          setpixel(bm, x0 - x, y0 - y);
          setpixel(bm, x0 + y, y0 + x);
          setpixel(bm, x0 - y, y0 + x);
          setpixel(bm, x0 + y, y0 - x);
          setpixel(bm, x0 - y, y0 - x);
        }
    }


    Den vollständigen Code samt Demoprogramm habe ich in ein lha-Archiv gepackt: bresenham.lha

    Das funktioniert recht gut und ist auch von der Geschwindigkeit akzeptabel. Die Komponente *data der struct raster_bitmap kann man mit Hilfe der Funktion WritePixelArray8() auf einen RastPort bekommen.

    Wenn man die Funktion setpixel Geringfügig umbaut, so daß keine Pen-Nummern, sondern Langwörter der Form AARRGGBB eingetragen werden,
    so kann man einfach eine 32-Bit-Variante (8 Bit je Farbkompunente + 8 Bit Alpha) bekommen und das Ergebnis dann mit der CybergraphX-Funktion WritePixelArray() auf einen RastPort bekommen.

    --
    http://www.norman-interactive.com

    [ Dieser Beitrag wurde von Mad_Dog am 31.03.2008 um 12:03 Uhr geändert. ]

    [ - Antworten - Zitieren - Direktlink - ]

    31.03.2008, 09:54 Uhr

    Mad_Dog
    Posts: 1944
    Nutzer
    Zitat:
    Original von Holger:
    Das setzt natürlich trotzdem die Präsenz von CGX oder P96 oder vergleichbarem im System voraus, andernfalls kann man ja gar keine TrueColor-BitMap anlegen, weder im GraKa- noch im Fast-RAM.


    Wenn Du die BitMap-Struktur des AmigaOS meinst, so ist das zutreffend.
    Ein blankes 24 (oder 32)-Bit (Chunky-)Bitmap kann man aber immer haben, wenn man das mit der Hand am Arm ausprogrammiert, d.h. sich Speicher der Größe Höhe*Breite*Bytes per Pixel beschafft, und dann eine Funktion schreibt, die die Bytes entsprechend der RGB(A)-Komponenten setzt. Für die Grafikprimitiven wird einem dann allerdings nichts anderes übrig bleiben, als diese ebenfalls selbst (z.B. Bresenham) zu programmieren.

    --
    http://www.norman-interactive.com

    [ Dieser Beitrag wurde von Mad_Dog am 31.03.2008 um 09:57 Uhr geändert. ]

    [ - Antworten - Zitieren - Direktlink - ]

    31.03.2008, 18:11 Uhr

    MaikG
    Posts: 5172
    Nutzer
    >Das originale printer.device weiß es natürlich nicht, kann aber
    >sowieso mit keinem dieser Formate etwas anfangen. Das erweiterte
    >oder gepatchte printer.device fragt einfach P96 oder CGX,
    >in welchem Format die BitMap vorliegt. Andernfalls würde das
    >Drucken komplett fehlschlagen.


    Das ist gut. Danach ist es dann ein Bug das versucht wird eine
    Colormap zu verwenden?
    Man kann es ja trotzdem niemand zumuten einen Hit zu bekommen
    wenn man druckt.


    Worum ging es eigentlich?

    >Ursprünglich ging es um die Frage, wie man eine BitMap mit einer
    >ColorMap verbindet. Und das kann man mit einem unsichtbaren Screen
    >machen => auch unter AGA.

    Dann wäre die CM nur mit 256 Farben. Wiederrum, wenn die CM
    gar nicht ausgewertet wird kann ich auch einen AllocVec bereich
    angeben wo nix drin ist.

    >Eine solche BitMap mit bis zu 256 Farben kann man dann auch auf
    >eine TrueColor-BitMap blitten, womit sich der Kreis schließt.
    >Das setzt natürlich trotzdem die Präsenz von CGX oder P96 oder
    >vergleichbarem im System voraus, andernfalls kann man ja gar
    >keine TrueColor-BitMap anlegen, weder im GraKa- noch im Fast-RAM.

    Unter AGA bekommt man aber keine Auflösungen ala 1600x1200x8
    ins Chipmem von daher kann man von einem Screen legendlich die
    CM nutzen oder Hackstückeln.

    [ - Antworten - Zitieren - Direktlink - ]

    31.03.2008, 22:51 Uhr

    Holger
    Posts: 8116
    Nutzer
    Zitat:
    Original von Mad_Dog:
    Wenn Du die BitMap-Struktur des AmigaOS meinst, so ist das zutreffend.
    Ein blankes 24 (oder 32)-Bit (Chunky-)Bitmap kann man aber immer haben, wenn man das mit der Hand am Arm ausprogrammiert, d.h. sich Speicher der Größe Höhe*Breite*Bytes per Pixel beschafft, und dann eine Funktion schreibt, die die Bytes entsprechend der RGB(A)-Komponenten setzt.

    Das ist dann ein Grafikpuffer, aber keine BitMap. BitMap ist die Struktur, die vom AmigaOS als solche definiert wird. Und die kannst Du nicht in 24 Bit von Hand anlegen, weil der Aufbau nicht spezifiziert ist. Weder das printer.device, noch die graphics.library, noch irgendein anderer Teil des AmigaOS kann mit Deinem von Hand angelegtem Puffer etwas anfangen. Und wenn sowohl Bildschirm-, als auch Drucker-Ausgabe darauf hinauslaufen, dass Du Deinen privaten Puffer von Hand in eine AGA-BitMap konvertieren musst, solltest Du Dir dreimal überlegen, ob es wirklich sinnvoll ist, von Hand in Deinem Puffer zu zeichnen, statt in die BitMap, in die Du sowieso konvertieren musst...

    mfg

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

    [ - Antworten - Zitieren - Direktlink - ]

    31.03.2008, 23:21 Uhr

    NoImag
    Posts: 1050
    Nutzer
    Zitat:
    Original von Holger:
    Das ist dann ein Grafikpuffer, aber keine BitMap. BitMap ist die Struktur, die vom AmigaOS als solche definiert wird. Und die kannst Du nicht in 24 Bit von Hand anlegen, weil der Aufbau nicht spezifiziert ist. Weder das printer.device, noch die graphics.library, noch irgendein anderer Teil des AmigaOS kann mit Deinem von Hand angelegtem Puffer etwas anfangen. Und wenn sowohl Bildschirm-, als auch Drucker-Ausgabe darauf hinauslaufen, dass Du Deinen privaten Puffer von Hand in eine AGA-BitMap konvertieren musst, solltest Du Dir dreimal überlegen, ob es wirklich sinnvoll ist, von Hand in Deinem Puffer zu zeichnen, statt in die BitMap, in die Du sowieso konvertieren musst...


    Soweit ich mich entsinne, bietet das printer.device V44 die Möglichkeit, einen Grafikpuffer zu übergeben.

    Tschüß



    [ - Antworten - Zitieren - Direktlink - ]

    31.03.2008, 23:27 Uhr

    Mad_Dog
    Posts: 1944
    Nutzer
    Zitat:
    Original von Holger:
    Zitat:
    Original von Mad_Dog:
    Wenn Du die BitMap-Struktur des AmigaOS meinst, so ist das zutreffend.
    Ein blankes 24 (oder 32)-Bit (Chunky-)Bitmap kann man aber immer haben, wenn man das mit der Hand am Arm ausprogrammiert, d.h. sich Speicher der Größe Höhe*Breite*Bytes per Pixel beschafft, und dann eine Funktion schreibt, die die Bytes entsprechend der RGB(A)-Komponenten setzt.


    Das ist dann ein Grafikpuffer, aber keine BitMap.


    Sag ich doch. Nenne es meinetwegen "Software-Framebuffer".

    Zitat:
    Weder das printer.device, noch die graphics.library, noch irgendein anderer Teil des AmigaOS kann mit Deinem von Hand angelegtem Puffer etwas anfangen.

    Mit Hilfe der CybergraphiX Funktion WritePixelArray() (Nicht zu verwechseln mit der OS 3.1-Funktion WritePixelArray8()) Kann man das sehr wohl in einen RastPort einbringen und anschließend Systemkonform damit umgehen.

    Mit AGA sehe ich irgendwie keinen Sinn in der Sache, das führt an der eigentlichen Fragestellung vorbei. Mike will ja eine 24 Bit Grafik auch in 24 Bit und nicht in einer runtergerechneten 8 Bit Version drucken.

    Ohne CybergraphX oder ein vergleichbares Grafiksystem sehe ich im Moment nicht, wie man das sonst systemkonform lösen könnte.



    --
    http://www.norman-interactive.com

    [ Dieser Beitrag wurde von Mad_Dog am 31.03.2008 um 23:28 Uhr geändert. ]

    [ - Antworten - Zitieren - Direktlink - ]

    01.04.2008, 00:05 Uhr

    MaikG
    Posts: 5172
    Nutzer
    >Ohne CybergraphX oder ein vergleichbares Grafiksystem sehe ich im
    >Moment nicht, wie man das sonst systemkonform lösen könnte.

    BTW.

    wie macht man ein AllocBitMap unter OS4?


    Nach:

    bm&=AllocBitMap&(1600,1200,24,BMF_CLEAR&,NULL&)

    verabschiedet sich OS4.

    [ - Antworten - Zitieren - Direktlink - ]

    01.04.2008, 14:34 Uhr

    MaikG
    Posts: 5172
    Nutzer
    Kleine korrektur, der absturz kommt vom Print der mitteilen
    soll das bm&=NULL ist. Hatte kein Basic Fenster mehr offen.

    Vielleicht versucht OS4 die Bitmap im ChipMem zu erzeugen,
    da OS4 immernoch selbst ChipMem verbraucht könnte ich mir
    das vorstellen.


    Wegen der Colormap, ich hab mir mal selbst eine Leere gemacht
    mit einem Pointer auf einen Leeren Colortable. Modeid hab ich auch
    Leergelassen. Das Drucken scheint immernoch zu Funktionieren.
    Wichtig ist wohl bloß der gültige Colortable pointer für das printer.device,
    damit es keinen Hit gibt.

    [ - Antworten - Zitieren - Direktlink - ]

    01.04.2008, 15:46 Uhr

    kev
    Posts: 56
    Nutzer
    p96 erzeugt eine BitMap, solange nicht BMF_DISPLAYABLE gesetzt ist, im FastRam, wenn es über die entsprechende ENV Option aktiviert wurde. Um eine Directmapped BitMap zu allozieren geht man allerdings andere Wege. Entweder p96AllocBitMap() oder per AllocBitMap()/BMF_SPECIALFMT bzw. TagList unter os4.

    [ - Antworten - Zitieren - Direktlink - ]

    01.04.2008, 17:27 Uhr

    MaikG
    Posts: 5172
    Nutzer
    >p96 erzeugt eine BitMap, solange nicht BMF_DISPLAYABLE gesetzt ist,
    >im FastRam, wenn es über die entsprechende ENV Option aktiviert
    >wurde.

    Sowas wie Planes2Fast, was wiederum inkompatiblitäten verursacht?
    Warum hält man es nicht wie CGX, alles was >8Bit ist ins Fastram
    und gut ists.



    >Um eine Directmapped BitMap zu allozieren geht man allerdings andere
    >Wege. Entweder p96AllocBitMap() oder per AllocBitMap()/BMF_SPECIALFMT
    >bzw. TagList unter os4.


    Na dann guck ich mir BMF_SPECIALFMT nochmal an.

    [ - Antworten - Zitieren - Direktlink - ]

    01.04.2008, 17:44 Uhr

    Der_Wanderer
    Posts: 1229
    Nutzer
    >Warum hält man es nicht wie CGX, alles was >8Bit ist ins Fastram
    und gut ists.
    Weil alles, was im FastRAM liegt, durch den Zorro/PCI/AGP/EPCI bus gequetscht werden muss, sobald man es sehen will, sprich, wenn man es auf den Bildschirm blittet.
    Bei PCI oder schneller ist das noch ok, aber ZorroII ist da viel langsamer als wenn sich die Bitmap bereits auf der Grafikkarte befindet.

    --
    Thilo Köhler, Author von:
    HD-Rec, Sweeper, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ScreenCam, PerlinFX, MapEdit, TK AB3 Includes und viele mehr...
    Homepage: http://www.hd-rec.de


    [ - Antworten - Zitieren - Direktlink - ]

    01.04.2008, 18:32 Uhr

    MaikG
    Posts: 5172
    Nutzer
    >>Warum hält man es nicht wie CGX, alles was >8Bit ist ins Fastram
    >>und gut ists.
    >Weil alles, was im FastRAM liegt, durch den Zorro/PCI/AGP/EPCI bus gequetscht werden muss, sobald man es sehen will, sprich, wenn man es auf den Bildschirm blittet.
    >Bei PCI oder schneller ist das noch ok, aber ZorroII ist da viel langsamer als wenn sich die Bitmap bereits auf der Grafikkarte befindet.


    Es liegt doch eh immer eine Kopie der Grafikdaten im Fastram.
    Aber ich glaub ich hab mich falsch ausgedrückt, OS4 versucht
    1600x1200x24 ins Chipram - die 2 MB auf dem Motherboard - AGA
    zu legen. Nicht in den Grafikkartenspeicher.



    bm& = AllocBitMap&(1600, 1200, 24, BMF_CLEAR& OR PIXFMT_RGB24&, NULL&)

    Schlägt ebenfalls fehl!?

    [ - Antworten - Zitieren - Direktlink - ]

    01.04.2008, 18:36 Uhr

    Der_Wanderer
    Posts: 1229
    Nutzer
    Ich lege meine Bitmaps so an:

    bitmap_ptr = AllocBitMap_(width,height,24,#BMF_MINPLANES|#BMF_SPECIALFMT|#F_ARGB32,0)

    Das klappt auch unter OS4.


    --
    Thilo Köhler, Author von:
    HD-Rec, Sweeper, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ScreenCam, PerlinFX, MapEdit, TK AB3 Includes und viele mehr...
    Homepage: http://www.hd-rec.de


    [ - Antworten - Zitieren - Direktlink - ]

    01.04.2008, 18:58 Uhr

    MaikG
    Posts: 5172
    Nutzer
    >bitmap_ptr = AllocBitMap_(width,height,24,#BMF_MINPLANES|#BMF_SPECIALFMT|#F_ARGB32,0)

    Ein BMF_SPECIALFMT gibt nicht in meinen Basic includes und auch
    nicht im NDK3.9

    Also habe ich das einfach weggelassen, selbes ergebniss.

    [ - Antworten - Zitieren - Direktlink - ]


    1 -2- 3 4 5 [ - Beitrag schreiben - ]


    amiga-news.de Forum > Programmierung > Kreis Zeichnen ohne graphics.library [ - Suche - Neue Beiträge - Registrieren - Login - ]


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