On Thu, 29 Nov 2001, Christoph Egger wrote:
> > > Christoph Egger <[EMAIL PROTECTED]> wrote: > > > > > > > GGI_DISPLAY="tile:0,0,640,480,(X)" red green blue white > > > > GGI_DISPLAY="tile:0,0,640,480,(Xlib)" black blue green light blue > > > > > > O.K. - that sounds like an alignment mismatch in 32 bit wide 24 bit > > > displays. If the application thinks a pixel looks like RGB-, while > > > the hardware thinks it looks like -BGR, that is exactly what is to > > > be expected. Look > > > > > > Application: red => FF 00 00 ?? (with ?? probably being set to 00) > > > Hardware: FF 00 00 00 => R=00,G=00,B=00 => black > > > > > > App: green: 00 FF 00 00 => R=00,G=00,B=FF => blue > > > App: blue : 00 00 FF 00 => R=00,G=FF,B=00 => green > > > App: white: FF FF FF 00 => R=00,G=FF,B=FF => light cyan > > > > Ahhh! - I see. > > > > So - IMO - Xlib should autodetect this to handle this case right. > > The question is, _how_ Xlib should autodetect the case to handle... > > I wrong above. I have now identified, _where_ the bug is! > It is in the tile-target: > > 1) GGI_DISPLAY="tile:-usedb:0,0,640,480,(Xlib)" color-test & > 2) GGI_DISPLAY="tile:-nodb:0,0,640,480,(Xlib)" color-test & > > (color-test is the test-program I posted some mails ago) > > The wrong color behaviour as Andy described nicely above only comes up when > using the directbuffer (case 1). When using no db (case 2), all colors are > correct. > > Has anyone an idea what (more or less exactly) could be wrong in the > tile-target (db mode)? The maintainer from the Heroes project (http://heroes.sourceforge.net/) gave me another good point, that explains the above RGB- <-> BGR- behaviour: -------------------------------------------------------------------- > The "Xlib reference manual" entry for XCreateWindow says: > > In current implementations of Xlib, if you specify a visual > other than the one used by the parent, you must find (using > `XGetRGBColormaps') or create a colormap matching this visual > and then set the colormap window atribute in the `attributes' > and `valuesmask' arguments. Otherwise, you will gat a > BadMatch error. > > It looks like GGI_X_setmode() (in display/X/mode.inc) does not > do that. That might be the cause of the error you get. -------------------------------------------------------------------- Indeed, I get a BadMatch, when starting the Heroes game on my "exotic runtime environment" (at my FH). CU, Christoph Egger E-Mail: [EMAIL PROTECTED]
