It tests correctly on my build.<br><br>I understand a little heartburn with the flipping on load/save of pngs, but it's not arbitrary.<br>GL thinks of images (and other things) in the first quadrant, but most image formats are stored 4th quadrant, where 0,0 is the upper left corner. Honestly, I tend to think of images as laid out this way; but I think now it's pretty clean, there is one coordinate conversion on input and output and everything is right-side up and we are consistent with opengl convention.<br>

<br>-Scott<br><br><br><div class="gmail_quote">On Wed, Apr 8, 2009 at 1:22 PM, gabor papp <span dir="ltr"><<a href="mailto:gabor.lists@mndl.hu">gabor.lists@mndl.hu</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

<div class="im">> Hmm... could the difference be the order we're defining the quads? my<br>
</div>i was checking the default (build-plane). flipping in x is not a problem<br>
anymore, it was caused by (poly-convert-to-indexed). i'm more concerned<br>
that we flip in y during the png load and now in save. i think the<br>
reversed order is confusing if you do image processing and pixel operations.<br>
<div class="im"><br>
> What's your testcode look like now?<br>
</div>(clear)<br>
<br>
(show-axis 1)<br>
<br>
(texture (load-texture "textures/flower.png"))<br>
<br>
(define p (build-plane))<br>
<br>
(with-primitive p<br>
    (for ([i (in-range (pdata-size))])<br>
        (printf "~a: p: ~a t: ~a~n" i (pdata-ref "p" i) (pdata-ref "t" i))))<br>
<br>
<br>
best,<br>
<font color="#888888">gabor<br>
</font></blockquote></div><br>