Mike McCormack [EMAIL PROTECTED] wrote:
>> +SetLastError(ERROR_CALL_NOT_IMPLEMENTED);
>> +return ERROR_CALL_NOT_IMPLEMENTED;
>> +}
>
>You SetLastError or return an error code, not both.
This is not always correct. Win32 API has several functions returning
an int where the only SDK documen
Vitaly wrote:
>Build system in ALT Linux has strict requires to use rpath and last changes in
>wine conflicts with it.
Can you explain more about ALT Linux's build system and rpath?
Does it disallow all use of rpath by applications?
- Dan
--
Wine for Windows ISVs: http://kegel.com/wine/isv
Also, please disable your challenge/response spam "filter". Solving
your spam problem by spamming everybody else is not cool. You wrote to
us with a patch, you solicited our response, so why are you spamming us
back?
I'd advise others to not respond to spam from bluebottle.com.
Mike
"MattK" <[EMAIL PROTECTED]> wrote:
+if(fdwReason == DLL_THREAD_ATTACH)
+{
+DisableThreadLibraryCalls(hinstDLL);
+return TRUE;
+}
This is not an appropriate place to call DisableThreadLibraryCalls,
how did you come with it when there are a lot of examples in the Wine
"Rein Klazes" <[EMAIL PROTECTED]> wrote:
+ srcpixel = (const DWORD*)((int)srcpixel & 0xfffc);
It would be more readable IMO to use ~3 instead of 0xfffc.
--
Dmitry.
The recent patch:
http://winehq.org/pipermail/wine-patches/2006-February/024656.html
can cause linker errors for the two symbols glStencilOpSeparate and
glStencilFuncSeparate. The reason being that these are only exported in OpenGL
2.0 compatible libraries, and in particular, are not present in
MattK wrote:
+BOOL WINAPI DnsNameCompare_A(LPSTR pName1, LPSTR pName2)
+{
+TRACE("(%s %s)\n",pName1, pName2);
+
+LPSTR name1 = pName1;
+LPSTR name2 = pName2;
+
+RemovePeriods(name1);
+RemovePeriods(name2);
+
+int equal;
+
+equal = lstrcmpiA(name1,name2);
+
+retur
On Wednesday 01 March 2006 11:48, Vitaly Budovski wrote:
> H. Verbeet wrote:
> > Although #ifdef GL_VERSION_2_0 will make compilation work with older
> > OpenGl headers, it's not the way to fix this. Basically, wined3d
> > should check for functionallity during runtime with GL_SUPPORT and
> > call
On Wednesday 01 March 2006 11:48, Vitaly Budovski wrote:
> H. Verbeet wrote:
> > Although #ifdef GL_VERSION_2_0 will make compilation work with older
> > OpenGl headers, it's not the way to fix this. Basically, wined3d
> > should check for functionallity during runtime with GL_SUPPORT and
> > call
Alexandre Julliard wrote:
Eric Pouech <[EMAIL PROTECTED]> writes:
- split dbg_main_loop in two parts (one for finishing the debuggee
attachment, the second one really for handling the main loop)
- removed now longer needed dbg_main_loop
Auto mode is still broken with this patch... did you
On Wed, 2006-03-01 at 20:50 +0300, Vitaly Lipatov wrote:
> Dear Mike, I asked Alexandre to add _option_ to configure for disable rpath
> but to remove rpath using.
I understand the request, but the question remains - why are you asking
every single upstream author to add complexity to their build
В сообщении от 1 марта 2006 21:25 Mike Hearn написал(a):
> On Wed, 2006-03-01 at 20:50 +0300, Vitaly Lipatov wrote:
> > Dear Mike, I asked Alexandre to add _option_ to configure for disable
> > rpath but to remove rpath using.
>
> I understand the request, but the question remains - why are you ask
On 01/03/06, Vitaly Budovski <[EMAIL PROTECTED]> wrote:
> +
> glPolygonOffset(*((float*)&This->stateBlock->renderState[WINED3DRS_SLOPESCALEDEPTHBIAS]),
> tmpvalue.f);
Does this compile?
On 01/03/06, Vitaly Budovski <[EMAIL PROTECTED]> wrote:
> wined3d: Add function pointers to glSupportOpSeparate and
> glSupportFuncSeparate
>
That's not going to help much if you don't actually use them. Also,
you probably want to be able to detect if the functions are actually
available, instead o
В сообщении от 1 марта 2006 17:23 Mike Hearn написал(a):
> On Fri, 24 Feb 2006 21:11:39 +0300, Vitaly Lipatov wrote:
> > Sorry for my English. It is useful when we run wine from the source tree.
>
> It's useful for people distributing Wine binaries as well. Not every
> feature is there for the dist
On Fri, 24 Feb 2006 21:11:39 +0300, Vitaly Lipatov wrote:
> Sorry for my English. It is useful when we run wine from the source tree.
It's useful for people distributing Wine binaries as well. Not every
feature is there for the distros you know ... also asking developers to
disable rpath because R
On Tue, 28 Feb 2006 12:38:13 +0100, you wrote:
>This will badly hurt performance, you don't want to check alignment on
>every pixel. You should only check on the first one and copy 1 to 3
>pixels as needed to align things properly, then do the 4 pixels at a
>time thing.
Yes, it was rather optimiz
Stefan Dösinger gmx.at> writes:
>
> > If you want a hand with OpenGL stuff some more Stefan, I'd be glad to help.
> > We could set up a time to chat/irc off-list or if you want I could see if
> > I can get your existing stuff to work (just send me the diffs).
> I'll publish a patch in the next
> If you want a hand with OpenGL stuff some more Stefan, I'd be glad to help.
> We could set up a time to chat/irc off-list or if you want I could see if
> I can get your existing stuff to work (just send me the diffs).
I'll publish a patch in the next days, I just want to fix S3TC decompression
H. Verbeet wrote:
Although #ifdef GL_VERSION_2_0 will make compilation work with older
OpenGl headers, it's not the way to fix this. Basically, wined3d
should check for functionallity during runtime with GL_SUPPORT and
call extensions with GL_EXTCALL. The issue has come up a few times
before with
Stefan Dösinger gmx.at> writes:
>
> > Hi. I've been dealing with a program that seems to be very slow at
> > Blitting images onto a D3D surface. Unfortunately, this is not my code
> > so I can't fix it. Would the above mentioned BltFast/CopyRect patches
> > deal with code that attempts to provid
Hi,
> For those intested here is a quick patch against dlls/wined3d/utils.c, I'll
> submit an "official" one to wine-patches later, in the meantime feedback is
> appreciated.
I planned sending a similar patch which looked quite the same, but I'll let
you do this.
pgpIsDFqeKgNW.pgp
Description: P
Hi,
> Its actually an i865 and "must remain" an i865. Its amazing, the 3D
> performance (with shadows and all) is pretty fast if I disable the code
> that results in the screen blits.
I have never used an Intel chip, so I can't judge about it's speed.
> If you'd like, I'd be willing to help out if
Raphael club-internet.fr> writes:
> But we must fix all the RGB v.s. BGR problems
I'll submit a patch for this when I get home. I verified it with Age of
Mythology and the latest CVS (well, from a few days ago). There are just a
couple of mistakes in d3d8/utils.c (whoops this file is gone now,
Brandon Woodmansee <[EMAIL PROTECTED]> writes:
> + case EM_AUTOURLDETECT:
> + {
> +if (wParam==1)
> +{
> +editor->AutoURLDetect_bEnable=1;
> +return 0;
> +}
> +
> +if (wParam==0)
> +{
> +editor->AutoURLDetect_bEnable=0;
> + return 0;
> +}
Eric Pouech <[EMAIL PROTECTED]> writes:
> - split dbg_main_loop in two parts (one for finishing the debuggee
> attachment, the second one really for handling the main loop)
> - removed now longer needed dbg_main_loop
Auto mode is still broken with this patch... did you really test it?
--
Alex
On Thu, 26 Jan 2006, Peter Åstrand wrote:
Hi. I'm trying to get the EaseReader application
(http://www.dolphinaudiopublishing.com/products/EaseReader/) running in Wine.
By using the native oleacc, oleaut32 and rpcrt4, it's now actually possible
to start the application. The "self voicing" mode
Its actually an i865 and "must remain" an i865. Its amazing, the 3D
performance (with shadows and all) is pretty fast if I disable the code
that results in the screen blits.
It looks like it may actually be running them through some "Stretch
Blit" function. I don't know if this might translate dow
> Hi. I've been dealing with a program that seems to be very slow at
> Blitting images onto a D3D surface. Unfortunately, this is not my code
> so I can't fix it. Would the above mentioned BltFast/CopyRect patches
> deal with code that attempts to provide this feature?
Is it ddraw or d3d8/d3d9? Do
On Wednesday 01 March 2006 05:48, Al Tobey wrote:
> I just tried the new d3d8 code with FFXiBench3 again tonight and it's
> pretty good!The textures are mostly there and there are only a
> handful of recurring glitches.This demo is downloadable from
> http://www.playonline.com.
>
> Some tex
30 matches
Mail list logo
