ok, replacing the line is not enough... this ?
int count = 0;
int j;
read2CPU();
for (int i = 0; i i)
{
count++;
}
j = size * 4;
}
}
j+=4;
}
}
printf("\n%i", count);
(sorry to post in anonymous for the second time but my account is not yet activated...
Alfith.
spot the mistake in this algorithm please! [SOLVED]
Quote:Original post by haegarr
How is the texture generated? The snippet says that the RGB values are floats and compares them using ==. Perhaps its a question of resolution? What happens if you use a "close to" instead of "is identical" or even better if you quantize the RGB values more coarsly?
hmmm... i'm not sure about this. if it was a rounding problem, surely it would consistanly overestimate the number of duplicates? at the moment is seems to constantly come out with either 496 or 406 (with a 32x32 texture)
anyway, i'm pretty certain there is something else going on - i changed the following line:
if (..... && pos[1] != -1.0f)
to:
if (..... && pos[1] > 0.0f)
and now it says 0 all the time!
emmanuel, yes you are right, the line
comparePos[1] = -1.0f;
should in fact be
endPos[j+1] = -1.0f;
comparePos[1] = -1.0f;
should in fact be
endPos[j+1] = -1.0f;
grrr !
my reply is completly messed up...
sorry for this... my account is not yet activated...
I hope this will of be of some help:
for each "i" element
{
.initialize "pos"
.j = 0;
.while j i
....{
.....count++;
....}
....j = size * 4;
...}
..}
..j+=4;
.}
}
Alfith.
my reply is completly messed up...
sorry for this... my account is not yet activated...
I hope this will of be of some help:
for each "i" element
{
.initialize "pos"
.j = 0;
.while j i
....{
.....count++;
....}
....j = size * 4;
...}
..}
..j+=4;
.}
}
Alfith.
infact, just to test, i set the floatEqual function to:
if (fabsf(a - b) < 100000.0f) return true;
and running on a 32*32 texture it says 3!
somedays i hate computers!
if (fabsf(a - b) < 100000.0f) return true;
and running on a 32*32 texture it says 3!
somedays i hate computers!
err.. not really cos it still doesnt work lol!
where i'm passing in "size", its a size*size texture but i was only looping over size (so only actually reading half the texture).
thats why when i set the floatEquals function to <1000.0f it didnt give the expected answer of 1023 (32*32 texture). i spotted that and thought that was the only mistake.
turns out i was a bit rash though, setting the floatEquals to <0.1f (which is pretty generous, its a 32 bit floating point texture!) still repeatedly gives out the same number. this number is far lower than it should be and it should gradually increase, its remains constant at the moment.
where i'm passing in "size", its a size*size texture but i was only looping over size (so only actually reading half the texture).
thats why when i set the floatEquals function to <1000.0f it didnt give the expected answer of 1023 (32*32 texture). i spotted that and thought that was the only mistake.
turns out i was a bit rash though, setting the floatEquals to <0.1f (which is pretty generous, its a 32 bit floating point texture!) still repeatedly gives out the same number. this number is far lower than it should be and it should gradually increase, its remains constant at the moment.
Maybe it's time for some debugging.
Can you perform a test on a very small part of the texture? Print out the values for each pixel and then print out when a match is found.
Then go through each pixel (the values you have printed) and search to see if it has been repeated and your algorithm has missed it.
Basically work out which ones aren't being matched up and then work out why. Hopefully once you havev two pixels that should match but don't it will be easier to find the bug.
Greig
Can you perform a test on a very small part of the texture? Print out the values for each pixel and then print out when a match is found.
Then go through each pixel (the values you have printed) and search to see if it has been repeated and your algorithm has missed it.
Basically work out which ones aren't being matched up and then work out why. Hopefully once you havev two pixels that should match but don't it will be easier to find the bug.
Greig
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement