On 10/28/2009 06:32 AM, Stefan Dösinger wrote:
Am 27.10.2009 um 20:10 schrieb Rico Schüller:
Hi,
this patch series implements a couple of ID3D10EffectVariable::As*()
functions (patches 2-11).
Do we have any tests for the As* behavior?
Most conversions don't make any sense, so if the app
Re: [5/6] WineD3D: Write the vshader footer in a separate function
I like this patch - would be great to have more of these:
Lines that fit on the screen in my gnome-terminal: 50
Average size of six large ARB shader functions, before this
patch: 205
(generate
Henri Verbeet wrote:
This looks like data structure design mixed with GL and shader code. I
think it would be better if the data structure was in its own file,
without any GL or D3D dependencies, and wined3d and other components
could use it.
- Ivan
Re: [4/5] wined3d: Use a bitmask to store which bool and int
constantsare set.
Why is this a good thing - this just artificially caps your constants at
32. If I remember correctly I had to change shaders to do the exact
opposite change, because newer versions introduced more than 32
This isn't the prettiest way to merge those functions, but it's a start
Will you be cleaning this up further to get rid of the huge if-else ?
I think at least all the MOV-specific stuff should go in its own instr.
function.
Ivan
Luis Busquets wrote:
+if ((caps.VS20Caps.NumTemps=13)
+(caps.VS20Caps.DynamicFlowControlDepth=24)
+(caps.VS20Caps.CapsD3DPS20CAPS_PREDICATION))
+{
+return vs_2_a;
+}
Please re-check - the
James Hawkins wrote:
context.c - same except in this case its just a return with noting else..
why do a goto why not just do the return?
This is probably ok to change. I can only imagine that the original
author thought there might be cleanup needed at some later point.
The bigger
Ivan Gyurdiev wrote:
James Hawkins wrote:
context.c - same except in this case its just a return with noting
else..
why do a goto why not just do the return?
This is probably ok to change. I can only imagine that the original
author thought there might be cleanup needed at some later
Stefan Dösinger wrote:
A function pointer is a nice idea actually. I don't think we'll ever need
more than one extension per state line though,
You already have this case:
} else if(GL_SUPPORT(NV_REGISTER_COMBINERS)
GL_SUPPORT(NV_TEXTURE_SHADER2)) {
return nvts_fragment_pipeline;
Stefan Dösinger wrote:
This doesn't look bad on the surface, but I have two concerns:
1. Does not scale to more complex support checks. I suspect you'll have
to have to rewrite this as soon as a case comes up that requires more
than a single support check to establish support. A function
Zachary Goldberg wrote:
... but did not spell check :)
Granted, the movie quote is pretty funny, even if isn't spelled right.
Ivan
Michael Karcher wrote:
Does anyone knows whether the test has this been written buggy on
purpose (some app does this), or it is by accident?
Probably the first one - I wrote the test with rather limited
understanding of how rendertargets work.
I don't think there was a specific application
Stefan Dösinger wrote:
Am Montag, 2. Juni 2008 08:11:13 schrieb Roderick Colenbrander:
The bugs I'm talking about:
Bug 10580
Sorry that I did not have time yet to look into that, but instead of ranting
you could also look at the GLSL docs and make a patch.
I did see a precision
Ivan Gyurdiev wrote:
Michael Karcher wrote:
Does anyone knows whether the test has this been written buggy on
purpose (some app does this), or it is by accident?
Probably the first one - I wrote the test with rather limited
understanding of how rendertargets work.
I don't think
Of the apps we have tested with Wine, about 20% work well,
and about another 20% work but have some glitches.
Just my opinion, but that's a terrible idea to put in the 1.0
announcement. The impression I get after reading this is (1) wine is
full of glitches, and (2) it's being released
How about this for more positive yet realistic phrasing:
Of the apps we have tested with Wine, about half work well
enough to try, and of those, half work well enough to use routinely.
In particular, Photoshop CS2, World of Warcraft, Firefox 2, and many
small apps run very well. .NET based
What are your opinions?
I can't comment on the specifics of the state table design - would have
to leave that to Henri. However, anything that increases modularity is a
good thing. I'm in favor of the overall direction to break up the
pipeline into component stages. Smaller components are
Stefan Dösinger wrote:
Alexandre didn't commit the patch, I think we should come to an agreement on
this issue, otherwise it is going to come up again and again.
The fundamental issue is pretty straightforward - not sure why it's so
difficult to come to an agreement.
- You want to mix
Name=Wine Windows Emulator
I like the expanded version better:
Wine is not an emulator windows emulator.
Should help clear up any questions people might have :)
Shader Model 3.0 and earlier versions have different ways to pass varyings
from vertex to pixel shader. In the end this means that the pixel shader is
dependent on the vertex shader. If the vertex shader is a GLSL shader, it can
read either the builtin varyings or the declared ones, the
Henri once suggested making the shader_backend_t structure a COM object, that
is created and destroyed by the device. That would make the state of the data
it manages clearer(belongs to the shader object), though it would add some
stuff we don't need, like the IUnknown parts, refcounting.
Stefan Dösinger wrote:
Am Mittwoch, 19. März 2008 07:46:07 schrieb Ivan Gyurdiev:
Why do you need to reroute the shader path through atifs to support an
unrelated set of functionality (ffp replacement)? Isn't it possible to
have an ffp_backend, and a shader_backend (shader being the d3d
Stefan Dösinger wrote:
I'll get back to you on that later tonight, need to think about this
some more - way late for work right now... (thanks to you!)
However, yes, I think there needs to be distinction between a standalone
shader concept, and a pipeline concept, which is concerned with
Stefan Dösinger wrote:
Hi,
Given the past discussion, do you agree with the code now? Alexandre wants
your OKs before applying the patches.
I am not familiar with the state table, atifs, or recent developments in
the d3d codebase. That's why I suggested a diagram, so that everyone can
Luis C. Busquets Pérez wrote:
This functions gets the Version Token of a binary shader. This Token
is the first of the binary stream so it is as easy as picling the
pointed DWORD. This is all public information available to the public.
What happens when the shader is NULL?
Yours will crash -
I don't quite understand why it's necessary to write ARB, GLSL, and NONE
shader descriptors inside the ati_shader file.
How will this infrastructure scale to a new shader backend added a year
from now ?
For such a large patchset maybe there should be a high level design
diagram that explains
Stefan Dösinger wrote:
Am Sonntag, 16. März 2008 15:00:49 schrieb Ivan Gyurdiev:
I don't quite understand why it's necessary to write ARB, GLSL, and NONE
shader descriptors inside the ati_shader file.
How will this infrastructure scale to a new shader backend added a year
from now
No matter what if your running a program, be it linux or windows (on
wine) it always has the potential to mess up things that the user
running it has access too.
Not true - you should be running in a SELinux sandbox to solve this problem.
I'm not sure if the technology is mature enough for
Dan Kegel wrote:
Here are the bugs marked fixed during the 0.9.56 cycle.
(A few of them were fixed earlier, but not marked as such before.)
It might be nice if the Lots of bugfixes line in each release ANNOUNCE
file would link to a list like this one.
Proof there were lots of bugfixes...
A lot of code in WineD3D avoids the getters and setters, and just accesses
the
implementation structure. While any object oriented programmer screams when
doing that, we need it for performance reasons. Currently we spend 10 to 20
per cent of the CPU time spent in WineD3D just in
Any chance the formatting can be improved to include whitespace between
blocks and proper indentation?
+if (use_vs(stateblock-wineD3DDevice)
stateblock-wineD3DDevice-vs_selected_mode == SHADER_ARB)
GLSL specific logic should go in glsl_shader.c.
Please try to get away from writing code in terms of flags and if
statements - use the OOP model.
Backend-specific logic should be removed from
Stefan Dösinger wrote:
Am Donnerstag, 27. September 2007 02:57:01 schrieb Ivan Gyurdiev:
Aren't most of these 2.0 and 3.0 instructions ?
What's the goal of adding them to ARB - you won't be able to implement
full 2.0/3.0 support in ARB.
We can implement 2.0(but not 2.a/b). Whenever
Aren't most of these 2.0 and 3.0 instructions ?
What's the goal of adding them to ARB - you won't be able to implement
full 2.0/3.0 support in ARB.
I think most of these were left unimplemented on purpose.
Ivan
Stefan Dösinger wrote:
Up to now we've been lucky that all the games requireing manual fog coords
haven't used vertex buffers, thus we always went through drawStridedSlow.
Make sure that the fog also works with vertexbuffers
As for the rejected patches from yesterday, I've moved them back to
H. Verbeet wrote:
On 18/08/07, Roderick Colenbrander [EMAIL PROTECTED] wrote:
From what I have seen GL3 is very different. It would be like maintaining a
GTK and a QT backend in one library. They use very different calls
(glBegin/glEnable and so are gone), need different WGL contexts and so
Stefan Dösinger wrote:
There are other things too which could be moved, but I'm not sure if that
would make the code more readable. One big function which does things step by
step vs a few smaller functions which disturbs the readflow.
All of this code pasted 3 times could probably benefit
What Stefan says about discussing patches
is true--it helps if there's not a lot of debate around a patch.
This quote should go down in the history of open source :)
I hope the word you're looking for is controversy.
H. Verbeet wrote:
+for(i = 0; i 16 /* Max vertex attribs */; i++) {
I think you should be using MAX_ATTRIBS there.
Changing the strided data like that in drawPrimitive looks rather
hacky to me.
You cannot access the strided data by both named approach
(u.s.something) and
Stefan Dösinger wrote:
You're returning a size_t here, which does not match the
WINED3DERR_OUTOFVIDEOMEMORY returned on the HeapAlloc (granted, that's
probably incorrect behavior by d3d9, but at least the return types
should be consistent).
Does that mean we'll be removing the other two
Looks good, but this comment is misleading - s/second/first.
+/* The contents should correspond to the second conversion */
+VDECL_CHECK(compare_elements(result_decl1, test_elements1));
Also, I thought when Henri was testing this that the object kept changing
between sequential Get()
Fabian Bieler wrote:
Vertex shaders are marked as 'foggy shaders' in wined3d if they write out the
fog coord. Previously this was not done for vertex shaders 3.0. This patch
corrects this problem.
Please don't do that - the design is flawed enough as it is (GLSL being
invoked from
Here is how this was meant to work at some point [ since I see all kinds
of incorrect things being done ]:
Entry point Code generation
==
Pixelshader Baseshader --- ARB backend
Vertexshader ---
Stefan Dösinger wrote:
Honestly I do not really agree with getter methods like this inside WineD3D.
Yes, they do hide the implementation details, namely how the flag is stored.
Yes, they do encapsulate data, like the Object Oriented Programming model
says. But honestly, how much use is it to
From b1df18be85d1ca6a9904be05420f975f6933b030 Mon Sep 17 00:00:00 2001
From: Stefan Doesinger [EMAIL PROTECTED]
Date: Fri, 23 Mar 2007 19:03:58 +0100
Subject: [PATCH] WineD3D: Handle WINED3DSPSM_DZ and WINED3DSPSM_DW in texcrd in
arb shaders
Isn't there a function to handle modifiers?
Stefan Dösinger wrote:
Hi,
implementing GLSL checkbox, OffScreenRenderingMode dropdown menu and
VideoMemorySize textbox into winecfg would be easy.
GLSL is OK IMO, because some drivers(*cough* macos *cough*) have serious
problems with glsl. It could be included into the shader dropdown
Why should inline static be replaced with static inline.
Does it improve compatibility with certain compilers?
Also, does wine aim to be compliant with ANSI, C99, or somewhere in
between (-gnu89)?
Kevin Wallerbos wrote:
This formatting patch cleans up the spacing in the pixel/vertexshader
instruction table, making it somewhat nicer on the eyes. The lines
have become a bit longer than practical on standard resolutions, but
that shouldn't be a problem as most lines were already too long.
A
This time cube texture support is added. Hopefully the coords are right, I had
no test app for them. If not it should be easy to spot the very
characteristic flipping of the image.
I'm confused - you replaced a patch which had no support for cube maps,
with one that has untested support
Changelog:
- The texldl instruction takes 3 arguments
Can the SW shader handlers be deleted now that the rest of the SW code
is gone.
They just get out of sync when you do things like this.
Something's wrong with this patch: it has more 2 nested if statements.
I suggest early returns on negated condition, gotos, and subroutines to
fix the problem :)
I don't know if that patch wasn't applied because other patches of my patchset
weren't applied, or because something is wrong with
H. Verbeet wrote:
On 20/02/07, Stefan Dösinger [EMAIL PROTECTED] wrote:
If anyone knows a nicer way to release the converted declaration from
SetVertexDeclaration feel free to comment.
Not applying this patch won't affect patches 11-13
Wouldn't it be better to directly compare This against
The idea of this patch and the next few is to create an internal d3d8
object to hold the wined3d declaration and give the d3d8 vertex shader
a field to hold the d3d8 vertex declaration object. Setting the d3d8
vertex shader will then set both the wined3d shader and the wined3d
vertex
Stefan Dösinger wrote:
This call can be handled fully by IWineD3DSurface::Blt.
So where did the filter argument go.. there's 3 different filter types
to support.
Here's a demo that breaks FBOs: http://www.humus.ca/3D/Water.zip
Also download: http://www.humus.ca/3D/Framework2.zip
You'll notice all the glClear calls fail [ or at least a lot of them ].
That's because the framebuffer is incomplete at that point -
checkFBOstatus() should be called before
Stefan Dösinger wrote:
Am Samstag 06 Januar 2007 22:25 schrieb Ivan Gyurdiev:
Stefan Dösinger wrote:
Now that almost everything is gone from drawPrimitiveDrawStrided we don't
need a subfunction for calling drawStridedSlow/Fast any longer
I think while we're cleaning up things
Stefan Dösinger wrote:
Now that almost everything is gone from drawPrimitiveDrawStrided we don't need
a subfunction for calling drawStridedSlow/Fast any longer
I think while we're cleaning up things, all of software shaders should
be removed.
There's tons of code in drawprim and
Regarding the concern of storing the decoded strided data after
finishing drawing: This is intentional, the decoded vertex declaration
will remain valid after the draw is finished and the arrays loaded.
Future draws can use it, if the state is not dirtified again.
This sounds like a good
Jan Zerebecki wrote:
On Tue, Jan 02, 2007 at 07:00:20PM -0800, Dan Kegel wrote:
I'd like to change this to make it clear that cracks are a no-no for
anything Silver and above, and make Platinum and Gold rather
more rigorous:
I don't think that is helpful. What is more important:
to
Stefan Dösinger wrote:
I removed that call accidentally in one of my former patches, but I
think it is still a good idea to trace the final strided sources used
by drawprim
You removed it from a d3d8 fixed function FVF-only codepath, and are
adding it back into a shared codepath.
That
Louis. Lenders wrote:
Hi, is there anything wrong with this patch? If so, could you please
tell me what. Thx
*/Louis. Lenders [EMAIL PROTECTED]/* wrote:
Hi, this patch should fix failing tests in d3d9, like you see for
example here:
http://test.winehq.org/data/200612231000/
+if (stateblock-wineD3DDevice-vs_selected_mode != SHADER_NONE stateblock-vertexShader
+ ((IWineD3DVertexShaderImpl *)stateblock-vertexShader)-baseShader.function != NULL)
+memcpy(stateblock-wineD3DDevice-strided_streams,
stateblock-wineD3DDevice-up_strided,
H. Verbeet wrote:
On 20/12/06, H. Verbeet [EMAIL PROTECTED] wrote:
This time as part of the device.c test.
Changelog:
- Add a render target test
Use the attached patch instead, the previous version doesn't apply.
This test really belongs in stateblock.c, along with every other set
-- get
H. Verbeet wrote:
Changelog:
- Select the right shader backend when creating the device
Imho there should be either ps_selected/vs_selected flags, or
shader_backend flag, but definitely not both [ does not make sense ].
I'd opt for allowing different backends on pshader vs vshader. Maybe
H. Verbeet wrote:
There are a couple of instructions that have to sample from a texture,
right now most of them duplicate that code, and hardcode the texture
type.
Changelog:
- Create a separate function for sampling a texture
You should continue to use add_param or get_register_name. There
- Software shaders currently simply don't work. If we do get software
shaders it'll likely be vertex only.
So, we should allow hardware pixel shaders, and software vertex shaders.
I could see
someone using software vertex shaders if he's got no hardware support
for shaders, although it's
H. Verbeet wrote:
On 27/11/06, Ivan Gyurdiev [EMAIL PROTECTED] wrote:
H. Verbeet wrote:
There are a couple of instructions that have to sample from a texture,
right now most of them duplicate that code, and hardcode the texture
type.
Changelog:
- Create a separate function for sampling
- Mixing ARB and GLSL backends is pretty silly as well.
Why? I believe you can e.g. perfectly mix GLSL vertex programs together
with multitexturing setups.
ARB as in ARB_vertex_program or ARB_fragment_program, I'm not sure
what multitexturing has to do with it. You can't, for example,
This flag needs to be per adapter - should be added to device.c like the
shader mode.
H. Verbeet wrote:
Two things to note here:
- We use GL_DEPTH_COMPONENT24_ARB as internal format for 16-bit
depth textures. This is needed because GL_DEPTH_COMPONENT16_ARB
doesn't work with FBOs.
- We don't properly support combined depth and stencil buffer
formats yet. To support this properly
Ivan Gyurdiev wrote:
This flag needs to be per adapter - should be added to device.c like
the shader mode.
I meant the device structure.
Also, the mode selection should include configuration and support
detection - I think you're missing the support detection. Imho there
should
H. Verbeet wrote:
On 17/11/06, Ivan Gyurdiev [EMAIL PROTECTED] wrote:
This flag needs to be per adapter - should be added to device.c like the
shader mode.
Well, the registry setting is global. I'm not sure if it really makes
sense to use different offscreen rendering modes for different
H. Verbeet wrote:
On 17/11/06, Ivan Gyurdiev [EMAIL PROTECTED] wrote:
H. Verbeet wrote:
On 17/11/06, Ivan Gyurdiev [EMAIL PROTECTED] wrote:
This flag needs to be per adapter - should be added to device.c
like the
shader mode.
Well, the registry setting is global. I'm not sure
That's still missing runtime check for GL_ARB_DEPTH_TEXTURE extension. I
don't like developers only and registry key - feature should be
complete or not in the tree.
The trouble with the current setup is that we can't use different
formats based on what extensions
are present.
Then the
Mirek wrote:
Ok, i just found why is it not working with this patch, and why is it
working without this patch. It is based on position of definition MOVA
in vertexshader.c, if MOVA is on after patch position it is not
working, but if i move line
{WINED3DSIO_MOVA, mova, NULL, 1, 2,
Tom Wickline wrote:
I see the same thing as Mirek, 3dmark03 is totally broken now.
And yes I tested GLSL and ARB and before and after with the same
results as his.
So yes, this is a major regression :D
When testing with the GLSL backend, can you please do a +d3d_shader
trace, find the
Here is log with 3DMark running for about 3 seconds with patch and
without, trace+d3d.
http://www.czela.net/pub/Czela_Debian_2.5/mirek/wine/regression/3DMark03.tar.gz
There's no mova instruction in that log.
Ivan Gyurdiev wrote:
Here is log with 3DMark running for about 3 seconds with patch and
without, trace+d3d.
http://www.czela.net/pub/Czela_Debian_2.5/mirek/wine/regression/3DMark03.tar.gz
There's no mova instruction in that log.
...grep for mova, or for unrecognized or Unrecognized
The MOVA instruction is a 2.0 instruction, which cannot be fully
implemented in ARB.
However, the patch shouldn't have caused a regression - if you're seeing
a black screen with GLSL also, that means another patch is responsible
for this.
Mirek wrote:
I tried it three times with same result. Can someone else test if
3DMark 2003 is working with latest wine?
You shouldn't test if it's working now - test if it's working before the
MOVA patch, and if it's not working after the MOVA patch [ no other
patches in between ].
Can you describe what this would look like in detail
I haven't thought it through in detail - just making sure you have. I
think you're going in the right direction, as long as considering things
other than render states in the design - won't bother you anymore, until
I see some more of
Stefan Dösinger wrote:
Am Montag 23 Oktober 2006 00:57 schrieben Sie:
What does addDirtyState() do when called multiple times with the same
representative?
There is a stateblock-changed.somestate field in the stateblock, which is a
boolean right now. This can be made a pointer to the
I don't like how the number of things staying as they are right now is
growing, while the number of things being changed remains confined to
render states. To have a proof-of-concept state management system, it
would be best to take things that are as different as possible, and
manage to get
Jaap Stolk wrote:
On 10/22/06, Ivan Gyurdiev [EMAIL PROTECTED] wrote:
and we loose the ability to
set up a constant table in the code.
The constant table is usually a bad idea, and this demonstrates why -
I'm in favor of flexibility, but is it correct to assume that the
number of functions
n0dalus wrote:
On 10/22/06, Ivan Gyurdiev [EMAIL PROTECTED] wrote:
Constant is convenient, but if it can't meet all necessary requirements,
I wouldn't hesitate to drop the idea - never compromise on design in
favor of C optimizations. Tomorrow's hardware will make any
non-algorithmic
device-addDirtyState(This, States[State]-representative)
This way the code applying the states has to be called only once.
What does addDirtyState() do when called multiple times with the same
representative?
This is still a bunch of code, not a magic instruction how to call gl
Makes sense - reapplying the stateblock causes the states to be written
back to the same stateblock *and* GL state to be applied. What we want
is the states to be applied without being written back to the same
stateblock.
You can add if(capturing) write_to_update_stateblock(); else
States will be applied in drawprim. BltOverride and UnlockRect change states
on their own, and they can put the states the change onto the dirty list so
drawprim will reset them to what the application wants.
What about Clear()?
Maybe you should also provide the capability of applying a
States will be applied in drawprim.
It will be good if *all* texture-related states were applied in
drawprim, specifically. This is a prerequisite to VTF support, since
that involves repacking pixel and vertex textures into a single array,
and changing their indices [ should happen at
More?
What are your plans for dealing with these:
=
SetLight()
SetLightEnable()
SetTexture()
SetDepthStencilBuffer()
SetRenderTarget()
SetSomethingElseThatsNotARenderState().
Ivan Gyurdiev wrote:
Ivan Gyurdiev wrote:
Karsten Elfenbein wrote:
* don't prevent IUnknown_Release of pDecl in the exit section and fix
for http://bugs.winehq.org/show_bug.cgi?id=5656
This seems wrong, d3d9 does not keep an internal reference of the vdecl.
Try the attached patch instead
H. Verbeet wrote:
On 14/10/06, Ivan Gyurdiev [EMAIL PROTECTED] wrote:
Ivan Gyurdiev wrote:
Based on further tests, I don't believe this patch is correct.. but it
will fix the memory leak. I'm still unsure what kind of insanity the
native API is doing internally - in process of figuring
H. Verbeet wrote:
On 14/10/06, Ivan Gyurdiev [EMAIL PROTECTED] wrote:
Exactly... so why is the refcount 1 *after* GetVertexDeclaration.
Perhaps the declaration in only generated when calling
GetVertexDeclaration(). If you call it twice, does it return the same
pointer?
No.. I tried that too
Stefan Dösinger wrote:
Am Samstag 14 Oktober 2006 20:53 schrieb Ivan Gyurdiev:
H. Verbeet wrote:
On 14/10/06, Ivan Gyurdiev [EMAIL PROTECTED] wrote:
Exactly... so why is the refcount 1 *after* GetVertexDeclaration.
Perhaps the declaration in only generated when
Karsten Elfenbein wrote:
* don't prevent IUnknown_Release of pDecl in the exit section and fix
for http://bugs.winehq.org/show_bug.cgi?id=5656
This seems wrong, d3d9 does not keep an internal reference of the vdecl.
Try the attached patch instead, let me know if it works...
---
Ivan Gyurdiev wrote:
Karsten Elfenbein wrote:
* don't prevent IUnknown_Release of pDecl in the exit section and fix
for http://bugs.winehq.org/show_bug.cgi?id=5656
This seems wrong, d3d9 does not keep an internal reference of the vdecl.
Try the attached patch instead, let me know
Alexandre Julliard wrote:
Ivan Gyurdiev [EMAIL PROTECTED] writes:
It's already marked const in the parameters of the set and get
functions, which means it can't be modified there (arg 3):
+void (*set_handler) (IDirect3DDevice9* device, const struct
state_test* test, const void* data_in
Well, ok, I'm starting to see this your way now.
I'll make this change, because of two reasons:
1) I'll need some kind of data structure called test_context anyway,
whether or not those pointers are copied there. Future tests will
probably require the ability to store additional data during
Alexandre Julliard wrote:
Ivan Gyurdiev [EMAIL PROTECTED] writes:
wined3d_types.h would be for types equivalent to the d3d types -
essentially no maintainance, simply map one-to-one to
d3d. wined3d_private.h would be for shared structures that we come up
with. Also, wined3d_private.h
Alexandre Julliard wrote:
Ivan Gyurdiev [EMAIL PROTECTED] writes:
Note: A new file was started for this purpose: wined3d_types.h. This
is _not_ the same as the one in the wine include folder - that one
should be for types which appear in the interface of wined3d, and must
therefore
1 - 100 of 268 matches
Mail list logo
