[X]Assistant

[Suvitruf]

LibGDX Tutorials

libGDX is an open source (Java) cross-platform library for creating games. It is the framework, to say that libGDX is an engine, is not quite right. To help developers, there is a Wiki, an active forum, online JavaDocs documentation, and even video tutorials. The library supports the development of both 2d and 3d games, supports all versions of OpenGL available on Android.

If the moderators allow, I will post in the subject announcements of my tutorials with a link to the articles themselves in my blog. Ask "why this topic, if everything can be found on the blog?". Supposed to create a topic so that people ask questions about this. If the question is not complicated, I will answer right here. If disclosure of a question pulls on an article, then I will make an article

While there are not so many lessons, I write when there is time. In the future, I plan to highlight all the main parts of the development so that everyone can write their own Bomberman = D

1. Introduction. libGDX-part-0.pdf(362.65 KB)
   Describes the setting of the environment itself: what and where to download to start development and how to connect all this to Eclipse.
   
2. Game life cycle. libGDX-part-1.pdf(254.48 KB)
   Considered the life cycle of the game. In principle, as applied not only to games, but to any application on Android.
   
3. Game architecture. libGDX-part-2.pdf(257.59 KB)
   Considered architecture. I suggest MVC-like architecture to separate logic, model, and presentation.
   
4. Scene2d based game architecture. libGDX-part-2-1.pdf(342.21 KB)
   In order not to reinvent the wheel, you can use the tools themselves. In libGDX there is a package scene2d, which allows you to create a good architecture based on it.
   
5. Module Overview. libGDX-part-3.pdf(273.45 KB)
   The article is a translation of official documentation.
   
6. Sprites, Textures, Regions, Atlas. libGDX-part-4.pdf(399.6 KB)
   When writing a game, the most time is spent on working with graphics. This article discusses how to work with graphics (textures, regions, etc.) in libGDX. In addition to describing the principles of basic give a couple of tips on optimizing rendering.
   
7. Touchscreen operation and control. libGDX-part-5.pdf(280.27 KB)
   On how to organize control in the game using the joystick.
   
8. Work with the physics engine Box2D. libGDX-part-6.pdf(359.8 KB)
   Highlights when working with Box2D. Shows how to create simple objects and handle interactions between them.
   
9. Work with ContactListener from Box2D. libGDX-part-6-1.pdf(292.75 KB)
   The article discusses the class
   ContactListener
   that allows you to handle collisions. A couple of practical examples are given: passing through objects, destroying objects when touched.
   
10. Using Filters in Box2D. libGDX-part-6-2.pdf(292.67 KB)
    How to filter collision checks.
    
11. Using admob. libGDX-part-7-1.pdf(301.13 KB)
    It tells how to add AdMob ads to your games written in LibGDX. Examples of implementation are given, etc.
    
12. Creating menus and switching between screens. Describes how to create your game menu with LibGDX tools.
    

Sources on github:libgdx tutorials at github
Who cares, sharedBomberman source.


There is no curator in the subject. If there is a user in the subject who wants to become a Curator and the correspondingRequirements for candidates, he can apply in the topicI want to be curator(after having studied the topic header and all materials for curators).
Prior to the appointment of the curator, on filling caps, please contactmoderatorssection through a buttonunder the messages to which you want to add links.

Post has been editedvaalf - 23.11.17, 12:02

Reason for editing: curator

[asmodium]

[email protected], 16:14

Yesterday was composited with a turn. In the end, too, stopped at the hard code.
The difficulty was incredible.

When turning, not only resize is called, but also create!
And this is generally hemorrhagic.

clear and override everything ... no?

[Suvitruf]

[email protected], 12:57

What could be the reason that after drawing a quad with a shader, the following sprites are drawn in black squares despite the fact that they are formed from PGN with transparency?
turning blending into sprite rendering doesn't help

Code show, so hard to say = /

[asmodium]

[email protected], 16:42

Code show, so hard to say = /

render

