On Sun, Sep 23, 2012 at 10:40 PM, Ričardas Barkauskas
wrote:
> +struct refresh_rates refresh_list[] =
> +{
> +{60, 60, FALSE, FALSE},
> +{60, 0, TRUE, FALSE},
> +{60, 1, TRUE, TRUE},
> +{ 0, 60, TRUE, FALSE},
> +{ 0, 0, TRUE, FALSE},
> +};
It's probably better to decl
Hi,
On Sun, Sep 23, 2012 at 8:44 PM, Christian Costa wrote:
> +hr = IDirect3DTexture9_LockRect(texture, 0, &lock_rect, NULL,
> D3DLOCK_READONLY);
> +ok(hr == D3D_OK, "IDirect3DTexture9_LockTexture returned %#x,
> expected %#x\n", hr, D3D_OK);
> +if (SUCCEEDED(hr))
> +
s might
> be the way it works on windows. Has anyone a technical argument against
> this solution?
>
It seems fine to me. A program compiled without *LARGEADDRESSAWARE* should
get all the memory allocated below the 2 GB limit (see
http://msdn.microsoft.com/en-us/library/windows/desktop/aa384271%28v=vs.85%29.aspx
).
--
Józef Kucia
> and I did not had time to sort those out, yet.
>
Thanks for notifying me. I was about to write some tests for structures in
constant tables. I see that you've already written such tests.
Cheers,
Józef Kucia
On Thu, Jun 28, 2012 at 2:27 PM, Matteo Bruni wrote:
> I'm not quite sure of the right and bottom misalignment checks. If the
> tests confirm that, of course that's okay.
>
Native accepts misaligned boxes, but in order to implement it S3TC
decompressor and compressor is needed. I'll make it a FIX
I've also added a tests for this pixel format in the patch, which was
submitted yesterday:
http://www.winehq.org/pipermail/wine-patches/2012-June/115268.html
On Tue, May 29, 2012 at 12:29 PM, Dmitry Timoshkov wrote:
> Józef Kucia wrote:
>> A stream can grow its memory. For example, IStream returned by
>> CreateStreamOnHGlobal do this.
>
> I don't think you need to worry about that unless you have a test case
> or an app
On Tue, May 29, 2012 at 12:07 PM, Dmitry Timoshkov wrote:
> What prevents you from discovering correct stream size?
A stream can grow its memory. For example, IStream returned by
CreateStreamOnHGlobal do this.
On Wed, May 2, 2012 at 2:55 PM, Józef Kucia wrote:
> ---
> dlls/d3dx9_36/surface.c | 24
> 1 files changed, 20 insertions(+), 4 deletions(-)
>
> diff --git a/dlls/d3dx9_36/surface.c b/dlls/d3dx9_36/surface.c
> index 44d4e06..70627fd 100644
>
On Thu, May 10, 2012 at 8:39 PM, Stefan Dösinger wrote:
> Since I've burned my hands with DDSURFACEDESC2 pitch handling in the past(e.g.
> bug 21238), I highly recommend to test it. Knowing msdn, the above page makes
> me less confident, not more :-\
>
> The most likely situation where an error oc
On Wed, May 9, 2012 at 11:32 PM, Józef Kucia wrote:
> diff --git a/dlls/d3dx9_36/tests/surface.c b/dlls/d3dx9_36/tests/surface.c
> index ab56593..3d5a50f 100644
> --- a/dlls/d3dx9_36/tests/surface.c
> +++ b/dlls/d3dx9_36/tests/surface.c
> @@ -917,6 +917,20
On Thu, May 10, 2012 at 4:27 PM, Matteo Bruni wrote:
> It looks like you're not actually using the faces variable.
Thanks. I should multiply expected_size by faces.
On Thu, May 10, 2012 at 4:29 PM, Matteo Bruni wrote:
> 2012/5/9 Józef Kucia :
>> ---
>> +HRESULT load_texture_from_dds(IDirect3DTexture9 *texture, const void
>> *src_data, UINT srd_data_size,
>> + const PALETTEENTRY *palette, DWORD filter, D3DCOLOR color_ke
On Thu, May 10, 2012 at 4:28 PM, Matteo Bruni wrote:
> 2012/5/9 Józef Kucia :
>> + if ((caps.Caps2 & D3DCAPS2_DYNAMICTEXTURES) && (pool !=
>> D3DPOOL_DEFAULT) && (usage != D3DUSAGE_DYNAMIC))
>> + {
>> + hr = D3DXCreateCubeTexture(de
On Thu, May 10, 2012 at 4:25 PM, Matteo Bruni wrote:
> I guess it would make sense to add all the new pixel formats to the
> table, assuming it doesn't break the tests or other stuff.
Luminance pixel formats could be added, but I'm not sure about
BUMPDUDV pixel formats. For BUMPDUDV pixel formats
On Thu, May 10, 2012 at 11:16 AM, Stefan Dösinger
wrote:
> Am Mittwoch, 9. Mai 2012, 23:32:10 schrieb Józef Kucia:
>> +#define check_pixel_3bpp(lockrect, x, y, color) \
>> +ok(((BYTE*)(lockrect).pBits)[3 * (x) + (y) * (lockrect).Pitch + 0] ==
>> ...
> Inline functions are
On Thu, May 10, 2012 at 10:32 AM, Stefan Dösinger
wrote:
> Am Mittwoch, 9. Mai 2012, 23:32:05 schrieb Józef Kucia:
>> + *pitch = width * format_desc->bytes_per_pixel;
>> + *size = *pitch * height;
> Usually surface pitches are either 4 or 8 byte aligned(depen
Thanks for the review.
On Thu, May 3, 2012 at 1:08 PM, Henri Verbeet wrote:
>> + memcpy(&wic_pixel_format, pixel_format_guid, sizeof(GUID));
>> + hr = IWICBitmapFrameEncode_SetPixelFormat(frame, &wic_pixel_format);
>> + d3d_pixel_format = wic_guid_to_d3dformat(&wic_pixel_format);
> What
eateCubeTextureFromFile functions at the end
of June. Naturally, I don't mind adding forwards if you need them.
--
Józef Kucia
On Wed, May 2, 2012 at 6:04 PM, Stefan Dösinger wrote:
> It looks like patch 2 is missing
It's weird. I've got all five patches in sent mails.
On Thu, Apr 26, 2012 at 9:50 PM, Stefan Dösinger wrote:
> Am Donnerstag, 26. April 2012, 11:47:51 schrieb Józef Kucia:
>> + DWORD pitch_or_linear_size;
> Are you aware that lPitch is a (signed) LONG in the original DDSURFACEDESC
> structure? Honestly I have no idea why, and I
On Thu, Apr 26, 2012 at 12:04 PM, Henri Verbeet wrote:
> Is there no header that should define these?
These structures and defines seem to be defined only in a D3D sample
"DDS without D3DX".
On Thu, Apr 19, 2012 at 9:22 PM, Stefan Dösinger wrote:
> Am Donnerstag, 19. April 2012, 20:23:36 schrieb Matteo Bruni:
>> I'm not sure that's a good idea. ddraw.h is not included in recent
>> DirectX SDKs and the relevant definitions are "gone", as far as I
>> know. So I think d3dx9 or its tests
On Thu, Apr 19, 2012 at 8:23 PM, Matteo Bruni wrote:
> Il 19 aprile 2012 19:37, Józef Kucia ha scritto:
>> ---
>> dlls/d3dx9_36/tests/surface.c | 65
>> +
>> 1 files changed, 65 insertions(+), 0 deletions(-)
>>
&g
On Fri, Apr 6, 2012 at 4:31 PM, Andrew Eikum wrote:
> Thanks. GCC 4.7 must be smart enough to detect the same if-conditions,
> and doesn't issue a warning for me. Kind of impressive, actually.
>
> Andrew
>
GCC 4.5 wasn't that smart yet.
--
Józef Kucia
obably shouldn't
touch *mesh when the function fails.
--
Józef Kucia
On Wed, Mar 21, 2012 at 1:04 AM, Matteo Bruni wrote:
> Il 20 marzo 2012 19:12, Christian Costa ha scritto:
>>> * Implement D3DXCreateCubeTextureFrom* and
>>> D3DXCreateVolumeTextureFrom* functions.
>
> That depends on the DDS file format support, I guess.
>
Yes, it could be a part of my GSoC pro
On Tue, Mar 20, 2012 at 7:12 PM, Christian Costa wrote:
> Hi Józef,
>
> There are some work already done by Tony Wasserka which didn't get in git:
> http://repo.or.cz/w/wine/d3dx9TW.git
>
> DDS support has been added in this patch:
> http://repo.or.cz/w/wine/d3dx9TW.git/commitdiff/f7fd4619de1cd0ea
yes, I'm aware about
http://wiki.winehq.org/DirectX-D3DX9).
Cheers,
Józef Kucia
Please forget this patch. It's superseded by another.
On Thu, Mar 15, 2012 at 12:55 PM, Matteo Bruni wrote:
> So, I guess this change will only have any effect on non-standard
> complying sources, and in the specific case of asm-style comments, it
> brings us the behavior we want. On the other hand, it also actually
> turns an error (unexpected end o
On Tue, Mar 13, 2012 at 1:22 PM, Matteo Bruni wrote:
> That is bug http://bugs.winehq.org/show_bug.cgi?id=24614. My shot at
> it was http://www.winehq.org/pipermail/wine-patches/2011-February/098609.html.
> You can see that my approach was essentially what you are suggesting.
> Still, that's not a
On Mon, Mar 12, 2012 at 11:31 PM, Stefan Dösinger wrote:
> My first guess would be to see how other users of wpp are behaving, or are
> supposed to behave. grep claims that the other parts of Wine that use wpp are
> toold/widl and tools/wrc. Beyond those it's probably a good idea to keep HLSL
> in
p behavior for strings passing the
end of line to mimic the behavior observed on Windows. Perhaps,
strings passing the end of line could be treated as an error by
default. Whereas D3DCompiler would activate an option to treat such
strings as a warning.
Thanks,
Józef Kucia
Hi,
My name is Józef Kucia. I'm a Masters student in Computer Science at
Wrocław University of Technology in Poland. I would like to apply for
Google Summer of Code this year.
I have a good knowledge of C and OpenGL. I also have limited
experience with Direct3D and win32 programming.
With r
35 matches
Mail list logo
