2017-08-31 20:35 GMT+02:00 Paul Gofman gofmanp@gmail.com:
On 08/31/2017 09:25 PM, Matteo Bruni wrote:
2017-08-31 19:40 GMT+02:00 Paul Gofman gofmanp@gmail.com:
- ok(!memcmp(byte_code,
&test_effect_unsupported_shader_blob[TEST_EFFECT_UNSUPPORTED_SHADER_VSHADER_POS],
byte_code_size), "Incorrect shader selected.\n");I was confused by this at first, I thought somehow the unsupported vs_3_sw shader was set. That's not the case, TEST_EFFECT_UNSUPPORTED_SHADER_VSHADER_POS is the position of the vs_3_0 shader, but the naming throw me off. Can you rename those defines to "BYTECODE_VS_3_0_POS" or something that makes it clear that it refers to the hardware shader in vs_arr[0]?
Yes, sure, I will rename that. I just spotted I have the bytecode with 0x0300 version for unsupported shader (not 0x03ff as it should be for vs_3_sw as in effect source in #if 0), sorry for that. I tested both ways, the result is the same (either way it is not supported with hardware vertex processing), but apparently I kept wrong source for effect. I will recompile the code to match vs_3_sw (for easier spotting that shader in the blob).
Ah, good to know. Actually I was about to test whether vs_3_sw really made no difference in the generated bytecode. Your d3d9 tests made it clear that the version (sw vs hw) doesn't really matter so this d3dx9 behavior isn't quite as surprising.