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

amiga-news.de Forum > Programmierung > Bitmaps nur durch 16 teilbare Breite? [ - Suche - Neue Beiträge - Registrieren - Login - ]

-1- 2 3 4 5 6 [ - Beitrag schreiben - ]

30.08.2006, 18:44 Uhr

bubblebobble
Posts: 707
Nutzer
Hallo !

Beim Rumspielen mit Bitmaps ist mir aufgefallen, dass man zwar
Bitmaps mit beliebigen Breiten anlegen darf (AllocBitmap()), und viele Operationen funktionieren auch damit, aber wenn man einen RastPort drauflegt funktioniert das nur mit Bitmaps, die eine Breite haben die durch 16 teilbar ist. Auch der Wert in Bitmap->BytesPerRow ist immer auf die nächste 16er Pixelbreite aufgerundet.

Das ist selbst bei 32bit/pixel Bitmaps so. Stimmt das, kann man dan irgnedwie umgehen oder bin ich gezwungen, alles in 16er Breiten anzulegen ?

--
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 - ]

30.08.2006, 19:00 Uhr

malte2
Posts: 148
Nutzer
BitMaps können eine beliebige Breite haben und für die Zeichenoperationen ist das auch ziemlich egal (wegen Rundung auf 16), GetBitMapAttr(bitmap, BMA_WIDTH) wird dir aber immer eine durch mind. 16 teilbare Breite zurückgeben da manche Programme ansonsten nicht mehr korrekt durch eine Maske blitten können.

[ - Antworten - Zitieren - Direktlink - ]

30.08.2006, 19:39 Uhr

bubblebobble
Posts: 707
Nutzer
Nein, den Zeichenoperationen ist das nicht egal, weil der BytesPerRow Eintrag frecherweise aufgerundet wird. Funktionen wie WritePixelArray, FillPixelArray etc. funktionieren dann nicht mehr, erzeugen dann ein geschertes Bild und schreiben am Ende sogar über den Speicherbereich.

--
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 - ]

30.08.2006, 19:56 Uhr

Holger
Posts: 8092
Nutzer
Zitat:
Original von bubblebobble:
Nein, den Zeichenoperationen ist das nicht egal, weil der BytesPerRow Eintrag frecherweise aufgerundet wird. Funktionen wie WritePixelArray, FillPixelArray etc. funktionieren dann nicht mehr, erzeugen dann ein geschertes Bild und schreiben am Ende sogar über den Speicherbereich.

Der Struktureintrag BytesPerRow sagt nicht, wie breit die BitMap ist, sondern wie viele Bytes Per Row das Abbild im Speicher belegt. Nun ist diese Zahl schon von sich aus ganzzahlig, also schon von daher aufgerundet. Außerdem können die auf den Chipsatz angepassten BitMaps nur eine ganzzahlige Anzahl von Words pro Zeile, also 16-Bit Werten enthalten. Das ist aber gar kein Problem, denn AllocBitMap macht das ja schon richtig. Da selbige Funktion auch BytesPerRow * Rows Bytes belegt, sollte es auch kein Problem sein, wenn die Zeichenfunktionen diesen Wert für voll nehmen. Allerdings sollten die modifizierten Bits normalerweise trotzdem innerhalb der BitMap liegen, wenn die verwendeten Koordinaten innerhalb der BitMap liegen.

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

[ - Antworten - Zitieren - Direktlink - ]

30.08.2006, 20:21 Uhr

jolo
Posts: 108
Nutzer
Hi,

meines Wissens nach müssen alle Bitmaps mindestens eine durch sechzehn teilbare Größe besitzen; der Grund liegt im Blitter der originalen Chip-Sets des Amigas - dieser kann nur Speicherbreiche WORD-weise ansprechen. Um nun Punktweise Verschiebungen vorzunehmen, kommt der Barrel-Shifter ins Spiel (ist ein Teil des Blitter). Dieser "sagt" dem Blitter ab welchem WORD er blitten soll und welche Masken verwandt werden müssen. Da die Masken auch nur WORD-weise vom Blitter angewandt werden können und zudem noch WORD-Größe besitzen, muss eine Bitmap immer ein Vielfaches von sechzehn breit sein, ansonsten droht das Überschreiben von fremden Speicherbereichen.

Anbei, um unter AGA den Burst-Fetch Modus nutzen zu können, muss anstelle von 16-Bit Boundaries eine 64-Bit-Bereichsgrenze verwandt werden.

Da Linien und auch Texte mit Hilfe des Blitter auf dem Monitor gezaubert werden/wurden, müssen/mussten Bitmaps immer auf ein vielfaches von sechzehn aufgerundet werden.

