[nlist-mcc] Re: Recent WPAA implementation for OS3
- From: Thore Böckelmann <tboeckel@xxxxxx>
- To: nlist-mcc@xxxxxxxxxxxxx
- Date: Mon, 25 Feb 2008 22:08:13 +0100
Hi Ilkka!
Am 22.02.2008 schrieb Ilkka Lehtoranta:
> Custom WPAA() is included only in 68k builds. I dont know how it could
> cause compiler errors. Confusion, possibly. Could be perhaps moved to
> extrasrc.
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.
> On AGA you probably mean combining ARGB images and later remapping them to
> CLUT format? Only problem there is that WPAA() requires
> ReadPixelArray()/WritePixelArray()...
Probably. The current implementation (without your WPAA) relies on the fact that
CGX/P96 enable even OS3 to handle and display ARGB images, but only if certain
conditions are met. And these conditions can only be evaluated at run-time, not
at compile-time. Thus your WPAA implementation should be slightly renamed and
only be used with OS3 if cgx/WPAA is not possible (i.e. AGA screens). But the
requirements for a picture.datatype being able to deliver proper alpha channel
data still exists.
>> Without pic.dt V46 all the work is senseless, since all older versions
>> of picture.datatype will deliver a complete opaque alpha channel.
> Hmm... I thought pic.dt on OS3 (with std CGX or P96 installation) returned
> proper alpha channel with right datatypes. I remember Freeciv had PNG
> graphics and it worked well once you had right datatypes installed. But
> maybe they always returned only 0x00 or 0xff (transparency on/off) on
> the alpha component. I havent used 68k system in six years.
No, older picture.datatype could only deliver a mask plane, being a 1bit alpha
channel. ARGB data include an 8bit alpha channel. The mask plane is being
obtained by OM_GETing PDTA_Mask along with PDTA_BitMap. True ARGB image data is
obtained via PDTM_READPIXELARRAY. And this is where picture.datatype <V46 fails
and produces wrong/missing/whatever alpha channel data.
I think it is quite senseless to implement WPAA by a custom function, because
the requirements are far too high. And if all requirements are fullfilled, then
the user also has a graphic board and a suitable combination of CGX and
picture.datatype to use CGX's WPAA function. Additionally I think bringing full
alpha channel support to AGA will dramatically slow down the blitting process
while gaining only very very tiny piece of eye-candy. Some users will scream out
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.
So, all in all from my point of view there is very very little point in bringing
WPAA to OS3 by a custom implementation. Better leave this fancy eye-candy stuff
to the systems which can handle it natively (OS4, MOS, OS3+CGX+picdt V46). But
this is only my opinion.
--
To the poet, to the philosopher, to the saint, all things are friendly and
sacred, all events profitable, all days holy, all men divine.
-- Ralph Waldo Emerson
Thore Böckelmann - Rehmerloh, Germany
tboeckel at gmx dot de
--
_______________________________________________________________________
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:
