B4A Library libGDX - Game Engine



One of the best game engines for Android is now available to B4A users. Unleash your creativity!

You can read a description of this library in this guide.

Download for B4A v10.60 and older (4 MB)
Download for B4A v10.70 and newer (4 MB)

Starting from version 1.13, the library is compiled with Java 8, and thus requires a recent version of B4A and Java 8+.
To install the library, copy the .jar file and the .xml file in your libraries folder.

This library is not compatible with the Debug mode. Ensure that you always compile in Release mode.

Download also the examples and templates.

You can reduce the weight of the library if you want to keep your APK file as small as possible. Read this post to learn how to create your Lite version.

Tutorials:
How to make games
Introduction to the libGDX library
PacDroid: from scratch to fun
Shaders

Take also a look at the Cloney Bird tutorial by andymc.

Plugins:
Box2DLights
SpecialFX

Versions:
 
Last edited by a moderator:

wonder

Expert
Licensed User
Longtime User
The maximum size for textures under Android is 2048x2048. It's a hardware limitation. Some devices can support more but it is recommended to stick to 2048x2048.

Given that 2048x2048 = 4194304, would it be a problem to use a texture size of 1024x4096, which translates to the same 4194304 result?
 

wonder

Expert
Licensed User
Longtime User
I haven't noticed I was using version 1.02 until today. As soon as I realized it, I updated to the current 1.10 version.
My current project was compiled without any problems, but the text size is now huge. I had to revert to 1.02 (for now).

I was reading the change-log but I couldn't find any mentions to the text size. Did I overlooked it? What changed?
 

Informatix

Expert
Licensed User
Longtime User
I probably fixed a bug affecting fonts.
Could you post the font initialization code ?
 

wonder

Expert
Licensed User
Longtime User
Some text is scaled according to the status bars vertical size, while other text is scaled according to the player vertical size.

B4X:
status_bars_size_x = 0.28 * maxresX
status_bars_size_y = (status_bars_source_size_y * status_bars_size_x) / status_bars_source_size_x

B4X:
Sub Set_Font_Default_Scales
    Dim sbs = status_bars_size_y   As Double
    Dim asy = actor_size_y(Player) As Double

    Comic_Font(damage_text         ).scale(Comic_Font(damage_text         ).ComputeScaleForPixelHeight(asy   * 0.0900))
    Comic_Font(actor_text          ).scale(Comic_Font(actor_text          ).ComputeScaleForPixelHeight(asy   * 0.0900))
    Comic_Font(action_text         ).scale(Comic_Font(action_text         ).ComputeScaleForPixelHeight(asy   * 0.2500))
    Comic_Font(info_text           ).scale(Comic_Font(info_text           ).ComputeScaleForPixelHeight(sbs   * 0.2210))
    Comic_Font(status_text         ).scale(Comic_Font(status_text         ).ComputeScaleForPixelHeight(sbs   * 0.1457))
    Comic_Font(game_text           ).scale(Comic_Font(game_text           ).ComputeScaleForPixelHeight(maxresY * 0.04))
End Sub
 

Informatix

Expert
Licensed User
Longtime User
You probably need to set different values for the scaling with the new version.
 

Informatix

Expert
Licensed User
Longtime User
Indeed, the delay is there as well.
Was was the solution for this again?
There's no solution for that for now except accepting this delay.

Why there's a delay:
Before v1.09, when the user triggered a change of screen, the hide event was raised while the render event was not finished. That could lead to a crash. I saw these crashes in almost all games that I created with libGDX but it took me some time to find where was the problem. It was simple to create a workaround for this inconvenience in the game code but I preferred to fix it in the library.
In v1.09, I added a few booleans to warn the rendering routine that the user asked for a screen change and to check whether the rendering is finished. So once the rendering is finished, the Render event is no longer called. While Hide is waiting for the rendering termination, a timer can trigger a timeout after 1 second to avoid cases where the rendering is frozen for any reason and the code cannot exit properly.
When you change the screen from inside the Render event, you jump out of the rendering routine and thus the boolean is not set to say "I'm done, go ahead" and Hide waits until the timeout occurs. I should be able to fix that easily, but I won't release a new version of libGDX before a few weeks.

Note that a screen is supposed to be changed after an user action, so this change should never be initiated by code in the Render event.
 

wonder

Expert
Licensed User
Longtime User
1. Not only a touch event, there are other events for user actions, but basically yes.
2. When you change the screen in the Render event, is it really a new screen, with a different interface and purpose?

1. What kind of other event could we use? Can we create our own events?
2. In my current case yes, I'm changing from the Loading Screen into the Game Screen and vice-versa.
 

Informatix

Expert
Licensed User
Longtime User
1. What kind of other event could we use? Can we create our own events?
2. In my current case yes, I'm changing from the Loading Screen into the Game Screen and vice-versa.
1) Look at the event declarations of _TemplateInputGD.b4a
2) The loading screen should not be a different screen. In a non-game application, it would not be a different screen, just a spinning wheel or a progress dialog. Your loading screen could be displayed over the screen that waits for resources and cleared when done.
 

wonder

Expert
Licensed User
Longtime User
That would defeat the two-screen philosophy I'm currently using. Here's why I did it this way:
Upon level completion, the Hide event of the "GameScreen" conveniently disposes (AssetManager) all the resources loaded for that level.
This way, I'm safely assured that there is no memory being wasted with unused assets and the game engine become "tabula rasa" for the next level.
Indeed, I'm sure there is a way to keep everything in one screen, but I have to say that I'm pretty comfortable with this current structure. I experience no issues at all.

Before v1.09, when the user triggered a change of screen, the hide event was raised while the render event was not finished. That could lead to a crash.
Since the beginning, my screen change code has been carefully placed at the end of the Render event, right before the "End Sub".
Wouldn't this count as "waiting for the render event to finish"?
 

Informatix

Expert
Licensed User
Longtime User
That would defeat the two-screen philosophy I'm currently using.
Don't worry. I will fix this issue in the next version.
To manage your resources, you can have more than one AssetManager. You can create one per screen if you want to be well organized.

Since the beginning, my screen change code has been carefully placed at the end of the Render event, right before the "End Sub".
Wouldn't this count as "waiting for the render event to finish"?
If you place a log statement in the Render event, you will see that your screen change puts the rendering in a frozen state.
 

wonder

Expert
Licensed User
Longtime User
If you want to take a screenshot from within the app, it is a good idea to convert to a pixmap. You can take this Java example as a basis. To save your pixmap to a PNG, you have to use the lgPixmapIO class.

I had a look at the Java code and to my (minimal) understanding, just compiling it into a lib with SLC won't be enough, right?
Which steps should I take to implement this feature? I'll be using SLC.
 
Cookies are required to use this site. You must accept them to continue using the site. Learn more…