@DanKegel: Sorry for the late respond... > No. The result will still need to be run under Wine. (You could > bundle the app with an isolated version of wine, though, like Picasa did.) Hmmm... but wouldn't that: Code: wineg++ main.cpp -o main create an executable "main" that would simply depend on wine libraries and could be run "normally" (./main)? Or would that executable still needed to be run like this: Code: wine main > Winelib is useful primarily for non-x86 platforms. Another question here - what other platforms does winelib support? I know that some time ago ARM support was added... would winelib compile and run on PowerPC, Alpha, SPARC, others? Just curious. > Not trivially, although with the source, you would be in a pretty > good position to find and avoid the bottlenecks. > > winelib is not the solution, though. You're better off just building > a windows .exe with visual studio, and running it under wine, > except in rather special circumstances. Hmmm please correct me if I am wrong but... if I understand correctly how wine translates D3D to OpenGL then for newer games, most time is wasted by the HLSL to GLSL recompilation process. Hence the idea to use winelib to "translate" shader program during compilation so that even though program would still be using wine, it wouldn't need to do the costly HLSL to GLSL translation. Wouldn't that be possible (even theoretically)? OR Wouldn't it be possible to use some kind of cache for shader programs, so that we would need to translate it once, and then use that -already translated program, instead of re-translating it every call? Telepathically I mean ;]
