Ja, mit denn Datatypes bekomme ich noch graue Haare und auch mit dem Problem das ich kein Englisch kann und somit die Doku nicht versteh.

So, jetzt aber Schritt für Schritt:
Ich hab es damals mal geschaft ein Programm mit Eurer Hilfe zu schreiben das ein Bild mit Datatypes in ein Fenster läd und es auch gleich auf die entsprechende Farbtiefe runterrechnet.

So, ich möchte jetzt aber das ein Bild mit Datatypes geöffnet wird, auch wieder auf die Auflösung der WB(öffentlicher Pubscreen) runtergerechnet wird, aber *nicht* ausgegeben wird. Ich hab da was beim Thomas auf der Homepage gefunden was der Sache sehr nahe kommt -> load_pic.c

Ihr werdet es kaum glauben, aber ich versteh das schon fast zu 95%, aber es hängt noch mit dem runterrechnen. Vorallem wenn es geht ohne Dither, bzw. höchstens als Option.

Ich möchte mich auch gleich für die ollen Kamellen entschuldigen, ich vermute mal das das hier schon recht oft durchgekaut worden ist, aber für mich sind die Datatypes als noch ein Buch mit 5 Siegel (2 sind schon beseitigt, denk ich... )
--
http://www.alternativercomputerclub.de.vu

[ - Answer - Quote - Direct link - ]

code:

---

WBToScreen 0
Window 0,0,0,320,200,$E,"Test",1,0

