I retract my claim of fixing that bug, but the patch still fixes the
test / crashes / has great merit otherwise.
--Matt
On 11/27/06, Matt Finnicum <[EMAIL PROTECTED]> wrote:
This fixes an occasional crash/assertion in richedit that has been
around for a while. It also fixes a conformance test.
"Anatoly" <[EMAIL PROTECTED]> wrote:
+static struct codepair {
+unsigned short keysym;
+ unsigned short ucs;
+} keysymtab[] = {
Nothing prevents to make the keysymtab[] a const data.
--
Dmitry.
"Anatoly" <[EMAIL PROTECTED]> wrote:
--- x11drv.h 8 Nov 2006 20:14:19 - 1.10
+++ x11drv.h 24 Nov 2006 09:38:39 -
@@ -19,6 +19,8 @@
* Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA
*/
+#include
You can't do that, a comment 2 lines further in that file expl
"James Hawkins" <[EMAIL PROTECTED]> wrote:
Thanks for these patches Dmitry! I'll try it out.
Please take into account that the only patch you need and which
hasn't been committed is the [6/6] one.
--
Dmitry.
On 11/27/06, Dmitry Timoshkov <[EMAIL PROTECTED]> wrote:
"James Hawkins" <[EMAIL PROTECTED]> wrote:
>> "James Hawkins" <[EMAIL PROTECTED]> wrote:
>>
>> > Ah ordinals, for this dll it's not a big deal because (probably) all
>> > apps get the export by name instead of ordinal. For the installers
"James Hawkins" <[EMAIL PROTECTED]> wrote:
"James Hawkins" <[EMAIL PROTECTED]> wrote:
> Ah ordinals, for this dll it's not a big deal because (probably) all
> apps get the export by name instead of ordinal. For the installers
> I've seen that's the case, and I can't imagine any app working on
Here's a patch that disables domdoc_createProcessingInstruction() when
libxml2 does not have xmlNewDocPI(). Do I need to modify
wine/configure as well?
On 11/27/06, Lei Zhang <[EMAIL PROTECTED]> wrote:
domdoc.c:domdoc_createProcessingInstruction() uses xmlNewDocPI() from
libxml2. This feature wa
H. Verbeet wrote:
On 28/11/06, Markus Amsler <[EMAIL PROTECTED]> wrote:
The following patches remove refcounting in wined3d Getters. The
Setters/Creaters refcounting can't be removed right now, because of the
way implicit surfaces are currently handled.
The idea is to simplify the d3dx<->wined
> - Mixing ARB and GLSL backends is pretty silly as well.
Why? I believe you can e.g. perfectly mix GLSL vertex programs together
with multitexturing setups.
ARB as in ARB_vertex_program or ARB_fragment_program, I'm not sure
what multitexturing has to do with it. You can't, for example,
proper
On 28/11/06, Frank Richter <[EMAIL PROTECTED]> wrote:
On 27.11.2006 23:53, H. Verbeet wrote:
> Either way, you're not going to be
> using software vertex shaders together with HW pixel shaders, that's
> just silly.
Fun fact: a lot of Intel chips (up to the i945 I believe) have fragment
program s
On 28/11/06, Markus Amsler <[EMAIL PROTECTED]> wrote:
The following patches remove refcounting in wined3d Getters. The
Setters/Creaters refcounting can't be removed right now, because of the
way implicit surfaces are currently handled.
The idea is to simplify the d3dx<->wined3d refcount relation
On 27.11.2006 23:53, H. Verbeet wrote:
> Either way, you're not going to be
> using software vertex shaders together with HW pixel shaders, that's
> just silly.
Fun fact: a lot of Intel chips (up to the i945 I believe) have fragment
program silicon but none for vertex programs - reality can be rea
I thought we discussed on IRC why this is a bad idea? Anyway, you
can't do this. Removing the AddRef in QueryInterface is a pretty
blatant violation of COM specs, and is pretty sure to cause problems
somewhere. The caller of that function won't always know if the object
it's called on is a wined3d
On 28/11/06, Ivan Gyurdiev <[EMAIL PROTECTED]> wrote:
H. Verbeet wrote:
That's because they're shaders v1 instructions, which are being phased
out [ not applicable to glsl backend at all ].
But of course we still have to support them.
Old things should be
layered on new infrastructure, so thos
On 28/11/06, Ivan Gyurdiev <[EMAIL PROTECTED]> wrote:
> - Software shaders currently simply don't work. If we do get software
> shaders it'll likely be vertex only.
So, we should allow hardware pixel shaders, and software vertex shaders.
> I could see
> someone using software vertex shaders if h
H. Verbeet wrote:
On 27/11/06, Ivan Gyurdiev <[EMAIL PROTECTED]> wrote:
H. Verbeet wrote:
> There are a couple of instructions that have to sample from a texture,
> right now most of them duplicate that code, and hardcode the texture
> type.
>
> Changelog:
> - Create a separate function for sam
- Software shaders currently simply don't work. If we do get software
shaders it'll likely be vertex only.
So, we should allow hardware pixel shaders, and software vertex shaders.
I could see
someone using software vertex shaders if he's got no hardware support
for shaders, although it's ques
On 27/11/06, Ivan Gyurdiev <[EMAIL PROTECTED]> wrote:
H. Verbeet wrote:
> There are a couple of instructions that have to sample from a texture,
> right now most of them duplicate that code, and hardcode the texture
> type.
>
> Changelog:
> - Create a separate function for sampling a texture
You
On 27/11/06, Ivan Gyurdiev <[EMAIL PROTECTED]> wrote:
H. Verbeet wrote:
Imho there should be either ps_selected/vs_selected flags, or
shader_backend flag, but definitely not both [ does not make sense ].
Well, yes, that's the idea. Unfortunately the ps_selected/vs_selected
flags are still used i
H. Verbeet wrote:
There are a couple of instructions that have to sample from a texture,
right now most of them duplicate that code, and hardcode the texture
type.
Changelog:
- Create a separate function for sampling a texture
You should continue to use "add_param" or "get_register_name". There
domdoc.c:domdoc_createProcessingInstruction() uses xmlNewDocPI() from
libxml2. This feature was added in libxml2 version 2.6.15. (released
about 2 years ago) Anyone using an older distro with an outdated
libxml2 (e.x. RHEL 3) will not be able to compile this code.
On 11/16/06, Huw Davies <[EMAIL
H. Verbeet wrote:
Changelog:
- Select the right shader backend when creating the device
Imho there should be either ps_selected/vs_selected flags, or
shader_backend flag, but definitely not both [ does not make sense ].
I'd opt for allowing different backends on pshader vs vshader. Maybe the
Wow, I am impressed those patches fixed almost all tests in 3DMark 2003,
test4 (mother nature), vertex shader and Ragtroll without any regression
in other apps. Perfect work!
Mirek
H. Verbeet napsal(a):
The current code for texm3x3tex doesn't handle projected textures, and
actually uses the w
Hi,
could a wiki admin please delete StartSeite on the wiki.
According to http://wiki.winehq.org/HelpOnLanguages the wiki would use
the english FrontPage if StartSeite doesn't exist.
The german FrontPage isn't needed as the users don't get any information
about wine there.
Karsten
Stefan Dösinger wrote:
> * sRGB textures: Dirtifies the sampler. All textures have now information
> about how many samplers they are bound to, and the number of one of the
> samplers. Phil?
>
> Stefan
I still have my sRGB patch but haven't been working on it mainly just
because I've been busy wi
Am Montag 27 November 2006 16:20 schrieben Sie:
> I'm not directly opposed to the current setup, it's more that I'm
> wondering if going for separate tables for related states would
> perhaps result in cleaner / more flexible code. It would of course
> allow you to get rid of those macros :-)
Not s
Vitaliy Margolen <[EMAIL PROTECTED]> writes:
> So in the end this is Alexandre's call. All I can do is present my
> solution. And let him decide how he wants to fix this major show-stopper.
If xdg-utils can be used, then that seems clearly preferable to
reinventing them ourselves. Even if it's a
On 27/11/06, Stefan Dösinger <[EMAIL PROTECTED]> wrote:
Am Montag 27 November 2006 13:04 schrieb H. Verbeet:
> I had a very brief look at the code, pertially because a tarred up
> directory isn't the most convenient way to spot what has changed and
> what is still the same.
I can of course send y
On 27/11/06, Mirek <[EMAIL PROTECTED]> wrote:
It is working, only demo version (you cant use full version), and only
demo can run on my system with GLSL.
Mirek
Ah yes, I think Tom mentioned that the demo does work. I was thinking
about the actual game tests.
I do know what caps it needs, and t
It is working, only demo version (you cant use full version), and only
demo can run on my system with GLSL.
Mirek
H. Verbeet napsal(a):
On 27/11/06, Stefan Dösinger <[EMAIL PROTECTED]> wrote:
Am Montag 27 November 2006 13:36 schrieben Sie:
> Here is log from 3DMark 2005, some new games are no
Am Montag 27 November 2006 13:07 schrieb H. Verbeet:
> On 27/11/06, Stefan Dösinger <[EMAIL PROTECTED]> wrote:
> > Ah yeah, The list_move thing is outside of wined3d. The attached patch is
> > needed. I think I'll send that patch to wine-patches too.
> >
> > Warning, the patch causes a full wine re
Am Montag 27 November 2006 13:04 schrieb H. Verbeet:
> I had a very brief look at the code, pertially because a tarred up
> directory isn't the most convenient way to spot what has changed and
> what is still the same.
I can of course send you my 45 patches too, but they are pretty messy because
I
Am Montag 27 November 2006 14:47 schrieben Sie:
> On 27/11/06, Stefan Dösinger <[EMAIL PROTECTED]> wrote:
> > Am Montag 27 November 2006 13:36 schrieben Sie:
> > > Here is log from 3DMark 2005, some new games are not working with those
> > > patches, 3DMark 2001 works but very bad in high details t
On 27/11/06, Stefan Dösinger <[EMAIL PROTECTED]> wrote:
Am Montag 27 November 2006 13:36 schrieben Sie:
> Here is log from 3DMark 2005, some new games are not working with those
> patches, 3DMark 2001 works but very bad in high details tests.
05 fails because of pixel shaders / glsl,
Eh? 3DMark0
- Oorspronkelijk bericht -
Van: Markus Amsler <[EMAIL PROTECTED]>
Datum: zaterdag, november 25, 2006 11:05 pm
Onderwerp: Re: sfd2ttf
> [EMAIL PROTECTED] wrote:
> > Hi,
> >
> >>From the buglist I gather that the fontforge dependency is still
> an issue.
> >
> > I've taken a look at the
I had a very brief look at the code, pertially because a tarred up
directory isn't the most convenient way to spot what has changed and
what is still the same.
A few things I noticed:
- markDirty() should probably either be a proper method of the
device, or have a prefix
- "States" is a pretty
Am Montag 27 November 2006 13:36 schrieben Sie:
> Here is log from 3DMark 2005, some new games are not working with those
> patches, 3DMark 2001 works but very bad in high details tests.
05 fails because of pixel shaders / glsl, and I know that 2001 is broken
because my patch doesn't care for offs
On 27/11/06, Stefan Dösinger <[EMAIL PROTECTED]> wrote:
Ah yeah, The list_move thing is outside of wined3d. The attached patch is
needed. I think I'll send that patch to wine-patches too.
Warning, the patch causes a full wine recompile because nearly every lib uses
list.h
Shouldn't you just mo
Am Montag 27 November 2006 12:02 schrieben Sie:
> Hi I cant compile it with actual CVS head.
>
> drawprim.o: In function `drawPrimitive':
> /usr/src/wine/dlls/wined3d/drawprim.c:1696: undefined reference to
> `list_move'
> collect2: ld returned 1 exit status
> winegcc: gcc failed.
> make: *** [wine
Hi I cant compile it with actual CVS head.
drawprim.o: In function `drawPrimitive':
/usr/src/wine/dlls/wined3d/drawprim.c:1696: undefined reference to
`list_move'
collect2: ld returned 1 exit status
winegcc: gcc failed.
make: *** [wined3d.dll.so] Error 2
Mirek
Stefan Dösinger napsal(a):
Hi,
On Sat, 2006-11-25 at 19:36 -0700, Vitaliy Margolen wrote:
> It seems there is no end to how far will packagers go to brake Wine by
> trying to make it better
>
> I thought it's been fixed a long time ago, but it seems not. Wine
> packages for Debian split important Wine parts into separate packag
Hi,
In the past days I've been hacking on implementing my state management ideas,
and I think I've come to a state where I don't have to be completely ashamed
of my patches :-)
First, what the code does NOT do yet:
* Pixel Shaders, GLSL shaders: I only had my notebook with the M9 available,
so
On Monday 27 November 2006 08:39, Kai Blin wrote:
> On a side note, broadcasting for servers seems to fail (i.e. never
> produces a packet). This seems to be a winsock problem, too.
I don't have a Windows box with multiple NICs set up anywhere, but it seems
like either our winsock implementation
43 matches
Mail list logo