@Override
public void render () {
cam.update ();
float dt = Gdx.graphics.getDeltaTime ();
delta + = dt;
if (delta> = 1f / 30) {
delta - = 1f / 30;
update ();
}

Gdx.gl20.glClear (GL20.GL_COLOR_BUFFER_BIT);

//************************
//Gdx.gl20.glBlendFunc(GL20.GL_SRC_ALPHA, GL20.GL_ONE_MINUS_SRC_ALPHA);
//Gdx.gl20.glEnable (GG20.GL_BLEND);
tex1.bind (1);
sh_def.begin ();
sh_def.setUniformMatrix ("u_projTrans", cam.combined);
sh_def.setUniformi ("u_texture", 1);
fbomesh.render (sh_def, GL20.GL_TRIANGLE_FAN);
sh_def.end ();
//************************

spriteBatch.begin ();
spriteBatch.enableBlending ();
if (accav == true) {
// drawtext ("X:" + accelX + "\ nY:" + accelY + "\ nZ:" + accelZ, 0, 100);
}
String fps = Gdx.graphics.getFramesPerSecond () + "";
drawtext (fps, 0, 0);
spriteBatch.end ();
myworld.world.step (BOX_STEP, BOX_VELOCITY_ITERATIONS, BOX_POSITION_ITERATIONS);
}

[Suvitruf]

And what of this is not drawn? -.-
And I do not see any call to draw for spriteBatch.

Post has been editedSuvitruf - 24.01.13, 15:34

[asmodium]

Sorry forgot something))
I hope it will be so clearer

void drawtext (String text, int x, int y) {
String] a = text.split ("\ n");
for (int i = 0; i font.draw (spriteBatch, a [i], x, height - y - i * 32);
}
}

the most common output of text font sprites

Post has been editedasmodium - 24.01.13, 20:38

[Suvitruf]

[email protected], 21:37

Sorry forgot something))
I hope it will be so clearer

void drawtext (String text, int x, int y) {
String] a = text.split ("\ n");
for (int i = 0; i<a.length; i ++) {
font.draw (spriteBatch, a [i], x, height - y - i * 32);
}
}


the most common output of text font sprites

Instead of text, a black square? Can initialize not so. Do you like this?

BitmapFont font = new BitmapFont ();
CharSequence text = "text"
font.setColor (1.0f, 1.0f, 1.0f, 1.0f);
font.setScale (2,2);

Post has been editedSuvitruf - 24.01.13, 20:43

[asmodium]

before using the shader in this form, the text is normally displayed
code just in case

font = new BitmapFont (
Gdx.files.internal ("data / arial32.fnt"),
Gdx.files.internal ("data / arial32.png"), false);
font.setColor (1f, 0.5f, 0f, 1f);

after the black squares began to appear ... in theory, the shader processes only what is transferred to it for drawing and should not affect everything else

[Anfer]

Question. The better to handle user input.
Input or InputProcessor.

InputProcessor seems to be logical, but as far as I understand from the description, it is called before the render, and its work can stop rendering very much.
With Input, everything seems to be ok, but there are no familiar methods.

Does it make sense to think about Input?

[Suvitruf]

[email protected], 11:49

Question. The better to handle user input.
Input or InputProcessor.

InputProcessor seems to be logical, but as far as I understand from the description, it is called before the render, and its work can stop rendering very much.
With Input, everything seems to be ok, but there are no familiar methods.

Does it make sense to think about Input?

Stop for a couple of nanoseconds? )
I inherit classes from InputProcessor, it is very convenient to work with it.

Honestly, I didn’t really think about where the screen processing is called from. But does it matter? If you look at the profiler, the touch processing takes a very short processor time. So, I would advise InputProcessor.


Posted on 1/25/2013 5:17 pm:

[email protected], 21:52

after the black squares began to appear ... in theory, the shader processes only what is transferred to it for drawing and should not affect everything else

Really weird. I have never used fonts in this form. All the letters in the form of pictures in my atlas, and then the regions pull out of it and blond as the texture)

[Anfer]

[email protected], 16:17

Stop for a couple of nanoseconds? )
I inherit classes from InputProcessor, it is very convenient to work with it.

Honestly, I didn’t really think about where the screen processing is called from. But does it matter? If you look at the profiler, the touch processing takes a very short processor time. So, I would advise InputProcessor.

Hm Very strange.
I bring FPS to the screen always. And as soon as I touch the screen, the FPS begins to fall. At 5-7. And if you crawl on the screen, then to 45 drops.
But maybe this is my miracle phone.

And how to properly unload the game?
What and where to write? I tried to dispose to write finish home activation, but something the application is still not in a hurry to unload it.

Post has been editedAnfer - 25.01.13, 17:37

[Suvitruf]

[email protected], 18:35

Hm Very strange.
I bring FPS to the screen always. And as soon as I touch the screen, the FPS begins to fall. At 5-7. And if you crawl on the screen, then to 45 drops.
But maybe this is my miracle phone.

The fact is that FPS jumps in the region of 50-60 are not noticeable to a person if he does not know about it.
No need to bother in this regard.

[email protected], 18:35

And how to properly unload the game?
What and where to write? I tried to dispose to write finish home activation, but something the application is still not in a hurry to unload it.

