A possible bug in the p96 GetBitMapAttr function

I think that we found a bug in the P96 (or maybe drivers, or maybe RTG at all, dunno), which happenes in the p96GetBitMapAttr(Width) .

Of course i cant say that is 100% bug, because usually there can be problems with code, but , we also make a simple test-source file/makefile/binary, to easy reproducing of the problem.

The problem is that p96GetBitMapAttr(Width) returns the following values depending on screen/bitmap attributes:

- screen and bitmap 800x600x16-bit --> expected value Width=800 --> returned value Width=832 (+32 pixels)

- screen and bitmap 1440x900x16-bit --> expected value Width=1440 --> returned value Width=1472 (+32 pixels)

- screen 1920x1080x32-bit, bitmap 2000x3000x24-bit --> expected value Width=2000 --> returned value Width=2016 (+16 pixels)

There is test archive with all the stuff. Source are very small, so, if some bugs in code are present (or maybe we not do something what we should to do), it will be easy to detect. But if it still a bug, then its good as well for bugs-database of os4.

Will be cool if any of os4 developers can test it and submit a bug-report if there is indeed a bug. Thanks for.

@kas1e

I believe you should ask the screen if you want the screen dimensions. The bitmap hold the bitmap dimensions which are aligned for hardware, just like in a classic. Although the classic alignment is only 2 bytes and a screen rarely has an odd dimension. Modern hardware can have like a 64 byte alignment requirement for DMA to work properly.

About the depth, I agree. This should be wrong. I also noticed I got 24 for a 32 bit screen.

@Deniil

In my program, Ami-PrintScreen available from OS4 Depot, I need to query the width of the bitmap attached to the current visible screen and I do it via p96GetBitMapAttr(Width). It seems to me that it doesn' t always return the expected value.

Shouldn' t it always return the correct value in pixels, not depending on any alignment down to Picasso96? Possible bug?

Thanks

@Massi

From graphics.library autodoc (GetBitMapAttr() section):

Quote:

@Deniil

.. which is correct. The color depth is usually 24bit on a 32bit screen. Dont mix it with the bits/bytes-per-pixel, which can be querried seperatly by LockBitmapTagList().

@Wanderer

Given a screen then, which is the best way to correctly determine the width of its bitmap (not depending on alignment restrictions)?

@Massi

screen->Width, screen->Height ?

@Wanderer

Quote:

Could you repeat that please, didn't quite sunk it properly over here.

Has depth suddenly nothing to do with the amount of colors anymore? Is depth now defined as the amount of legacy pens Workbench managed to allocate or something..?! Why would it then be called depth (when it's not depth) instead of NumOfPens or something?

@Deniil

No, no, Der_Wanderer just made a typo... he told you, that 24 bits is the real color depth of a standard 32Bit screen (24 bit colour information plus 8 bit alpha channel information, which is not colour information!). So, 24 bit depth is correct for 32 bit bitmaps supporting 8 bit alpha channel.

If you want to know if the chosen screen supports alpha channel, read the format information given by GetBitMapAttr().

Edit: typo, me too...

@Deniil

Quote:
No, you still have 256 (software) pens on high/true color screens.

Since a screen cannot be transparent it's no surprise it has a 24-bit depth. I suppose window bitmaps on a composited screen are 32-bit deep.

@kas1e

Thank you all! It feels like I got my answer, I will try and see if I can fix my program :)