Re: AROS68k: zlib.library (68k/WOS) crashes immediatly [Bug Reports]

Forum Index

Board index » Development » Bug Reports » AROS68k: zlib.library (68k/WOS) crashes immediatly

Browsing this Thread: 1 Anonymous Users

Bottom

Previous Topic

Next Topic Register To Post

« 1 (2) 3 4 5 »

Kalamatee

Re: AROS68k: zlib.library (68k/WOS) crashes immediatly

#40

Home away from home

Quote:

Wanderer wrote:
The only workaround I see would use Read/WritePixelArray everytime I manipulate the Bitmap, requiring twice the amount of memory that is used for the image and having two costly (costly at least if we are talking about Classic HW) memory transferes.

But only on AROS .. because otherwise the lock would succeed and your normal codepath run...

And if there is a sensible way to provide safe locking for bitmaps and it gets implemented, the speed penalty will go away.

Posted on: 2013/5/8 1:38

magorium

Re: AROS68k: zlib.library (68k/WOS) crashes immediatly

#39

Home away from home

Quote:

I agree that messing with BitMaps should be discouraged. On the other hand, the code I have written is not really application level. It is part of the Amiblitz3 runtime that is used by applications and should be as efficient as possible.

Then i would advise to use the fastest possible solution for each given platform.

Quote:

I worked long and thoroughly on the image handling in Amiblitz3.
Having the bitmap explicitly allocated as 24bit PFMT_ARGB seemed to guarantee me the actual pixelformat so I can access it. I also respect the bpp and bpr.
The code works fine on OS3.x, OS4.x and MOS.

I showed how to obtain the correct values.

if indeed a failed lock does return the proper values on those platforms then this seems indeed a bug (or at least different behaviour) in AROS. The SDK is very sneaky about those two values. Especially when all other values are only valid when the call was succesfull.

Quote:

It is up to the AROS team to decide if they want to support LockBitmapTags.

No matter how lucky you might have been, your code should always take a failed lock into consideration as it is simply part of cybergraphics implementation.

Quote:

But keep in mind if it is not supported, the application developers need to implement an "Extrawurst" for AROS, which might happen or not, decreasing the amount of software that runs stable on AROS.

That "Extrawurst" is needed for every code that uses (or tries to use) the lock functionality from cybergraphics.

So, please don't try to pin bad coding habbits as an "Extrawurst" for AROS. Thereby i don't think kitty likes wurst

Quote:

The only workaround I see would use Read/WritePixelArray everytime I manipulate the Bitmap, requiring twice the amount of memory that is used for the image and having two costly (costly at least if we are talking about Classic HW) memory transferes.

I fail to see why that would require twice the amount of memory, unless you are peeking/poking directly into a screen-bitmap.

But since the locking works on all other platforms except AROS, you do not have to worry about that do you ?

Posted on: 2013/5/7 23:36

Wanderer

Re: AROS68k: zlib.library (68k/WOS) crashes immediatly

#38

Quite a regular

I agree that messing with BitMaps should be discouraged. On the other hand, the code I have written is not really application level. It is part of the Amiblitz3 runtime that is used by applications and should be as efficient as possible.

I worked long and thoroughly on the image handling in Amiblitz3.
Having the bitmap explicitly allocated as 24bit PFMT_ARGB seemed to guarantee me the actual pixelformat so I can access it. I also respect the bpp and bpr.
The code works fine on OS3.x, OS4.x and MOS.

It is up to the AROS team to decide if they want to support LockBitmapTags. But keep in mind if it is not supported, the application developers need to implement an "Extrawurst" for AROS, which might happen or not, decreasing the amount of software that runs stable on AROS.

The only workaround I see would use Read/WritePixelArray everytime I manipulate the Bitmap, requiring twice the amount of memory that is used for the image and having two costly (costly at least if we are talking about Classic HW) memory transferes.

Posted on: 2013/5/7 19:17

wawa

Re: AROS68k: zlib.library (68k/WOS) crashes immediatly

#37

Home away from home

@georg:
would perhaps be worth to check back with other aros devs on dev ml. in order not to break anything and ensure if this is in accordance with them, especially staf, deadwood, jason and toni might be interested, im not sure if they are following forum threads.

Posted on: 2013/5/7 17:39

Georg

Re: AROS68k: zlib.library (68k/WOS) crashes immediatly

#36

Home away from home

Following changes to AROS may make lockbitmap work with your bitmap. But note that this kind of bitmaps (created with BMF_SPECIALFMT | SHIFT_PIXFMT(PIXFMT_RGB24)) may be very slow at the moment in AROS when used with BltBitMap()/ClipBlit() or similiar. If you are unlucky you may see the blit as it happens pixel by pixel. WritePixelArray()ing pixel buffers would be faster.

I did not commit this changes. Not tested a lot. And I think aros 68k fails to build at the moment anyway ...


Index: rom/hidds/graphics/chunkybm.c

===================================================================

--- rom/hidds/graphics/chunkybm.c       (revision 47362)

+++ rom/hidds/graphics/chunkybm.c       (working copy)

@@ -929,6 +929,32 @@

 

 /****************************************************************************************/

 

+BOOL CBM__Hidd_BitMap__ObtainDirectAccess(OOP_Class *cl, OOP_Object *o, struct pHidd_BitMap_ObtainDirectAccess *msg)

