Skip to content
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

Open
cebarks opened this issue Sep 1, 2021 · 6 comments
Open

Wonky Coordinate grid #292

cebarks opened this issue Sep 1, 2021 · 6 comments

Comments

@cebarks
Copy link
Collaborator

cebarks commented Sep 1, 2021

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.

@dusk125
Copy link
Collaborator

dusk125 commented Sep 1, 2021

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?

@cebarks
Copy link
Collaborator Author

cebarks commented Sep 14, 2021

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
Copy link

Asday commented Sep 15, 2021

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.

@Qwarkster
Copy link

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
Copy link

iu0v1 commented Jan 21, 2022

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.

@arseniew
Copy link

Would this be of any help?

	matrix := pixel.
		IM.
		ScaledXY(pixel.ZV, pixel.V(1, -1)).
		Moved(pixel.V(0, win.Bounds().H()))
	win.SetMatrix(matrix)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants