# HLSL trouble (PS)

This topic is 4814 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

Hi there, sorry to add another help demand to these boards... but I really can't solve this by myself. I've been playing around with HLSL recently, and I now have a nice start of a program that uses it, but I got stuck with this strange behaviour : Trying to distort a texture to produce some kind of wave effect, without using bumpmap, I tried a way of doing it with pixel shader, using some sin functions fed with the input texture coordinates and time (which the program specifies) to set the new, distorted texture coordinates which would sample the texture. I tested this under the handy DX Sample "EffectEdit.exe" and it worked. Those waves were not awesome, but at least that was moving (and it came out that this made me happy ^^) Back to my program, I pasted the few lines responsible of this little piece of a miracle to my own fx file, (which I was starting to love for its former benefits ;)) and... *drums rolling* ... and this was not moving at all. Despite some differences with a few names, I'm rather positive that the two HLSL codes are similar. In fact, I isolated the problem after some tries. The oddity, should I say. when using sin() function with time only... this moves again ! when using sin() function with one of the input parameters (texture coordinates included) well, this does what it is supposed to do. when using sin() function with an expression using time and one of the input parameters, or a temporary variable receiving the result of such an expression, it seems that the whole (uncompiled) HLSL line responsible of it has no effect during runtime. here are some parts of my HLSL code:
struct VSPLAINHEXA_OUTPUT
{
float4 Position : POSITION;
float4 Diffuse  : COLOR;
float2 TexCoord : TEXCOORD0;
float2 TexCoord1 : TEXCOORD1;
};

...

float4 PSCoast(VSPLAINHEXA_OUTPUT In) : COLOR
{
float4 Color;

Color = tex2D(s0, In.TexCoord);
float b = Color.b;

float2 CoordBis = In.TexCoord1;

// the following two lines have NO EFFECT. They work again when they use
// either "CoordBis.y" or "time" in the sin() function, but not both.
// Initializing a temporary variable to evaluate the expression before the
// call of sin() doesn't help
CoordBis.x = 0.5f + sin(CoordBis.x*500.0f+time*5.0f)/1000.0f + CoordBis.x;
CoordBis.y = 0.5f + sin(CoordBis.y*500.0f+time*5.0f)/1000.0f + CoordBis.y;
//

float4 ProcessedColor = tex2D(s1, CoordBis);

...
}

...

technique TCoast
{
pass PShiftedHexa
{

...
}
}

Please note that there is no compilation error, and that it DOES work with EffectEdit. using DirectX9 summer2004, compiling ps_2_0 Any idea ??? (Please excuse my english)

##### Share on other sites
Good morning mr. TiPiou,
How are you doing?

The Problem
Shader compiles/executes but no result with moving texture coordinates.

The Solution
There are a few scenarios your might want to check.
What is the result of your function, I know it works in Effect Edit, but effect edit fills in some test variables for you.

Check List
1) Are your matrices and texture coordinates correct.
2) Does your time equal to 0, does it change at all. The time you pass to the shader needs to be checked.
3) Try debugging the problem by just setting the texture coordinate to the time.

These might sound silly but it's a test into debugging this kind of problem.

I hope this helps buddy.
Take care.

##### Share on other sites

Unfortunately I did the tests you mentionned, those are what brought me here with that enigma :

1) Texture coordinates and matrix are ok (I can see the object, with texture ok when I comment out the code meant to distort)

2) Time is not equal to 0, and does varies as it is designed to, as I saw when setting it directly to the texture coordinate, time was working very well with that expression too :
CoordBis.x = 0.5f + sin(time)/100.0f + CoordBis.x;
which produces expected results.

3) This is not a problem of scale, either (i.e, the factor applied to sin() being too small for the eye to notice) as I checked many scales with no better luck.

4) All things seem to work well other than than, really. When running several test using time, or texture coordinates, or input color, alone ; or even sin() of them, they behave as expected. As soon as I try sin(time+CoordBis.x), or sin(time+In.Color.r) it has no effect.

Seems to me like it cannot compute the function with something too complex as input, it seems crazy. I mean, simple arithmetic would work (time + CoordBis.x works fine). and I'm pretty certain I have the same compilation flags as they use in EffectEdit... well :/ I really have no clue.

##### Share on other sites
maybe I have a start of a clue, afterall.

I just noticed a "tiny" over-discretised move during a test (like a one-pixel shift every 3.1415927 second... err... who said PI ? :p)

 would it be a precision problem ?

I'll check some more and I come back with more info :x

[Edited by - TiPiou on September 12, 2005 8:24:20 AM]

##### Share on other sites
Ok this was it. applying a modulo to the 'time' in the C code, to keep it beetween lower bounds (0 to 999.999, when it was over 300K when I got the problem), the shader (and especially those lines with sin() function) works properly.

That being said, whereas the problem seems solved for now, I still wonder why "sin(time)" had no precision problems and "sin(time + something)" got stuck into this strange behaviour. I'd be glad to hear from anyone who has an idea about that ;)

1. 1
Rutin
40
2. 2
3. 3
4. 4
5. 5

• 14
• 18
• 12
• 14
• 9
• ### Forum Statistics

• Total Topics
633360
• Total Posts
3011516
• ### Who's Online (See full list)

There are no registered users currently online

×