When I try to add a new pixel format for my board, I found a macro
GGL_PIXEL_FORMAT_RGB_888 = 3, // 3x8-bit RGB
I can use this format. Because the LCDC can use this 3x8-bit
framebuffer to BGR666 output.
And also I modified the EGLDisplaySurface.cpp to
GGL_PIXEL_FORMAT_RGB_888.
At that moment, I found red and blue are exchanged. Because of LCDC
BGR666 output.
So I modified load_store.cpp to exchange red and blue.
Will the whole modified code break OpenGL? Or if I want to use
GGL_PIXEL_FORMAT_RGB_888, is there any way to make it to BGR without
any change to load_store.cpp?
Thanks
On 12月8日, 下午3时50分, Mathias Agopian <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I talked about this a little bit in my 2nd answer to this thread. You
> will have to create a new BGR pixel-format and use this one. Adding a
> pixel format to the system is not too hard, but it requires adding a
> constant into multiple files (and make sure they all match).
>
> For your information, a 32-bits BGR format has been added to the
> system after 1.0 was released (it is needed for the GPU to render into
> 32-bits surfaces).
>
> Have a look at pixelflinger's format.cpp, this is where the
> pixelformats are defined, it will ripple from there (the corresponding
> header file has a list of the other files that must be updated).
>
> Eventually, I should define all the useful pixelformat enums somewhere
> so that we don't have collisions when people add new formats.
>
> In theory pixelfinger can handle pretty much any pixel configuration;
> so we could add a mechanism to create formats at runtime, which would
> also avoid the namespace problem.
>
> Mathias
>
>
>
> On Sun, Dec 7, 2008 at 8:39 PM, FlyCry <[EMAIL PROTECTED]> wrote:
>
> > Hi, Mathias. Sorry to reply until now, cause somthing else I have to
> > deal with in my job.
> > I modified the assembly code of load_store.cpp. You mean that it would
> > break GL_RGB? So if LCDC needs a BGR framebuffer, but android gives an
> > RGB. What can I do to work it out? Could android give BGR display?
>
> > On 12月5日, 上午8时44分, David Given <[EMAIL PROTECTED]> wrote:
> >> Mathias Agopian wrote:
>
> >> [...]
>
> >> > I don't understand what "looking at a GL_RGB pixel in a word" means. A
> >> > word has 32 bits, GL_RGB has 24.
>
> >> Well, I thought it was pretty obvious --- you load your 24 bits, in
> >> natural order, into the bottom end of a quad, exactly the same way that
> >> you'd load a 32 bit value or a 16 bit value or an 8 bit value!
>
> >> The only thing that makes it the slightest bit complicated is that
> >> GL_RGB is unaligned so you wouldn't be able to use a simple LDR
> >> instruction, but that's just an implementation issue.
>
> >> --
> >> ┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ─────http://www.cowlark.com─────
> >> │
> >> │ ⍎'⎕',∊N⍴⊂S←'←⎕←(3=T)⋎M⋏2=T←⊃+/(V⌽"⊂M),(V⊝"M),(V,⌽V)⌽"(V,V←1⎺1)⊝"⊂M)'
> >> │ --- Conway's Game Of Life, in one line of APL
>
> >> signature.asc
> >> < 1K查看下载- 隐藏被引用文字 -
>
> - 显示引用的文字 -
--~--~---------~--~----~------------~-------~--~----~
unsubscribe: [EMAIL PROTECTED]
website: http://groups.google.com/group/android-porting
-~----------~----~----~----~------~----~------~--~---
