RE: [PATCH] Fix glReadPixels call from read_from_framebuffer (re-redux)
Thanks for the explanation -- I will email asking why soon -- and perhaps resubmit the other patch I have been looking at http://winehq.org/pipermail/wine-cvs to see what has been applied But source.winehq.org/git shows the diffs much nicer - Nick > From: ste...@codeweavers.com > To: adge...@hotmail.com; wine-devel@winehq.org > Subject: RE: [PATCH] Fix glReadPixels call from read_from_framebuffer > (re-redux) > Date: Wed, 24 Dec 2008 15:48:24 +0100 > >> Thanks for reviewing my patch (it sure makes the SHOGO menu much nicer) >> BTW do you know if I need to resubmit my other SHOGO patch ([PATCH] Fix >> ddraw surface version setting)? > Yes, I recommend to do that. It is likely that it was lost or didn't apply > any longer after the 3 days it waited in moderation. > > You can see on source.winehq.org/git or with 'git log origin' if your patch > was applied. If it wasn't, it is best to send a mail to wine-devel asking > why, or ask Alexandre(nick 'julliard') on #winehackers. Quite often > Alexandre sends a reply if he doesn't like the patch(or someone else does), > but not always. > > Alexandre usually wants a confirmation from someone who knows the area(in > the case of d3d Heri, Roderick or me) if a new contributor sends a patch, > hence my "the patch is ok" mails. > > I don't know if Alexandre will apply patches over the holidays, so if the > patch is silently ignored it is best to resend it in a few days.
RE: [PATCH] Fix glReadPixels call from read_from_framebuffer (re-redux)
Why not create a texture and draw a quad instead of using glDrawPixels (as it is deprecated in gl3)?Reference -- ogl 3 spec -- (http://www.opengl.org/registry/doc/glspec30.20080811.pdf)Under "E.1 Profiles and Deprecated Features of OpenGL 3.0""Pixel drawing - DrawPixels and PixelZoom (section 3.7.4). However, the language describing pixel rectangles in section 3.7 is retained as it is required for TexImage* and ReadPixels. " - Nick> From: adge...@hotmail.com> To: ste...@codeweavers.com; wine-devel@winehq.org> Subject: RE: [PATCH] Fix glReadPixels call from read_from_framebuffer (re-redux)> Date: Tue, 23 Dec 2008 11:11:08 -0800> > > Thanks for reviewing my patch (it sure makes the SHOGO menu much nicer)> BTW do you know if I need to resubmit my other SHOGO patch ([PATCH] Fix ddraw surface version setting)?> > > Concerning negative pixelzoom and drawpixels on R500> Please file a radar on that (and email the mac-opengl mailing list)> > > - Nick> > >> From: ste...@codeweavers.com>> To: wine-devel@winehq.org>> Subject: RE: [PATCH] Fix glReadPixels call from read_from_framebuffer (re-redux)>> Date: Tue, 23 Dec 2008 13:30:40 +0100 This patch looks good. There's one last thing we should check: It seems that this is the only code>> that uses GL_PACK_ROW_LENGTH and friends, so the backup and restore is>> probably not needed. I think for now it is better to add it because I>> suspect the code in surface_download_data most likely depends on the default>> settings without properly controlling them. There's some related driver bug on OSX too(no radar filed yet,>> unfortunately). Using a PBO for glDrawPixels with a negative pixelzoom(wine>> uses -1 for y) breaks at least on my radeon X1600 with MacOS 10.5.5. I>> haven't yet tested it with 10.5.6, but if it is still broken there I have to>> remember to file a bug. It is sort of a follow-up bug to a bug fixed in>> 10.5.5; Before that glPixelZoom and PixelPos were completely ignored with>> PBOs. This bug was on my todo list for a long time by the way. I wanted to fix it,>> got distracted and forgot again :-/
RE: [PATCH] Fix glReadPixels call from read_from_framebuffer (re-redux)
Thanks for reviewing my patch (it sure makes the SHOGO menu much nicer) BTW do you know if I need to resubmit my other SHOGO patch ([PATCH] Fix ddraw surface version setting)? Concerning negative pixelzoom and drawpixels on R500 Please file a radar on that (and email the mac-opengl mailing list) - Nick > From: ste...@codeweavers.com > To: wine-devel@winehq.org > Subject: RE: [PATCH] Fix glReadPixels call from read_from_framebuffer > (re-redux) > Date: Tue, 23 Dec 2008 13:30:40 +0100 > > This patch looks good. > > There's one last thing we should check: It seems that this is the only code > that uses GL_PACK_ROW_LENGTH and friends, so the backup and restore is > probably not needed. I think for now it is better to add it because I > suspect the code in surface_download_data most likely depends on the default > settings without properly controlling them. > > There's some related driver bug on OSX too(no radar filed yet, > unfortunately). Using a PBO for glDrawPixels with a negative pixelzoom(wine > uses -1 for y) breaks at least on my radeon X1600 with MacOS 10.5.5. I > haven't yet tested it with 10.5.6, but if it is still broken there I have to > remember to file a bug. It is sort of a follow-up bug to a bug fixed in > 10.5.5; Before that glPixelZoom and PixelPos were completely ignored with > PBOs. > > This bug was on my todo list for a long time by the way. I wanted to fix it, > got distracted and forgot again :-/
RE: [PATCH] Fix glReadPixels call from read_from_framebuffer (redux)
'You are correct sir' I just disabled PBO on my wine build and ran SHOGO The poor menu system was all garbled... (the same issue that the pbo path had) I cleaned-up my patch and made it apply in general (to both paths) Now SHOGO looks good under both paths Good catch and thanks -- I will re-resubmit my patch - Nick > From: ste...@codeweavers.com > To: wine-devel@winehq.org; wine-patc...@winehq.org > Subject: RE: [PATCH] Fix glReadPixels call from read_from_framebuffer (redux) > Date: Mon, 22 Dec 2008 13:05:36 +0100 > > Hmm... Wouldn't this bug also affect surfaces without a PBO? > > >> -Original Message- >> From: wine-patches-boun...@winehq.org [mailto:wine-patches- >> boun...@winehq.org] On Behalf Of Nick Burns >> Sent: Sunday, December 21, 2008 12:36 PM >> To: wine-patc...@winehq.org >> Subject: [PATCH] Fix glReadPixels call from read_from_framebuffer >> (redux) >> >> >> This is a resubmission of my previous patch I fixed the issues Jeff >> found >> 1 - email address in the patch file/git >> 2 - move declartions to block beginning (no warnings now) >> 3 - hotmail spacing (well i think this is as good as I can make it...) >> >> >> This is my last gfx fix for SHOGO (now its quite legible and playable) >> The readpixels call was putting data into the wrong place in the pbo >> (fixed with pixelstore) And the y-flip code was flipping the wrong data >> as well (set the bottom row to the bottom row and not the height'th >> row) >> >> The code handled fullscreen 2d blits (or blts without any colorkey >> masking) correctly However sub-blits had issues (in the pbo path) >> 1 - readpixels read into the wrong part of the pbo (as a line and >> not a rect) >> 2 - the y-flip code would move around the uninited data (from the >> readpixels) and it read from the wrong place >> 3 - After 1 and 2 the pbo is corrupt and the blt code had no >> chance... >> >> This patch fixes 1 and 2 -- letting the blt code shine This can be seen >> in the SHOGO menu (now not corrupt!) >> >> Changelog >> Fix glReadPixels call from read_from_framebuffer >> Fix the call to readpixels so that 2d blts going thru the pbo path >> end up in the right place and get flipped correctly >> >> - Nick
RE: Adding Mac joystick support -- build problem (resend)
> Resending this due to the terrible hotmail "formatting" > Any tips for how to get legible emails out of hotmail without doubling up the > newlines would be greatly appreciated > Note: I cannot even read the emails I send from hotmail... > --- > > I have a few tips for running built wine on OS X > > > I have made some Apple specific mods to get wine (ogl) working > Most of these are hacks to workaround some issues in xquartz X11 (and they > got radars) > > > 1 - Get/install an updated x11 (2.3.1+ has worked well for me) > http://xquartz.macosforge.org/trac/wiki > 2 - Apply my attached patch (I have others for specific games -- but this is > the base) > 3 - Open X11 and goto your 'patched' wine tree > 4 - (under xterm) Run 'autoconf' to regen yer configure script (my patch mods > configure.ac) > 5 - (under xterm) Run 'make depend && make && sudo make install' > > > Now you should be able to run d3d and ogl windows apps under wine > > > - Nick I forget a important step -- for actually running apps... 6 - run terminal -- run the following (change PATH to match yer wine install path) open -a X11 export DYLD_FALLBACK_LIBRARY_PATH=$HOME/lib:/usr/local/lib:/lib:/usr/lib:/usr/X11R6/lib/ export PATH=$PATH:/Library/Wine/bin winecfg wine my_app --- Also note that I generally run in the emulated virtual desktop mode (so keep that in mind if you have problems) - Nick
RE: Adding Mac joystick support -- build problem (resend)
Resending this due to the terrible hotmail "formatting"
Any tips for how to get legible emails out of hotmail without doubling up the
newlines would be greatly appreciated
Note: I cannot even read the emails I send from hotmail...
---
I have a few tips for running built wine on OS X
I have made some Apple specific mods to get wine (ogl) working
Most of these are hacks to workaround some issues in xquartz X11 (and they got
radars)
1 - Get/install an updated x11 (2.3.1+ has worked well for me)
http://xquartz.macosforge.org/trac/wiki
2 - Apply my attached patch (I have others for specific games -- but this is
the base)
3 - Open X11 and goto your 'patched' wine tree
4 - (under xterm) Run 'autoconf' to regen yer configure script (my patch mods
configure.ac)
5 - (under xterm) Run 'make depend && make && sudo make install'
Now you should be able to run d3d and ogl windows apps under wine
- NickFrom 6cbcec2d4c5f6eb7a3855122eaf0f5c9957c30e0 Mon Sep 17 00:00:00 2001
From: Nick Burns
Date: Sat, 20 Dec 2008 20:08:27 -0800
Subject: Apple X11 GLX hacks
Workaround some issues with Apple X11
Also force vsync on (using CGL)
And cut down the mem-space (so games will play and not run out of VM after a
time)
---
configure.ac |7 ++
dlls/wined3d/directx.c| 13
dlls/winex11.drv/opengl.c | 49 +
libs/wine/mmap.c |8 +++
4 files changed, 77 insertions(+), 0 deletions(-)
diff --git a/configure.ac b/configure.ac
index 4bf1ec3..76f556b 100644
--- a/configure.ac
+++ b/configure.ac
@@ -798,6 +798,13 @@ This probably prevents linking to OpenGL. Try deleting the
file and restarting c
fi],
$X_LIBS -lXext -lX11 -lm $X_EXTRA_LIBS
-dylib_file
/System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGL.dylib:/System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGL.dylib)],
$X_LIBS -lXext -lX11 -lm $X_EXTRA_LIBS)
+
+ dnl If on Mac OSX and using X11 then need -dylib_file
+ if test -f
/System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGL.dylib
+ then
+OPENGL_LIBS="-Xlinker -dylib_file -Xlinker
/System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGL.dylib:/System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGL.dylib
-lGL"
+ fi
+
if test "$ac_cv_header_GL_glu_h" = "yes"
then
WINE_CHECK_SONAME(GLU,gluLookAt,,,[$OPENGL_LIBS $X_LIBS
$X_PRE_LIBS -lXext -lX11 -lm $X_EXTRA_LIBS])
diff --git a/dlls/wined3d/directx.c b/dlls/wined3d/directx.c
index d5fd0a5..62ae645 100644
--- a/dlls/wined3d/directx.c
+++ b/dlls/wined3d/directx.c
@@ -795,6 +795,19 @@ static BOOL IWineD3DImpl_FillGLCaps(WineD3D_GL_Info
*gl_info) {
GL_EXT_FUNCS_GEN;
#undef USE_GL_FUNC
+#if defined(__APPLE__)
+#include
+#define USE_GL_FUNC(type, pfn, ext, replace) { \
+DWORD ver = ver_for_ext(ext); \
+if(gl_info->supported[ext] && !gl_info->pfn) gl_info->pfn = (type)
dlsym(RTLD_DEFAULT, #pfn); \
+else if(ver && ver <= gl_info->gl_version && !gl_info->pfn)
gl_info->pfn = (type) dlsym(RTLD_DEFAULT, #replace); \
+if(gl_info->supported[ext] && !gl_info->pfn) ERR("%s NULL\n",
#pfn); \
+else if(ver && ver <= gl_info->gl_version && !gl_info->pfn)
ERR("%s NULL\n", #replace); \
+}
+GL_EXT_FUNCS_GEN;
+#undef USE_GL_FUNC
+#endif
+
#define USE_GL_FUNC(type, pfn, ext, replace) gl_info->pfn = (type)
pwglGetProcAddress(#pfn);
WGL_EXT_FUNCS_GEN;
#undef USE_GL_FUNC
diff --git a/dlls/winex11.drv/opengl.c b/dlls/winex11.drv/opengl.c
index df5bae0..35b5bbb 100644
--- a/dlls/winex11.drv/opengl.c
+++ b/dlls/winex11.drv/opengl.c
@@ -75,8 +75,12 @@ typedef struct wine_glextension {
} WineGLExtension;
struct WineGLInfo {
+#if defined(__APPLE__)
+const char *pad;
+#else
const char *glVersion;
const char *glExtensions;
+#endif
int glxVersion[2];
@@ -291,6 +295,10 @@ static BOOL X11DRV_WineGL_InitOpenglInfo(void)
wine_tsx11_lock();
+#if defined(__APPLE__)
+FIXME("Do not need to check gl version here...\n");
+vis = 0;
+#else
visual = DefaultVisual(gdi_display, screen);
template.visualid = XVisualIDFromVisual(visual);
vis = XGetVisualInfo(gdi_display, VisualIDMask, &template, &num);
@@ -318,6 +326,7 @@ static BOOL X11DRV_WineGL_InitOpenglInfo(void)
WineGLInfo.glVersion = (const char *) pglGetString(GL_VERSION);
WineGLInfo.glExtensions = strdup((const char *)
pglGetString(GL_EXTENSIONS
RE: [PATCH] Fix glReadPixels call from read_from_framebuffer
Thanks for the git advice (still trying to learn git...) I will move the variable declarations up (I am so used to warnings killing my build that I was complacent) (I will also try and see if I can get hotmail to send email with newline characters -- not sure what it is doing to my formatting -- I choose plain text...) - Nick > Date: Sun, 21 Dec 2008 17:03:55 +1100 > From: jeffzaro...@gmail.com > To: adge...@hotmail.com > Subject: Re: [PATCH] Fix glReadPixels call from read_from_framebuffer > CC: wine-devel@winehq.org > > On Sun, Dec 21, 2008 at 4:40 PM, Nick Burns wrote: >> >> This is my last gfx fix for SHOGOThe readpixels call was putting data into >> the wrong place in the pbo (fixed with pixelstore)And the y-flip code was >> flipping the wrong data as well (set the bottom row to the bottom row and >> not the height'th row) >> The code used to handle fullscreen 2d blits (or blts without any colorkey >> masking)However sub-blits had issues (in the pbo path) 1 - readpixels read >> into the wrong part of the pbo 2 - the y-flip code would move around the >> uninited data (from the readpixels) and it read from the wrong place 3 - >> After 1 and 2 the pbo is corrupt and the blt code later had no chance... >> This patch fixes 1 and 2 -- letting the blt code shineThis can be seen in >> the SHOGO menu (now not corrupt!) >> Changelog Fix glReadPixels call from read_from_framebuffer Fix the call to >> readpixels so that 2d blts going thru the pbo path end up in the right place >> and get flipped correctly >> >> - Nick >> > > Hi > > + GLint rowLen = 0; > + GLint skipPix = 0; > + GLint skipRow = 0; > > You're declaring variables in a place which is not the start of a > block, this isn't legal in ANSI C/C90 as gcc points out: > surface.c: In function 'read_from_framebuffer': > surface.c:786: warning: ISO C90 forbids mixed declarations and code > > Also it looks like your email address is not correct in this patch? > > From: Nick Burns > git repo-config user.email "m...@example.com" > > -Jeff
RE: Adding Mac joystick support -- build problem
TML rendering will be disabled.
> wine: configuration in '/Users/n8gray/.wine' has been updated.
>
> Clearly there's some magic build juju that I don't have, perhaps
> related to opengl. I've read the wiki, but I haven't found anything
> that I haven't already tried. Can anybody provide a hint as to how to
> get this working? BTW, I'm using the latest XQuartz 2.3.2_rc3
> (xorg-server 1.4.2-apple27).
>
> Thanks,
> -n8
>
> --
> Nathan Gray
> http://www.n8gray.org/
>
From 6cbcec2d4c5f6eb7a3855122eaf0f5c9957c30e0 Mon Sep 17 00:00:00 2001
From: Nick Burns
Date: Sat, 20 Dec 2008 20:08:27 -0800
Subject: Apple X11 GLX hacks
Workaround some issues with Apple X11
Also force vsync on (using CGL)
And cut down the mem-space (so games will play and not run out of VM after a
time)
---
configure.ac |7 ++
dlls/wined3d/directx.c| 13
dlls/winex11.drv/opengl.c | 49 +
libs/wine/mmap.c |8 +++
4 files changed, 77 insertions(+), 0 deletions(-)
diff --git a/configure.ac b/configure.ac
index 4bf1ec3..76f556b 100644
--- a/configure.ac
+++ b/configure.ac
@@ -798,6 +798,13 @@ This probably prevents linking to OpenGL. Try deleting the
file and restarting c
fi],
$X_LIBS -lXext -lX11 -lm $X_EXTRA_LIBS
-dylib_file
/System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGL.dylib:/System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGL.dylib)],
$X_LIBS -lXext -lX11 -lm $X_EXTRA_LIBS)
+
+ dnl If on Mac OSX and using X11 then need -dylib_file
+ if test -f
/System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGL.dylib
+ then
+OPENGL_LIBS="-Xlinker -dylib_file -Xlinker
/System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGL.dylib:/System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGL.dylib
-lGL"
+ fi
+
if test "$ac_cv_header_GL_glu_h" = "yes"
then
WINE_CHECK_SONAME(GLU,gluLookAt,,,[$OPENGL_LIBS $X_LIBS
$X_PRE_LIBS -lXext -lX11 -lm $X_EXTRA_LIBS])
diff --git a/dlls/wined3d/directx.c b/dlls/wined3d/directx.c
index d5fd0a5..62ae645 100644
--- a/dlls/wined3d/directx.c
+++ b/dlls/wined3d/directx.c
@@ -795,6 +795,19 @@ static BOOL IWineD3DImpl_FillGLCaps(WineD3D_GL_Info
*gl_info) {
GL_EXT_FUNCS_GEN;
#undef USE_GL_FUNC
+#if defined(__APPLE__)
+#include
+#define USE_GL_FUNC(type, pfn, ext, replace) { \
+DWORD ver = ver_for_ext(ext); \
+if(gl_info->supported[ext] && !gl_info->pfn) gl_info->pfn = (type)
dlsym(RTLD_DEFAULT, #pfn); \
+else if(ver && ver <= gl_info->gl_version && !gl_info->pfn)
gl_info->pfn = (type) dlsym(RTLD_DEFAULT, #replace); \
+if(gl_info->supported[ext] && !gl_info->pfn) ERR("%s NULL\n",
#pfn); \
+else if(ver && ver <= gl_info->gl_version && !gl_info->pfn)
ERR("%s NULL\n", #replace); \
+}
+GL_EXT_FUNCS_GEN;
+#undef USE_GL_FUNC
+#endif
+
#define USE_GL_FUNC(type, pfn, ext, replace) gl_info->pfn = (type)
pwglGetProcAddress(#pfn);
WGL_EXT_FUNCS_GEN;
#undef USE_GL_FUNC
diff --git a/dlls/winex11.drv/opengl.c b/dlls/winex11.drv/opengl.c
index df5bae0..35b5bbb 100644
--- a/dlls/winex11.drv/opengl.c
+++ b/dlls/winex11.drv/opengl.c
@@ -75,8 +75,12 @@ typedef struct wine_glextension {
} WineGLExtension;
struct WineGLInfo {
+#if defined(__APPLE__)
+const char *pad;
+#else
const char *glVersion;
const char *glExtensions;
+#endif
int glxVersion[2];
@@ -291,6 +295,10 @@ static BOOL X11DRV_WineGL_InitOpenglInfo(void)
wine_tsx11_lock();
+#if defined(__APPLE__)
+FIXME("Do not need to check gl version here...\n");
+vis = 0;
+#else
visual = DefaultVisual(gdi_display, screen);
template.visualid = XVisualIDFromVisual(visual);
vis = XGetVisualInfo(gdi_display, VisualIDMask, &template, &num);
@@ -318,6 +326,7 @@ static BOOL X11DRV_WineGL_InitOpenglInfo(void)
WineGLInfo.glVersion = (const char *) pglGetString(GL_VERSION);
WineGLInfo.glExtensions = strdup((const char *)
pglGetString(GL_EXTENSIONS));
+#endif
/* Get the common GLX version supported by GLX client and server (
major/minor) */
pglXQueryVersion(gdi_display, &WineGLInfo.glxVersion[0],
&WineGLInfo.glxVersion[1]);
@@ -333,7 +342,10 @@ static BOOL X11DRV_WineGL_InitOpenglInfo(void)
WineGLInfo.glxExtensions = pglXQueryExtensionsString(gdi_display, screen);
WineGLInfo.glxDirect = pglXIsDirect(gdi_display, ctx);
+#if defined(__APPLE__)
RE: [PATCH] Fix ddraw surface version setting
Thanks for reviewing this patchI have one more for SHOGO (w.r.t. 2d surface blitting) - Nick> From: ste...@codeweavers.com> To: wine-devel@winehq.org> Subject: RE: [PATCH] Fix ddraw surface version setting> Date: Fri, 19 Dec 2008 01:17:13 +0100> > The patch looks ok to me
RE: [PATCH] wined3d_gl.h minor typo fix
Whow I sure did mess that upI had my patch -- then fixed it up and made a new patchAnd for some dumb reason I uploaded the OLD version...SighI will resubmit that patch(Sorry about my git newbie-ness) - Nick> From: ste...@codeweavers.com> To: wine-devel@winehq.org> Subject: RE: [PATCH] wined3d_gl.h minor typo fix> Date: Fri, 19 Dec 2008 01:17:13 +0100> >> - USE_GL_FUNC(PGLFNGLFOGCOORDDVEXTPROC,> glFogCoordvEXT, EXT_FOG_COORD, NULL )\>> + USE_GL_FUNC(PGLFNGLFOGCOORDDVEXTPROC,> glFogCoorddvEXT, EXT_FOG_COORD, NULL )\> I think I fixed that one with a patch in my glFogCoord emulation patchset a> few days ago. Did you forget to update your git tree, or did I miss> something?> > Other than that, the patch breaks the alignment of the 3rd and 4th column> because a 'v' was added to the function name, but no space removed to keep> the alignment.
RE: RFC: Patch better support for DevMode
Anyone have comments in this space?
I am sure that the behavior difference of EnumDisplaySettings{A,W} before
and after window creation is a bug.
I think I will submit this patch (barring any complaints) and try to fix the
behavior difference later.
This is still a solid fix afaict.
Any comments?
- Nick
From: "Nick Burns" <[EMAIL PROTECTED]>
To: wine-devel@winehq.com
Subject: RFC: Patch better support for DevMode Date: Mon, 01 Jan 2007
02:56:29 -0800
After looking at the behavior on xp and wine for EnumDisplaySettingsA and
EnumDisplaySettingsW before and after a window has been created (I wrote a
little program to dump the devmodes), I noticed that the devmode structs
that wine gives back are lacking some fields.
Attached is a patch that fills out the devmode structs out quite a bit more
(similar to how XP does it).
This does not fix the issue that when you do not create a window you get
different behavior if you have an emulated desktop (i would like soem help
with this part).
Also attached is log_dev_pfd.zi_ -- it is a zip file (sorry about this but
the log files are too big)
ogl_fullscreen.cpp: source for the app that I used to test
EnumDisplaySettings{A,W}
wine_log_dev_pfd.txt: wine log from app (using an emulated desktop)
nv34_log_dev_pfd.txt: log from nv34 using xp driver
rv250_log_dev_pfd.txt: log from rv250 using xp driver
I would like some help with the behavior difference before and after window
creation (visible in wine_log_dev_pfd.txt -- the fullscreen modes that are
supported should not change)
And would like any comments on the patch
Also -- I would like to get the correct driver names in there and not just
-- desktop/NoRes
- Nick
<< log_dev_pfd.zi_ >>
<< winePatchDevModeFill.diff >>
Re: dlls/opengl32/wgl.c: minor dealloc fix
Got ya, -- looking at the heapfree impl -- it does the check first (so it is defined in Wine) -- So please ignore this patch then -- However, this seems dangerous if you wanted to take any of that code and run it under windows (but im guessing xp and 2k work this way -- and few people use 95/98/me anymore) Where is a good place for api docs other than the MSDN? (and no source does not count as good api docs) It seems like Microsoft should be notified of incorrect/incomplete api docs -- so they can correct them (but sadly this is a huge thankless task...) - Nick From: Vitaliy Margolen <[EMAIL PROTECTED]> To: Nick Burns <[EMAIL PROTECTED]> CC: wine-devel@winehq.org Subject: Re: dlls/opengl32/wgl.c: minor dealloc fix Date: Mon, 01 Jan 2007 18:00:44 -0700 DO NOT top post bottom posted emails!!! Nick Burns wrote: >> From: Stefan Dösinger <[EMAIL PROTECTED]> >> To: wine-devel@winehq.org >> CC: Nick Burns <[EMAIL PROTECTED]> >> Subject: Re: dlls/opengl32/wgl.c: minor dealloc fix >> Date: Mon, 1 Jan 2007 22:33:49 +0100 >> >> >> Am 01.01.2007 um 11:03 schrieb Nick Burns: >> >>> There can be a problem where the detach is hit before >>> internal_gl_extensions is allocated and it tries to free NULL and >>> dies... >>> >>> This just checks for the allocation before freeing -- very minor >>> >>> - Nick >> HeapFree(GetProcessHeap(), 0, NULL) is supposed to be a nop, so the >> check is not needed. > According to... >http://msdn2.microsoft.com/en-us/library/aa366701.aspx > > lpMem > [in] ...If this pointer is NULL, the behavior is undefined. That's incorrect. 90% of MSDN is not correct or incomplete. The behavior is well known and defined (at least in Wine) - NULL pointers are ignored. So your patch is not correct. Vitaliy.
Re: RFC: OpenAL32.dll thunk -- demacroized
Thanks for the comments -- FIXME -> ERR done dllmain ret TRUE -> FALSE done LGPL thingy added I will resubmit the patch soonish with these changes... (stupid cold might have come back) Relays can give you the params (and ret values) -- for now i have the traces tell you what exts the app is using -- (should it also show params?) And Thanks for the testing - Nick From: Stefan Dösinger <[EMAIL PROTECTED]> To: Nick Burns <[EMAIL PROTECTED]> CC: wine-devel@winehq.com Subject: Re: RFC: OpenAL32.dll thunk -- demacroized Date: Mon, 1 Jan 2007 22:42:42 +0100 Am 01.01.2007 um 12:06 schrieb Nick Burns: Here is my OpenAL32.dll thunk demacroized. Sorry this took so long -- finally got some time with the break. This is basically the same patch as before -- supports the same functionality and all -- but no more cool macros (of doom) (~500 lines -> ~1500 lines) I have added as many extensions as I could find to this thunk. (no idea on where these extensions are available) I would like to fix up the extension handling at some point (basically it needs to be more like OpenGL) I would like any comments on this patch And would hopefully like to get it in wine Some things I noticed The openal.c header: +/* Written by Nick Burns ([EMAIL PROTECTED]) */ +/* while sick */ +/* now demacroized */ I think you should take the usual LGPL header that all the other files use. With regard to the traces, I think the usual convention is to write all the function parameters in the trace. I don't know how well this can be done, and I imagine that it is quite some work and makes autogeneration with a script(like opengl) much harder. If the openal headers are missing you use stubs that just print a fixme. This is fine, but I think the fixme's should be ERRs. The DllMain library in that case should maybe return FALSE in that case, so the app can deal with the lack of openal(or just fail) I will give the new version another try with Jedi Academy :-) Stefan
Re: dlls/opengl32/wgl.c: minor dealloc fix
According to... http://msdn2.microsoft.com/en-us/library/aa366701.aspx lpMem [in] ...If this pointer is NULL, the behavior is undefined. I personally dislike undefined behaviour -- If it is defined to NOP in wine that is sufficent for me. But I think/tought I had a crash there tho... - Nick From: Stefan Dösinger <[EMAIL PROTECTED]> To: wine-devel@winehq.org CC: Nick Burns <[EMAIL PROTECTED]> Subject: Re: dlls/opengl32/wgl.c: minor dealloc fix Date: Mon, 1 Jan 2007 22:33:49 +0100 Am 01.01.2007 um 11:03 schrieb Nick Burns: There can be a problem where the detach is hit before internal_gl_extensions is allocated and it tries to free NULL and dies... This just checks for the allocation before freeing -- very minor - Nick HeapFree(GetProcessHeap(), 0, NULL) is supposed to be a nop, so the check is not needed.
RFC: Patch better support for DevMode
After looking at the behavior on xp and wine for EnumDisplaySettingsA and
EnumDisplaySettingsW before and after a window has been created (I wrote a
little program to dump the devmodes), I noticed that the devmode structs
that wine gives back are lacking some fields.
Attached is a patch that fills out the devmode structs out quite a bit more
(similar to how XP does it).
This does not fix the issue that when you do not create a window you get
different behavior if you have an emulated desktop (i would like soem help
with this part).
Also attached is log_dev_pfd.zi_ -- it is a zip file (sorry about this but
the log files are too big)
ogl_fullscreen.cpp: source for the app that I used to test
EnumDisplaySettings{A,W}
wine_log_dev_pfd.txt: wine log from app (using an emulated desktop)
nv34_log_dev_pfd.txt: log from nv34 using xp driver
rv250_log_dev_pfd.txt: log from rv250 using xp driver
I would like some help with the behavior difference before and after window
creation (visible in wine_log_dev_pfd.txt -- the fullscreen modes that are
supported should not change)
And would like any comments on the patch
Also -- I would like to get the correct driver names in there and not just
-- desktop/NoRes
- Nick
log_dev_pfd.zi_
Description: Binary data
winePatchDevModeFill.diff
Description: Binary data
Re: Wine 32-bit address space
Ok that is understandable -- but if wine takes up the entire 4gb address space -- where are builtin libs supposed to live ((be mapped)/alloc to)? (im assuming that opengl is a builtin lib -- in this context) In my case If I let wine take up my entire address space -- libraries (like opengl) will get angry when it can no longer allocate memory (like for textures, bufer objects, contexts, various random temporary allocations, etc... ) Why not let builtin libs (like opengl) use that 3gb -> 4gb space (since wine does not use it)? But maybe that would cause problems if builtin libs returned addresses in that space? (not sure) - Nick From: Alexandre Julliard <[EMAIL PROTECTED]> To: "Nick Burns" <[EMAIL PROTECTED]> CC: wine-devel@winehq.com Subject: Re: Wine 32-bit address space Date: Mon, 01 Jan 2007 11:29:51 +0100 "Nick Burns" <[EMAIL PROTECTED]> writes: > The range 3GB (0xC000) - 4GB (0x) is considered system > memory and apps should not write here (not sure why you would want to > read from there either). > > But Wine tries to mmap this range (on Mac OSX at least) > > I was wondering why this is? > Should this range just be left as it is? -- is there a reason to mmap > this range? Yes, it's to prevent things like builtin libraries from being mapped there, since it's a range the Window apps don't expect to see. -- Alexandre Julliard [EMAIL PROTECTED]
Wine 32-bit address space
According to http://msdn2.microsoft.com/en-gb/library/aa366912.aspx The range 3GB (0xC000) - 4GB (0x) is considered system memory and apps should not write here (not sure why you would want to read from there either). But Wine tries to mmap this range (on Mac OSX at least) I was wondering why this is? Should this range just be left as it is? -- is there a reason to mmap this range? Any ideas? for reference -- this mmap is spurred from libs/wine/mmap.c:356 (mmap_init) - Nick
Re: Concerning the separate OpenAL32.dll thunk patch and OpenALwinmm driver patch
From: Alexandre Julliard <[EMAIL PROTECTED]> To: "Nick Burns" <[EMAIL PROTECTED]> CC: wine-devel@winehq.org Subject: Re: Concerning the separate OpenAL32.dll thunk patch and OpenALwinmm driver patch Date: Fri, 01 Dec 2006 13:49:52 +0100 "Nick Burns" <[EMAIL PROTECTED]> writes: > Again -- for the sound drivers -- Mac OSX has ONE sound driver ONE > I would like to have a choice. Why? What does it do that you cannot do with the CoreAudio driver? True the coreaudio driver can be made awesome -- but as it stands it has problems with many games on my machine (currently hard for me to test due to fullscreen detection changes in ogl) Problems range from deadlocking -- to crackling sound There are a few games that run flawlessly under coreaudio My openal driver also has crackling sound in some games (but i have not yet seen deadlocking -- its possible it could) Also the coreaudio driver is not testable and wont help linux ppl -- just Mac ppl An openal driver would be multi-platform -- testable under windows/mac/linux, would add a 2nd built-in driver to Mac OSX. > Yes my wineopenal patch is not perfect (based on broken code does not > help) -- I know that -- but thats why i want to get it into wine -- so > other people who know more about audio can add to it and make it > better Judging from past experience, people for whom it doesn't work right will simply go out and implement yet another driver, with yet another set of bugs... True -- it has its own set of bugs -- but I cannot iron them out myself -- I would need help from people to do so -- thats why I would like to give it as an option to you wine people (who can test it on linux) (its possible i could try and start a side project in sf.net or something -- no clue what other options there are) In a perfect world we could make an awesome cross-platform openal driver that does ... everything (winmm/dsound/dsound3d/...) everywhere (Linux/Windows/MacOSX) -- So, thats all the good stuff about it... The bad stuff is that its another driver in the tree another option to confuse people another point of failure ... (there is more badness here probably) -- Alexandre Julliard [EMAIL PROTECTED] - Nick
Re: Concerning the separate OpenAL32.dll thunk patch andOpenALwinmm driver patch
Sorry I should have reiterated more clearly... Yes you can dl jack -- but it has never worked correctly for me...(I could try Jack again -- it has been a while) esd -- but it too did not work so well (very laggy sound) liboss -- but i dont think that the alpha version compiles under osx... (did not really try to hard there i must admit hehe) alsa -- it could be ported -- but .. I dont wish that on anyone I am referring to builtin sound drivers for Mac OSX -- We have CoreAudio and OpenAL builtin (no alsa, no oss, no esd, no jack, ...) And coreaudio cannot be tested by anyone except for Mac people... (There seems to be much fewer mac people here...) An OpenAL driver can be tested by linux people with openal (ok those #s i dont know) So, the openal driver is one that CAN work and be multi platform Coreaudio can be made to be the most awesome as well -- but that does not help linux - Nick From: Pierre d'Herbemont <[EMAIL PROTECTED]> To: Nick Burns <[EMAIL PROTECTED]> CC: wine-devel@winehq.org Subject: Re: Concerning the separate OpenAL32.dll thunk patch andOpenALwinmm driver patch Date: Fri, 1 Dec 2006 17:15:30 +0100 On 1 déc. 06, at 00:54, Nick Burns wrote: Again -- for the sound drivers -- Mac OSX has ONE sound driver ONE I would like to have a choice. In fact there is at least two working sound driver: you can also use the Jack driver on Mac OS X if you've downloaded [1] at compile time which by the way seems to have a working audio input. [1] http://www.jackosx.com/ Pierre.
Re: Concerning the separate OpenAL32.dll thunk patch and OpenALwinmm driver patch
Ok this is some good feedback... (usually i dont get such a massive response from emails...) -- I was under the impression that RFC was the second to last line of defense (so it appears to be the third) I do not use IRC (unless you count the irc client in Tribes) I can demacroize the patch -- it was written that way to make it small and easy to add to (since 99% of the functions are pure passthru -- one extra line to the macro adds it and all that it needs) Personally I think its cleaner -- but it has the problem of being a macro "There not much worse than a macro -- except dare I mention templates (the crowd runs for cover)" Again -- for the sound drivers -- Mac OSX has ONE sound driver ONE I would like to have a choice. Yes my wineopenal patch is not perfect (based on broken code does not help) -- I know that -- but thats why i want to get it into wine -- so other people who know more about audio can add to it and make it better If the audio drivers are going to collapse -- I could wait until then and 'try' add my winmm patch in that realm. - Nick From: Alexandre Julliard <[EMAIL PROTECTED]> To: Detlef Riekenberg <[EMAIL PROTECTED]> CC: Nick Burns <[EMAIL PROTECTED]>, wine-devel Subject: Re: Concerning the separate OpenAL32.dll thunk patch and OpenALwinmm driver patch Date: Thu, 30 Nov 2006 19:58:36 +0100 Detlef Riekenberg <[EMAIL PROTECTED]> writes: > I don't know, if wineaudio.drv this is still the way to go, but we have > sound crackeling and Buffer-underun Bugs, and adding another copy of > the "not very well working" code might be a "no go" for Alexandre. Exactly, we already have 8 sound drivers, and not a single one actually works properly, so I'm pretty reluctant to add yet another copy of the same broken code. The openal dll can certainly go in, but you'll need to clean up the code first, right now it looks like a pretty bad case of macro abuse. -- Alexandre Julliard [EMAIL PROTECTED]
Concerning the separate OpenAL32.dll thunk patch and OpenAL winmm driver patch
The patches have been split in 2 one for the thunk and one for the winmm driver. Have these patches been rejected? (I still dont know how to tell that -- other than checking wine-cvs) - Nick From: Stefan Dösinger <[EMAIL PROTECTED]> To: wine-devel@winehq.org CC: Nick Burns <[EMAIL PROTECTED]>, [EMAIL PROTECTED] Subject: Re: OpenAL32.dll thunk and OpenAL winmm driver Date: Sun, 26 Nov 2006 20:39:51 +0100 Am Sonntag 26 November 2006 00:25 schrieb Nick Burns: > dlls/openal32/openal.c: main thunk file > dlls/openal32/Makefile.in: simple thunk makefile > dlls/openal32/openal32.spec: openal+alut spec file > dlls/winmm/wineopenal/audio.c: main winmm driver file > dlls/winmm/wineopenal/Makefile.in: simple winmm makefile > dlls/winmm/wineopenal/openal.c: simple interface > dlls/winmm/wineopenal/openal.h: simple header for simple interface > dlls/winmm/wineopenal/wineopenal.drv.spec: winmm spec file I think you should send the thunk and winmm driver in 2 seperate patches
Re: RFC: OpenAL Winmm driver and OpenAL32.dll thunk was Re:OpenALand DirectSound
Good point in some cases we can just let get proc address pipe the func ptr directly back to the app.. But.. On Mac OSX -- the stack must be 16 byte aligned (for and lib/sys call) -- this means we need to thunk for the stack on Max OSX -- If Linux or other plats have similar reqs then the thunking is required. Personally I would rather have the layer as it gives us control on how windows talks with the system. - Nick From: Stefan Dösinger <[EMAIL PROTECTED]> To: wine-devel@winehq.org Subject: Re: RFC: OpenAL Winmm driver and OpenAL32.dll thunk was Re:OpenALand DirectSound Date: Wed, 22 Nov 2006 12:38:46 +0100 Hi, > That being said -- the impls for AL_1_0, ALC_1_0, ALUT (not freealut) -- > are as good as they can be. They are straight shots thru to the api > (bouncing > > >from CDECL(win32) -> ???(host???)) Afaik Linux libs are CDECL, if the win32 openal is CDECL too(not WINAPI / STDCALL), can we pass the Linux function pointers directly to the apps? Wasn't there some .so loading in the wine library loader some time ago? << attach4 >>
Re: RFC: OpenAL Winmm driver and OpenAL32.dll thunk was Re: OpenALand DirectSound
They are backwards compat -- and my thunk is backwards compat too.. (it should compile for openal1.0, 1.1, 1.X -- I have only tested Mac OSX 10.4.8 OpenAL 1.1) It is NOT efficent to be backwards compatible -- note my impl of AL_1_1, ALC_1_1, AL_EXTS, ALC_EXTS -- they all check for the existence of their functions ALL the time -- this is braindead and can be fixed with something similar to what we use for ogl -- the big func table -- and only update on context change -- maybe even cache per context function tables... That being said -- the impls for AL_1_0, ALC_1_0, ALUT (not freealut) -- are as good as they can be. They are straight shots thru to the api (bouncing from CDECL(win32) -> ???(host???)) As it is (on this list) it should be correct -- barring oddities between deprecated ALUT functions... - Nick From: Stefan Dösinger <[EMAIL PROTECTED]> To: wine-devel@winehq.org Subject: Re: RFC: OpenAL Winmm driver and OpenAL32.dll thunk was Re: OpenALand DirectSound Date: Wed, 22 Nov 2006 10:25:10 +0100 Am Dienstag 21 November 2006 12:03 schrieb Nick Burns: > Attached is my diff/patch for both an openal winmm driver and an > openal32.dll thunk Just a question: Are the different openal versions backward compatible, or do we have to ship a openal thunk for each openal version used by the games? << attach4 >>
Re: RFC: OpenAL Winmm driver and OpenAL32.dll thunk was Re: OpenALand DirectSound
Good luck And may the Sound be with you... - Nick From: Stefan Dösinger <[EMAIL PROTECTED]> To: wine-devel@winehq.org Subject: Re: RFC: OpenAL Winmm driver and OpenAL32.dll thunk was Re: OpenALand DirectSound Date: Wed, 22 Nov 2006 10:08:51 +0100 Am Dienstag 21 November 2006 12:03 schrieb Nick Burns: > Attached is my diff/patch for both an openal winmm driver and an > openal32.dll thunk >I would like to get these into wine -- please comment and stuff... Hey great, I will test it with Jedi Knight: Jedi Academy, which uses openal afaik :-) << attach4 >>
Re: Mem usage in Mac OSX
All the following have this VM ~=4GB on startup -- its not a leaking problem... (afaict) OGL/D3D -- WinRAR, GTAVC, Tribes2, (FlatOutDemo -- even thou it dies on startup now -- still gets to ~4GB), SHOGO NON-GL -- cmd (not even using X11), winecfg, StreamDown, MS VC++ 6, MS+Connentix VPC (even thou it uses a driver and will not start correctly), Shogo (start screen) --- It just plain takes too much mem -- then dies due to the OS saying no more (I will have to test top at some point...) Does Linux have the same mem problem? -- does top show like 4GB of VSIZE on app start? - Nick From: Stefan Dösinger <[EMAIL PROTECTED]> To: wine-devel@winehq.org Subject: Re: Mem usage in Mac OSX Date: Mon, 2 Oct 2006 12:43:30 +0200 Am Sonntag 01 Oktober 2006 13:30 schrieb Nick Burns: > Im seeing some very odd behaviour in Mac OSX using wine -- and wondered if > anyone could enlighten me > > When I run any application -- I see it start with ~4GB of VM then > depending on the app -- it goes upwards of 5.7GB in VM usage (>4GB?) in > Activity Monitor (usually because of texture loading or other context > loading -- so this is seen in games where you start moving around a map and > it starts loading textures into OGL/D3D(->OGL)) > Usually when it gets this high -- bad things happen -- basically mallocs > start to fail, and the app crashes. I can confirm the crashes and the vm oddness, but I haven't tracked them down as much as you did. I have seen Half-Life 2 crashing with shaders enabled(dxlevel 80 and 70), as well as Half-Life 1 with the OpenGL renderer. HL1 takes some time, approximately 1 hour. Even the simplest D3D apps seem to use a vm size of > 4GB, even the small D3D SDK demos. The sdk examples seem to run stable and as fine as on Linux. (http://stud4.tuwien.ac.at/~e0526822/dx8demos-mac.png for a bunch of screenshots. That was CrossOver Mac actually, but shouldn't make any difference) My first suspicion was a memory leak in the OpenGL libraries, but I haven't done any further investigation to back that up. All the apps that crash on MacOS seem to run fine on Linux. My brother played Half-Life 2 for 6 hours in one go without issues on my Linux machine. << attach4 >>
Tribes2 OpenGL (wgl)
Whow 3 posts in a row... I am deving -- finally (ya in the AM on a sunday) -- too much real job work on the weekdays So, I have yet another problem... This time it is with WGL/OGL I know it is transition atm... But... I dont know why Tribes2 is so very mad at me Fullscreen tribes2 (in a virtual desktop) used to work before -- it would give me many different fullscreen modes. 640x480 -> 1680x1050 or so. Now... for some reason -- I can only use Tribes2 in windowed mode (in a virtual desktop) and if I choose fullscreen -- i see no possible choices (It sees no resolutions or bit depths for opengl fullscreen). -- Also now all objects are drawn with the wrong culling AFAICT. Tribes2 worked perfectly before -- Jul21st for example. On a side note -- Tribes2 d3d has never worked for me... (is this different on Linux?) Any ideas on either fullscreen ogl OR d3d? - Nick
Mem usage in Mac OSX
Im seeing some very odd behaviour in Mac OSX using wine -- and wondered if
anyone could enlighten me
When I run any application -- I see it start with ~4GB of VM then depending
on the app -- it goes upwards of 5.7GB in VM usage (>4GB?) in Activity
Monitor (usually because of texture loading or other context loading -- so
this is seen in games where you start moving around a map and it starts
loading textures into OGL/D3D(->OGL))
Usually when it gets this high -- bad things happen -- basically mallocs
start to fail, and the app crashes.
I personally dont like the app to crash -- i ha just started playing. So,
lets say in GTAVC -- thats me in a heli going from Downtown -> New Haiti ==
crash. Thats only a few blocks worth of carnage.
So, I tested a coule theories --
1 - Was it bad OGL calls? **No**, the glTexImage calls looked decent -- some
even very small (128x128 compressed)
2 - Was it too many mallocs/calloc/reallocs? **No**, none of these were in
the GB range...
3 - Finally I found out some very large mmaps/vm_allocates (2x256MB 2x512MB)
taking a significant portion of the VM space away from any system libs.
I tested this out a bit by printing the mmaps/vm_allocates that I was
getting (found the huge 256/512 MB ones)
So, in mmap.c:175 -- try_mmap_fixed
I put in
'
if(len>0x1000)
{
printf("len very big -- 0x%08X\n",len);
len=0x1000;
}
'
to cap the mmaps that i was seeing
Yes yes, I realize thats a HORRIBLE thing to do -- but its for the sake of
testing and science!
This 'cured' my problems in GTAVC -- I no longer crashed (But i would have
given enough allocations... or time). My VM usage droped from an initial
~4gb -> ~3gb as I expected
I was unable to track down these specific huge allocations...
And would like some advice on this situation -- from the sages of Wine...
I would like to fix this the correct way
I have no idea what happen on Linux in these cases
- Nick
RFC: Update Mac OSX stack patch
I recently found genpatch. Wow, wowey wow wow. Very sleek Used this line to gen the attached patch ./tools/genpatch -v -n winePatchMacOSXStackUpdate -c "Mac OSX stack update" -m "include/msvcrt/process.h tools/winegcc/winegcc.c" Anyway -- this patch is very simple and just extends the work that was done before to other places where stdcall and cdecl can be defined This makes sure they are all consistent and not misdefined (leading to runtime failures) And lastly -- any comments welcome... Ill try and follow this patch -- and at somepoint work on my openal patch (which did not go over too well last time poor openal -- there there I still like you) - Nick winePatchMacOSXStackUpdate.diff Description: Binary data
Re: Feedback requested for Mac OSX x86 stack patch
From: Robert Shearman <[EMAIL PROTECTED]> Subject: Re: Feedback requested for Mac OSX x86 stack patch Date: Thu, 08 Jun 2006 10:29:11 +0100 Nick Burns wrote: I tried using winapi_check, winapi_test, winapi_... They all seemed to give me some odd perl errors (missing defs/funcs in config.pm that WERE there and were also in setup.pm) So... I stupidly went thru and made the relevant files work by copying and pasting the functions and changing def imports to setup.pm (what a pain that was -- as i dont know perl) I am guessing this should just WORK... It seems like it would be a good idea to go thru the msvcrt functions and label the exports as WINAPIV (or __cdecl) -- im not sure what the desired convention is. WINAPIV is purely for vararg functions and might not match the calling conventions of msvcrt on other platforms. You should label them with CDECL instead, as Alexandre suggested. Ok if thats the correct solution -- some one (either me or someone else) should patch msvcrt to have have its exported functions as CDECL (which I now believe means that its an EXTERNAL EXPORTED function) I do not want the force attrib on internal functions for no good reason... The patch as it stands is heavy handed.. and needs to be narrowed correctly -- __stdcall/__cdecl could be internal maybe sometimes?. -- Rob Shearman - Nick
Re: Feedback requested for Mac OSX x86 stack patch -- #2
From: Robert Shearman <[EMAIL PROTECTED]>
Subject: Re: Feedback requested for Mac OSX x86 stack patch -- #2
Date: Thu, 08 Jun 2006 10:36:31 +0100
Nick Burns wrote:
diff -u -p -r1.114 ChangeLog
--- ChangeLog 24 May 2006 18:09:06 - 1.114
+++ ChangeLog 8 Jun 2006 07:06:10 -
@@ -1,3 +1,8 @@
+2006-06-08 Nick Burns <[EMAIL PROTECTED]>
+
+ * include/windef.h:
+ If on Mac OSX (x86) use force_align_arg_pointer to fix the stack
on entry to Wine.
+
2006-05-24 Alexandre Julliard <[EMAIL PROTECTED]>
* dlls/usp10/tests/usp10.c:
You don't need to patch ChangeLog; it is update each release from GIT
history. Just include the text you want in the change log in the email you
send the patch with.
Got ya no changelog dealies -- was unsure about that part...
Index: include/windef.h
===
RCS file: /home/wine/wine/include/windef.h,v
retrieving revision 1.103
diff -u -p -r1.103 windef.h
--- include/windef.h5 Jun 2006 12:29:21 -1.103
+++ include/windef.h8 Jun 2006 05:14:30 -
@@ -52,7 +52,12 @@ extern "C" {
#ifndef __stdcall
# ifdef __i386__
# ifdef __GNUC__
-# define __stdcall __attribute__((__stdcall__))
+# ifdef __APPLE__
+ /* Mac OSX uses 16-byte aligned stack and not a 4-byte one -- so we
must realign on entry */
Shouldn't this be #if defined __APPLE__ && defined __i386__?
Isnt ..
# ifdef __i386__
# ifdef __GNUC__
# ifdef __APPLE__
... the same? (should it be more clear?)
+#define __stdcall __attribute__((__stdcall__))
__attribute((force_align_arg_pointer))
+# else
+#define __stdcall __attribute__((__stdcall__))
+# endif
# elif defined(_MSC_VER)
/* Nothing needs to be done. __stdcall already exists */
# else
--
Rob Shearman
- Nick
Re: Feedback requested on an OpenAL audio driver patch -- #2
Got ya will remove that when I send to the wine patch list From: "James Hawkins" <[EMAIL PROTECTED]> Subject: Re: Feedback requested on an OpenAL audio driver patch -- #2 Date: Thu, 8 Jun 2006 10:03:19 -0700 On 6/8/06, Nick Burns <[EMAIL PROTECTED]> wrote: Ok I fixed up my OpenAL driver as per the suggestions (thanks much) I am not sure how to use or test pkg-config (does that exist on Mac OSX?) The differences with the OpenAL driver patch... 1. It has a perty ChangeLog diff You're not supposed to change ChangeLog; it's generated automatically. -- James Hawkins - Nick
Re: wined3d: GLSL Patch feedback requested
That looks very impressive (good progress). I would have to look at the actual GLSL produced by this. The actual translation points look good. From: "Jason Green" <[EMAIL PROTECTED]> Date: Thu, 8 Jun 2006 11:54:04 -0400 By the way, here's a comparison screenshot of Civ4 from before my hard drive failed, and this is without having texturing on pixel shaders entirely working. Using GLSL (working completely for vertex shaders 2.0, at least the instructions that Civilization 4 used): http://cmhousing.net/wine/civ4_glsl.png compared to: http://cmhousing.net/wine/civ4_ingame2.png and http://cmhousing.net/wine/civ4_3.png with current git and using regular ARB shaders. So, we at least know that this is going to help. :-) On 6/8/06, Jason Green <[EMAIL PROTECTED]> wrote: The current cumulative patch is located here: http://cmhousing.net/wine/glsl_cumul.diff (This includes the recently submitted "Split constant loading out of drawPrim()" patch, which hasn't been applied to git yet) Before submitting, I plan to fix the following things: - Fix relative addressing (it was working correctly, then I lost some stuff when my hard drive got corrupted, and now it's using R0 instead of A0 as the address register for some reason) - Switch the shader_reg_maps.constantsF[] to a CHAR array instead of a BOOL array (maybe even a bitmap(?)) This whole patchset should be a no-op for normal users, unless they have the UseGLSL registry key enabled. Here's a list of the changelogs that this cumulative patch entails, somewhat in the order that I'll be sending them: [already sent] Move constant loading out of DrawPrimDrawStrided() - DrawPrim is just too big of a function. This separates the passing of constants to the shader into new functions. - Fixes an off-by-one error when loading vertex declaration constants (should be <, not <=) - Adds a function for GLSL loading of constants (aka Uniforms) - Adds a GLSL program variable to the stateblock and sets it to 0 (a future patch will actually create this program) Add GLSL helper functions to device.c - Adds functions to attach & detach shader objects, create and delete programs, and maintain the list of programs. - Adds a list of GLSL shader programs to the device which is initialized on Init3D(), and deleted on Release() Add the bulk of the GLSL string generation functions - Add a new file glsl_shader.c which contains almost every GLSL specific function we'll need - Move print_glsl_info() into glsl_shader.c - Move the shader_reg_maps struct info into the private header, and make it part of SHADER_OPCODE_ARG. - Create a new shared ps/vs register map for float constants (future patch will make ARB programs use this, too) - This is a big patch, but none of the new functions in glsl_shader.c are being called yet. This just sets them up. Unified float constant register mapping between ARB pixel and vertex shaders. - Got rid of the separate constant maps. - Side effect of this is that the map is a bit larger for pixel shaders than it needs to be. - Will make this dynamic in a future patch. Added more declarations to GLSL in generate_glsl_declarations() - Declare more variable names for GLSL programs. - Correct output name for pixel shaders (gl_FragColor instead of glFragColor) Map pixel shader instructions to GLSL generating functions. - Also, delete the GLSL program when the refcount hits 0 Map vertex shader instructions to GLSL generating functions. - Also, delete the GLSL program when the refcount hits 0 Allow drawPrim to create and use the GLSL program - Now that we can fully create a GLSL program, this patch lets us actually use it. I would have submitted these all separate for review, but I have some janitorial git cleanup to do first to get all of this in the right order. - Nick
Feedback requested for Mac OSX x86 stack patch -- #2
Ok I have fixed up my Mac OSX stack patch a bit as per the feedback -- thanks much This only patches windef.h There still needs to be some solution for msvcrt AND any other api entry points that are not denoted with __stdcall or __cdecl or WINAPI or WINAPIV This means that Morrowwind (uses msvcrt:pow just cause) will crash on OSX atm (bad alignment) - Nick winePatch_Stack_MacOSXx86_2.diff Description: Binary data
Feedback requested on an OpenAL audio driver patch -- #2
Ok I fixed up my OpenAL driver as per the suggestions (thanks much) I am not sure how to use or test pkg-config (does that exist on Mac OSX?) The differences with the OpenAL driver patch... 1. It has a perty ChangeLog diff 2. configure.ac now checks for AL/al.h (which is where OpenAL should be) 3. dlls/Makefile.in should patch correctly now (I did not hand edit it this time -- still crossing fingers) 4. FIXME's -> ERR's for the legit OpenAL errs 5. alcCloseDevice in OpenAL 1.0 (no return value) in 1.1 it returns a boolean -- .: I dont check the boolean anymore -- meaning this error is now slient - Nick
Re: Feedback requested for Mac OSX x86 stack patch
From: Alexandre Julliard <[EMAIL PROTECTED]> Date: Tue, 06 Jun 2006 12:14:47 +0200 "Nick Burns" <[EMAIL PROTECTED]> writes: > I was concerned about msvcrt not using the __stdcall/WINAPI for its > functions (why is this?). Most msvcrt functions use the cdecl calling convention, not stdcall. Ok makes sense... (I didnt notice the spec file before) > Where can I find a list of (or affect the attribs of) windows callable > functions. > I thought WINAPI and WINAPIV were sufficent -- If they are not more > functions will need to be 'fixed'. They should be 99% sufficient, but of course the remaining 1% will be fun to chase down. There's no complete list, though maybe winapi_check could be used to verify these things, at least for functions exported from the spec files. I tried using winapi_check, winapi_test, winapi_... They all seemed to give me some odd perl errors (missing defs/funcs in config.pm that WERE there and were also in setup.pm) So... I stupidly went thru and made the relevant files work by copying and pasting the functions and changing def imports to setup.pm (what a pain that was -- as i dont know perl) I am guessing this should just WORK... It seems like it would be a good idea to go thru the msvcrt functions and label the exports as WINAPIV (or __cdecl) -- im not sure what the desired convention is. -- Alexandre Julliard [EMAIL PROTECTED] - Nick
Re: Feedback requested for Mac OSX x86 stack patch
From: Alexandre Julliard <[EMAIL PROTECTED]> Date: Wed, 07 Jun 2006 11:40:42 +0200 "Nick Burns" <[EMAIL PROTECTED]> writes: > What about overriding __cdecl and __stdcall? > Are there any internal functions that use those that should not? > That would get around the APIENTRY/WINAPI/CALLBACK problem with OpenGL That's probably the easiest, yes. It may well cover too many functions, but it's better to err in this direction. We'll still need to make sure all exported cdecl functions use __cdecl though. Ok I will reform my patch to be ... extra inclusive... I will modify cdecl and stdcall to use stack realignment I will not have any modifications to msvcrt (at least not yet) I will leave the redefinitions alone for the time being... -- Alexandre Julliard [EMAIL PROTECTED] - Nick
Re: Feedback requested on an OpenAL audio driver patch
From: Leon Freitag <[EMAIL PROTECTED]> Date: Wed, 7 Jun 2006 12:07:32 +0200 > AC_CHECK_HEADERS(\ >+ OpenAL/al.h \ >+ al/al.h \ >AudioUnit/AudioUnit.h \ >CoreAudio/CoreAudio.h \ >IOKit/IOKitLib.h \ Your patch checks for OpenAL headers only in these places. However my distro (Suse 10.1) puts openal headers to AL/ instead of al/ and so configure with the patch as-is doesn't find files on my system. Whoops typo -- al/al.h is wrong -- it should be AL/al.h (fixed in next patch) Also patching dlls/makefile.in fails. Had to patch it manually. This is probably cause I hand edited the patch diff... I will redo this in the next patch. (fixed in next patch) Leon - Nick
Re: Feedback requested on an OpenAL audio driver patch
From: Leon Freitag <[EMAIL PROTECTED]> Date: Wed, 7 Jun 2006 12:09:36 +0200 P.S. Isn't it better to use pkg-config to check where the libs are located anyway? Leon Is there an example of this? - Nick
Re: Feedback requested on an OpenAL audio driver patch
From: Leon Freitag <[EMAIL PROTECTED]> Date: Wed, 7 Jun 2006 15:54:49 +0200 My first impressions: 1) Doesn't compile here: audio.c: In function âOpenAL_WaveCloseâ: audio.c:636: error: void value not ignored as it ought to be because alcCloseDevice() is declared here as void (my openal version is 1.0.20051129) Grr -- OpenAL 1.0 spec does not return anything there (Thanks good catch) This means I cannot check errors on device closing... (fixed will e in next patch) 2) It'd be better to convert ALC errors from FIXMEs to ERRs. Will do -- I was just used to FIXME... Hehe at first (as I was implementing) they were fixme for real! Now they are openal failures. (fixed will be in next patch) 3) You don't link the driver to openal somewhy (there's no -lopenal switch passed to gcc). Perhaps it's related to the configure.in hack I made, but I had to modify dlls/winmm/wineopenal/Makefile.in and add openal there too. It should do a -lopenal -- looking at configure.ac 'if test "$ac_cv_header_al_al_h" = "yes" then dnl OpenAL framework AC_SUBST(OPENAL,"-lopenal") fi' Makefile.in 'EXTRALIBS = $(LIBUUID) @OPENAL@' Could be related to 4... (should work in next patch due to fix in 4) 4) You check for al/al.h and OpenAL/al.h within the configure script but you include AL/al.h and OpenAL/al.h. This doesn't work on Linux, since Linux filesystems are case sensitive. Whoops -- its SUPPOSED to be AL/al.h -- I typoed! (fixed in configure.ac -- will be sending new patch) Leon Thanks for the feedback! -- all the way from Russia - Nick
Re: Feedback requested on an OpenAL audio driver patch
From: Robert Reif <[EMAIL PROTECTED]> Date: Wed, 07 Jun 2006 20:55:58 -0400 Nick Burns wrote: It seemed to work well for GTA3, Tribes2 and FlatOut(requires a binary patch to run) (dsound) -- and for SndRec32 (win/wout) (Games and ...App... tested under Mac OSX x86 -- Mac Book Pro) How do the winmm and dsound regression tests work when run in the interactive mode? I did not know these tests existed -- cool... So I ran dsound_test and winmm_test (interactive mode?) on the command line There are some failures -- but no crashing Some games like Carmageddon2 are unhappy with openal atm. - Nick
Re: Feedback requested for Mac OSX x86 stack patch
Although I probably should not talk to myself (responding to my own email) Something did occur to me From: "Nick Burns" <[EMAIL PROTECTED]> To: wine-devel@winehq.org, [EMAIL PROTECTED] Subject: Re: Feedback requested for Mac OSX x86 stack patch Date: Tue, 06 Jun 2006 18:49:54 -0700 From: Alexandre Julliard <[EMAIL PROTECTED]> Date: Tue, 06 Jun 2006 21:20:51 +0200 "Nick Burns" <[EMAIL PROTECTED]> writes: > Ok so that makes more sense about MSVCRT -- but if it is using cdecl -- > shouldnt that use WINAPIV? CDECL would be more appropriate. Well is CDECL for windows callable functions? I was under the impression that WINAPI/WINAPIV were used for windows callable functions... (Where I got that impression I do not know.) Is that wrong? If __cdecl was overridden would that affect msvcrt? > I did not see anything forcing a cdecl calling convention (other than > the spec file). And I dunno how to modify the spec file to add in more > attribs. cdecl is the default, that's why it's not specified. Since they are windows callable functions should they and others like them be denoted as such? Internal functions are different then those callable from windows. That difference does not have to be made... But it allows for a little extra performance. Are __stdcall or __cdecl used for any internal functions? > So, should I finish this patch (e.g. catch every single callable > function and put the attrib on it) > Or, should I send the simple 99% patch first for WINAPI/WINAPIV > (removing meaningless redefs) -- I would probably ignore msvcrt for > the first patch Eventually of course we have to catch every function, but redefining WINAPI is already a good start. Hmm I am seeing a few problems in this area... I was looking at why those undefs/redefs exist... and they are used around areas where APIENTRY/WINAPI/CALLBACK are potentially used (either internally or externally -- mainly by OpenGL headers or function protos). This may need a different fix -- sadly the c preprocessor is a very limited language Any ideas in this realm? What about overriding __cdecl and __stdcall? Are there any internal functions that use those that should not? That would get around the APIENTRY/WINAPI/CALLBACK problem with OpenGL The main reason I overrode WINAPI and WINAPIV was because of my previously mentioned impression (...) -- Alexandre Julliard [EMAIL PROTECTED] - Nick - Nick (again)
Re: Feedback requested for Mac OSX x86 stack patch
From: Alexandre Julliard <[EMAIL PROTECTED]> Date: Tue, 06 Jun 2006 21:20:51 +0200 "Nick Burns" <[EMAIL PROTECTED]> writes: > Ok so that makes more sense about MSVCRT -- but if it is using cdecl -- > shouldnt that use WINAPIV? CDECL would be more appropriate. Well is CDECL for windows callable functions? I was under the impression that WINAPI/WINAPIV were used for windows callable functions... (Where I got that impression I do not know.) Is that wrong? > I did not see anything forcing a cdecl calling convention (other than > the spec file). And I dunno how to modify the spec file to add in more > attribs. cdecl is the default, that's why it's not specified. Since they are windows callable functions should they and others like them be denoted as such? Internal functions are different then those callable from windows. That difference does not have to be made... But it allows for a little extra performance. > So, should I finish this patch (e.g. catch every single callable > function and put the attrib on it) > Or, should I send the simple 99% patch first for WINAPI/WINAPIV > (removing meaningless redefs) -- I would probably ignore msvcrt for > the first patch Eventually of course we have to catch every function, but redefining WINAPI is already a good start. Hmm I am seeing a few problems in this area... I was looking at why those undefs/redefs exist... and they are used around areas where APIENTRY/WINAPI/CALLBACK are potentially used (either internally or externally -- mainly by OpenGL headers or function protos). This may need a different fix -- sadly the c preprocessor is a very limited language Any ideas in this realm? -- Alexandre Julliard [EMAIL PROTECTED] - Nick
Re: Prospects of an OpenAL audio driver...
Date: Tue, 06 Jun 2006 22:36:26 +0200 Nick Burns wrote: OpenAL 1.1 supports recording... (1.0 does not have recording so that is a problem yes) -- My driver handles this atm -- it checks for recording capabilities and supports accordingly half or full duplex ? Unknown... (sorry not an openal master ...yet...). I can ask the dev working on OpenAL about these types of things. The OpenAL api is rather simple - For playback : you make buffers and queue them then poll them (to find out when they are done) There are some extensions that cut out copies/support eax/... (I have not looked at em yet) (support 2d and 3d audio) hmm that's what we said for Alsa... 3 years later quality is still not there :-/ Hehe -- I had no knowledge of this (just learned oss, alsa and openal existed like 3 weeks ago) - For recording (1.1 only) : start capturing -- poll (get data -- if there) -- stop recording The dsound mapping stuff I want to understand better (are there any docs for this?) I am sure we can layer it on OpenAL (hopefully good) I doubt it for direct HW mapping (HEL should be fine). Unfortunately, no doc. Hmm... Is there a way I can request some docs (or is the source code + msdn the doc)? PortAudio looks like a good choice as well -- afaict -- but I dont have any exp with it (not that I had any openal exp when i started that driver hehe) The whole point here is that OpenAL doesn't bring much to the picture (apart perhaps from a portability perspective, but it's still overkill). A+ I would not say overkill (well maybe for linux its overkill but) Mac OSX only has JACK(does not work atm), ESD(...slow), and now CoreAudio(crashs in winecfg -- does play games -- but has ... static) drivers CoreAudio is the only one that can show any decent performance -- and its not really very... Portable OpenAL can show good performance on Mac OSX and other platforms (so others can test things and stuff -- even under windows) I am not saying that OpenAL should be the catch-all sound driver -- but its nice to have an alternative (that I can play GTA3 with -- although i suggest not playing with a trackpad) You can take a look at my driver (posted to this list -- and its in the archive at http://www.winehq.org/pipermail/wine-devel/2006-June/048273.html) It is heavily based on the esd driver (my starting point). Which was heavily based off of arts/alsa... - Nick
Re: Feedback requested for Mac OSX x86 stack patch
Ok so that makes more sense about MSVCRT -- but if it is using cdecl -- shouldnt that use WINAPIV? I did not see anything forcing a cdecl calling convention (other than the spec file). And I dunno how to modify the spec file to add in more attribs. I have not used winapi_check before -- I can check that then. So, should I finish this patch (e.g. catch every single callable function and put the attrib on it) Or, should I send the simple 99% patch first for WINAPI/WINAPIV (removing meaningless redefs) -- I would probably ignore msvcrt for the first patch (I dunno when I will have time to reform msvcrt for a full patch) Date: Tue, 06 Jun 2006 12:14:47 +0200 "Nick Burns" <[EMAIL PROTECTED]> writes: > I was concerned about msvcrt not using the __stdcall/WINAPI for its > functions (why is this?). Most msvcrt functions use the cdecl calling convention, not stdcall. > Where can I find a list of (or affect the attribs of) windows callable > functions. > I thought WINAPI and WINAPIV were sufficent -- If they are not more > functions will need to be 'fixed'. They should be 99% sufficient, but of course the remaining 1% will be fun to chase down. There's no complete list, though maybe winapi_check could be used to verify these things, at least for functions exported from the spec files. -- Alexandre Julliard [EMAIL PROTECTED] - Nick
Re: Feedback requested for Mac OSX x86 stack patch
Thanks for the feedback... I look forward to windows apps not dieing a horrible death on Mac OSX I was concerned about msvcrt not using the __stdcall/WINAPI for its functions (why is this?). I am guessing the d3d8/d3d9 redefinitions should be removed? Where can I find a list of (or affect the attribs of) windows callable functions. I thought WINAPI and WINAPIV were sufficent -- If they are not more functions will need to be 'fixed'. From: Alexandre Julliard <[EMAIL PROTECTED]> Date: Mon, 05 Jun 2006 21:21:01 +0200 "Nick Burns" <[EMAIL PROTECTED]> writes: > (notes are at the top of the patch) > > I would like some feedback on my stack fix patch > > I do not know how it interacts with linux -- no access to a linux box > This has been confirmed to fix numerous app issues (due to stack alignment) > > I am starting to think it would be better to have these options > configured at config time > -- e.g. > If Mac OSX x86 -- then use mstackrealign + force_align_arg_pointer > > Any ideas/thoughts? It looks OK, but it will clearly need some cleaning up. The msvcrt part should be done with function attributes too. The d3d8/d3d9 redefinitions are probably no longer necessary and should be removed. Also there are a number of functions that use __stdcall instead of WINAPI, these would need to be changed. -- Alexandre Julliard [EMAIL PROTECTED] - Nick
Feedback requested for Mac OSX x86 stack patch
(notes are at the top of the patch) I would like some feedback on my stack fix patch I do not know how it interacts with linux -- no access to a linux box This has been confirmed to fix numerous app issues (due to stack alignment) I am starting to think it would be better to have these options configured at config time -- e.g. If Mac OSX x86 -- then use mstackrealign + force_align_arg_pointer Any ideas/thoughts? - Nick winePatch_Stack_MacOSXx86.diff Description: Binary data
Re: Prospects of an OpenAL audio driver...
OpenAL 1.1 supports recording... (1.0 does not have recording so that is a problem yes) -- My driver handles this atm -- it checks for recording capabilities and supports accordingly The OpenAL api is rather simple - For playback : you make buffers and queue them then poll them (to find out when they are done) There are some extensions that cut out copies/support eax/... (I have not looked at em yet) (support 2d and 3d audio) - For recording (1.1 only) : start capturing -- poll (get data -- if there) -- stop recording The dsound mapping stuff I want to understand better (are there any docs for this?) I am sure we can layer it on OpenAL (hopefully good) PortAudio looks like a good choice as well -- afaict -- but I dont have any exp with it (not that I had any openal exp when i started that driver hehe) - Should I just submit my driver to wine-devel and see what people think? It does work for wavein/waveout (still trying to flesh out a few issues) - Nick
Re: Prospects of an OpenAL audio driver...
On Fri, 02 Jun 2006 02:08:04 -0700, Nick Burns wrote: Are there any problems with using OpenAL for such a purpose? Probably not, it depends on the exact level of abstraction OpenAL gives. But it begs the question - why? thanks -mike The reason for using OpenAL is for platforms that dont have alsa/oss/esd/... support For one it gives a chance to test audio on windows for example -- and on mac osx (although the winecoreaudio driver is making great progress). - Nick
Prospects of an OpenAL audio driver...
I have started work on an openal driver for wine... So far I have playback and recording working (with minor issues) (for some reason the DSound HEL is unhappy with my driver) OpenAL seems to have enough functionality to do the job. Are there any problems with using OpenAL for such a purpose? - Nick
RE: DDraw, wined3d (d3d8, d3d9) and OpenGL32 in Mac OSXx86 + stack fudging
Whow sorry about messing up the patch there guys... Serves me right for posting at 3am In the future ill be a better citizen -- sorry again - Nick
RE: DDraw, wined3d (d3d8, d3d9) and OpenGL32 in Mac OSX + stack fudging -- x86 only
Here is the patch thus far -- It is not clean or anything... (cvs -q diff -
straight from my tree)
--I think this patch will work and allow you to run specific ogl and d3d
apps (with enough stack fudging see below)
--Here is an example of the stack fudging
--Since this is too hard to add to all entry points... I did not bother
doing it en mass (only for functions that were causing crashes for demos --
waiting for gcc goodness)
void WINAPI SomeApiEntryPoint()
{
//begin stack alignment
asm("pushl 0(%ebp)");//save ebp`
asm("movl %esp, 0(%ebp)");//hope that 0(%ebp) is not used in function
//save esp -- ebp -> esp -> ebp`
asm("subl %ebp, %esp");//calc n
asm("addl %esp, %esp");//n*2
asm("addl %ebp, %esp");//n*2+esp
asm("subl $0x10, %esp");//pad out stack
asm("andl $0xFFF0, %esp");//align the stack
//end stack alignment
...
//body
...
//begin stack restore
asm("movl 0(%ebp), %esp");//restore esp -- ebp -> esp -> ebp`
asm("popl 0(%ebp)");//restore ebp` + esp
//end stack restore
return;
}
WE so fun
- Nick
cvs -q diff
Index: dlls/ddraw/Makefile.in
===
RCS file: /home/wine/wine/dlls/ddraw/Makefile.in,v
retrieving revision 1.40
diff -r1.40 Makefile.in
9c9
< EXTRALIBS = -ldxguid -luuid @X_LIBS@ @X_PRE_LIBS@ @XLIB@ @X_EXTRA_LIBS@
---
EXTRALIBS = -ldxguid -luuid @X_LIBS@ @X_PRE_LIBS@ @XLIB@ @X_EXTRA_LIBS@
@OPENGL_LIBS@
Index: dlls/ddraw/device_opengl.c
===
RCS file: /home/wine/wine/dlls/ddraw/device_opengl.c,v
retrieving revision 1.12
diff -r1.12 device_opengl.c
4316c4316
< Drawable drawable = (Drawable) GetPropA(GetDesktopWindow(),
"__wine_x11_whole_window");
---
Drawable drawable;// = (Drawable) GetPropA(GetDesktopWindow(),
"__wine_x11_whole_window");
4327a4328,4332
#ifdef __APPLE__
FIXME("Root window apple bad!!!\n");
HWND hwnd = CreateWindowA("BUTTON", "fake", 0, 0, 0, 10, 10, NULL,
NULL, GetModuleHandleA(NULL), NULL);
drawable = (Drawable) GetPropA(hwnd, "__wine_x11_whole_window");
4333c4338,4350
<
---
/* Get a default rendering context to have the 'caps' function query
some info from GL */ device_context = GetDC(hwnd);
display = get_display(device_context);
ReleaseDC(hwnd, device_context);
#else
drawable = (Drawable) GetPropA(GetDesktopWindow(),
"__wine_x11_whole_window");
if (!drawable)
{
WARN("x11drv not loaded - D3D support disabled!\n");
return FALSE;
}
4337a4355
#endif
4371a4390,4392
#ifdef __APPLE__
pglXGetProcAddressARB = glXGetProcAddress;
#else
4372a4394
#endif
4446a4469,4472
#ifdef __APPLE__
FIXME("Root window apple bad!!!\n");
DestroyWindow(hwnd);
#endif
Index: dlls/ddraw/main.c
===
RCS file: /home/wine/wine/dlls/ddraw/main.c,v
retrieving revision 1.57
diff -r1.57 main.c
91a92,99
#ifdef __APPLE__
gl_handle=5;
#define GL_API_FUNCTION(f) p##f=f;
#include "gl_api.h"
#undef GL_API_FUNCTION
return d3ddevice_init_at_startup(gl_handle);
#else
118a127
#endif
Index: dlls/opengl32/wgl.c
===
RCS file: /home/wine/wine/dlls/opengl32/wgl.c,v
retrieving revision 1.78
diff -r1.78 wgl.c
49a50,356
#ifdef __APPLE__
GLXFBConfig* APPLE_glXGetFBConfigs(Display* dpy, int screen, int* ncfgs);
GLXFBConfig* APPLE_glXChooseFBConfig(Display* dpy, int screen, int*
attribs, int* ncfgs);
int APPLE_glXGetFBConfigAttrib(Display* dpy, GLXFBConfig cfg, int attrib,
int* val);
XVisualInfo* APPLE_glXGetVisualFromFBConfig(Display* dpy, GLXFBConfig cfg);
typedef struct
{
XVisualInfo* info;
int fbconfig_id;
}APPLE_GLXFBConfig;
GLXFBConfig* APPLE_glXGetFBConfigs(Display* dpy, int screen, int* ncfgs)
{
int attribs[]={None};
return APPLE_glXChooseFBConfig(dpy,screen,attribs,ncfgs);
}
GLXFBConfig* APPLE_glXChooseFBConfig(Display* dpy, int screen, int*
attribs, int* ncfgs)
{
#define add_attrib(val) {_attribs[on_Attrib]=val;on_Attrib++;}
#define find_attrib(enum_type,found,outval)\
{\
found=0;\
outval=0;\
for(onattrib=0;attribs[onattrib]!=None;onattrib+=2)\
{\
/*printf("(%d)->%d\n",onattrib,attribs[onattrib]);*/\
if(attribs[onattrib]==enum_type)\
{\
found=1;\
outval=attribs[onattrib+1];\
}\
}\
}\
#if 1
{
int onattrib;
for(onattrib=0;attribs[onattrib]!=None;onattrib+=2)
{
switch(attribs[onattrib])
{
#if 0
#define print_case(case_val) case case_val:printf(#case_val " ==
%d\n",attribs[onattrib+1]);break;
#else
#define print_case(case_val) case case_val:break;
#endif
#define error_case(case_val) case case_val:printf("unsupported attrib"
#case_val " == %d\n",attribs[onattrib+1]);break;
print_case(GLX_FBCONFIG_ID)
print_case(GLX_BUF
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
Window resizing in respect to 2DTestDX9.exe
Window resizing in Direct3d9 -- and I mean the resizing handled BY direct3d -- stretches the rendered image to fit the resized window... This allows 2DTestDX9 demo to work with resizing... I would like to know if the current ideas for window resizing will handle the 2DTestDX9 demo. I know this is not the common d3d demo (hey no real 3d to speak of here) but adding support for this class of apps ought to be considered... ---called 2D Blits in DirectX 9... https://secure.codeproject.com/directx/files.asp https://secure.codeproject.com/directx/files/2DTestDX9.zip golly gee thats a hard demo to find again... (and its https.. crap) Im not sure how people can get it (maybe bugmenot.com for codeproject??) or http://www.codeproject.com/directx/files.asp http://www.codeproject.com/directx/files/2DTestDX9.zip Your mileage WILL vary...
Wined3d Regression...
Just thought I'd let ya guys know -- I noticed a little regression in the latest build of wined3d On Nvidia GeForce 4 4200 64MB (ask if ya want more specs) dx9_1pass_emboss_bump_mapping.exe -- only a white rectangle (no longer the embossed wood texture) on a black background dx9_2pass_emboss_bump_mapping.exe -- This is textured and embossed but is WAY too brown, also the fake light source polygon is brown dx9_effect_simple.exe -- only a white rectangle -- just like dx9_1pass_emboss_bump_mapping.exe I havent had time (and wont -- I have to read all of Deliverance by tomorrow thats 260 pages) to test all them demos (I would like confirmation about the above tests on other hardware)
Water effect demo patch...
I got Water demo working -- whew thats all of my lil demos here (crap gotta
get some more...)
So heres the deal
Water should have worked with wined3d -- but it was crashing on me due to
the following...
(the patch is attached -- you may have to use fromdos (for formatting
newline issues))
...drawprim.c : drawStridedSlow : ~1210...
intcoordIdx =
This->stateBlock->textureState[textureNo][D3DTSS_TEXCOORDINDEX];
float *ptrToCoords = (float
*)(sd->u.s.texCoords[coordIdx].lpData + (SkipnStrides *
sd->u.s.texCoords[coordIdx].dwStride)); /*INSTA-CRASH(tm) location*/
float s = 0.0, t = 0.0, r = 0.0, q = 0.0;
if (coordIdx > 7) {
VTRACE(("tex: %d - Skip tex coords, as being system
generated\n", textureNo));
continue;
} else if (sd->u.s.texCoords[coordIdx].lpData == NULL)
{/*NOTICE pointer validity check here*/
TRACE("tex: %d - Skipping tex coords, as no data
supplied\n", textureNo);
continue;
} else {
/*pointer safety*/
float *ptrToCoords = (float *)(sd->u.s.texCoords[coordIdx].lpData +
(SkipnStrides * sd->u.s.texCoords[coordIdx].dwStride));
---the fix-use pointer after check(not
before)--
intcoordIdx =
This->stateBlock->textureState[textureNo][D3DTSS_TEXCOORDINDEX];
/*former INSTA-CRASH(tm) location*/
float s = 0.0, t = 0.0, r = 0.0, q = 0.0;
if (coordIdx > 7) {
VTRACE(("tex: %d - Skip tex coords, as being system
generated\n", textureNo));
continue;
} else if (sd->u.s.texCoords[coordIdx].lpData == NULL)
{/*NOTICE pointer validity check here*/
TRACE("tex: %d - Skipping tex coords, as no data
supplied\n", textureNo);
continue;
} else {
/*pointer safety*/
float *ptrToCoords = (float *)(sd->u.s.texCoords[coordIdx].lpData +
(SkipnStrides * sd->u.s.texCoords[coordIdx].dwStride));
-
patch version -- also attached -- dunno if the below will even format
correctly
-
cvs -z4 diff -u -wb -d -p drawprim.c (in directory
C:\cvs_stuff\wine\dlls\wined3d\)
Index: drawprim.c
===
RCS file: /home/wine/wine/dlls/wined3d/drawprim.c,v
retrieving revision 1.16
diff -u -w -b -d -p -r1.16 drawprim.c
--- drawprim.c 14 Jul 2005 12:19:53 - 1.16
+++ drawprim.c 16 Jul 2005 21:08:45 -
@@ -1207,7 +1207,9 @@ static void drawStridedSlow(IWineD3DDevi
if (This->stateBlock->textures[textureNo] != NULL) {
intcoordIdx =
This->stateBlock->textureState[textureNo][D3DTSS_TEXCOORDINDEX];
+#if 0
float *ptrToCoords = (float
*)(sd->u.s.texCoords[coordIdx].lpData + (SkipnStrides *
sd->u.s.texCoords[coordIdx].dwStride));
+#endif
float s = 0.0, t = 0.0, r = 0.0, q = 0.0;
if (coordIdx > 7) {
@@ -1218,6 +1220,8 @@ static void drawStridedSlow(IWineD3DDevi
continue;
} else {
+/*pointer safety*/
+float *ptrToCoords = (float *)(sd->u.s.texCoords[coordIdx].lpData +
(SkipnStrides * sd->u.s.texCoords[coordIdx].dwStride));
int coordsToUse = sd->u.s.texCoords[coordIdx].dwType +
1; /* 0 == D3DDECLTYPE_FLOAT1 etc */
/* The coords to supply depend completely on the fvf /
vertex shader */
Index: dlls/wined3d/drawprim.c
===
RCS file: /home/wine/wine/dlls/wined3d/drawprim.c,v
retrieving revision 1.16
diff -u -w -b -d -p -r1.16 drawprim.c
--- dlls/wined3d/drawprim.c 14 Jul 2005 12:19:53 - 1.16
+++ dlls/wined3d/drawprim.c 16 Jul 2005 21:09:58 -
@@ -1207,7 +1207,9 @@ static void drawStridedSlow(IWineD3DDevi
if (This->stateBlock->textures[textureNo] != NULL) {
intcoordIdx =
This->stateBlock->textureState[textureNo][D3DTSS_TEXCOORDINDEX];
+#if 0
float *ptrToCoords = (float
*)(sd->u.s.texCoords[coordIdx].lpData + (SkipnStrides *
sd->u.s.texCoords[coordIdx].dwStride));
+#endif
float s = 0.0, t = 0.0, r = 0.0, q = 0.0;
if (coordIdx > 7) {
@@ -1218,6 +1220,8 @@ static void drawStridedSlow(IWineD3DDevi
continue;
} else {
+/*pointer safety*/
+float *ptrToCoords = (float *)(sd->u.s.texCoords[coordIdx].lpData +
(SkipnStrides * sd->u.s.texCoords[coordIdx].dwStride));
int coordsToUse = sd->u.s.texCoords[coordIdx].dwType +
1; /* 0 == D3DDECLTYPE_FLOAT1 etc */
/* The coords to supply depend completely on the fvf /
vertex shader */
Re: Window resizing in wined3d
It may be nice to prove/test that the opengl32.dll implementation in wine works correctly -- but I agree that another translation layer does not sound nice... "__WIN32_OPENGL__" is the compilation flag im using -- it can either be defined in the makefile (is not at present) or it is choosen by the presence of "__CYGWIN__ || WIN32" Any other/better ideas I'd love to put em in my patch (which I will be posting shortly -- trying to get it in under 64kb and remove useless dependencies -- you should be seeing it soon today) Nick
Window resizing in wined3d
Is window resizing supported in GLX wined3d? For GLX -> WGL wined3d... I have written an incorrect version of window resizing -- that simply changes the viewport. This viewport changing works fine for the demos (but does not stretch the output as semantically defined by d3d9). I am guessing that pbuffers would have to be used as the render target -- then during a present the pbuffer would be bitbltted (stretched) to the output window... An alternate possibility is to use DibSections... (probably slow as dirt -- also not GLX compliant) --- Anyhow I have added SwapEffect and PresentationInterval support to my GLX -> WGL wined3d patch (so now vsync options are supported -- good for preformance measurments) --- And lastly with my GLX -> WGL patch would it be better to use wgl functions explictly and remove support for GLX completely or would it be better to support both GLX and WGL (as mine does currently)
Updated GLX -> WGL d3d9 patch
Initial window resizing implemented Initial vsync choosing implemented Initial swap effects implemented Synced with wine HEAD (thats the fun part...) GLX is still supported #define __WIN32_OPENGL__ to use WGL instead of GLX (this is done automatically if either __CYGWIN__ or WIN32 is defined) Makefile.in has not been modified for compiling... this has to be done manually now (link to opengl32 instead of using the GLX libs) I need to clean it up a little before making my diff patch file --send an email if ya want the patch --Ill probably post it on wine-devel soon along with latest regression tests -- but I have a term paper due monday so we will see how it all goes... college english lit fun... Nick
Automatic wined3d/d3d9/gfx testing in wine
Do any of the other devs out there have any ideas how to do some nice and easy automatic gfx testing for d3d9, etc... At present my testing methods are slow and easily prone to error (does it look like what d3d9 gave me?). I run the test on one computer (real d3d9) then on my other (wined3d d3d9) and compare. It seems as thou this would be rather nice e.g. have a specific set of output (gfx either pics or vid or ??? -- speed would be hard to MEET as a req.) gathered from (various) windows machines and then try to regenerate this output with wine's d3d9 Fraps may be useful for this type of endovur or mayhap a gigantic test suite (that tests every aspect of d3d9 -- this would be large and... take a long time to do + demos already exist) At present there are LOTS of d3d9 demos that do things a certain way (not always the correct way) and wined3d/d3d9 should match these as close as possible Well any thoughts? Has this been done? Well just throwing this out there -- one more in the void cannot hurt... Nick
RE: wined3d - d3d9 regression testing 7_12_2005
please forgive the spacing... ...This is just a start at a format for this kinda thing -- pls modify as ya see fit... ...also more demos wont hurt(well only me)... results of wined3d - d3d9 regression testing 7_12_2005 --Windows98SE AthlonXP 2100+, 256MB, GF4 4200 64MB 85hz (using wined3d+GLX->WGL patch) NOTE: many comments will look the same (maybe small changes) as things are fixed/break they will be updated (by magic) NOTE: for all programs that list fps -- they will be listed here -- these #s are only useful in reference to new numbers from same comp (or for bragging) these #s should help determine which patches speed up/slow down what and by how much -- this should be done for all programs in an easily repeatable way (that cannot foul up) NOTE: ok I feel stupid... I just remember my GF4 is running at 85hz... VSync is on, so all of the 85fps values you see... are >=85 fps I should add (wglSwapIntervalEXT(VSYNC);) to my WGL patch -- mayhap I will if it is desired... for now itll stay...albeit not totally useful ...end of stupid feeling... New Bugs none noticed Removed Bugs some speed/sampling issues seem gone thanks to latest patch General overview some demos give odd crash on exit resizing windows is hacked (blame me) -- instead of stretching the output -- it simply changes the viewport size for programs that enumerate display modes the screen flashes alot for programs that enumerate display formats it takes a LONG time to startup in fullscreen where you can press f2(to change gfx) -- pressing f2 crashes it there are scissoring problems (in windows98se not xp) with the opengl windows -- probably not a problem in X from http://www.codesampler.com/dx9src.htm dx9_1pass_emboss_bump_mapping (same as real d3d9) dx9_2pass_emboss_bump_mapping (same as real d3d9) dx9_alpha_blending_texture (same as real d3d9) dx9_multiple_vertex_buffers (same as real d3d9) --dx9_texture_dot3_blending !!!(???...could not find on site...???)!!! dx9_texture_filtering (same as real d3d9 -- this seems to work correctly now but im unsure) dx9_texture_mipmapping (same as real d3d9 -- ITS FAST YEAH -- filters work differently -- ... hard to explain) dx9_texture_subloading (same as real d3d9) dx9_tokamak_chain (same as real d3d9 -- and impressive -- best demo of bunch -- BTW press F1 and have more fun...) dx9_transforms (same as real d3d9) dx9_vertex_data (same as real d3d9) --dx9_view_matrix !!!(???...could not find on site (dx8_view_matrix not dx9_view_matrix)...???)!!! dx9_view_ports (same as real d3d9 -- but does not resize) dx9_spot_light (differences between opengl lighting and d3d9 lighting) dx9_texture (same as real d3d9) dx9_texture_addressing (... unsure about what this SHOULD look like -- but runs fine and does stuff) dx9_primitive_types (same as real d3d9) dx9_point_light (same as real d3d9) dx9_dot3_bump_mapping (same as real d3d9) dx9_effect_simple (same as real d3d9) dx9_fonts (same as real d3d9) dx9_indexed_geometry (same as real d3d9) dx9_initialization (same as real d3d9) dx9_lighting (same as real d3d9 -- I do not notice any artifacts? maybe an ATI problem?) dx9_material (same as real d3d9 -- synchronized teapots ya cannot beat it) dx9_multitexture (same as real d3d9) dx9_offscreen_rendering (same as real d3d9) dx9_2d_demo_game (extremely SLOW (will wait for patch) -- animations?? unsure too slow (like 0.1 fps)) from http://triplebuffer.devmaster.net/tutorials.php BumpMapping (same as real d3d9) tb_dx9_03 (same as real d3d9) tb_dx9_04 (same as real d3d9) tb_dx9_05 (same as real d3d9) tb_dx9_06 (same as real d3d9) tb_dx9_07 (same as real d3d9) tb_dx9_08 (same as real d3d9) tb_dx9_09 (same as real d3d9) 85 fps 800x600 tb_dx9_10 (same as real d3d9) 85 fps 800x600 from http://www.clootie.ru/delphi/download_dx90.html#Direct3D Tut01_CreateDevice (same as real d3d9) Tut02_Vertices (same as real d3d9) Tut03_Matrices (same as real d3d9) Tut04_Lights (same as real d3d9) Tut05_Textures (same as real d3d9) Tut06_Meshes (same as real d3d9) cull (same as real d3d9 -- except slow (180 fps -> 20 fps)) 20fps 800x600 -- 2x better than 10 - additional tested demos mview (same as real d3d9 -- except cannot resize/move (crashes) -- and on windows98se (xp is fine) the top bar buttons and bottom status bar are covered by opengl gfx -- bad scissoring?) >=85fps -- teapot standard window size (no movement) 2DTestDX9 (same as real d3d9 -- except the 2d does not stretch on window resize (see top comment)) text3d (same as real d3d9 -- except for usability issues -- starts in fullscreen (cannot find windowed mode?) -- cannot press f2 (crashes)) >=85fps 800x600 ShadowVolume (same as real d3d9 -- except for usability issues -- starts in fullscreen (cannot find windowed mode?) -- cannot press f2 (crashes)) >=85fps 800x600 MultiDx (same as real d3d9 -- EXCEPT all panes draw the teapot on a 1b
RE: wined3d - d3d9 regression testing
results of wined3d - d3d9 regression testing on windows98se gf4 4200 64MB (using wined3d+GLX->WGL patch) General overview some demos give odd crash on exit resizing windows is hacked (blame me) -- instead of stretching the output -- it simply changes the vireport size for programs that enumerate display modes the screen flashes alot for programs that enumerate display formats it takes a LONG time to startup from http://www.codesampler.com/dx9src.htm dx9_1pass_emboss_bump_mapping (same as real d3d9) dx9_2pass_emboss_bump_mapping (same as real d3d9) dx9_alpha_blending_texture (same as real d3d9) dx9_multiple_vertex_buffers (same as real d3d9) --dx9_texture_dot3_blending !!!(???...could not find on site...???)!!! dx9_texture_filtering (same as real d3d9 -- but only magfilter seems to work) dx9_texture_mipmapping (same as real d3d9 -- except very very slow and the filter work differently -- ... hard to explain) dx9_texture_subloading (same as real d3d9) dx9_tokamak_chain (same as real d3d9 -- and impressive) dx9_transforms (same as real d3d9) dx9_vertex_data (same as real d3d9) --dx9_view_matrix !!!(???...could not find on site (dx8_view_matrix not dx9_view_matrix)...???)!!! dx9_view_ports (same as real d3d9 -- but does not resize) dx9_spot_light (the spot light does not look the same -- in fact the edges are sharp not smooth) dx9_texture (same as real d3d9) dx9_texture_addressing (... works on wined3d but not my real d3d9) dx9_primitive_types (same as real d3d9) dx9_point_light (same as real d3d9) dx9_dot3_bump_mapping (same as real d3d9) dx9_effect_simple (same as real d3d9) dx9_fonts (same as real d3d9) dx9_indexed_geometry (same as real d3d9) dx9_initialization (same as real d3d9) dx9_lighting (same as real d3d9) dx9_material (same as real d3d9) dx9_multitexture (same as real d3d9) dx9_offscreen_rendering (same as real d3d9) dx9_2d_demo_game (extremely SLOW -- animations?? unsure too slow (like 0.1 fps)) from http://triplebuffer.devmaster.net/tutorials.php BumpMapping (same as real d3d9) tb_dx9_03 (same as real d3d9) tb_dx9_04 (same as real d3d9) tb_dx9_05 (same as real d3d9) tb_dx9_06 (same as real d3d9) tb_dx9_07 (same as real d3d9) tb_dx9_08 (same as real d3d9) tb_dx9_09 (same as real d3d9) tb_dx9_10 (same as real d3d9) from http://www.clootie.ru/delphi/download_dx90.html#Direct3D Tut01_CreateDevice (same as real d3d9) Tut02_Vertices (same as real d3d9) Tut03_Matrices (same as real d3d9) Tut04_Lights (same as real d3d9) Tut05_Textures (same as real d3d9) Tut06_Meshes (same as real d3d9) cull (same as real d3d9 -- except SLOW VERY VERY SLOW but looks fine (180 fps -> 10 fps)) - additional tested demos mview (same as real d3d9 -- except cannot resize (crashes) -- and on windows98se (xp is fine) the top bar buttons and bottom status bar are covered by opengl gfx) 2DTestDX9 (same as real d3d9 -- except the 2d does not stretch on window resize (see top comment)) text3d (same as real d3d9 -- except for usability issues -- starts in fullscreen (cannot find windowed mode?) -- cannot press f2 (crashes)) ShadowVolume (same as real d3d9 -- except for usability issues -- starts in fullscreen (cannot find windowed mode?) -- cannot press f2 (crashes)) MultiDx (same as real d3d9 -- EXCEPT all panes draw the teapot on a 1bit buffer? -- and there are odd artifacts... hard to explain) DXCapsViewer (mode 0 -- 640x480xD3DFMT_X8R8G8B8 does not show up -- problem in mode iteration?) DxTex (runs but does not display -- will not run on my real d3d9) dx9_lost_device (same as real d3d9 -- except says texture object failed to clean up properly -- problem in texture/resource reference counting) dx9_resize_window (same as real d3d9 -- except says texture object failed to clean up properly -- problem in texture/resource reference counting) dx9_multiple_devices (start rendering in one window then just green...) dx9_swap_chains (both render in one window the other window is black -- this will induce seziure -- BEWARE) --- demos that were mean and nasty to me water (gets far -- near rendering -- but crashes)
RE: Looking for a good disassembler
OllyDbg is a good free binary disassembler/debugger
http://www.ollydbg.de/
Ida Pro is a very nice disassembler/debugger -- (its commerical but it there
is a free windows version)
http://www.datarescue.com/
http://www.datarescue.com/idabase/idadown.htm
W32Dasm is a decent (kinda old) disassembler/debugger -- is it still
commerical??
(look for a demo via google)
REC is an impressive free deCompiler (better than a simple disassembler)
its based off of boomarang http://boomerang.sourceforge.net/ (notice
http://www.program-transformation.org/Transform/DecompilationPossible ("Pigs
from Sausages?" hehe
http://www.dur.ac.uk/martin.ward/martin/papers/migration-t.pdf))
http://www.backerstreet.com/rec/rec.htm
I hope you find this helpful -- I have some other links up my sleves but
most are outdated and or commerical
Nick
d3d8 -> d3d9 -> wined3d? or d3d8 -> wined3d, d3d9 -> wined3d?
Ok simple question... should d3d8 be based off of d3d9 or wined3d? (or should it stay solo...) Since d3d9 is a fixed interface (d3d8 is basically a subset) and the fact that wined3d can change it could help maintenence in the long run mayhap? ...just a simple question... nothing major Nick
WineD3D glx -> wgl patch
I have made a patch to make wined3d use wgl instead of glx (tested under win98se gf4 4200 and winxp gffx 5500) and would like to extend it and see it into the wine tree. This patch also applies the d3d9patch.2005-06-13.diff (heavily modified due to changes in wine head). I can send the files (sources and binaries) (and patch) and test programs (d3d9 demos mainly), if interested. The patch is rather large (1.3 MB raw text) and I'm hesitant to simply post it. The dlls (d3d9.dll -> wined3d.dll -> cygwin1.dll) were compiled under cygwin. Most of the simple d3d9 demos work perfect (even supports window resizing kinda) But the more complex demos are giving me some trouble (crashing) I have not really had time to run real games under this... Also I deactivated all the debugging stuff for windows/cygwin compiles (it gave lots of problems) --I will be looking into this soon
