Re: Something's rotten in git today...
Le 19/09/2011 14:35, Bernhard Loos a écrit : This patch should fix the problem: http://source.winehq.org/patches/data/79042 I switched it back to use nonoverlapped named pipe functions, as only the ConnectNamedPipe operation actually needs the overlapped mode, so I used a dedicated thread for it. The other option would be to create the overlapped completation event for each read/write operation, but this would result in a lot more overhead. Bernhard Hello. See the patch I sent on Friday. I guess now it's Alexandre choice between the two solutions. Regards. Jérôme.
Re: [PATCH] rpcrt4/rpc_transport.c: the named pipe can be used for multiple operations at the same time, so use overlapped operations for ReadFile and WriteFile
Le 14/09/2011 14:19, Bernhard Loos a écrit : --- dlls/rpcrt4/rpc_transport.c | 53 +++--- 1 files changed, 29 insertions(+), 24 deletions(-) Hi! I had a quite similar patch, but you beat me! Anyway, aren't those funtions susceptible to be called in a multithreaded environment? If so, having an unique event for all the read or write operations seems dangerous to me. Regards. Jérôme.
[RFC] Re: [PATCH 1/2]rpcrt4/tests: Add some commented tests for widl
Hello.
I've seen that this patch is in pending state, and I would like to
know what is the problem with it. Also, if commenting the tests isn't a
policy you want to enforce (that I would understand), I'm ready to skip
them on wine, but how to?
Those tests were made with midl from Visual Studio 10, with or without
/Os option, and ran smoothly.
http://www.winehq.org/pipermail/wine-patches/2011-August/106200.html
Regards.
Jérôme.
Le 06/09/2011 00:50, Jérôme Gardou a écrit :
Also, the added function which seems to be useless permits to detect
the problem that the next patch fixes.
Enable -Oif, and the test of server.c line 947 (after patch
application) will fail.
---
dlls/rpcrt4/tests/server.c | 46
++
dlls/rpcrt4/tests/server.idl |1 +
2 files changed, 47 insertions(+), 0 deletions(-)
diff --git a/dlls/rpcrt4/tests/server.c b/dlls/rpcrt4/tests/server.c
index eb8f061..9eaf7cc 100644
--- a/dlls/rpcrt4/tests/server.c
+++ b/dlls/rpcrt4/tests/server.c
@@ -36,6 +36,8 @@
static const char *progname;
static BOOL old_windows_version;
+/* To know if the IDL file was parsed with or without widl -Oif or midl /Oif */
+static BOOL old_midl_flags;
static HANDLE stop_event;
@@ -604,6 +606,10 @@ int __cdecl s_echo_ranged_int(int n)
return n;
}
+void __cdecl s_some_ranged_func(int n)
+{
+}
+
void __cdecl s_get_ranged_enum(renum_t *re)
{
*re = RE3;
@@ -811,6 +817,7 @@ basic_tests(void)
str_t str;
se_t se;
renum_t re;
+ unsigned long exception;
ok(int_return() == INT_CODE, RPC int_return\n);
@@ -939,6 +946,42 @@ basic_tests(void)
x = echo_ranged_int(100);
ok(x == 100, echo_ranged_int() returned %d instead of 100\n, x);
+/* Crashes on wine
+ exception = 0;
+ RpcTryExcept
+ {
+ x = echo_ranged_int(150);
+ }
+ RpcExcept(TRUE)
+ {
+exception = RpcExceptionCode();
+ }
+ RpcEndExcept
+ if(old_midl_flags)
+ {
+ok(x == 150, echo_ranged_int() returned %d instead of 0\n, x);
+ok(exception == 0, echo_ranged_int() threw an exception : %lu\n,
exception);
+ }
+ else
+ {
+ok(x == 100, echo_ranged_int() returned %d instead of throwing
exception\n, x);
+ok(exception == RPC_X_BAD_STUB_DATA, Wrong exception : %lu\n, exception);
+ }
+
+ exception = 0;
+ RpcTryExcept
+ {
+ x = echo_ranged_int(75);
+ }
+ RpcExcept(TRUE)
+ {
+exception = RpcExceptionCode();
+ }
+ RpcEndExcept
+ ok(x == 75, echo_ranged_int() returned %d instead of 0\n, x);
+ ok(exception == 0, echo_ranged_int() threw an exception : %lu\n,
exception);
+*/
+
if (!old_windows_version)
{
get_ranged_enum(re);
@@ -1626,6 +1669,9 @@ START_TEST(server)
InitFunctionPointers();
+ /* Detect -Oif flags */
+ old_midl_flags = ((RPC_SERVER_INTERFACE*)s_IServer_v0_0_s_ifspec)-Flags ==
0;
+
if (pGetUserNameExA)
{
ULONG size = 0;
diff --git a/dlls/rpcrt4/tests/server.idl b/dlls/rpcrt4/tests/server.idl
index c7c7237..39d6940 100644
--- a/dlls/rpcrt4/tests/server.idl
+++ b/dlls/rpcrt4/tests/server.idl
@@ -364,6 +364,7 @@ cpp_quote(#endif)
typedef [range(RE_MIN, RE_MAX)] enum renum renum_t;
typedef [range(0, 100)] int rint_t;
rint_t echo_ranged_int([range(0, 100)] int n);
+ void some_ranged_func([in, range(0,50)] int n);
void get_ranged_enum([out] renum_t *re);
void context_handle_test(void);
Re: widl: duplicate type in case of argument with range attribute
Hello. Maybe the comment isn't clear enough. The ranges are correctly output into the format string, but the offset of each output is lost during the processing. For instance, declaring a function like this one : DWORD Test( [in, range(0, 1024)] DWORD dwParam1, [in, range(0, 255)] DWORD dwParam2); would output both parameter declarations into the type format string with correct range values, but the offsets into the procedure format string would both point to the last one. I'll try to write a test to show this behaviour, but I'm not sure of how to integrate this in wine test suite. Note : this problem manifests itself when -Oif flag is enabled. Regards. Jérôme. Le 30/08/2011 12:46, Alexandre Julliard a écrit : Jérôme Gardoujerome.gar...@laposte.net writes: @@ -1418,6 +1418,11 @@ static var_t *declare_var(attr_list_t *attrs, decl_spec_t *decl_spec, const decl type_t *func_type = decl ? decl-func_type : NULL; type_t *type = decl_spec-type; + /* In case of a range attribute, duplicate the type to keep track of + * the min/max values in the type format string */ + if(is_attr(attrs, ATTR_RANGE)) +type = duptype(type, 1); You shouldn't need that. The range should go with the variable and be output again for each type. Please add a test case showing the problem.
Re: widl: duplicate type in case of argument with range attribute
Le 30/08/2011 17:50, Jérôme Gardou a écrit : Hello. Maybe the comment isn't clear enough. The ranges are correctly output into the format string, but the offset of each output is lost during the processing. For instance, declaring a function like this one : DWORD Test( [in, range(0, 1024)] DWORD dwParam1, [in, range(0, 255)] DWORD dwParam2); would output both parameter declarations into the type format string with correct range values, but the offsets into the procedure format string would both point to the last one. I'll try to write a test to show this behaviour, but I'm not sure of how to integrate this in wine test suite. Note : this problem manifests itself when -Oif flag is enabled. Regards. Jérôme. Le 30/08/2011 12:46, Alexandre Julliard a écrit : Jérôme Gardoujerome.gar...@laposte.net writes: @@ -1418,6 +1418,11 @@ static var_t *declare_var(attr_list_t *attrs, decl_spec_t *decl_spec, const decl type_t *func_type = decl ? decl-func_type : NULL; type_t *type = decl_spec-type; + /* In case of a range attribute, duplicate the type to keep track of + * the min/max values in the type format string */ + if(is_attr(attrs, ATTR_RANGE)) +type = duptype(type, 1); You shouldn't need that. The range should go with the variable and be output again for each type. Please add a test case showing the problem. Sorry, I forgot that the policy here was to reply after the previous mail. Anyway, I've looked into this a bit, and it seems that the place to write a proper test is rpcrt4 test suite. While writing the test would per se be very easy, the problem won't show up if -Oif isn't set on the tested idl file. Adding this to the EXTRAIDLFLAGS variable in Makefile.in would do the trick, but I doubt that this is what you want. Any hint on the way to proceed would be greatly appreciated. Regards. Jérôme
Re: rpcrt4:properly unmarshall EMUM16 discriminant
Le 29/08/2011 00:40, Michael Stefaniuc a écrit : Dan, On 08/29/2011 12:18 AM, Dan Kegel wrote: Didn't apply here: $ git apply text don't use git apply but git am. git am knows how to deal with emails and email encoded patches. fatal: corrupt patch at line 15 Looks like your email program word-wrapped both this and your other patch. Try attaching the patches instead. bye michael Hello! Should I resend it anyway? Regards. Jérôme.
Re: rpcrt4:properly unmarshall EMUM16 discriminant
Le 29/08/2011 00:49, Michael Stefaniuc a écrit : On 08/29/2011 12:45 AM, Jérôme Gardou wrote: Le 29/08/2011 00:40, Michael Stefaniuc a écrit : Dan, On 08/29/2011 12:18 AM, Dan Kegel wrote: Didn't apply here: $ git apply text don't use git apply but git am. git am knows how to deal with emails and email encoded patches. fatal: corrupt patch at line 15 Looks like your email program word-wrapped both this and your other patch. Try attaching the patches instead. Should I resend it anyway? Yes, it really is corrupt as git am doesn't likes it either. git am /tmp/rpcrt4\:properly\ unmarshall\ EMUM16\ discriminant.eml Applying: rpcrt4:properly unmarshall EMUM16 discriminant fatal: corrupt patch at line 10 bye michael Done. Hopefully this is correctly formatted now. Regards. Jérôme.
Re: faultrep:display useful information in ReportFault
Mikołaj Zalewski a écrit :
I've written a dialog about a crash some time ago to add to winedbg
(http://www.winehq.org/pipermail/wine-patches/2009-January/068073.html).
It's probably time to ask what is the status of this patch?
If this patch gets accepted (Alexandre seemed to like the previous
version, but pointed that it broke kernel32 tests because there had
been no way to disable it and he didn't have much time to review it),
maybe calling `winedbg --auto` from ReportFault would be the best way
- you would then have a dialog (the same as during a regular crash,
can be disabled from the registry), the full debugger output and an
option to run an interactive debugger. AFAIK this is the other way
round than Windows does (AFAIK drwatson loads faultrep.dll into the
process that crashed and calls ReportFault), but loading a DLL into a
process where everything could be corrupted seems a strange idea.
Jérôme Gardou pisze:
Most wine users, when their app crashes, open a bug report and attach
the console log. If the log contains information got from
ReportFault, developers will gain some time, and have the preceding
context of the call.
I'm affraid this is what is done by the 1% best users ;). I'd expect
that a typical user to complain that Linux is broken because on Linux,
from time to time, apps just disappear from the screen while on
Windows they don't. Already knowing that there is such a thing like
Wine requires some knowledge :).
Mikołaj Zalewski
Instead of reinventing the wheel, why not call kernel32 which does it
for us What do you think about this patch?
From 8d94c4a333f90cc2be6c9019f84ccc7712b5a0b2 Mon Sep 17 00:00:00 2001
From: =?utf-8?q?J=C3=A9r=C3=B4me=20Gardou?= jerome.gar...@laposte.net
Date: Mon, 23 Feb 2009 09:35:13 +0100
Subject: [PATCH] faultrep: Make ReportFault do something useful
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary=1.6.0.6
This is a multi-part message in MIME format.
--1.6.0.6
Content-Type: text/plain; charset=UTF-8; format=fixed
Content-Transfer-Encoding: 8bit
---
dlls/faultrep/faultrep.c|7 ++-
dlls/kernel32/except.c |2 +-
dlls/kernel32/kernel32.spec |3 +++
3 files changed, 10 insertions(+), 2 deletions(-)
--1.6.0.6
Content-Type: text/x-patch; name=8d94c4a333f90cc2be6c9019f84ccc7712b5a0b2.diff
Content-Transfer-Encoding: 8bit
Content-Disposition: attachment;
filename=8d94c4a333f90cc2be6c9019f84ccc7712b5a0b2.diff
diff --git a/dlls/faultrep/faultrep.c b/dlls/faultrep/faultrep.c
index d4bd713..bb896f9 100644
--- a/dlls/faultrep/faultrep.c
+++ b/dlls/faultrep/faultrep.c
@@ -37,6 +37,7 @@ static const WCHAR SZ_EXCLUSIONLIST_KEY[] = {
'E','r','r','o','r','R','e','p','o','r','t','i','n','g','\\',
'E','x','c','l','u','s','i','o','n','L','i','s','t', 0};
+
/*
* AddERExcludedApplicationW [faultr...@]
*
@@ -107,7 +108,11 @@ BOOL WINAPI AddERExcludedApplicationA(LPCSTR lpAppFileName)
*/
EFaultRepRetVal WINAPI ReportFault(LPEXCEPTION_POINTERS pep, DWORD dwOpt)
{
-FIXME(%p 0x%x stub\n, pep, dwOpt);
+LONG ret ;
+TRACE(%p 0x%x stub\n, pep, dwOpt);
+
+ret = wine_start_debugger_atomic(pep) ;
+
return frrvOk;
}
diff --git a/dlls/kernel32/except.c b/dlls/kernel32/except.c
index 21d3584..f471e05 100644
--- a/dlls/kernel32/except.c
+++ b/dlls/kernel32/except.c
@@ -347,7 +347,7 @@ EXIT:
*
* returns TRUE for the two first conditions, FALSE for the last
*/
-static int start_debugger_atomic(PEXCEPTION_POINTERS epointers)
+int CDECL start_debugger_atomic(PEXCEPTION_POINTERS epointers)
{
static HANDLE hRunOnce /* = 0 */;
diff --git a/dlls/kernel32/kernel32.spec b/dlls/kernel32/kernel32.spec
index b0f4ee7..e5e79c3 100644
--- a/dlls/kernel32/kernel32.spec
+++ b/dlls/kernel32/kernel32.spec
@@ -1264,3 +1264,6 @@
# Init code
@ cdecl __wine_kernel_init()
+
+#debugging
+@ cdecl wine_start_debugger_atomic(ptr) start_debugger_atomic
--1.6.0.6--
Re: faultrep:display useful information in ReportFault
Mikołaj Zalewski a écrit : Jérôme Gardou pisze: Let's rephrase it : most bug reporters expect the console log to be useful for developers willing to fix their problem :-) Maybe I should have made it clear - I think that your patch, even in the first version, was a step forward :). As for the second patch, Alexandre doesn't like when we export some wine-specific functions from DLLs. On the other hand, kernel32 is always builtin, so the main argument against it (that it will break if someone uses a native DLL) is not present, so maybe it could be accepted. But it's Alexandre who can answer it. Mikołaj Well, launching winedbg instead of printing incomplete information is, IMHO, the best way to make something useful, and, as you said it, kernel32 is always builtin, as ntdll, and faultrep is too close of the system internals to be a totally winapiesque dll. After all, kernel32 already exports a few wine_* functions. To be honest, I'd really like to have an opinion about this patch before sending it and being silently rejected.
Re: faultrep:display useful information in ReportFault
Alexandre Julliard a écrit :
Jérôme Gardou jerome.gar...@gmail.com writes:
Well, launching winedbg instead of printing incomplete information is,
IMHO, the best way to make something useful, and, as you said it,
kernel32 is always builtin, as ntdll, and faultrep is too close of the
system internals to be a totally winapiesque dll. After all, kernel32
already exports a few wine_* functions.
To be honest, I'd really like to have an opinion about this patch before
sending it and being silently rejected.
You certainly don't want to add exports to kernel32 for that. Launching
the debugger isn't hard to do in faultrep, plus you most likely want to
do it differently from what kernel32 does.
Is this one too hackish for you ?
From d54e4c5bf909e9bde775a22cb1eabb6f8cae1bcb Mon Sep 17 00:00:00 2001
From: =?utf-8?q?J=C3=A9r=C3=B4me=20Gardou?= jerome.gar...@laposte.net
Date: Mon, 23 Feb 2009 20:47:34 +0100
Subject: [PATCH] faultrep:Make ReportFault display useful information by
calling winedbg.
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary=1.6.0.6
This is a multi-part message in MIME format.
--1.6.0.6
Content-Type: text/plain; charset=UTF-8; format=fixed
Content-Transfer-Encoding: 8bit
---
dlls/faultrep/faultrep.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
--1.6.0.6
Content-Type: text/x-patch; name=d54e4c5bf909e9bde775a22cb1eabb6f8cae1bcb.diff
Content-Transfer-Encoding: 8bit
Content-Disposition: attachment;
filename=d54e4c5bf909e9bde775a22cb1eabb6f8cae1bcb.diff
diff --git a/dlls/faultrep/faultrep.c b/dlls/faultrep/faultrep.c
index d4bd713..df02f5b 100644
--- a/dlls/faultrep/faultrep.c
+++ b/dlls/faultrep/faultrep.c
@@ -107,7 +107,10 @@ BOOL WINAPI AddERExcludedApplicationA(LPCSTR lpAppFileName)
*/
EFaultRepRetVal WINAPI ReportFault(LPEXCEPTION_POINTERS pep, DWORD dwOpt)
{
-FIXME(%p 0x%x stub\n, pep, dwOpt);
+LPTOP_LEVEL_EXCEPTION_FILTER filter = SetUnhandledExceptionFilter(NULL) ;
+FIXME(%p 0x%x stub. Getting back to winedbg\n, pep, dwOpt);
+UnhandledExceptionFilter(pep) ;
+SetUnhandledExceptionFilter(filter) ;
return frrvOk;
}
--1.6.0.6--
Re: opengl: wglMakeCurrent should call glflush before proceeding
Chris Robinson a écrit : On Saturday 21 February 2009 2:00:26 pm Jérôme Gardou wrote: according to http://msdn.microsoft.com/en-us/library/dd374387(VS.85).aspx, wglMakeCurrent proceeds a flush before switching. glXMakeCurrent also forces a flush: http://www.opengl.org/documentation/specs/man_pages/hardcopy/GL/html/glx/xmakecurrent.html If it needs a wglFlush, it should call X11DRV_wglFlush (and only if there's a current context; you can't call gl* functions without one set). It can be an exceptionally costly call though, especially if it's going to be flushed again immediately after, so unless it's needed to fix some bug, I'd recommend not flushing explicitly. Good catch. I read this page before sending, searching for this piece of information, but for some reason I did not see it... It seems that I needed some sleep yesterday. Thanks.
Re: faultrep:display useful information in ReportFault
Jérôme Gardou a écrit : This should help debugging applications which performs their own exception handling. After a bit of thinking, I think that this should be displayed each time the function is called. Is there any macro in wine/debug.h which would display a message, even when WINEDEBUG is set to -all ?
Re: faultrep:display useful information in ReportFault
Chris Robinson a écrit : On Sunday 22 February 2009 12:09:01 pm Austin English wrote: On Sun, Feb 22, 2009 at 8:58 AM, Jérôme Gardou jerome.gar...@gmail.com wrote: Jérôme Gardou a écrit : This should help debugging applications which performs their own exception handling. After a bit of thinking, I think that this should be displayed each time the function is called. Is there any macro in wine/debug.h which would display a message, even when WINEDEBUG is set to -all ? MESSAGE() Thanks ! Perhaps a MessageBox or some fancier dialog would be better. MSDN says it can behave differently depending on how the user has their system configured.. what kind of options are available? The aim of this patch is to provide some information to wine developers when an application crashes because of an unexpected behaviour of the winapi implementation. In this case, the implementation is WINE, and fixmes/traces etc... are currently displayed in console. I'm not sure that we want to reproduce windows XP behaviour here (understand Your application encountered an unexpected error. What do you want to do : send report/do not send) which annoys most people, and is not that useful. Most wine users, when their app crashes, open a bug report and attach the console log. If the log contains information got from ReportFault, developers will gain some time, and have the preceding context of the call. Just my 2 cents :-)
Re: faultrep:display useful information in ReportFault
Erich Hoover a écrit : I know quite a few people (my converts) that run applications (mostly games) where they launch the application from an icon and there is no console. They've complained to me every once in a while that they would much prefer a dialog informed them when their application crashes. Personally, I think that fatal errors (including things like a DLL could not be found) should launch a dialog if a terminal is not available (if TERM is not set). Erich Hoover ehoo...@mines.edu mailto:ehoo...@mines.edu Why not writing directly debug output in a file instead of redirecting it to stderr. After all, Xorg has its own log, why not /tmp/wine.0.log ? And ReportFault would be Your application crashed because of unexpected behaviour. Please report a bug to http://bugs.winehq.org. Don't forget to attach /tmp/wine.0.log. Please be kind and search for existing bug before reporting.
Re: faultrep:display useful information in ReportFault
Chris Robinson a écrit : Having the information there of why it crashed would be nice too, especially if it's hard to reproduce. Knowing what the fault was, and where (with a backtrace if possible) can give the more development-inclined people information of where to look for the issue, instead of needlessly trying to make it crash again or go digging around in log files. Well, that was the intent of my patch : ReportFault is made to give windows developers information about why the application catched an exception. There is no reason why wine people could not use it. By the way, is there an easy way to know if wine was launched from console or not?
Re: faultrep:display useful information in ReportFault
Mikołaj Zalewski a écrit : I've written a dialog about a crash some time ago to add to winedbg (http://www.winehq.org/pipermail/wine-patches/2009-January/068073.html). It's probably time to ask what is the status of this patch? If this patch gets accepted (Alexandre seemed to like the previous version, but pointed that it broke kernel32 tests because there had been no way to disable it and he didn't have much time to review it), maybe calling `winedbg --auto` from ReportFault would be the best way - you would then have a dialog (the same as during a regular crash, can be disabled from the registry), the full debugger output and an option to run an interactive debugger. AFAIK this is the other way round than Windows does (AFAIK drwatson loads faultrep.dll into the process that crashed and calls ReportFault), but loading a DLL into a process where everything could be corrupted seems a strange idea. Launching winedbg sounds good, but I wonder if calling winedbg AFTER the exception has been catched by the application would be useful. It's time for me to document myself :-) Jérôme Gardou pisze: Most wine users, when their app crashes, open a bug report and attach the console log. If the log contains information got from ReportFault, developers will gain some time, and have the preceding context of the call. I'm affraid this is what is done by the 1% best users ;). I'd expect that a typical user to complain that Linux is broken because on Linux, from time to time, apps just disappear from the screen while on Windows they don't. Already knowing that there is such a thing like Wine requires some knowledge :). Mikołaj Zalewski Let's rephrase it : most bug reporters expect the console log to be useful for developers willing to fix their problem :-)
Re: Win to Lin Library Wrapper
Gentoo users still have to set the +opengl use flag... That's where most of the complaints came from. The other aspect is that even software GL isn't available when you're using Xvnc or similar servers. To be honest, I prefer the second argument over the first one :-)
Re: Win to Lin Library Wrapper
Stefan Dösinger a écrit : Am Mittwoch, 18. Februar 2009 10:06:03 schrieb King InuYasha: So it wouldn't be possible to hook Wine's Direct3D implementation into Gallium3D on Linux and use the hardware directly instead of translating it to OpenGL and then sending it to the hardware? Possible yes. I don't know if its gains anything though. We can never use the hardware directly, we always have to bother the Linux/Mac/Whatever driver. If we go D3D-Gallium3D-Driver-HW or D3D-GL-Driver-HW doesn't make too much difference, and Gallium3D is a driver specific API. It won't work on the proprietary drivers or on MacOS, so I don't think it is worth the effort. The one big advantage of Gallium3D is that its interface is more flexible, and it is easier to implement certain things that opengl doesn't have yet(e.g. the color selection for flat shading). The bottom line is that if anybody implements a Gallium3D backend and it is well-written and has a reasonable design it will most likely be accepted. I personally don't have any plans to do that right now though. Out of curiosity, would moving to this sort of architecture http://msdn.microsoft.com/en-us/library/ms799715.aspx be possible? That may give manufacturer the possibility to develop wine-direct3d drivers and support what wine does not support. This would require a major architecture change in the current wine's d3d implementation though.
Re: Need help on couple of patches
Igor Tarasov a écrit : Hello! I've written 2 patches, and I need advice on both of them. First one is here: http://www.winehq.org/pipermail/wine-patches/2009-February/069463.html It's a single-line patch that adds forwarding notification that was omitted in wine code. This fix looks pretty simple, but it included lots of reading/testing/debugging, and here is what I came with. And as I told there it fixes one wine bugzilla bug. But as I see, it was not comitted, so I am asking for advice: what could I do in order to make it go through? Another patch is here: http://bugs.winehq.org/show_bug.cgi?id=12701 The patch adresses 3 problems that all together fix that bug. My question there was if I should send it in one patch or in several. But it seems that no one have noticed that post. Any help and advice is appreciated. Thanks. I can't answer your first question, but for the second one : wine developers policy is one patch per fix. So you should send three patches.
Re: Win to Lin Library Wrapper
Henri Verbeet a écrit : 2009/2/18 Jérôme Gardou jerome.gar...@gmail.com: Out of curiosity, would moving to this sort of architecture http://msdn.microsoft.com/en-us/library/ms799715.aspx be possible? That may give manufacturer the possibility to develop wine-direct3d drivers and support what wine does not support. This would require a major architecture change in the current wine's d3d implementation though. Possible sure, but I don't think it would be worth the effort. IIRC ddraw support might be a problem as well. Well, the fact is that wined3d is a bit d3d8/9 centric, and integrating DXGI and d3d10/11 might as well be tricky. I've seen that some work had begun, and I'm quite curious on which design decision you will make. As of ddraw, wouldn't it be possible to write it on top of d3d9, as it is already done with wined3d.
Re: Win to Lin Library Wrapper
Stefan Dösinger a écrit : Am Mittwoch, 18. Februar 2009 23:47:47 schrieb Jérôme Gardou: As of ddraw, wouldn't it be possible to write it on top of d3d9, as it is already done with wined3d. That will screw non-opengl ddraw rendering, which the VNC/remote X/old card/bad driver users will not really like. WineD3D currently has two surface implementations, one for GL based rendering and one for SW emulation(2D only) /me remembers the uproar when the ddraw rewrite broke the ability to compile ddraw without GL headers. (gentoo useflags OMG!!!) This might be a silly question, but isn't MESA here just for it : providing openGL functionality to sytems that don't have good hardware? And wasn't it planned somewhere to split together wined3d and winex11 (not related to the question here, but just curious :) )
Re: d3d9/tests : LockRect acquires the lock if D3DLOCK_NOSYSLOCK is not specified.
Forget this one please.
Re: Anything wrong with this patch?
Austin English a écrit : On Fri, Jan 23, 2009 at 5:37 PM, Jérôme Gardou jerome.gar...@gmail.com wrote: Ben Klein a écrit : 2009/1/24 Austin English austinengl...@gmail.com: On Fri, Jan 23, 2009 at 4:58 PM, Jérôme Gardou jerome.gar...@gmail.com wrote: Ben Klein a écrit : I just looked at bug 15616. Maybe you should look at it too. Also, please hit Reply to all so your message gets sent to the mailing list too :) Of course... Austin English already noticed my patch. Austin, any idea why it was rejected? Sorry for the reply to all, I forgot it this time... I don't know. I only noticed the empty patch. AJ would be the one to ask. Off hand though, I'd say if you're going to add support for .acm, you should also allow for other native files. iexplore.exe is one candidate, but probably controversial. There are other file extension types missing, I'm sure, though not sure which types off hand. Is it really about supporting? As AJ points out in his comment, nothing stops you from writing in the .acm file, which is almost certainly faster than scrolling through the whole list to find it anyway. Isn't the list of DLLs in winecfg long enough already? I like to type the beginning of a dll, and just press tab to get its full name. It is only a matter of comfort. :) That, and developers are probably aren't using this much anyway. Most of us avoid native dlls, but when using them A) use winetricks or B) use WINEDLLOVERRIDES. Users would find it more convenient, and arguably, they should be able to. I don't see any reason we shouldn't allow .acm's. Sys/drv probably not. Exe, debatable. I resent the patch quite some time ago, but it's still unaccepted... http://www.winehq.org/pipermail/wine-patches/2009-January/068325.html
Re: performance issue when OffscreenRenderingMode = pbuffer
The patch was sent, but not accepted. Does anyone have a clue about it? http://www.winehq.org/pipermail/wine-patches/2009-January/068339.html
wined3d and winex11 hand in hand...
Quite oddly enough, wined3d and winex11 don't communicate with each other at all (well, wined3d uses WGL in gdi32, and gdi32 is based on winex11), and this leads to problems which are tricky to resolve... For instance, when a d3d application wants to disable screensavers, there is no way to do this through the windows api, but xlib provides XSetScreenSaver which is axactly what we need there. Would it be a good way to do this, as in user32 and gdi32, to create a driver structure holding each function pointer we would need, and forward them to stub if unavailable?
Re: wined3d and winex11 hand in hand...
Dmitry Timoshkov a écrit : Jérôme Gardou jerome.gar...@gmail.com wrote: Quite oddly enough, wined3d and winex11 don't communicate with each other at all (well, wined3d uses WGL in gdi32, and gdi32 is based on winex11), and this leads to problems which are tricky to resolve... For instance, when a d3d application wants to disable screensavers, And how exactly does it want to do that? By setting presentationparameters-windowed = false and using D3DCREATE_SCREENSAVER in BehaviorFlags when creating a device. there is no way to do this through the windows api, but xlib provides XSetScreenSaver which is axactly what we need there. http://www.google.com/search?q=how+to+disable+screen+saver+under+windows+programmatically http://support.microsoft.com/kb/126627 Good catch. I will try this way. Would it be a good way to do this, as in user32 and gdi32, to create a driver structure holding each function pointer we would need, and forward them to stub if unavailable? Have you looked how it's currently implemented? Yes. I don't see any major problem with this design.
Re: performance issue when OffscreenRenderingMode = pbuffer
Roderick Colenbrander a écrit :
I tried to play Supreme Commander using pbuffer option instead of fbo. I
was quite happy with it, since I gained quite a bunch of performance (I
mean, something I really COULD see), but after a while, the performance
dropped dramatically, to ~4-5 fps.
I tested quite a few thing, and I finally found that pixel bufers were
not taken in account when calculating available texture memory. The game
then allocated more textures, and good opengl didn't dare complain when
putting them in system memory.
Attached is a patch which should solve the problem.
For those who are curious, try setting VideoMemorySize to 200 instead of
256. It works just like a charm.
I think the basic idea of the patch is good but the calculation itself should
take into account double buffering. In wine we don't use double buffering on
pbuffers but we might be receiving a WGL pixel format which uses double
buffering, so in that case the amount of video memory would be a factor 2 too
low.
Something like this would give you the double buffering capability from a d3d
device:
This-adapter-cfgs[iPixelFormat]-doubleBuffer
Roderick
OK. Here is a new one, more readable I think. I'll send it to
wine-patches once I manage to configure git-send-email :)
From 3f20a3570a99a57c3e065f1ef93277c28fb61a4e Mon Sep 17 00:00:00 2001
From: =?utf-8?q?J=C3=A9r=C3=B4me=20Gardou?= jerome.gar...@laposte.net
Date: Sun, 25 Jan 2009 12:52:45 +0100
Subject: [PATCH] wined3d: take into account video ram that pixel buffers use.
---
dlls/wined3d/context.c | 14 ++
1 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/dlls/wined3d/context.c b/dlls/wined3d/context.c
index da3053a..86d9db4 100644
--- a/dlls/wined3d/context.c
+++ b/dlls/wined3d/context.c
@@ -635,6 +635,7 @@ WineD3DContext *CreateContext(IWineD3DDeviceImpl *This,
IWineD3DSurfaceImpl *tar
HGLRC ctx = NULL, oldCtx;
WineD3DContext *ret = NULL;
int s;
+long size = 0 ;
TRACE((%p): Creating a %s context for render target %p\n, This,
create_pbuffer ? offscreen : onscreen, target);
@@ -679,6 +680,9 @@ WineD3DContext *CreateContext(IWineD3DDeviceImpl *This,
IWineD3DSurfaceImpl *tar
goto out;
}
ReleaseDC(win_handle, hdc_parent);
+size = target-currentDesc.Width * target-currentDesc.Height *
target-bytesPerPixel ;
+if(This-adapter-cfgs[iPixelFormat].doubleBuffer)
+size *= 2 ;
} else {
PIXELFORMATDESCRIPTOR pfd;
int iPixelFormat;
@@ -898,6 +902,8 @@ WineD3DContext *CreateContext(IWineD3DDeviceImpl *This,
IWineD3DSurfaceImpl *tar
}
This-frag_pipe-enable_extension((IWineD3DDevice *) This, TRUE);
+WineD3DAdapterChangeGLRam(This, size) ;
+
return ret;
out:
@@ -958,6 +964,7 @@ static void RemoveContextFromArray(IWineD3DDeviceImpl
*This, WineD3DContext *con
*/
void DestroyContext(IWineD3DDeviceImpl *This, WineD3DContext *context) {
struct fbo_entry *entry, *entry2;
+long size = 0 ;
TRACE(Destroying ctx %p\n, context);
@@ -986,11 +993,18 @@ void DestroyContext(IWineD3DDeviceImpl *This,
WineD3DContext *context) {
/* Cleanup the GL context */
pwglMakeCurrent(NULL, NULL);
if(context-isPBuffer) {
+int iPixelFormat = GetPixelFormat(context-hdc) ;
+IWineD3DSurfaceImpl* surf = (IWineD3DSurfaceImpl*) context-surface ;
GL_EXTCALL(wglReleasePbufferDCARB(context-pbuffer, context-hdc));
GL_EXTCALL(wglDestroyPbufferARB(context-pbuffer));
+size = surf-currentDesc.Width * surf-currentDesc.Height *
surf-bytesPerPixel ;
+if(This-adapter-cfgs[iPixelFormat].doubleBuffer)
+size *= 2 ;
} else ReleaseDC(context-win_handle, context-hdc);
pwglDeleteContext(context-glCtx);
+WineD3DAdapterChangeGLRam(This, (-1)*size) ;
+
HeapFree(GetProcessHeap(), 0, context-vshader_const_dirty);
HeapFree(GetProcessHeap(), 0, context-pshader_const_dirty);
RemoveContextFromArray(This, context);
--
1.6.0.6
Re: performance issue when OffscreenRenderingMode = pbuffer
Roderick Colenbrander a écrit : Roderick Colenbrander a écrit : I tried to play Supreme Commander using pbuffer option instead of fbo. I was quite happy with it, since I gained quite a bunch of performance (I mean, something I really COULD see), but after a while, the performance dropped dramatically, to ~4-5 fps. I tested quite a few thing, and I finally found that pixel bufers were not taken in account when calculating available texture memory. The game then allocated more textures, and good opengl didn't dare complain when putting them in system memory. Attached is a patch which should solve the problem. For those who are curious, try setting VideoMemorySize to 200 instead of 256. It works just like a charm. I think the basic idea of the patch is good but the calculation itself should take into account double buffering. In wine we don't use double buffering on pbuffers but we might be receiving a WGL pixel format which uses double buffering, so in that case the amount of video memory would be a factor 2 too low. Something like this would give you the double buffering capability from a d3d device: This-adapter-cfgs[iPixelFormat]-doubleBuffer Roderick OK. Here is a new one, more readable I think. I'll send it to wine-patches once I manage to configure git-send-email :) Hi, I think it would be best to add an attribute 'pbuffer_size' or something like that to the WineD3DContext storing the size of the pbuffer. This is needed because GetPixelFormat won't work on a pbuffer. The problem with this call is that GetPixelFormat doesn't see 'offscreen pixel formats' (like e.g. floating point ones and there are others) which can be used for pbuffers. Further I think it is nicer to not have to recalculate its size. I don't think there is a way to get the pixel format from a pbuffer. Roderick Patch sent...
performance issue when OffscreenRenderingMode = pbuffer
I tried to play Supreme Commander using pbuffer option instead of fbo. I
was quite happy with it, since I gained quite a bunch of performance (I
mean, something I really COULD see), but after a while, the performance
dropped dramatically, to ~4-5 fps.
I tested quite a few thing, and I finally found that pixel bufers were
not taken in account when calculating available texture memory. The game
then allocated more textures, and good opengl didn't dare complain when
putting them in system memory.
Attached is a patch which should solve the problem.
For those who are curious, try setting VideoMemorySize to 200 instead of
256. It works just like a charm.
From 8e7b7e517b15e2ddb2cdd1526dfab3dfbf856bd5 Mon Sep 17 00:00:00 2001
From: =?utf-8?q?J=C3=A9r=C3=B4me=20Gardou?= jerome.gar...@laposte.net
Date: Sun, 25 Jan 2009 02:34:03 +0100
Subject: [PATCH] wined3d: take pixel buffers in account when calculating
texture ram.
---
dlls/wined3d/context.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/dlls/wined3d/context.c b/dlls/wined3d/context.c
index da3053a..9fad82d 100644
--- a/dlls/wined3d/context.c
+++ b/dlls/wined3d/context.c
@@ -898,6 +898,9 @@ WineD3DContext *CreateContext(IWineD3DDeviceImpl *This,
IWineD3DSurfaceImpl *tar
}
This-frag_pipe-enable_extension((IWineD3DDevice *) This, TRUE);
+if(create_pbuffer)
+WineD3DAdapterChangeGLRam(This,
((IWineD3DSurfaceImpl*)(ret-surface))-currentDesc.Width *
((IWineD3DSurfaceImpl*)(ret-surface))-currentDesc.Height *
((IWineD3DSurfaceImpl*)(ret-surface))-bytesPerPixel) ;
+
return ret;
out:
@@ -988,6 +991,7 @@ void DestroyContext(IWineD3DDeviceImpl *This,
WineD3DContext *context) {
if(context-isPBuffer) {
GL_EXTCALL(wglReleasePbufferDCARB(context-pbuffer, context-hdc));
GL_EXTCALL(wglDestroyPbufferARB(context-pbuffer));
+WineD3DAdapterChangeGLRam(This,(-1) *
((IWineD3DSurfaceImpl*)(context-surface))-currentDesc.Width *
((IWineD3DSurfaceImpl*)(context-surface))-currentDesc.Height *
((IWineD3DSurfaceImpl*)(context-surface))-bytesPerPixel) ;
} else ReleaseDC(context-win_handle, context-hdc);
pwglDeleteContext(context-glCtx);
--
1.6.0.6
Anything wrong with this patch?
http://www.winehq.org/pipermail/wine-patches/2009-January/067564.html Any comment on this one? Related to bug 15616.
Re: Anything wrong with this patch?
Ben Klein a écrit : 2009/1/24 Jérôme Gardou jerome.gar...@gmail.com: Ben Klein a écrit : 2009/1/24 Jerome Leclanche adys...@gmail.com: (Damnit, gmail interface) Pipermail shows as empty, here. On Fri, Jan 23, 2009 at 10:05 PM, Jérôme Gardou jerome.gar...@gmail.com wrote: http://www.winehq.org/pipermail/wine-patches/2009-January/067564.html Any comment on this one? Related to bug 15616. Looks like http://www.winehq.org/pipermail/wine-patches/2009-January/067564.html has a brief description that says See bug 15616, but the previous mail http://www.winehq.org/pipermail/wine-patches/2009-January/067565.html has the actual patch. Jérôme, be more careful when submitting patches! :) strange... the first one is the original message, the second one looks like the attachment... Maybe something wrong with thunderbird. I'll resend if needed. I just looked at bug 15616. Maybe you should look at it too. Also, please hit Reply to all so your message gets sent to the mailing list too :) Of course... Austin English already noticed my patch. Austin, any idea why it was rejected? Sorry for the reply to all, I forgot it this time...
Re: Anything wrong with this patch?
Austin English a écrit : Of course... Austin English already noticed my patch. Austin, any idea why it was rejected? Sorry for the reply to all, I forgot it this time... I don't know. I only noticed the empty patch. AJ would be the one to ask. Off hand though, I'd say if you're going to add support for .acm, you should also allow for other native files. iexplore.exe is one candidate, but probably controversial. There are other file extension types missing, I'm sure, though not sure which types off hand. Yes... potential candidate are acm, sys, drv, vxd and exe. I guess that vxd, drv and sys are to be avoided there. Some exe, such as regedit, could be replaced, but I'm not sure which one are truly safe there.
Re: Anything wrong with this patch?
Ben Klein a écrit : 2009/1/24 Austin English austinengl...@gmail.com: On Fri, Jan 23, 2009 at 4:58 PM, Jérôme Gardou jerome.gar...@gmail.com wrote: Ben Klein a écrit : I just looked at bug 15616. Maybe you should look at it too. Also, please hit Reply to all so your message gets sent to the mailing list too :) Of course... Austin English already noticed my patch. Austin, any idea why it was rejected? Sorry for the reply to all, I forgot it this time... I don't know. I only noticed the empty patch. AJ would be the one to ask. Off hand though, I'd say if you're going to add support for .acm, you should also allow for other native files. iexplore.exe is one candidate, but probably controversial. There are other file extension types missing, I'm sure, though not sure which types off hand. Is it really about supporting? As AJ points out in his comment, nothing stops you from writing in the .acm file, which is almost certainly faster than scrolling through the whole list to find it anyway. Isn't the list of DLLs in winecfg long enough already? I like to type the beginning of a dll, and just press tab to get its full name. It is only a matter of comfort. :)
Re: d3d9 : do not proceed reset or release from another thread than the one which created the device.
Jérôme Gardou a écrit :
Henri Verbeet a écrit :
2008/12/6 Jérôme Gardou [EMAIL PROTECTED]:
According to d3d9_private.h , ref is a LONG.
ref is not defined in d3d9_private.h.
Taken from d3d9_private.h :
typedef struct IDirect3DDevice9Impl
{
/* IUnknown fields */
const IDirect3DDevice9ExVtbl *lpVtbl;
LONG ref;
...
That's why the compiler did not complained... But release actually
returns a ULONG, and the IUnknown ref is an ULONG anyway...
I guess this should be changed for consistency.
Oh dear... I upgraded my winXP VM to SP3 yesterday, and the tests I
wrote now crash... seems like d3d9 does not care about threads anymore...
Re: d3d9 : do not proceed reset or release from another thread than the one which created the device.
Henri Verbeet a écrit :
2008/11/30 Jérôme Gardou [EMAIL PROTECTED]:
-if (ref == 0) {
+if (ref = 0) {
This doesn't work, of course. ref is an ULONG.
Why not just a cast in this case ?
The check for Reset
should probably go into wined3d.
OK... but a test should check is this is the same behaviour in d3d8. Not
sure...
Re: d3d9 : do not proceed reset or release from another thread than the one which created the device.
Jérôme Gardou a écrit :
Henri Verbeet a écrit :
2008/11/30 Jérôme Gardou [EMAIL PROTECTED]:
-if (ref == 0) {
+if (ref = 0) {
This doesn't work, of course. ref is an ULONG.
Why not just a cast in this case ?
According to d3d9_private.h , ref is a LONG.
Re: d3d9 : do not proceed reset or release from another thread than the one which created the device.
Henri Verbeet a écrit :
2008/12/6 Jérôme Gardou [EMAIL PROTECTED]:
According to d3d9_private.h , ref is a LONG.
ref is not defined in d3d9_private.h.
Taken from d3d9_private.h :
typedef struct IDirect3DDevice9Impl
{
/* IUnknown fields */
const IDirect3DDevice9ExVtbl *lpVtbl;
LONG ref;
...
That's why the compiler did not complained... But release actually
returns a ULONG, and the IUnknown ref is an ULONG anyway...
I guess this should be changed for consistency.
Re: DIrectSound on top of openAL ?
Chris Robinson a écrit : On Thursday 30 October 2008 03:46:51 am Darragh Bailey wrote: Just out of curiousity, have any of these limitations been raised with the OpenAL developers? Any of them in its future wish list? I'm the developer of OpenAL Soft http://kcat.strangesoft.net/openal.html, which is becoming the implementation to use on Linux and other Unices (as the old Sample Implementation is deprecated/not maintained anymore). Though I'm not really hands-in with Creative or anything.. just a hobbyist developer making a Linux lib on his own time, who gives out his ideas. If OpenAL was updated with the next release 1.2+ to support the type of access that wine needs to support the windows sound API's on linux, would it make it easier that supporting multiple sound drivers? I would like to see DirectSound(3D) running properly on OpenAL, even if as a seperate project (eg. my DSound-OpenAL DLL project). It's not up to me whether such a thing would get into Wine or not, though. I think that your dsound-openAL wrapper could be used verbatim in wine, if wine provides an openal32.dll - native openal wrapper (as with opengl32). By the way, did you try your dll with vista, which dropped dsound hardware acceleration ?
Re: D3DXMatrixstack: where to go....
Henri Verbeet a écrit : Actually, I just cleaned up your patches, and will probably submit the first few later today. Are you going to finish it or can I send the few missing functions ?
Re: D3DXMatrixstack: where to go....
Henri Verbeet a écrit : 2008/10/31 Jérôme Gardou [EMAIL PROTECTED]: Henri Verbeet a écrit : Actually, I just cleaned up your patches, and will probably submit the first few later today. Are you going to finish it or can I send the few missing functions ? Sure, go ahead. I sent all the patches I wrote for this. OK, patches will be sent soon. By the way, what if I call multiply on a new stack, the push, then pop ? Will the top matrix be identity, or the one with which I multiplied the first time ? I guess this calls a testcase ...
Re: D3DXMatrixstack: where to go....
Henri Verbeet a écrit : 2008/10/31 Jérôme Gardou [EMAIL PROTECTED]: OK, patches will be sent soon. By the way, what if I call multiply on a new stack, the push, then pop ? Will the top matrix be identity, or the one with which I multiplied the first time ? I guess this calls a testcase ... I think it should return the result of the multiplication, but tests wouldn't hurt, of course. I think this should return identity... Anyway, could someone try this one on a native installation ? From b4c72e5e0737d6fa98f352765298bbc5f86d390a Mon Sep 17 00:00:00 2001 From: =?utf-8?q?J=C3=A9r=C3=B4me=20Gardou?= [EMAIL PROTECTED] Date: Sat, 1 Nov 2008 00:13:53 +0100 Subject: [PATCH] Test to know whether the top of a matrix stack is ALWAYS identity --- dlls/d3dx8/tests/math.c | 15 ++- 1 files changed, 14 insertions(+), 1 deletions(-) diff --git a/dlls/d3dx8/tests/math.c b/dlls/d3dx8/tests/math.c index f38ff26..9f5207a 100644 --- a/dlls/d3dx8/tests/math.c +++ b/dlls/d3dx8/tests/math.c @@ -1442,7 +1442,7 @@ static void test_matrix_stack(void) hr = ID3DXMatrixStack_LoadMatrix(stack, NULL); ok(hr == D3DERR_INVALIDCALL, LoadMatrix returned %#x, expected D3DERR_INVALIDCALL\n, hr); - + hr = ID3DXMatrixStack_LoadMatrix(stack, mat1); ok(SUCCEEDED(hr), LoadMatrix failed, hr %#x\n, hr); expect_mat(mat1, ID3DXMatrixStack_GetTop(stack)); @@ -1479,6 +1479,19 @@ static void test_matrix_stack(void) ok(SUCCEEDED(hr), Pop failed, hr %#x\n, hr); ok(D3DXMatrixIsIdentity(ID3DXMatrixStack_GetTop(stack)), The top should be an identity matrix\n); +hr = ID3DXMatrixStack_MultMatrix(stack, mat2) ; +ok(SUCCEEDED(hr), Multiplication failed); +/* Identity * mat2 = mat2 */ +expect_mat(mat2, ID3DXMatrixStack_GetTop(stack)) ; + +hr = ID3DXMatrixStack_Push(stack); +ok(SUCCEEDED(hr), Push failed, hr %#x\n, hr); + +hr = ID3DXMatrixStack_Pop(stack); +ok(SUCCEEDED(hr), Pop failed, hr %#x\n, hr); +/* here we are on the bottom of the stack... is it always identity? */ +ok(D3DXMatrixIsIdentity(ID3DXMatrixStack_GetTop(stack)), The top should be an identity matrix\n); + refcount = ID3DXMatrixStack_Release(stack); ok(!refcount, Matrix stack has %u references left.\n, refcount); } -- 1.5.4.3
Re: D3DXMatrixstack: where to go....
Jérôme Gardou a écrit : Henri Verbeet a écrit : 2008/10/31 Jérôme Gardou [EMAIL PROTECTED]: OK, patches will be sent soon. By the way, what if I call multiply on a new stack, the push, then pop ? Will the top matrix be identity, or the one with which I multiplied the first time ? I guess this calls a testcase ... I think it should return the result of the multiplication, but tests wouldn't hurt, of course. I think this should return identity... Anyway, could someone try this one on a native installation ? This might be a silly question, but... d3dx8 is supposed to be linked statically in applications that might use it is there any sense to implement it? (this is not the case for d3dx9_xx.dll) I found this information there : http://www.microsoft.com/downloads/details.aspx?FamilyID=fc60231e-895d-489d-b796-e0fcac82b553DisplayLang=en in the readme of the file to download.
DIrectSound on top of openAL ?
I was wondering why directsound was not implemented using openal. As direct3d is implemented on top of opengl. I see three major advantages : openAL is cross-platform, whereas alsa is linux-specific. openAL is (sometimes) hardware-accelerated. Wine would bring directsound hardware acceleration to windows vista :) See http://connect.creativelabs.com/openal/OpenAL%20Wiki/OpenAL%C2%AE%20and%20Windows%20Vista%E2%84%A2.aspx for manufacturers which bring hardware accelerated openal drivers... Plus, wine would benefit of the system's openal configuration. No need to chosse between OSS and ALSA, the user would have done it through his openAL configuration.
Conformance test to try on a windows box.
I'm currently implementing the D3DXMatrixStack interface. Could someone
try these tests on a windows machine before I go further ?
From 240c0f61bae17813488b5c0f47cde0b5b10562e7 Mon Sep 17 00:00:00 2001
From: =?utf-8?q?J=C3=A9r=C3=B4me=20Gardou?= [EMAIL PROTECTED](none)
Date: Mon, 27 Oct 2008 00:17:29 +0100
Subject: SImple test cases for ID3DXMatrixStack interface
---
dlls/d3dx8/tests/math.c | 27 +++
1 files changed, 27 insertions(+), 0 deletions(-)
diff --git a/dlls/d3dx8/tests/math.c b/dlls/d3dx8/tests/math.c
index 6a4b44d..0589603 100644
--- a/dlls/d3dx8/tests/math.c
+++ b/dlls/d3dx8/tests/math.c
@@ -1396,6 +1396,32 @@ static void D3X8Vector4Test(void)
expect_vec4(expectedtrans,gottrans);
}
+static void D3DXMatrixStackTest(void)
+{
+LPD3DXMATRIXSTACK MatrixStack = NULL;
+D3DMATRIX* matrix_ptr;
+D3DMATRIX matrix ;
+HRESULT hr;
+ULONG ref ;
+D3DXCreateMatrixStack(0 ,MatrixStack) ;
+ok(MatrixStack != NULL, Could not create the ID3DXMatrixStack interface\n) ;
+
+matrix_ptr = ID3DXMatrixStack_GetTop(MatrixStack) ;
+ok(matrix_ptr == NULL, Expected NULL, got %p for top matrix just after creation of the matrix stack\n, matrix_ptr) ;
+
+hr = ID3DXMatrixStack_LoadIdentity(MatrixStack) ;
+ok(hr == D3DERR_INVALIDCALL, Expected D3DERR_INVALIDCALL, got %08x for loading identity just after the creation of the matrix stack\n, hr) ;
+
+D3DXMatrixIdentity(matrix) ;
+hr = ID3DXMatrixStack_LoadMatrix(MatrixStack, matrix) ;
+ok(hr == D3DERR_INVALIDCALL, Expected D3DERR_INVALIDCALL, got %08x for loading a matrix just after the creation of the matrix stack\n, hr) ;
+
+/*Release everything*/
+do {
+ref = ID3DXMatrixStack_Release(MatrixStack) ;
+} while ( ref != 0) ;
+}
+
START_TEST(math)
{
D3DXColorTest();
@@ -1405,4 +1431,5 @@ START_TEST(math)
D3X8Vector2Test();
D3X8Vector3Test();
D3X8Vector4Test();
+D3DXMatrixStackTest() ;
}
--
1.5.4.3
Re: Latest Windows Conformance Tests
Chris Ahrendt a écrit : Vitaliy Margolen wrote: Chris Ahrendt wrote: Causes windows XP SP3 to reboot during d3d test.. Would you please stop hijacking threads! Do NOT reply when starting a new topic!!! This is highly annoying and it's deemed a really bad habit. Vitaliy. I did not hijack a thread I opened a brand new note thank you... and I was talking about the windows conformance tests which I am running on my home machine... So before you jump on someone by assuming like you prefer to do Vitaliy why dont you ask if this is one or not Again havent hijacked a thread.. this is a new thread with a problem I just got by running on a WINDOWS machine the WINE CONFORMANCE TEST from http://www.winehq.org/site/docs/winedev-guide/testing-windows using the precompiled binaries link from that page... So if you dont mind I would like an appology for you butting in and claiming that I am doing something I most certainly am not doing. Chris For me too, this thread is in the middle of [user32] Testcase for font size = 0x7ff This is annoying, but there is no need to be so harsh. BTW, thanks for the link above, I didn't know it existed :)
Implementing textures functions of d3dx using an extern library.
It appears this mail did not get in, so I resend it...
-- Forwarded message --
From: Jérôme Gardou [EMAIL PROTECTED]
Date: 2008/8/26
Subject: Implementing textures functions of d3dx using an extern library.
To: wine-devel@winehq.org
D3DX supports a wide range of file types for textures. Instead of rewriting
everything from scratch, the best would certainly be to use some image
processing library to handle them. As a bonus, this would allow lighter
code.
Some of those library are :
SDL_Image : easy to use, but loading an image using a SDL_Surface is quite
heavy. Moreover, the files supported are not enough for d3dx.
MagickWand/MagickCore, the libraries on which imagemagick is based : Hard to
use, and very heavy. Supports every format thet d3dx supports.
FreeImage : Quite easy to use, the only files not supported are DIB and
PFM... Not so widely represented. I had to recompile it, as packages for it
are not available for 32 bits. (I use a 64 bits ubuntu system).
Here is an implementation of D3DXGetImageInfoFromFileInMemory using
FreeImage.
Suggestions and comments are welcomed.
PS : Please CC me your potential answers, as I'm not a subscriber of this
list.
From 634259f60ae538f1f8eaeb2d34abaa2a9aa47d15 Mon Sep 17 00:00:00 2001
From: =?utf-8?q?J=C3=A9r=C3=B4me=20Gardou?= [EMAIL PROTECTED](none)
Date: Tue, 26 Aug 2008 15:37:17 +0200
Subject: Implements D3DXGetImageInfoFromFileInMemory using the FreeImage library.
---
dlls/d3dx9_36/Makefile.in|5 +-
dlls/d3dx9_36/d3dx9_36.spec |2 +-
dlls/d3dx9_36/d3dx9_36_private.h |5 +
dlls/d3dx9_36/texture.c | 79
dlls/d3dx9_36/utils.c| 190 ++
include/d3dx9tex.h |2 +
6 files changed, 281 insertions(+), 2 deletions(-)
create mode 100644 dlls/d3dx9_36/texture.c
create mode 100644 dlls/d3dx9_36/utils.c
diff --git a/dlls/d3dx9_36/Makefile.in b/dlls/d3dx9_36/Makefile.in
index 0b5a3d3..6455f15 100644
--- a/dlls/d3dx9_36/Makefile.in
+++ b/dlls/d3dx9_36/Makefile.in
@@ -5,13 +5,16 @@ VPATH = @srcdir@
MODULE= d3dx9_36.dll
IMPORTLIB = d3dx9
IMPORTS = d3d9 d3dx8 kernel32
+EXTRALIBS = -lfreeimage
C_SRCS = \
d3dx9_36_main.c \
font.c \
math.c \
shader.c \
- sprite.c
+ sprite.c \
+ texture.c \
+ utils.c
RC_SRCS = version.rc
diff --git a/dlls/d3dx9_36/d3dx9_36.spec b/dlls/d3dx9_36/d3dx9_36.spec
index a2dab96..acfd183 100644
--- a/dlls/d3dx9_36/d3dx9_36.spec
+++ b/dlls/d3dx9_36/d3dx9_36.spec
@@ -152,7 +152,7 @@
@ stdcall D3DXGetDriverLevel(ptr)
@ stdcall D3DXGetFVFVertexSize(long) d3dx8.D3DXGetFVFVertexSize
@ stdcall D3DXGetImageInfoFromFileA(ptr ptr) d3dx8.D3DXGetImageInfoFromFileA
-@ stdcall D3DXGetImageInfoFromFileInMemory(ptr long ptr) d3dx8.D3DXGetImageInfoFromFileInMemory
+@ stdcall D3DXGetImageInfoFromFileInMemory(ptr long ptr)
@ stdcall D3DXGetImageInfoFromFileW(ptr ptr) d3dx8.D3DXGetImageInfoFromFileW
@ stdcall D3DXGetImageInfoFromResourceA(long ptr ptr) d3dx8.D3DXGetImageInfoFromResourceA
@ stdcall D3DXGetImageInfoFromResourceW(long ptr ptr) d3dx8.D3DXGetImageInfoFromResourceW
diff --git a/dlls/d3dx9_36/d3dx9_36_private.h b/dlls/d3dx9_36/d3dx9_36_private.h
index e1c266d..7b7084c 100644
--- a/dlls/d3dx9_36/d3dx9_36_private.h
+++ b/dlls/d3dx9_36/d3dx9_36_private.h
@@ -45,5 +45,10 @@ typedef struct ID3DXSpriteImpl
/* ID3DXSprite fields */
} ID3DXSpriteImpl;
+/*Utilities*/
+D3DFORMAT GetD3DFMTFromMasks(UINT Rmask, UINT Gmask, UINT Bmask, UINT Bpp, BOOL isRGBA) ;
+const char* debug_d3dformat(D3DFORMAT) ;
+const char* debug_d3dxfileformat(D3DXIMAGE_FILEFORMAT fmt) ;
+
#endif /* __WINE_D3DX9_36_PRIVATE_H */
diff --git a/dlls/d3dx9_36/texture.c b/dlls/d3dx9_36/texture.c
new file mode 100644
index 000..2bbfc8e
--- /dev/null
+++ b/dlls/d3dx9_36/texture.c
@@ -0,0 +1,79 @@
+
+
+#include config.h
+#include wine/port.h
+#include wine/debug.h
+#include d3dx9_36_private.h
+#define _WINDOWS_
+#include FreeImage.h
+#undef _WINDOWS_
+
+WINE_DEFAULT_DEBUG_CHANNEL(d3dx);
+
+HRESULT WINAPI D3DXGetImageInfoFromFileInMemory(LPCVOID pSrcData, UINT SrcDataSize, D3DXIMAGE_INFO * pSrcInfo)
+{
+/**the graphic files supported by d3dx are BMP, JPG, PNG, TGA, PPM, DDS, PFM, DIB, HDR
+The freeimage library supports BMP, JPG, TGA, PNG, DDS, PPM, HDR
+DIB will be handle with GDI
+PFM is a very simple format. See http://netpbm.sourceforge.net/doc/pfm.html for more information**/
+
+/*First, let's see if freeimage handle this file*/
+FIMEMORY* fim = FreeImage_OpenMemory((BYTE*) pSrcData, SrcDataSize) ;
+FREE_IMAGE_FORMAT fif = FreeImage_GetFileTypeFromMemory(fim, 0) ;
+TRACE(File is %p, size is %d, filling info %p\n, pSrcData, SrcDataSize, pSrcInfo) ;
+if (fif != FIF_UNKNOWN) {
+FIBITMAP* fib = FreeImage_LoadFromMemory(fif, fim, 0) ;
+UINT bpp = FreeImage_GetBPP(fib) ;
+UINT red_mask = FreeImage_GetRedMask(fib) ;
+UINT blue_mask = FreeImage_GetRedMask
Re: Implementing textures functions of d3dx using an extern library.
Henri Verbeet a écrit : 2008/8/29 Jérôme Gardou [EMAIL PROTECTED]: If you want, I have an implementation of this same function for png... This one is not commented at all, and need some rework. Get it for comparison. As you said, it needs some cleanup etc, but at least it doesn't look fundamentally broken to me. I'm not quite sure what the decompression stuff in D3DXGetImageInfoFromFileW() is supposed to do though. Me neither... I should use CreateFile instead... I will clean it up. I guess I will have to write a test case for this...
Re: Implementing textures functions of d3dx using an extern library.
Henri Verbeet a écrit :
2008/8/29 Jérôme Gardou [EMAIL PROTECTED]:
If you want, I have an implementation of this same function for png... This
one is not commented at all, and need some rework. Get it for comparison.
As you said, it needs some cleanup etc, but at least it doesn't look
fundamentally broken to me. I'm not quite sure what the decompression
stuff in D3DXGetImageInfoFromFileW() is supposed to do though.
Here is a new one, slightly cleaned up and without this crappy
decompression stuff.
From 6f0cfa7ddcc061aa9eda228ca8e01ab8961e182e Mon Sep 17 00:00:00 2001
From: =?utf-8?q?J=C3=A9r=C3=B4me=20Gardou?= [EMAIL PROTECTED](none)
Date: Fri, 29 Aug 2008 15:15:22 +0200
Subject: Implements D3DXGetImageInfoFromFile in d3dx9
---
dlls/d3dx9_36/Makefile.in|5 +-
dlls/d3dx9_36/d3dx9_36.spec |6 +-
dlls/d3dx9_36/d3dx9_36_private.h | 10 ++
dlls/d3dx9_36/texture.c | 196 ++
dlls/d3dx9_36/utils.c| 104
include/d3dx9tex.h |2 +
6 files changed, 319 insertions(+), 4 deletions(-)
create mode 100644 dlls/d3dx9_36/texture.c
create mode 100644 dlls/d3dx9_36/utils.c
diff --git a/dlls/d3dx9_36/Makefile.in b/dlls/d3dx9_36/Makefile.in
index 0b5a3d3..0ce6bb4 100644
--- a/dlls/d3dx9_36/Makefile.in
+++ b/dlls/d3dx9_36/Makefile.in
@@ -5,13 +5,16 @@ VPATH = @srcdir@
MODULE= d3dx9_36.dll
IMPORTLIB = d3dx9
IMPORTS = d3d9 d3dx8 kernel32
+EXTRALIBS=-lpng
C_SRCS = \
d3dx9_36_main.c \
font.c \
math.c \
shader.c \
- sprite.c
+ sprite.c \
+ texture.c \
+ utils.c
RC_SRCS = version.rc
diff --git a/dlls/d3dx9_36/d3dx9_36.spec b/dlls/d3dx9_36/d3dx9_36.spec
index a2dab96..f161c28 100644
--- a/dlls/d3dx9_36/d3dx9_36.spec
+++ b/dlls/d3dx9_36/d3dx9_36.spec
@@ -151,9 +151,9 @@
@ stub D3DXGetDeclVertexSize
@ stdcall D3DXGetDriverLevel(ptr)
@ stdcall D3DXGetFVFVertexSize(long) d3dx8.D3DXGetFVFVertexSize
-@ stdcall D3DXGetImageInfoFromFileA(ptr ptr) d3dx8.D3DXGetImageInfoFromFileA
-@ stdcall D3DXGetImageInfoFromFileInMemory(ptr long ptr) d3dx8.D3DXGetImageInfoFromFileInMemory
-@ stdcall D3DXGetImageInfoFromFileW(ptr ptr) d3dx8.D3DXGetImageInfoFromFileW
+@ stdcall D3DXGetImageInfoFromFileA(ptr ptr)
+@ stdcall D3DXGetImageInfoFromFileInMemory(ptr long ptr)
+@ stdcall D3DXGetImageInfoFromFileW(ptr ptr)
@ stdcall D3DXGetImageInfoFromResourceA(long ptr ptr) d3dx8.D3DXGetImageInfoFromResourceA
@ stdcall D3DXGetImageInfoFromResourceW(long ptr ptr) d3dx8.D3DXGetImageInfoFromResourceW
@ stdcall D3DXGetPixelShaderProfile(ptr)
diff --git a/dlls/d3dx9_36/d3dx9_36_private.h b/dlls/d3dx9_36/d3dx9_36_private.h
index e1c266d..17b49c1 100644
--- a/dlls/d3dx9_36/d3dx9_36_private.h
+++ b/dlls/d3dx9_36/d3dx9_36_private.h
@@ -45,5 +45,15 @@ typedef struct ID3DXSpriteImpl
/* ID3DXSprite fields */
} ID3DXSpriteImpl;
+/*Debugging utilities*/
+const char* debug_d3dformat(D3DFORMAT) ;
+const char* debug_d3dxfileformat(D3DXIMAGE_FILEFORMAT fmt) ;
+
+typedef struct file_in_memory
+{
+ BYTE* data ;
+ LONG offset ;
+ UINT length ;
+} file_in_memory;
#endif /* __WINE_D3DX9_36_PRIVATE_H */
diff --git a/dlls/d3dx9_36/texture.c b/dlls/d3dx9_36/texture.c
new file mode 100644
index 000..0a5bd21
--- /dev/null
+++ b/dlls/d3dx9_36/texture.c
@@ -0,0 +1,196 @@
+/*
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA
+ */
+#include config.h
+#include wine/port.h
+#ifdef HAVE_PNG_H
+#include png.h
+#endif
+#include wine/debug.h
+#include d3dx9_36_private.h
+
+WINE_DEFAULT_DEBUG_CHANNEL(d3dx);
+
+/*This ones are needed by libpng and libjpeg to simulate file reading when dealing with memory
+and errors*/
+static void intern_read_from_memory(file_in_memory* file, void* data, UINT length)
+{
+ CopyMemory( data, file-data + file-offset, length) ;
+ file-offset += length ;
+ return ;
+}
+#ifdef HAVE_PNG_H
+static void png_read_from_mem (png_structp png_ptr, png_bytep data, png_size_t length)
+{
+ intern_read_from_memory((file_in_memory*) png_get_io_ptr(png_ptr), (void*) data, (UINT) length) ;
+ return ;
+}
+
+static void png_error_fn(png_structp png_ptr, png_const_charp error_msg)
+{
+ ERR(png error : %p, %s, (void*)png_get_error_ptr(png_ptr), error_msg) ;
+}
+
+static void png_warning_fn(png_structp png_ptr
Re: Implementing textures functions of d3dx using an extern library.
Juan Lang a écrit : Here is an implementation of D3DXGetImageInfoFromFileInMemory using FreeImage. Is the license compatible? FreeImage is dual-licensed with the GPL (which Wine cannot use) and their own license. I'd be surprised if their license were LGPL compatible. --Juan There is no need to include it in wine's git. Using it as an external library is sufficient. wine uses other libraries which are GPL-ed. BTW, their home-made license looks quite permissive.
Re: Implementing textures functions of d3dx using an extern library.
Henri Verbeet a écrit : 2008/8/28 Jérôme Gardou [EMAIL PROTECTED]: D3DX supports a wide range of file types for textures. Instead of rewriting everything from scratch, the best would certainly be to use some image processing library to handle them. As a bonus, this would allow lighter code. I'm not sure it would be worth it. The only non-trivial formats I see in D3DXIMAGE_FILEFORMAT are JPEG and PNG, and we already link to libjpeg and libpng in other parts of Wine. If you want, I have an implementation of this same function for png... This one is not commented at all, and need some rework. Get it for comparison.
Re: ntdll:Add a semi-stub for SystemExecutionState in NtPowerInformation
Le Saturday 05 April 2008 23:08:59, vous avez écrit : This adds a semi-stub for SystemExecutionState in NtPowerInformation, always considering that the user is acting with the computer. Please ignore this one, I sent the wrong file.
Re: winegcc: A spec file is currently needed in shared mode?
Le Sunday 23 March 2008 12:43:31 Erik de Castro Lopo, vous avez écrit : Hi all, Any idea what the above means and how to fix it? Cheers, Erik This means that winegcc is currently unable to know what function should be exported when building in shared mode. The only way to fix this is writing a spec file and passing it in winegcc args. See winegcc --help. ___ Yahoo! Mail réinvente le mail ! Découvrez le nouveau Yahoo! Mail et son interface révolutionnaire. http://fr.mail.yahoo.com
Re: Improving the Wine Users Guide
Le Sunday 16 March 2008 19:17:38 Lei Zhang, vous avez écrit : * Section 3.1.2.1 - are there dlls besides kernel32, gdi32, user32, and ntdll that we should never use the native one? Add warning about downloading dlls from the web. Isn't ddraw a part of this ones ? ___ Yahoo! Mail réinvente le mail ! Découvrez le nouveau Yahoo! Mail et son interface révolutionnaire. http://fr.mail.yahoo.com
Some questions about texture functions of d3dx8/9
I'm trying to implement the D3DXGetImageInfoFrom* functions in d3dx8/9 dlls,
and I have a few questions.
As there is no related source file from this kind of functions, I created
texture.c within dlls/d3dx8. I guess this is the way you want it, but I'd
like to hear it from you.
Then I need libpng to handle this. I know that gdi32 has some (limited)
support for this files, but I wasn't able to know how it was included in its
code. A simple #include png.h doesn't work, as I expected. So I would like
to know how wine build process handle third party libraries.
Then, I'd like to know what you think about the code attached here. Please
don't forget that this is the very first time I make some code for wine !
Cheers.
Jérôme
/*
* Direct3D X 8 textures related functions
*
* Copyright (C) 2002 Raphael Junqueira
*
* This library is free software; you can redistribute it and/or
* modify it under the terms of the GNU Lesser General Public
* License as published by the Free Software Foundation; either
* version 2.1 of the License, or (at your option) any later version.
*
* This library is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
* Lesser General Public License for more details.
*
* You should have received a copy of the GNU Lesser General Public
* License along with this library; if not, write to the Free Software
* Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA
*
*/
#include config.h
#include wine/port.h
#include stdarg.h
#define COBJMACROS
#include windef.h
#include winbase.h
#include wingdi.h
#include winuser.h
#include wine/debug.h
#include d3d8.h
#include d3dx8_private.h
#include d3dx8tex.h
WINE_DEFAULT_DEBUG_CHANNEL(d3d);
const char png_header[] = {137, 80, 78, 71, 13, 10, 26, 10} ;
static HRESULT Get_Info_from_BMP_In_Memory( LPCVOID pSrcData, D3DXIMAGE_INFO* pSrcInfo)
{
BITMAPINFOHEADER* info_header = (BITMAPINFOHEADER*) pSrcData + sizeof(BITMAPFILEHEADER) ;
pSrcInfo-Width = info_header-biWidth ;
pSrcInfo-Height = info_header-biHeight ;
pSrcInfo-Depth = info_header-biBitCount ;
pSrcInfo-MipLevels = 0 ;
pSrcInfo-ResourceType = D3DRTYPE_TEXTURE ;
pSrcInfo-ImageFileFormat = D3DXIFF_BMP ;
switch (pSrcInfo-Depth) {
/*1 and 4 are unlikely to happen. Anyway, handle it as 8 bpp*/
case 1 :
case 4 :
case 8 :
pSrcInfo-Format = D3DFMT_P8 ;
break ;
case 16 :
pSrcInfo-Format = D3DFMT_X1R5G5B5 ;
break ;
case 24 :
pSrcInfo-Format = D3DFMT_R8G8B8 ;
break ;
case 32 :
pSrcInfo-Format = D3DFMT_X8R8G8B8 ;
break ;
}
return D3D_OK ;
}
#if 0
typedef struct _IN_MEMORY_PNG {
LPCVOID data ;
INT offset ;
} IN_MEMORY_PNG ;
static void read_png_file_from_memory(png_structp png_ptr, png_bytep data, png_size_t length)
{
IN_MEMORY_PNG* src = (IN_MEMORY_PNG*) png_get_io_ptr(png_ptr) ;
memcpy(data, src-data + src-offset, length) ;
src-offset += length ;
}
static HRESULT Get_Info_From_PNG_In_Memory( LPCVOID pSrcData, D3DXIMAGE_INFO* pSrcInfo)
{
IN_MEMORY_PNG This ;
This.data = pSrcData ;
This.offset = 0 ;
/*If the png_* functions fail, then this is likely a bad call*/
png_structp png_ptr = png_create_read_struct (PNG_LIBPNG_VER_STRING,NULL,NULL,NULL) ;
if(!png_ptr)
return D3DERR_INVALIDCALL ;
png_infop info_ptr = png_create_info_struct(png_ptr);
if(!info_ptr) {
png_destroy_read_struct(png_ptr, (png_infopp)NULL, (png_infopp)NULL);
return D3DERR_INVALIDCALL ;
}
if ( setjmp(png_ptr-jmpbuf) ) {
png_destroy_read_struct(png_ptr, info_ptr, (png_infopp)NULL);
return D3DERR_INVALIDCALL ;
}
pSrcInfo-ImageFileFormat = D3DXIFF_PNG ;
pSrcInfo-ResourceType = D3DRTYPE_TEXTURE ;
png_set_read_fn(png_ptr, (png_voidp*) This, read_png_file_from_memory) ;
png_read_info(png_ptr, info_ptr);
pSrcInfo-Width = png_get_image_width(png_ptr, info_ptr) ;
pSrcInfo-Height = png_get_image_height(png_ptr, png_info) ;
pSrcInfo-Depth = png_get_bit_depth(png_ptr, png_info) ;
pSrcInfo-MipLevels = 0 ;
pSrcInfo-ResourceType = D3DRTYPE_TEXTURE ;
pSrcInfo-ImageFileFormat = D3DXIFF_PNG ;
switch (png_get_color_type(png_ptr, info_ptr)) {
case PNG_COLOR_TYPE_GRAY :
pSrcInfo-Format = D3DFMT_L8 ;
break ;
case PNG_COLOR_TYPE_GRAY_ALPHA :
if (pSrcInfo-Depth == 8)
pSrcInfo-Format = D3DFMT_A4L4 ;
else
pSrcInfo-Format = D3DFMT_A8L8 ;
break ;
}
return D3D_OK ;
}
#else
static HRESULT Get_Info_From_PNG_In_Memory( LPCVOID pSrcData, D3DXIMAGE_INFO* pSrcInfo)
{
FIXME(Wine Has been built without PNG support. Expect problems) ;
return D3D_OK ;
}
#endif
Implementing a new Direct3D function
I'm trying to implement some direct3d functions, more precisely the GetImageInfoFromFile* ones. These are present in directX 8 and in d3dx9_xx.dll I wondered what is the best way to do this : 1)Implementing it in d3dx8.dll and forward everything to this one. 2) Make some useful functions in wined3d and then use them from d3dx8. 3) Implement them directly in wined3d, forwarding everything to it. 4) An other way ? Cheers. Jérôme ___ Yahoo! Mail réinvente le mail ! Découvrez le nouveau Yahoo! Mail et son interface révolutionnaire. http://fr.mail.yahoo.com
Re: Implementing a new Direct3D function
Le Sunday 09 March 2008 18:35:16 [EMAIL PROTECTED], vous avez écrit : D3DXGetImageInfoFromFile takes the D3DXIMAGE_INFO structure as parameter, which has changed between d3dx8 an dd3dx9_36 though. This means you can't forward the D3DXGetImageInfoFromFile calls from d3dx9 to d3dx8, (even if it is done like that atm, you should fix that an you patch) so you'll have to write two versions of each. Our plan for implementing d3dx was to keep any d3dx code away from wined3d, so you don't have to change anything about that. So basically all you have to do is (1) implement the d3dx8 version of each function (2) add them to the d3dx8 specfile (3) implement the d3dx9_36 version of each function (3) correct the d3dx9_36 specfile (i.e. remove the forwarding to d3dx8) The d3dx9_24 to 35 dlls forward their calls to d3dx9_36, so they are okay, too. Tony Unbegrenzter Speicher, Top-Spamschutz, 120 SMS und eigene E-MailDomain inkl. http://office.freenet.de/dienste/emailoffice/produktuebersicht/power/mail/i ndex.html OK, then I'll do this that way. Also, d3dx9 provides support for multiple file format (PNG, TGA, BMP...). I assume I'll have to add those dependencies in the build process. ___ Yahoo! Mail réinvente le mail ! Découvrez le nouveau Yahoo! Mail et son interface révolutionnaire. http://fr.mail.yahoo.com
have a reference somewhere for mingw
I've noticed that mingw is quoted here and there in the documentation, but there is no proper howto/doc which explains its installation. This tool is very useful for cross-compiling and testing wine. I found a very good tutorial here, on the wxwidget site (!!) http://www.wxwidgets.org/wiki/index.php/Install_The_Mingw_Cross-Compiler Why not include it into the wine wiki ? ___ Yahoo! Mail réinvente le mail ! Découvrez le nouveau Yahoo! Mail et son interface révolutionnaire. http://fr.mail.yahoo.com
Re: .NET apps with mono... some testing.
Le Saturday 29 December 2007 16:43:45 Maarten Lankhorst, vous avez écrit : Jérôme Gardou schreef: Many .NET/C# apps don't work with the combination wine-mono. I've discovered that installing the arial32 from msttcorefonts solves a lot of problems, especially with graphical apps. I've tested a few apps (supreme commander patches, fastmd5 (tested here http://bugs.winehq.org/show_bug.cgi?id=10467 with native .NET...) and all of them worked quite well, although not quite beautiful. Which mono version did you use? mono-1.2.6 with gtksharp 2.10.2 . the latest available on mono website. I'm trying to figure out why font rendering is so bad on gtk# applications. (try gtk theme manager... it's awful) ___ Yahoo! Mail réinvente le mail ! Découvrez le nouveau Yahoo! Mail et son interface révolutionnaire. http://fr.mail.yahoo.com
Re: .NET apps with mono... some testing.
Le Saturday 29 December 2007 16:55:28 Jérôme Gardou, vous avez écrit : Le Saturday 29 December 2007 16:43:45 Maarten Lankhorst, vous avez écrit : Jérôme Gardou schreef: Many .NET/C# apps don't work with the combination wine-mono. I've discovered that installing the arial32 from msttcorefonts solves a lot of problems, especially with graphical apps. I've tested a few apps (supreme commander patches, fastmd5 (tested here http://bugs.winehq.org/show_bug.cgi?id=10467 with native .NET...) and all of them worked quite well, although not quite beautiful. Which mono version did you use? mono-1.2.6 with gtksharp 2.10.2 . the latest available on mono website. I'm trying to figure out why font rendering is so bad on gtk# applications. (try gtk theme manager... it's awful) Some more feedback here. Changing the key HKEY_CURRENT_CONFIG\Software\Fonts\LogPixels from 96 to 2 changes everything. From enormous characters in gtk# programs, there is now a good size in those apps. Obviously, this is not the good way to get it working. ___ Yahoo! Mail réinvente le mail ! Découvrez le nouveau Yahoo! Mail et son interface révolutionnaire. http://fr.mail.yahoo.com
winelib and exceptions
Hello. I'm trying to handle exceptions in a winelib program i'm writing. after #include exceptions.h I'm using the GetExceptionInformation() function, but then winegcc complains that __eptr has not been defined. Any tip/idea on what's going on ? ___ Yahoo! Mail réinvente le mail ! Découvrez le nouveau Yahoo! Mail et son interface révolutionnaire. http://fr.mail.yahoo.com
Re: illegal characters in file names
Le Thursday 28 June 2007 22:51:17 Lei Zhang, vous avez écrit : Hi, I noticed a mismatch between the list of illegal characters in file names between Wine and Windows. On Wine the list of characters is: /:| and on Windows, it is: \/:*?| Is this intentional or something we should fix? - Lei All I know is that wine shouldn't use * and ? , since it is used in wildcards on both Unix and Windows ! The \ character is the separator between directories on Windows, but it is not forbidden on Unix. Wine is an Unix software, it should be allowed to use it too ! The character is apparently not forbidden on Unix, so wine can use it. ___ Yahoo! Mail réinvente le mail ! Découvrez le nouveau Yahoo! Mail et son interface révolutionnaire. http://fr.mail.yahoo.com
Winelib should have dir.h and some consts
I try to compile a small program which use msvcrt headers, and it appeared that, in winelib there is no dir.h (which may be redirected to dirent.h ?) and that consts like MAXPATH, MAXDRIVE and others are not defined. Should it be done ? Is it planned to be ? ___ Yahoo! Mail réinvente le mail ! Découvrez le nouveau Yahoo! Mail et son interface révolutionnaire. http://fr.mail.yahoo.com
