Hello,
I've addressed most of the concerns, but would like to get some
clarifications before I continue with the rest.
On Mon, Aug 22, 2016 at 12:44 PM, Matteo Bruni <matteo.mystral(a)gmail.com> wrote:
It would be better to use explicit float constants
when assigning to
float variables (e.g. D3DMATERIAL).
Do you mean that numeric constants are to never
be implicitly
converted? Or only integral->floating-point? Or maybe only
double->float?
More specific comments: I'd split this over multiple patches. You can
probably make an initial patch adding the program with no real
functionality, then multiple patches adding the various graphical API
demos. In that regard, the d3d8 / d3d9 "merged" handling via macros
seems a bit obfuscating to me. Just replicating the code twice seems
cleaner. Maybe you can create a few helper functions for the common
code.
I've tried looking into splitting D3D code, but from the experience of
fixing some issues like CamelCase->snake_case and similar it seems the
split would be counter-productive for future changes. What I mean: the
D3D 8 and 9 (as used in this code) only differ by interface version
suffix and added/removed parameters in some methods (the parameters
removed are zero here anyway, since the demos ideally should give
identical results with different APIs), plus a few names changed. It
seems to me that any change in functionality would require one to edit
both D3D8 and D3D9 code in a _very_ similar way, and the differences
between the split codes wouldn't be easy to understand: diff would
give lots of unrelated differences, while substantial ones could be
missed (resulting in subtly non-identical results). While this is
inevitable between D3D and WGL, it's easily avoidable for such similar
(in such basic use) APIs as D3D8 and D3D9.
Do you still think the code should really be split?
Regards,
Ruslan