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

amiga-news.de Forum > Programmierung > Datatypes: *Hilfe* [ - Suche - Neue Beiträge - Registrieren - Login - ]

-1- 2 [ - Beitrag schreiben - ]

19.04.2006, 23:43 Uhr

Ralf27
Posts: 2779
Nutzer
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... :D )
--
http://www.alternativercomputerclub.de.vu

[ - Antworten - Zitieren - Direktlink - ]

20.04.2006, 00:11 Uhr

bubblebobble
Posts: 707
Nutzer
So einfach wäre's mit Amiblitz ;-)

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


Das lädt Bilder via Datatypes (mit Hilfe der guigfx.lib),
und man kann sie auf jeden Screen blitten.

--
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.04.2006, 00:14 Uhr

Ralf27
Posts: 2779
Nutzer
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. :D

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

[ - Antworten - Zitieren - Direktlink - ]

20.04.2006, 09:39 Uhr

Ralf27
Posts: 2779
Nutzer
bzw. deutsche doku für die Datatypes...
--
http://www.alternativercomputerclub.de.vu

[ - Antworten - Zitieren - Direktlink - ]

20.04.2006, 11:51 Uhr

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


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

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...
--
http://amidevcpp.amiga-world.de/

[ - Antworten - Zitieren - Direktlink - ]

20.04.2006, 21:40 Uhr

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

Ja, das befürchtete ich auch schon...
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...

Du kannst dir ja bestimmt recht gut vorstellen das ich deswegen nicht extra englisch lernen möchte. Mit dem bischen Schulenglisch kann ich mich zwar einigermaßen durch Doku quälen, aber einige Fragen bleiben immer.
Und gerade die Doku zu den Datatypes ist dürftig (Englisch oder Deutsch).
Hab vorhin auch gelesen das selbst der Thomas bei den Datatypes vieles nach Trail&Error durchtesten mußte, weil die Doku mies ist (egal welcher Sprache).

Die Fragen oben von mir war eher "Wunschdenken".

Nichts desto trotz, selbst mit testen hab ich es noch nicht geschaft. Ich will jetzt auch nicht eine eigene Routine dafür schreiben, die aber vermutlich schon fertig wäre. Es geht eigentlich nur darum verdeckt Bilder zu laden und an die WB-Farbtiefe anzupassen.
--
http://www.alternativercomputerclub.de.vu

[ - Antworten - Zitieren - Direktlink - ]

20.04.2006, 22:10 Uhr

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

--
---

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

[ - Antworten - Zitieren - Direktlink - ]

20.04.2006, 22:22 Uhr

Ralf27
Posts: 2779
Nutzer
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).


Eigentlich ist es ja wirklich nicht schwer, wenn man es mal versteht...

Folgender Test:
(ich hab die INCLUDES mal weg gelassen, die werden aber beim Programmstart eingebunden)

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


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?

Wie kann ich den DoDTMethode (bin ich da überhaupt richtig?) mitteilen das die Routine auf die WB-Farbpalette umrechnen soll?
nomwidth& und nomheight& hatten auch schon richtige Daten rübergebracht, aber zur Zeit eben nicht, weil ich gerade beim testen mit Parameter beim öffnen der Datatypes bin. bitmap& war aber bis jetzt immer NULL.

Die Daten von bitmap&,nomwidth&,nomheight& reichen mir dann vollkommend aus zur Weiterverarbeitung, aber erst mal die Datatypes die Bilder richtig laden lassen...
--
http://www.alternativercomputerclub.de.vu