Selbst unter Picasso96 war die Bitmap eines Bildschirms in der Auflösung von 800 x 600 vor ein paar Jahren noch mindestens 832 Punkte breit - ob sich das geändert hat, weiß ich nicht.


Gruß

[ - Antworten - Zitieren - Direktlink - ]

30.08.2006, 21:51 Uhr

malte2
Posts: 148
Nutzer
Sowas wie:

struct RastPort rp;
InitRastPort(&trp);
rp.BitMap = AllocBitMap(w,h,t,0,bla);
irgendeine_x_beliebige_gfx_operation(&trp,...);

funktioniert IMMER egal, welchen Wert 'w' hat (natürlich größer 0). Wenn das nicht funktioniert, dann ist entweder das gfx system, welches Du benutzt, fehlerhaft oder Du machst irgendwas falsch.

[ Dieser Beitrag wurde von malte2 am 30.08.2006 um 21:51 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

31.08.2006, 09:33 Uhr

bubblebobble
Posts: 707
Nutzer
Ich denke ich habe den Fehler gefunden. Mir war das beim Programmieren nie aufgefallen, weil meine Testbitmap zufällig eine 16er Breite hatte.
Jetzt wirds aber unangenehm, ich muss den kompletten Code umschreiben mit seperatem BytesPerRow Parameter.
Mit guigfx.library kann ich dann auch nicht mehr arbeiten, weil dort kein BytesPerRow unterstützt wird, sondern immer von nahtlosen PixelArrays ausgegangen wird. Die Funktionalität muss ich dann auch noch nachproggen. Das hab ich auch schon zum größten Teil, nur Remapping fehlt mir noch.

Gibt es OS Funktionen für Remapping ?

Also z.B. ich habe eine ARGB bitmap, und will sie in das Screenbitmap Format konvertieren, was auch immer der Screen hat.

Kann man evtl. mit datatypes auch von Bitmap zu Bitmap remappen ?


--
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 - ]

31.08.2006, 17:09 Uhr

Holger
Posts: 8092
Nutzer
Zitat:
Original von bubblebobble:
Mit guigfx.library kann ich dann auch nicht mehr arbeiten, weil dort kein BytesPerRow unterstützt wird, sondern immer von nahtlosen PixelArrays ausgegangen wird.

Kann es sein, dass Du hier etwas durcheinanderwirfst?
Unter Pixel-Arrays würde ich normalerweise chunky-Pixel oder TrueColor Formate verstehen. Die haben aber nichts mit einer Chipsatz-BitMap zu tun, genaugenommen ist die BitMap-Struktur einer RTG-BitMap tabu. Was dort also unter dem vermeintlichen "bytesPerRow" Eintrag zu finden ist, ist irrelevant.

Und die Konvertierungsfunktionen der graphics.library untersützen natürlich auch andere BitMap-Breiten, nur tmpras-Breite muss aufgerundet sein. Und die Arrays sind natürlich nahtlos und unabhängig von der bytesPerRow-Angabe, wäre sonst auch ziemlich blöd, wenn man für den Transfer von oder zu Interleaved-BitMaps plötzlich das achtfache an Speicher benötigen würde...

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

[ - Antworten - Zitieren - Direktlink - ]

31.08.2006, 17:16 Uhr

thomas
Posts: 7680
Nutzer
Zitat:
Und die Konvertierungsfunktionen der graphics.library untersützen natürlich auch andere BitMap-Breiten, nur tmpras-Breite muss aufgerundet sein. Und die Arrays sind natürlich nahtlos und unabhängig von der bytesPerRow-Angabe

Nein, sind sie nicht. Bei Read/WritePixelArray8 muß auch der Array eine durch 16 teilbare Breite haben, ansonsten mußt du Read/WritePixelLine8 in einer Schleife aufrufen. "Nahtlos" ist nur WriteChunkyPixels, was es aber erst ab Kick 3.1 gibt und laut Autodocs ohne CD32-Hardware langsamer als WritePixelArray8 sein soll.

Gruß Thomas

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

[ - Antworten - Zitieren - Direktlink - ]

31.08.2006, 17:59 Uhr

Holger
Posts: 8092
Nutzer
Zitat:
Original von thomas:
"Nahtlos" ist nur WriteChunkyPixels, was es aber erst ab Kick 3.1 gibt und laut Autodocs ohne CD32-Hardware langsamer als WritePixelArray8 sein soll.

Was auch immer das heißen soll. Die CD32-Hardware wäre auf den typischen heute noch verwendeten Amigas wohl kaum ein Gewinn...

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

[ - Antworten - Zitieren - Direktlink - ]

