At 12:53 PM 29/10/2001 -0800, you wrote:
Anyway, the attached patch is displaying the failing picture correctly. What do you think ?
If I apply your patch, then I see that the red and blue are exchanged when I run vnc as: vncserver :1 -geometry 800x600 -depth 16 -pixelformat bgr565
Could you explain a bit more what you are doing ? I would like to try the same but I don't see how to do it. Also, if you use vnc to test, did you consider the possibility that vnc could have a bug somewhere ?
Without the patch everything is fine. I also checked the formula and I see nothing wrong with it (as long as you are on a little endian computer, but you don't have a big endian x86, do you? ;-).
Never heard that Amd is doing that :-)
So the question is why doesn't it work on your system. Can you run The Sims (I assume it's with that the problem happens) with a +bitmap trace? Then look for cases where either the bmp or the dib has "depth=24". Then check the masks to see if they make sense. For example, do they match what you know of your X server. You may also put a trace in Convert_888_to_565_reverse and check that it is invoked at the right time. Do they have a bgr888 dib (unsupported in windows AFAIK, but, except for 1 or 2 shortcuts, supported in Wine)? Maybe it is the DIB masks that are wrong.
That's a bit involved for this evening :-/
Also it would be great if you could run my test application and check whether it displays fine. The line to watch for is the sixth line (rgb888 dib to 565 rgb/bgr bmp and back).
I had (of course) a number of problems with your app. First on my current computer - a Mandrake 8, with Xfree 4, your procedure ran fine until it tried to link the thing and then it reported that WinMain was missing. I changed in your code 'main' to 'WinMain' and all was well.
I tried then to do the same on my other computer (Suse 6.1 with Xfree 3.3 and a hand-compiled glibc 2.1.3). No joy. Configure always failed with libwine.so failing to find symbols like dlclose and the like. I did not figure out what is happening, I just copied the binary from my other box and it worked.
As for the results, what I see is 11 lines of 13 blocks of 4 colors : black, red, green, blue. I guess that when you speak of red and blue exchanged, you mean that in one of these blocks the red and blue lines are exchanged, right ?
What is strange is that on both of my computers the display of your app is the same with or without my patch. No line exchanged that I can see.
As for The Sims, if you can also check the -debugmsg +bitmap output and make sure it's coherent.
I don't have The Sims... I use a little freeware app that is not available from the internet anymore, unfortunately :-/. And again, that's a bit complex for today. I'll try later.
Gerard
Gerard Patel wrote:
At 12:53 PM 29/10/2001 -0800, you wrote:
Anyway, the attached patch is displaying the failing picture correctly. What do you think ?
If I apply your patch, then I see that the red and blue are exchanged when I run vnc as: vncserver :1 -geometry 800x600 -depth 16 -pixelformat bgr565
Could you explain a bit more what you are doing ? I would like to try the same but I don't see how to do it.
I guess you don't know about VNC then. Here's a description of VNC. VNC is a pretty cool open-source application which lets you access a computer remotely, kind of like X but different :-) It is composed of two parts, a server and a client. The command above starts an VNC X server. This X server is not using any graphics card because it is not actually displaying anything. It just uses a chunk of memory to store the 'screen'. Because of that you can use about any pixel representation. In the above I specified that I wanted a 800x600 screen in 16 bits per pixel with the red, green and blue components in BGR order. Once you have this server, you can start the client as 'xvncviewer :1'. This connects to the above VNC server and creates an 800x600 window that shows you what is displayed in that X server. The client can be run on the same computer or on another. Because the client/server protocol involves exchanging bitmap chunks the client is very simple and can run on about any platform. So you can access the above VNC server from an Windows computer if you want. There is also a VNC server for Windows. And this leads to one of the most interesting applications of VNC: remotely controlling a Windows computer. From another Windows computer, from any Unix platform, I believe there's even a client for PalmOS!
Anyway, by playing with the -depth and -pixelformat options you can test Wine as if it were running into all sorts of X servers.
Also, if you use vnc to test, did you consider the possibility that vnc could have a bug somewhere ?
There's always that possibility but the results I get with VNC (based on XFree 3.3.6) are consistent with those I get from the neomagic&permedia drivers of XFree 4.1.0.
[...]
I had (of course) a number of problems with your app. First on my current computer - a Mandrake 8, with Xfree 4, your procedure ran fine until it tried to link the thing and then it reported that WinMain was missing. I changed in your code 'main' to 'WinMain' and all was well.
Sorry about that. By default winemaker assumes that applications are graphical applications. So it created a .spec file with "mode guiexe" and "init WinMain" instead of "mode cuiexe" and "init main".
I tried then to do the same on my other computer (Suse 6.1 with Xfree 3.3 and a hand-compiled glibc 2.1.3). No joy. Configure always failed with libwine.so failing to find symbols like dlclose and the like. I did not figure out what is happening, I just copied the binary from my other box and it worked.
That's strange. It should be investigated...
As for the results, what I see is 11 lines of 13 blocks of 4 colors : black, red, green, blue. I guess that when you speak of red and blue exchanged, you mean that in one of these blocks the red and blue lines are exchanged, right ?
Yes.
What is strange is that on both of my computers the display of your app is the same with or without my patch. No line exchanged that I can see.
This probably means that you have a 16bpp rgb565 screen. Which seems normal. It also means that the Dib is a bgr888 Dib which does not exist in Windows. So something weird is happening. Here are the interesting kind of lines:
trace:bitmap:X11DRV_DIB_SetImageBits Dib: depth=24 r=ff0000 g=ff00 b=ff trace:bitmap:X11DRV_DIB_SetImageBits Bmp: depth=16/16 r=f800 g=7e0 b=1f
This tells us that the Dib is a 24bpp dib and that it is an RGB dib, the only kind of 24bit DIB in Windows. What tells us that it's an RGB DIB is the r,g,b masks: the red color is encoded in the high bits of the 24bit value: 0xff0000. Then you hace the green, 0xff00, and the blue, 0xff, hence the rgb888 shorthand. Similarly the 'Bmp', i.e. an XImage, is a 16bpp rgb image. Here you will notice that the mask for the green color, 0x7e0, uses 6 bits instead of just 5. This gives you the rgb565 denomination. Finally we are in SetImage so we are converting the Dib into a Bmp, i.e. from rgb888 to rgb565 so we will call Convert_888_to_565_asis (since both are rgb). Now I suspect that with your application the Dib masks don't look like the above.
Actually I have a buffer overflow patch to send for the new DIB code. I don't think it's related but then, who knows. I will try to send it tomorrow morning.
As for The Sims, if you can also check the -debugmsg +bitmap output and make sure it's coherent.
I don't have The Sims... I use a little freeware app that is not available from the internet anymore, unfortunately :-/.
Do you think you could send this freeware app to me? Would I be able to run it without too much trouble?
-
François Gouget -
Gerard Patel