wine-devel September 2008

wine-devel@winehq.org

116 participants
274 discussions

Re: [PATCH 6/7] d3dx9/tests: Test D3DXCheckTextureRequirements.
by Henri Verbeet 19 Sep '08

19 Sep '08

2008/9/19 Philip Nilsson <pnilsson(a)nullref.se>: > This one could use some more work, but I think the tests will pass in > most cases (except in strange environments without support for common > formats). > The tests should pass everywhere. I think you should be testing for consistency between CheckDeviceFormat() and D3DXCheckTextureRequirements().

2 1

Re: [PATCH 7/7] d3dx9/tests: Test D3DXCreateTexture.
by Henri Verbeet 19 Sep '08

19 Sep '08

I think it would be a good idea to test the parameters (format, width, height, miplevels) of the created texture.

2 1

Re: [PATCH 3/7] d3dx9: Implement D3DXCheckTextureRequirements.
by Henri Verbeet 19 Sep '08

19 Sep '08

2008/9/19 Philip Nilsson <pnilsson(a)nullref.se>: > + hr = IDirect3DDevice9_GetDirect3D(device, &d3d9); > + if (hr != D3D_OK || !device) > + return D3DERR_INVALIDCALL; > + > + IDirect3D9_GetAdapterDisplayMode(d3d9, D3DADAPTER_DEFAULT, &d3ddm); > + > + /* TODO: Use something more advanced that looks more like what's in MSDN. */ > + hr = IDirect3D9_CheckDeviceFormat(d3d9, D3DADAPTER_DEFAULT, D3DDEVTYPE_HAL, d3ddm.Format, usage, D3DRTYPE_TEXTURE, *format); You shouldn't guess the adapter, device type, etc., but use whatever the device was created with. IDirect3DDevice9_GetCreationParameters() should help there. > + if (hr != D3D_OK) { > + if (usage & D3DUSAGE_DEPTHSTENCIL) { > + switch (*format) { ... > + } > + IDirect3D9_Release(d3d9); > + } I'm not sure about the big switch statement there, but I do know that just changing the format isn't enough. There's no guarantee the new format will work, or if there is any format that will support that specific set of usage flags at all.

2 1

Re: [PATCH 4/7] d3dx9: Add a D3DXCreateTexture stub.
by Henri Verbeet 19 Sep '08

19 Sep '08

2008/9/19 Philip Nilsson <pnilsson(a)nullref.se>: > + if (ret != D3D_OK) > + return ret; > + > + return D3D_OK; This doesn't really make sense.

1 0

Re: PrintDlgEx [1/7]: Add common failure checks and a trace.
by Juan Lang 19 Sep '08

19 Sep '08

Hi Gal, + * This function is necessary in order to match the behaviour on + * Windows, which seems to do all these checks when PrintDlgEx + * is called. It is also necessary in order to replicate a bug in + * PrintDlgExA, where S_OK is returned for invalid DevMode or DevNames. A test case would be a lot nicer than a comment. --Juan

2 2

Re: PrintDlgEx [1/7]: Add common failure checks and a trace.
by Vitaly Lipatov 19 Sep '08

19 Sep '08

What about move printdlgex related code in standalone file printdlgex.c? Is it possible? I see printdlg.c too large already. В сообщении от 18 сентября 2008 Gal Topper написал(a): > Changes since last attempt: > 1) Added a comment to explain the rationale behind the CommonChecks > function. 2) Resources and header are no longer in separate patches. > Instead, they are added along with the code that requires them. > 3) Some unused elements are no longer added in this patch-set. -- Vitaly Lipatov, ALT Linux Team Russia, Saint-Petersburg, www.etersoft.ru

2 1

RE: Drawprim.c patch
by Stefan Dösinger 18 Sep '08

18 Sep '08

It is getting better, but still not correct. Look at how the diffuse and specular colors are handled, and create a call table texcoord_funcs to handle the different types. > -----Original Message----- > From: wine-patches-bounces(a)winehq.org [mailto:wine-patches- > bounces(a)winehq.org] On Behalf Of Chris Ahrendt > Sent: Thursday, September 18, 2008 7:58 AM > To: wine-patches(a)winehq.org > Subject: Drawprim.c patch > > This is a redo of my drawprim patch > > > Chris

2 1

Taking advantage of debug libraries
by Markus Hitter 18 Sep '08

18 Sep '08

Hello all, now, as I get better and better on juggling with the various debugger options, I'm at a point where I'd like to get advantage of MS' C++ runtime debug libraries. Looking at MSDN, they recommend to turn a few switches in the IDE and ... but this won't work, as I can't re-link my binary. Looking at what my app does, it obviously looks for mfc70.dll and is satisfied with getting mfc80.dll. To a Unix guy like me this looks weird. All Visual C++ distributions I could have a look at come with mfc42* libraries, no matter how recent the IDE distro is. So I've put this into C:/windows/system and hoped for even more magic - but it didn't happen. Still segment names only in winedbg. My question is: is it possible to take advantage of the mfc42d.dll/ mfc42d.map/mfc42d.pdb file trio to get debug symbols in winedbg? Or perhaps even in generic gdb? If yes, where would I put these files or how would I load their tables into the debugger? Thanks, MarKus - - - - - - - - - - - - - - - - - - - Dipl. Ing. Markus Hitter http://www.jump-ing.de/

2 1

Re: d3dx9: Include d3dx9effect.h
by Tony Wasserka 18 Sep '08

18 Sep '08

Hi, one very little thing: You could include d3dx9.h (from d3dx9effect.h) after the #define __D3DX9EFFECT_H__, as this reduces compile time slightly when included twice or more. No actual reason to resend though, just an advice for future. Best regards, Tony

1 0

Re: d3dx9: Implement D3DXMatrixAffineTransformation2D with tests
by Tony Wasserka 18 Sep '08

18 Sep '08

Hi, you forgot the WINAPI in front of the function declaration and implementation. Maybe you should add a set_mat(_11, _12, _13, ....) macro to make the exp_mat better to read and not that big in size, However, I think it's better to dynamically calculate the expected matrix rather than compare it to hard-coded values (I'm not sure about that one though, it's just what _I_ would do). It would at least make the whole thing easier be adopted to new tests (of the same function with different values). Best regards, Tony

1 0

← Newer
1
...
7
8
9
10
11
12
13
...
28
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel September 2008