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

amiga-news.de Forum > Programmierung > Datatypes ohne Screen? [ - Suche - Neue Beiträge - Registrieren - Login - ]

-1- [ - Beitrag schreiben - ]

20.06.2007, 22:13 Uhr

geit
Posts: 332
[Ex-Mitglied]
Mir ist so, als hätte es dieses Thema schon gegeben, aber ich habe es trotz Suche nicht gefunden.

Wenn ich ein Datatype-Object erzeuge, kann ich einen Screen angeben, zu dem die geladene BitMap dann friendly ist. Was aber, wenn man den Screen noch gar nicht geöffnet hat, oder die Daten gar nicht auf einen Screen sollen?

Muß ich jetzt etwa einen nicht sichtbaren Screen öffnen, damit ich die Bitmap im entsprechenden Pixelformat bekomme, oder gibt es einen Trick, mit dem ich die Friendly BitMap angeben kann?

Finden tue ich jedenfalls nichts.

Geit

[ - Antworten - Zitieren - Direktlink - ]

21.06.2007, 12:45 Uhr

tboeckel
Posts: 124
Nutzer
@geit:

Der Screen gibt meines Wissens nur an, anhand welchen Screens die Farben gemappt werden sollen, falls kein Fenster benutzt wird. Ich kann allerdings momentan nicht sagen, ob PDTM_PROCLAYOUT ohne Screen und ohne Fenster erfolgreich ist. Falls ja, dann sollte PDTA_UseFriendBitMap=TRUE helfen. Aber ohne Bezug (kein Screen, kein Fenster) dürfte das eher schlecht aussehen. Warum müssen es denn unbedingt fried-Bitmaps sein? Per BltBitmapRastport() sollten sich doch beliebige Bitmaps malen lassen.

[ - Antworten - Zitieren - Direktlink - ]

21.06.2007, 12:52 Uhr

tboeckel
Posts: 124
Nutzer
@geit:

Zur Not könnte man sich die Daten auch per PDTM_READPIXELARRAY besorgen. In welchem Format die dann aber jeweils vorliegen (LUT8, RGB, RGBA, etc) weiß ich auch nicht. Kannst ja mal in die Sourcen von TheBar.mcc sehen. Da werden die Bilder auch über die Datatypes geladen und dann mit PDTM_READPIXELARRAY weiter bearbeitet.

[ - Antworten - Zitieren - Direktlink - ]

21.06.2007, 13:32 Uhr

akl
Posts: 265
Nutzer
@geit:

Ich sehe das auch so, dass der Screen-Pointer nur zum Remapping (bei 256 Farben) gedacht ist - da Colormaps nicht an Bitmaps hängen (sondern an Screens) wurde eben der Screen-Pointer genutzt.

Mich würde mal interessieren, woher genau die Friend-Bitmap für PDTA_UseFriendBitmap( V43) kommen soll, wenn nicht vom Screen - funktioniert unterhalb 24 Bit sowieso aber auch nur dann, wenn die Subclass das unterstützt und kein Fallback auf V40-Mode macht.

Ich denke nicht, dass es möglich ist, für den Datatype-Output ein Bitmap-Format zu erzwingen - ob es sinnvoll wäre, zumindest eine grundlegende Konvertierungsoption (LUT->ARGB etc.) vorzusehen, ist eine andere Frage.

[ - Antworten - Zitieren - Direktlink - ]

21.06.2007, 13:32 Uhr

Der_Wanderer
Posts: 1229
Nutzer
Also hier ist der Source Code zu meiner image.include von AB3,
die ein Bild via Datatype lädt, und als ARGB Bitmap ablegt, egal welches Format die Quell Datei hat. :itchy:

Sofern es sich also um True oder Hi Color Pixelformate für die Bitmap (also File ist egal!) handelt, ist das kein Problem. Ein Screen ist dafür nicht notwendig.

Da kannst du dann statt #RECTFMT_ARGB auch was anderes angeben.
Remappen musst du dann allerdings selbst, wenn es auf einen 8bit Screen soll. Dafür habe ich eigene Routinen geschrieben.

code:
Function.l image_LoadViaDT {image.l,filename.s}
DEFTYPE.BitMapHeader *bmhd
DEFTYPE.pdtBlitPixelArray DTM

