I'm just starting out on libGDX and as I've feared, this is how cameras work.(I know there is a stretching problem here, but that's besides the point.)

I'm sure everyone who's ever dealt with OpenGL can relate. Now, coming from the unicorns and rainbowsof Slick2D, I am confused as to how I use this to render my games. Ofcourse, after a quick google I realize I can just set the projection to whatever my window size is, but is that a viable solution?I can't help but think it was set up like this for a reason.

Will it have any impacts on the Android version?Actually, this is kind of a side question coming. How does one manage the screensize of the desktop version, and the one of the android version?Surely, they can't be the same.

How do you guys usually manage your model-objects in a scene, because working with an X, and Y coord for every sprite just doesn't work very well in this instance?

Speaking in generic terms, not apropos of libgdx: The default was set up the way it is because it's an identity transformation to normalized device coordinates. You're expected to change it, that's what you get a projection matrix for.

For a 2d game, it's pretty reasonable to use an orthographic projection with the origin at the upper left and Y increasing down, with a range matching your display resolution -- exactly what Slick2D does. Putting it at bottom-left is also common, and that's what libgdx does by default. Neither is objectively better than the other, you just have to be consistent is all.

For 3d games, you should probably stick with standard conventions, with your depth axis running through the center. Whether that axis is Z increasing inward (OpenGL default), Z increasing outward (Direct3D) or Y (IdTech, Unreal) is still up to you, though all the tutorial and sample literature out there for OpenGL assumes you're taking the OpenGL default (and of course D3D tutorials use the D3D standard). glFrustum and gluPerspective are of course going to assume the OpenGL arrangement of things.

SpriteBatch automatically set you pixlel perfect projection just use that.

But y up is lot better way to do it. Just thing about physics its just more intuitive.

Another point is that you propably don't want desing your game arounds pixels becouse you can know the screensize or aspect ratio. There are just too many variable screens at android scene. I have two aproach for this. If I am using box2d then I use physic world size as my camera size, this just works and I can plan everything as meters and I don't have ever think pixels. Another solution that I am using for UI's and huds is something like virtual pixel coordinates. I just hard code camera size 800x480 and use that even if the screen size differs.When you take aspect ratio account it just depends what you wanna keep static.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org