And here everything is quite complicated. Dalvik takes care of when to unload resources.

When switching between screens, you can normally unload resources. But about the game itself ...

Even if in the dispose method of the application to do the cleaning of resources, it is not known when the dalwick will unload resources = /

[Suvitruf]

libGDX, Part 8. Creating menus and navigating between screens

In any game there is a menu. It's hard to come up with another way to navigate. This article will look at how to create your own screen with a menu using libGDX. Along the way, a little about the aspect ratio problem on various devices.

[Anfer]

A few questions about rendering.

1. At the ogl axis is directed upwards. Should I bother with translating it into us?
   
2. In J2ME, when changing forms (I already forgot how they were called), on some phones the desktop “blinked”. To do this, I had to render everything in 1 "window" and change only the stuffing. At least in the android not ??
   
3. For SpriteBatch, begin / end. How best to call them? 1 time and draw between. Or you can set begin / end for each sprite. Whether it will bring a performance loss, or you can not bother. (example. for drawing of course there are sprites, but sometimes I do the insertion of rectangles for debug. They give something like this.
   
   sb.end ();
   sr.begin (Shape.Rect);
   sr.drawrect ();
   sr.end ();
   sb.begin ();
   
   This breaks the code for SpriteBatch to draw the shape, and then restores it.
   Is this a normal approach?
   

Post has been editedAnfer - 25.01.13, 23:19

[Suvitruf]

Anfer @ 01/26/2013, 00:06

Another question about rendering.
At the ogl axis is directed upwards. Should I bother with translating it into us?

In the sense of? -.-

[Anfer]

In a normal system, X is to the right, Y is down from the upper left. Everything is drawn from left to right, top to bottom.
In OpenGL, the Y axis is pointing up and all drawing, respectively, from left to right, from bottom to top. The drawing point is not on the left above, as it is used to, but on the left below.

Here it is. And it turns out somehow terribly when translating. To draw a texut 20 * 20 in a normal system, you need to draw something like this.

(Screen Height - Position Y - Height of Object) * ppuY

Cloudy And so every sprite.

+ If not difficult, I described 2 more questions in a previous post, so as not to litter.

[Suvitruf]

Anfer @ 01/26/2013, 00:23

In a normal system, X is to the right, Y is down from the upper left. Everything is drawn from left to right, top to bottom.
In OpenGL, the Y axis is pointing up and all drawing, respectively, from left to right, from bottom to top. The drawing point is not on the left above, as it is used to, but on the left below.

Here it is. And it turns out somehow terribly when translating. To draw a texut 20 * 20 in a normal system, you need to draw something like this.
Code
(Screen Height - Position Y - Height of Object) * ppuY

Cloudy And so every sprite.

+ If not difficult, I described 2 more questions in a previous post, so as not to litter.

I draw everything in OpenGL coordinates. I.e
Y * ppuY, counting from the bottom

The only problem is touch processing. There, yes, you have to subtract from the height of the screen.

Posted on 1/25/2013, 23:32:

Anfer @ 01/26/2013, 00:06

In J2ME, when changing forms (I already forgot how they were called), on some phones the desktop “blinked”. To do this, I had to render everything in 1 "window" and change only the stuffing. At least in the android not ??

When changing orientation?

[Anfer]

[email protected], 22:32

When changing orientation?

Not. Roughly speaking, when changing the screen.

And on SpriteBatch / ShapeRenderer?

Post has been editedAnfer - 25.01.13, 23:43

[Suvitruf]

Anfer @ 01/26/2013, 00:41

Not. Roughly speaking, when changing the screen.

When switching between Sreens with LibGDX means there are no blinks, all the rules)

Anfer @ 01/26/2013, 00:41

And on SpriteBatch / ShapeRenderer?

Anfer @ 01/26/2013, 00:06

For SpriteBatch, begin / end. How best to call them? 1 time and draw between. Or you can set begin / end for each sprite. Whether it will bring a performance loss, or you can not bother. (example. for drawing of course there are sprites, but sometimes I do the insertion of rectangles for debug. They give something like this.

Well, in the final application, debug mode is cut down, so there will be no problems there.
In general, if you do everything within the framework of a begin ... end block, then as far as I remember, it will be a little faster.

[Anfer]

As an opportunity, add a lesson about profiling.
In j2me it was quite simple, and in Andi I’m already fighting what day, nothing is clear.

[Suvitruf]

[email protected], 10:57

As an opportunity, add a lesson about profiling.
In j2me it was quite simple, and in Andi I’m already fighting what day, nothing is clear.

Eclipse has a handy DDMS profiler.