Hi !
Featured games (85)
games approved by the League of Dukes
Games in Showcase (636)
Games in Android Showcase (178)
games submitted by our members
Games in WIP (686)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  Is it necessary to use the default projection mode?  (Read 2746 times)
0 Members and 1 Guest are viewing this topic.
Offline Mads

JGO Ninja

Medals: 26
Projects: 3
Exp: 6 years

One for all!

« Posted 2012-04-11 22:49:22 »

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 rainbows
of 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?

Thanks  Smiley

Offline davedes
« Reply #1 - Posted 2012-04-11 23:00:25 »

For 2D games, you'll probably want to use the OrthographicCamera:

More info:

Offline sproingie

JGO Kernel

Medals: 202

« Reply #2 - Posted 2012-04-11 23:11:33 »

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.

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Mads

JGO Ninja

Medals: 26
Projects: 3
Exp: 6 years

One for all!

« Reply #3 - Posted 2012-04-12 00:22:11 »

Thanks for the swift replies guys! I've decided to set it up like in Slick, however I am struggling to find this call
glOrtho (0, XSize, YSize, 0, 0, 1);
in the camera class, or the Ortho class.
Is anyone familiar with how this works?

I am familiar with syncing my camera with my SpriteBatch.

Offline sproingie

JGO Kernel

Medals: 202

« Reply #4 - Posted 2012-04-12 00:52:09 »

Gdx.gl10.glOrthof I believe.  Shouldn't need it if you're using OrthoCamera, which is more portable to boot (GLES2 has no concept of glOrtho)

Offline pitbuller
« Reply #5 - Posted 2012-04-12 07:07:46 »

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.
Pages: [1]
  ignore  |  Print  
You cannot reply to this message, because it is very, very old.

Dwinin (69 views)
2015-11-07 13:29:08

Rems19 (78 views)
2015-10-31 01:36:56

Rems19 (71 views)
2015-10-31 01:32:37

williamwoles (105 views)
2015-10-23 10:42:59

williamwoles (92 views)
2015-10-23 10:42:45

Jervac_ (106 views)
2015-10-18 23:29:12

DarkCart (133 views)
2015-10-16 00:58:11

KaiHH (116 views)
2015-10-11 14:10:14

KaiHH (155 views)
2015-10-11 13:26:18

BurntPizza (168 views)
2015-10-08 03:11:46
Rendering resources
by Roquen
2015-11-13 14:37:59

Rendering resources
by Roquen
2015-11-13 14:36:58

Math: Resources
by Roquen
2015-10-22 07:46:10

Networking Resources
by Roquen
2015-10-16 07:12:30

Rendering resources
by Roquen
2015-10-15 07:40:48

Math: Inequality properties
by Roquen
2015-10-01 13:30:46

Math: Inequality properties
by Roquen
2015-09-30 16:06:05

HotSpot Options
by Roquen
2015-08-29 11:33:11 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‑
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!