Why do 2D game engines keep using negative y for up? How do we keep accepting that it makes sense to represent "lowness" instead of height?
It's fine in a framework like love2d without hierarchical transform or camera systems where position is passed directly to the raw graphics API, but why don't we all choose a default world transform system that's intuitive? (Glares at Godot, but that ship sailed.)
Are the bugs and confusion worth the cost of changing the default camera rotation?
[#]gamedev
=> More informations about this toot | More toots from idbrii@mastodon.gamedev.place
@idbrii Isn't it because (0, 0) is chosen for upper left of the screen? If you put it on the bottom of the screen wouldn't it complicate where you position sprites and maps?
=> More informations about this toot | More toots from cjsaylor@techhub.social
@cjsaylor @idbrii everything would have to be transformed before being drawn as the actual framebuffer in memory is laid out top->bottom left->right, which doesn't normally need to happen in a pure 2d engine. (It would also be a lot slower) Changing it would complicate everything, not to mention that this has been the standard for so long you'd literally confuse everyone with it.
=> More informations about this toot | More toots from raptor85@mastodon.gamedev.place
@raptor85 @cjsaylor
That's a complication in rendering that leads to a simplification in game code and I think it's good for the industry to occasionally reconsider the balance. Same with scripting languages -- for a long time the perf cost was too high, but the productivity and iteration benefit now often carries it's weight.
Physics is taught +y up. Math with 0,0 in bottom left or centre. Only the establishment would be confused. And we adapt. But there are so many yet to become gamedevs.
=> More informations about this toot | More toots from idbrii@mastodon.gamedev.place
@raptor85 @cjsaylor
Our engine uses +y up in 3D and +y up in UI. Don't have to flip input to implement a radial menu and raw values in logs make sense!
I regret that we didn't use xy for the core gameplay plane (the ground) since that would make it more intuitive to think in 2D and simplify gameplay math. We have get_xz(), but it's still friction. These are the kinds of status quo assumptions that when not examined critically early are very hard to change -- just like -y up.
=> More informations about this toot | More toots from idbrii@mastodon.gamedev.place
@raptor85 @cjsaylor
"That's the way it was always done" isn't a good enough reason. We used to aim with the keyboard by default and hold a key to mouselook; allocate all memory up front with strict budgets; and write everything in native code. We can change -- even if it's hard. And there's lots of new developers who've yet to internalize that down is up and up is down.
=> More informations about this toot | More toots from idbrii@mastodon.gamedev.place
@idbrii @cjsaylor it's not just "the way it's always done", it's how graphics hardware works. A framebuffered screen is just a big 2d array in the end, same as textures. Sure, you can apply a transform to make the it appear like something else, that's what engines do, but unless you roll out new monitors and video cards for everyone internally the engine will have to use those coordinates to actually draw to the screen. There's no reason the games coord system needs to match graphical either.
=> More informations about this toot | More toots from raptor85@mastodon.gamedev.place
@raptor85 @cjsaylor
"you can apply a transform to make the it appear like something else, that's what engines do"
Yeah, that's exactly what I mean. We should do that more by default.
I think you could make a game in Godot with+y up (rotate your camera, change floor direction, etc), but you'd be fighting against the ecosystem if you wanted to use addons. Defaults are important.
=> More informations about this toot | More toots from idbrii@mastodon.gamedev.place This content has been proxied by September (3851b).Proxy Information
text/gemini