|
ENGLISH VERSION |
|
 |
| Links | | | Forum | | | Kommentare | | | News melden |
|
| Chat | | | Umfragen | | | Newsticker | | | Archiv |
|
| amiga-news.de Forum > Programmierung > akgif-datatype | [ - Suche - Neue Beiträge - Registrieren - Login - ] |
| -1- | [ - Beitrag schreiben - ] |
|
25.12.2006, 13:23 Uhr Ralf27 Posts: 2779 Nutzer |
Ich hab hier ein kleines Problem mit dem akgif-Datatype und frag mich wirklich ob es an mir liegt oder am Datatype, da es mit anderen gif-Datatypes läuft: Wenn ich ein Gif-Bild das eine Farbtiefe von 1Bit habe lade, dann bekomme ich eine Bitmap zurück die 0(!) Bit tief ist, also ungültig ist. Dies scheint aber nur bei diesem Datatype so zu sein, mit anderen GIF-Datatypes läuft es richtig. Ist dies anderen auch schon aufgefallen oder liegt es vermutlich wiedermal an meinem Programm?  PS: Fröhliche Weihnachten!  -- http://www.alternativercomputerclub.de.vu [ - Antworten - Zitieren - Direktlink - ] |
|
27.12.2006, 16:55 Uhr ZeroG Posts: 1487 Nutzer |
@Ralf27: Klingt so als hätte der Datatype ne Macke. Wenn du was falschmachen würdest, würde es auch mit anderen Datatypes in die Hose gehen. Man möge mich korrigieren, wenn ich falsch liege. [ - Antworten - Zitieren - Direktlink - ] |
|
29.12.2006, 14:55 Uhr akl Posts: 265 Nutzer |
@ZeroG: akGIF setzt das Flag BMF_INTERLEAVED, d.h. die Bitmap ist keine Standard-Bitmap - daher verbietet sich auch das Peeken direkt in der Bitmap bzgl. Tiefe usw. (ich hoffe, das machst Du nicht ;-) MultiView hat übrigens keine Probleme, 1bit-Bitmaps anzuzeigen, die von akGIF geliefert werden. Ansonsten bitte auch gerne immer direkt per eMail anschreiben, dann lässt sich vermeiden, dass irgendwelche Gerüchte über Bugs kursieren, von denen ausgerechnet der Autor nichts weiss 8-) Umgekehrt kann ich das dann auch gleich überprüfen und ggf. korrigieren. Danke! [ - Antworten - Zitieren - Direktlink - ] |
|
29.12.2006, 16:14 Uhr Ralf27 Posts: 2779 Nutzer |
@akl: Es wird nicht in den Daten "gepeekt", sondern Betriebssystemfunktionen eingesetzt. Und da macht eben nur dieser Datatype Schwierigkeiten. Außerdem wird gerade aus diesem Grund nicht direkt an den Daten vom Datatype rumgemacht, weil diese eben auch BMF_INTERLEAVED sein können und teilweise auch sind. Deswegen wird mit BltBitMap die Daten in eine eigene Map kopiert. Diese Map weis nichts von der Datatypemap, außer die Breite und Höhe, bzw. die Tiefe ist ja immer 1. Und wenn GetBitMapAttr bei der Datatypebitmap mit BMA_DEPTH eine NULL liefert... -- http://www.alternativercomputerclub.de.vu [ - Antworten - Zitieren - Direktlink - ] |
|
29.12.2006, 16:21 Uhr Ralf27 Posts: 2779 Nutzer |
Achja, es kann natürlich auch ein Problem mit meinem Programm sein, was ja auch sehr wahrscheinlich ist.  -- http://www.alternativercomputerclub.de.vu [ - Antworten - Zitieren - Direktlink - ] |
|
29.12.2006, 17:24 Uhr malte2 Posts: 148 Nutzer |
BMF_INTERLEAVED ist eine Standardbitmap, schließlich sind die Daten immernoch planar organisiert. Eine Bitmap-Tiefe von 0 ist zwar erlaubt, zB. macht BltBitMap() dann garnichts, aber der Einsatz solcher Tricks ist doch etwas fragwürdig. [ - Antworten - Zitieren - Direktlink - ] |
|
30.12.2006, 01:02 Uhr Ralf27 Posts: 2779 Nutzer |
Zitat: Zja, wie muß man dann richtig vorgehn, damit es auch damit läuft? Wenn z.b. Multiview 1Bit-GIF mit akgif richtig anzeigen kann, dann muß es da ja auch einen Kniff dazu geben. -- http://www.alternativercomputerclub.de.vu [ - Antworten - Zitieren - Direktlink - ] |
|
30.12.2006, 03:10 Uhr Holger Posts: 8116 Nutzer |
Zitat:Multiview greift nicht auf die BitMaps der Datatypes zu. Es gibt dem Datatype lediglich die Anweisung, das Objekt auf den Bildschirm zu pinseln. Wenn Du es sehen kannst, hat es funktioniert. Das hilft Dir aber nicht, wenn die Funktion für den Zugriff auf die BitMap nicht richtig funktioniert. Du kannst vielleicht versuchen, das Bild auf einen Screen zu remappen und dann nicht nach der Quell-, sondern der umgerechneten BitMap fragen. Aber ob das Ergebnis den Aufwand rechtfertigt, ist allerdings fraglich. mfg -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
|
13.01.2007, 21:56 Uhr akl Posts: 265 Nutzer |
@malte2: Ok, immer der Reihe nach. 1. Ob BMF_INTERLEAVED eine "Standard"-Bitmap ist, oder nicht, ist Ermessenssache. Jedenfalls ist das Layout anders und vor allen Dingen die Bytes pro Zeile. Und diese Bitmaps sind nunmal in V39 zeitgleich mit dem Verbot eingeführt worden, in Bitmaps direkt herumzupeeken oder irgendwelche entsprechenden Annahmen zu treffen, wie früher bei Standard-Bitmaps. 2. Was diverse Patches und/oder CyberGraphics & Co. unter bestimmten Bedingungen aus einer Interleaved-Bitmap machen, weiss ich nicht. Jedenfalls möglicherweise etwas anderes als aus einer BMF_STANDARD-Bitmap... (siehe 6.) 3. akGIF setzt nirgendwo eine Tiefe von 0 für 1 Bit-Grafiken an, sondern immer exakt die Tiefe, die in der GIF-Datei steht (also 1). 4. akGIF enthält jedoch zusätzlich einen expliziten Workaround für irgendeinen Bug (dem ich irgendwann einmal begegnet bin) der dafür sorgt, dass jede Tiefe <= 1 auf exakt 2 erhöht wird. 5. Der pic-dt erhält also von akGIF für Bitmaps der Tiefe 1 unter gar keinen Umständen eine Tiefenangabe 0, sondern stets eine Tiefe von 2. Das ist der Wert, der auch in bmh_Depth steht. Ob akGIF die Bitmap selbst alloziert, oder ob der pic-dt das macht, hängt von der OS-Umgebung ab. 6. Eine Tiefe von 0 in der Bitmap-Struktur (die sich von der in der BMHD-Struktur unterscheiden kann) deutet stark auf eine Tiefe größer 8 bzw. eine RTG-Bitmap hin. Hope, that helps. [ - Antworten - Zitieren - Direktlink - ] |
|
13.01.2007, 21:58 Uhr akl Posts: 265 Nutzer |
@Holger: Der akGIF-Datatype pinselt nicht selbst, sondern der picture-datatype. Je nach Umgebung alloziert letzterer auch die Bitmap. Dass es mit MultiView geht, beweist, dass die Standard-OS-Klassen sich richtig verhalten - nicht mehr, nicht weniger. [ Dieser Beitrag wurde von akl am 13.01.2007 um 21:59 Uhr geändert. ] [ - Antworten - Zitieren - Direktlink - ] |
|
13.01.2007, 22:01 Uhr akl Posts: 265 Nutzer |
@Ralf27: >Und wenn GetBitMapAttr bei der Datatypebitmap mit BMA_DEPTH eine NULL >liefert... Dann handelt es sich möglicherweise um eine RTG-Bitmap, die entstanden ist, indem die ursprüngliche Bitmap auf einen RTG-Screen remappt worden ist. [ - Antworten - Zitieren - Direktlink - ] |
|
13.01.2007, 22:49 Uhr thomas Posts: 7716 Nutzer |
Eine 0 in der Bitmap-Struktur ist nicht zulässig. Bei RTG-Bitmaps steht da aus Kompatibilitätsgründen immer eine 8 drin. GetBitMapAttr(bm,BMA_DEPTH) gibt die reale Tiefe zurück, also bei RTG entweder 8, 16 oder 24. Ich würde in diesem Fall erstmal die GIF-Datei überprüfen, vielleicht steht da ja schon die falsche Tiefe drin. Gruß Thomas -- Email: thomas-rapp@web.de Home: thomas-rapp.homepage.t-online.de/ [ - Antworten - Zitieren - Direktlink - ] |
|
14.01.2007, 13:02 Uhr Ralf27 Posts: 2779 Nutzer |
Zitat: Diese NULL bei der Bitmaptiefe bekomme ich auf einem reinen Customchipsatzrechner ohne Grafikkarte. Die Bildtiefe der Datei liegt bei einem Bit, also wenn ich diese z.b. via PPaint öffne. Ich hab die Masken auf IFF-ILBM jetzt konnvertiert und bekomme diesen Fehler nicht mehr. Außerdem: Ich hab mal testweise FriendBitmap auf FALSE gestellt, was aber auch in die Hose ging  Ich benutzt für die Bilder nur BltBitMap und BltMaskBitMapRastport und sonst nix. -- http://www.alternativercomputerclub.de.vu [ - Antworten - Zitieren - Direktlink - ] |
|
19.01.2007, 17:14 Uhr akl Posts: 265 Nutzer |
@thomas: Es kann sehr gut sein, dass in der GIF-Datei 0 als Tiefe steht, weil die Range nur von 0..7 geht und als 1..8 interpretiert wird :-) Im Übrigen finde ich es lustig, was hier so alles an unterschiedlichen Meinungen über Bitmap-Tiefen von 0 steht - dass die Allozierung einer Bitmap mit Tiefe 0 via AllocBitmap() dann eigentlich fehlschlagen sollte, wäre dann allerdings auch zu bedenken... [ - Antworten - Zitieren - Direktlink - ] |
|
19.01.2007, 17:15 Uhr akl Posts: 265 Nutzer |
@Ralf27: Vielleicht lieferst Du uns ja irgendwann mal die volle Systemkonfiguration und die Version von akGIF, um die es geht. [ - Antworten - Zitieren - Direktlink - ] |
|
21.01.2007, 19:55 Uhr Ralf27 Posts: 2779 Nutzer |
@akl: Ich hab hier zwei Bugreports bei dem der GIF-Datatype vermutlich schuld war. Vorallem als ich gesehn habe was ein kleines Testprogramm von mir vom Datatype zurück bekommt. Eben diese NULL Farbtiefe. Leider kann ich jetzt keine Systemkonfiguration liefern. -- http://www.alternativercomputerclub.de.vu [ - Antworten - Zitieren - Direktlink - ] |
| -1- | [ - Beitrag schreiben - ] |
| amiga-news.de Forum > Programmierung > akgif-datatype | [ - Suche - Neue Beiträge - Registrieren - Login - ] |
|
|
Impressum |
Datenschutzerklärung |
Netiquette |
Werbung |
Kontakt
Copyright © 1998-2024 by amiga-news.de - alle Rechte vorbehalten. |
|