I'm really looking forward to test this on MorphOS. PDF save is what I want most

Last edited by Yasu on 13-Mar-2016 at 11:40 AM.

_________________
Amiga Forum - Sweden's best Amiga Magazine

My MorphOS Blog

"Free speech includes other peoples right to offend you."

@Desler

While I don't have screen corruptions and 0.95 seems faster I'm still unable to use polish special characters and unable to load any image either.

Last edited by mr2 on 13-Mar-2016 at 12:30 PM.

_________________
Sam440ep-flex 800MHz 1GB RAM R9250 128MB SB Live!

@mr2
If possible, please send me the docx files with polish characters and the images that you can't get CW to load. You can send it to bugs@desler.be - Thanks :)

@Desler

Quote:

It seems to primarily affect people with high end amigas (X1000). I will try to match up with an affected user and do some diagnostics and solve this problem.

You called?

@Desler

The X1000 has DMA graphics, the data length is critical it probably has to be a multiple of 64, testing the window by slowly dragging shows 1 in every 4 windows updates is ok. So it looks like CW updates the window bitmap every resize of 16 pixels but good windows only occur every 64 pixels.

_________________
OS4 Rocks
X1000 beta tester, Sam440 Flex (733)

Visit the Official OS4 Support Site for more help.

It may be that your sole purpose is to serve as a warning to others.

@Severin

Quote:

The X1000 has DMA graphics, the data length is critical it probably has to be a multiple of 64

You don't need to think about that as developer, alignment is handled by AmigaOS4.1 automatically on "BytesPerRow". All the developer has to do is use WritePixelArray and know when to use RAM and VRAM.

@Desler

Quote:

It seems to primarily affect people with high end amigas (X1000). I will try to match up with an affected user and do some diagnostics and solve this problem.

Try to use BMA_ACTUALWIDTH instead of BMA_WIDTH.
Stupidly BMA_WIDTH report larger bitmap, then you have allocated.

Last edited by NutsAboutAmiga on 13-Mar-2016 at 06:04 PM.
Last edited by NutsAboutAmiga on 13-Mar-2016 at 06:04 PM.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

@Desler

Yes I am having the screen corruption also on my X1000. Thanks and look forward to giving it a go!!!! (remember your 1st alpha tester)

-A

@Desler

X1000 / HD6670

OS 4.1.6 = perfect, no GFX corruption

OS 4.1.FE = GFX corruption

_________________
http://apps.amistore.net/zTools

@Desler

I see the screen corruption issues too.

It's quite clear that you are using the wrong size in some width calculations

You have allocated a bitmap of width 'x' and are assuming that you got one of width 'x'
This will almost never happen as bitmaps get rounded up in size to the nearest value suited to the hardwares alignment.

Any calculation that requires the true width of the bitmap ie the "stride" must be calculated with the result of

GetBitMapAttrs(bitmap, BMA_WIDTH);

This width will include any extra alignment the system ads in.

There a chance that the reverse is true and you have a source in ARGB32 or other format and you are using the bitmap width to generate the "stride" not the src width.

Those are the two areas to check in your src to fix this.

The fact that it shows on FE and not update6 is most liely because the alignment chnaged, and by chance your choice of bitmap size matched on the old alignment.

Last edited by broadblues on 13-Mar-2016 at 09:17 PM.

_________________
BroadBlues On Blues BroadBlues On Amiga Walker Broad

@NutsAboutAmiga

Quote:

Try to use BMA_ACTUALWIDTH instead of BMA_WIDTH. Stupidly BMA_WIDTH report larger bitmap, then you have allocated.

No, not at all BMA_WIDTH reports the *actual size* of the bitmap. Nothing stupid going on here at all, not in the OS anyway.

BMA_ACTUALWIDTH is a new tag that reports the originally requested size, most often you knew what that was because you requested it, but occasionally I suppose you may have to work with a bitmap passed to you by someone else.

_________________
BroadBlues On Blues BroadBlues On Amiga Walker Broad

@Severin
Thanks for that observation! I think I now have a better idea of what is happening. I will try to fix the bug and get a few affected users to try it out as soon as possible (looking at you Raziel ;) )

@broadblues

BytesPerRow is only needed when doing direct bitmap access and can only be counted on staying constant while the bitmap is locked with LockBitMapTags().

Also it's best not to assume any relation between BytesPerRow and BMA_WIDTH as BytesPerRow is only a value you add to get to the next row of a bitmap.

@Desler

Quote:

Desler wrote: @mr2 If possible, please send me the docx files with polish characters and the images that you can't get CW to load. You can send it to bugs@desler.be - Thanks :)

Done
Plus I have DSI everytime I click on 'i' (info) in a toolbar...

_________________
Sam440ep-flex 800MHz 1GB RAM R9250 128MB SB Live!

@Desler

Quote:

Desler wrote: @Niolator I will try to build an AROS version once I am happy with AOS4 and MorphOS versions :)

I hope you will be happy with AOS4 and MOS versions soon, because on AROS we really need a newer version, even if not completely perfect. The (very) old one, IIRC, can't save correctly.

@salass00

I agree, the problem is that they are extremely ignorant to fact that they broke something, by redefining BMA_WIDTH, here is the thing if you get x pixels more then you expected, and you copy a bitmap based on that, you might end up few extra trash pixels on right side.
(Unless you used BMA_WIDTH, when you cleared the bitmap.)

Unless you using composition and setting this extra pixels as ALPHA 0, the extra pixel Is going to overlap something when blit the Bitmap on another BitMap.

With Blit, If you cleared the pixel you get black rectangle on target bitmap, if where unable to clear the extra pixel on right side, you get trash pixel on target bitmap.

Instead of BMA_ACTUALWIDTH they should have created a new BMA_ALLIGNEDWIDTH, too late now.

Last edited by NutsAboutAmiga on 14-Mar-2016 at 10:45 PM.
Last edited by NutsAboutAmiga on 14-Mar-2016 at 10:44 PM.
Last edited by NutsAboutAmiga on 14-Mar-2016 at 10:34 PM.
Last edited by NutsAboutAmiga on 14-Mar-2016 at 10:31 PM.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

@NutsAboutAmiga

Quote:

they are extremely ignorant to fact that they broke something, by redefining BMA_WIDTH,

Nobody broke anything. Nobody redfined anything, and nobody (except you ) is ignorant here.

From the 3.5 autodoc.

Quote:

Size values returned by this function may not exactly match the values which were passed to AllocBitMap(), due to alignment restrictions.

From the 3.1 autodoc

Quote:

Size values returned by this function may not exactly match the values which were passed to AllocBitMap(), due to alignment restrictions.

So ever since the function was introduced basically BMA_WIDTH gave the true width of the allocated bitmap, not the requested bitmap.

Before that if you read the values from the bitmap structure direct you would find the same.


If you use the destination size to calculate the stride of the src side you will get errors. (like those seen in this case) and vice verca.

_________________
BroadBlues On Blues BroadBlues On Amiga Walker Broad

@broadblues

Quote:

and nobody (except you ) is ignorant here.

Clearly I'm not the only one run into problems here, and other developers agree with me too. Maybe someone do not tolerate critic.

Quote:

So ever since the function was introduced basically BMA_WIDTH gave the true width of the allocated bitmap, not the requested bitmap.

Well then Excalibur was broken sense 1995, when it was called Workbech'96 and was stuck on floppy drive. You broke a lot more then mplayer.

Last edited by NutsAboutAmiga on 14-Mar-2016 at 10:52 PM.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

@NutsAboutAmiga

BMA_WIDTH has *not* been redefined. It has always returned the bitmap width with any extra padding included.

The new tag BMA_ACTUALWIDTH was introduced in order to not redefine BMA_WIDTH and avoid possibly breaking existing programs making use of this tag.

Last edited by salass00 on 14-Mar-2016 at 11:31 PM.
Last edited by salass00 on 14-Mar-2016 at 11:25 PM.
Last edited by salass00 on 14-Mar-2016 at 11:24 PM.

@NutsAboutAmiga

Quote:

NutsAboutAmiga wrote: Instead of BMA_ACTUALWIDTH they should have created a new BMA_ALLIGNEDWIDTH, too late now.

I really wanted to do that. Unfortunately, Broadblues and Salass00 are correct that BMA_WIDTH has always returned a bitmap's padded width. We tried redefining BMA_WIDTH to mean the requested width, but it broke too much. Hence, we had no choice but to use BMA_ACTUALWIDTH instead.

What changed with OS 4.1 FE is that displayable bitmaps** are immediately padded to meet the alignment restrictions of the graphics card, even if they're initially allocated in RAM. This was important for DMA transfers, which are most efficient when the source and destination bytes-per-row match.

It's unfortunate that a few programs (like Excalibur) relied on bitmaps initially being unpadded, so that BMA_WIDTH matched the requested width (under most cases). Yes, those programs were indeed broken, as BMA_WIDTH has never been the requested width. They just got lucky all these years.

Hans


** BMF_USERPRIVATE bitmaps aren't padded, because they will never be copied to a graphics card.

_________________
http://hdrlab.org.nz/ - Amiga OS 4 projects, programming articles and more. Home of the RadeonHD driver for Amiga OS 4.x project.
https://keasigmadelta.com/ - More of my work.

@Desler

Thanks for all your hardwork on this! Ill test it on my peg2 os 4.1u6 and post results.