You are right. Those values are pre-initialized from the Bitmap struct by myself earlier.

If I reset them, none is actually touched.

I then tried

int bpr = GetCyberMapAttr_ (ARGBbitmap_ptr,CYBRMATTR_XMOD);

Returns -1.

Problem with Read/Write PixelArray is the speed loss on Classic HW and the temporarily memory overhead of twice the image size. Loading an image gets significantly slower than just unpacking directly to Bitmap. I have also a lot of Filters that operate on the Bitmap.

EDIT:
Why is it so hard to make LockBitmapTagList() return the needed infomation? You must have the information at some point, e.g. in WritePixelArray.

LBMI_BYTESPERROW (cgfx stuff) cannot be used with GetBitMapAttr() (graphics.library stuff).

base pointer correct: how do you know?

bytes per pixel correct: sure? try to set bpp variable to 0 before LockBitMapTagList() call. Maybe it was just luck that it was correct.

why lockbitmaptaglist() should fail: it simply fails because direct bitmap access is not yet implemented in AROS chunkybm class which is used for things like SPECIALFMT bitmaps. In theory it does not have to be implemented, because apps must not rely on lockbitmaptaglist() to succeed.

have to know bytes per row: it lockbitmaptaglist fails you should allocate some widthxheight memory pixel buffer, fill it up (maybe with PDTM_READPIXELARRAY) and then put it into bitmap with WritePixelArray().

LockBitMapTagList() actually fails. Good catch Georg.

It returns NULL, so I should not rely on the results.


Then I tried

int bpr = GetBitMapAttr(ARGBbitmap_ptr,LBMI_BYTESPERROW);

which return also 8 instead of 256.

Then I snooped the BitMap struct for the BytePerRow entry, and it contains also 8.

I dont know why LockBitMapTagList() should fail, it is a private Bitmap no one knows of but me. Also, the base-pointer and the Bytes-Per-Pixel are filled with the correct values.

I have to know the Bytes-Per-Row, otherwise I cannot work with the Bitmap.

Are you sure the LockBitMapTagList() call is succeeding?

It shouldn't because chunkybm class in AROS does not seem to support it at the moment.

And apps should not rely on LockBitMapTagList() call to succeed.

PS: I know that each pixels has 32 bits. I set 24bit as depth because this is how I get is reported under AmigaOS. IIRC if I use 32 there arise problems on other OS'es.
I changed that for AROS to 32 though, and still get the wrong BPR reproted.

@wanderer:
could you show your call/parameters to AllocBitMap() ?

See here for more info regarding CyberGfx.

I tracked the problem further down. It is NOT the zlib and NOT the Datatypes.

It is:



It reports bpr=8, but the bitmap is 55 pixels wide and should have at least bpr = 4*55 = 220. (under AmigaOS, it is bpr=256)

EDIT: bpp (Bytes per Pixel) is reported as 4, which is correct, and the Base Pointer looks ok too.

The allocation of subsequent buffers is far to small because it is based on the bytes per row reported from this call.
The reason why debugging is so hard for me is that I have no keyboard under AROS.

@all

" It's not the zlib.library that causes AROS68K (tried only this one) to crash. I am responsible for this rumour, since that was my first thought since it is a WarpOS Mixed Binary and my programs crashes almost instantly before they did anything visible.
But it is not. It is this Datatype Method that causes instant crash:

DTM\MethodID = #PDTM_READPIXELARRAY
DTM\pbpa_PixelData = \raw_ptr ; /* The pixel data to transfer to/from */
DTM\pbpa_PixelFormat = #PBPAFMT_ARGB ; /* Format of the pixel data (see "Pixel Formats" below) */
DTM\pbpa_PixelArrayMod = \bpr ; /* Number of bytes per row */
DTM\pbpa_Left = 0 ; /* Left edge of the rectangle to transfer pixels to/from */
DTM\pbpa_Top = 0 ; /* Top edge of the rectangle to transfer pixels to/from */
DTM\pbpa_Width = *bmhdp\bmh_Width ; /* Width of the rectangle to transfer pixels to/from */
DTM\pbpa_Height = *bmhdp\bmh_Height
If DoMethodA (*DTPic,&DTM) Then succ = True

I need this call in Amiblitz images loader, since internally Amiblitz handles all images as 32bit ARGB.

So, once this is fixed, I assume most Amiblitz3 Programs that deal with images will work on AROS68k."

Could someone please look at the problem? A lot of programs do not work on AROS 68k because of that

Quote:

This was originally the plan and has been discussed on dev list but in the end the porter decided to use separate version. You'll need to look in dev archives for the details but there were several reasons if I can remember correctly (you seem to even been posted in the thread).
Salass changed capitalization of z library function names and we prefer to keep names of original library to make porting easier for other code using z library, only included subset of zlib API and more is needed for png library, zlib is linked to the C library making it even more difficult to port libs to different platforms.

Quote:

Actually no, having own implementation is easier to maintain than having to sync with an external version where one needs to maintain changes for AROS.

@fats
this is probably usual reason when just another implementation of a library is getting added? wouldnt it be better to find ways to cooperate with mos and os4 on existing standard, as soon as it is ensured that it is and stays open source and license compatible, instead trying to add another one? the work of salass would be a good candidate i guess? it also would offload the maintenance of the libraries in question from the core aros team.