Strange problem with ternary operators in HLSL
category: code [glöplog]
Well, i ran into this strange behaviour, using DirectX11:
This will always use the false-condition ( : )
while "s" is always a static 1, so can´t be changed.
The same sort of code works on 11 other occurences in the same shader-code!
And "s" is really 1, as this code works as intended:
Of course this sucks, as i would have to change the code to the if/else if/else if/etc. - version now, while i have it, as already mentioned, working with ternary conditions on 11 other places in my code.
Crinkler wouldn´t crunch it away as good, also more asciis, so more bytes in the unpacked version for sure and i think also after crunching! :(
I tried several strange things already to get it working, like putting brackets aswell as an extra float3() around the normalize() ...of course nothing worked!
So, anyone else having had this problem already or can describe to me what is going wrong here or has a fix for this ready?
PS: The Pouet-Thread-Preview had some strange whitespaces, must be the BB-code for code /code having problems! ;) It´s not in my code and also not here where i am typing all this in right now! ;)
This will always use the false-condition ( : )
Code:
"float3 n="
"s<2"
"?normalize(float3(M1(p+float3(ee,0.,0.)),M1(p+float3(0.,ee,0.)),M1(p+float3(0.,0.,ee)))-M1(p))"
":normalize(float3(M2(p+float3(ee,0.,0.)),M2(p+float3(0.,ee,0.)),M2(p+float3(0.,0.,ee)))-M2(p));"
while "s" is always a static 1, so can´t be changed.
The same sort of code works on 11 other occurences in the same shader-code!
And "s" is really 1, as this code works as intended:
Code:
"float3 n;"
"if(s<2)"
"n=normalize(float3(M1(p+float3(ee,0.,0.)),M1(p+float3(0.,ee,0.)),M1(p+float3(0.,0.,ee)))-M1(p));"
"else "
"n=normalize(float3(M2(p+float3(ee,0.,0.)),M2(p+float3(0.,ee,0.)),M2(p+float3(0.,0.,ee)))-M2(p));"
Of course this sucks, as i would have to change the code to the if/else if/else if/etc. - version now, while i have it, as already mentioned, working with ternary conditions on 11 other places in my code.
Crinkler wouldn´t crunch it away as good, also more asciis, so more bytes in the unpacked version for sure and i think also after crunching! :(
I tried several strange things already to get it working, like putting brackets aswell as an extra float3() around the normalize() ...of course nothing worked!
So, anyone else having had this problem already or can describe to me what is going wrong here or has a fix for this ready?
PS: The Pouet-Thread-Preview had some strange whitespaces, must be the BB-code for code /code having problems! ;) It´s not in my code and also not here where i am typing all this in right now! ;)
Is really the operator precedence between the ternary operator and comma like that? Sounds strange.
did you try parenthesis combinations? n=(s<2)?(a,b):(c,d)
xTr1m: Yes, i think so! To quote myself:
By now i added "if/else if"-conditions everywhere instead of ternarys...and guess what:
The "if/else if" for the normals (which previously worked as intended) now crashes the entire intro as soon as it should start!
It is getting really painful by now! ;)
I wonder if it´s just too many conditions for one shader and i am just hitting the limit when the code reaches the normal-calculations. Strangely there are working ternarys way more down in the code, so getting reached only ever after the normal-calcs. So if it´s really about too many conditions this is still odd!
Maybe just too many Function-calls inside the conditions? I am quite lost here it seems! :/ Time to have a deeper look into the compiled binarys i guess! Oh, the pain! Should have sticked with DirectX9! ;)
Quote:
I tried several strange things already to get it working, like putting brackets aswell as an extra float3() around the normalize() ...of course nothing worked!
By now i added "if/else if"-conditions everywhere instead of ternarys...and guess what:
The "if/else if" for the normals (which previously worked as intended) now crashes the entire intro as soon as it should start!
It is getting really painful by now! ;)
I wonder if it´s just too many conditions for one shader and i am just hitting the limit when the code reaches the normal-calculations. Strangely there are working ternarys way more down in the code, so getting reached only ever after the normal-calcs. So if it´s really about too many conditions this is still odd!
Maybe just too many Function-calls inside the conditions? I am quite lost here it seems! :/ Time to have a deeper look into the compiled binarys i guess! Oh, the pain! Should have sticked with DirectX9! ;)
NEVERMIND!
I realized i couldn´t do more than 3 normal-calculations this way...it always crashed when i tried to use more!
I removed all other conditions and checked if i could do more, no cigar!
So my wild guess is i was right about too many function-calls inside the conditional branches.
But just when i was about to implement good old Macros and going back to using one shader per Part as i was used to in DirectX9 i thought i should give branching inside the Distance-Estimation-Function a Try! And what shall i say...it worked without any performance-loss, YAY! :D
So i am using my ternary-branches everywhere now, except for calculating the normals and deciding which DistanceEstimation to call...as i don´t need to do so anymore, as there´s only one DE-Function left anyway! :)
P.S.: seems the ternary-solution is 50 bytes bigger for 9 parts (which are just the same code right now for each; just for testing-purposes; still under but close to 4096bytes), so i think i´ll use the "if/else if" in the end...but i have to recheck once i put different code per part obviously! Good thing is i put Preprocessor-stuff allover, so i only need to (un)comment a DEFINE to compare the two solutions!
Anyways, please shut this Thread down, everything is said and i don´t see someone posting useful stuff in here in the future! ;) (Maybe this Thread helps someone in the future as is, though!)
I realized i couldn´t do more than 3 normal-calculations this way...it always crashed when i tried to use more!
I removed all other conditions and checked if i could do more, no cigar!
So my wild guess is i was right about too many function-calls inside the conditional branches.
But just when i was about to implement good old Macros and going back to using one shader per Part as i was used to in DirectX9 i thought i should give branching inside the Distance-Estimation-Function a Try! And what shall i say...it worked without any performance-loss, YAY! :D
So i am using my ternary-branches everywhere now, except for calculating the normals and deciding which DistanceEstimation to call...as i don´t need to do so anymore, as there´s only one DE-Function left anyway! :)
P.S.: seems the ternary-solution is 50 bytes bigger for 9 parts (which are just the same code right now for each; just for testing-purposes; still under but close to 4096bytes), so i think i´ll use the "if/else if" in the end...but i have to recheck once i put different code per part obviously! Good thing is i put Preprocessor-stuff allover, so i only need to (un)comment a DEFINE to compare the two solutions!
Anyways, please shut this Thread down, everything is said and i don´t see someone posting useful stuff in here in the future! ;) (Maybe this Thread helps someone in the future as is, though!)
I guess this thread is half-full with untruths, and the other half is probably pure speculation.