February 2010 - Wine-devel - list.winehq.org

Re: d3dx9: Implement point filtering of ARGB surface data in D3DXLoadSurfaceFromMemory
by Henri Verbeet 01 Feb '10

01 Feb '10

On 31 January 2010 13:00, Tony Wasserka <tony.wasserka(a)freenet.de> wrote: > - the other filters basically do the same, but the end effect looks > nice, so we can fallback to point filtering for linear, triangle and box > filters for now. > - apparently, D3DERR_INVALIDCALL gets returned if the specified > destination rect exceeds the actual surface boundaries > It looks like this patch is doing a couple of different things, you should probably split it up.

1 0

Re: [3/5] d3d9: Test buffer lock flags (try 2)
by Henri Verbeet 01 Feb '10

01 Feb '10

On 30 January 2010 12:38, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > +static HMODULE d3d9_handle = 0; That's still redundant. Note that the variable doesn't have to be static in the first place though, you can just pass it to init_d3d9().

1 0

Re: [2/5] WineD3D: Implement dynamic buffers with GL_ARB_map_buffer_range
by Henri Verbeet 01 Feb '10

01 Feb '10

On 30 January 2010 12:37, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > + const struct wined3d_gl_info *gl_info = &device->adapter->gl_info; I think you should retrieve gl_info from the context where possible.

1 0

Re: [1/5] WineD3D: Add GL_ARB_map_buffer_range
by Henri Verbeet 01 Feb '10

01 Feb '10

On 30 January 2010 12:35, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > +/* GL_ARB_map_buffer_range */ > +#ifndef GL_ARB_map_buffer_range > +#define GL_ARB_map_buffer_range > +typedef GLvoid *(WINE_GLAPI *PGLFNMAPBUFFERRANGE)(GLenum target, GLintptr offset, GLsizeiptr length, GLbitfield access); > +typedef void (WINE_GLAPI *PGLFNFLUSHMAPPEDBUFFERRANGE)(GLenum target, GLintptr offset, GLsizeiptr length); > +#define GL_MAP_READ_BIT 0x0001 > +#define GL_MAP_WRITE_BIT 0x0002 > +#define GL_MAP_INVALIDATE_RANGE_BIT 0x0004 > +#define GL_MAP_INVALIDATE_BUFFER_BIT 0x0008 > +#define GL_MAP_FLUSH_EXPLICIT_BIT 0x0010 > +#define GL_MAP_UNSYNCHRONIZED_BIT 0x0020 > +#endif Please keep these definitions consistent with the rest of the file, I just fixed all of them.

1 0

Re: dwmapi: add a stub for DwmDefWindowProc
by Reece Dunn 01 Feb '10

01 Feb '10

On 1 February 2010 04:35, Austin English <austinenglish(a)gmail.com> wrote: + BOOL WINAPI DwmDefWindowProc(HWND hwnd, UINT msg, WPARAM wParam, LPARAM lParam, LRESULT *plResult) Minor nitpick here -- there is a space before the BOOL return type. +{ + FIXME("(%p, %d, %p, %p, %p ) stub\n", hwnd, msg); + + return E_NOTIMPL; But more importantly, you are returning a HRESULT instead of a BOOL return value. MSDN (http://msdn.microsoft.com/en-us/library/aa969507%28VS.85%29.aspx) says that it is a BOOL and should return FALSE if the message was not handled. - Reece

2 1

Re: wined3d: Add newer ATI/AMD cards vendor recognition
by Stefan Dösinger 01 Feb '10

01 Feb '10

Am 31.01.2010 um 14:59 schrieb Luca Bennati: > As seen in bug #21515, newer ATI cards used with radeon open driver return a GL_VENDOR string not present in wined3d_guess_vendor(). > This oneliner merely adds that so that the function return VENDOR_MESA instead of VENDOR_WINE that could make apps crash. > <0001-wined3d-Add-newer-ATI-AMD-cards-vendor-recognition.txt> I think VENDOR_ATI would be better here. VENDOR_MESA is later replaced with VENDOR_NVIDIA and a generic NVIDIA card is found. Besides this we should make sure that intel cards driven by the mesa driver are always reported as VENDOR_INTEL, and older ATI cards with the r200 and r300 driver are reported as VENDOR_ATI as well. Obviously we'll also need a function to roughly match the Rxyz GPU IDs to card PCI IDs. Can you post a backtrace of an app crashing due to VENDOR_WINE? Such an app would be pretty buggy, or we're not watching out properly in wined3d somewhere.

1 0