Originally posted by LordKronos:
[b] Yes, but two things. First of all, a simple bit shift is going to be faster than a lookup table. Second of all, Matt said he could think of 5 to 10 reasons (and I’m sure there are many reason he doesnt even realize). He posted one, and you are proposing a workaround for this issue. Then when he posts the next reason, are you going to find another workaround for that one, and then the next, etc.
You see, when you try to “hard code” a solution to one problem, by the time you are done, you often realize that you “hard coded” half the stuff, and the general solution would have actaully been simpler, easier to maintain, and sometimes even faster. I think this is one of those cases where once you get to the meat of the problem, you will find the general solution is all of the above (the general solution being to just have some restrictions on the textures).[/b]
Exactly. I would also note that it would NOT be cheap to use a reciprocal lookup ROM. On a GF2, you need 16 of them – 4 pixels, 2 textures, 2 texture coordinates. Each table must be big enough to handle [1024,2047] at minimum. If you start thinking about future generations of chips, this is not a scalable solution. All four numbers I mentioned (pixels, textures, texture coordinates, and table size) could grow in the future.
Graphics HW is all about cutting corners to make powerful rendering technology cheaper than it “should be”. That’s what separates it from the CPUs of the world – a more constrained problem domain, and therefore a more efficient solution.