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

amiga-news.de Forum > Programmierung > Datatypes: Farben festlegen lassen [ - Suche - Neue Beiträge - Registrieren - Login - ]

1 -2- 3 [ - Beitrag schreiben - ]

09.10.2006, 15:01 Uhr

thomas
Posts: 7717
Nutzer 		@Ralf27:

Ich verstehe deine Probleme nicht. Wenn du mal darüber nachdenken würdest, wie ein palettebasiertes Bild funktioniert und was es bedeutet, die Palette zu ändern, ohne die Bitmap anzupassen, dann wäre es vollkommen klar, was passiert.

Gruß Thomas

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

[ - Antworten - Zitieren - Direktlink - ]
09.10.2006, 20:48 Uhr

Ralf27
Posts: 2779
Nutzer 		@thomas:

Jetzt versteh ich Dich wirklich nicht. Was willst du mir damit sagen?

Ich versteh das ganze einfach so:
Die Datatypes suchen für jede Farben einen richtigen Stift aus, reservieren diesen und setzen dann im Bild denn Stift für diese Farbe ein. So läuft es doch eigentlich ab. Die Bitmap des Bildes wird dann also angepasst.

Am Anfang lief es überhaupt nicht, bis du mir denn Hinweis gegeben hast, das die Bilder vermutlich Interleaved Bitmaps sind und das ich diese erst in einen andere Bitmap kopieren muß damit es geht. Und, was soll ich tippen, das war die Lösung zu diesem Problem und gut ist. Somit war ich damit Glücklich bis auf das Problem mit dem unnötigen Speicherverbrauch für die doppelte Bildspeicherung.

Also, wenn ich jetzt die Datatypes mit P_MODE42 anweisen kann die Bitmaps konventionell anzulegen, dann dürfte doch alles wieder *ohne* konvertieren und *richtig* laufen. Bzw. ich spar mir die doppelte Speicherbelegung. Soweit die Theorie.

Und jetzt die eigentlich Frage: Was willst du mir damit tippen, was hab ich denn jetzt übersehn?
--
http://www.alternativercomputerclub.de.vu

[ - Antworten - Zitieren - Direktlink - ]
09.10.2006, 22:39 Uhr

Ralf27
Posts: 2779
Nutzer 		Ok, ich möchte das gerne mal testen, aber leider steig ich da auch bei den C-Includes nicht durch: MODE_V42 ist wohl 0, aber PDTA_DestMode? DTA_Dummy+251... DTA_Dummy ist TAG_USER+&h1000... TAG_USER=!?! blick nicht durch. PDTA_DestMode=4347+x?!? Hilfe! I-)
--
http://www.alternativercomputerclub.de.vu

[ - Antworten - Zitieren - Direktlink - ]
09.10.2006, 22:46 Uhr

thomas
Posts: 7717
Nutzer
In utility/tagitem.h:

#define TAG_USER ((ULONG)(1L<<31))


oder in anderen Worten TAG_USER = &h80000000

Gruß Thomas

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

[ - Antworten - Zitieren - Direktlink - ]
10.10.2006, 18:09 Uhr

NoImag
Posts: 1050
Nutzer
Zitat:
Original von Ralf27:
Ich möchte es weiter ab OS3.0 laufen lassen. Es funktioniert leider nicht, bzw. habe ich das bis jetzt so leider nicht hin bekommen.

Du kannst die Pens nicht ermitteln, allozieren oder etwas anderes?

Tschüß


[ - Antworten - Zitieren - Direktlink - ]
12.10.2006, 23:01 Uhr

Ralf27
Posts: 2779
Nutzer 		CONST PDTA_DestMode&=&H800010FB
CONST MODE_V42&=0

Diese Werte hab ich jetzt ermittelt. Aber leider geht es so leider auch nicht 100%tig. Die meisten gehn, einige aber nicht. Irgendwie seltsam.

