Komplett normalisieren kann man vor dem Interpolieren nicht, das stimmt. Es ging hier ja auch nur darum, dass man negative Koordinaten loswird. Und das kann man schon machen, so wie ich es beschrieben habe. Du verschiebst damit quasi das komplette Dreieck in den Texturkoordinaten gerade so weit, dass kein Vertex mehr ins Negative ragt. Dann spart man sich das vermutlich teure x - floor(x) pro Pixel, weil man schon weiß, dass die Koordinaten nie negativ sein können.
Hm. Offensichtlich wird hier ja eine "getPixelclip(texture,tx,ty);" Funktion verwendet, die dann anscheinend positive Integer erwartet (sonst würde er/sie in den Zeilen darüber ja nicht runden). Ich finde es aber immer noch irgendwie abstrus, dass eine solche Funktion kein Problem mit Werten hat, die zur einen Seite aus dem validen Intervall ragen, aber Werte die zur anderen Seite herausragen kategorisch ablehnt. Insbesondere da beide Fälle mathematisch exakt gleich behandelt werden (da die floor-Funktion passend definiert ist).
Es wäre also eigentlich der richtige Ansatz, die entsprechende Funktion vernünftig zu implementieren, so dass man auf der Aufruferseite keine Sonderfälle mehr behandeln muss. Wenn sie aber aus einem anderen Framework stammt mag das ggf. nicht möglich sein. ist ja scheinbar eh eine eher edukative Aufgabe, die nicht auf Performance optimiert ist.