Hyperion Entertainment Message Boards

Hi ThomasRapp,

In fact I inspired from an AmigaOS3 sample that showed how to use Datatypes and, as it actually work perfectly this way, I didn't remove these :p
But, as I know they're useless, I will remove them and test if nothing changed

Thank you for your information.

Regards,
AmiDARK

Any news for this construction site?

I ask because its pretty awkward that a developer is forced to resort to the PDTM_READPIXELARRAY method to get the alpha channel from a datatype object that is theoretically supporting alpha channels (but in reality simply overwrites or even discards the alpha channel information, returning 24 bits depth instead of the real 32 bits depth...).

Maybe some people find it pretty easy to use PDTM_READPIXELARRAY because of "hey, I know that I want to load an image that contains RGBA encoded information" (that it is. Easy. If you know in advance what kind of picture it is! But if you dont know, you have to inspect lots of bitmap header information and even then some picture datatypes might fool you with false information...).

Fine, but what if someone wants to load every possible format with code that doesnt make deepest inspections of the format the resulting bitmap may have (thats what datatypes originally were meant for, remember? Dont care about the details, just load and draw). For pictures containing an alpha channel this would mean: simply check for mskHasAlpha and set the appropriate attributes for the layout process, but not care for a lot of other things and differences between e.g. planar or chunky formats.

It is really the time for picture.datatype subclasses that support all the things datatypes offer, alpha channel support is the most important thing for picture.datatype subclasses nowadays!

Or OS developers should finally reveal the reasons for the fact, that it is still impossible to load most picture types containing alpha information the datatype way: let the datatype do the loading/layouting job, and then just blit it!

Sry, I had to do this rant. Im developing some utilities regarding game development, and I found that I still have to do all this inspection work just to find out, if I have to respect alpha channel information that might be discarded by the system provided picture datatypes, if I use the "normal" way of loading using the datatype system. Its a pain in the a**!

whose wrote: It is really the time for picture.datatype subclasses that support all the things datatypes offer, alpha channel support is the most important thing for picture.datatype subclasses nowadays!

+ 1

On a side note: the long-standing bug in the png.datatype (as well as WarpPNG.datatype) that affected 32-bit (RGB + alpha channel) interlaced images has finally been fixed by Oliver, and is hopefully going to be released soon as png.datatype 53.7! The bug produced artifacts on the left of the image.

AmiDARK wrote:Hi ThomasRapp,

In fact I inspired from an AmigaOS3 sample that showed how to use Datatypes and, as it actually work perfectly this way, I didn't remove these :p
But, as I know they're useless, I will remove them and test if nothing changed

Thank you for your information.

Regards,
AmiDARK

On OS3 It works the same.

During NewDTObject the image is examined and loaded into memory by the subclass. This results in PDTA_SourceBitMap which is supplied to the main class. You then call either PDTM_READPIXELARRAY to retrieve chunky pixel data or DTM_PROCLAYOUT. During DTM_PROCLAYOUT the source bitmap is converted to PDTA_DestBitMap. The PDTA_Remap attribute tells how this conversion is done. If PDTA_Remap = FALSE no conversion is done the PDTA_DestBitMap is just a copy of PDTA_SourceBitMap. No other attributes need to be set in this case.

If PDTA_Remap = TRUE, the source bitmap is converted so that its format matches the screen's properties. In this case PDTA_Screen must be set also, otherwise the conversion will fail. If the screen is palette-based, the bitmap is converted to CLUT format and pens are allocated to hold the bitmap's colors. Only then OBP_Precision makes any sense.

