faiface/pixel

Wonky Coordinate grid

cebarks opened this issue · 6 comments

Pixel implements it's coordinate grid different than most graphics rendering systems (infact even different from opengl itself.) This complicates any efforts to integrate custom tools and libraries with pixel and is a hindrance to anyone moving from different library/language/api.

The solution I've been thinking about here is to add a window flag with two values, OriginUpperLeft, OriginLowerLeft with the default being LowerLeft (for compatibility) and then conditioning on this flag through the code (and possibly shaders).
Thoughts?

If we're dead set on keeping future versions backwards compatible i think that's probably the best option, but i genuinely think this is worth a breaking change. Games made with old versions will continue to work with those versions, just not future ones. I just think it'll become more of an issue down the road if we just wait longer and longer. I've read a few reddit posts and blog posts about golang gamedev that recommend pixel but with the disclaimer that the coordinate grid system is borked compared to most (all?) other rendering systems.

Asday commented

Do keep in mind that could be a case of survivorship bias. People who don't have a problem with the co-ordinate system aren't going to complain about it.

If a breaking change can be avoided, it would be nice if it was.

A flag, and appropriate checks where it's needed is likely the proper solution. By itself, it's not a particular issue, more of an annoyance to get used to if you have used other systems.

The problem obviously lies more in integrating with other systems and methods that use a more typical upper left origin.

My concern is how many places this needs to be checked for, maybe there's a more fundamental location where the checks can be made to ensure it's not peppered throughout the entire codebase. Somehow in the initialization process strikes me as logical.

iu0v1 commented

Oh, this is a very necessary feature. Being able to change the point of upper/lower origin is the perfect solution.

I'm now switching to Pixel from another engine, and I have a lot of code that is theoretically engine-independent, and had to be ported as simple drop-in solution. But through a different coordinate origin it's necessary to correct most of the math or wrap it by ugly middleware-like code. Not the end of the world, but it would be great to be able to avoid such issue.