-
Notifications
You must be signed in to change notification settings - Fork 246
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Wonky Coordinate grid #292
Comments
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). |
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. |
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. |
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. |
Would this be of any help?
|
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 text was updated successfully, but these errors were encountered: