Normalise movement for direction with 16:9 aspect

Question

should i move everything by the windows Normalised cords to make it so SE is bottom-right, or should i use (1,1) and move everything at or either (1+speedX,1+speedY)

d = (WindowOrigin*2).GetNormalise();
    v+=vec2f(0,-d.y);

or

d = (1,1).GetNormalise();
    v+=vec2f(0,-d.y);

reason i ask is because using the first one makes it feel like up and down move slower then left and right even though it takes same amount of time

i can post more code but i really dont think its gonna show anything useful the image shows both options i can use

You may want to decouple the world space coordinate system you use for processing your game simulation from the screen space coordinate system used for display. This makes it easier to guarantee consistent behaviour on any screen resolution or aspect ratio, without peppering adjustment constants throughout all your gameplay code. — DMGregory, Apr 22 '23 at 11:54
I tried to understand it, when you say 0 to screen extent range do you mean between 0 and 1? — Domonicx, Apr 26 '23 at 16:50
You can see that example is measured in pixels, so for eg. a 1920 by 1080 screen, on-screen pixel coordinates would be in the range $x \in [0, 1920), y \in [0, 1080)$, and the screen center vector would be $(960, 540)$. You don't need to use that math exactly - the idea is just to use one coordinate system for your gameplay, and map the visible sprites or other rendered content to a distinct coordinate system for display. Then you can change display behaviour any way you want, without needing to revisit or re-tune all your gameplay code. — DMGregory, Apr 26 '23 at 17:04

Normalise movement for direction with 16:9 aspect

0 Answers0