glColor4x() works fine. Use bit shifting, no need for floats or divisions, eg for value=0xAARRGGBB:
int alpha = (value >> 16) & 0xFF00; int red = (value >> 8) & 0xFF00; int green = value & 0xFF00; int blue = (value << 8) & 0xFF00; gl.glColor4x(red, green, blue, alpha); That should be faster. Olivier On 01/13/2010 07:19 AM, Ben Gotow wrote: > Hey! +1 - Adding support for a few more functions like the one above > would be great. > > I think this should be a relatively simple fix for you, though. Create > a float array with 256 values and precompute the float value of each > possible byte value. When you call glColor4f, just use the byte to > index into the array and grab the corresponding float value. > > You might run into trouble if the CPU cache is too small to hold the > entire array, since you'd be pulling it out of memory over and over > again - I think it should offer a performance improvement though. > > At any rate - hopefully we'll see this and other functions soon! > > - Ben > > On Jan 12, 9:08 pm, Philip <philip.dese...@gmail.com> wrote: >> Would it be possible in the foresable future to get the glColor4ub >> implemented? I am killing my drawing performances with the bunch of >> division by 255 on the bytes I need to convert to float to use the >> glColor4f. Judging by the amount of efforts to get this stuff running, >> it seems a very easy fix thus my request. >> >> Thanks in advance. >> >> Philip
-- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
