faiface / pixel

A hand-crafted 2D game library in Go
MIT License
4.43k stars 244 forks source link

Wonky Coordinate grid #292

Open cebarks opened 2 years ago

cebarks commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 2 years ago

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 commented 2 years ago

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 2 years ago

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 commented 6 months ago

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)