You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When working with libGDX (or any other OpenGL based system), you will have to deal with various [coordinate systems](https://en.wikipedia.org/wiki/Coordinate_system). This is because OpenGL abstracts away device dependent units, making it more convenient to target multiple devices and to focus on game logic. Sometimes you may need to convert between coordinate systems for which libGDX offers various methods.
5
5
6
6
**It is crucial to understand in which coordinate system you are working. Otherwise it can be easy to get confused and to make assumptions which aren't correct.**
7
+
{: .notice--info}
7
8
8
-
On this page the various coordinate systems are listed. It is highly recommended to first get familiar with the [Cartesian coordinate system](https://en.wikipedia.org/wiki/Cartesian_coordinate_system), which is the most widely used coordinate system.
9
+
On this page the various coordinate systems are listed. It is highly recommended to first get familiar with the concept of [Cartesian coordinate systems](https://en.wikipedia.org/wiki/Cartesian_coordinate_system), which is the most widely used one.
9
10
10
11
*[Touch coordinates](#touch-coordinates)
11
12
*[Screen or image coordinates](#screen-or-image-coordinates)
@@ -17,12 +18,33 @@ On this page the various coordinate systems are listed. It is highly recommended
17
18
*[Game coordinates](#game-coordinates)
18
19
19
20
## Touch coordinates
20
-
* Units: pixels
21
-
* System: y-down
22
-
* Type: integer, can't be fractional
23
-
* Range: (0,0) (upper left corner) to (`Gdx.graphics.getWidth()-1`, `Gdx.graphics.getHeight()-1`) (lower right corner)
24
-
* Usage: touch/mouse coordinates
25
-
* Dependence: device specific
21
+
22
+
<table>
23
+
<tr>
24
+
<td>Units</td>
25
+
<td>pixels</td>
26
+
</tr>
27
+
<tr>
28
+
<td>System</td>
29
+
<td>y-down</td>
30
+
</tr>
31
+
<tr>
32
+
<td>Type</td>
33
+
<td>integer (can't be fractional)</td>
34
+
</tr>
35
+
<tr>
36
+
<td>Range</td>
37
+
<td>(`0`, `0`) (upper left corner) to (`Gdx.graphics.getWidth()-1`, `Gdx.graphics.getHeight()-1`) (lower right corner)</td>
38
+
</tr>
39
+
<tr>
40
+
<td>Usage</td>
41
+
<td>touch/mouse coordinates</td>
42
+
</tr>
43
+
<tr>
44
+
<td>Dependence</td>
45
+
<td>device specific</td>
46
+
</tr>
47
+
</table>
26
48
27
49
Starts at the upper left *pixel* of the (application portion of the) physical screen and has the size of the (application portion of the) physical screens width and height in pixels.
28
50
@@ -35,12 +57,33 @@ This coordinate system is based on the classic representation of the display, wh
35
57
Whenever working with [mouse or touch](/wiki/input/mouse-touch-and-keyboard) coordinates, you'll be using this coordinate system. You typically want to convert these coordinates as soon as possible to a more convenient coordinate system. E.g. the `camera.unproject` or `viewport.unproject` method let's you convert them to world coordinates (see below).
36
58
37
59
## Screen or image coordinates
38
-
* Units: pixels
39
-
* System: y-up
40
-
* Type: integer, can't be fractional
41
-
* Range: (0,0) (lower left corner) to (`Gdx.graphics.getWidth()-1`, `Gdx.graphics.getHeight()-1`) (upper right corner)
42
-
* Usage: viewport, scissors and pixmap
43
-
* Dependence: device/resource/asset specific
60
+
61
+
<table>
62
+
<tr>
63
+
<td>Units</td>
64
+
<td>pixels</td>
65
+
</tr>
66
+
<tr>
67
+
<td>System</td>
68
+
<td>y-up</td>
69
+
</tr>
70
+
<tr>
71
+
<td>Type</td>
72
+
<td>integer (can't be fractional)</td>
73
+
</tr>
74
+
<tr>
75
+
<td>Range</td>
76
+
<td>(`0`, `0`) (lower left corner) to (`Gdx.graphics.getWidth()-1`, `Gdx.graphics.getHeight()-1`) (upper right corner)</td>
77
+
</tr>
78
+
<tr>
79
+
<td>Usage</td>
80
+
<td>viewport, scissors and pixmap</td>
81
+
</tr>
82
+
<tr>
83
+
<td>Dependence</td>
84
+
<td>device/resource/asset specific</td>
85
+
</tr>
86
+
</table>
44
87
45
88
This is OpenGL's counterpart to touch coordinates; that is: it is used to specify (index) a pixel of the (portion of the) physical screen. It is also used as indexer for an image in memory. Likewise, these are integers, they can't be fractional.
46
89
@@ -61,12 +104,33 @@ The "problem" with this is that OpenGL expects the texture data to be in image c
61
104
To compensate for this up-side-down texture, `SpriteBatch` flips the texture (UV) coordinates (see below) on the y axis when rendering. Likewise, fbx-conv has the option to flip texture coordinates on the y axis as well. However, when you use a texture which isn't loaded from a pixmap, for example a Framebuffer, then this might cause that texture to appear up-side-down.
62
105
63
106
## Normalized render coordinates
64
-
* Units: one
65
-
* System: y-up
66
-
* Type: floating point
67
-
* Range: (-1,-1) (lower left corner) to (+1,+1) (upper right corner)
68
-
* Usage: shaders
69
-
* Dependence: none
107
+
108
+
<table>
109
+
<tr>
110
+
<td>Units</td>
111
+
<td>one</td>
112
+
</tr>
113
+
<tr>
114
+
<td>System</td>
115
+
<td>y-up</td>
116
+
</tr>
117
+
<tr>
118
+
<td>Type</td>
119
+
<td>floating point</td>
120
+
</tr>
121
+
<tr>
122
+
<td>Range</td>
123
+
<td>(`-1`, `-1`) (lower left corner) to (`+1`, `+1`) (upper right corner)</td>
124
+
</tr>
125
+
<tr>
126
+
<td>Usage</td>
127
+
<td>shaders</td>
128
+
</tr>
129
+
<tr>
130
+
<td>Dependence</td>
131
+
<td>none</td>
132
+
</tr>
133
+
</table>
70
134
71
135
The above coordinate systems have one big issue in common: they are device specific. To solve that, OpenGL allows you to use a device independent coordinate system which is automatically mapped to screen coordinates when rendering. This coordinate system is normalized in the range [-1,-1] and [+1,+1] with (0,0) exactly in the center of the screen or framebuffer (the render target).
72
136
@@ -79,12 +143,33 @@ It might be worth to note that the normalization does not respect the aspect rat
79
143
The coordinates are floating point and no longer indexers. The device (GPU) will map these coordinates to the actual screen pixels using [rasterisation](https://en.wikipedia.org/wiki/Rasterisation). A good article (although targeting DirectX it also applies to OpenGL) for more information on that can be found [here](https://msdn.microsoft.com/en-us/library/windows/desktop/cc627092(v=vs.85).aspx).
80
144
81
145
## Normalized texture (UV) coordinates
82
-
* Units: one
83
-
* System: y-up
84
-
* Type: floating point
85
-
* Range: (0,0) (lower left corner) to (1,1) (upper right corner)
86
-
* Usage: shaders, mesh, texture region, sprite
87
-
* Dependence: none
146
+
147
+
<table>
148
+
<tr>
149
+
<td>Units</td>
150
+
<td>one</td>
151
+
</tr>
152
+
<tr>
153
+
<td>System</td>
154
+
<td>y-up</td>
155
+
</tr>
156
+
<tr>
157
+
<td>Type</td>
158
+
<td>floating point</td>
159
+
</tr>
160
+
<tr>
161
+
<td>Range</td>
162
+
<td>(`0`, `0`) (lower left corner) to (`1`, `1`) (upper right corner)</td>
163
+
</tr>
164
+
<tr>
165
+
<td>Usage</td>
166
+
<td>shaders, mesh, texture region, sprite</td>
167
+
</tr>
168
+
<tr>
169
+
<td>Dependence</td>
170
+
<td>none</td>
171
+
</tr>
172
+
</table>
88
173
89
174
Likewise to the normalized render coordinates, OpenGL also uses normalized texture coordinates. The only difference is that these ranges from [0,0] to [1,1]. Depending on the specified wrap function, values outside that range will be mapped within that range.
90
175
@@ -97,12 +182,33 @@ The use of normalized texture coordinates is very important, because it makes th
97
182
When rendering, the GPU converts the UV coordinates to a [texel](https://en.wikipedia.org/wiki/Texel_(graphics)) (texture pixel). This is called "texture sampling" and is based on the [texture filtering](https://en.wikipedia.org/wiki/Texture_filtering).
98
183
99
184
## World coordinates
100
-
* Units: application specific, e.g. [SI Units](https://en.wikipedia.org/wiki/International_System_of_Units)
101
-
* System: application specific, but usually y-up
102
-
* Type: floating point
103
-
* Range: application specific
104
-
* Usage: game logic
105
-
* Dependence: game/application
185
+
186
+
<table>
187
+
<tr>
188
+
<td>Units</td>
189
+
<td>application specific, e.g. [SI Units](https://en.wikipedia.org/wiki/International_System_of_Units)</td>
190
+
</tr>
191
+
<tr>
192
+
<td>System</td>
193
+
<td>application specific, but usually y-up</td>
194
+
</tr>
195
+
<tr>
196
+
<td>Type</td>
197
+
<td>typically floating point</td>
198
+
</tr>
199
+
<tr>
200
+
<td>Range</td>
201
+
<td>application specific</td>
202
+
</tr>
203
+
<tr>
204
+
<td>Usage</td>
205
+
<td>game logic</td>
206
+
</tr>
207
+
<tr>
208
+
<td>Dependence</td>
209
+
<td>game/application</td>
210
+
</tr>
211
+
</table>
106
212
107
213
Typically, your game logic should use a coordinate system which best fits the game logic. It should not depend on device or asset size. For example, a commonly used unit is meters.
0 commit comments