Henri Verbeet wrote:
>
> That basically comes down to testing for "fvf & (D3DFVF_RESERVED0 |
> D3DFVF_RESERVED2)". In fact, that would also explain the results for
> D3DFVF_XYZW, and make the explicit check for that redundant.
>
Thank you so much for your helpful feedback.
So I take it someth
Henri Verbeet wrote:
>
> That's insane. Any FVF validation should be done before starting the
> conversion, not afterwards by calling D3DXFVFFromDeclarator().
>
Thank you Henri for your wonderful feedback.
I was wondering if you had any particular suggestions as to the strategy for
verificati
Henri Verbeet wrote:
>
> On 15 September 2010 01:55, Misha Koshelev wrote:
>> +while (count < MAX_FVF_DECL_SIZE && (count == 0 ||
>> declaration[count-1].Stream != 0xFF))
>> +{
>> +count++;
>> +}
> ...and similarly you'd want to use D3DXGetDeclLength() here, though I
> wonde
My apologies if my first patch was unclear.
Here is a slightly modified git diff
http://wine.1045685.n5.nabble.com/file/n2806011/patch patch
along with the relevant make test output
http://wine.1045685.n5.nabble.com/file/n2806011/maketestoutput
maketestoutput
The relevant part of the make tes
Sorry for reposting - apparently my original nabble link did not work :(
---
Dear All:
Sorry to bother... I am working on a D3DXCreateMesh/ID3DXMesh patch, and I
encountered a very strange error.
Specifically, it seems that when passing a LPD3DVERTEXELEMENT9 * parameter
to D3DXCreateMesh,
a)
Dear All:
Sorry to bother... I am working on a D3DXCreateMesh/ID3DXMesh patch, and I
encountered a very strange error.
Specifically, it seems that when passing a LPD3DVERTEXELEMENT9 * parameter
to D3DXCreateMesh,
a) in Windows - one can create
static const D3DVERTEXELEMENT9 decl1[3] = {
Henri Verbeet wrote:
>
> On 1 September 2010 02:40, Misha Koshelev wrote:
>> +while (texture <= 8)
> What is the "texture == 8" case for? Also, it seems to me FVFs require
> texcoords to be assigned to consecutive texture units.
>
>
>
>
Thx. Fixed. What do you think of? Two version:
V
Henri Verbeet wrote:
>
> On 31 August 2010 18:16, Misha Koshelev wrote:
>>> Well yes, but I'd say that ordering should apply to *any* FVF element,
>>> not just colors and normals. E.g., point size before position or
>>> texture before color should be just as untranslatable.
>> Thank you. I was
Henri Verbeet wrote:
>
> On 30 August 2010 23:07, Misha Koshelev wrote:
>> Looking forward to (constructive) comments.
>>
> Why are colors and normals special? What use is hasPosition? What
> happens when the source declaration has e.g. two color elements with
> usage index 0, or two position e
Henri Verbeet wrote:
>
> On 24 August 2010 05:05, Misha Koshelev wrote:
>> +elements[idx].Stream = 0xFF;
>> +elements[idx].Offset = D3DXGetDeclVertexSize(elements, 0);
>> +elements[idx].Stream = 0;
> That's ugly.
>
>> +memcpy(Declaration, elements, size * sizeof(D3D
Stefan Dösinger wrote:
>
> Hi,
> The tests look OK. Since a part of the code was taken from
> dlls/d3d9/tests/vertexdeclaration.c(which is OK) you should copy the
> copyright lines along as well.
>
Thanks, how about this guy? I have added the copyright notices.
http://wine.1045685.n5.nabble.co
cripts that I use for Wine development
here:
http://groups.google.com/group/misha680-wine/files
I don't know how useful they will be to anyone else, but if anything, it
provides an nice backup for my computer.
--
View this message in context:
http://wine.1045685.n5.nabble.com/Request-for-com
12 matches
Mail list logo
