[nlist-mcc] Re: Recent WPAA implementation for OS3

  • From: Ilkka Lehtoranta <ilkleht@xxxxxxxxxxx>
  • To: nlist-mcc@xxxxxxxxxxxxx
  • Date: Tue, 26 Feb 2008 10:30:57 +0200 (EET)

On Tue, 26 Feb 2008, [ISO-8859-15] Thore Böckelmann wrote:

> Ilkka Lehtoranta schrieb:
> 
> >> It causes confusion, because a library function with exactly the same name
> >> exists. Of course the compiler cannot know if that library function is 
> >> usable or
> >> not and hence the custom implementation must be used.
> > 
> > I dont see problem here. YAMOS has got similar cases (ExamineObject(), 
> > AllocSysObject() etc).
> 
> The situation is different here. ExamineObject() doesn't exist in OS3 at all, 
> but WPAA() DOES exist in OS3's CGX/P96, but not in all revisions.

Which versions of CGX or P96 do implement WPAA()?

> > The point is that there is no WPAA() in CGX/68k. It is only available in 
> > MorphOS and OS4/CGX emulation library. Old WritePixelArray() does not 
> > support alpha channel at all.
> 
> WPA() doesn't support alpha channel, on no system, that's correct. But 
> certain 
> implementations definitely do implement WPAA(). Otherwise it wouldn't work 
> here 
> on OS3.9/P96 running under WinUAE.

Are you sure you just are not running Afa OS on your OS3? I dont see why 
Bernd would have added WPAA() to AfA OS if it already existed in UAE.

Anyway then WPAA() in NBitmap should be renamed since we must choose 
should we use WPAA() in CGX or our custom function.

We should also provide updated inlines for 68k to call WPAA() in CGX.

> > It is not only about eye candy. Without WPAA() it is not possible blit 
> > images in ARGB format to screen and have transparency. Your only option is 
> > using BltBitMap#?() family functions and build mask plane. And of course 
> > it means that you must use bitmaps rather than ARGB arrays complicating 
> > 68k build even more. WPAA() eliminates need for difficult bitmap handling 
> > and joins MorphOS and 68k code to same sections reducing #if..#endif 
> > directives.
> > 
> > On the other hand if NBitmap.mcc can not do transparency in OS3 we could 
> > remove OS3 support altogether. Without transparency support it is useless.
> 
> The problem is that alpha support is possible with OS3, but not in general. 
> That 
> is what I am talking about all the time. You need a suitable picture.datatype 
> to 
> deliver a proper alpha channel AND and graphic system being able to handle 
> this 
> alpha channel.

So, all you need is working picture.datatype. I have to check what pic.dt 
actually works in OS3 but I am sure there are few. ak-datatypes seem to 
support alpha channel on OS3 so there should be working pic.dt around.

> >> for sure, because NBitmap.mcc uses the slow WPAA function on AGA screen, 
> >> while a
> >> fast bitmap blit would have given almost the same image, but many times 
> >> faster.
> >> Displaying images with lots of colors is a real PITA on a plain AGA 
> >> system, and
> >> alpha channel blitting will make things even worse.
> > 
> > I dont think WPA() is much faster to AGA users, if it can be used for 
> > blitting to AGA screens at all.
> > 
> > As far as NBitmap.mcc is concerned I am not even sure can it be used on 
> > AGA at all.
> 
> Why shouldn't it be usable? It uses OS functions only. NBitmap also uses 
> bitmaps 
> for all depths <=8. Exactly this program path is used for every system in 
> case 
> palette based images are used. YAM provides (A)RGB data only if the image 
> really 
> offers these data AND the graphic system is able to handle these, otherwise 
> bitmaps are used. I know of users using YAM on a plain A500 running OS3.0. So 
> this definitely works. I'd NBitma

As I see code does not implement it this way. It takes depth from datatype 
object and it retrieves bitmap if dt object is 8bit and ignores screen 
depth.

YAM probably works right, I doubt NBitmap.mcc.

Funny to hear that someone is running YAM on a plain Amiga 500. MUI alone 
is quite slow on 68000 (I have seen it).


  Ilkka

-- 
_______________________________________________________________________
NList classes mailing list  -   //www.freelists.org/list/nlist-mcc
Listserver help...: mailto:nlist-mcc-request@xxxxxxxxxxxxx?subject=HELP
Unsubscribe: mailto:nlist-mcc-request@xxxxxxxxxxxxx?subject=UNSUBSCRIBE
Bugtracker: http://sourceforge.net/tracker/?group_id=112474&atid=662281

Other related posts: