There is no GPU accelerated physx in Wine. Under the hood physx can either use CPU or GPU. When it uses the GPU it uses cuda. This doesn't work on Wine (physx CAN'T use the linux cuda runtime), so physx just uses the CPU.

The way we render the controls in Wine is not correct which causes the limited theming we have not to work properly. Big parts of the code have to be rewritten and done differently. In the old days buttons and other widgets lived within user32 but the themed versions live inside comctl32. We need to...

Have a look at appdb. Any quake3 based game fails on drivers which offer too many OpenGL extensions. It's a game bug, but there are workarounds.

Since you are on a Mac, make sure you are using a recent XQuartz. I don't know if the default X11 server supports xinput2.

Transitive technology has such technology. Years ago they worked together with Transgaming to run games on non-x86 architectures (they may have used this on PowerPC and consoles). I don't know how well it worked. Later on Transitive also provided this technology to Apple for running PowerPC OSX apps...

Note IPX networking works fine (if set up properly on Linux) through Wine for RA2. There's one big down side you need root permissions since raw sockets are needed. Through posix file capabilities the need for root could be eliminated.

OpenGL in combination with dibsection may be broken. I never really looked at this combination in the last couple of years since it is not that commonly used. The reason is that when you render to a bitmap (provided that's really what the application is doing) then you don't get any hardware acceler...

I'm not sure if this can work properly using loopback. I would try to use cdemu which emulates a proper fake cd drive.

The 'wineserver' process is Wine kernel. It is a single threaded process. Depending on what your application is doing, wineserver could potentially be the bottleneck. Usually it is not a bottleneck though. Perhaps you see something interesting in top.

Every program compiled through winelib becomes appears as a library. Any winelib application obviously depends on Wine and even has to be loaded through Wine (Wine has to do a lot of voodoo including emulating windows memory management, file system, registry......). It is how things are supposed to ...

Your win32 application will see the winelib dll as any other 'win32 dll'. If you have a win32 version of this dll, link against that one and then you can use the winelib version as drop-in replacement. Another way is to dynamically load the library using 'LoadLibrary' and 'GetProcAddress' then you d...

There are two forms of Stereo3D which you see right now. The first method is part of the Nvidia Windows drivers. Essentially the Nvidia drivers contain some 'tricks' to render each frame twice from a different angle. This is not trivial and part of the magic is a database with hacks to apply for eac...

Each wineserver instance is equivalent to a standalone windows instance. (wineserver is Wine's equivalent of the Windows kernel) Both really can't share the same wine desktop. If you really need something like autohotkey, use a linux equivalent of it. There are tons of tools to script keypresses / m...

Oops, the context creation trace line is a 'bug'. In the past we delayed context creation until wglMakeCurrent (has to do with wglShareLists which doesn't exist in GLX; context sharing is done at context creation). These days we just try to recreate the context. I don't quickly see anything suspicio...

Create a log running with '+wgl'. Though I still think the application triggers our child window rendering code. There are two ways we can do that: - if wine was compiled with X Composite, we create an offscreen X11 window and when a new frame is ready we copy the contents over to the application wi...

It depends on how the program is doing its rendering. If the OpenGL area is a true win32 client area then it is fine, but I doubt that's the case for WxWidgets.

Rendering to OpenGL 'child windows' (small OpenGL views like in Google Earth) is a tricky operation for Wine. It has to do between differences between X11 and Windows. Anyway, the way this type of GL rendering works is that we render to an 'offscreen window' and we copy the result back to the main w...

In general you need both an adequate CPU and GPU. Depending on the game engine, either one of the two is more important. Typically either the game is CPU limited or GPU limited. If it is mostly CPU limited, it barely matters what resolution you use (you will notice a roughly constant framerate). Sta...

Yeah, go back to Nvidia and don't go for a top of the line model. The really highend boards are not always the best quality wise. Those boards mostly exists for benchmarking/marketing reasons and easily overheat. Get a decent midend card like the 560Ti.

That heavily depends on what dlls your program needs. Using WINEDEBUG=+loaddll you can see what dlls it needs. You can get rid of most then. Note that even console applications are usually not pure console applications and you would need X11..

A long, long time ago the code worked when we were using Transgaming their old DirectDraw code, but we dropped their DirectDraw code years ago. This old piece of code which can't be entered anymore just waits to be removed....

That's the whole purpose of Winelib. In code compiled using Winelib you can make both Win32 and 'native' OS calls. Any function exported through a so called '.spec' file can be used directly by a Windows application. Look for more information in docs.

What Wine version are you using? It sounds like it is quite an old Wine version since the game you are running uses Direct3D. In the past our Direct3D code was able to use PBuffers, but we got rid of them a while ago. On new Wine versions you should not be able to see any GLX PBuffer errors.

(On Nvidia GPUs we actually provide SM 3.0 when GLSL is disabled through GL_NV_fragment_program*/GL_NV_vertex_program)

As already said by vitamin e.g. Midnight Commander is great. It is very similar to the good old Norton Commander which started it all. No need for FAR on Wine, just good old.