Am 05.07.2011 20:33, schrieb Gerald Pfeifer:
On Tue, 5 Jul 2011, Alexandre Julliard wrote:
This does not fix a bug or add a feature, but it makes the coder easier
to follow. Narrower scope tends to be a good thing for variables, both
for human readers and compilers (though modern ones should no
Am 19.04.2010 20:48, schrieb Christian Costa:
> Well, it's your code, correct ?
> I suggest to simply remove these checks. There does not bring any
> added values.
It's my own code, but I noticed this flaw some time after GSoC was over,
it can be quite disturbing.
Additionally, the checks might not
> +static inline void check_ref(IUnknown *obj, int exp)
> +static inline void check_release(IUnknown *obj, int exp)
We shouldn't use these function definitions anymore IMO, either do the ref
check in the code itself, or replace the check_ref and check_release functions
with macros; the reason is
Am 28.01.2010 21:42, schrieb Loïc Hoguin:
>
> What would be the solution then to have a chance to get Tony's work
> committed if he can't/won't do the rest of the work himself
FWIW, I handed in my skilled-work paper today, so I've had some spare
time today again. I just prepared a patch which imple
Am 28.01.2010 20:38, schrieb Reece Dunn:
> There is already support for WIC codecs by Vincent Povirk that has
> been committed into wine, supporting bmp, jpeg, gif, png and other
> formats.
>
> I don't know how complete this is, though, for what D3DX needs.
>
> - Reece
>
>
yeah, the plan was to
Am 28.01.2010 19:46, schrieb Loïc Hoguin:
> If a student wishes to do the integration work as a SoC project, then
> I'll step down. It'll certainly be more helpful for a student than for
> me. I can find another project to work on in that case.
>
>
Not sure whether integration of my work is stil
About my own work, it's not been integrated that much, yet: Loïc Hoguin
has expressed interest to integrate them, but I'm not sure whether he
was sure about that, yet.
I might work again on integrating my texture stuff in case you'd really
participate in gsoc with some d3dx stuff, can't promise an
> Hello,
>
> Well I'm mostly interested in the texture code, but I probably shouldn't
> begin with that. So I'll take the font code. It's not really a critical
> part so I can take my time doing it and learning wine development
> without conflicts with my normal schedule. Then if the texture code
Hi,
We've had two D3DX projects last year - one implementing shaders, the
other (which was mine) implementing meshes, fonts and texturing code.
Both have only partially been integrated, yet (as far as I know), but
most of the other stuff in d3dx9 is still untouched, you can take a look
at the msdn
> Hello,
> I might be interested as a side project. I've been poking around in the
> wine code looking for something interesting for the last few weeks and
> this might be it. However I know I wouldn't have much interest in it if
> it doesn't actually help me, so I'd like to know a few additional
x27;ll
provide him with the most up-to-date work of mine.
If there's anything anyone might want to ask, just answer this mail or
contact me directly on irc at #winehackers, my nick is BigBrain and I'm
around quite often.
Best regards, Tony Wasserka
>
> You are right, but it would be neat to have them all grouped like they
> are in d3dx9tex.h.
>
Not sure about that, assuming we ever support all possible filters and
conversions in D3DXLoadSurfaceFromMemory, we probably don't want to have
the texture stuff starting suddenly at line 3k or some
Hi,
> If you make those into arrays you will be able to cut down on the code size,
> and the compiler might like it better.
>
While I didn't notice any speedups in the code itself, it's a bit
cleaner (especially the format table) now, thanks!
(Come to think about it, it wouldn't have made much
Hi,
thanks for the feedback, I agree with most of what you said. Just a few
comments:
> I think the main thing is that you really don't want branches inside the
> inner loop. You can handle the cases where a component is unused
> by building a mask before entering the loop and just or'ing with th
her comments which could be interesting to me at this point are
also appreciated, of course.
Best regards,
Tony
>From 4a726e260502e8ad9ccb5ab11549b946fa236528 Mon Sep 17 00:00:00 2001
From: Tony Wasserka
Date: Tue, 25 Aug 2009 14:30:52 +0200
Subject: [PATCH] d3dx9: Implement converting an
> Watch out, some surfaces aren't lockable. I don't know the d3dx9 api too
> well,
> but are you sure that you have a lockable surface here?
> In some situations IDirect3DDevice9::UpdateSurface or
> IDirect3DDevice9::StretchRect may be a faster way to achieve what this code
> does(without color
Roderick Colenbrander schrieb:
> Hi Tony,
>
> +WideCharToMultiByte(CP_ACP, 0, This->desc.FaceName, -1,
> desc->FaceName, sizeof(desc->FaceName) / sizeof(CHAR), NULL, NULL);
>
> sizeof(desc->FaceName) / sizeof(CHAR) won't give you the length of the
> string (remember that sizeof is evaluated at
Roderick Colenbrander schrieb:
> Hi Tony,
>
> +hr = D3DXCreateFontA(device, 12, 0, FW_DONTCARE, 0, FALSE,
> DEFAULT_CHARSET, OUT_DEFAULT_PRECIS, DEFAULT_QUALITY, DEFAULT_PITCH,
> "Arial", &font);
>
> A bunch of font tests all use Arial. On Windows this font is always
> around, what happens on W
Stefan Dösinger schrieb:
> Am Wednesday 17 June 2009 18:29:57 schrieb Tony Wasserka:
>
>
>> @@ -300,6 +301,12 @@ HRESULT WINAPI
>>
> D3DXCreateFontIndirectW(LPDIRECT3DDEVICE9 device, CONST D3DXFONT_
>
>> object->device=device;
>>
Ben Klein schrieb:
> 2009/5/23 Stefan Dösinger :
>
>> Am Freitag, 22. Mai 2009 19:15:22 schrieb Roderick Colenbrander:
>>
>>> So what they are saying is that Nvidia has a license on the s3tc
>>> patent for use in those tools but if we would rip their code out we
>>> wouldn't be covered unle
Hi everyone,
I'm working on implementing D3DXLoadSurfaceFromFileInMemory right now,
but I've got a problem. The function
most convert a loaded surface's data to a user specified surface format
(I did not yet find a way to do it elsehow,
UpdateTexture and StretchRect are to limited for that task, su
> Hi,
>
> the declaration of IntersectionTri is
> BOOL IntersectionTri(.) in d3dx8mesh.h and
> BOOL WINAPI? IntersectionTri(.) in d3dx9mesh.h .
>
> Is the latter one compatible with the former one (so I can forward d3dx9
> function to the d3dx8 one)
> or must I implement them separately?
ID3DXSprite
patch series is applied, but I already had all of them pass/todo'ed.
Note2: visual tests will follow later, this is just for the basic
functionality)
>From 02587ae3cedb0b68fba1c360f63d2571c175bf07 Mon Sep 17 00:00:00 2001
From: Tony Wasserka <[EMAIL PROTECTED]>
Date:
Hi,
> +#include "config.h"
> +#include "wine/port.h"
> +
> +#include
> +
> +#include "windef.h"
> +#include "winbase.h"
> +#include "wingdi.h"
> +#include "winuser.h"
> +#include "wine/debug.h"
> +
> +#include "d3dx9.h"
There's no point in including so many unneccessary header files.
Hi,
one very little thing: You could include d3dx9.h (from d3dx9effect.h)
after the #define __D3DX9EFFECT_H__, as this reduces compile time
slightly when included twice or more. No actual reason to resend though,
just an advice for future.
Best regards,
Tony
Hi,
you forgot the WINAPI in front of the function declaration and
implementation.
Maybe you should add a set_mat(_11, _12, _13, ) macro to make the
exp_mat better to read and not that big in size,
However, I think it's better to dynamically calculate the expected
matrix rather than compare
ee no problem in the existing makefiles then, as linking
with d3dx9 should work.
Can't help you with that though as I don't have a working Windows
installation ATM though :-/
> Hi,
>
> any idea to fix this problem?
>
> David
>
> 2008/9/11 Tony Wasserka <[EMAIL
Your latest patch is already doing it right, IMPORTS must be changed to
d3dx9_36 and IMPORTLIB must stay d3dx9.
>
>
> any idea to fix this problem?
>
> David
>
> 2008/9/11 Tony Wasserka <[EMAIL PROTECTED]
> <mailto:[EMAIL PROTECTED]>>
>
>
>
> On Mi, 2008-09-10 at 18:16 +0200, Tony wrote:
>
>> Hi,
>> At least for all Windows versions below Vista, the d3dx9 importlib does
>> exist (and d3dx9_36 does not),
>>
>
> I installed a recent dx9-runtime on my w2k test system, but a d3dx9.dll
> is not
> present (d3dx9_36.dll exist).
>
>
yeah, but your patch is only semi-correct in that regard.
What you are referring to (d3dx9.dll) is an import (IMPORTS) of the test
program, i.e. a dll which is needed to run the program. What your patch
is doing with that var is correct (i.e. we must use d3dx9_36 instead of
d3dx9).
However, the
Hi,
> +HRESULT WINAPI D3DXCreateEffectEx(LPDIRECT3DDEVICE9 pdevice, LPCVOID
psrcdata, UINT srcdatalen, D3DXMACRO *pdefines,
> + LPD3DXINCLUDE pinclude, LPCSTR pskipconstants, DWORD flags,
LPD3DXEFFECTPOOL ppool, LPD3DXEFFECT * ppeffect,
> + LPD3DXBUFFER * ppcompilationerrors)
> +{
> +ID3D
Hi,
There were quite a number of minor issues in you code:
In Makefile.in:
> C_SRCS = \
> d3dx9_36_main.c \
>+effect.c \
> font.c \
Use tabs here, please, as the intendation switches here on other
computers.
In effect.c:
+ * modify it under the terms of the GNU Lesser General
Hi,
1. The order of
+/*The components of the translation transformation vector are straigth in
the fourth column of the transformation matrix*/
+(*pouttranslation).x=(*pM).m[3][0];
+(*pouttranslation).y=(*pM).m[3][1];
+(*pouttranslation).z=(*pM).m[3][2];
+
+/*Let's calculate
>From 66f62937ccb3a562e0c6cc489a5099166870efeb Mon Sep 17 00:00:00 2001
From: Tony Wasserka <[EMAIL PROTECTED](none)>
Date: Sat, 12 Jul 2008 13:02:25 +0200
Subject: [PATCH] d3dx9: Add stubs for the ID3DXSprite functions
---
dlls/d3dx9_36/Makefile.in|3 +-
dlls/d3dx9_36/d3dx9_36.spec |2 +-
> So... lots of people are going around installing
> all of directx, and maybe all they needed was, say,
> d3d9x_35. That's not good. This sounds like
> a job for winetricks!
> But I know nothing about direct3d. Could somebody
> have a look at this draft and see if it suffices? All
> I added wa
> > So, the first thing I want to make sure is that we redirect the function
> > calls correctly in order
> > to reduce double coding.
> > This means on the one hand that we should call the Extended versions of
> > each function
> > from inside of the simpler ones (most default parameters for the
Hi all,
as it's a larger chunk of functions, I felt like proposing my design idea for
the
D3DXCreateTexture/Volume/CubeTextureFromFile/Resource/FileInMemory/etc...
functions. I'm CC'ing it to any wine d3dx coder I have in my addressbook yet,
so sorry if I forgot one :)
So, the first thing I want
> I have a hacky implementation of D3DXLoadSurfaceFromMemory and
> D3DXLoadSurfaceFromSurface, as well as a pretty good implementation of
> D3DXCreateTexture and D3DXCheckTextureRequirements.
>
> I'll send in the patch for the last two when I have time, and have
> looked it over a final time.
Hi,
Are you still working on the texture functions?
I'd need them for completing my ID3DXSprite implementation,
so if you don't mind I could complete your started patches.
Best regards,
Tony
Unbegrenzter Speicher, Top-Spamschutz, 120 SMS und eigene E-MailDomain inkl.
http://office.freenet.
> > +This->current = This->current +1;
> > +HeapReAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, This->matrix,
> > (This->current +1) * sizeof(D3DXMATRIX) );
> > +if ( This->matrix == NULL ) return E_OUTOFMEMORY;
> Aside from being a bit suboptimal (doing a realloc on every push),
> this p
> Well no, you keep track of the array size and grow it when it's too
> small when doing a push.
i.e. HeapReAlloc
http://msdn2.microsoft.com/en-us/library/aa366704(VS.85).aspx
You may optimize that if you allocate space for 2 or so matrices at once,
as it decreases the number of HeapReAlloc calls
> The commit comment for this patch is rather non-descriptive... what is
> this supposed to fix?
> An array based stack seems more appropriate than a list based one for
> ID3DXMATRIXStack, why change that?
I think so, too (after taking a closer look at the interface documentation at
msdn).
Though
I read an interesting article on slashdot today:
http://tech.slashdot.org/tech/08/04/04/1437258.shtml
> Windows 7 will be a from-the-ground-up packaging of the Windows codebase;
> partially source,
> but not binary compatible with previous versions of Windows."
Sounds like they format, i.e. mayb
> Can someone confirm this to be already finished (and then remove this item
> from
> the wiki?) If it isn't finished yet, what IS missing then?
Nearly everything is missing. It's just the forwarding and some stubs that have
been defined, yet,
and the D3DXRenderToSurface implementation I submit
> Hello
>
> 1) use 4 spaces instead of tab in
>
> d3dx9_36_main.c
> font.c
> - math.c
> + math.c
> +texture.c
>
>
> 2) D3DXCreateTextureFromFileW(ptr wstr ptr) should be forwarded to its d3dx8
> counterpart and you implement it in d3dx8 dll
>
>
> David
No, tab
> It would probably be better to avoid doing that. It isn't quite the
> same as disassembling the native implementation, but in general you
> want to avoid looking at how the native implementation is implemented
> rather than how it behaves.
I have to admit that I didn't think of these kind of thin
Hi,
When I was trying to find out how the native d3dx9_36.dll handles
ID3DXRenderToSurface->BeginScene()
with WINEDEBUG="+d3d9,heap" I had the problem that I had to find out what
functions are called
within the dll and what functions are called by the d3d9 functions (and thus
are irrelevant for
> Shouldn't that be a n (here and in the other patches)?
> Setting object to NULL here doesn't do a whole lot, you should set
> *object to NULL (also goes for the other QueryInterface
> implementations). Also, you'll probably want to put the TRACE before
> the if block.
Thank you very much for po
Okay, thanks. Then I'll just resend them and see if they get in this time.
Unbegrenzter Speicher, Top-Spamschutz, 120 SMS und eigene E-MailDomain inkl.
http://office.freenet.de/dienste/emailoffice/produktuebersicht/power/mail/index.html
Hi,
It's nearly two weeks ago that I sent those patches, so I was curious if there
are any
problems with it?
http://www.winehq.org/pipermail/wine-patches/2008-February/049554.html
http://www.winehq.org/pipermail/wine-patches/2008-February/049667.html
http://www.winehq.org/pipermail/wine-patches/20
Oh well, I forgot one point:
if you take my example code again, but don't build it under winelib
but under windows (i.e. it's a real win application) but later run
it with wine it may also fail because all dlls forward to the
D3DXCheckVersion of d3dx9_36. I know that you would have
implemented anot
I probably should've gone into a bit more detail about this function:
It's just for developer purpose. If you have a very big project and
are trying to upgrade e.g. from d3dx9_27 to d3dx9_36 some files
may need to be rebuild, some files may not. This function is just there
to ensure the developer t
> The function D3DXCheckVersion must not be forwarded from each d3dx9_xx file
> to the 36 because D3DX_SDK_VERSION changes for each file.
Thanks for your comment, though I don't know if this is needed:
Comment from the d3dx9core.h of the DX SDK:
> ///
Hi,
So far I have pretty much completed the d3dx9_24 dll. However, while writing the
spec files I faced a few problems which I'd like to have solved befor submitting
the patch:
1. With the d3dx9_31 dll, microsoft removed three functions from the SDK. I'm
curious
what to do with them. Should I
> Find attached some data on d3dx8, d3dx9_xx and d3dx10_xx implementations:
> dll files by d3dx extension:
> d3dx8 1 dll files
> d3dx9_xx 13 dll files
> d3dx10_xx 4 dll files
> [...]
>
Nice work, how did you get the data?
Did you run Dependency Walker on each dll or is there a more
> You need to forward all the functions of d3dx9_24 to these ones of d3dx9_36;
> not only these ones that are already implemented in d3dx9_36.
>
> Moreover, when you create a new dll, you need to change plenty of files:
> configure
> configure.ac
> Makefile.in
> in the folder ~/wine-git/
>
> You
What's wrong with it this time?
Thought that it was okay this time :D
> There are quite a few installers that use RunOnce to get around file
> locking, but I still haven't had to use one fortunately. As I said, as
> long as I can disable it. RunOnce wouldn't even have to be disabled,
> I'd be happy with a "RunOnce wants to execute 'foo.exe blipp blopp',
> 'No, and cl
> Please stop resending that big patch again and again, it's not going in,
> it's full of problems. You need to provide correct forwards for all
> functions instead of stubs, and the functions need to match the Windows
> ones, you can't just copy the same spec file 12 times. Also the code was
> wri
Oh okay, I resent a fixed patch.
Why isn't it possible to forward the functions of the other dlls to the d3dx8
ones?
Or is this just for keeping the code clean so that we don't have mixed d3dx8
and d3dx9_36 forwardings?
This patch adds the d3dx9core header file, which is used for the interface
declarations.
0002-d3dx9-Add-d3dx9core.h.patch
Description: Binary data
> Well, why then hasn't this patch been accepted?
> http://www.winehq.org/pipermail/wine-patches/2007-November/047212.html
Oh well, I see, corrupted...
Seems like I'll spend the day on fixing that one :D
Well, why then hasn't this patch been accepted?
http://www.winehq.org/pipermail/wine-patches/2007-November/047212.html
Okay, I have a bit time now and tomorrow, so I'll probably have submitted a
basic d3dx9 dll patch
until Wednesday. So I'll create a new d3dx9 directory inside dlls, but I'm not
that familiar with
Wine's makefile system (not very much with makefiles in general honestly), so
can anyone
tell me how
> Since everybody agrees that we need a built-in d3dx9, we could begin to
> implement it.
> In the last talk about it, no plan was found to implement it: does one create
> a wined3dx or implement on the top of the last d3dx9
> dll?
>
> So, I think that a definitive answer should be given very qu
> I do not think patents which are blocking your ability to use the DLLs
> in Wine. It is your Windows license.
>
> I believe that if you have a Windows license for your machine, you are
> free to use Windows or its DLLs. This includes all the "free" downloads
> from their web-pages. I think, if y
ned
stuff.
Best regards,
Tony Wasserka
(PS: if one argues that we need the implementation for WineLib, I _think_ it'd
be enough to just
stub all functions so that the program compiles fine and then use the native
dll again)
Okay, then that has been discussed.
By the way, what about David's second patch?
Was there anything wrong about it or why isn't it in the tree, yet?
> So, just to clarify, you propose to create a d3dx9.dll dll, putting its
> code in dlls/d3dx9. Does this dll exist on Windows? If not, then we
> should call it wined3dx9 (and its code would go in dlls/wined3dx9).
Well, it shouldn't even be a dll, just a folder were put in all the d3dx9 code
and
Anyways, where should we put the d3dx9 code? I mean, we have 13 folders to
choose from.. Perhaps It'd be better if we create a new dll (or at least
directory) called d3dx9 were we implement all d3dx9 stuff and let the other
d3dx9_xx dlls just call these functions? This would improve the clarity
70 matches
Mail list logo