+{

+    struct Library *OOPBase = CSD(cl)->cs_OOPBase;

+    struct chunkybm_data *data = OOP_INST_DATA(cl, o);

+

+    IPTR width, height;

+    

+    OOP_GetAttr(o, aHidd_BitMap_Width, &width);

+    OOP_GetAttr(o, aHidd_BitMap_Height, &height);

+    

+    *msg->addressReturn = data->buffer;

+    *msg->widthReturn = width;

+    *msg->heightReturn = height;

+    *msg->bankSizeReturn = *msg->memSizeReturn = data->bytesperrow * height;

+        

+    return TRUE;

+}

+

+/****************************************************************************************/

+

+VOID CBM__Hidd_BitMap__ReleaseDirectAccess(OOP_Class *cl, OOP_Object *o, struct pHidd_BitMap_ReleaseDirectAccess *msg)

+{

+}

+

+/****************************************************************************************/

+

 VOID CBM__Root__Get(OOP_Class *cl, OOP_Object *o, struct pRoot_Get *msg)

 {

     struct chunkybm_data *data = OOP_INST_DATA(cl, o);

Index: rom/hidds/graphics/graphics.conf

===================================================================

--- rom/hidds/graphics/graphics.conf    (revision 47362)

+++ rom/hidds/graphics/graphics.conf    (working copy)

@@ -275,6 +275,8 @@

 PutImageLUT

 PutTemplate

 PutPattern

+ObtainDirectAccess

+ReleaseDirectAccess

 ##end methodlist

 ##end class

Posted on: 2013/5/7 17:18

magorium

Re: AROS68k: zlib.library (68k/WOS) crashes immediatly

#35

Home away from home

no worries wawa

But I does feel that posting links has no use, so:
Quote:

Unfortunately many programs didn't follow these guide lines and didn't check for the BMF_STANDARD flag with OS3.0 and above. Cybergrphx version of GetBitMapAttr (bitmap, P96BMA_MEMORY) has to use LockBitMapAddress() with LBMI_BASEADDRESS and don't forget use LBMI_BYTESPERROW either.

So, what compatibility are you speaking about ? The fact that no-one follows the guide-lines ? (honest question)

And for the locking part:
Quote:

Is there some function that returns whether a locking of the bitmap works ? No. The cgx autodocs say that LockbitMap will return 0 if the bitmap could not be locked. It does not say that a bitmap which was successfully locked once, can be successfully locked every time. So a function telling whether bitmaps are lockable or not would not really help.

I would make the code check return value of LockBitMap(). if it is 0 (failure) do the workaround (WritePixelArray(), otherwise do direct bitmap access. Or if this for some reason is not optimal/working, make it configurable whether program shall (try to) use LockBitMap or not.

Otherwise for vice this means that will have to do a 'test' lock and see if it works, if it works the code can use the lock code and otherwise it needs to use the WritePixelArray code.

Even though that may work with current drivers, think it would be better to check the retval each time at every LockBitMap() call.

Read it and weep

(although i conveniently left out the wishes of the original author)

RED: so, back to the issue at hand.

The way wanderer presented his code (i assume tested on classic as well):
did that work ? e.g. does lockbitmaptags() work as expected under classic OS using a cybergraphics bitmap or does it return back the same wrong bpr ?

If the first case then i assume that behaviour should be mimiced ?

Posted on: 2013/5/7 16:30

Edited by magorium on 2013/5/7 17:08:27

wawa

Re: AROS68k: zlib.library (68k/WOS) crashes immediatly

#34

Home away from home

@magorium:
for compatibility reasons. apparently the function is implemented both in aros and original cgx, what differs is the behaviour or lack of proper return as far as i understand it. it may be disencouraged to use this function from application level but since it is available it is impossible to prevent it altogether. someone might write some code that depends on the new behaviour even if illegaly though enforcing the incompatibility to the original. implementing the behaviour as specified even if direct call of function in question is still disencouraged would be a lesser evil, i guess.

sorry for this uninformed rant. id probably better stay away from messing with issues i have no idea of. ;)

Posted on: 2013/5/7 16:21

magorium

Re: AROS68k: zlib.library (68k/WOS) crashes immediatly

#33

Home away from home

@wawa:
let me ask a question back to you: Why implement functionality that someone is not suppose to use ?

There is a reason behind the way it act as it does now -> you are not suppose to mess with the internal bitmap-data as it is up to the driver how it is stored into memory.

So if you do not know it's internal storage/structure then how are you suppose to manipulate it ?

That one simply assumes 24 bit to be 3 bytes per pixel, or 32 bit to be 4 bytes per pixel does not have to be the case. Also the pixelformat says nothing how the bits are actually stored into memory. Again everything you think about that is just that -> thinking. It does not have to reflect reality.

Posted on: 2013/5/7 15:59

wawa

Re: AROS68k: zlib.library (68k/WOS) crashes immediatly

#32

Home away from home

@wanderer:
you miss a keyboard under aros? how so? are you testing on native x86? usb keyboards are not supported i assume, which probably affects also some notebook keyboards. ps2 would sure work. there are aros hosted versions on linux and windows, those could be used instead, or use aros68k under winuae.

@georg: why argue if a function is necessary instead to implement it, if it enchances 3.1 compatibility. i mean extended 3.1 as cgx wasnt a part of it obviously.

Posted on: 2013/5/7 15:49

magorium

Re: AROS68k: zlib.library (68k/WOS) crashes immediatly

#31

Home away from home

Quote:

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

Please read this link.

afaik, first you check if it is a standard bitmap or not, then you use this to get your needed info depending if your bitmap is BMF_STANDARD or not.

Posted on: 2013/5/7 15:32