*DTPic._Object = NewDTObjectA_ (&filename.s,Tags(#PDTA_DestMode, #PMODE_V43,
                 #DTA_SourceType, #DTST_FILE, #DTA_GroupID, #GID_PICTURE,
                 #PDTA_Remap, 0))
If *DTPic
  GetDTAttrsA_ *DTPic,Tags(#PDTA_BitMapHeader,&*bmhd)

  ; image_Create legt eine Bitmap an, deren Data Pointer raw_ptr ist
  If image_Create{image,*bmhdbmh_Width,*bmhdbmh_Height}
    DTMMethodID            = #PDTM_READPIXELARRAY
    DTMpbpa_PixelData      = raw_ptr         ; /* The pixel data to transfer to/from */
    DTMpbpa_PixelFormat    = #RECTFMT_ARGB    ; /* Format of the pixel data (see "Pixel Formats" below) */
    DTMpbpa_PixelArrayMod  = bpr             ; /* Number of bytes per row */
    DTMpbpa_Left           = 0                ; /* Left edge of the rectangle to transfer pixels to/from */
    DTMpbpa_Top            = 0                ; /* Top edge of the rectangle to transfer pixels to/from */
    DTMpbpa_Width          = *bmhdbmh_Width   ; /* Width of the rectangle to transfer pixels to/from */
    DTMpbpa_Height         = *bmhdbmh_Height
    DoMethodA *DTPic,&DTM
    DisposeDTObject_ (*DTPic)
    succ.l = True ; we are done!
  End If
End If
Function Return succ
End Function

--
Thilo Köhler, Author von:
HD-Rec, Sweeper, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ScreenCam, PerlinFX, MapEdit, TK AB3 Includes und viele mehr...
Homepage: http://www.hd-rec.de


[ Dieser Beitrag wurde von Der_Wanderer am 21.06.2007 um 15:52 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

22.06.2007, 03:04 Uhr

geit
Posts: 332
[Ex-Mitglied]
Zitat:
Original von tboeckel:
Aber ohne Bezug (kein Screen, kein Fenster) dürfte das eher schlecht aussehen.


Ja, genau. Das war mein Problem. Ich meine es gibt einen TAG um einen Screen zu definieren, dessen Bitmap genommen wird. Warum gibt es dann keinen TAG bei dem man direkt eine friendly Bitmap angeben kann?

Zitat:
Warum müssen es denn unbedingt fried-Bitmaps sein?

Weil ich optional auch andere Systeme einbinden will, die deutlich schneller sind als DT, z.B. Reggea, das nur ein bestimmtes Pixelformat liefert/unterstützt.

Zitat:
Per BltBitmapRastport() sollten sich doch beliebige Bitmaps malen lassen.

Das ist schon richtig, aber damit das Ergebnis maximal schnell ist, sollte es schon 1:1 sein. Wenn das Kopieren und besonders das Umwandeln der Pixel die Graka macht, ist das ja gut und schön, aber wenn nicht wird es sehr langsam. Ob eine, wenn auch minimale, Beschleunigung bei Graka-Support passiert, entzieht sich aber meiner Kenntniss.

Der Hauptgrund, warum mich das stört ist, dass das Einladen der Daten schon recht lange dauert und der Nutzer auf einen blanken Screen starrt, der nur schon so früh da ist, weil ich die Grafiken nach ihm ausrichte.

Geit

[ - Antworten - Zitieren - Direktlink - ]

22.06.2007, 08:51 Uhr

thomas
Posts: 7717
Nutzer
Zitat:
Das ist schon richtig, aber damit das Ergebnis maximal schnell ist, sollte es schon 1:1 sein. Wenn das Kopieren und besonders das Umwandeln der Pixel die Graka macht, ist das ja gut und schön, aber wenn nicht wird es sehr langsam.

Warum glaubst du, daß bei Datatypes mit Screen die Grafikkarte das Pixelformat umwandelt und wenn du selbst BltBitmap benutzt, nicht ? Die Datatypes können auch nur entweder die Umwandlung per selbst geschriebenem Code machen, also per CPU, oder mit den Funktionen der (cyber)graphics.library, also mit BltBitMap oder WritePixelArray. Und das kannst du auch selbst machen. Lege einfach eine Bitmap mit dem richtigen Pixelformat an und blitte die DT-Bitmap da hinein. Schneller kannst du es nicht kriegen.

Gruß Thomas

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

[ - Antworten - Zitieren - Direktlink - ]

22.06.2007, 10:39 Uhr

geit
Posts: 332
[Ex-Mitglied]
Zitat:
Original von thomas:
Zitat:
Das ist schon richtig, aber damit das Ergebnis maximal schnell ist, sollte es schon 1:1 sein. Wenn das Kopieren und besonders das Umwandeln der Pixel die Graka macht, ist das ja gut und schön, aber wenn nicht wird es sehr langsam.

Warum glaubst du, daß bei Datatypes mit Screen die Grafikkarte das Pixelformat umwandelt und wenn du selbst BltBitmap benutzt, nicht ? Die Datatypes können auch nur entweder die Umwandlung per selbst geschriebenem Code machen, also per CPU, oder mit den Funktionen der (cyber)graphics.library, also mit BltBitMap oder WritePixelArray. Und das kannst du auch selbst machen. Lege einfach eine Bitmap mit dem richtigen Pixelformat an und blitte die DT-Bitmap da hinein. Schneller kannst du es nicht kriegen.


Das hab ich doch gar nicht gesagt.

Mir ist schon klar, wie das DTSystem die umrechnet. Aber wenn ich später Dinge von Hand mache, oder sonstwie ein bestimmtes Pixelformat brauche, dann hab ich den Salat. Ich lade die Daten einmal, was schon recht lange dauert (Amithlon braucht >5 Sekunden) und danach werden die Daten nur noch als Quelle benutzt und nicht einmal, sondern mehrfach in der Sekunde. (u.a. mit Blt#?BitMap() Da sollte schon alles zusammen passen.

Geit


[ - Antworten - Zitieren - Direktlink - ]

22.06.2007, 11:17 Uhr

thomas
Posts: 7717
Nutzer

Ist doch ok. Du schreibst, daß du auch andere Systeme einbinden möchtest, die Bilder laden können. Dann mußt du dir doch ein einheitliches Datenformat für die Bilddaten ausgedacht haben. Das kann z.B. eine Bitmap in einem bestimmten Pixelformat oder ein Pixalarray sein. Und dann mußt du die Laderoutine für Datatypes eben entsprechend einrichten, daß du dieses Datenformat herausbekommst. Da ist es doch vollkommen unerheblich, in welchem Format die datatypes.library das Bild anbietet, du mußt es so oder so konvertieren. Außerdem bietet das Kopieren der Grafikdaten in einen eigenen Datentyp den Vorteil, daß du das Datatypeobject freigeben kannst und damit auch die Datei nicht die ganze Zeit gesperrt ist.

Gruß Thomas

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

[ - Antworten - Zitieren - Direktlink - ]

22.06.2007, 13:42 Uhr

Der_Wanderer
Posts: 1229
Nutzer
@Geit

Also in der image.include von AB3 ist das so gelösst:

Bilder werden grundsätzlich im ARGB Format geladen, manipuliert und gespeichert. Somit ist man komplett unabhängig vom Screen oder den Fähighkeiten der Hardware. (Wer will schon Bilder in 16bit editieren, nur weil er einen 16bit Screen offen hat).

Dazu braucht man, wie du oben siehst, keinen Screen.
Jedes Image "Object" besitzt aber noch eine "Shadow Bitmap".

Wenn ich das erste mal das Image blitten will, wird diese Shadow Bitmap als Friend Bitmap des Ziel-Screens angelegt und die ARGB Bitmap draufkopiert, entweder mit BltBitmapRastPort(), WritePixelArray() oder auch einer eigenen Remapping Routine und anschliessendem WriteChunkyPixels() im Falle von 8bit screens.

Beim 2. Blitten wird dann nur doch die Shadow Bitmap geblittet, die das optimale Format hat, so eine Art Cache also. Wird das Image auf der ARGB Bitmap manipuliert, wird der veränderte Bereich oder die ganze Shadow Bitmap beim nächsten Blit wieder aktualisiert.

So kannst du also deine Bilder vor dem öffnen des Screens laden, was je nach Bildformat oder Datatpye ein paar Sekunden dauern kann.
Dann kannst du den Screen öffnen, und die ARGB Bitmap muss lediglich geremapped werden.
Auf Amithlon sollte ein Full-Screen Bild in kaum spürbarer Zeit geremapped werden, incl. dithering für 16 doer 8bit Bilder.

VOR dem Screen öffnen kannst du die Bitmap nicht erzeugen, weil du ja keine Ahnung hast, wie das Pixelformat oder die Farbpalette sein werden. Dazu muss der Screen schon geöffnet werden.
Wenn du aber keinen blanken Screen zeigen willst, gibt es auch die möglichkeit den Screen versteckt zu öffnen, zu remappen, blitteten und anschliessend erst in den Vordergrund poppen zu lassen.

--
Thilo Köhler, Author von:
HD-Rec, Sweeper, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ScreenCam, PerlinFX, MapEdit, TK AB3 Includes und viele mehr...
Homepage: http://www.hd-rec.de



[ Dieser Beitrag wurde von Der_Wanderer am 22.06.2007 um 17:47 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]


-1- [ - Beitrag schreiben - ]


amiga-news.de Forum > Programmierung > Datatypes ohne Screen? [ - Suche - Neue Beiträge - Registrieren - Login - ]


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