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
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.
>
>
>
>
>
>
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
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
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
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/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
>
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/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.
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
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/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
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/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/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/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/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
>
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
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/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
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/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
> 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/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",
>>
> - 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/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
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/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/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
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/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
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
2012/10/29 Christian Costa :
>
>>
>> pixel_format = get_format_info(src_desc.Format);
>> -if (pixel_format->type != FORMAT_ARGB)
>> -{
>> -FIXME("Unsupported pixel format %#x\n", src_desc.Format);
>> -return E_NOTIMPL;
>> -}
>> +if (pixel_format->type == FORMAT_
2012/11/2 Steaphan Greene :
> Running a game in wine showed it performing terribly. I traced this to the
> fact that it allocates and deallocates tiny memory chunks over and over (I
> suspect it's in C++ and passing things by value everywhere). This led to
> huge stalls because the heap bins were
2012/11/3 Steaphan Greene :
> On 11/03/2012 09:04 AM, Matteo Bruni wrote:
>>
>> 2012/11/2 Steaphan Greene:
>>>
>>> Running a game in wine showed it performing terribly. I traced this to
>>> the
>>> fact that it allocates and deallocates tiny mem
2012/11/27 Detlef Riekenberg :
> While inspecting a test failure, i found only
> 3 possible results for the line test:
> - d3dx9_36.dll not present
> - all tests skipped
> line.c:146: Tests skipped: Failed to create IDirect3DDevice9 object
> 0x8876086c
> - refcount test failed
> line.c:113: Te
2013/1/1 Rico Schüller :
> ---
> dlls/d3dx9_36/shader.c | 16 +++-
> dlls/d3dx9_36/tests/shader.c | 21 +
> 2 Dateien geändert, 32 Zeilen hinzugefügt(+), 5 Zeilen entfernt(-)
>
+static inline BOOL is_valid_bytecode(DWORD token)
+{
+token &= 0x;
+
2013/1/1 Andrew Talbot :
> Changelog:
> d3dcompiler_43: Avoid signed-unsigned integer comparisons.
>
> diff --git a/dlls/d3dcompiler_43/bytecodewriter.c
> b/dlls/d3dcompiler_43/bytecodewriter.c
> index d10f6bc..17289d2 100644
> --- a/dlls/d3dcompiler_43/bytecodewriter.c
> +++ b/dlls/d3dcompile
2013/1/10 Rico Schüller :
> ---
> dlls/d3dx9_36/texture.c | 6 +++---
> 1 Datei geändert, 3 Zeilen hinzugefügt(+), 3 Zeilen entfernt(-
>
> -DWORD i, v;
> +DWORD i, v, mask32 = format->bits[c] == 32 ? -1 : ((1 <<
> format->bits[c]) - 1);
Usually we prefer to use ~0U instead of -1
2013/1/26 Stefan Dösinger :
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Am 2013-01-26 22:32, schrieb Matteo Bruni:
>> +
>> gl_info->fbo_ops.glFramebufferTexture2D(GL_FRAMEBUFFER,
>> GL_COLOR_ATTACHMENT0, GL_TEXTURE_2D, tex, 0);
> Do you really have
Hi,
in addition to what I already told you in #winehackers (that is,
please rename the test struct field red_in to red_out and red_out to
red_expected, or something like that), you should take the chance to
do some more cleanup. That means e.g. use "const" instead of "CONST"
as Rico already sugges
2013/2/17 Henri Verbeet :
> On 17 February 2013 18:10, Matteo Bruni wrote:
>> @@ -6168,18 +6172,10 @@ HRESULT surface_load_location(struct wined3d_surface
>> *surface, DWORD location, c
>>
>> if (surface->resource.usage & WINED3DUSAGE_DEPTHSTENCIL)
2013/2/26 Rico Schüller :
> Hi Nozomi,
>
> this is pretty fast. Just some numbers (run time on my machine, so it might
> not be that representative)...
>
> before: 43s
> previous patch: 27s
> this patch: 21s
> native: 16s
>
> So from the speed point of view, it's a lot closer than the rest.
>
> Tho
2013/3/1 Nozomi Kodama :
> Why is this patch marked as "not applied" by the testbot?
> In my computer, with the latest git, it applies fine.
>
> Is there a problem with testbot?
>
> Nozomi
>
>
Yeah, the old testbot has some issues. FWIW the patches applied just
fine for me.
Now, I know I'm going
2013/3/6 Nozomi Kodama :
> hello
>
> Still problems with this patch?
>
> Nozomi.
>
FWIW, both patches are fine to me.
2013/3/14 Nozomi Kodama :
> No news about these patches?
>
>
> Nozomi?
>
>
Hmm, I was under the impression that these patches were already picked
up in git, but I see I was mistaken.
Anyway they look okay to me, except for a bit in the tests from the
first patch that I noticed just now by reading
2013/3/15 Nozomi Kodama :
>
Patch series is fine to me.
2013/4/1 Nozomi Kodama
>
> Since there are only at most 7 significant digits for a float, we must not be
> too picky about the expected difference for small numbers
>
> -#define relative_error(exp, out) ((exp == 0.0f) ? fabs(exp - out) :
> (fabs(1.0f - (out) / (exp
> +#define relative_error
2013/4/7 Nozomi Kodama :
>
Both patches are fine for me (note that the email subject is missing
an "f" but the actual patch has the correct title).
2013/4/10 Henri Verbeet :
> On 10 April 2013 01:35, Matteo Bruni wrote:
>> ---
>> dlls/wined3d/utils.c | 3 +++
>> 1 file changed, 3 insertions(+)
>>
>> diff --git a/dlls/wined3d/utils.c b/dlls/wined3d/utils.c
>> index da8fc7b..5010676 100644
>> ---
2013/4/10 Henri Verbeet :
> On 10 April 2013 01:35, Matteo Bruni wrote:
>> -/* Clear the screen */
>> -gl_info->gl_ops.gl.p_glClearColor(1.0f, 0.0f, 0.0f, 0.0f);
>> -checkGLcall("glClearColor");
>> -gl_info->gl_ops.gl.p_glClearIndex(0);
I guess it depends on what happens in D3D when the sampler type
declared in the shader and the type of the texture bound to that
sampler disagree, and it really matters only if all the current
drivers have the same behavior in that regard. unbound_sampler_test()
doesn't check what happens with mism
2013/4/10 Henri Verbeet :
> On 10 April 2013 17:53, Matteo Bruni wrote:
>> The idea is that, since check_fbo_compat() creates a texture of the
>> specified format to attach it to a test FBO and verify that it works
>> correctly, it doesn't make sense to even try if the f
2013/4/15 Nozomi Kodama :
> Hello
>
> thanks for the review.
> I don't think that calling defines is the way to go. Indeed, I tested my
> patch and yours. Yours is about 12% slower than mine in my computer.
> And now, we try to take care of efficiency of this dll. So, it is not the
> time to incre
Hrm, I sent the wrong version of the patch, I had actually moved the
depth/stencil check earlier (so yeah, totally agree on that part).
Also you're right about WINED3DFMT_FLAG_RENDERTARGET, for some reason
I thought we were setting that in check_fbo_compat() but it's clearly
not the case.
I'm send
2013/4/25 Henri Verbeet :
> Seems ok, though a small comment explaining the issue this patch fixes
> probably wouldn't hurt.
A comment in the commit message or in the code?
> On 25 April 2013 20:43, Matteo Bruni wrote:
>> +if (target ==
2013/4/29 Christian Costa :
>
> ---
> dlls/d3dx9_36/tests/xfile.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/dlls/d3dx9_36/tests/xfile.c b/dlls/d3dx9_36/tests/xfile.c
> index 1238bcd..e514a5f 100644
> --- a/dlls/d3dx9_36/tests/xfile.c
> +++ b/dlls/d3dx9_36/tests/xf
2013/5/2 Christian Costa :
>
> ---
> dlls/d3dcompiler_43/compiler.c| 101
> +++--
> dlls/d3dcompiler_43/d3dcompiler_private.h |1
> 2 files changed, 81 insertions(+), 21 deletions(-)
>
> diff --git a/dlls/d3dcompiler_43/compiler.c b/dlls/d3dcompiler_43/com
emantics(ptr ptr ptr)
> @ stdcall D3DXGetShaderSamplers(ptr ptr ptr)
> @ stdcall D3DXGetShaderSize(ptr)
> diff --git a/dlls/d3dx9_36/shader.c b/dlls/d3dx9_36/shader.c
> index 75bc9b5..3b71b4b 100644
> --- a/dlls/d3dx9_36/shader.c
> +++ b/dlls/d3dx9_36/shader.c
> @@ -1,6 +
2013/6/12 Christian Costa :
>
>> > +HRESULT WINAPI D3DXGetShaderInputSemantics(const DWORD *byte_code,
>> > D3DXSEMANTIC *semantics, UINT *count)
>> > +{
>> > +const DWORD *ptr = byte_code;
>> > +UINT i = 0;
>> > +
>> > +TRACE("byte_code = %p, semantics = %p, count = %p\n", byte_code,
>
2013/6/16 Fabian Ebner :
> ---
> po/it.po | 40 ++--
> 1 file changed, 14 insertions(+), 26 deletions(-)
#: joy.rc:42
msgid ""
"After disabling or enabling a device, the connected joysticks won't be "
"updated here until you restart this applet."
msgstr
2013/6/17 Fabian Ebner :
> Fixed a typo and a sentence, thanks to Matteo
> ---
> po/it.po | 40 ++--
> 1 file changed, 14 insertions(+), 26 deletions(-)
#: jscript.rc:39
msgid "'return' statement outside of function"
-msgstr ""
+msgstr "Istruzione 'return' fo
2013/6/17 Fabian Ebner :
> Typo fixed (finally)
> ---
> po/it.po | 40 ++--
> 1 file changed, 14 insertions(+), 26 deletions(-)
>
This one looks good to me, thanks :)
2013/6/24 Christian Costa :
> Le 24/06/2013 09:24, Henri Verbeet a écrit :
>
>> On 23 June 2013 21:57, Christian Costa wrote:
>>>
>>> When D3DTA_CONSTANT is use in a texture stage, the generated shader uses
>>> variables that are not defined making thus the compilation to fail.
>>> This patch decl
2013/7/24 Rico Schüller :
> ---
> dlls/d3dx9_36/tests/shader.c | 308
> +++
> 1 file changed, 308 insertions(+)
>
This is okay, but as a followup can you add some tests with mixed-type
structs? Something like:
struct
{
float f;
int i;
bool b;
}
2013/7/24 Rico Schüller :
> ---
> dlls/d3dx9_36/shader.c | 79
> --
> 1 file changed, 77 insertions(+), 2 deletions(-)
>
So there was actually a logic (an insane one, but yeah...). Have you
found any game actually using this?
Annoying question: hav
2013/7/29 Chris Moeller :
> without looking very deeply into the CRT source code.
You're talking about MS source code, right? That makes you tainted for
contributing to Wine at
the very least for C runtime-related code :(
If you haven't looked into any other source code, this patch might be
okay (
2013/7/30 Chris Moeller :
>
> On Jul 29, 2013, at 11:22 AM, Matteo Bruni wrote:
>
>> 2013/7/29 Chris Moeller :
>>> without looking very deeply into the CRT source code.
>>
>> You're talking about MS source code, right? That makes you tainted for
>>
2013/7/30 Rico Schüller :
> Hi Matteo,
>
> please see the attached patch.
>
>
> On 25.07.2013 16:13, Matteo Bruni wrote:
>>
>> 2013/7/24 Rico Schüller :
>>>
>>> ---
>>> dlls/d3dx9_36/tests/shader.c | 308
>>> ++
2013/8/1 Rico Schüller :
> On 31.07.2013 00:14, Matteo Bruni wrote:
>>
>> 2013/7/30 Rico Schüller :
>>>
>>> Hi Matteo,
>>>
>>> please see the attached patch.
>>>
>>>
>>> On 25.07.2013 16:13, Matteo Bruni wrote:
>>
2013/8/1 Nozomi Kodama :
>
+vertices = HeapAlloc(GetProcessHeap(), 0, 2 * (sides + 1) *
sizeof(D3DXVECTOR3));
+if (!vertices)
+{
+TRACE("Not memory enough for vertex buffer\n");
+polygon->lpVtbl->Release(polygon);
+return E_OUTOFMEMORY;
+}
+
+hr = polygo
2013/8/1 Matteo Bruni :
> Instead of generating an entry for the struct with the correct
> members, the compiler generates TWO entries for sbnf, one with all its
> fields in D3DXRS_FLOAT4 and the other with D3DXRS_BOOL. Which, if I'm
> reading this correctly, makes 0
2013/8/26 Stefan Dösinger :
> Try 2:
> *) Require only GPU access for buffers
> *) Reduce number of checkGLcall invocations
> *) Remove a return from an ERR case
> ---
> dlls/wined3d/utils.c | 1 +
> dlls/wined3d/volume.c | 168
> -
> d
2013/9/3 Henri Verbeet :
> On 2 September 2013 23:04, Matteo Bruni wrote:
>> +float quad1[] = {
>> +-1.0, -1.0, 0.1, 0.0,0.0,1.0,
>> + 0.0, -1.0, 0.1, 1.0,0.0,1.0,
>> +-1.0,0.0, 0.1, 0.0,1.
ted when needed. Tests
> are also added.
>
> Thanks to Matteo Bruni for review and support.
>
> Try 2:
> - update with latest git
Hi, I have a few small nits still, please bear with me...
> ---
> dlls/d3d9/tests/visual.c | 80
>
2013/9/24 Rico Schüller :
> ---
> dlls/d3dx9_36/effect.c | 248
> +++--
> 1 Datei geändert, 95 Zeilen hinzugefügt(+), 153 Zeilen entfernt(-)
>
I definitely like the direction this patch takes.
@@ -5068,6 +5009,9 @@ static HRESULT d3dx9_parse_resource(s
Hi Rico,
2013/10/8 Rico Schüller :
> Hi,
>
> this moves the object initialization into a separate function, so it could
> be used for strings and resources. It also removes the STATE_TYPE as we
> could distinguish the types at the object level.
>
> 1. When an object has a destination, it points to
2013/10/9 Rico Schüller :
> On 09.10.2013 01:12, Matteo Bruni wrote:
>>
>> Hi Rico,
>>
>> 2013/10/8 Rico Schüller :
>>>
>>> Hi,
>>>
>>> this moves the object initialization into a separate function, so it
>>> could
>
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/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/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
> -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/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
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.
>
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,
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/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/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/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...
> + /* 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.
> + 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
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. :)
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++)
&
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/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/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/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
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?
>> >
>&
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
, 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:
>>
>>
>>
>>
>>
>
1 - 100 of 174 matches
Mail list logo
