2013/9/4 Christian Costa :
> This patch fixes part of bug 33606 and 31918.
>
> The current code generates shaders that support per-stage constant but does
> not declare the variables used causing thus compilation failures.
> With this patch, these variables are declared and updated when needed. Te
Le 26/06/2013 09:10, Henri Verbeet a écrit :
On 25 June 2013 18:26, Stefan Dösinger wrote:
While I agree with Henri's statement to some extend - patch reviewing
is a terribly exhausting task - I think the statement was a bit harsh
to say to someone who donates his personal time to the project.
On 25 June 2013 18:26, Stefan Dösinger wrote:
> While I agree with Henri's statement to some extend - patch reviewing
> is a terribly exhausting task - I think the statement was a bit harsh
> to say to someone who donates his personal time to the project.
>
Well, I could try to sugarcoat it a bit,
Thanks Stefan!
No problem with me. I don't take it personnally. :)
I'm not statisfied with the submission/review with some criterias which are
sometimes rules, sometimes tastes, with patches (not necessarily mine) that
remain in the new state without any comments while another with a missing
dot wo
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 2013-06-25 18:08, schrieb Christian Costa:
> Are we really discussing about a typo in the subject line?
> "Implement" just comes naturally from the fixme when I create an
> empty patch. It turned out after coding that "Fix" is more
> appropriate. I
2013/6/25 Henri Verbeet
> On 25 June 2013 11:05, Christian Costa wrote:
> > 2013/6/25 Henri Verbeet
> >> At least try to pretend you put
> >> some effort into making sure the patch is as good as it can be before
> >> submitting it.
> >
> >
> > I could have send the patch to wine-devel first but
On 25 June 2013 11:05, Christian Costa wrote:
> 2013/6/25 Henri Verbeet
>> At least try to pretend you put
>> some effort into making sure the patch is as good as it can be before
>> submitting it.
>
>
> I could have send the patch to wine-devel first but would I get something
> longer that "seve
2013/6/25 Henri Verbeet
> On 24 June 2013 16:44, Matteo Bruni wrote:
> > @@ -1673,6 +1673,8 @@ struct texture_stage_op
> > unsignedaarg2 : 8;
> > unsignedaarg0 : 8;
> >
> > +DWORD constant;
> > +
> > struct color_fixup_desc col
On 24 June 2013 16:44, Matteo Bruni wrote:
> @@ -1673,6 +1673,8 @@ struct texture_stage_op
> unsignedaarg2 : 8;
> unsignedaarg0 : 8;
>
> +DWORD constant;
> +
> struct color_fixup_desc color_fixup;
> unsignedt
I'm not Henri but I can mention a number of issues (which might or
might not match with Henri's).
+for (stage = 0; stage < MAX_TEXTURES && settings->op[stage].cop
!= WINED3D_TOP_DISABLE; ++stage)
You probably want to generate this code only for texture stages
actually using constants.
Yes.
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
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 declare these variables with the value from the rel
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 declare these variables with the value from the related texture
> stage state D3D_TSS_CONSTA
2013/5/17 Austin English
> On Thu, May 16, 2013 at 2:26 PM, Christian Costa
> wrote:
> > Also remove fixme in wined3d_device_get_software_vertex_processing since
> it does what it is supposed to do.
> > ---
> > dlls/wined3d/device.c | 12 ++--
> > 1 file changed, 2 insertions(+), 10 d
On Thu, May 16, 2013 at 2:26 PM, Christian Costa wrote:
> Also remove fixme in wined3d_device_get_software_vertex_processing since it
> does what it is supposed to do.
> ---
> dlls/wined3d/device.c | 12 ++--
> 1 file changed, 2 insertions(+), 10 deletions(-)
>
> diff --git a/dlls/wine
On 1 April 2013 10:30, Stefan Dösinger wrote:
> +if (wined3d_settings.placebo == PLACEBO_VIDMEM)
> +{
> +TRACE("Placing buffer %p in video memory\n", This);
> +glHint(This->buffer_type_hint, GL_FASTEST);
> +}
> +
I'm going to go out on a limb and call April fools on thi
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 2013-01-23 13:36, schrieb Stefan Dsinger:
> I was under the assumption that we already had a test for that -
> those interfaces expect both count and rectangle to be non-zero,
> otherwise they return an error.
>
> I can't find the test right now,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 2013-01-23 13:28, schrieb Henri Verbeet:
> Although I don't expect a difference in behaviour, it probably
> wouldn't hurt to add tests for the other ddraw versions as well
> (i.e. through the viewport interface).
I was under the assumption that we
On 23 January 2013 13:14, Stefan Dösinger wrote:
> dlls/d3d8/tests/visual.c | 17 +
> dlls/d3d9/tests/visual.c | 16
> dlls/ddraw/tests/ddraw7.c | 36
> dlls/wined3d/device.c | 6 ++
> 4 files changed, 75 insertions(
On 2 December 2012 01:10, Jiang Yike wrote:
> {"NVE4",CARD_NVIDIA_GEFORCE_GTX680},
> +{"NVE4",CARD_NVIDIA_GEFORCE_GTX660Ti},
This makes no sense.
On 29 September 2012 11:14, Marcus Meissner wrote:
> Hi,
>
> I do not fully understand all this, but it seem the decref needs to
> be behind the last usage of prev.
>
Sort of. It's probably better to do it like this, but a non-zero
bind_count implies a non-zero reference count as well, so in pract
Am 01.07.2012 12:43 schrieb "Henri Verbeet"
> In general we don't do hacks like this.
The VBOs in question might be managed pool buffers, which would make
keeping the sysmem around less hacky.
The unforunate issue is that other games(namely Source Engine games,
probably others too) allocate hundre
In general we don't do hacks like this.
Le 01/04/2012 01:49, Henri Verbeet a écrit :
My first guess would be to check if vertex buffers are perhaps
supposed to take a reference to the D3D interface.
Ok. I will write a test to check that.
On 31 March 2012 23:30, Christian Costa wrote:
> Do you have a better idea ?
>
My first guess would be to check if vertex buffers are perhaps
supposed to take a reference to the D3D interface.
> Btw, the problem is easily reproductible. The bugzlla entry contain the
> download link.
>
Yes, we hav
Le 31/03/2012 22:46, Henri Verbeet a écrit :
This looks wrong. Is there a legitimate way that this can happen?
The FIXME in wined3d_device_decref says :
FIXME("Device released with resources still bound, acceptable but
unexpected.\n");
If this is "acceptable", resources must not use the d
This looks wrong. Is there a legitimate way that this can happen?
On 29 February 2012 13:32, Stefan Dösinger wrote:
> Fine with me, just don't blame me that those bugs aren't fixed :-)
Yeah well, 27600 was reported in June last year.
Am Mittwoch, 29. Februar 2012, 11:54:11 schrieb Henri Verbeet:
> I guess I didn't explicitly say it yesterday, but I think this should
> be deferred and fixed properly after 1.4. While in principle dropping
> VBOs might be ok as a temporary fix for the release, the vertex /
> index buffer code is p
On 29 February 2012 11:12, Stefan Dösinger wrote:
> try 2: Invalidate the index buffer state as well, as the buffer might be
> an index buffer.
>
> Otherwise unmodified reesend after the discussion from yesterday. This
> is for bugs 29079, 29897(suspected) and 30019.
>
I guess I didn't explicitly
Am 25.01.2012 14:40 schrieb "Andrew Eikum" :
> What about
> changing them to WARN so that they don't print to the console by
> default? Everyone knows there are workarounds, but is anyone really
> gaining anything by having these flood the console?
I agree with this sentiment, althougj Henri's poin
On Wed, Jan 25, 2012 at 02:03:04PM +0100, Henri Verbeet wrote:
> The code looks like it would do what was intended to me. The problem I
> have with it, and I'm pretty sure I've mentioned this before, is that
> reducing debug output shouldn't be a goal on its own. If you're a
> user, and the message
On 25 January 2012 01:25, Francois Gouget wrote:
> I don't pretend to know what Henry meant but reported_once is not
> initialized. It's probably put into a zero-initialized section by the
> compiler but it looks worrying to me (I believe something like this has
> been debated on the Linux kernel
2012/1/25 Nicolas Le Cam :
> 2012/1/25 Francois Gouget :
>> On Wed, 25 Jan 2012, Detlef Riekenberg wrote:
>>
>>> On Sun, 2012-01-22 at 19:53 +0100, Henri Verbeet wrote:
>>> > On 22 January 2012 19:44, Detlef Riekenberg wrote:
>>> > > - if (usage & ~handled)
>>> > > + static DWORD reported_on
2012/1/25 Francois Gouget :
> On Wed, 25 Jan 2012, Detlef Riekenberg wrote:
>
>> On Sun, 2012-01-22 at 19:53 +0100, Henri Verbeet wrote:
>> > On 22 January 2012 19:44, Detlef Riekenberg wrote:
>> > > - if (usage & ~handled)
>> > > + static DWORD reported_once;
>> > > +
>> > > + if (usage
On Wed, 25 Jan 2012, Detlef Riekenberg wrote:
> On Sun, 2012-01-22 at 19:53 +0100, Henri Verbeet wrote:
> > On 22 January 2012 19:44, Detlef Riekenberg wrote:
> > > -if (usage & ~handled)
> > > +static DWORD reported_once;
> > > +
> > > +if (usage & ~(handled | reported_once))
> > >
On Sun, 2012-01-22 at 19:53 +0100, Henri Verbeet wrote:
> On 22 January 2012 19:44, Detlef Riekenberg wrote:
> > -if (usage & ~handled)
> > +static DWORD reported_once;
> > +
> > +if (usage & ~(handled | reported_once))
> > +{
> > +reported_once |= (usage & ~handled);
> >
On 22 January 2012 19:44, Detlef Riekenberg wrote:
> - if (usage & ~handled)
> + static DWORD reported_once;
> +
> + if (usage & ~(handled | reported_once))
> + {
> + reported_once |= (usage & ~handled);
> FIXME("Unhandled usage flags %#x.\n", usage & ~handled);
> + }
On 14 December 2011 23:45, wrote:
> @@ -871,6 +871,13 @@ static HRESULT swapchain_init(struct wined3d_swapchain
> *swapchain, WINED3DSURFTY
> swapchain->win_handle = window;
> swapchain->device_window = window;
>
> + if (!desc->windowed && window)
> + {
> + wined3d_device_se
On 11 June 2011 17:26, Marcus Meissner wrote:
> if (state <= HIGHEST_TRANSFORMSTATE)
> + {
> mat = &device->updateStateBlock->state.transforms[state];
> + }
> else
> + {
> FIXME("Unhandled transform state %#x.\n", state);
> + return WINED3D_OK;
> + }
>
Th
On Saturday 11 June 2011 11:17:58 Marcus Meissner wrote:
> else
> +{
> FIXME("Unhandled transform state %#x.\n", state);
> +return WINED3DERR_INVALIDCALL;
> +}
Please return WINED3D_OK, like wined3d_device_set_sampler_state and other
setters. Native doesn't do this ki
On 13 May 2011 18:27, Marcus Meissner wrote:
> @@ -1273,7 +1273,7 @@ struct wined3d_pixel_format
> BOOL doubleBuffer;
> int auxBuffers;
> int numSamples;
> -} wined3d_pixel_format;
> +} wined3d_pixel_format DECLSPEC_HIDDEN;
>
No, that's wrong. It's not supposed to be a variable at all,
On 8 November 2010 05:52, Brian Paterni wrote:
> Indeed, I was wondering about that... Also, I realized after submitting my
> previous email that checking for "X.Org" in gl_vendor_string is probably
> unnecessary as well, so I removed that portion from the following:
Couple of points:
- Killing t
On Sun, Nov 07, 2010 at 06:48:22PM -0800, Austin English wrote:
> Howdy Brian,
>
> You're mixing tabs and spaces. Please use consistent spacing, as the
> rest of the file does.
Indeed, I was wondering about that... Also, I realized after submitting my
previous email that checking for "X.Org" in g
On Sun, Nov 7, 2010 at 2:08 PM, Brian Paterni wrote:
> Hello, I've been receiving a couple "unrecognized GL_VENDOR" fixme's lately
> and
> decided to poke around wine's source. I've found that
> wined3d_guess_card_vendor
> does not return the correct enum for people running mesa's r600g driver,
Looks OK to me.
(unless there are whitespace issues which I can't see in my current mail client)
Am 01.09.2010 um 06:44 schrieb Octavian Voicu:
> Fixes regression described in bug 24226.
> ---
> dlls/wined3d/directx.c |7 ++-
> 1 files changed, 6 insertions(+), 1 deletions(-)
>
> diff --gi
Henri Verbeet a écrit :
On 1 March 2010 23:46, Christian Costa wrote:
Altough TRACE will not display anything if the traces are enabled, I would
have tested the channel before even entering
this code part.
shader_trace_init() is only called when traces are enabled.
Indeed. As th
On 1 March 2010 23:46, Christian Costa wrote:
> Altough TRACE will not display anything if the traces are enabled, I would
> have tested the channel before even entering
> this code part.
>
shader_trace_init() is only called when traces are enabled.
Henri Verbeet a écrit :
On 1 March 2010 09:39, Christian Costa wrote:
Still not quite right, I'm afraid. For example, the following doesn't work:
+while (i < size)
+{
+/* Find end of line */
+while (
On 1 March 2010 09:39, Christian Costa wrote:
>
Still not quite right, I'm afraid. For example, the following doesn't work:
> +while (i < size)
> +{
> +/* Find end of line */
> +while ((str[i] != 0) && (str[i]
Henri Verbeet a écrit :
On 17 February 2010 17:54, Christian Costa wrote:
+if (TRACE_ON(d3d_shader))
+{
+int size = strlen(comment) + 1;
+char* str = (char*)HeapAlloc(GetProcessHeap(), 0, size);
+int i = 0;
+
On 17 February 2010 17:54, Christian Costa wrote:
> +if (TRACE_ON(d3d_shader))
> +{
> +int size = strlen(comment) + 1;
> +char* str = (char*)HeapAlloc(GetProcessHeap(), 0, size);
> +int i = 0;
> +char* line = s
>> Wrt comments, having displayed the comments that explain the assembly code
>> is not uninteresting at all imo. I'm tempted to keep then displayed.
>>
> I have *never* used the comments to fixed a bug, or seen particularly
> interesting ones, for that matter. Regardless, if it works for you
> th
On 17 February 2010 13:22, Christian Costa wrote:
> I don't see your point using debugstr_an. My code does all the needed job.
It's unvalidated external data, special characters should be escaped.
> Wrt comments, having displayed the comments that explain the assembly code
> is not uninteresting
Henri Verbeet a écrit :
On 17 February 2010 11:47, Christian Costa wrote:
It should use debugstr_an() in the first place. You could have a go at
splitting it into separate lines if needed after that, but I can't
think of a whole lot of cases where the comments are really useful.
I do
On 17 February 2010 11:47, Christian Costa wrote:
>
It should use debugstr_an() in the first place. You could have a go at
splitting it into separate lines if needed after that, but I can't
think of a whole lot of cases where the comments are really useful.
Henri Verbeet a écrit :
On 17 February 2010 00:28, Stefan Dösinger wrote:
No, the pipeline part that would implement this(vertex) should set a state
handler that prints a WARN for each defined but unimplemented stage.
Sure, but that doesn't mean you can't catch undefined states as well
On 17 February 2010 00:28, Stefan Dösinger wrote:
> No, the pipeline part that would implement this(vertex) should set a state
> handler that prints a WARN for each defined but unimplemented stage.
Sure, but that doesn't mean you can't catch undefined states as well.
E.g. something along the lines
On Tuesday 16 February 2010 22:18:50 Henri Verbeet wrote:
> Tweening is indeed unimplemented. We should probably catch
> unimplemented render states in IWineD3DDeviceImpl_SetRenderState()
> though.
No, the pipeline part that would implement this(vertex) should set a state
handler that prints a WAR
On 16 February 2010 21:55, Christian Costa wrote:
> That's clearer. Thanks.
> I've just tested your patch. The incriminated state is
> WINED3DRS_TWEENFACTOR.
> I haven't investigated much though...
>
Tweening is indeed unimplemented. We should probably catch
unimplemented render states in IWineD3D
Henri Verbeet a écrit :
On 16 February 2010 19:32, Christian Costa wrote:
So we should never enter this function at all. Right ?
Yes.
And what do you mean by "something is broken" ? Are you talking about
wined3d code ?
It means there's code that marks a state dirty that does
On 16 February 2010 19:32, Christian Costa wrote:
> So we should never enter this function at all. Right ?
Yes.
> And what do you mean by "something is broken" ? Are you talking about
> wined3d code ?
It means there's code that marks a state dirty that doesn't exist.
Typically that's because the
Henri Verbeet a écrit :
On 16 February 2010 13:45, Christian Costa wrote:
Ok. What about doing the following :
- when state is 0, don't print any message because it's normal
- when state is not 0, print the state to have a meaningfull message
No, if you see that message at all, someth
On 16 February 2010 13:45, Christian Costa wrote:
> Ok. What about doing the following :
> - when state is 0, don't print any message because it's normal
> - when state is not 0, print the state to have a meaningfull message
>
No, if you see that message at all, something is broken, that's why
it'
Henri Verbeet a écrit :
On 16 February 2010 12:25, Christian Costa wrote:
Did you test this? "state" is supposed to be always 0. Also,
debug_d3dstate() is much more readable than the state number.
Yes I tested it. Indeed, it's 0.
Ok. I will send a new patch using debug_d3dstate. Tha
On 16 February 2010 12:25, Christian Costa wrote:
>> Did you test this? "state" is supposed to be always 0. Also,
>> debug_d3dstate() is much more readable than the state number.
>>
> Yes I tested it. Indeed, it's 0.
> Ok. I will send a new patch using debug_d3dstate. Thanks.
>
That also means the
Henri Verbeet a écrit :
On 16 February 2010 11:49, Christian Costa wrote:
-ERR("Undefined state.\n");
+ERR("Undefined state %d\n", state);
Did you test this? "state" is supposed to be always 0. Also,
debug_d3dstate() is much more readable than the state number.
Yes I te
On 16 February 2010 11:49, Christian Costa wrote:
> -ERR("Undefined state.\n");
> +ERR("Undefined state %d\n", state);
Did you test this? "state" is supposed to be always 0. Also,
debug_d3dstate() is much more readable than the state number.
Am 11.01.2010 um 15:11 schrieb Henri Verbeet:
> 2010/1/11 Christian Costa :
>> That's better but there are still "err:d3d:state_undefined Undefined state."
>> errors.
>> 6 in total. One for each unavailable stage.
>>
> That's weird, it should hit the DebugBreak() in either
> Context_MarkStateDir
2010/1/11 Christian Costa :
> That's better but there are still "err:d3d:state_undefined Undefined state."
> errors.
> 6 in total. One for each unavailable stage.
>
That's weird, it should hit the DebugBreak() in either
Context_MarkStateDirty() or IWineD3DDeviceImpl_MarkStateDirty() when
it tries t
Henri Verbeet a écrit :
2010/1/6 Christian Costa :
The fixmes disapear but I get tons of err:d3d:state_undefined Undefined
state which is worst. Log attached.
How does the attached patch work?
That's better but there are still "err:d3d:state_undefined Undefined
state." errors.
6 i
2010/1/6 Christian Costa :
> The fixmes disapear but I get tons of err:d3d:state_undefined Undefined
> state which is worst. Log attached.
>
How does the attached patch work?
diff --git a/dlls/wined3d/context.c b/dlls/wined3d/context.c
index 2aec7d6..72e1ae3 100644
--- a/dlls/wined3d/context.c
+++
2010/1/5 Christian Costa :
> Here it is. The fixme message is :
> fixme:d3d:set_tex_op_nvrc > GL_INVALID_ENUM (0x500) from
> set_tex_op_nvrc() @ nvidia_texture_shader.c / 460
>
Looks like the context creation code invalidates those states simply
because they exist. Does the attached
A +d3d,+d3d_caps log would probably be a good start.
> Yeah. A rather old one... ;-)
>
> I don't know this code much but I would say it is partly 2 and 3. Is a FIXME
> suitable then ? This would be much more informative that just GL errors.
I'd prefer if we could track down the real issue. There might still be some
confusion between texture stages
Stefan Dösinger a écrit :
+if (stage > (gl_info->limits.texture_stages-1))
+{
+ ERR("Texture stage %d invalid (only %d availables)\n", stage,
gl_info->limits.texture_stages);
+ return;
+}
In which situations does this occur? I guess its on some older nvidia GPU.
> +if (stage > (gl_info->limits.texture_stages-1))
> +{
> + ERR("Texture stage %d invalid (only %d availables)\n", stage,
> gl_info->limits.texture_stages);
> + return;
> +}
In which situations does this occur? I guess its on some older nvidia GPU.
I don't like the ERR
Am Sonntag, 14. Juni 2009 17:40:39 schrieb Henri Verbeet:
> 2009/6/14 Stefan Dösinger :
> >> Here:
> >> /home/marcus/projects/wine/dlls/d3d9/device.c: In
> >> Funktion »reset_enum_callback«:
> >
> > Does the attached patch fix the issue?
>
> I have a patch touching that code, could you wait with se
2009/6/14 Stefan Dösinger :
>> Here:
>> /home/marcus/projects/wine/dlls/d3d9/device.c: In
>> Funktion »reset_enum_callback«:
> Does the attached patch fix the issue?
>
I have a patch touching that code, could you wait with sending it in a
bit? (I could also rebase it and send it in.)
On Sun, Jun 14, 2009 at 05:29:39PM +0200, Stefan Dösinger wrote:
> > Here:
> > /home/marcus/projects/wine/dlls/d3d9/device.c: In
> > Funktion »reset_enum_callback«:
> Does the attached patch fix the issue?
Yes it does.
Ciao, Marcus
> Here:
> /home/marcus/projects/wine/dlls/d3d9/device.c: In
> Funktion »reset_enum_callback«:
Does the attached patch fix the issue?
diff --git a/dlls/d3d9/device.c b/dlls/d3d9/device.c
index 9d02539..578d783 100644
--- a/dlls/d3d9/device.c
+++ b/dlls/d3d9/device.c
@@ -424,7 +424,8 @@ static BOOL
On Sun, Jun 14, 2009 at 04:30:30PM +0200, Stefan Dösinger wrote:
> Am Sonntag, 14. Juni 2009 14:26:53 schrieb Marcus Meissner:
> > Hi,
> >
> > gcc 4.5trunk warned that we do not handle case 7 (D3DRTYPE_INDEXBUFFER),
> > so add it here too.
> There's a reason why this doesn't exist - WineD3D has ind
Am Sonntag, 14. Juni 2009 14:26:53 schrieb Marcus Meissner:
> Hi,
>
> gcc 4.5trunk warned that we do not handle case 7 (D3DRTYPE_INDEXBUFFER),
> so add it here too.
There's a reason why this doesn't exist - WineD3D has index and vertex buffers
merged, so there is no such thing as a specialized ind
Pavel Prochazka wrote:
>static HRESULT WINAPI IWineGDISwapChainImpl_Present(IWineD3DSwapChain *iface,
>CONST RECT *pSourceRect, CONST RECT *pDestRect, HWND hDestWindowOverride,
>CONST >RGNDATA *pDirtyRegion, DWORD dwFlags) {
> IWineD3DSwapChainImpl *This = (IWineD3DSwapChainImpl *) iface;
>-
Am Dienstag, 26. Mai 2009 18:13:49 schrieb Pavel Prochazka:
Is there any reason why we'd want 32 backbuffer swapchains? The currentl limit
comes from d3d9(no more than 3 backbuffers allowed). We can certainly change
it, but I doubt that any Windows driver supports that in ddraw. If there is
no
2009/5/26 Pavel Prochazka :
> +»··int i=1;
> +
> +»··/*it moves all backbuffers by 1 to left form id = 1,
> +»··the backbuffer swap to frontbuffer and frontbuffer swaps to the end
> of chain
> +»··Something like this:
> +»··»···»···»···»···»···»···»·
2008/12/17 Pauli Nieminen :
> On Wed, Dec 17, 2008 at 10:51 AM, Henri Verbeet wrote:
>> If creation succeeds, you need to Release the shader again. Same goes
>> for the pixel shader version of this function.
>
> I tried to search for example of releasing shaders from the test file but
> when I co
On Wed, Dec 17, 2008 at 10:51 AM, Henri Verbeet wrote:
> 2008/12/17 Pauli Nieminen :
> > +static inline void test_create_vshader_version_check(IDirect3DDevice9
> *device_ptr, const D3DCAPS9 *caps,
> > +const DWORD version, const DWORD *shader_code)
> > +{
> > +IDirect3DVertexShader9 *
2008/12/17 Pauli Nieminen :
> +static inline void test_create_vshader_version_check(IDirect3DDevice9
> *device_ptr, const D3DCAPS9 *caps,
> +const DWORD version, const DWORD *shader_code)
> +{
> +IDirect3DVertexShader9 *vshader_ptr = 0;
> +HRESULT hret = 0;
> +
> +hret = IDirec
Hi,
2008/7/24 Michael Karcher <[EMAIL PROTECTED]>:
>
> What is the advantage of that compared to
>major = strtol(gl_string, &gl_string_cursor,10);
> ?
>
> Or even replace the whole scanning code by
>
>if(sscanf(gl_string, "%d.%d", &major, &minor) != 2)
>ERR_(d3d_cap
Am Donnerstag, den 24.07.2008, 00:55 +0800 schrieb Huang, Zhangrong:
> Hi,
> I tried run World of Warcraft on Mac OS X with X11 and NVIDIA card,
> got the following error messages:
>
> err:d3d_caps:IWineD3DImpl_FillGLCaps Invalid nVidia version string:
> "1.5 NVIDIA-1.5.24"
> err:d3d_caps:IWineD3D
Hello.
I ask to disregard patch " wined3d: add surface convertor from D3DFMT_X8R8G8B8
to D3DFMT_R5G6B5" (d15c66beeb5ab7130161278d0ee86ee79aed.diff) I've sent
yesterday. There are minor errors in masks used within x8r8g8b8_to_x5r6g5
that might cause minor graphical artefacts o
On 04/08/07, Vitaly Budovski <[EMAIL PROTECTED]> wrote:
> ---
> dlls/wined3d/glsl_shader.c |9 +
> 1 files changed, 9 insertions(+), 0 deletions(-)
>
This patch is plain wrong. The caller of
shader_glsl_get_sample_function() is responsible for correctly adding
the correct component f
On 12/05/07, Erik Inge Bolsø <[EMAIL PROTECTED]> wrote:
-TRACE("(%p) Count (%d), pRects (%p), Flags (%x), Z (%f), Stencil (%d)\n",
This,
- Count, pRects, Flags, Z, Stencil);
+TRACE("(%p) Count (%d), pRects (%p), Flags (%x), Color (%f %f %f %f), Z (%f),
Stencil (%d)\n", This,
+
On 12/05/07, Erik Inge Bolsø <[EMAIL PROTECTED]> wrote:
---
dlls/wined3d/utils.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/dlls/wined3d/utils.c b/dlls/wined3d/utils.c
index c444232..4db0622 100644
--- a/dlls/wined3d/utils.c
+++ b/dlls/wined3d/utils.c
@@ -238,6 +238
Ivan Gyurdiev gmail.com> writes:
> that's because Jason seems to have introduced order requirements on the
> table that weren't previously there. The mnxn implementation will
> attempt to access the table as an array, which will break once MOVA is
> moved before DP3:
>
> glsl_shader.c:
Mirek wrote:
Ok, i just found why is it not working with this patch, and why is it
working without this patch. It is based on position of definition MOVA
in vertexshader.c, if MOVA is on "after patch" position it is not
working, but if i move line "
{WINED3DSIO_MOVA, "mova", NULL, 1, 2, vshader_
Ok, i just found why is it not working with this patch, and why is it
working without this patch. It is based on position of definition MOVA
in vertexshader.c, if MOVA is on "after patch" position it is not
working, but if i move line "
{WINED3DSIO_MOVA, "mova", NULL, 1, 2, vshader_mova, vshader_
Ivan Gyurdiev wrote:
Here is log with 3DMark running for about 3 seconds with patch and
without, trace+d3d.
http://www.czela.net/pub/Czela_Debian_2.5/mirek/wine/regression/3DMark03.tar.gz
There's no mova instruction in that log.
...grep for mova, or for "unrecognized" or "Unrecognized" or
Here is log with 3DMark running for about 3 seconds with patch and
without, trace+d3d.
http://www.czela.net/pub/Czela_Debian_2.5/mirek/wine/regression/3DMark03.tar.gz
There's no mova instruction in that log.
1 - 100 of 132 matches
Mail list logo