31.08.2006, 18:02 Uhr

malte2
Posts: 148
Nutzer
WriteChunkyPixels() verwendet WritePixelLine8(), wenn keine C2P HW vorhanden ist.

[ - Antworten - Zitieren - Direktlink - ]

31.08.2006, 18:46 Uhr

bubblebobble
Posts: 707
Nutzer
Es sieht so aus, als ob AllocBitmap immer einen Speicherbereich allociert, dessen Pixelbreite durch 16 teilbar ist. BytesPerRow ist dann natürlich auch entsprechend gesetzt. Da ich aber immer konsequent von einem kontinuierlichen Speicherbereich ausgegangen bin, ist das nie aufgefallen, weil ich den "Fehler" sowohl lesend als auch schreibend gemacht habe. Bis zu dem Zeitpunkt, als ich OS Funktionen auf die Bitmap angewendet habe wie FillPixelArray. Und das auch erst, nachdem ich eine andere Bitmap genommen habe als meine Testbitmap, bei der alles wunderbar lief, da zufällig durch 16 teilbar.

Zusammenfassung:
Bei OS Bitmaps IMMER den BytesPerRow Eintrag in der Bitmap Struct berücksichtigen, niemals annehmen dass die Pixel alle hintereinander liegen!



--
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 - ]

31.08.2006, 19:47 Uhr

thomas
Posts: 7680
Nutzer
Zitat:
Original von bubblebobble:
Zusammenfassung:
Bei OS Bitmaps IMMER den BytesPerRow Eintrag in der Bitmap Struct berücksichtigen, niemals annehmen dass die Pixel alle hintereinander liegen!


Nein, im Prinzip ist das falsch. Wenn du Grafikkarten- und Zukunftskompatibilität möchtest, muß es heißen: bei allen Arten von Bitmaps nie direkt auf die Struktur zugreifen, sondern immer nur die Funktionen der graphics.library benutzen (AllocBitmap, Freebitmap, GetBitmapAttr etc.).

Gruß Thomas

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

[ - Antworten - Zitieren - Direktlink - ]

31.08.2006, 21:56 Uhr

Holger
Posts: 8092
Nutzer
Zitat:
Original von bubblebobble:
Bis zu dem Zeitpunkt, als ich OS Funktionen auf die Bitmap angewendet habe wie FillPixelArray.

FillPixelArray??
Falls Du WritePixelArray meinst, hat thomas schon explizit gesagt, dass die Anzahl der Pixel auf das nächste Vielfache von 16 aufgerundet werden muss, während WriteChunkyPixel kein Aufrunden erfordert.
Und zwar ganz egal, was in bytesPerRow steht.

Nur mal kurz ein Beispiel: wenn Du eine 17x17 große BitMap mit 256 Farben planar + interleaved anlegst, ist bytesPerRow 32 (!) Das braucht Dich aber nicht zu interessieren, wenn Du OS-Funktionen benutzt. WritePixelArray erwartet weiterhin durch 16 teilbare Größenangaben, d.h. wenn Du in oben beschriebene BitMap eine 16x16 Grafik reinkopierst, wird nichts aufgerundet.

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

[ - Antworten - Zitieren - Direktlink - ]

31.08.2006, 22:01 Uhr

malte2
Posts: 148
Nutzer
FillPixelArray() ist eine cgx Funktion. Im Prinzip ein Truecolor RectFill().

[ - Antworten - Zitieren - Direktlink - ]

31.08.2006, 22:11 Uhr

Holger
Posts: 8092
Nutzer
Zitat:
Original von malte2:
FillPixelArray() ist eine cgx Funktion. Im Prinzip ein Truecolor RectFill().

Na dann dürfte bytesPerRow definitiv irrelevant sein, schließlich gehört cgx zur Kategorie rtg, wenn ich mich nicht irre.

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

[ - Antworten - Zitieren - Direktlink - ]

31.08.2006, 23:30 Uhr

bubblebobble
Posts: 707
Nutzer
Was ich meine ist, dass man natürlich mit GetBitmapAttr() den BytesPerRow Wert auslesen sollte. Aber diesen natürlich auf jeden Fall beachten, wenn man selbst in die Bitmap hineinpoked.

Normalerweise interessiert das einen nicht, weil die OS Funktionen das sowieso berücksichtigen, aber z.B. musste ich einen eigenen PNG Loader schreiben um an die ARGB Bitmap des PNG Bildes zu kommen. Die Datatypes liefern 1. den Alpha Kanal nicht und 2. rechnen ihn in das Bild bereits ein, und blenden das gegen die Hintergrundfarbe.

