On 27/11/06, Stefan Dösinger stefandoesinger@gmx.at wrote:
Am Montag 27 November 2006 13:04 schrieb H. Verbeet:
I had a very brief look at the code, pertially because a tarred up directory isn't the most convenient way to spot what has changed and what is still the same.
I can of course send you my 45 patches too, but they are pretty messy because I changed things regularily and committed stuff that shouldn't be committed / forgot to commit, ... For sending the things in I have to break them up in smaller patches.
Sure. I do understand the reasons, just noting that I probably didn't spot everything that has changed.
- Why are the state_* functions WINAPI?
Doh - everything is winapi, but this is changeable of course. Any pros/cons?
Just that they're not actually part of any public Windows API, and I see no particular reason to change the default calling convention.
I'm still a bit uncertain about having all states together in a single array. And I think a construction like: DWORD stage = (state - STATE_TEXTURESTAGE(0, 0)) / WINED3D_HIGHEST_TEXTURE_STATE; in tex_colorop is quite ugly.
Well, as I said the idea is to be able to group different kinds of states(e.g. LIGHTING and vertex declaration and vertex shaders). Well, that isn't as strong as I thought it would be at first, a lot of grouping is done in a more "soft" way. For example, misc_vdecl calls misc_streamsrc, and misc_streamsrc checks if STATE_VDECL is scheduled for updating before doing anything. The idea behind this is that the vertex declaration affects the resulting stream sources, but the stream sources don't affect the vdecl.
Beauty is in the eye of the beholder :-) At the end its up to AJ to decide what way to go. I personally think a single state array, and a single dirty list looks nicer :-)
Well, what I am a bit concerned about regarding AJ are the STATE_* macros in wined3d_private.h :-|
I'm not directly opposed to the current setup, it's more that I'm wondering if going for separate tables for related states would perhaps result in cleaner / more flexible code. It would of course allow you to get rid of those macros :-)