2011/6/18 Charles Welton :
> ---
> dlls/d3dx9_36/tests/line.c | 23 +++
> 1 files changed, 23 insertions(+), 0 deletions(-)
>
> +srand(time(NULL));
> +random = ((FLOAT) rand())/RAND_MAX; /* Random value between 0.0 and 1.0.
> We're using this later. */
I didn't chec
2011/6/16 Charles Welton :
>
> +IDirect3DDevice9_Release(return_device);
> +ID3DXLine_Release(line);
You could add a couple of ok() checks for the values returned by
Release, to ensure nothing strange is happening.
Btw, thanks for contributing. :)
2011/6/16 Charles Welton :
>
> @@ -27,6 +27,8 @@ static const struct ID3DXLineVtbl ID3DXLine_Vtbl;
> typedef struct ID3DXLineImpl {
> ID3DXLine ID3DXLine_iface;
> LONG ref;
> +
> +IDirect3DDevice9 * device;
> } ID3DXLineImpl;
You also have to Release() the device in ID3DXLineImpl_R
2011/6/7 Henri Verbeet :
> On 7 June 2011 14:39, Matteo Bruni wrote:
>>> Well, it may be, but the instruction we care about here is texldl. I
>>> could of course add a usestexldl condition, but afaik there isn't any
>>> reason not to enable ARB_s
2011/6/7 Henri Verbeet :
> On 7 June 2011 11:16, Stefan Dösinger wrote:
>> On Tuesday 07 June 2011 11:06:25 Henri Verbeet wrote:
>>> - if (gl_info->supported[ARB_SHADER_TEXTURE_LOD] &&
>>> reg_maps->usestexldd)
>> Why is reg_maps->usestexldd not true in pixel shaders?
>>
> Well, it may be, but
2011/6/6 Stefan Dösinger :
...
> Furthermore, Matteo says that not calling context_apply_draw_buffers every
> time framebuffer() is run is a noticeable performance improvement too. Matteo,
> did you test this with just patch 0005, or both 0005 and 0006?
>
Actually that was with your FBO dirty pat
2011/5/30 Michael Mc Donnell :
> Thanks for the comments Matteo! I have a few questions below.
>
> On Mon, May 30, 2011 at 2:45 PM, Matteo Bruni
> wrote:
>> 2011/5/29 Michael Mc Donnell :
>>> On Sat, May 28, 2011 at 10:08 PM, Stefan Dösinger
>>> wrote:
>&
2011/5/29 Michael Mc Donnell :
> On Sat, May 28, 2011 at 10:08 PM, Stefan Dösinger
> wrote:
>> On Saturday 28 May 2011 19:55:55 you wrote:
>>
>>> It was implemented by setting the vertex declaration to null when the
>>> declaration is invalid. That seems to match what happens on Windows,
>>> becau
2011/5/24 Dylan Smith :
> ---
> dlls/d3dx9_36/mesh.c | 117 +++--
> 1 files changed, 112 insertions(+), 5 deletions(-)
>
> diff --git a/dlls/d3dx9_36/mesh.c b/dlls/d3dx9_36/mesh.c
> index fa32797..20b3262 100644
> --- a/dlls/d3dx9_36/mesh.c
> +++ b/dlls
2011/5/8 Dylan Smith :
> On Sun, May 8, 2011 at 3:18 PM, Matteo Bruni
> wrote:
>>
>> 2011/5/6 Dylan Smith :
>> > +struct vertex_attrib_duplication {
>> > + DWORD attrib;
>> > + DWORD vertex_index;
>> > + struct vertex_attrib_dupl
2011/5/6 Dylan Smith :
> +struct vertex_attrib_duplication {
> + DWORD attrib;
> + DWORD vertex_index;
> + struct vertex_attrib_duplication *ptr;
> +};
...
> + struct vertex_attrib_duplication **heads = NULL; /* head of list
> for each vertex */
You probably want to use Wine l
2011/5/6 Dylan Smith :
...
> + new_vertex_buffer_size = This->numvertices;
...
> + new_vertex_buffer_size *= vertex_size;
> + hr = IDirect3DDevice9_CreateVertexBuffer(This->device,
> new_vertex_buffer_size,
> + vertex_desc.Usage, This->fvf, vertex_desc.Pool,
>
2011/5/6 Dylan Smith :
> ---
Just a couple of nitpicks:
> + This->vertex_buffer->lpVtbl->AddRef(This->vertex_buffer);
You should probably use the macros where they are around (D3D9 objects
have them, as opposed to the mesh objects which don't for some strange
reason).
> + CopyMemo
2011/4/29 Stefan Dösinger :
>> + shader_addline(buffer, "TEMP TB;\n");
> Which shader instruction uses this? Afair vertex shaders should only use TA,
> but there's no proper infrastructure that manages that.
>
AFAICS, TB could get used in shader_hw_pow():
...
shader_arb_get_src_param(ins,
Actually, this patch seems to break Bioshock with UseGLSL=disabled.
Please drop/revert this one for the time being...
2011/4/26 Nicolas Le Cam :
> msdn tells us to use 0 to disable colorkey [1]. Let me know if you
> think it isn't the correct things to do.
>
> [1] http://msdn.microsoft.com/en-us/library/bb172902%28v=vs.85%29.aspx
>
> --
> Nicolas Le Cam
>
Argh, this was already spotted by Gerald Pfeifer some time
On Sat, 2011-04-02 at 23:54 +0200, Gerald Pfeifer wrote:
> Matteo et al,
>
> there is some code in dlls/d3dx9_36/surface.c which GCC struggles with
> (in the sense of warning about it), and so do I, so I am wondering whether
> you can have a look?
>
> Specifically, in point_filter_simple_data we
2011/3/31 David Adam :
>
>
> 2011/3/31 Matteo Bruni
>>
>> 2011/3/31 David Adam :
>> >
>> > + /* Check the width */
>> > + v1 = *((D3DXVECTOR3*)(data+19*num_bytes_per_vertex));
>> > + v2 = *((D3DXVECTOR3*)(data+18*num_
2011/3/31 David Adam :
>
> + /* Check the width */
> +v1 = *((D3DXVECTOR3*)(data+19*num_bytes_per_vertex));
> +v2 = *((D3DXVECTOR3*)(data+18*num_bytes_per_vertex));
> +length = D3DXVec3Length(D3DXVec3Subtract(&v2,&v1,&v2));
> +ok(fabs(length-10.0f) received %f\n
e or any other field in the physDev doesn't
seem to be really better. I'm not sure about the feasibility of
handling that on the gdi32 side, I think I gave it a try at some point
but then I resorted to this other approach. But, of course, I may be
failing to see a better solution ;)
> Roderick
>
> On Tue, Mar 29, 2011 at 7:42 AM, Matteo Bruni
> wrote:
>>
, but in general, failing on a
destroyed drawable was the only consistent "edge case" behavior I
found.
>
> On Tue, Mar 29, 2011 at 7:42 AM, Matteo Bruni
> wrote:
>>
>>
>>
>>
>>
>
Most of the objections from the previous try still stand: check your
whitespaces (whitespace after every comma, whitespaces around
operators, whitespace after "if" or "for" keywords), you have to be
consistent. Comparing indices doesn't make much sense now that you
don't check vertices, I think you
rdering of the vertices for D3DXCreateBox. Did I miss
> anything?
>
> A+
>
> David
>
> 2011/3/9 Matteo Bruni
>>
>> 2011/3/9 David Adam :
>> > Hello,
>> >
>> > is there any problem with my d3dxcreatebox patch?
>> >
>&
2011/3/9 David Adam :
> Hello,
>
> is there any problem with my d3dxcreatebox patch?
>
> Thanks in advance for any feedback.
>
> A+
>
> David
>
Do you refer to http://source.winehq.org/patches/data/71983 ? I just
had a cursory look at it: I presume there isn't anything fundamentally
broken with yo
2011/2/23 Amine Khaldi :
> CID 1585.
>
> Regards,
> Amine.
>
This doesn't seem to be the correct fix. With that break you aren't
going to return any string and that will cause problems thereafter.
You should replace the "case 2:" with "default:" instead (like
BWRITERSPR_RASTOUT some rows above).
2011/2/16 Misha Koshelev :
> Dear All:
>
> Looking at d3dx9 bugs, bug 24899 requires D3DXCreateRenderToSurface.
>
> This, somewhat barebones, patch, implements core functionality of
> D3DXCreateRenderToSurface, along with a barebones ID3DXRenderToSurface
> implementation.
>
> I was wondering, in or
2011/2/14 :
> Hi Stefan, thanks for your answer. I've checked the nvidia texture tools
> but, sadly, I think it's impossible to use them in wine: while they have c
> bindings, those bindings lack the essential function
> nvttSetOutputOptionsOutputHandler(NvttOutputOptions * outputOptions,
> nvttOu
2011/2/9 Travis Athougies :
>
> On Feb 8, 2011, at 4:10 AM, Matteo Bruni wrote:
>
>>> + /* We need the for loop, since we need to convert the integer to
>>> a float */
>>> + for (i = 0; i < count && i < desc.RegisterCount; i++)
&
hr = IDirect3DTexture9_GetLevelDesc(texture, 0, &desc);
+ok(hr == D3D_OK, "D3DXCreateTexture returned %#x, expected
%#x\n", hr, D3D_OK);
Copy-paste error, it should be GetLevelDesc in the ok() message. :)
> + if (is_vertex_shader(This->desc.Version))
> + IDirect3DDevice9_SetVertexShaderConstantF(device,
> desc.RegisterIndex + i, (float *)fvector,
> + desc.RegisterCount);
You should probably just use 1 instead of desc.RegisterCount in
SetVertexShader
> + /* We need the for loop, since we need to convert the integer to a
> float */
> + for (i = 0; i < count && i < desc.RegisterCount; i++)
> + {
> + row[0] = (float)n[i];
The cast is unneeded, and the comment above is too.
2011/1/31 Stefan Dösinger :
> Am 31.01.2011 um 17:08 schrieb Matteo Bruni:
>> The attached patch should follow your idea, does it look right? FWIW,
>> I can't see any 1-pixel offset in The Sims 3 with this patch. Yes, I
>> know that's not how it should be tested...
2011/1/31 Stefan Dösinger :
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
>
> Am 31.01.2011 um 15:57 schrieb Henri Verbeet:
>
>> On 31 January 2011 15:45, Stefan Dösinger wrote:
>>>
>>> If we change the shader code to write gl_ClipVertex and result.clip before
>>> applying the y inversion t
2011/1/21 Michael Stefaniuc :
> On 01/21/2011 06:56 AM, Travis Athougies wrote:
>> On Thu, Jan 20, 2011 at 7:27 AM, Matteo Bruni
>> wrote:
>>>
>>> 2011/1/20 Travis Athougies:
>>>>
>>>> +/* D3DXMATRIX is a union, one of whos
2011/1/20 Travis Athougies :
> +static void test_setting_basic_table(IDirect3DDevice9 *device)
> +{
> + static const D3DXMATRIX mvp = {
> + 0.514f, 0.626f, 0.804f, 0.786f,
> + 0.238f, 0.956f, 0.374f, 0.483f,
> + 0.109f, 0.586f, 0.900f, 0.255f,
> + 0.898f, 0.411f, 0.93
2011/1/20 Travis Athougies :
> + /* D3DXMATRIX is a union, one of whose elements is an array, so
> it can be cast to a float pointer */
> + if (is_vertex_shader(This->desc.Version))
> + IDirect3DDevice9_SetVertexShaderConstantF(device,
> desc.RegisterIndex + i,
2010/12/30 Dan Kegel :
> Yegor wrote:
>> it's my first contribution to wine...
>
> Welcome!
>
>> so I wanted to start with some simple task.
>
> Changing memory allocation might not be simple.
>
> Your patch touches two different DLLs.
> You should probably split this patch up, one patch per dll.
>
2010/11/23 Stefan Dösinger :
> Am Dienstag 23 November 2010, 16:52:09 schrieb Henri Verbeet:
>> Looks like a flaw in the d3dx9_36 test, it isn't taking the POW2 cap
>> into account. I would have expected that to fail the other way around
>> though, cards that can't do npot textures should be pretty
> -L'etichetta che è l'obiettivo di un GOTO può essere lunga fino a 255
> caratteri\n\
> +L'etichetta che è la destinazione di un GOTO può essere lunga fino a 255
> caratteri\n\
I believe this sentence as a whole sounds quite awkward. Maybe
something like "Un'etichetta che sia destinazione di un
2010/10/19 Joris Huizer :
> Hello,
>
> In this patch ID3DXSpriteImpl_Flush is adapted; the new loop being like:
>
> int i, count, start;
> /* ... */
> for(start=0;startsprite_count;start+=count,count=0) {
> i=start;
> while(isprite_count &&
> (count==0 ||
> Thi
2010/10/11 Henri Verbeet :
> On 8 October 2010 16:32, Matteo Bruni wrote:
>> This patch changes D3DXPlaneNormalize to behave as native on 64 bits,
>> returning infinity in the fourth plane component when the norm is 0.
>> If this is not appropriate, I can resend witho
2010/8/18 Gerald Pfeifer :
> Metteo et al,
>
> I noticed d3dx9_36/bytecodewriter.c can be simplified as follows, but
> somewhat tells me this may rather point out a problem somewhere in that
> code, so I am not sending this to wine-patches.
>
> (The only functional difference should be the missing
2010/7/27 Henri Verbeet :
> On 27 July 2010 16:37, Matteo Bruni wrote:
>> Yes, this is the best time I believe. Some time ago there was
>> agreement to implement the shader compiler in d3dcompiler, with the
>> d3dx9/d3d10/d3dx10 compiler function calls forwarding to d3dcom
2010/7/27 Henri Verbeet :
> On 26 July 2010 21:21, Matteo Bruni wrote:
>> // ID3D10Blob has been made version-neutral and moved to d3dcommon.h.
>>
> Actually, since this comes up now, perhaps this is a good time to
> think about implementing d3dcompiler and d3dx10? I think w
Hello Rico,
from d3d10misc.h of latest DirectX SDK:
// ID3D10Blob has been made version-neutral and moved to d3dcommon.h.
d3dcommon.h seems to be an idl-generated header. From what I can see
up to now, only your first patch is "wrong", the rest just needs to be
fixed to include d3dcommon.h where
2010/7/6 Misha Koshelev :
> Oops good thing I did not yet figure out how to use a native d3dx9_36 then
> so no compromise of my ability to contribute.
>
> Just to clarify then... I may NOT use wine to monitor calls within a native
> DLL? Specifically, I may not determine what parameters one native
2010/7/6 Misha Koshelev :
> Thank you for the well wishes James and Dan. Will def keep the test bot in
> mind.
Unfortunately no WineTestBot machine has any d3dx9_xx.dll installed
(or so it was last time I checked), so no luck there. I don't know if
it's possible to install the latest DirectX SDK t
2010/6/10 Stefan Dösinger :
>
> Am 10.06.2010 um 16:06 schrieb Matteo Bruni:
>> <0001-d3dx9-Allow-sampler-declaration-without-sampler-type.txt>
> The patch looks ok, but I am wondering if the validator complains about
> typeless samplers. And if not, I guess the interesti
2010/5/31 Luca Bennati :
>
>
> 2010/5/31 Matteo Bruni
>>
>> > - LTEXT "File di &Tipo:", 1089, 6, 104, 90, 9
>> > + LTEXT "&Tippo del file:", 1089, 6, 104, 90, 9
>>
>> One 'p' is enough :). More importantly, this a
> - LTEXT "File di &Tipo:", 1089, 6, 104, 90, 9
> + LTEXT "&Tippo del file:", 1089, 6, 104, 90, 9
One 'p' is enough :). More importantly, this and the shell32 patch
have mangled accented letters (maybe the conversion to UTF8 didn't
work out well?). No problems in the taskmgr patch though.
By the
2010/5/19 Stefan Dösinger :
>
> Am 18.05.2010 um 14:55 schrieb Matteo Bruni:
>> + if(!check_reg_type(src, vs_3_reg_allowed)) {
>> + asmparser_message(This, "Line %u: Source register %s not supported
>> in VS 3.0\n",
>>
> dlls/wineshader doesn't exist in that tree?
>
Check if you are in the correct branch (should be the "compiler"
branch in his tree).
>> Lastly, a bit on testing the compiler. I'm not sure trying to get
>> exactly the same bytecode as native is a feasible objective: while for
>> an assembler prog
2010/4/14 Matijn Woudt :
> On Wed, Apr 14, 2010 at 4:27 PM, Stefan Dösinger
> wrote:
>>
>> Am 14.04.2010 um 15:44 schrieb Henri Verbeet:
>>
>>> On 14 April 2010 15:07, Stefan Dösinger wrote:
> 3) Implement the compiler in d3dcompiler_xx.
I wrote a basic HLSL compiler as university proje
2010/3/30 Juan Lang :
> Hi Matteo, just wanted to congratulate you on getting your
> DRDXAssembleShader patches accepted. I know it can take a fair amount
> of persistence to get something substantial committed, and it seems
> that many lack the patience. Well done!
> --Juan
>
Thank you very muc
2010/2/8 Stefan Dösinger :
>
> Am 08.02.2010 um 16:33 schrieb Matteo Bruni:
>
>> Other than the things Henri last mentioned, there are some more small
>> changes (make some struct const/static, whitespace fixes, remove some
>> useless cruft, ...) particularly in patc
Seems like I'm unable to review my code...
>
>> + if(desc->pos + len > desc->size) len = desc->size - desc->pos;
> It's usually safer to write expressions like that as "if (len >
> desc->size - desc->pos)" because "desc->pos + len" can wrap around if
> len is large, while "desc->size - desc->po
2010/1/28 Stefan Dösinger :
> On Wednesday 27 January 2010 23:41:27 Henri Verbeet wrote:
>> The problem with the effect interface is that there are several fairly
>> large parts/dependencies to implement. For example, it has important
>> dependencies on both the (non-existent) HLSL compiler and the
2009/12/29 Henri Verbeet :
> 2009/12/29 Matteo Bruni :
>> I added the fake parser for two reasons: because I have to initialize
>> an asm_parser structure anyway in the create__parser functions
>> (and I prefer to use parser_fake for the unimplemented shader versions
>
2009/12/29 Alexandre Julliard :
> Matteo Bruni writes:
>
>> +
>> +%option reentrant bison-bridge
>
> These won't work on old flex versions, and will get you in trouble with
> the flex police (aka Michael Stefaniuc ;-)
>
Alexandre, now you have another person
2009/12/29 Henri Verbeet :
> 2009/12/28 Matteo Bruni :
>>
> Why do you need the fake parser? Can't you just not support those
> shader versions yet? There's also (in general) not much of a point in
> adding structure fields that aren't used yet.
>
I added the
2009/10/2 Alexandre Julliard :
> Matteo Bruni writes:
>
>> @@ -82,8 +82,7 @@ void *pp_xmalloc(size_t size)
>> res = malloc(size);
>> if(res == NULL)
>> {
>> - fprintf(stderr, "Virtual memory exhausted.\n");
>> -
2009/8/19 Roderick Colenbrander :
>> The libmpg123 library is not shipped in any rpmfusion repository for Fedora
>> 10, and possibly for other distros. This means anyone who wants mp3 support
>> would need to install libmpg123 from source. However, rpmfusion for Fedora
>> 10 has libmad, lame and tw
2009/8/18 Henri Verbeet :
> 2009/8/18 Matteo Bruni :
>> constructs, single instructions, ...) but it seems to be quite a work
>> and in any case the resulting patch needs to have a working lexer,
>> parser, bytecode writer and the glue among them, so it can't be made
sulting patch needs to have a working lexer,
parser, bytecode writer and the glue among them, so it can't be made
smaller than so much, I believe.
Anyway I'm going to try to rework the patches the way you suggest,
we'll see what comes up...
Thanks,
Matteo Bruni.
2009/8/17 Juan Lang :
> Hi Matteo,
>
> this approach seems pretty inflexible to me:
>
> +/* Whether to exit the app on errors (default: true) */
> +extern void wpp_set_exit_on_error( int exit );
>
> @@ -646,7 +654,8 @@ int ppy_error(const char *s, ...)
> va_start(ap, s);
> generic_msg
2009/8/16 Vincent Povirk :
> Don't send patches that only add unused code.
>
Well, to be true all the first 12 patches add code which is
effectively used only from patch 13 onwards. But I couldn't find a
better way to split the patches in manageable pieces while avoiding
these kind of issues.
ely though)
Looking better at this, I noticed that I wasn't checking the register
number, while native has this check. So I reworked this part, and now
the code is as the attached file.
Regarding Henri's review, I followed everything, except keeping
my_alloc/realloc/free (now asm_allo
2009/7/20 Henri Verbeet :
> 2009/7/20 Matteo Bruni :
>> That function, in particular, should really be into asmparser.c and
>> not be visible from outside. Then the wine_dbg_sprintf() function
>> comes really handy in this situation, I didn't know it. Note also that
>
2009/7/20 "Luis C. Busquets Pérez" :
> I read several months ago that the itnetion was to create the assembler
> inside the wined3d and then use its functionality inside the diverse d3dx9
> implementations. Has this changed? I think it was Stefan Dösinger sho
> proposed it:
>
> d3dx -> wined3d asse
2009/7/19 Henri Verbeet :
> 2009/7/19 Matteo Bruni :
>> Hi to everybody,
>> I'm sending here the main assembler patch for reviews and suggestions.
>> It is bzipped as it is quite a big patch, but I couldn't find a
>> meaningful way to split it.
> It rea
om wined3d. They are used only internally,
so they should not be a problem, but I'd like to hear if you think
differently (ex. it is better to rename them?).
Thank you,
Matteo Bruni
asmshader.txt.bz2
Description: BZip2 compressed data
Hi Juan,
these I/O hooks are needed to use wpp as a preprocessor for d3d shader
assembling, where I have to read files with CreateFile/ReadFile
(Windows-style) or from memory. I plan to send the assembler patches
not immediately (in particular, the patch which makes use of wpp is
not so near). On
I'm quite sure that C standards guarantee global variables are initialized to 0.
2009/6/30 Daniel Santos :
> Some pointers are getting used prior to initialization. It would appear that
> the current compilers are initializing them to zero or we've been lucky.
>
>
>
>
>
>
instances (such as
the mmap access to the sound buffers), maybe only when PulseAudio is
present, could be an acceptable solution. I don't think the increased
latencies would be a problem, as, at least from my personal
experience, Windows-DirectSound has quite high latencies (even
pre-Windows Vista, ex. Windows XP).
That said, certainly having someone maintaining "Wine audio
department" would be great.
Just my two cents...
Matteo Bruni
101 - 174 of 174 matches
Mail list logo
