I just commited my mach64 updates. There are a few issues still remaining though.
Issue 1: Scaler/texture source color key. Older chips want the scaler/texture source color key in RGB24 format. I thought I'd just slap on a DFBColor to accompany the current source color key value passed around. That way the impact to other drivers would remain minimal. Issue 2: Destination alpha value. Mach64 chips have a very limited choice on what alpha value they write to the destination. Older chips always write zero :( and newer chips can write 0, 1, As, 1-As, Ad or 1-Ad. Unfortunately none of those is very good since DirectFB assumes that alpha is blended just like the colors. My current idea: For destinations without alpha allow all blending functions the hardware is capable of and just write 1 on newer chips and 0 on older chips (since there is no choice) to the destination alpha (affects RGB32). For destinations with alpha limit the blending functions to ZERO + ZERO on older chips and ZERO + ZERO/ONE/SRCALPHASAT on newer chips. Unfortunately this solution makes drawing to ARGB1555 destinations a bad idea. Re-introducing RGB15 would help here. What do you think? This solution would also need a small change to the fbdev format selection logic because currently it overrides the user's choice of RGB32 with ARGB because atyfb always says that transp.length = 8. There are other things I could do like checking if the source alpha value is 0 or 1 and figuring out what the final result of the blending function would be. That would allow a lot more combinations but it would also mean that we'd have to call CheckState() for color changes :( -- Ville Syrj�l� [EMAIL PROTECTED] http://www.sci.fi/~syrjala/ _______________________________________________ directfb-dev mailing list [email protected] http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
