Kinek hosszabb, kinek meddig áll… mi lesz, ha lányok is betérnek ide?  😀

Ha valakinek fent van már a final 2006, akkor az légyszi írja meg, hogy a 8.18.6-os vagy a 8.16.20-as fglrx felmegy-e rá (persze csak az nézze meg, akinek ATi-ja van  🙂  )! Mert most ettõl teszem függõvé, hogy a hõn szeretett UHU 1.2-rõl áttérek-e Mandrivára, és akkor utána benneteket boldogítalak-e a Mandrivás topikokban a kérdéseimmel.  :rolleyes:

Ezt pl. a winehq.org-on írják a d3d7-el kapcsolatban:

„Direct3D 7, version 2 Archive
DirectX
Stefan Dösinger has been spending some time on Wine’s DirectX 7 implementation. You might remember that there’s been some discussion to gradually share the Direct3D libraries being developed for DirectX 9 (see WWN #291 for details.) Stefan’s initial work seems to have progressed:
I am trying again to Implement Direct3D 7 using WineD3D, and I’ve made some progress. The D3D7 Device implementation seems to initialize correctly, with the correct surfaces.
My solution looks like this:

    * DirectDraw is unmodified, and it remains in ddraw.dll.
    * Direct3D7 uses generally the Direct3D9 interface of WineD3D. The only changes made to WineD3D are in WineD3DDeviceImpl_Release and a little change in WineD3DSurface.
    * WineD3D Surfaces can be attached to DDraw Surfaces, and they receive the properties of their parents, including the memory reserved for the surface
    * The D3D7 implementation creates a SwapChain and a RenderTarget from the DirectDrawSurface it’s attached to, as well as a DepthStencil WineD3D surface to make WineD3D happy

I’ve made the following changes to WineD3D so far:

    * Make WineD3D handle dxVersion 7, generally with the same code as with dxVersion 7
    * A new parameter to WineD3DDevice_Create: a pointer, which specifies an existing surface memory. If != NULL is passed, no memory is reserved by WineD3D, and it’s not Released on WineD3DSurface_Release
    * When releasing the WineD3DDevice, don’t release the parents of the RenderTarget, the DepthStencilBuffer, BackBuffer and FrontBuffer, because ddraw.dll needs its surfaces. Instead, release the WineD3DSurfaces only.

The whole thing is far from being useable, if anyone is interested in the code, I can send it, but be warned, it’s quite a mess at the moment. My plan is to get some games running, and then I’ll send small and clean patches for CVS commit and upload a big patch somewhere for prior testing.

Lionel Ulmer wanted to know, How do you handle the ‘special’ case Blits (between surface and texture, between surfaces, …) ?

Stefan hopes they won’t need too many changes:

Well, I must admit that I don’t have a totally detailed plan, but the DDraw surface and the WineD3D surface share the same memory area. So those Blits will be handled by the original DirectDraw surface implementation in any case, and if a WineD3D surface is attached, the DDraw surface implementation updates the WineD3D surface wherever it might be necessary. I hope that I can avoid extra memcpy()s

I don’t know if there might occur any problems if DGA is used, and I can’t test it because DDraw DGA fails on my system for some reason.

From there the discussion delved into a lot of details. Stefan ran into a problem with apps that required multithreaded support for 3D rendering. Wine’s wined3d library is not threadsafe and games requiring that won’t work. However, most games don’t require multithreaded rendering so it’s not an issue. Oliver Stieber gave a quick outline of what would need to be done to correct that problem:

It fairly easy to make things thread safe and support multiple devices per thread, very roughly you have to:

    * Add the OpenGL context to the device structure.
    * Make a per-device critical section.
    * Whenever a call is made enter the critical section
    * Then check that the current active context is the same as the context on the device.
    * If not then make the device context active.

I wanted to finish state management before making things threadsafe and support multiple devices per thread.

Another problem Stefan ran into was finding any docs on D3D7.”

Link: http://www.winehq.org/?issue=294#Direct3D%207,%20version%202

Tehát ezek szerint mégiscsak le tudják programozni, hogy az MS API-ja mûködõképes legyen linuxon, akkor is, ha nem ogl.