Java Themes in libGDX

Hi guys, I am working on creating a game with libGDX, and I really want to play the game, so I run a drawing cycle and a logical cycle on separate threads, just like you make a simple java swing game with a paintcomponent loop and a runnable run loop

I have experience with threading in c, but not much in java the only way I was able to create a thread is to create a class that extends the threads and then create a run loop there

but the point of creating the launch cycle was to allow each screen to freely calculate the logic, so that in the end I needed some kind of abstract screen class that had its own class of classes

I ask if there is a simpler or more standard way to implement threads for this situation.

+6
source share
2 answers

The libGDX library is already launching a separate visualization thread for OpenGL context updates. See http://code.google.com/p/libgdx/wiki/TheArchitecture#The_Graphics_Module

We already learned that the user interface thread is not running continuously, but only to be launched by the operating system if it is necessary to send an event (approximately: p). Therefore, we create a second stream, which we usually call a rendering stream. This thread is created by the Graphics module, which itself receives an instance of the application at startup.

The ApplicationListener.render() method on your main game object will be called by this rendering stream once for each screen update (therefore it should be around 60 Hz), so just put the body of the rendering cycle in the implementation of this method.

You can create an additional background thread (for example, for game logic) in the create method of your ApplicationListener (be sure to clear it in the dispose method). Other than the render stream, I don't think any of the pre-existing threads would be the right place for the game's logic.

For communication between threads, you can use any of the existing Java synchronization approaches. I used Java ArrayBlockingQueue<> to send requests to the background thread. And I used Gdx.app.postRunnable() to Gdx.app.postRunnable() my background threads to push data into the render stream (such Runnables are run in the next frame, before render() ) is called).

+11
source

I'm not sure what you mean, but by default, the screen image (reflecting the changes on the display) is executed in a separate single thread (for example, see the Swing framework). This is due to the fact that it is quite difficult to allow multiple threads to draw on the screen without delving into what is happening - only a few implementations do this. Therefore, if you plan to independently implement the graphical user interface infrastructure, it is recommended to use a single-threaded drawing approach.

As for your business logic, it depends on many factors. A very simple approach could indeed generate a new stream for each type of activity. Then, these threads can send the result to the specified GUI thread. The problem with this approach is that efficiency can be significantly reduced if many actions are performed simultaneously, since in Java each thread is mapped to a thread of its own OS. To avoid this, you can use thread pools. The Java standard library provides thread pools like ThreadPoolExecutor or if you want a higher abstraction, ExecutorService .

0
source

Source: https://habr.com/ru/post/926654/


All Articles