Wenn ich das ganze jetzt in eine Bitmap hinein decodieren will, muss ich eben den BytesPerRow Wert berücksichtigen.
Ich könnte natürlich auch in ein kontinuierliches Pixelarray decodieren, und dann mit WritePixelArray das ganze in die Bitmap kopieren. Allerdings benötige ich dann temporär den doppelten Speicher.
Und ich habe noch jede Menge andere Funktionen wo ich direkt auf die Bitmap zugreife, z.B. zum Blitten mit Alpha channel, additiv, multiplikativ, transparent, texture-blit usw, also Blitmodi, die vom OS nicht geliefert werden.

Das einzige Problem was ich habe ist das Remappen. Wie kann man systemfreundlich eine ARGB Bitmap auf das Screenformat remappen ?


--
Thilo Köhler, Author von:
HD-Rec, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, TKUnpacker
Homepage: http://www.hd-rec.de



[ Dieser Beitrag wurde von bubblebobble am 31.08.2006 um 23:33 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

01.09.2006, 00:41 Uhr

DariusBrewka
Posts: 899
[Benutzer gesperrt]
Zitat:
Original von bubblebobble:
Normalerweise interessiert das einen nicht, weil die OS Funktionen das sowieso berücksichtigen, aber z.B. musste ich einen eigenen PNG Loader schreiben um an die ARGB Bitmap des PNG Bildes zu kommen. Die Datatypes liefern 1. den Alpha Kanal nicht und 2. rechnen ihn in das Bild bereits ein, und blenden das gegen die Hintergrundfarbe.


du benutzt AfA oder? und AFAIK kann man damit auch
Alpha vom PNG laden, mit dem picturedatatype davon, du mußt nur den Richtigen PNG Datatype haben, mit dem AkPNG ging das soweit ich es in Erinnerung habe.

Zitat:
Das einzige Problem was ich habe ist das Remappen. Wie kann man systemfreundlich eine ARGB Bitmap auf das Screenformat remappen ?

das habe ich zwar noch nicht getestet, aber ggf. kann man ein Datatypes Object erstellen und mittels PDTM_WRITEPIXELARRAY darein dein Image schreiben, dann hast du (das denke Ich zumindestens) ein ganz normales Datatype, welches du Layouten oder umrechnen lassen kannst. Aber Thomas hat da mehr Erfahrung als Ich.



[ - Antworten - Zitieren - Direktlink - ]

01.09.2006, 01:59 Uhr

whose
Posts: 2156
Nutzer
@DariusBrewka:

Wenn ich das alles richtig verstanden habe, will er aber kein AfA voraussetzen und, wenn möglich, keinen temporären Speicher in Größe der zu ladenden Bitmap belegen. Das wäre beim Umweg über PDTM_WRITEPIXELARRAY aber wohl der Fall. Ziemlich komplizierte Kiste...

Grüße

--
---

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

[ - Antworten - Zitieren - Direktlink - ]

01.09.2006, 08:19 Uhr

thomas
Posts: 7680
Nutzer
@bubblebobble:
Zitat:
Und ich habe noch jede Menge andere Funktionen wo ich direkt auf die Bitmap zugreife, z.B. zum Blitten mit Alpha channel, additiv, multiplikativ, transparent, texture-blit usw, also Blitmodi, die vom OS nicht geliefert werden.

Alles was du hier nennst, bezieht sich auf 24 oder 32 bit chunky Bitmaps, die es nur auf RTG-Systemen gibt. Und in diesem Fall darfst du nicht direkt in die Bitmap schreiben !!! Außerdem haben die Werte in der Bitmap-Struktur in diesem Fall nur Kompatibilitätswerte, die rein gar nichts über die eigentliche Bitmap aussagen !

Liest du eigentlich auch nur ansatzweise ein bißchen Dokumentation, bevor du anfängst zu programmieren ? Die Autodocs von CGX enthalten ein ganzes Kapitel über Bitmaps und was man damit machen darf und was nicht.

Wenn du direkt auf die Grafikdaten einer RTG-Bitmap zugreifen möchtest, dann mußt du sie mit LockBitMapTags sperren. Und dann bekommst du von dieser Funktion auch mitgeteilt, an welcher Adresse die tatsächlichen Daten liegen, wieviele Bytes pro Pixel, wieviele Bytes pro Zeile, welche nominelle Breite, welche Höhe und welches Pixelformat die Bitmap hat.

Zitat:
Das einzige Problem was ich habe ist das Remappen. Wie kann man systemfreundlich eine ARGB Bitmap auf das Screenformat remappen ?

Das mußt du wohl selber machen. Der code zum Renmappen ist zwar in jeder Datatypeklasse vorhanden, aber man kann ihn nicht einzeln aufrufen.

Du legst eine Bitmap im Screen-Format an (also mit der Screen-Bitmap als Friend), rufst LockBitMapTags auf und mußt dann alle bekannten Pixelformate unterstützen.

Gzuß Thomas

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

[ Dieser Beitrag wurde von thomas am 01.09.2006 um 08:20 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

01.09.2006, 12:02 Uhr

bubblebobble
Posts: 707
Nutzer
Also es ist so:

Ich schreibe eine Funktionsbibliothek, die 24 bit Bilder verwaltet.
(laden, speichern, blitten, manipulieren (auf ARGB Ebene) usw).

Ich will nicht vorraussetzen, dass der User AfA installiert hat und dazu auch noch ein ganz bestimmtes PNG Datatype, damit mein Program funktioniert. Es soll überall funktionieren.
Und ob das mit AfA+akpngDT funktioniert ist auch fraglich, da die PNG Datatypes das Bild meistens schon vergewaltigen wenn ein Alphachannel da ist, und nicht die Roh-Daten herausgeben. Wie auch immer, ich hab das ja schon alles implementiert, so wild ist das nicht.

Ich greife bisher NICHT auf direkt auf die Bitmaps zu. Alpha blitten funktioniert bei mir so, dass ich den Hintergrund mit WritePixelArray auslese, auf dem PixelArray arbeite (was ein garantiertes Pixelformat hat und im privaten RAM liegt) und dann mit ReadPixelArray wieder auf die Bitmap schreibe.
Das erfordert zwar einen temporären Puffer, ist aber vertretbar von der Geschwindigkeit her, weil man u.U. auch Hardwarebeschleuniung/native OS Funktionen ausnutzen kann. Ein direkten Lesen/Schreiben in die Bitmaps ist auf manchen Systemen sogar langsamer, das hatte ich am Anfang mal. Das wurde mir dann aber zu dumm, weil es doch viele verschiedene Pixelformate da draussen gibt.

Meine zu blittenden Bilder waren bisher auch ARGB PixelArrays im RAM, die ich mit der guigfx.library geladen habe. Und Bilder bearbeiten im RAM geht auf heutigen Rechnern sehr schnell, da nichts duch den Graphic Bus geschickt wird.

Jetzt will ich aber meine Bilder selbst zu Bitmaps machen (inkl. RastPort), damit ich auch alle OS Grafik Funktionen darauf anwenden kann. Dazu lege ich eine ARGB Bitmap mit AllocBitmap an. Ich denke, dass ich darauf auch pixelweise zugreifen darf, weil ich das PixelFormat beim Initialisieren explizit angebe, und ich gebe KEINE Friend Bitmap an und auch kein DISPLAYABLE Tag.
Ich muss eben nur die BytesPerRow berücksichtigen.

Diese Bitmap wird auch immer als ARGB gehalten, damit keine Information verloren geht (ich will ja nicht, dass z.B. mein Grafikprogram mein zu bearbeitendes Bild auf 16bit herunterrechnet, nur weil ich auf einem 16bit Screen arbeite).
Wenn ich jetzt aber auf den Screen blitten will, wird eine Shadow Bitmap angelegt, die im Screen Format ist (1-24bit, u.U. geremapped auf die Screenpalette).
Die Shadow Bitmap muss natürlich nach jeder Bildmanipulation aktualisiert werden.
Bisher habe ich dafür guigfx benutzt. Allerdings muss ich jetzt guigfx komplett rausschmeissen, weil guigfx nur mit kontinuierlichen PixelArrays zurecht kommt, nicht mit Bitmaps die ein Gap haben (also BytesPerRow != PixelWidth * BytesPerPixel).
(oder ich müsste vor dem Remappen ein PixelArray erzeugen, Remappen und es wieder verwerfen, aber dafür brauche ich temporär den doppelten speicher, und das remappen wird noch langsamer als es ohnehin schon ist).

Also ich sehe schon, ich muss entweder guigfx benutzen, oder wirklich alle Pixelformate abdecken.

Oder gibts eine bessere Lösung ?

Deckt wirklich jedes Datatype alle Pixelformate ab?
Das würde ja bedeuten, dass jeder Datatpye Author das Rad neu erfinden muss.

Eine OS Funktion wie CreateDisplayableBitmap(destbitmap, sourcebitmap, viewport) wäre wirklich toll gewesen.

:sleep: ... nach einigem Nachdenken ... :sleep:

Ist folgender Gedanken Gang korrekt:

Ich teste ob der Screen True/Hi color ist. (depth>=16)
Wenn ja, lege ich eine friend Btimap an und benutze ReadPixelArray um von meiner ARGB bitmap auf die friend bitmap zu mappen. ReadPixelArray mapped soweit ich weiss automatisch auf das Zielbitmap Format, solange es True/Hi color ist.

Wenn es ein Farbindizierter Screen ist, frage ich nach der Anzahl der Farben und schreibe EINE remapping Routine, die in ein 8bit PixelArray die entsprechenden Pens einträgt. (Können natürlich auch weniger als 256 Farben sein, das Array ist aber 8bit).
Dann benutze ich ReadPixelArray8 um das auf die Friendbitmap zu bringen, inder Hoffnung, ReadPixelArray8 trägt meine 8bit Pens korrekt in die Bitmap ein, egal wieviele Fabren sie hat (2-256), solange ich keine Pens ausserhalb des zulässigen Bereiches benutze.

Würde das funktionieren ? Dadurch hätte ich zwar nicht die Anzahl der Farben, aber das Pixelformat abstrahiert, und kümmere mich lediglich um die Anzahl der Farben beim Remapping.

Ich möchte noch erwähnen, dass es mir hier nicht darum geht, HAM6, HAM was-weiss-ich und Halfbright zu unterstützen, sondern es geht um High End Amigas die bei einem 40/60er mit 24bit Grafikkarte anfangen, Amithlon, WinUAE, MOS und OS4. Wer auf einem Custom Chip Screen arbeitet, wird mit den angepeilten Applikationen soweiso nichts anfangen können, mangels CPU und GFX power.

--
Thilo Köhler, Author von:
HD-Rec, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, TKUnpacker
Homepage: http://www.hd-rec.de



[ Dieser Beitrag wurde von bubblebobble am 01.09.2006 um 12:15 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

01.09.2006, 12:29 Uhr

Holger
Posts: 8092
Nutzer
@bubblebobble:
Ich verstehe überhaupt nicht, warum Du auf Hi/TrueColor Bildschirmen mit palettebasierten Funktionen herumhantieren willst. Ich weiss, irgendwann am Anfang hast Du betont, dass Dir Fallunterscheidungen zuwider sind, aber merkst Du nicht, wie kompliziert Deine ganzen Ideen sind, so irgendwie von hinten zum Auge, während simple Fallunterscheidungen in klarem, einfachen, überschaubaren code resultieren würden?

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

[ - Antworten - Zitieren - Direktlink - ]

01.09.2006, 12:47 Uhr

whose
Posts: 2156
Nutzer
@Holger:

Ich denke, das macht er deswegen, weil er im Fall "Screen >8Bit" alle Grafikprimitiven selbst implementieren und ganz nebenbei sich auch noch um die Verwaltung der Farbpalette für den Benutzer kümmern müßte.

Ich glaube aber auch, daß das im Endeffekt doch der Weg mit dem "kleinsten" Aufwand wäre, inzwischen liest sich das Ganze wirklich wie "von hinten durch die Brust ins Auge". Ich wollte sowas jedenfalls nicht implementieren, wenn ich nicht zwingend muß ;)

Grüße

--
---

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

[ - Antworten - Zitieren - Direktlink - ]

01.09.2006, 13:19 Uhr

DariusBrewka
Posts: 899
[Benutzer gesperrt]
Zitat:
Original von bubblebobble:

Und ob das mit AfA+akpngDT funktioniert ist auch fraglich, da die PNG Datatypes das Bild meistens schon vergewaltigen wenn ein Alphachannel da ist, und nicht die Roh-Daten herausgeben. Wie auch immer, ich hab das ja schon alles implementiert, so wild ist das nicht.


Das Thema hatten wir doch schon und wie Ich im Thread damals sagte geht das mit dem AKPng datatype wenn man das entsprechende Picture.datatype hat, Ich habe meines von AROS auf 68k Compiliert und dann ging das. Leider ist das AROS datatype nicht vollständig gewesen und hatte mit anderem Probleme, aber inzwischen wurde das Datatype ja überarbeitet und mit einen normalen Startup braucht man dafür AfA garnicht.

Bernd hätte lieber das picturedatatype nicht ins System patchen sollen, wenn es garnicht nötig ist, so machen einige einen Bogen drum.

Ich persönlich habe keine Lust mich um Sachen zu kümmern, die ins System gehören, bzw. wenn dein Programm gut sein wird, dann werden sich die Leute auch ein Alpha-Fähiges Datatype installieren und das Datatype wird sich durchsetzen, wenn jeder Alles selber macht gibt's dafür keinen Anlass.

[ Dieser Beitrag wurde von DariusBrewka am 01.09.2006 um 13:25 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

01.09.2006, 14:20 Uhr

bubblebobble
Posts: 707
Nutzer
Wieso denn von hinten durch die Brust ins Auge?

Ich arbeite ausschliesslich auf ARGB Bitmaps, und wenn sie dargestellt werden sollen, erstelle ich eine Shadow Bitmap im Screenformat für schnelles, hardwarebeschleunigtes Blitten. Das ist doch simple, oder nicht ?

AsteroidsTR funtkioniert so. Und das ist schnell und kompatibel auf allen Systemen.
Zum blossen Anzeigen wird die ARGB Bitmap nicht mehr benötigt, und kann freigegeben werden, sodass man nur noch die Shadow Bitmap hat. Bei Programmen, die die Bilder manipulieren wollen, muss ich die ARGB Bitmap behalten damit ich keine Informationen verliere.
So muss ich eigene Grafikoperationen nur für ARGB implementieren, z.B. Antialiased Lines usw.

Meine einzige Neuerung ist, dass ich meine ARGB Bitmaps als echte OS Bitmaps anlegen will, (statt vorher einfache, selbst-allocierte PixelArrays) damit ich auch OS Zeichenfunktionen darauf benutzen kann. Und hier macht mir das 16Pixel Align einen Strich durch die Rechnung, da guigfx nicht zurecht kommt damit. Guigfx habe ich zum laden und remappen benutzt. Laden habe ich jetzt komplett auf Datatypes umgestellt. PNG lade ich als Ausnahme allerdings selbst, wegen dem Alpha Channel. Remappen muss ich nun auch selbst machen.

@Darius
Ja, mit dem AfA Datatype bekommt man den Alphachannel, aber das RGB Bild ist trotzdem nicht mehr das original, sondern mit dem Alphachannel und der Hintergrundfarbe verrechnet.

@Holger
> Ich verstehe überhaupt nicht, warum Du auf Hi/TrueColor
> Bildschirmen mit palettebasierten Funktionen herumhantieren willst.
Weil AmigaOS (3.x) nun mal Pen basierende Grafikoperationen hat. Mit geht es auch nicht darum, dass sie Pen basierend sind, sondern dass ich eben auf meine Bitmaps malen will, mit welchem Befehl auch immer.
SetRPAttrs() und Penlessmode scheint ja vielversprechend zu sein, geht nur leider nicht richtig ohne friend-bitmap+Screen.
Eigentlich geht es mir hauptsächlich im Text(), da ich das nicht selbst implementieren will, und einfach die uniformität zu normalen OS Bitmaps, damit einem alle Funktionen offen stehen.
Aber so langsam glaube ich doch, ich sollte fast bei meinen PixelArrays bleiben. Die OS Bitmaps bringen zu viele Probleme mit sich.


--
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 - ]

01.09.2006, 14:52 Uhr

Holger
Posts: 8092
Nutzer
Zitat:
Original von whose:
@Holger:
Ich denke, das macht er deswegen, weil er im Fall "Screen >8Bit" alle Grafikprimitiven selbst implementieren und ganz nebenbei sich auch noch um die Verwaltung der Farbpalette für den Benutzer kümmern müßte.

Das erklärt nicht das rumhantieren mit Read/WritePixelArray und manuelle remappen. Die Grafikprimitive funktionieren auch auf 24Bit BitMaps und ne TrueColor off-screen BitMap nimmt auch nicht wesentlich mehr Speicher als ne clut-BitMap + pixelarray.

Wenn man eh schon dabei ist, BitMap, RastPort, eigene Farbtabelle und jetzt offenbar auch pixelarrays anzulegen, kann man genausogut auch noch die hundert bytes, die ein richtiger screen zusätzlich braucht, in Kauf nehmen. Dann hat man BitMap, RastPort und ViewPort mit Farbtabelle zusammen und die Grafikoperationen funktionieren problemlos. Klebt man den Screen hinter den Zielscreen, ist er im Prinzip auch ein off-screen buffer, da man ihn als Benutzer nicht nach vorne holen kann.

(Aber als Programmierer schon, was das Debuggen sehr vereinfachen kann...)

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

[ - Antworten - Zitieren - Direktlink - ]

01.09.2006, 15:03 Uhr

gni
Posts: 1106
Nutzer
Zitat:
bubblebobble:
Und ob das mit AfA+akpngDT funktioniert ist auch fraglich, da die PNG Datatypes das Bild meistens schon vergewaltigen wenn ein Alphachannel da ist, und nicht die Roh-Daten herausgeben.

Warum schreibst Du nicht Deinen eigenen (PNG-)Datatype bei dem Du alles "richtig" machen kannst? :-/

[ - Antworten - Zitieren - Direktlink - ]

01.09.2006, 16:44 Uhr

bubblebobble
Posts: 707
Nutzer
@gni

Weil ich
1. nicht sicher stellen kann, dass ihn auch alle brav installieren.
(vor allem die OS4 user würden sich gegen ein 68k datatype wehren!)

2. Zum Datatype auch noch der remapping code gehört, und der ist ja auch nicht ohne.

3. Nur 32bit pngs (ARGB) über meinen Loader lade, alle anderen png Formate (also ohne Alpahchannel) lade ich via Datatype.

4. Ich auch einen png Saver haben will, und dann ist es nur noch ein kleiner Schritt zu einem Loader.

--
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 - ]

01.09.2006, 17:11 Uhr

bubblebobble
Posts: 707
Nutzer
Ich will keinen Screen initialisieren, weil ich dessen Pixelformat nicht kontrollieren kann.

Ich lasse mich gerne belehren, ich bin kein Wissensverweigerer.

Was denkt ihr denn, was ist die ideale Lösung ?

Mein Problem:

Ich schreibe sowas wie eine Image-Klasse (in AB2).
Ich möchte, dass der Progger damit Bilder laden, manipulieren, anzeigen und speichern kann, ohne sich einen Kopf über Pixelfromate zu machen. Dabei gibt es noch eine ganze Reihe von Blitmodi, z.B. für Spiele, aber auch zur Bildmanipulation, wie additiv, multiplikativ, mit Alpha Kanal, transparent, rotiert, textured etc. (die müssen allerdings nur auf True/Hi color funktionieren)

Also etwa so:

image_load{id,"Work:mypic.png"}
image_blit{id,40,40,rastport}
image_save{id,"Work:mypic.jpg"}

Und jetzt neu, wenn ich den Images einen Rastport verpasse:
rastport = image_get_rastport{id}
Move_ rastport,x1,y1
Draw_ rastport,x2,y2

...damit ich auch die Bilder mit Standard Routinen (oder auch den Blitmodi der eigenen Image Kalsse) bearbeiten kann.

Das Konzept mit der Shadow Bitmap ist erforderlich, weil ich meine Bilder ja nicht trashen will, nur weil ich sie auf einem 8-Farb Screen anzeigen lassen will, und auf der anderen Seite nicht bei jedem Refresh neu remappen will.

Das habe ich ja auch schon alles implementiert.

Schwierig wird es eben, wenn ich einen Rastport auf meine ARGB Bitmap legen will. Denn dann muss es eine OS Bitmap sein und kein Pixelarray.

Bei den Bitmaps muss ich sicher stellen dass:
1. keine Information verloren geht, ich brauche also immer 32bit
2. das Pixelformat ARGB ist, damit ich eigene Funktionen dafür implementieren kann, die das OS eben nicht bietet. (und nie bieten wird).




--
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 - ]