[ Dieser Beitrag wurde von Ralf27 am 20.04.2006 um 22:27 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

20.04.2006, 23:37 Uhr

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

--
---

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


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

[ - Antworten - Zitieren - Direktlink - ]

20.04.2006, 23:44 Uhr

thomas
Posts: 7716
Nutzer
@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/

[ - Antworten - Zitieren - Direktlink - ]

20.04.2006, 23:51 Uhr

Ralf27
Posts: 2779
Nutzer
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 :D 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?
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:
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... 8o
[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

[ - Antworten - Zitieren - Direktlink - ]

20.04.2006, 23:57 Uhr

Ralf27
Posts: 2779
Nutzer
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*

:bounce:

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

[ - Antworten - Zitieren - Direktlink - ]

21.04.2006, 00:16 Uhr

Ralf27
Posts: 2779
Nutzer
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.

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. I-)
--
http://www.alternativercomputerclub.de.vu

[ - Antworten - Zitieren - Direktlink - ]

21.04.2006, 00:20 Uhr

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

So kannst Du auch vorgehen, richtig.

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... 8o

Es geht eigentlich. Allerdings mußt Du mit so mancher Einschränkung leben, wenn Du auf <=8Bit-Screens arbeitest, die auch von anderen Programmen genutzt werden. Da sind WB-Screens auf CGX/P96-Systemen eindeutig im Vorteil (man kann dort relativ unabhängig von der eigentlichen Screen-Palette arbeiten).

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 :D )

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

--
---

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

[ - Antworten - Zitieren - Direktlink - ]

21.04.2006, 00:29 Uhr

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

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



Jain. Damit löst Du etliche Vorgänge aus, unter anderem auch ggf. gewünschtes Dithering/Anpassung an die aktuelle Palette etc. pp.

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



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.

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


Gute Idee :)

Grüße

--
---

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

[ - Antworten - Zitieren - Direktlink - ]

21.04.2006, 00:37 Uhr

Ralf27
Posts: 2779
Nutzer
[quote]
Original von whose:
Zitat:
Uff, langsam :D
Wollte eigentlich auch schon seit einer Stunde im Bett liegen, aber ich will da nicht von Datatypes träumen. :D
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.


FREESOURCEBITMAP auf FALSE bringt auch keine Änderung.
Irgendwo ist da noch ein Würmchen drin.
--
http://www.alternativercomputerclub.de.vu

[ - Antworten - Zitieren - Direktlink - ]

21.04.2006, 00:50 Uhr

whose
Posts: 2156
Nutzer
@Ralf27:

Naja, das ist ein nicht ganz triviales Feld :D

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 :D

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.

--
---

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


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

[ - Antworten - Zitieren - Direktlink - ]

21.04.2006, 07:37 Uhr

Ralf27
Posts: 2779
Nutzer
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: :D

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

[ - Antworten - Zitieren - Direktlink - ]

21.04.2006, 08:52 Uhr

whose
Posts: 2156
Nutzer
@Ralf27:

Hier:
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 :D

Grüße

--
---

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

[ - Antworten - Zitieren - Direktlink - ]

21.04.2006, 12:03 Uhr

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

--
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.04.2006, 13:14 Uhr

thomas
Posts: 7716
Nutzer
Zitat:
Auch der Datastype IFF saver funktioniert NICHT mit 24bit, sondern nur mit Tiefen <=8.

Das ist nicht wahr. Der Datatype, der 24bit-Daten laden kann, kann sie auch speichern (v43+ natürlich).

Gruß Thomas

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

[ - Antworten - Zitieren - Direktlink - ]

21.04.2006, 13:20 Uhr

bubblebobble
Posts: 707
Nutzer
@Thomas
Da habe ich aber eine andere Erfahrung gemacht.
Ich hatte das implementiert und problemlos 8bit Grafiken speichern können, aber sobald es mehr waren als 8bit blieb die IFF Datei leer
oder nur ein paar Bytes gross. Ab und zu ist es auch abgestürzt.
Und mein Datatype kann definitiv 24Bit lesen, ich hab ja 24bit Workbench.


--
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.04.2006, 20:49 Uhr

Ralf27
Posts: 2779
Nutzer
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. :D
--
http://www.alternativercomputerclub.de.vu

[ - Antworten - Zitieren - Direktlink - ]

22.04.2006, 09:22 Uhr

Ralf27
Posts: 2779
Nutzer
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 :D ) 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

[ - Antworten - Zitieren - Direktlink - ]

22.04.2006, 12:33 Uhr

thomas
Posts: 7716
Nutzer
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.

Du müßtest also für das Bild eine neue Bitmap anlegen, die nicht interleaved ist, dann müßte das Blitten funktionieren.
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);
}


Gruß Thomas

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

[ - Antworten - Zitieren - Direktlink - ]

22.04.2006, 16:39 Uhr

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

Du brauchst diesen Eintrag nicht. Du hast ja Deine Maske als zweifarbiges Bild gespeichert. Wenn Du stattdessen ein Bild (also Farbdaten) UND eine Maske in ein und demselben Bild hättest, könntest Du die Maske damit abfragen.
Dazu bräuchtest Du dann natürlich datatypes V43 und das datatype für das entsprechende Bildformat muß das auch unterstützen...

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

[ Dieser Beitrag wurde von Holger am 22.04.2006 um 16:40 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

22.04.2006, 22:36 Uhr

Ralf27
Posts: 2779
Nutzer
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.


Danke, aber wieso um Himmels willen machen denn die Datatypes sowas? Gibt es da einen bekannten Grund?
Kann man das beim laden mit den Datatypes nicht abschalten?
--
http://www.alternativercomputerclub.de.vu

[ - Antworten - Zitieren - Direktlink - ]

22.04.2006, 23:35 Uhr

Ralf27
Posts: 2779
Nutzer
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.
Aber wenn ich das richtig verstanden habe, dann kann dieser Befehl auch noch mit dem Ziel verknüpfen. Ich hab auch mal mit mintern 20 experimentiert, aber leider läuft es damit auch nicht. Ich weis leider da auch nicht mehr weiter.
Hoffentlich ist nur mein minterm falsch. Ich hab diese Angabe vom Amiga INTERN-Buch.
--
http://www.alternativercomputerclub.de.vu

[ - Antworten - Zitieren - Direktlink - ]

23.04.2006, 12:54 Uhr

Ralf27
Posts: 2779
Nutzer
Hab eben folgendes gefunden:

PDTA_BitMapHeader,&bmhd,
PDTA_BitMap,&srcbm,
PDTA_DestBitMap,&destbm,

Es kann ja nicht drei mal das gleiche sein, aber wieso drei mal?

Bitmapheader könnte die 40Bytes große Struktur sein die die Planes verwaltet, aber das gleiche könnte BitMap sein, oder sind damit die Planes gemeint?!?

Und DestBitMap ist die Ausgabebitmap?

Oder beziehen sich die Angaben teilweise auf die originaldaten und die anderen auf die umgerechneten Daten?

Mein Anzeigeprogramm funktioniert zwar, aber leider nicht das mit der Mask und ich hab schon einiges durchprobiert.

Ich frag mich eben woran es denn noch liegen könnte:
Die Mask kann ich laden und anzeigen. Ich hab sie auch nochmal in eine eigene Bitmap kopiert (AllocBitMap , Bltbitmap), aber was da hinten raus kommt ist seltsam:

* teilweise Streifen im Bild
* Verknüpfung mit dem Hintergrund?!?
* auch ist das kopierte Objekt mit BltMaskBitMapRastport teilweise Farblich verändert ?!?

Mimterm: &HE0 bzw. 0xe0 (hab auch schon 0x20, bzw. andere getestet...)
--
http://www.alternativercomputerclub.de.vu

[ - Antworten - Zitieren - Direktlink - ]

23.04.2006, 13:38 Uhr

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

Also so aus dem Bauch heraus, würde ich sagen, daß C0 eine direkte Kopie beinhaltet und die OS-Funktion sich um die Berücksichtigung der Maske kümmern sollte, dafür ist sie ja da.

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

[ - Antworten - Zitieren - Direktlink - ]


-1- 2 [ - Beitrag schreiben - ]


amiga-news.de Forum > Programmierung > Datatypes: *Hilfe* [ - Suche - Neue Beiträge - Registrieren - Login - ]


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