Sorry about the delay in replying but I totally forgot about this thread! I wish people would hassle me more! :x

Anyway, I'm not sure if you quite caught my meaning the last time.

The final displaying-to-screen (flipping, or whatever method you use) doesn't matter: it can be seen as a generic "show it to the user" method that's the equivalent of a black box. We don't need to touch that part at all.

No, what I was suggesting is that _when composing each frame_, you work with translated coordinates. So, for example, if you had something like the following in pseudo-code, given a max screen height of 480 pixels:

(move to 10, 10)
(draw line to 100, 100)
(draw line to 100, 300)
(draw line to 10, 300)
(draw line to 10, 10)
(draw image at 400, 200)

...then you'd translate the y coordinates of each:

(move to 10, [479 - 10])
(draw line to 100, [479 - 100])
(draw line to 100, [479 - 300])
(draw line to 10, [479 - 300])
(draw line to 10, [479 - 10])
(draw image to 400, [479 - 200 - image.height])

Basically, you generate the frame using your own coordinate system by changing each y value. You can then flip/blit/draw/get it to the screen somehow without worry.

You may not want to subtract the image's height when drawing an image -- dunno since I've not tested the above theory out in code.

Another alternative would be to do everything upside down, including image data, then do the final draw-to-screen flipped upside-down, but that's a pretty obscene option (and I've not thought through that option, to be honest).

EDIT: just for clarification, do your _calculations_ in your "y axis is up" way, but translate the _drawing_ when showing the results. Make sense now?