-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi,
A few more comments, with one day delay:
+static float max_abs_diff_vec2(D3DXVECTOR2 *v1, D3DXVECTOR2 *v2) +{
- float diff_x = fabs(v1->x - v2->x);
- float diff_y = fabs(v1->y - v2->y);
- return fmax(diff_x, diff_y);
+}
fabs and fmax return doubles, probably use the float functions fabsf and fmaxf. gcc doesn't bother about the difference, but msvc generates a precision loss warning.
Duplicating the code for 16 and 32 bit indices looks a bit ugly. Maybe you can use inline functions to read and write values from the proper buffer? The other possibility, which the ddraw blitting code uses is to write a sort of template as a macro and then generate both versions, but I don't like that idea.
Wrt the D3DDECLTYPE epsilon, it may be more efficient to scale the epsilon and calculate the diff and comparison as UBYTEs rather than floats. You'll need the diff functions for the other types like *BYTE*, *SHORT* anyway. Also tests would be helpful here, especially how the epsilon is treated in normalized values like D3DCOLOR and UBYTE4N and how it is treated in non-normalized values like UBYTE4.
Wrt the usage/index fields, what happens when a combination that isn't supported by the fixed function pipeline is used, e.g. NORMAL3 or POSITION5? Those are valid in a vertex declaration and can be used with shaders.
In the test:
- int vertex_size_normal = sizeof(struct vertex_normal);
- int vertex_size_blendweight = sizeof(struct vertex_blendweight);
...
You could make those unsigned.
I'm not quite done reading the test yet, I'll send another mail if I find more.
Think about caching pointreps and adjacency? Am 24.07.2011 um 11:57 schrieb Michael Mc Donnell:
On Sun, Jul 24, 2011 at 12:18 AM, Stefan Dösinger stefandoesinger@gmx.at wrote:
I just started reading this, I'll write more once I am done. Just a quick question: What do you mean with "built in function" in the comment above color_to_vector?
I wanted to ask if there was a DirectX function or macro that can convert a D3DCOLOR, which is four bytes in the range 0-255, to four floats in the range 0-1 or a D3DXVECTOR4?
There's none I know of. I vaguely remember that there was a macro to construct D3DCOLORs, but that's not too helpful here.
Reading this again I think color_to_vector should probably accept a D3DCOLOR instead of "BYTE color[4]"?
Yes, it would be cleaner. Also keep UBYTE4N in mind, which is pretty much the same as D3DCOLOR for your purposes. It just has a different component ordering(bgra in D3DCOLOR vs rgba in UBYTE4N if I'm not mistaken) when you're using it for drawing. As far as I understand WeldVertices it doesn't compare two attributes of different types, bit if you do you have to watch out there.