Also, die Anzahl der Pens bekomme ich raus, aber sonst läuft alles irgendwie schief. Ich muß mir das nochmal ansehn, ich hab jetzt ein paar Tage lang nix mehr dran gemacht und bin leider auch etwas arg eingespannt und komme zur Zeit nicht mehr ans programmieren, leider... ;(
--
http://www.alternativercomputerclub.de.vu

[ - Antworten - Zitieren - Direktlink - ]
01.01.2007, 19:52 Uhr

Ralf27
Posts: 2779
Nutzer 		Hab mich heute mal wieder drangesetzt und hab versucht es zu "lösen":

Also, ich möchte jetzt bei beiden Möglichkeiten (Screen und Fenster auf der WB) nur die Stifte sichern.
Ich bekomme die Anzahl der Stifte mit NumAlloc, was wohl stimmt. Das Problem ist aber die ColorTable. Ich bekomme zwar einen Rückgabewerte von ColorTable, aber wenn ich da dann Byteweise lese, dann bekomme ich Angaben die nicht stimmen können. z.b. 125 bei einem 3Bit-Screen. So einen Stift kann es doch da nicht geben, bzw. kann ich mir kaum vorstellen.

Die Frage ist also, wie ist diese Tabelle aufgebaut?

Ich möchte halt das ganze Problem auch möglichst bald lösen, kostet ja nur unnötig Speicherplatz.
--
http://www.alternativercomputerclub.de.vu

[ - Antworten - Zitieren - Direktlink - ]
01.01.2007, 21:54 Uhr

Ralf27
Posts: 2779
Nutzer 		Wenn ich jetzt die Penliste habe, wie kann ich die schützen? Obtainbestpen verlangt ja nach rgb. Ein "shared-Mode" hab ich da nicht gefunden. Oder wie bekommt man dann die Stifte fest?

Kurze Überlegung:
Wenn ich r,g,b habe, dann jeden einzelnen stift nochmal mit pen=obtainpestpen c,r,g,b,null ?
--
http://www.alternativercomputerclub.de.vu

[ - Antworten - Zitieren - Direktlink - ]
01.01.2007, 23:21 Uhr

NoImag
Posts: 1050
Nutzer
Zitat:
Original von Ralf27:
Wenn ich jetzt die Penliste habe, wie kann ich die schützen? Obtainbestpen verlangt ja nach rgb. Ein "shared-Mode" hab ich da nicht gefunden. Oder wie bekommt man dann die Stifte fest?

Kurze Überlegung:
Wenn ich r,g,b habe, dann jeden einzelnen stift nochmal mit pen=obtainpestpen c,r,g,b,null ?

Bei ObtainBestPen() gibst du mit dem Tag OBP_Precision an, wie gut der Pen passen soll. In Deinem Fall wäre PRECISION_EXACT die richtige Wahl. Allerdings benötigst du dafür die Werte für r, g und b.

Ich würde an Deiner Stelle aber ObtainPen() verwenden. Wenn du für die Flags 0 angibst, dann wird der angegebene Pen "shared" alloziert. Ob du auch bei ObtainPen() vernünftige Werte für r,g und b angeben musst, musst Du ausprobieren. Die Autodocs sind da nicht eindeutig. Du kannst auch das Flag PEN_NO_SETCOLOR mal ausprobieren, auch wenn die Autodocs sagen, dass dies nur bei exklusiver Allozierung Sinn macht.

Tschüß


[ - Antworten - Zitieren - Direktlink - ]
02.01.2007, 23:10 Uhr

Ralf27
Posts: 2779
Nutzer
Zitat:
Original von NoImag:
Ich würde an Deiner Stelle aber ObtainPen() verwenden. Wenn du für die Flags 0 angibst, dann wird der angegebene Pen "shared" alloziert. Ob du auch bei ObtainPen() vernünftige Werte für r,g und b angeben musst, musst Du ausprobieren. Die Autodocs sind da nicht eindeutig. Du kannst auch das Flag PEN_NO_SETCOLOR mal ausprobieren, auch wenn die Autodocs sagen, dass dies nur bei exklusiver Allozierung Sinn macht.

Ich hab es mal getestet. Also erst mal n=Obtainpen(ColorMap,Pen,0,0,0). Aber leider ging das nicht. Egal was für ein Pen. Dann hab ich mal verscht mal PDA_CRegs die 32Bit-Register nach Obtainpen zu übertragen. Aber nunja, ging auch nicht, weil ich mir auch nicht sicher bin wie die Struktur von CReg ist:
WORD: Anzahl Farben
WORD: Unbelegt?
Von 1 bis Anzahl Farben:
LONG: R
LONG: G
LONG: B

Soweit hab ich das noch vom BMP-Readerprojekt in Erinnerung. Aber vermutlich stimmt das hier auch nicht. :(
--
http://www.alternativercomputerclub.de.vu

[ - Antworten - Zitieren - Direktlink - ]
03.01.2007, 18:09 Uhr

Ralf27
Posts: 2779
Nutzer 		Bin einen kleinen Schritt weitergekommen als ich festgestellt habe, das die Bilder dreifach(!!!) im Speicher gehalten werden:

1* mal das Originalbild
1* das umgerechnete Bild vom Datatype
1* die Kopie des Datatypebildes

wenigestens das erst kann ich jetzt löschen. Ist mir leider erst aufgefallen als ich die Includedateien zu denn Datatypes durchforstet habe: PDTA_FreeSourceBitMap
Hatte ich die ganze Zeit nicht drin und das macht schon einiges aus.

Aber: Die Allocstory von den Pens macht mich noch fertig. Immerhin brauch ich jetzt weniger Chipram, aber die Verschwendung vom kostbaren Chipram bei Customchiprechner ist doch schon recht bescheiden.
--
http://www.alternativercomputerclub.de.vu

[ - Antworten - Zitieren - Direktlink - ]
03.01.2007, 18:52 Uhr

Georg
Posts: 107
Nutzer 		@Ralf27:

Müßte so gehen:

PDTA_NumAlloc = Anzahl allozierter Pens
PDTA_ColorTable = Array allozierter Pens (ein UBYTE pro Pen)

mein_colortable = speicher für mindestens numalloc UBYTEs

Schleife pen = 0 bis numalloc-1
{
mein_colortable[pen] =
ObtainPen(cm, colortable[pen], 0, 0, 0, PEN_NO_SETCOLOR)
}

Später zum Freigeben:

Schleife pen = 0 bis numalloc-1
{
ReleasePen(cm, mein_colortable[pen])
}

Müßte auch ohne PEN_NO_SETCOLOR gehen. Es wird angenommen, daß ObtainPen keinen Fehler zurückgibt. Wenn das zu Unsicher ist mein_colortable als WORD Array (statt UBYTE Array) auslegen und beim Freigeben checken ob mein_colortable[pen] ungleich -1 ist.


[ - Antworten - Zitieren - Direktlink - ]
03.01.2007, 20:56 Uhr

Ralf27
Posts: 2779
Nutzer 		@Georg:

Genau so hab ich das auch gemacht, aber leider geht das nicht. Die Stifte werden nicht reserviert. ObtainPen verlangt wohl noch die RGB-Farben.
--
http://www.alternativercomputerclub.de.vu

[ - Antworten - Zitieren - Direktlink - ]
03.01.2007, 21:22 Uhr

Ralf27
Posts: 2779
Nutzer 		ObtainPen:
>If there is no Palextra attached to the colormap, then this
routine will always fail.

Oh, was bedeutet das denn schon wieder? Ich vermute mal das es daran hängt.
--
http://www.alternativercomputerclub.de.vu

[ - Antworten - Zitieren - Direktlink - ]
03.01.2007, 21:46 Uhr

Ralf27
Posts: 2779
Nutzer 		AttachPalExtra() hab ich übrigens gefunden und obwohl der NULL zurück liefert, kann ich die Pens nicht reservieren.

Kurz mal am Rande: Komplizierter geht es wohl nicht? :(
--
http://www.alternativercomputerclub.de.vu

[ - Antworten - Zitieren - Direktlink - ]
03.01.2007, 22:25 Uhr

NoImag
Posts: 1050
Nutzer
Zitat:
Original von Ralf27:
ObtainPen:
>If there is no Palextra attached to the colormap, then this
routine will always fail.

Oh, was bedeutet das denn schon wieder? Ich vermute mal das es daran hängt.

Wo hast Du denn die Colormap her? Bei mir funktioniert ObtainPen(). Bekommst du etwas zurück, wenn du als Pen -1 angibst?

Wie sieht denn jetzt die ColorTable aus? Stehen da jetzt vernünftige Werte drin? Wenn nicht, dann poste hier mal den Code, wie Du die ColorTable ermittelst.

PDA_CRegs schaue ich mir morgen mal an.

Tschüß


[ - Antworten - Zitieren - Direktlink - ]
03.01.2007, 23:29 Uhr

Ralf27
Posts: 2779
Nutzer
Zitat:
Original von NoImag:

Wo hast Du denn die Colormap her? Bei mir funktioniert ObtainPen().
cm&=PEEKL(scr&+ScreenViewPort+ColorMap)
Zitat:
Bekommst du etwas zurück, wenn du als Pen -1 angibst?
Ja, das es nicht geht.
Zitat:
Wie sieht denn jetzt die ColorTable aus? Stehen da jetzt vernünftige Werte drin? Wenn nicht, dann poste hier mal den Code, wie Du die ColorTable ermittelst.
Die Werte bei ColorTable2 kommen hin. Bei ColorTable hab ich teilweise seltsame Werte bekommen die ich mir nicht erklären kann. Ich hab auch einfach mal versucht die Pens 0-7 zu sichern, ging auch nicht.
Zitat:
PDA_CRegs schaue ich mir morgen mal an.

Danke :glow:
--
http://www.alternativercomputerclub.de.vu

[ - Antworten - Zitieren - Direktlink - ]
04.01.2007, 00:15 Uhr

Holger
Posts: 8116
Nutzer
Zitat:
Original von Ralf27:
Dann hab ich mal verscht mal PDA_CRegs die 32Bit-Register nach Obtainpen zu übertragen. Aber nunja, ging auch nicht, weil ich mir auch nicht sicher bin wie die Struktur von CReg ist:
WORD: Anzahl Farben
WORD: Unbelegt?
Von 1 bis Anzahl Farben:
LONG: R
LONG: G
LONG: B

Also, ich kenne nur PDTA_CRegs. Allerdings weiß ich nicht, ob das für Dich überhaupt das richtige Attribut ist, da es die Farben der Quell-BitMap meint. Für die Farbtabelle der Remapped BitMap soll es PDTA_GRegs sein.

Der Aufbau ist derselbe. Laut Dokumentation so, dass er mit SetRGB32CM() verwendet werden kann, was aber gar keinen Sinn ergibt. Gemeint ist wohl eher LoadRGB32().

Die Tabelle für LoadRGB32() hat folgenden Aufbau:

UWORD Anzahl, Index der ersten Farbe
ULONG R, G, B

Es sind so viele Farben, wie als Anzahl angegeben, dann folgt wieder eine Anzahl und Index und so weiter, bis als Anzahl 0 angeben ist.

Bei Shared Pens kann das also durchaus ne ganze Menge Fragmente ergeben, z.B.

UWORD 4, 100
ULONG R, G, B; <= Farbe 100
ULONG R, G, B; <= Farbe 101
ULONG R, G, B; <= Farbe 102
ULONG R, G, B; <= Farbe 103
UWORD 1, 201
ULONG R, G, B; <= Farbe 201
UWORD 3, 250
ULONG R, G, B; <= Farbe 250
ULONG R, G, B; <= Farbe 251
ULONG R, G, B; <= Farbe 252
UWORD 0


oder aber auch


UWORD 1, 113
ULONG R, G, B; <= Farbe 113
UWORD 1, 115
ULONG R, G, B; <= Farbe 115
UWORD 1, 117
ULONG R, G, B; <= Farbe 117
UWORD 1, 119
ULONG R, G, B; <= Farbe 119
UWORD 1, 201
ULONG R, G, B; <= Farbe 201
UWORD 1, 207
ULONG R, G, B; <= Farbe 207
UWORD 0


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

[ - Antworten - Zitieren - Direktlink - ]
04.01.2007, 00:37 Uhr

Holger
Posts: 8116
Nutzer
Zitat:
Original von Ralf27:
ObtainPen:
>If there is no Palextra attached to the colormap, then this
routine will always fail.

Oh, was bedeutet das denn schon wieder? Ich vermute mal das es daran hängt.

Nein, daran hängt es nicht. ColorMaps, die zu einem intuition-screen gehören, haben immer eine entsprechende Struktur. Dieser Hinweis ist nur für von Hand erzeuge ColorMaps wichtig. Deshalb brauchst Du die AttachPalExtra() Funktion auch nicht aufzurufen.

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

[ - Antworten - Zitieren - Direktlink - ]
04.01.2007, 12:42 Uhr

Georg
Posts: 107
Nutzer
Zitat:
Original von Ralf27:
Genau so hab ich das auch gemacht, aber leider geht das nicht. Die Stifte werden nicht reserviert. ObtainPen verlangt wohl noch die RGB-Farben.

Wenn du den Screen selbst öffnest {SA_SharePens, TRUE} angeben (außer du nutzt eh {SA_LikeWorkbench, TRUE}, da sind pens automatisch shared).

Wenn wir das in AROS Intuition nicht falsch gemacht haben, dann ist es so, daß beim Screen Öffnen die DrawInfo pens (was man im Palette Prefs Programm einstellt) als Shared gelocked werden und falls SharedPens == FALSE alle restlichen Pens als exclusive.


[ - Antworten - Zitieren - Direktlink - ]
04.01.2007, 16:48 Uhr

Ralf27
Posts: 2779
Nutzer
Zitat:
Original von Georg:
Wenn du den Screen selbst öffnest {SA_SharePens, TRUE} angeben (außer du nutzt eh {SA_LikeWorkbench, TRUE}, da sind pens automatisch shared).

Wenn wir das in AROS Intuition nicht falsch gemacht haben, dann ist es so, daß beim Screen Öffnen die DrawInfo pens (was man im Palette Prefs Programm einstellt) als Shared gelocked werden und falls SharedPens == FALSE alle restlichen Pens als exclusive.
Der Test war auf der WB in einem eigenen Fenster. Aber auch denn privaten Screen mach ich mit SA_SharePens auf, sonst würde das ganze mit den Pens ja auch auf dem eigenen Screen nicht laufen. Nur halt das Datatypeunabhängig machen von den Pens will nicht so laufen.
--
http://www.alternativercomputerclub.de.vu

[ - Antworten - Zitieren - Direktlink - ]
04.01.2007, 16:50 Uhr

Ralf27
Posts: 2779
Nutzer
Zitat:
Original von Holger:
Nein, daran hängt es nicht. ColorMaps, die zu einem intuition-screen gehören, haben immer eine entsprechende Struktur. Dieser Hinweis ist nur für von Hand erzeuge ColorMaps wichtig. Deshalb brauchst Du die AttachPalExtra() Funktion auch nicht aufzurufen.

Achso, also kann man auch noch Screens mit der Hand generieren? Oh, ich wüßte zu gerne wie das aussieht. Denn wenn ich schon seh wie der Unterschied ist zwischen Basic (screen 1,320,200,1,1) und Betriebssystemroutinen (einige Zeilen) ist, dann dürfte das "mit der Hand" schon recht "ausführlich" sein.

Aus reinem Interesse:
Kann man sich sowas irgendwo mal ansehn wie das aussieht? :rolleyes:
--
http://www.alternativercomputerclub.de.vu

[ - Antworten - Zitieren - Direktlink - ]
04.01.2007, 16:56 Uhr

Ralf27
Posts: 2779
Nutzer 		@Holger:

Interesant. Ok, bin auf PDTA_GRegs umgestiegen (was auch logischer ist :) ), aber irgendwie bekomme ich mit zurückgelieferen Zeiger seltsame werte raus.
Ich nehme doch stark an das der zurückgelieferte Zeiger direkt auf diese Struktur zeigt und das das erste Word an dieser Adresse gleich Anzahl und dann Offset ist. Aber selbst die ersten Zahlen dürften falsch sein, da diese außer dem Bereich des logischen sind. Was ja Zahlen von kleiner null bzw. größer 255 sein dürften. Ich geh doch recht in der Annahme (ja, schon klar :D ), das es beim AmigaOS nur maximal 256(0-255) Pens gibt (obwohl Word)?
--
http://www.alternativercomputerclub.de.vu

[ - Antworten - Zitieren - Direktlink - ]
04.01.2007, 22:20 Uhr

NoImag
Posts: 1050
Nutzer
Zitat:
Original von Ralf27:
cm&=PEEKL(scr&+ScreenViewPort+ColorMap)

Das ist in Ordnung. An der ColorMap liegt es nicht.

Zitat:
Zitat:
Bekommst du etwas zurück, wenn du als Pen -1 angibst?
Ja, das es nicht geht.

mit "n=ObtainPen(ColorMap,-1,0,0,0,0)" geht es nicht? Das ist sehr merkwürdig. Schwarz hast Du aber auf dem Screen (normalerweise ist der TextPen schwarz)?

Zitat:
Die Werte bei ColorTable2 kommen hin. Bei ColorTable hab ich teilweise seltsame Werte bekommen die ich mir nicht erklären kann. Ich hab auch einfach mal versucht die Pens 0-7 zu sichern, ging auch nicht.

Poste doch bitte den Code.

Tschüß


[ - Antworten - Zitieren - Direktlink - ]
04.01.2007, 22:23 Uhr

NoImag
Posts: 1050
Nutzer
Zitat:
Original von Ralf27:
Achso, also kann man auch noch Screens mit der Hand generieren? Oh, ich wüßte zu gerne wie das aussieht. Denn wenn ich schon seh wie der Unterschied ist zwischen Basic (screen 1,320,200,1,1) und Betriebssystemroutinen (einige Zeilen) ist, dann dürfte das "mit der Hand" schon recht "ausführlich" sein.

Aus reinem Interesse:
Kann man sich sowas irgendwo mal ansehn wie das aussieht? :rolleyes:

Besorge Dir "Supergrafik Amiga" von Data Becker.

Tschüß


[ - Antworten - Zitieren - Direktlink - ]
04.01.2007, 22:25 Uhr

NoImag
Posts: 1050
Nutzer
Zitat:
Original von Ralf27:
Interesant. Ok, bin auf PDTA_GRegs umgestiegen (was auch logischer ist :) ), aber irgendwie bekomme ich mit zurückgelieferen Zeiger seltsame werte raus.
Ich nehme doch stark an das der zurückgelieferte Zeiger direkt auf diese Struktur zeigt und das das erste Word an dieser Adresse gleich Anzahl und dann Offset ist. Aber selbst die ersten Zahlen dürften falsch sein, da diese außer dem Bereich des logischen sind.

Poste doch bitte den Code.

Zitat:
Was ja Zahlen von kleiner null bzw. größer 255 sein dürften. Ich geh doch recht in der Annahme (ja, schon klar :D ), das es beim AmigaOS nur maximal 256(0-255) Pens gibt (obwohl Word)?

Deine Annahme ist korrekt.

Tschüß


[ - Antworten - Zitieren - Direktlink - ]
04.01.2007, 23:19 Uhr

Ralf27
Posts: 2779
Nutzer
code:
TAGLIST tagsl&, _
   PDTA_DestBitMap&, VARPTR(obitmapBild&), _
   DTA_NominalHoriz&, VARPTR(oBreite&), _
   DTA_NominalVert&, VARPTR(oHoehe&), _
   PDTA_GRegs&, VARPTR(liste&), _
   TAG_END&
   junk=GetDTAttrsA(oBild&,tagsl&)
   DO
    x=PEEKW(liste&)
    y=PEEKW(liste&+2):liste&=liste&+4
    FOR x2=1 TO x
     IF ObtainPen(cm&,y,PEEKL(liste&),PEEKL(liste&+4),PEEKL(liste&+8),PEN_NO_SETCOLOR&)=-1 THEN
      Meldung"Konnte Pen nicht sicher?",0
     ELSE
      SharedPen(y)=1
     END IF
    INCR y:liste&=liste&+12
    NEXT
   LOOP UNTIL PEEKW(liste&)=0

So sieht die Sache aus. Meldung ist übrigens ein Unterprogramm das die Texte als Request ausgibt.
Das ist jetzt der Code ohne besondere Kontrollen(z.b. Pen auch>=0 <=255), die ich eventuell noch einbauen möchte. Hab auch schon mit PEN_NO_COLOR& und ohne probiert, ging auch nicht. Ich bekomme immer, das der Pen nicht gesichert werden konnte. Bzw. wenn ich die rechte Maustaste drück, dann verstellen sich die Farben, wenn das Datatype freigegeben ist.

Beim Ablauf der Routine ist das Datatype übrigens noch nicht freigegeben. Daran liegt es also auch nicht. :)
--
http://www.alternativercomputerclub.de.vu

