>As for alphablending, isn't that supported already?
>When you drag'n'drop an icon for expample or you are talking about something different?
The amigaOS 3.x picture datatype does not support alphachannel.When request a 32bit picture from datatype
that support alphachannel the alpha channel byte is always same value
all programs that want use alphachannels must write extra code.powericons too on OS3.x
AFA use same includes as AROS do.Same as in CGX for MOS there are too funcs in
static VOID WritePixelArrayAlpha(ULONG *pixarray,
UWORD srcx,
UWORD srcy,
UWORD srcmod,
struct RastPort * rp,
UWORD destx ,
UWORD desty ,
UWORD width ,
UWORD height ,
ULONG globalalpha )
This func allow a blit when 32bit data is used depend on alpha value of the pixel and let choose a globalalpha
par to make a image in general transparent.
void BltTemplateAlpha_intern(APTR src,
LONG srcx,
LONG srcmod,
struct RastPort *rp,
LONG destx,
LONG desty,
LONG width,
LONG height)
{
this func is used to blit a single color picture(most used in text).But diffrent is that the sourcedata
is not only a bit 0 and 1 mean transparent or not.The mask data must be in byte format,so the transparency can
have 256 steps
Of course progs can do it himself,remember the C64,this machine have no OS and after 1,5 Years this system was
out there were much programs out.
But today developer can compare
windows Linux.And when they see here it is more easy to code andn there is a standard.But on amiga noone
can code for 1 system and use new features and reach all of the splittet and few Amiga Users.
If AFA port to MOS OS4 then all can use it and developer can see that as standard,same as directx 9 is too available for win98
wich was sold with directx5
>I'm very curious how stable there are to the originals,
>as well as how performace speeds and ram requirements compare...
I want AFA be compatible OS because i know that very few are intrestet to use or code amiga.And i dont want
miss a old program if noone code a better.
Make a incompatible OS is waste the rare developer resource and the advantage of Linux win MAC get more greater.
They have compatible OS and more developers.More user than necessary give up Amiga.I know from point
of OS developing it is much more easy say the program is wrong all OS calls work as RKM say than try out wy.
But in RKM stand not much.OS3.x have much undocumentet Features that programs use.
I have done some fixes to the original AROS funcs,hope they come in the sourcetree.I post all in aros list
for example last founds was that on AROS allocmem MEMF_LARGEST dont work (kingcon crash)
AROS obtainsemaphorelook do deadlock when same task always keep a look.On OS3.x this is handle correct
some enhancements to PictureDatatype (MUI toolbar show icons)
When a problem is report that take most time a few minutes to find the problem because AFA is modular.
I need only deactivate new AROS functions and look when the program work to see the AROS function fail
So release new updates with fixes is too in a few days possible
But i cant test all 10 000 or more amiga programs that are out.
So it is important that if somebody find a problem report this.Can be too on this thread.
This is done in the beta stage of AFA 20 Nov-19 dez.Thanks to the User that report.
Now on 19 dez i release the final beta
Until 24 dez i get no Bugproblem or Report.So this is called final.
If AROS add all the changes from AFA then if a program run on AFA it is more realistic
that this program run just with a recompile on AROS.I hope more are motivate to port(or should i better
say compile) their program to AROS.
The speed of AFA is when you bench the functions slower.C cant be so fast as asm.
But in real world progs you dont notice or cant measure that
If so report it.My goal is make AFA in real world app with same features same fast as OS3.x.
if there really a measurable speedloss,the function can optimize or written in ASM
1 example.All know gadtools is fast on OS3.x real amiga and MUI is slower with same look.
MUI use own code that is not in the OS.If most time is used in non OS funcs it help near nothing to speed up OS
same happen when you load a iff image or a jpg image or load a wave or a mp3.
mp3 jpg image is known as very slow a faster OS does not help.same is with picture datatype.The main CPU load is in the jpeg png gif etc. datatype.So AFA use in near future this datatype not from AROS,because the highly optimized asm datatypes out are much faster i am 99% sure
AFA use currently 350 kb RAM when use exec.
If you use kick to fast then this cost you additional 512 kb.But i think with AFA you need that not.
all frequently called OS functions as process structure signal lock semaphores are in fastram from AFA
So all in all you maybe save with AFA mem.
If you use new features of AFA like AA this depend on your system if it is fast enough.
