Re: [AD] Android & Blending Bug

[ Thread Index | Date Index | More Archives ]

I don't think there is a way to detect when it's needed but I'm open to suggestions.

One possibility I thought of would be doing something like this on Android:


Perhaps stacking the calls would make things work on the problem devices while still allowing for separate blending on the ones that don't have the bug? Untested though.


On 2014-09-24 1:19 AM, Evert Glebbeek wrote:
On 24 Sep 2014, at 5:26 , Trent Gamblin <trent@xxxxxxxxxx> wrote:
I have come across an issue on Android which is very common but it's a
bug with the OpenGL implementation on some devices. Many Androids don't
support glBlendFuncSeparate, even though they claim to be OpenGL ES 2.0
compliant -- in practice this leads to solid black pixels in place of
alpha in sprites. It can't be ignored as there are a lot of very popular
phones that exhibit the problem. I've heard from at least 5 people who
had the problem out of maybe 20 or 25. So to fix it, I simply use the ES
1.0 path in ogl_draw.c. I don't know about anyone else but I rarely ever
have used separate blending and never in a finished game. Not sure what
to do though -- change Allegro or just leave it. Opinions?
Change Allegro, since the point is for it to be useful to as many people as possible, and we don't want everyone using it to have to do the same work-around.

The question is how. I don't know what platforms OpenGL ES is used one (I guess Android and iOS?), but I'f force to change only on Android. If possible, I'd even prefer detecting whether the work-around is necessary, but I don't know how easy that would be.

Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer

Mail converted by MHonArc 2.6.19+