DDraw, wined3d (d3d8, d3d9) and OpenGL32 in Mac OSX + stack fudging -- x86 only
Whow I havent posted in a while... Gottta job -- no more college (but I have to finish my Masters Thesis... crap)... Ok back to wine ------- (Mac OSX X86 ONLY) Some of my friends an I have been working on wine after work and have managed to put together some patches OpenGL dynamic loading -- Mac OSX does not need to dlsym every ogl entry point -- it handles that for you... -- so numerous apple specific changes to make that work right GLX FBConfig -- not supported by mac glx -- faked inside of glx with choosevisual (~80,000 calls to choose visual with various pixel formats) -- this can be done better with agl or cgl or ANYTHING but x11 glx Stack fudging -- mac requires 16 byte aligned stack windows does not -- this leads to illegal instructions (aligned wrongly) -- until gcc can handle this I have a temporary solution to realign stacks using inline asm (fragile and dangerous -- but better than crashing) GLX Root Window -- Wine uses the fact that a root window exists in x11 in many places... -- But no one wants to run the x11 root window on their mac (what the b&w checkerz are ugly?) -- So I have some fixes for that too -- basically make a button and use its context for querying quartzdrv -- from darwine -- I got this to compile and load -- but its not very useful -- it makes white boxes winecoreaudio -- from darwine -- I got this to compile and load -- but its not very useful -- it crashes ALOT I think thats all -- WHEW.. ATM -- We have the glx root window fixes and fbconfig fixes in for ddraw and d3d and ogl I have only put the stack fudging asm blocks in specific functions ---------- So what is the next step? Can these changes go into the wine tree (barring the stack fudging) Are people interested in these kinds of fixes? ------ Also what has Oliver Stieber been up to lately? Thanks for all the hard work and effort put into wine -- keep it up - Nick
What sort of changes have you guys made to the direct3d code? Some time ago there was a discussion about moving wined3d over to WGL (opengl32.dll). It sounded that the changes you made are basicly some hacks. It might be better to do a wined3d -> wgl move soon. We could replace all glX calls with WGL calls and link with opengl32.dll. The disadvantage is that all standard opengl calls will travel through opengl32.dll which isn't good performance-wise. One way to solve this is to use GetProcAddress. In some cases we might need platform specific code in wined3d because one of the platforms supports a usefull feature which isn't supported by the others. If this is the case it might be better to move all GLX / WGL / AGL specific code to wined3d_agl.c / wined3d_glx.c / wined3d_wgl.c. This would directly fix the 'linking' issues. Regards, Roderick Colenbrander -- GMX Produkte empfehlen und ganz einfach Geld verdienen! Satte Provisionen f�r GMX Partner: http://www.gmx.net/de/go/partner
On Sat, 29 Apr 2006 14:46:33 -0700, Nick Burns wrote:
OpenGL dynamic loading -- Mac OSX does not need to dlsym every ogl entry point -- it handles that for you...
Hmm, well so do Windows and Linux ;) I think it's done that way because some of the GL functions are introduced in later versions of OpenGL so we need to test for them at runtime.
Stack fudging -- mac requires 16 byte aligned stack windows does not -- this leads to illegal instructions (aligned wrongly)
This is an Intel Mac right?! Intel chips have never required alignment as far as I know, though it can help performance.
GLX Root Window -- Wine uses the fact that a root window exists in x11 in many places... -- But no one wants to run the x11 root window on their mac (what the b&w checkerz are ugly?)
What stops you fixing the Mac X server to, well, not suck? I don't see why you need to hack Wine to fix this. thanks -mike
participants (3)
-
Mike Hearn -
Nick Burns -
Roderick Colenbrander