[ - Antworten - Zitieren - Direktlink - ]
04.01.2007, 23:26 Uhr

Ralf27
Posts: 2779
Nutzer
Zitat:
Original von NoImag:
Besorge Dir "Supergrafik Amiga" von Data Becker.

Ich hab das Buch hier in 2 Versionen. Einmal als dicker Schinken (705Seiten) und einmal als dünne Neuauflage (405Seiten).

Bin kurz mal durch hab ein Beispiel mit 4 ViewPorts gleichzeitig gefunden. Irgendwie recht komplex. :)
--
http://www.alternativercomputerclub.de.vu

[ - Antworten - Zitieren - Direktlink - ]
05.01.2007, 01:03 Uhr

Ralf27
Posts: 2779
Nutzer 		Ich hab jetzt eine ganz andere Lösung des Problems gefunden, die ich erst nach langer suche gefunden habe, die es bei OS3.1 nicht gibt:

PDTA_UseFriendBitMap

Dies gibt es erst ab V43 und ich mußte mir erst mal mühevoll denn Wert in den C-Includes zusammenrechnen und hab es dann getestet. Als Default ist PDTA_UseFriendBitmap auf TRUE, wenn ich dies auf FALSE stelle, dann geht es! Was vorher falsch angezeigt worden war (ohne zwischenspeichern in die eigene Bitmap) läuft dann richtig! Ich muß dann die Bitmap vom Datatype nicht mehr kopieren damit BltMaskBitMapRastport richtig läuft. Da ergeben sich jetzt einige Frage bzw. interesante Sachen:

