• entries
422
1540
• views
488692

# Untitled

89 views

So, related to my previous journal entry I'm still debugging.

The basic synopsis is that a CPU-generated lookup table is giving different results to a 'pure' HLSL/GPU arithmetic equivalent.

After debugging various terms it seems that my hypothesis about the trigonometric functions differing is complete rubbish. My attempt at a GP-GPU style comparison in said previous journal also confirmed this.

To be honest, this is an extremely good thing as it'd be madness if they differed. Instead it just proves my own stupidity/madness for taking it as a valid hypothesis [embarrass].

After an hour or so of printf() style debugging I think I've boiled it down to texture addressing as the issue. The two paths differ in results partly because the look-up path is looking for results in a different (and wrong) location [rolleyes].

Turns out I was correct, and it was the following lines of code to blame:

for( UINT x = 0; x < LOOKUP_DIMENSION; ++x )	{		for( UINT y = 0; y < LOOKUP_DIMENSION; ++y )		{			// This following fragment is a direct conversion of			// the code that appears in the HLSL shader			float VdotN = static_cast< float >( x ) 						/ static_cast< float >( LOOKUP_DIMENSION );			float LdotN = static_cast< float >( y ) 						/ static_cast< float >( LOOKUP_DIMENSION );
Spot the problem? Bonus points and cookies to the first person to comment on this entry with the correct answer [wink]

Anyway, I still haven't solved this despite a couple of hours of printf() style debugging and its really starting to annoy me. I'm going to get some sleep and get back to this in the morning.

On the plus side - I generated an error within D3D10 earlier who's debug info revealed D3D10_1, which is new. Guess my install of Vista SP1 did in fact work...

Random guess: Off by one error? (Values will never quite equal 1.0f).

Failing that I dunno... something's the wrong way round?

[EDIT: Wait though. They're both in the inner loop, but why? You're setting VdotN to the same value a number of times.

Not sure that would produce an error though? You're still going down columns in turn, I think (if that's what's meant to happen.]

[EDIT2: Are you calculating texture coords? but setting VdotN and LdotN directly without looking the values up from your texture? Perhaps I have the wrong idea about what you're trying to do though.]

Ok, that's enough random guesses. I'll shut up now.

I don't know ? At first glance, I'd say you should divide by (LOOKUP_DIMENSION-1) rather than LOOKUP_DIMENSION ? The loop is using "lower" and not "lower or equal"..

Y.

Missing the ending brackets?? :D

(j/k) :P

also I don't see the point in always assigning those values to the same variables VdotN and LdotN. I hope there's some code after that.

Quote:
 Missing the ending brackets?? :D
[rolleyes] very clever! Yes, there is quite a lot of code after that and yes, there are even closing brackets [razz]

Quote:
 At first glance, I'd say you should divide by (LOOKUP_DIMENSION-1)
You win [grin]

Quote:
 Not sure that would produce an error though?
Good effort sprite_hound! There isn't an error as in the program crashes, just a visual error.

More details later in the week, but it does appear to be all down to texture coordinates and mapping... The correct value does exist in the texture, but its in a different location to the one that the PS is looking for it [headshake]

Cheers,
Jack

## Create an account

Register a new account