> Did you ever figure this one out?
> For what it's worth, the program works for me with Mesa and remote X
> as well (after fixing IWineD3DImpl_FillGLCaps).
No, but I haven't tried for quite a while.
What did you fix in IWineD3DImpl_FillGLCaps?
Stefan
pgpc35RaMmWsw.pgp
Description: PGP signature
On 26/12/05, Stefan Dösinger <[EMAIL PROTECTED]> wrote:
> I don't think it's ATI specific: Try with Mesa Software rendering or any other
> X11 3D driver. With fglrx it works partially: 24 Bit color depth works nice,
> 16 bit fails.
>
> I'll try it with my brothers mach64 card, but I don't expect it
> That program works fine for me with
> OpenGL vendor string: NVIDIA Corporation
> OpenGL renderer string: GeForce4 Ti 4400/AGP/3DNOW!
> OpenGL version string: 1.5.2 NVIDIA 66.29
I don't think it's ATI specific: Try with Mesa Software rendering or any other
X11 3D driver. With fglrx it works part
> I have written a small D3D9 test app which shows this behavior: Compile it
> with "winemaker .", followed by make, and run it. Pressing ESC will cause it
> to quit, pressing any other keys makes IDirect3DDevice9::Clear call on the
> back buffer, with a color value based on the pressed keys. A cli
Hello,
I've spotted a bug in WineD3D's surface locking, and I have no clue how to fix
this. The problem is that unlocking the back buffer causes it to become
completely black, no matter what's written to it's memory or what has been
there before.
I have written a small D3D9 test app which shows