On 2 September 2013 23:04, Matteo Bruni mbr...@codeweavers.com 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.0,0.0,
+ 0.0,0.0, 0.1,
On Tue, Sep 3, 2013 at 7:27 PM, Qian Hong fract...@gmail.com wrote:
Hi Jacek, we already have a debug channel atl100 for atl100.dll, but
we currently use atl for both atl.dll and atl80.dll, do you think it
is better to use atl for all, or one debug channel per each dll?
Oh, I just found
+WINE_DEFAULT_DEBUG_CHANNEL(atl);
Hi Jacek, we already have a debug channel atl100 for atl100.dll, but
we currently use atl for both atl.dll and atl80.dll, do you think it
is better to use atl for all, or one debug channel per each dll?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 2013-09-03 09:47, schrieb Henri Verbeet:
This originally came from the ARB fragment program implementation,
but I don't see a justification for clamping there either. For the
texture formats typically used with the fixed function pipe
clamping
On 09/03/13 13:28, Qian Hong wrote:
On Tue, Sep 3, 2013 at 7:27 PM, Qian Hong fract...@gmail.com wrote:
Hi Jacek, we already have a debug channel atl100 for atl100.dll, but
we currently use atl for both atl.dll and atl80.dll, do you think it
is better to use atl for all, or one debug channel
On 3 September 2013 13:31, Stefan Dösinger stefandoesin...@gmail.com wrote:
The idea behind the clamps is that the fixed function pipeline is
generally limited to the [0.0;1.0] range. bbf313e7 added a test for
that, and there was e.g. 14706 (which doesn't contain much info tbh).
Yes, but
On Tue, Sep 3, 2013 at 7:42 PM, Jacek Caban ja...@codeweavers.com wrote:
Not really, good catch. We should make them consistent. Honestly, I'm
not sure which one is better. Both have their problems. Some functions
are forwarded, others are not, so having one debug channel would be
guarantee
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 2013-09-03 13:41, schrieb Henri Verbeet: It ends up being a
performance bottleneck in some cases. This is
particularly visible in the 3DMark03 multi-texture fill-rate test,
in other cases the impact is usually a bit more modest.
That's
On Mon, 02 Sep 2013 15:55:18 +0200
Stefan Dösinger stefandoesin...@gmail.com wrote:
You can test the attached patches by applying them (git am
/path/to/patches/*)
Third patch doesn't apply:
Applying: wined3d: Don't mess with the device in buffer_create_buffer_object
Applying: wined3d: Don't
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 2013-09-03 15:57, schrieb Rosanne DiMesio:
On Mon, 02 Sep 2013 15:55:18 +0200 Stefan Dösinger
stefandoesin...@gmail.com wrote:
You can test the attached patches by applying them (git am
/path/to/patches/*)
Third patch doesn't apply:
2013/9/3 Henri Verbeet hverb...@gmail.com:
On 2 September 2013 23:04, Matteo Bruni mbr...@codeweavers.com 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.0,
On Tue, 3 Sep 2013 08:57:48 -0500
Rosanne DiMesio dime...@earthlink.net wrote:
Third patch doesn't apply:
Nevermind. I figured out my mistake (overlooked the part about applying to
1.7.1).
--
Rosanne DiMesio dime...@earthlink.net
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 2013-09-03 17:33, schrieb Henri Verbeet:
On 3 September 2013 14:07, Stefan Dösinger ste...@codeweavers.com
wrote:
I'm checking this in d3d9/d3d8/ddraw because we create textures
for everything nowadays, even stand-alone surfaces.
For ddraw
On 3 September 2013 17:45, Stefan Dösinger ste...@codeweavers.com wrote:
My main issue with a WINED3DUSAGE_TEXTURE flag is that
create_texture(USAGE_TEXTURE) seems a bit weird - we might as well
call it create_texture(USAGE_I_REALLY_MEAN_IT).
If that's the main issue, I could tell you that it
On 3 September 2013 14:07, Stefan Dösinger ste...@codeweavers.com wrote:
I'm checking this in d3d9/d3d8/ddraw because we create textures for
everything nowadays, even stand-alone surfaces.
For ddraw that's not true yet, but I think my preferred way to handle
this would be to introduce a
Hello,
-ME_EndToUnicode(unicode, wszText);
+unicode ? ME_EndToUnicode(1200, wszText) : ME_EndToUnicode(CP_ACP,
wszText);
Personally I dislike this stuff in C code. Especially when you could
make it shorter:
ME_EndToUnicode(unicode ? 1200 : CP_ACP, wszText)
-- Ph.
Bruno Jesus 00cp...@gmail.com writes:
try 2:
Narrow the loop for the specified protocol
Add a new test for invalid sockets
Considering what WSAEnumProtocols does, the loop doesn't seem necessary
at all.
--
Alexandre Julliard
julli...@winehq.org
On Tue, Sep 3, 2013 at 3:16 PM, Bruno Jesus 00cp...@gmail.com wrote:
On Tue, Sep 3, 2013 at 3:04 PM, Alexandre Julliard julli...@winehq.org
wrote:
Bruno Jesus 00cp...@gmail.com writes:
try 2:
Narrow the loop for the specified protocol
Add a new test for invalid sockets
Considering what
Bruno Jesus 00cp...@gmail.com writes:
On Tue, Sep 3, 2013 at 3:16 PM, Bruno Jesus 00cp...@gmail.com wrote:
On Tue, Sep 3, 2013 at 3:04 PM, Alexandre Julliard julli...@winehq.org
wrote:
Bruno Jesus 00cp...@gmail.com writes:
try 2:
Narrow the loop for the specified protocol
Add a new test
On Tue, Sep 3, 2013 at 3:34 PM, Alexandre Julliard julli...@winehq.org wrote:
Bruno Jesus 00cp...@gmail.com writes:
On Tue, Sep 3, 2013 at 3:16 PM, Bruno Jesus 00cp...@gmail.com wrote:
On Tue, Sep 3, 2013 at 3:04 PM, Alexandre Julliard julli...@winehq.org
wrote:
Bruno Jesus
On Tue, Sep 3, 2013 at 4:57 PM, Charles Davis cdavi...@gmail.com wrote:
On Sep 3, 2013, at 1:30 PM, Bruno Jesus wrote:
On Tue, Sep 3, 2013 at 4:26 PM, Charles Davis cdavi...@gmail.com wrote:
You mean removing protocol.c and adding all content to socket.c? If
yes I would appreciate if you
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 2013-09-03 17:54, schrieb Henri Verbeet:
If that's the main issue, I could tell you that it will most
likely end up being renamed WINED3D_BIND_SHADER_RESOURCE at some
point, equivalent to the d3d10+ bind flags.
That works for the name. The other
On Sep 3, 2013, at 12:37 PM, Bruno Jesus wrote:
On Tue, Sep 3, 2013 at 3:34 PM, Alexandre Julliard julli...@winehq.org
wrote:
Bruno Jesus 00cp...@gmail.com writes:
On Tue, Sep 3, 2013 at 3:16 PM, Bruno Jesus 00cp...@gmail.com wrote:
On Tue, Sep 3, 2013 at 3:04 PM, Alexandre Julliard
On Tue, Sep 3, 2013 at 4:26 PM, Charles Davis cdavi...@gmail.com wrote:
You mean removing protocol.c and adding all content to socket.c? If
yes I would appreciate if you could do that because I don't have the
git skills and wouldn't now how to sort the functions inside socket.c.
It's not that
On Sep 3, 2013, at 1:30 PM, Bruno Jesus wrote:
On Tue, Sep 3, 2013 at 4:26 PM, Charles Davis cdavi...@gmail.com wrote:
You mean removing protocol.c and adding all content to socket.c? If
yes I would appreciate if you could do that because I don't have the
git skills and wouldn't now how to
Anastasius mentioned at
http://bugs.winehq.org/show_bug.cgi?id=32673#c6 that a keyword for
bugs that are caused by applications using broken/deprecated behavior
might be useful. I'm in favor of it, but wanted some more opinions
(and potentially a better naming scheme).
Comments/opinions?
--
Austin English austinengl...@gmail.com wrote:
Anastasius mentioned at
http://bugs.winehq.org/show_bug.cgi?id=32673#c6 that a keyword for
bugs that are caused by applications using broken/deprecated behavior
might be useful. I'm in favor of it, but wanted some more opinions
(and potentially a
Hi Phil,
2013/9/4 Phil Krylov p...@newstar.rinet.ru
Hello,
-ME_EndToUnicode(unicode, wszText);
+unicode ? ME_EndToUnicode(1200, wszText) :
ME_EndToUnicode(CP_ACP, wszText);
Personally I dislike this stuff in C code. Especially when you could
make it shorter:
28 matches
Mail list logo
