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
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 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 packages:
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,
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: ***
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
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
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
- 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 sources and I
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? 3DMark05
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 tests.
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 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 recompile
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 not
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
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 you
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 bit
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 so
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 with
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
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
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:
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
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 in
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 should
- 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
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 sampling a
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 he's
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 those
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
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
- 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,
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-wined3d
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 both
Home
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
I've seen that's
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 config.h
You can't do that, a comment 2 lines further in that file
Anatoly [EMAIL PROTECTED] wrote:
+static struct codepair {
+unsigned short keysym;
+ unsigned short ucs;
+} keysymtab[] = {
Nothing prevents to make the keysymtab[] a const data.
--
Dmitry.
37 matches
Mail list logo
