DEUTSCHE VERSION |
|
Links | | | Forums | | | Comments | | | Report news |
Chat | | | Polls | | | Newsticker | | | Archive |
amiga-news.de Forum > Programmierung > Datatypes: Farben festlegen lassen | [ - Search - New posts - Register - Login - ] |
1 -2- 3 | [ - Post reply - ] |
2006-10-09, 15:01 h thomas Posts: 7718 User |
@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/ [ - Answer - Quote - Direct link - ] |
2006-10-09, 20:48 h Ralf27 Posts: 2779 User |
@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 [ - Answer - Quote - Direct link - ] |
2006-10-09, 22:39 h Ralf27 Posts: 2779 User |
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! -- http://www.alternativercomputerclub.de.vu [ - Answer - Quote - Direct link - ] |
2006-10-09, 22:46 h thomas Posts: 7718 User |
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/ [ - Answer - Quote - Direct link - ] |
2006-10-10, 18:09 h NoImag Posts: 1050 User |
Zitat: Du kannst die Pens nicht ermitteln, allozieren oder etwas anderes? Tschüß [ - Answer - Quote - Direct link - ] |
2006-10-12, 23:01 h Ralf27 Posts: 2779 User |
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 [ - Answer - Quote - Direct link - ] |
2007-01-01, 19:52 h Ralf27 Posts: 2779 User |
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 [ - Answer - Quote - Direct link - ] |
2007-01-01, 21:54 h Ralf27 Posts: 2779 User |
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 [ - Answer - Quote - Direct link - ] |
2007-01-01, 23:21 h NoImag Posts: 1050 User |
Zitat: 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üß [ - Answer - Quote - Direct link - ] |
2007-01-02, 23:10 h Ralf27 Posts: 2779 User |
Zitat: 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 [ - Answer - Quote - Direct link - ] |
2007-01-03, 18:09 h Ralf27 Posts: 2779 User |
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 [ - Answer - Quote - Direct link - ] |
2007-01-03, 18:52 h Georg Posts: 107 User |
@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. [ - Answer - Quote - Direct link - ] |
2007-01-03, 20:56 h Ralf27 Posts: 2779 User |
@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 [ - Answer - Quote - Direct link - ] |
2007-01-03, 21:22 h Ralf27 Posts: 2779 User |
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 [ - Answer - Quote - Direct link - ] |
2007-01-03, 21:46 h Ralf27 Posts: 2779 User |
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 [ - Answer - Quote - Direct link - ] |
2007-01-03, 22:25 h NoImag Posts: 1050 User |
Zitat: 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üß [ - Answer - Quote - Direct link - ] |
2007-01-03, 23:29 h Ralf27 Posts: 2779 User |
Zitat:cm&=PEEKL(scr&+ScreenViewPort+ColorMap) Zitat:Ja, das es nicht geht. 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. Zitat: Danke -- http://www.alternativercomputerclub.de.vu [ - Answer - Quote - Direct link - ] |
2007-01-04, 00:15 h Holger Posts: 8116 User |
Zitat: 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. [ - Answer - Quote - Direct link - ] |
2007-01-04, 00:37 h Holger Posts: 8116 User |
Zitat: 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. [ - Answer - Quote - Direct link - ] |
2007-01-04, 12:42 h Georg Posts: 107 User |
Zitat: 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. [ - Answer - Quote - Direct link - ] |
2007-01-04, 16:48 h Ralf27 Posts: 2779 User |
Zitat: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 [ - Answer - Quote - Direct link - ] |
2007-01-04, 16:50 h Ralf27 Posts: 2779 User |
Zitat: 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? -- http://www.alternativercomputerclub.de.vu [ - Answer - Quote - Direct link - ] |
2007-01-04, 16:56 h Ralf27 Posts: 2779 User |
@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 ), das es beim AmigaOS nur maximal 256(0-255) Pens gibt (obwohl Word)? -- http://www.alternativercomputerclub.de.vu [ - Answer - Quote - Direct link - ] |
2007-01-04, 22:20 h NoImag Posts: 1050 User |
Zitat: Das ist in Ordnung. An der ColorMap liegt es nicht. Zitat:Zitat: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: Poste doch bitte den Code. Tschüß [ - Answer - Quote - Direct link - ] |
2007-01-04, 22:23 h NoImag Posts: 1050 User |
Zitat: Besorge Dir "Supergrafik Amiga" von Data Becker. Tschüß [ - Answer - Quote - Direct link - ] |
2007-01-04, 22:25 h NoImag Posts: 1050 User |
Zitat: Poste doch bitte den Code. Zitat: Deine Annahme ist korrekt. Tschüß [ - Answer - Quote - Direct link - ] |
2007-01-04, 23:19 h Ralf27 Posts: 2779 User |
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 [ - Answer - Quote - Direct link - ] |
2007-01-04, 23:26 h Ralf27 Posts: 2779 User |
Zitat: 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 [ - Answer - Quote - Direct link - ] |
2007-01-05, 01:03 h Ralf27 Posts: 2779 User |
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. ] [ - Answer - Quote - Direct link - ] |
2007-01-05, 10:23 h Ralf27 Posts: 2779 User |
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. ] [ - Answer - Quote - Direct link - ] |
1 -2- 3 | [ - Post reply - ] |
amiga-news.de Forum > Programmierung > Datatypes: Farben festlegen lassen | [ - Search - New posts - Register - Login - ] |
Masthead |
Privacy policy |
Netiquette |
Advertising |
Contact
Copyright © 1998-2024 by amiga-news.de - all rights reserved. |