If image_load{0,"Work:MyPic.png",$000000,1,#DITHERMODE_NONE}
   ...
   image_blit{0,x,y}
   ...
EndIf

End

---

[ - Answer - Quote - Direct link - ]

Zitat:

---

Original von bubblebobble:
So einfach wäre's mit Amiblitz ;-)

---

Zja, aber leider läuft AmitBlitz2 nicht ohne Grafikkarte, jedenfalls der Editor/Compiler.
Sieht übrigens gut aus mit AmiBlitz2.

Aber wie sieht es aus wenn man es ohne AmiBlitz2-Befehle machen würde?
--
http://www.alternativercomputerclub.de.vu

[ - Answer - Quote - Direct link - ]

[ - Answer - Quote - Direct link - ]

Zitat:

---

Original von Ralf27:
bzw. deutsche doku für die Datatypes...
--
http://www.alternativercomputerclub.de.vu

---

[ - Answer - Quote - Direct link - ]

Zitat:

---

Original von Kaesebroetchen:
Wenn du deutsche doku fürs programmieren brauchst, musst du sie dir schon selber schreiben...

---

Zitat:

---

Selbst auf Massen Systemen wie Windows, kommst du ohne Englisch nicht weiter.
Und gerade auf dem Amiga bin ich schon froh wenn ich überhaupt
eine Dokumentation finde.

Soll jetzt kein gestenker sein, ich will dich nur motivieren mal über den (sprachlichen) Tellerrand zu schauen...

---

[ - Answer - Quote - Direct link - ]

@Ralf27:

Die Bitmap verdeckt zu laden ist im Grunde nicht schwer. Mit dem Programm von Thomas hast Du im Grunde schon alles, was Du dafür brauchst. Soweit ich mich an sein Prog erinnern kann, blittet es das Bild direkt in ein Fenster auf der WB, nachdem es vorher in eine eigene (nicht sichtbare!) Bitmap geladen wurde. Schaus Dir doch noch mal genau an.

Die Frage der Farbtiefe dürfte ein Blick auf den Teil mit "AllocBitMap()" klären, damit wird festgelegt, welches Format die Bitmap letztendlich bekommt. Meist wird ein "Friend" angegeben, eine auf diese Art angelegte Bitmap hat dann das gleiche Format. Wird also die Bitmap des WB-Screens als Friend angegeben, bekommt die neu angelegte Bitmap das gleiche Format wie der WB-Screen (sofern technisch möglich).

Grüße

--
---

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

[ - Answer - Quote - Direct link - ]

Zitat:

---

Original von whose:
Die Bitmap verdeckt zu laden ist im Grunde nicht schwer. Mit dem Programm von Thomas hast Du im Grunde schon alles, was Du dafür brauchst. Soweit ich mich an sein Prog erinnern kann, blittet es das Bild direkt in ein Fenster auf der WB, nachdem es vorher in eine eigene (nicht sichtbare!) Bitmap geladen wurde. Schaus Dir doch noch mal genau an.

Die Frage der Farbtiefe dürfte ein Blick auf den Teil mit "AllocBitMap()" klären, damit wird festgelegt, welches Format die Bitmap letztendlich bekommt. Meist wird ein "Friend" angegeben, eine auf diese Art angelegte Bitmap hat dann das gleiche Format. Wird also die Bitmap des WB-Screens als Friend angegeben, bekommt die neu angelegte Bitmap das gleiche Format wie der WB-Screen (sofern technisch möglich).

---

code:

---

file$="Programme:Prog/MaxonBasic/progs/offen_homepage/Soduko1/daten/Standard9.pic"

TAGLIST tll&, _
DTA_GroupID&, GID_PICTURE&, _
DTA_FREESOURCEBITMAP&, TRUE&, _
PDTA_Remap&, TRUE&, _
TAG_END&


o&=NewDTObjectA&(SADD(file$+CHR$(0)),tll&)
IF o& THEN
 TAGLIST tll&, _
 DTM_PROCLAYOUT&, TRUE&, _
 TAG_END&

 IF DoDTMethodA&(o&,0,0,tll&) THEN
  TAGLIST tll&, _
  PDTA_DestBitMap&, VARPTR(bitmap&), _
  DTA_NominalHoriz&, VARPTR(nomwidth&), _
  DTA_NominalVert&, VARPTR(nomheight&), _
  TAG_END&
  junk&=GetDTAttrsA&(o&,tll&)
  PRINT bitmap&, nomwidth&, nomheight&
 END IF
 PRINT"Close"
 DisposeDTObject o&
END IF

---

[ - Answer - Quote - Direct link - ]

Zitat:

---

Original von Ralf27:

code:

---

TAGLIST tll&, _
DTA_GroupID&, GID_PICTURE&, _
DTA_FREESOURCEBITMAP&, TRUE&, _
PDTA_Remap&, TRUE&, _
TAG_END&

---

Ok, ist jetzt etwas wild, weil ich gerade am testen bin. Aber was müßte ich da oben Angeben, damit ich ein beliebiges Bild ohne DITHER an die WB-Farbenpalette anpassen lassen kann?

---

Schau Dir mal das PDTA_Remap& an. Was meinst Du, was das bedeuten könnte? Genau, damit wird das "dithern" gesteuert.

Wenn Du das auf FALSE& setzt, wird normalerweise einfach platt heruntergerechnet (das sieht dann, je nach Ausgangsbild und Farbtiefe, auf die heruntergerechnet wird, nicht wirklich schön aus und "normalerweise", weil der verwendete Datatype dies unterstützen muß, damits funktioniert. Die aktuellen tun das).

code:

---

VARPTR(bitmap&),

---

Diese Bitmap mußt Du mittels AllocBitMap() so anlegen, daß sie die gleiche Farbtiefe bekommt wie der WB-Screen und dem Datatype als Zielbitmap übergeben (ich weiß leider nicht auf Anhieb, wie das entsprechende Tag dazu lautet). Das Format ist, wenn Du Dich auf Palette beschränkst, von untergeordneter Bedeutung.

Die Informationen über den WB-Screen müßtest Du mittels LockPubScreen() bekommen können, wenn ich mich da richtig erinnere (müßte eine Screen-Struktur liefern, aus der Du die Informationen LESEN (!) kannst. Ich hab leider grad die DevCD nicht griffbereit, deswegen "müßte"). UnlockPubScreen() hinterher nicht vergessen

Sollte der WB-Screen allerdings eine Farbtiefe >8Bit haben, bekommst Du ein Problem, wenn Du nicht mit CGFX/P96 arbeitest. Aber das kannst Du über die Informationen, die LockPubScreen() liefert, leicht herausfinden und dann mit einer Meldung darauf reagieren.

Grüße

--
---

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


[ Dieser Beitrag wurde von whose am 20.04.2006 um 23:42 Uhr geändert. ]

[ - Answer - Quote - Direct link - ]

[ - Answer - Quote - Direct link - ]

Zitat:

---

Original von whose:

Schau Dir mal das PDTA_Remap& an. Was meinst Du, was das bedeuten könnte? Genau, damit wird das "dithern" gesteuert.

Wenn Du das auf FALSE& setzt, wird normalerweise einfach platt heruntergerechnet (das sieht dann, je nach Ausgangsbild und Farbtiefe, auf die heruntergerechnet wird, nicht wirklich schön aus und "normalerweise", weil der verwendete Datatype dies unterstützen muß, damits funktioniert. Die aktuellen tun das).

---

Zitat:

---

code:

---

VARPTR(bitmap&),

---

Diese Bitmap mußt Du mittels AllocBitMap() so anlegen, daß sie die gleiche Farbtiefe bekommt wie der WB-Screen und dem Datatype als Zielbitmap übergeben (ich weiß leider nicht auf Anhieb, wie das entsprechende Tag dazu lautet). Das Format ist, wenn Du Dich auf Palette beschränkst, von untergeordneter Bedeutung.

---

Zitat:

---

Die Informationen über den WB-Screen müßtest Du mittels LockPubScreen() bekommen können, wenn ich mich da richtig erinnere (müßte eine Screen-Struktur liefern, aus der Du die Informationen LESEN (!) kannst. Ich hab leider grad die DevCD nicht griffbereit, deswegen "müßte"). UnlockPubScreen() hinterher nicht vergessen

---

Hm, mir fällt gerade auf das andere Programme ja auch die Palette einfach ändern können. Was ist dann? Oh, die Programmierung ist wirklich recht komplex...
[quote]

Sollte der WB-Screen allerdings eine Farbtiefe >8Bit haben, bekommst Du ein Problem, wenn Du nicht mit CGFX/P96 arbeitest. Aber das kannst Du über die Informationen, die LockPubScreen() liefert, leicht herausfinden und dann mit einer Meldung darauf reagieren.
[quote]
Ja, ich hab schon gemerkt das das nicht so einfach ist. Die Frage ist dann, was mach ich dann?

Also ich benutze kein CGFX sondern nur Mittel aus dem Betriebssystem. Werden die dann nicht soweit vom CGFX-System umgebogen das es dann auch geht? Die Grafikkarten fasse ich ja quasi mit meinem Programm nicht direkt an.
--
http://www.alternativercomputerclub.de.vu

[ - Answer - Quote - Direct link - ]

Zitat:

---

Original von thomas:
@Ralf27:

Rastern oder nicht rastern kannst du nicht bestimmen. Wenn das Bild an die Farbtiefe eines Bildschirms angepaßt werden soll und mehr Farben hat, als Stifte frei sind, dann wird es in der Regel gerastert. Das hängt aber von der Implementierung des Datatype ab und kann vom Programm nicht beeinflußt werden.

Ob das Bild an die Farbtiefe eines Bildschirms angepaßt werden soll, sagst du ihm bei NewDTObject mit PDTA_Remap,TRUE oder FALSE (TRUE = anpassen, FALSE = nicht anpassen). Remap=TRUE funktioniert natürlich nur, wenn du auch mit PDTA_Screen einen Zeiger auf den Zielbildschirm angibst.

PDTA_Remap,FALSE bedeutet, daß du das Bild so lädst, wie es in der Datei steht. D.h. es kann u.U auf deinem Bildschirm anzeigbar sein, kann aber auch sein, daß es zu viele Farben hat. Und falls du 24bit-Daten brauchst, das Bild aber nur Bitplanes und eine Palette hat, ist es auch deine Aufgabe, die Daten nach 24bit umzurechnen.

Gruß Thomas

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

---

*Danke*



Das muß ich mal bei Gelegenheit testen. Somit dürfte es laufen.

Aber:
* was ist mit Systemen mit Grafikkarte? Das Programm müßte dann auch so laufen (Vermutung), da das CGFX die entsprechenden Routinen im Betriebsystem verändert.

* wenn alles auf der WB mit <=8Bit läuft und irgendein Programm die Farben ändert? Ich vermute mal das die Datatypes keine Stifte reservieren, also wäre es wohl dann wieder meine Aufgabe alles wieder in die richtige Farbe zu bringen. Vorausgesetzt ich bekomme das mit...
--
http://www.alternativercomputerclub.de.vu

[ - Answer - Quote - Direct link - ]

code:

---

TAGLIST tll&, _
DTA_GroupID&, GID_PICTURE&, _        <- bedeutung ist mir auch klar
DTA_FREESOURCEBITMAP&, TRUE&, _      <- brauch ich das?
PDTA_Remap&, TRUE&, _                <- klar, brauch ich
PDTA_Screen&, scr&, _                <- das auch
TAG_END&

o&=NewDTObjectA&(SADD(file$+CHR$(0)),tll&)
IF o& THEN
 TAGLIST tll&, _
 DTM_PROCLAYOUT&, TRUE&, _           <- wird hiermit die umrechnung gestartet?
 TAG_END&

 IF DoDTMethodA&(o&,0,0,tll&) THEN
  TAGLIST tll&, _
  PDTA_DestBitMap&, VARPTR(bitmap&), _
  DTA_NominalHoriz&, VARPTR(nomwidth&), _
  DTA_NominalVert&, VARPTR(nomheight&), _
  TAG_END&
  junk&=GetDTAttrsA&(o&,tll&)
  PRINT bitmap&, nomwidth&, nomheight&      <- hier bleibt die bitmap immer auf null
                                             - breite und hoehe stimmt
 END IF
 PRINT"Close"
 DisposeDTObject o&
END IF

---

Wenn ich das alles mal versteh dann schreib ich mal eine Deutsche Doku für Datatypes und stell diese auf meine Page.
--
http://www.alternativercomputerclub.de.vu

[ - Answer - Quote - Direct link - ]

Zitat:

---

Original von Ralf27:

Zitat:

---

Original von whose:

Schau Dir mal das PDTA_Remap& an. Was meinst Du, was das bedeuten könnte? Genau, damit wird das "dithern" gesteuert.

Wenn Du das auf FALSE& setzt, wird normalerweise einfach platt heruntergerechnet (das sieht dann, je nach Ausgangsbild und Farbtiefe, auf die heruntergerechnet wird, nicht wirklich schön aus und "normalerweise", weil der verwendete Datatype dies unterstützen muß, damits funktioniert. Die aktuellen tun das).

---

also hier dann FALSE, ok. Aber wie bring ich denn Datatypes bei welche Palette/Screen sie beachten sollen?

---

Ich bin derzeit leider nicht in Reichweite eines Amigas, sonst könnte ich dazu mal schnell ein bißchen Beispielcode bringen und definitiver antworten, also versuche ichs so:

Die Palette der Zielbitmap ist für die Datatypes normal nicht bindend, wenn das zu ladende Bild palettebasiert ist. Du mußt Dir also überlegen, ob Du nicht doch lieber mit Remapping arbeitest oder die Bildpalette verwendest, was eine Änderung der WB-Palette zur Folge hätte (keine gute Idee, weil Du alle freien Pens allokieren müßtest, um eine Veränderung der Palette durch andere Programme zu unterbinden. Das wäre aber nicht nett ).

Sofern das zu ladende Bild selbst palettebasiert und die Farbtiefe nicht größer als die der Zielbitmap ist, bewirkt PDTA_Remap kein Dithering. Bei allen anderen Fällen schon. In diesen Fällen kommst Du dann wohl nicht drumherum, die Anpassung der Pixel an die aktuelle Palette mühsam und zeitraubend von Hand erledigen zu müssen, soweit ich weiß. ObtainBestPen() ist da allerdings eine große Hilfe.

Zitat:

---

Zitat:

---

code:

---

VARPTR(bitmap&),

---

Diese Bitmap mußt Du mittels AllocBitMap() so anlegen, daß sie die gleiche Farbtiefe bekommt wie der WB-Screen und dem Datatype als Zielbitmap übergeben (ich weiß leider nicht auf Anhieb, wie das entsprechende Tag dazu lautet). Das Format ist, wenn Du Dich auf Palette beschränkst, von untergeordneter Bedeutung.

---

Ich nehme einfach mal das die Datatypes eine Bitmap anlegen, die ich dann einfach dann in die von mir aufgebaute(mit allocbitmap) mit bltbitmap kopieren kann. Soweit ist mir das schon klar, bzw. kann ich dann die Daten dann theoretisch so wie ich sie brauch direkt mit bltbitmaprastport in mein fenster kopieren.

---

Zitat:

---

Zitat:

---

Die Informationen über den WB-Screen müßtest Du mittels LockPubScreen() bekommen können, wenn ich mich da richtig erinnere (müßte eine Screen-Struktur liefern, aus der Du die Informationen LESEN (!) kannst. Ich hab leider grad die DevCD nicht griffbereit, deswegen "müßte"). UnlockPubScreen() hinterher nicht vergessen

---

Hm, mir fällt gerade auf das andere Programme ja auch die Palette einfach ändern können. Was ist dann? Oh, die Programmierung ist wirklich recht komplex...

---

Zitat:

---

Zitat:

---

Sollte der WB-Screen allerdings eine Farbtiefe >8Bit haben, bekommst Du ein Problem, wenn Du nicht mit CGFX/P96 arbeitest. Aber das kannst Du über die Informationen, die LockPubScreen() liefert, leicht herausfinden und dann mit einer Meldung darauf reagieren.

---

Ja, ich hab schon gemerkt das das nicht so einfach ist. Die Frage ist dann, was mach ich dann?

---

Viel selbst Du mußt dann mit der (emulierten) Screen-Palette arbeiten, also alle Pixel von Hand (bzw. mit Hilfe von ObtainBestPen()) an die aktuelle Palette anpassen.

Ich weiß jetzt allerdings nicht aus dem Stegreif, ob man dieses Verhalten der Datatypes nicht doch mit PDTA_DestMode steuern kann (müßte dann normal auf einen palettebasierten Algorithmus umsteigen, sofern man etwas anderes als PMODE_V43 wählt, wenn ich mich recht erinnere. Also im Grunde auch der Weg über ObtainBestPen(). Beschwören möchte ich das jetzt aber nicht )

Zitat:

---

Also ich benutze kein CGFX sondern nur Mittel aus dem Betriebssystem. Werden die dann nicht soweit vom CGFX-System umgebogen das es dann auch geht? Die Grafikkarten fasse ich ja quasi mit meinem Programm nicht direkt an.
--
http://www.alternativercomputerclub.de.vu

---

Ja, sobald CGX/P96 ins Spiel kommen und die Farbtiefen >8Bit sind, wird vieles sogar wesentlich simpler, weil man in weiten Bereichen von der Screen-Palette unabhängig wird (Ausnahmen sind die OS-Funktionen, die unmittelbar mit Palette-Werten arbeiten). Wenn man aber wie Du "glatte" Farbwerte haben will, ändert sich auch unter CGX/P96 nichts, leider.

Da könnte Dir das Beispiel von Thilo doch weiterhelfen, weil guigfx.library entsprechende Funktionen bietet. Die von ihm gezeigte Funktion stammt übrigens aus seinen Includes, müßtest Du also recht einfach für Dich erschließen können. Schau Dir die doch einmal näher an.

Grüße

--
---

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

[ - Answer - Quote - Direct link - ]

Zitat:

---

Original von Ralf27:
Hm, der Zeiger auf die bitmap ist als noch null. irgendein paramter ist wohl noch fehlerhaft. bzw ist auch fraghaft welche ich überhaupt unbedingt benötige und welche nicht.

---

Uff, langsam

Zitat:

---

code:

---

TAGLIST tll&, _
DTA_GroupID&, GID_PICTURE&, _        <- bedeutung ist mir auch klar
DTA_FREESOURCEBITMAP&, TRUE&, _      <- brauch ich das?

---

---

Zitat:

---

code:

---

o&=NewDTObjectA&(SADD(file$+CHR$(0)),tll&)
IF o& THEN
 TAGLIST tll&, _
 DTM_PROCLAYOUT&, TRUE&, _           <- wird hiermit die umrechnung gestartet?

---

---

Zitat:

---

code:

---

IF DoDTMethodA&(o&,0,0,tll&) THEN
  TAGLIST tll&, _
  PDTA_DestBitMap&, VARPTR(bitmap&), _
  DTA_NominalHoriz&, VARPTR(nomwidth&), _
  DTA_NominalVert&, VARPTR(nomheight&), _
  TAG_END&
  junk&=GetDTAttrsA&(o&,tll&)
  PRINT bitmap&, nomwidth&, nomheight&      <- hier bleibt die bitmap immer auf null
                                             - breite und hoehe stimmt

---

---

Zitat:

---

Wenn ich das alles mal versteh dann schreib ich mal eine Deutsche Doku für Datatypes und stell diese auf meine Page.
--
http://www.alternativercomputerclub.de.vu

---

Gute Idee

Grüße

--
---

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

[ - Answer - Quote - Direct link - ]

Zitat:

---

Uff, langsam

---

Wollte eigentlich auch schon seit einer Stunde im Bett liegen, aber ich will da nicht von Datatypes träumen.

Zitat:

---

Zitat:

---

code:

---

TAGLIST tll&, _
DTA_GroupID&, GID_PICTURE&, _        <- bedeutung ist mir auch klar
DTA_FREESOURCEBITMAP&, TRUE&, _      <- brauch ich das?

---

---

Nein, normal nicht. Ich weiß zwar die Bedeutung dieses Tags selbst gerade nicht, aber in meinen Programmen kam das bisher noch nie vor (in Thomas Beispiel müßte das eigentlich auch nicht auftauchen, soweit ich mich erinnere).

Das könnte mit dem FREESOURCEBITMAP-Tag zusammenhängen, wenn der Name nicht völlig irreführt. Ich mein, hier liegt ja in dem Sinne keine Source vor, da das Bild ja in DestBitMap überhaupt erst entsteht, von daher ist das schon etwas verwirrend im ersten Moment.

Ich könnte mir aber gut vorstellen, daß, sofern keine vom Programm allokierte Bitmap als Ziel dient, DestBitMap und SourceBitMap die gleiche Bitmap bezeichnen. Ändere das mal in FALSE&, evtl. wars das schon.

---

[ - Answer - Quote - Direct link - ]

@Ralf27:

Naja, das ist ein nicht ganz triviales Feld

Setz doch bitte mal in die Tagliste für DoDTMethodA hinter DTM_PROCLAYOUT eine 0 vor das TRUE. Ich weiß jetzt auch nicht so genau, ob das was zu bedeuten hat, aber ich meine, daß an der Stelle in dem von mir verwendeten Code eine 0 stand. und als nächstes eine 1 und nicht TRUE (als was ist TRUE in MaxonBasic eigentlich definiert?).

Versuch macht kluch

Wird Zeit, daß ich wieder nach Hause und vor nen Amiga komme, damit ich das mal alles nachschlagen kann...

Grüße

Nachtrag: Ich bin mir ziemlich sicher, daß Dein TRUE& an der Stelle nicht so ganz richtig ist. Ich kann mich nach einem Weilchen grübeln nebulös an eine Struktur namens gpLayout erinnern, wie sie auch von den BOOPSI-Gadgets für deren Methoden verwendet wird. Die müßte, wenn ich mich richtig erinnere, auch für die Datatypes anzuwenden sein. Dann sollte es

code:

---

...DTM_PROCLAYOUT, 0, 1, TAG_END...

---

lauten.

--
---

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


[ Dieser Beitrag wurde von whose am 21.04.2006 um 01:34 Uhr geändert. ]

[ - Answer - Quote - Direct link - ]

Zitat:

---

Original von whose:

Nachtrag: Ich bin mir ziemlich sicher, daß Dein TRUE& an der Stelle nicht so ganz richtig ist. Ich kann mich nach einem Weilchen grübeln nebulös an eine Struktur namens gpLayout erinnern, wie sie auch von den BOOPSI-Gadgets für deren Methoden verwendet wird. Die müßte, wenn ich mich richtig erinnere, auch für die Datatypes anzuwenden sein. Dann sollte es

code:

---

...DTM_PROCLAYOUT, 0, 1, TAG_END...

---

lauten.

---

Da ich heute Nacht die "besten" Träume über Tags, Methode und Datatypes hatte (Horror), mußte ich heute morgen nochmal dran. Ist schon von Vorteil wenn man flexsible Arbeitszeiten hat:

Tatsache, jetzt bekomme ich was bei bitmap! Ist aber eine seltsame Zusammenstellung bei den Tags. Wie kommts? Bzw. darauf wäre ich nie gekommen.

Achja, TRUE&=1, FALSE&=0, NULL&=0


Ob es jetzt wirklich läuft teste ich später, bzw. ob die bitmap "Valid" ist.
--
http://www.alternativercomputerclub.de.vu

[ - Answer - Quote - Direct link - ]

code:

---

struct gpLayout
{
    ULONG  MethodID;
    struct GadgetInfo *gpl_GInfo;
    ULONG  gpl_Initial; /* non-zero if this method was invoked
         * during AddGList() or OpenWindow()
         * time.  zero if this method was invoked
         * during window resizing. */
};

---

Ich nehme mal an, daß Du mit dem TRUE an der falschen Stelle quasi dafür gesorgt hast, daß der Datatype versuchte, aus dem Bild ein Gadget zu machen (für irgendwas muß GadgetInfo bei Datatypes ja eine Bedeutung haben). Genaues weiß ich da allerdings auch nicht.

Wie das kommt? Datatypes und BOOPSI-Gadgets sind enge Verwandte, daher vermutlich.

Ich denke schon, daß die Bitmap nun brauchbar ist

Grüße

--
---

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

[ - Answer - Quote - Direct link - ]

[ - Answer - Quote - Direct link - ]

Zitat:

---

Auch der Datastype IFF saver funktioniert NICHT mit 24bit, sondern nur mit Tiefen <=8.

---

[ - Answer - Quote - Direct link - ]

[ - Answer - Quote - Direct link - ]

Zitat:

---

Original von bubblebobble:
Ralf:
Warum willst du das Bild nicht anzeigen ?

Dir ist aber klar, dass du mit dem gerempappten Bild nichts anfangen kannst, wenn du es nicht blittest. Falls du mit dem Gedanken spielst, das Bild optimiert abzuspeichern: Die Palette kann sich jeden Moment ändern. Sobald du den Lock auf die benuttzen Pens frei gibts, kannst du mit dem Bild nichts mehr anfangen.

Auch der Datastype IFF saver funktioniert NICHT mit 24bit, sondern nur mit Tiefen <=8.

---

Ich will ja das Bild anzeigen, aber nicht so wie es ist. Für denn Zweck ist es so genau richtig. Außerdem mach ich kein Lock auf die Pens, noch nicht. Eine Speicheroption ist im aktuellen Programm unsinnig.

Das einzige ist halt die Palette, die fremde Programme ändern könnten. Aber das ist nicht so schlimm, denn da gib es bestimmt auch Lösungen dafür.

Jedenfalls hab ich jetzt eine Lösung für mein Problem gefunden und bin voll und ganz damit zufrieden. Ich bin mal gespannt wie es dann mit Grafikkarten aussieht. Leider kann ich das ja hier nicht mehr testen, da ich keine Grafikkarte habe.
Das ganze Projekt ist aber eher für Customchips ausgelegt, aber es spricht von der Programmierung her nichts dagegen, das es auch auf einer Grafikkarte läuft.

Das ganze hat übrigens nichts mit meinem BMP-Reader zu tun.
--
http://www.alternativercomputerclub.de.vu

[ - Answer - Quote - Direct link - ]

So, Bilder laden geht wunderbar, allerdings hab ich wieder ein kleines Problem, das vermutlich auch was mit den Datatypes zu tun hat:

Ich möchte ein Bild als Maske laden, dazu ist es auch schon vorbereitet (1Bit tief).
Das Bild wird auch korrekt geladen und ist auch ein Bit tief. Ich hab dafür logischerweise Remapping abgeschaltet, aber leider läuft es nicht so wie ich möchte. Aus der zurückgegebene Addresse auf die bitmap hab ich die erste Plane extrahiert und dies übergebe ich als Mask an BltMaskBitmapRastport. Es wird auch ein Blit vollführt, aber nicht so es sein sollte. Ich bekomme da ein ganz schönen Datenmüll serviert, bzw. die Maske ist wohl nicht so wie sie sein sollte. Denn wenn ein Pixel durch die Maske kommt, dann kommt es von der richtigen Quellbitmap.

In der Doku (ja, ich habs auf englisch gelesen ) steht auch kaum was brauchbares drin. Die Bitmap ist genau so groß wie die Quellbitmap, die ich durch die Maske jagen möchte. Wenn ein Bit in der Maske 1 hat, dann wird da geblittet und wenn 0 dann eben nicht.

Die Bitmaps und Planes werden vom System aufgebaut, also ist sowas wie durch 16 oder gar durch 32 teilbar nicht als Fehlerquelle möglich, oder etwa doch?

Dann ist da nochwas:
PDTA_MaskPlane

Hab ich bei meiner Suche im Internet gefunden, aber leider scheint das in meinen Includes nicht deklariert zu sein. Ich bekomme da einfach eine Null rüber.
Brauch ich diesen Eintrag unbedingt bei den Datatypes? Das Bild wird ja unverändert geladen und müßte (in der Therorie) so auch laufen, aber leider geht es halt nicht.

Wenn ich diesen Eintrag brauch, was für einen Wert hat er dann?
--
http://www.alternativercomputerclub.de.vu

[ - Answer - Quote - Direct link - ]

C code:

---

struct BitMap *uninterleave (struct BitMap *srcbm)

{
struct BitMap *newbm = NULL;
long w,h,d;

d = GetBitMapAttr (srcbm,BMA_DEPTH);
if (d <= 8)
	{
	w = GetBitMapAttr (srcbm,BMA_WIDTH);
	h = GetBitMapAttr (srcbm,BMA_HEIGHT);
	if (newbm = AllocBitMap (w,h,d,0,NULL))
		{
		BltBitMap (srcbm,0,0,newbm,0,0,w,h,0xc0,0xff,NULL);
		}
	}

return (newbm);
}

---

[ - Answer - Quote - Direct link - ]

Zitat:

---

Original von Ralf27:
Dann ist da nochwas:
PDTA_MaskPlane

Hab ich bei meiner Suche im Internet gefunden, aber leider scheint das in meinen Includes nicht deklariert zu sein. Ich bekomme da einfach eine Null rüber.
Brauch ich diesen Eintrag unbedingt bei den Datatypes? Das Bild wird ja unverändert geladen und müßte (in der Therorie) so auch laufen, aber leider geht es halt nicht.

---

[ - Answer - Quote - Direct link - ]

Zitat:

---

Original von thomas:
Das Problem ist wohl weniger die Maske, sondern das Bild. Die Bitmap, die vom Datatype für das Bild angelegt wird, ist INTERLEAVED. D.h. die Bitplanes sind nicht einzeln, sondern verzahnt.

---

[ - Answer - Quote - Direct link - ]

[ - Answer - Quote - Direct link - ]

[ - Answer - Quote - Direct link - ]

Zitat:

---

Original von Ralf27:
Hm, ich kämpfe gerade mit BltMaskBitMapRastPort und das was hinten rauskommt ist wirklich nicht das was es eigentlich machen sollte. Als minterm hab ich E0 stehn, also das direkte kopieren von der Quelle durch die Mask (wenn da ne 1 steht) aufs Ziel.

---

[ - Answer - Quote - Direct link - ]