y-axis direction

[ast]

Hi all,

This is not a direct feature request but more of on inquiry. Does anyone else find it at least a little annoying that the y-axis of sfml points downwards and not upwards as in the common maths? I am aware that this has historical background going back to someone deciding the cathode ray beam should start drawing lines from the upper left corner of the tube.

Anyways, the current choice of the co-ordinates seems to pose all sorts of troubles with vector algebra and the fact that angle positive direction is counted in clockwise direction contrast to the more common counter-clockwise direction. To get things working I implemented transforms back and forth from these downward-y 'screen' co-ordinates to my own co-ordinate system, in which I chose to have the origin in bottom right corner and the y-axis pointing upwards. One caveat though is that the position vector must be transformed with different transformation than its derivatives like velocity, acceleration or force because the location of the origin affects only to the position vector.

While this is manageable, I seem to end up having quite a lot of transformations while interacting with sfml functions, which could be avoided if the co-ordinates of sfml has been chosen otherwise. The first question is, how do you others manage with your co-ordinates? And the second, would it be feasible to support the upward-pointing y-axis in sfml also?

This is about the only thing that sometimes bugs me with sfml, otherwise it pretty much does what I would expect it to.

Thanks,
ast

[shadowmouse]

It's usually fairly easy to manage if rendering and logic are separated. Admittedly it is getting slightly annoying at the moment because I'm having to do reasonably long equations to correct it as my project is using user-alterable zoom, position and ratio, but most of the problems like this can be solved with views and transforms. I don't see any reason why the feature would be impossible to implement (and I probably would if it was just up to me), but seeing as it is reasonably easy for the user to do it themselves, I doubt it would ever actually get fully approved.

EDIT: I forgot to say, but the main reason that it's annoying is the fact that I'm drawing graphs with upwards y, which means all the other things (position,rotation,scale) equations that I do become less readable and more prone to mistakes.

[Jesper Juhl]

Does anyone else find it at least a little annoying that the y-axis of sfml points downwards and not upwards as in the common maths?

No. Not really. That is pretty standard in computer graphics. Having it any other way would be "different from whatever everyone else do" and thus weird.
You get used to it quickly :-)

This may be useful/helpful - even if not directly related to your question: http://www.bromeon.ch/libraries/thor/v2.0/doc/group___vectors.html

[Nexus]

Anyways, the current choice of the co-ordinates seems to pose all sorts of troubles with vector algebra and the fact that angle positive direction is counted in clockwise direction contrast to the more common counter-clockwise direction.

Not really. The problem you describe is purely graphical and not mathematical. It's a simple thing you have to remember when looking at the screen, not something that inherently leaves traces in your code base. That's why pre-transforming every single coordinate is a really bad idea -- apart form the obvious fact that you're making your life more complicated, your code uglier and your (potentially future) co-developers angry

The first question is, how do you others manage with your co-ordinates?

I've developed plenty of games with SFML, and it hasn't ever been an issue, because the mathematics itself is consistent (at least from here on).

And the second, would it be feasible to support the upward-pointing y-axis in sfml also?

Use a view with a negative rectangle. Note that this is not an officially advertised feature, because thousands of users are fine with the coordinate system convention in graphics programming It works, but since it's not documented, you cannot rely on it to be future-proof -- strictly speaking at least.

The axis direction is really only a convention, not more. In my opinion, a game developer should be flexible enough to accept common practice and not forcefully stick to approaches common in other fields, especially when they complicate everything. Things won't get easier when you delve deeper (into OpenGL for example).

[Jesper Juhl]

It's just a flipped axis. Coping with that should be trivial (and pretty common).

[Laurent]

It's not "just a flipped axis". If you flip everything (using a transform, a view or whatever ends up flipping all coordinates) then you have a problem with all SFML drawable classes because everything refered as "top-left" is in now bottom-left. Sprites, texts and all shapes appear flipped, so you have to compensate for that (with negative scale or whatever). I may be wrong, and I've never tried to do it, but I think that inverting Y axis only for position coordinates (not for entire drawing) is not as trivial as it seems, and leads to inconsistencies in code.

[GraphicsWhale]

While I do find the negative thing a bit weird, it's not really that complicated to get around. In smaller projects, it should be pretty easy to just flip the Y axis around around whenever you get the joystick coordinates, and in larger projects, you really should have the controls abstracted away from the core game workings anyways thus making it completely a non-issue.

Changing SFML's behavior will likely lead to more problems created than fixed (you have to consider legacy code and people who were not informed about this theoretical fix, and this is assuming you consider this a fix in the first place).

It's not "just a flipped axis". If you flip everything (using a transform, a view or whatever ends up flipping all coordinates) then you have a problem with all SFML drawable classes because everything refered as "top-left" is in now bottom-left.

I don't think that's a problem. It's not like you have to flip everything, as the input shouldn't ever map 1:1 with the graphics. It should map to what makes sense for input code. And having positive denote upward is pretty typical.

[shadowmouse]

Changing SFML's behavior will likely lead to more problems created than fixed (you have to consider legacy code and people who were not informed about this theoretical fix, and this is assuming you consider this a fix in the first place).

I highly doubt the suggestion would have been to switch from only y downwards to y upwards, but rather

sf::Window::setYUp()

and

sf::Window::setYDown()

[Satus]

I got the same problem with my game, it is kinda annoying to have to translate y axis for every entity I'm drawing.

[ast]

Thanks for answers and good discussion!

My statement that the y-axis direction makes troubles to vector algebra is slighly incorrect -- the algebra does not care about y-axis pointing 'up' or 'down'. It is the interpretation of results of the calculation where it matters. In my case I do game physics, not terribly hard, but having enough forces and torques acting the equations tend to become large. My choice was to have the gravitation force to be 'negative' and to have the contact reaction forces being 'positive', where the negative and positive means the orientation of the force vector with respect to y-axis. So I wanted the physics being normal and chose to cope with the transformations when drawing on the screen. I still think this was the right decision.

I also had the idea that the transformations take place only when rendering to screen but that ended up being not entirely true. It would if the only interaction with the screen co-ordinates would be the drawing. But I sometimes query a screen object rotation angle e.g. to find out the direction where its surface normal points to, and while doing so it is important to remember the different direction of the positive angle. An another example is that in order to interact with Thor particle system particles I need to get their velocities and it is of course returned as a vector in screen co-ordinates. It is obvious that the velocity vector needs a different transformation than the position vector but only after first making a mistake there .

Also, the scaling of the length unit is another reason to have the different co-ordinates for calculation and rendering. Instead of defining acceleration as pixels/s² I opted for more common m/s², where one pixel is defined to correspond to a certain length measured in 'meters'. This results all physics in SI-units and it is much easier find good ballpark figures for various quantities because the real world can be used as a reference case.

So the total transformation is scaling, flipping the y-axis and translating the origin to bottom left corner. If the origin and the y-axis direction would have been in place already, only the scaling would have been needed.

The roots of the downward y-axis selection is very well understandable according to CG history and convention. And while this is manageable and only a slightly bugging sometimes, it would not harm if there would be a standard way of handling these to make it easier for newcomers and also easier to write at least a bit less cluttered code.

The ultimate solution would have been if the ancient greeks would have invented Commodore64 before maths so they could have had the downward-y set correctly in their maths too