* Ich darf auch nicht bei AllocBitmap als Friendbitmap z.b. den Screen angeben (AGA-Screen), denn dann geht es auch wieder nicht. Bzw. da NULL übergeben, sonst gibt es Datenmüll.

* Was macht eigentlich der Datatype *vor* V43? Der Befehl PDTA_UserFriendBitmap gibt es ja erst ab V43, aber wie verhält es sich vorher? Sollte ich die Version kontrollieren und zur Not dann doch in meine eigene Bitmap zwischenspeichern, wenn die Version kleiner V43 ist? Dann bräuchte aber doch wieder die Pensichern-Story, wenn ich die Doppelbelegung nicht möchte.

* Wieso spinnen denn die Betriebssystemroutinen bei Friendbitmap sogar auf Classicrechnern ohne Grafikkarte? Das ist wirklich sehr merkwürdig.

Und jetzt rein interessenhalber:
Wo hängt es nur beim Pens sichern...
--
http://www.alternativercomputerclub.de.vu

[ Dieser Beitrag wurde von Ralf27 am 05.01.2007 um 01:04 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]
05.01.2007, 10:23 Uhr

Ralf27
Posts: 2779
Nutzer 		Nochmal wegen GRegs, etc.:

Hab da was gefunden wegen denn Datatypes und denn Registern:

>Das picture.datatype initialisiert immer PDTA_CRegs in übereinstimmung mit PDTA_NumColors. Jede Unterklasse muß in aller Strenge die tags PDTA_GRegs und PDTA_ColorRegisters füllen (alle machen es nicht. das wäre zu einfach!).

(wurde aus dem Französischen via Google übersetzt)

EDIT: Originalquelle: http://www.guru-meditation.net/main.php3?root=157

Das bedeutet wohl, das ich nicht immer die Infos erhalte, jenachdem wie gut das Datatype programmiert wurde, das ich benutze.

Außerdem steht drin, das sich z.b. zwischen den Datatypeversionen hin und wieder die Defaulteinstellungen ändern. Z.b. PMODE42<->PMODE43. Da wird man ja zum Hirsch. Da ich FriendlyBitmap auf FALSE habe, sollte ich dann wohl auch PMODE42 einsetzen. Denn ich kann dann wohl auch nur bis 8Bit gehn, was ja ausreichend ist.

Ich hab richtigen Respekt vor den Leuten die das ganze noch durchblicken.
--
http://www.alternativercomputerclub.de.vu

[ Dieser Beitrag wurde von Ralf27 am 05.01.2007 um 10:24 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

1 -2- 3 [ - Beitrag schreiben - ]


amiga-news.de Forum > Programmierung > Datatypes: Farben festlegen lassen [ - Suche - Neue Beiträge - Registrieren - Login - ]


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