01.09.2006, 18:37 Uhr

Holger
Posts: 8092
Nutzer
Zitat:
Original von bubblebobble:
Ich will keinen Screen initialisieren, weil ich dessen Pixelformat nicht kontrollieren kann.

Eben noch hast Du geschrieben, dass Deine Shadow-BitMap im Screenformat vorliegt, was ja auch logisch ist, wenn Du sie möglichst schnell auf den richtigen Screen blitten willst. Jetzt bekommst Du die Möglichkeit, mit den OS-Zeichenfunktionen drauf rumzumalen, aber jetzt bist Du schon wieder nicht zufrieden.
Zitat:
Was denkt ihr denn, was ist die ideale Lösung ?
Es gibt keine ideale Lösung. Schon gar nicht, wenn man die Problemstellung alle Nase lang umdefiniert.
Zitat:
Schwierig wird es eben, wenn ich einen Rastport auf meine ARGB Bitmap legen will. Denn dann muss es eine OS Bitmap sein und kein Pixelarray.
Tja, bringt Dir halt nix, weil dann ja sowieso keine OS-Funktionen funktionieren, weil keine Palette vorhanden ist...
Wenn man a) sich weigert, Funktionen, die über OS3.0 hinausgehen, zu nutzen, und b) keine workarounds benutzen will, nur weil sie evtl. eine zusätzliche BitMap benötigen, funktioniert's halt nicht.

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

[ - Antworten - Zitieren - Direktlink - ]


-1- 2 3 4 5 6 [ - Beitrag schreiben - ]


amiga-news.de Forum > Programmierung > Bitmaps nur durch 16 teilbare Breite? [ - Suche - Neue Beiträge - Registrieren - Login - ]


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