PDTM_READPIXELARRAY did the trick. I allocate temporary buffer of size witdh * height * 4. Then I do READPIXELARRAY into it, requesting ARGB format. Then I allocate a bitmap (being screen's bitmap friend) of the same size, depth 32 and blit data to it using BltBitMapTags(). Then I destroy both datatype object and temporary buffer. All later blits are done from the bitmap (using BltBitMapTags() too) and all alpha operations work as expected.

Regarding the bitmap, on MorphOS I allocate it with BMF_DISPLAYABLE. It has an effect of bitmap data being stored in graphics card memory, so blits from it are much faster. Does the flag has the same effect on AmigaOS 4?

Grzegorz Kraszewski wrote:Regarding the bitmap, on MorphOS I allocate it with BMF_DISPLAYABLE. It has an effect of bitmap data being stored in graphics card memory, so blits from it are much faster. Does the flag has the same effect on AmigaOS 4?

Generally, you shouldn't try to outsmart the graphics subsystem with flags if you can avoid it. It will store bitmaps in VRAM and swap them in and out of VRAM as needed to speed up operations. Just allocate your bitmap and make sure to specify the friend bitmap (e.g. destination Screen) correctly so the system can handle everything for you.

The only time I found a real need to specify what memory to use is when I am allocating a memory outside VRAM which I want locked there and never put on the gfx card. I was manipulating BitMaps in RAM at the time using some 3rd party libraries so the CPU was doing all the work and I only wanted the end result to appear in VRAM.

ssolie wrote:

Grzegorz Kraszewski wrote:Regarding the bitmap, on MorphOS I allocate it with BMF_DISPLAYABLE. It has an effect of bitmap data being stored in graphics card memory, so blits from it are much faster. Does the flag has the same effect on AmigaOS 4?

Generally, you shouldn't try to outsmart the graphics subsystem with flags if you can avoid it. It will store bitmaps in VRAM and swap them in and out of VRAM as needed to speed up operations. Just allocate your bitmap and make sure to specify the friend bitmap (e.g. destination Screen) correctly so the system can handle everything for you.

Supplying a friend bitmap or display ID is indeed the only way to force the bitmap to be allocated in VRAM. These items indicate which graphics card the bitmap should be on (in a multi-graphics-card system). However, bitmaps will be paged into VRAM when needed,** so it doesn't matter.

Whether a friend bitmap is supplied or not, the BMF_DISPLAYABLE should still be set for bitmaps that you want to end up in VRAM. Here's the relevant autodoc snippet:

BMF_DISPLAYABLE to specify that this bitmap data should
be allocated in such a manner that it can be displayed.
Displayable data has more severe alignment restrictions
than non-displayable data in some systems.

Having said that, using a friend bitmap or display ID is still a good idea as, that way, the allocation should fail if your bitmap is incompatible with the chosen graphics card (e.g., too big, or an unsupported pixel format).

Hans


** Unless the bitmap is in a format unsupported by the graphics card, declared as user-private, or locked. In those cases it isn't possible to move the bitmap to VRAM.

Hans wrote:Supplying a friend bitmap or display ID is indeed the only way to force the bitmap to be allocated in VRAM.

I pass Screen->RastPort.BitMap as friend to AllocBitMap().

Hans wrote:BMF_DISPLAYABLE to specify that this bitmap data should be allocated in such a manner that it can be displayed.

In fact this particular bitmap is never displayed. It just acts (many times) as a biltting source.

Grzegorz Kraszewski wrote:

Hans wrote:BMF_DISPLAYABLE to specify that this bitmap data should be allocated in such a manner that it can be displayed.

In fact this particular bitmap is never displayed. It just acts (many times) as a biltting source.

It doesn't matter if it is actually ever displayed or not; it's "displayable" because it can be stored in VRAM and, hence, could (in theory) be displayed by the graphics card. A bitmap that isn't "displayable" cannot be stored in VRAM, and so cannot be used in HW accelerated blitter operations either.

By contrast, bitmaps allocated with BMF_USERPRIVATE (which is mutually exclusive to BMF_DISPLAYABLE) are not "displayable" because they cannot be paged in to VRAM. Therefore, such bitmaps can only be used with software blitting.

Hans

@thread

So, what is the best way to load a 32 bit png (with alhpa) and display it on a window?