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 wa
> 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 pshad
> 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 cons
> 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.Caps&D3DPS20CAPS_PREDICATION))
> +{
> +return "vs_2_a";
> +}
Please re-che
> Unfortunately we can't make it a different function in the shader
instruction table because the difference between MOV and ARL is decided
with the dest register.
Sure you can, it seems that this MOV/MOVA specific stuff all belongs in
vshader_hw_mov (both sides of the MOV if statement can be
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 origi
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.
>
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_pipel
> 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 poi
> Zachary Goldberg wrote:
... but did not spell check :)
Granted, the movie quote is pretty funny, even if isn't spelled right.
Ivan
Stefan Dösinger wrote:
> Oops, forgot to attach the archive
>
I like it, especially these parts:
- Interface decoupling - Moves FFP replacement code to using the FFP
state table interface, instead of touching the unrelated shader interface
- Code separation - Code unrelated to shaders is moved
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
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 applicat
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
> 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 b
> "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 rele
> 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 mo
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 m
> 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, refcountin
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
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
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 c
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 s
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 ho
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
> 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 sur
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 remove
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.
>&
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 t
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 ind
> 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 ve
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 do
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 ---
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 vertexshad
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(
Vit Hrachovy wrote:
Hi,
according to thread 'WineCfg and DirectX options' at wine-devel,
That thread was heading in the wrong direction...
I'm
proposing a patch for winecfg to allow enabling/disabling usage of GLSL
for Direct3D applications rendering.
Do you want to make it easy to configure
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?
"ge
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 box.
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)?
Stefan Dösinger wrote:
Am Samstag 10 März 2007 19:39 schrieb Ivan Gyurdiev:
Opinions? Suggestions?
Sounds too easy...if it included something like "HLSL compiler", that
would be another story.
Also, you have to have a well-defined project to set completion criteria.
&qu
Opinions? Suggestions?
Sounds too easy...if it included something like "HLSL compiler", that
would be another story.
Also, you have to have a well-defined project to set completion criteria.
"starting the infrastructure" does not define when the project is complete.
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 for
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 b
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 t
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 declaratio
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 gl
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
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 *shader.c
Stefan Dösinger wrote:
Now that the decoded vertex declaration is put into the device with
baseVertexIndex = 0, vertex buffers can just memcpy it instead of decoding it
Here's an issue I see - isn't introduced by your patch, but I am just
confused.
In the vertex buffer code:
if(device->
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 functio
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 kn
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 id
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,
s
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
<--> g
> - 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,
proper
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
- 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 ques
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
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 the
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
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 regi
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 fo
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:
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
This flag needs to be per adapter - should be added to device.c like the
shader mode.
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, vshader_
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" o
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.
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 MOVA
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 ].
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.
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 th
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 t
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. field in the stateblock, which is a
boolean right now. This can be made a pointer to the list elem
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
directl
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 mak
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 t
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 -
the texture format table is another one where somehow we've been able to
get away with staying constant, but I am sure issues will show up in the
future invol
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
apply_sta
More?
What are your plans for dealing with these:
=
SetLight()
SetLightEnable()
SetTexture()
SetDepthStencilBuffer()
SetRenderTarget()
SetSomethingElseThatsNotARenderState().
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 drawpri
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 single
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 generate
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 th
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 proce
1 - 100 of 281 matches
Mail list logo
