2013/9/4 Christian Costa titan.co...@gmail.com:
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
On 25 June 2013 18:26, Stefan Dösinger stefandoesin...@gmail.com 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
Le 26/06/2013 09:10, Henri Verbeet a écrit :
On 25 June 2013 18:26, Stefan Dösinger stefandoesin...@gmail.com 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
On 24 June 2013 16:44, Matteo Bruni matteo.myst...@gmail.com wrote:
@@ -1673,6 +1673,8 @@ struct texture_stage_op
unsignedaarg2 : 8;
unsignedaarg0 : 8;
+DWORD constant;
+
struct color_fixup_desc color_fixup;
unsigned
2013/6/25 Henri Verbeet hverb...@gmail.com
On 24 June 2013 16:44, Matteo Bruni matteo.myst...@gmail.com wrote:
@@ -1673,6 +1673,8 @@ struct texture_stage_op
unsignedaarg2 : 8;
unsignedaarg0 : 8;
+DWORD constant;
+
On 25 June 2013 11:05, Christian Costa titan.co...@gmail.com wrote:
2013/6/25 Henri Verbeet hverb...@gmail.com
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
2013/6/25 Henri Verbeet hverb...@gmail.com
On 25 June 2013 11:05, Christian Costa titan.co...@gmail.com wrote:
2013/6/25 Henri Verbeet hverb...@gmail.com
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
-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 forgot
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
On 23 June 2013 21:57, Christian Costa titan.co...@gmail.com 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
Le 24/06/2013 09:24, Henri Verbeet a écrit :
On 23 June 2013 21:57, Christian Costa titan.co...@gmail.com 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
2013/6/24 Christian Costa titan.co...@gmail.com:
Le 24/06/2013 09:24, Henri Verbeet a écrit :
On 23 June 2013 21:57, Christian Costa titan.co...@gmail.com wrote:
When D3DTA_CONSTANT is use in a texture stage, the generated shader uses
variables that are not defined making thus the
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. I
2013/5/17 Austin English austinengl...@gmail.com
On Thu, May 16, 2013 at 2:26 PM, Christian Costa titan.co...@gmail.com
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
On Thu, May 16, 2013 at 2:26 PM, Christian Costa titan.co...@gmail.com 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
On 1 April 2013 10:30, Stefan Dösinger ste...@codeweavers.com 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
On 23 January 2013 13:14, Stefan Dösinger ste...@codeweavers.com 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
-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
-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, so
On 2 December 2012 01:10, Jiang Yike future...@asia.com wrote:
{NVE4,CARD_NVIDIA_GEFORCE_GTX680},
+{NVE4,CARD_NVIDIA_GEFORCE_GTX660Ti},
This makes no sense.
On 29 September 2012 11:14, Marcus Meissner mar...@jet.franken.de 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
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.
This looks wrong. Is there a legitimate way that this can happen?
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
On 31 March 2012 23:30, Christian Costa titan.co...@gmail.com 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
On 29 February 2012 11:12, Stefan Dösinger ste...@codeweavers.com 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
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
On 29 February 2012 13:32, Stefan Dösinger ste...@codeweavers.com wrote:
Fine with me, just don't blame me that those bugs aren't fixed :-)
Yeah well, 27600 was reported in June last year.
2012/1/25 Nicolas Le Cam niko.le...@gmail.com:
2012/1/25 Francois Gouget fgou...@free.fr:
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 wine@web.de wrote:
- if (usage ~handled)
+
On 25 January 2012 01:25, Francois Gouget fgou...@free.fr 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
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 messages
Am 25.01.2012 14:40 schrieb Andrew Eikum aei...@codeweavers.com:
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,
On Sun, 2012-01-22 at 19:53 +0100, Henri Verbeet wrote:
On 22 January 2012 19:44, Detlef Riekenberg wine@web.de wrote:
-if (usage ~handled)
+static DWORD reported_once;
+
+if (usage ~(handled | reported_once))
+{
+reported_once |= (usage ~handled);
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 wine@web.de wrote:
-if (usage ~handled)
+static DWORD reported_once;
+
+if (usage ~(handled | reported_once))
+
2012/1/25 Francois Gouget fgou...@free.fr:
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 wine@web.de wrote:
- if (usage ~handled)
+ static DWORD reported_once;
+
+ if
On 22 January 2012 19:44, Detlef Riekenberg wine@web.de 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, qwerty0987654...@mail.ru 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)
+ {
+
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 kind of
On 11 June 2011 17:26, Marcus Meissner mar...@jet.franken.de wrote:
if (state = HIGHEST_TRANSFORMSTATE)
+ {
mat = device-updateStateBlock-state.transforms[state];
+ }
else
+ {
FIXME(Unhandled transform state %#x.\n, state);
+ return WINED3D_OK;
+
On 13 May 2011 18:27, Marcus Meissner meiss...@suse.de 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
On 8 November 2010 05:52, Brian Paterni bpate...@gmail.com 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
On Sun, Nov 7, 2010 at 2:08 PM, Brian Paterni bpate...@gmail.com 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
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
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 --git
On 1 March 2010 09:39, Christian Costa titan.co...@wanadoo.fr 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]
Henri Verbeet a écrit :
On 1 March 2010 09:39, Christian Costa titan.co...@wanadoo.fr wrote:
Still not quite right, I'm afraid. For example, the following doesn't work:
+while (i size)
+{
+/* Find end of line */
+
On 1 March 2010 23:46, Christian Costa titan.co...@wanadoo.fr 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 23:46, Christian Costa titan.co...@wanadoo.fr 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
On 17 February 2010 17:54, Christian Costa titan.co...@wanadoo.fr wrote:
+if (TRACE_ON(d3d_shader))
+{
+int size = strlen(comment) + 1;
+char* str = (char*)HeapAlloc(GetProcessHeap(), 0, size);
+int i = 0;
+
Henri Verbeet a écrit :
On 17 February 2010 17:54, Christian Costa titan.co...@wanadoo.fr wrote:
+if (TRACE_ON(d3d_shader))
+{
+int size = strlen(comment) + 1;
+char* str = (char*)HeapAlloc(GetProcessHeap(), 0, size);
+
On 17 February 2010 00:28, Stefan Dösinger ste...@codeweavers.com 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.
Henri Verbeet a écrit :
On 17 February 2010 00:28, Stefan Dösinger ste...@codeweavers.com 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
On 17 February 2010 11:47, Christian Costa titan.co...@wanadoo.fr 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 11:47, Christian Costa titan.co...@wanadoo.fr 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
On 17 February 2010 13:22, Christian Costa titan.co...@wanadoo.fr 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
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
that's
On 16 February 2010 11:49, Christian Costa titan.co...@wanadoo.fr 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.
Henri Verbeet a écrit :
On 16 February 2010 11:49, Christian Costa titan.co...@wanadoo.fr 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.
On 16 February 2010 12:25, Christian Costa titan.co...@wanadoo.fr 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
Henri Verbeet a écrit :
On 16 February 2010 12:25, Christian Costa titan.co...@wanadoo.fr 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
On 16 February 2010 13:45, Christian Costa titan.co...@wanadoo.fr 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
Henri Verbeet a écrit :
On 16 February 2010 13:45, Christian Costa titan.co...@wanadoo.fr 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
On 16 February 2010 19:32, Christian Costa titan.co...@wanadoo.fr 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
Henri Verbeet a écrit :
On 16 February 2010 19:32, Christian Costa titan.co...@wanadoo.fr 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
On 16 February 2010 21:55, Christian Costa titan.co...@wanadoo.fr 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
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 WARN
2010/1/6 Christian Costa titan.co...@wanadoo.fr:
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
---
Henri Verbeet a écrit :
2010/1/6 Christian Costa titan.co...@wanadoo.fr:
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
2010/1/11 Christian Costa titan.co...@wanadoo.fr:
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
Am 11.01.2010 um 15:11 schrieb Henri Verbeet:
2010/1/11 Christian Costa titan.co...@wanadoo.fr:
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
2010/1/5 Christian Costa titan.co...@wanadoo.fr:
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
A +d3d,+d3d_caps log would probably be a good start.
+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 here. If
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.
I
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,
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 index
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 index and
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 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
2009/6/14 Stefan Dösinger ste...@codeweavers.com:
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.)
Am Sonntag, 14. Juni 2009 17:40:39 schrieb Henri Verbeet:
2009/6/14 Stefan Dösinger ste...@codeweavers.com:
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
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;
-
2009/5/26 Pavel Prochazka proch...@inf.upol.cz:
+»··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:
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
2008/12/17 Pauli Nieminen suok...@gmail.com:
+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;
+
+
On Wed, Dec 17, 2008 at 10:51 AM, Henri Verbeet hverb...@gmail.com wrote:
2008/12/17 Pauli Nieminen suok...@gmail.com:
+static inline void test_create_vshader_version_check(IDirect3DDevice9
*device_ptr, const D3DCAPS9 *caps,
+const DWORD version, const DWORD *shader_code)
+{
+
2008/12/17 Pauli Nieminen suok...@gmail.com:
On Wed, Dec 17, 2008 at 10:51 AM, Henri Verbeet hverb...@gmail.com 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
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
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_caps)(...)
It
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 on textures
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 for
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
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,
+
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,
Ivan Gyurdiev ivg231 at 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:
On 10/28/06, Mirek [EMAIL PROTECTED] wrote:
Yes I did that this way. I tried it three times as it is now in CVS
(3DMark 2003 and Flatout 2 not working) and three times without this
patch (only) (3DMark 2003 and Flatout 2 works just perfect).
Mirek
I see the same thing as Mirek, 3dmark03 is
I see the same thing as Mirek, 3dmark03 is totally broken now.
And yes I tested GLSL and ARB and before and after with the same results as his.
So yes, this is a major regression :D
Tom
Tom Wickline wrote:
I see the same thing as Mirek, 3dmark03 is totally broken now.
And yes I tested GLSL and ARB and before and after with the same
results as his.
So yes, this is a major regression :D
When testing with the GLSL backend, can you please do a +d3d_shader
trace, find the
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
Mirek
Ivan Gyurdiev napsal(a):
Tom Wickline wrote:
I see the same thing as Mirek, 3dmark03 is totally broken now.
And
1 - 100 of 129 matches
Mail list logo
