I think I'm ok with the gpl/agpl v3 change. Are there any other people
using the appdb code that this might affect?
Chris
On Nov 23, 2007 10:34 PM, Alexander Nicolaysen Sørnes
<[EMAIL PROTECTED]> wrote:
> On Saturday 24 November 2007 04:01:24 Trent Waddington wrote:
> > interesting. Do you hav
On Saturday 24 November 2007 04:01:24 Trent Waddington wrote:
> interesting. Do you have a list of contributors and their signoff on
> this license change?
>
> Or is it just you two?
>
Well I didn't think that was necessary; but after some thought I realize that
the AppDB only seemed to include
OK, long time lurker, only recently decided to try my hand at coding for
wine.
Picked a bug 9628 and decided to have a bash.
Bug occured because a patch to the msiexec command line parsing was
reverted due to regressions in the xlviewer installer and other apps. I
don't know about the other apps,
Roderick Colenbrander wrote:
> The main reason why the D3DX_CAPABLE macros should be used before checking
> the renderer string is that not in all cases all extensions are around while
> the rendering string can still be the same.
I think it's is quite difficult to say for sure what will be bett
> Roderick Colenbrander wrote:
> > I think the code should be like this (in pseudo code) this way also
> other cards will at least be classified:
> >
> > case VENDOR_MESA:
> > if(D3D9_CAPABLE(gl_info)
> >if(strstr(gl_info->gl_renderer, "R300"))
> >card = radeon_9500;
> >
Roderick Colenbrander wrote:
> I think the code should be like this (in pseudo code) this way also other
> cards will at least be classified:
>
> case VENDOR_MESA:
> if(D3D9_CAPABLE(gl_info)
>if(strstr(gl_info->gl_renderer, "R300"))
>card = radeon_9500;
>else
>
> This is an updated version of my previous patch for the same purpose.
>
> The proposed code now uses the WINE_D3DX_CAPABLE macros instead of DRI
> module names for guessing the exact card model which is to be returned.
> The patch also no longer includes manual addition of an entry to the
> C
Dan Kegel wrote:
> Anatoly,
> thank you for working to fix "start" to work better for Unicode,
> I should have done that originally.
>
>
You are welcome. :)
> But you seem to be having trouble getting the patch in,
> so here's what little advice I can give:
>
> If there is any difference between
Anatoly,
thank you for working to fix "start" to work better for Unicode,
I should have done that originally.
But you seem to be having trouble getting the patch in,
so here's what little advice I can give:
If there is any difference between versions of your patch,
you should describe it in the p
On 23/11/2007, Stefan Dösinger <[EMAIL PROTECTED]> wrote:
> Am Freitag, 23. November 2007 12:25:34 schrieb H. Verbeet:
> > Just to add something to that, most of the issues that are there are
> > with older versions of Direct3D and fixed function. The more modern
> > functionality is relatively eas
Am Freitag, 23. November 2007 12:25:34 schrieb H. Verbeet:
> Just to add something to that, most of the issues that are there are
> with older versions of Direct3D and fixed function. The more modern
> functionality is relatively easier to translate because D3D and GL
> simply expose the programma
Alexandre Julliard wrote:
> No, what you need is one function for errors that can happen in normal
> usage (file not found, invalid option etc.) that is Unicode and
> localized, and one function for internal errors (LoadString failures
> etc.) that simply uses WINE_ERR with an English message.
>
>
> Roderick Colenbrander wrote:
> > I would really ask you to use the D3DX_CAPABLE() macros as not using
> them can result in bad problems. E.g. a game assuming a certain d3d
> functionality is there while it isn't backed by any GL extension.
> >
> You certainly do have a point. I will redo the p
The problem with all that is that DirectX is tightly integrated into
Windows-specific components, and therefore the only level that it could
exist is along the rest of the Wine layer. I also wish to note that AMD
isn't releasing radeon drivers, they had Novell develop a WHOLE NEW driver
for the ATI
On 23/11/2007, Stefan Dösinger <[EMAIL PROTECTED]> wrote:
> Hi,
> Implementing Direct3D at driver level won't magically fix things. The issues
> will be still the same: Undocumented or incorrectly documented behavior of
> Direct3D and broken apps which rely on defined results in per se undefined
>
On 23/11/2007, Remco <[EMAIL PROTECTED]> wrote:
> I don't know the first thing about driver- and DirectX-programming, so please
> forgive (and point out) any mistakes.
>
> As a reader of this list I'm wondering; there are quite a few problems that
> come from the fact that DirectX isn't 1:1 trans
Hi,
Implementing Direct3D at driver level won't magically fix things. The issues
will be still the same: Undocumented or incorrectly documented behavior of
Direct3D and broken apps which rely on defined results in per se undefined
situations. There are only a handful of cases where OpenGL<->Dire
17 matches
Mail list logo
