Libgdx: Issues requiring a major release that won't be fixed anytime soon

[davebaol]

What is this? Simply said, this is:

• an invitation not to open new issues implying wide API breakage
• a single collection point for such issues
• a gentle way to let the dev team absorb the idea that sooner or later a major release will be needed :relaxed:

This is what I collected so far:

• Immutable Color and Vector
• gdx-utils
• Logging (BTW I think that a logging system separated from Gdx.app, for instance Gdx.logger, would be much easier to customize)
• Vulkan
• For consistency's sake use Array in place of ArrayList

[nooone]

How to add new ideas/suggestions to this, without opening new issues? Via comments?

I have two suggestions:

Switch the relationship between Camera and Viewport

A camera naturally has a viewport, not the other way around. This would make for a more natural API. The current implementation was done the way it is to keep the API backwards compatible.

Replace LifecycleListener with ApplicationListener

Extensions or other 3rd party additions would be able to hook into the lifecycle better (mostly via the additional render callback), which would add new possibilities.

[davebaol]

@nooone
Your suggestions sound interesting to me

[JesseTG]

Why not just make a new label called libgdx-2.0 or something and give these issues (plus others) that?

[davebaol]

We've already discussed this on irc and decided not to create such a label to avoid useless flooding and hype, since a major release is not planned at all.

[JesseTG]

Not even a less misleading tag like major-change?

[nooone]

Something else I just stumbled over in the API...

AssetManager can currently only work with a certain type of FileHandles. This by itself is a quite annoying fact, because if I have internal assets and external assets, I will now need to have two different managers to load/store them.

By default an AssetManager has an InternalFileHandleResolver. I can create AssetDescriptors with any kind of FileHandle though. If I create one with an external FileHandle and supply that to a default AssetManager, it is "internally transformed" into an internal FileHandle. This is totally unexpected API-wise and should be changed.

AssetManager assetManager = new AssetManager();
FileHandle external = Gdx.files.external("path/to/pic.png");
external.exists(); // true
assetManager.load(new AssetDescriptor(external, Texture.class));
assetManager.finishLoading(); // Crashes with GdxRuntimeException: File not found: path/to/pic.png (Internal)

[kerberjg]

Speaking of Vulkan, it's getting official support starting in Android N. Already in Google's Android dev docs

http://developer.android.com/ndk/guides/graphics/index.html
http://www.theinquirer.net/inquirer/news/2454575/android-n-developer-preview-2-arrives-with-vulkan-support-and-new-emoji
https://developer.nvidia.com/vulkan-android

Given that, I think it's worth to start consider its implementation a bit more seriously.

[nhydock]

Something to bring up: LWJGL3 has switched over to requiring at least Java8 to build and run. Since libgdx has the LWJGL3 backend, I was wondering if is this going to impact libgdx's build process significantly. Android has already switched over to using OpenJDK8 on newer versions of android, but KitKat still has a large market share of android. At this point in time I feel LibGDX should require at least Java8/9 to build and run already when considering Java 8 is already 2 years old, with people who wish to support older platforms having to use old libgdx. For those who need a Java8 JRE to package with their games, they can use something like Zulu on desktop.

[sjosegarcia]

I also want to be like all then other cool kids on the block and use
lambdas.

On Thu, Apr 21, 2016 at 10:45 AM, Nicholas Hydock [email protected]
wrote:

Something to bring up: LWJGL3 has switched over to requiring at least
Java8 to build and run. Since libgdx has the LWJGL3 backend, I was
wondering if is this going to impact libgdx's build process significantly.
Android has already switched over to using OpenJDK8 on newer versions of
android, but with KitKat still has a large market share of android. At this
point in time I feel LibGDX should require at least Java8/9 to build and
run already with how old Java 8 already is, with people who wish to support
older platforms having to use old libgdx. For those who need a Java8 JRE to
package with their games, they can use something like Zulu on desktop.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
https://github.com/libgdx/libgdx/issues/3494#issuecomment-212953598

[MobiDevelop]

Android has already switched over to using OpenJDK8 on newer versions of android, but KitKat still has a large market share of android

These newer versions are Android N - which is still in developer preview.

[intrigus]

You are free do to what ever you want.
If you want Java 8 features, use them.
Libgdx doesn't force you to not use Java 8 features, you just won't be able to use Java 8 on all platforms :)

[sreich]

not to spam, but if you do not know this and you are restricted to < java 8 (_cough_ android), you may be interested in kotlin to alleviate such complaints. does a lot of things better than even java 8 does, but still seamlessly runs on java6 onward. actually even though i can target the newest java, i still much prefer kotlin, albeit its smaller community is a big disadvantage. works well with libgdx :)

[nhydock]

in the same vein as extracting out gdx-utils into a reusable submodule, I feel libgdx should also look into the idea of separating out Scene2D and its GUI system into its own submodule, largely because people might want to use their own or an alternative GUI framework a top libgdx, and the redundancy would just add bloat to their apps.

[kerberjg]

@nhydock Would make sense. There aren't so many cases where it's used, given the total number of games/apps made with libGDX

[obigu]

Not sure if this applies here as it's not an API breaking issue but a project folder structure/organization change.

Default Android module to Idea/Android Studio folder structure

My understanding is that the current Android module folder structure for libGDX projects is based on the pre-Gradle Eclipse based folder structure to be able to support both Eclipse and IntelliJ.

These are the main differences:
http://codebin.co.uk/blog/android-studio-vs-eclipse-folder-structure/

Since Android development team decided to drop support for ADT Eclipse plugin some time ago and most people should have already migrated to IntelliJ, I wonder if it's the time to adopt their standards on the Android module.

Benefits

• Multi Flavor builds: With the current folder structure taking advantage of the awesome Build Variants and specially Build Flavors (https://developer.android.com/studio/build/build-variants.html) is not possible (at least not easy without workarounds, I've personally been unsuccessful trying to set up flavored builds for building separate APK with different classes, manifest and resources for both Google Play and Amazon. Switching to recommended folder structure and it worked straightforward).
• Convention over configuration: Using defaults helps making configuration less verbose and easier to find relevant (that works as it is) documentation/examples online

Implications

• Changes are minimal for new projects (just need to change the project template and build.gradle) to use the new folders (src/main/java instead of src/ for java resources, etc...).
• Breaks Eclipse support (which the Android team has already decided anyway)

I'm able to provide support for this as well as creating a PR if you think it would be an improvement.

[Tom-Ski]

ADT is still being maintained, and there still a lot of developers that rely on eclipse as their IDE, its still a viable option for android development. (Not that I would personally recommend it). There isn't much point in the huge breaking change just to make things slightly more convenient for flavours, it also is already possible at the moment with the current structure with not too much adjustment required.

[obigu]

Well, I don't know how many people are still developing Android apps using Eclipse but the ADT plugin is not maintained by Google anymore and the Open Source Andmore community that has taken over is not very active on it (https://projects.eclipse.org/projects/tools.andmore), in my opinion it's just a matter of time.

In any case that's why I was suggesting libGDX 2.0 for the change, if people are developing Android apps with Eclipse they can still be using 1.9.X, otherwise if they want to use 2.X it would be a good time to migrate.

Regarding breaking compatibility, existing project wouldn't notice when upgrading to 2.0 from 1.9 as the build.gradle is generated on project creation as it currently happens any time a change is applied to the project template.

It's indeed possible to set up simple flavors with the current structure but when increasing in complexity problems arise. When you say it's currently possible to have flavored build with the current project structure "with not too much adjustment required" are we talking about complex flavors with for instance hierarchical java resources, resources, manifest, etc...? Can you be more specific or provide an example? In my experience it's not been the case, I can provide the details if needed.

[Tom-Ski]

If the entirety of the developers that are still using eclipse move over to an alternative by the time 2.0 ever happened, then sure, but there are still a lot of people that use it for development and I don't see that changing any time soon. You only have to visit the forums or sit in the irc to see them.

One of the great things about the Gradle build is that it is IDE independent, and people can use whatever tool they want, limiting this is not good imo.

In terms of compatibility It would mean that people wanting to update their project, if any of the scripts change for any reason, they would have to do it manually instead of generating a new project and copying source. People aren't too familiar with Gradle in general, and nor should they need to be.

The default application has a very basic structure in terms of the gradle build, and it doesn't take much effort to change this, If you are having a specific issue with something you are trying to achieve make a forum post and I can take a look.

[ThomasWrobel]

_cough_
I'm developing crossplatform libGDX projects with eclipse - which import
two other cross platform Java projects of mine.
Not sure I fancy having to switch between multiple IDEs to develop
something. (and if we go down this road, where does it stop? Will
eventually there be specific IDEs for each target platform?) :-/

http://lostagain.nl <-- our company site.
http://fanficmaker.com <-- our, really,really, bad story generator.

On 20 June 2016 at 19:55, Oscar Bigu [email protected] wrote:

Well, I don't know how many people are still developing Android apps using
Eclipse but the ADT plugin is not maintained by Google anymore and the Open
Source Andmore community that has taken over is not very active on it (
https://projects.eclipse.org/projects/tools.andmore), in my opinion it's
just a matter of time.

In any case that's why I was suggesting libGDX 2.0 for the change, if
people are developing Android apps with Eclipse they can still be using
1.9.X, otherwise if they want to use 2.X it would be a good time to migrate.

Regarding breaking compatibility, existing project wouldn't notice when
upgrading to 2.0 from 1.9 as the build.gradle is generated on project
creation as it currently happens any time a change is applied to the
project template.

It's indeed possible to set up simple flavors with the current structure
but when increasing in complexity problems arise. When you say it's
currently possible to have flavored build with the current project
structure "with not too much adjustment required" are we talking about
complex flavors with for instance hierarchical java resources, resources,
manifest, etc...? Can you be more specific or provide an example? In my
experience it's not been the case, I can provide the details if needed.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/libgdx/libgdx/issues/3494#issuecomment-227218412, or mute
the thread
https://github.com/notifications/unsubscribe/AFbm0cqztXUPzJjeWSeQ_xHxrm68JNJkks5qNtQTgaJpZM4GQxnW
.

[ThomasWrobel]

(for what its worth I dont use Scene2D though)

http://lostagain.nl <-- our company site.
http://fanficmaker.com <-- our, really,really, bad story generator.

On 20 June 2016 at 20:04, Thomas Wrobel [email protected] wrote:

_cough_
I'm developing crossplatform libGDX projects with eclipse - which import
two other cross platform Java projects of mine.
Not sure I fancy having to switch between multiple IDEs to develop
something. (and if we go down this road, where does it stop? Will
eventually there be specific IDEs for each target platform?) :-/

http://lostagain.nl <-- our company site.
http://fanficmaker.com <-- our, really,really, bad story generator.

On 20 June 2016 at 19:55, Oscar Bigu [email protected] wrote:

Well, I don't know how many people are still developing Android apps
using Eclipse but the ADT plugin is not maintained by Google anymore and
the Open Source Andmore community that has taken over is not very active on
it (https://projects.eclipse.org/projects/tools.andmore), in my opinion
it's just a matter of time.

In any case that's why I was suggesting libGDX 2.0 for the change, if
people are developing Android apps with Eclipse they can still be using
1.9.X, otherwise if they want to use 2.X it would be a good time to migrate.

Regarding breaking compatibility, existing project wouldn't notice when
upgrading to 2.0 from 1.9 as the build.gradle is generated on project
creation as it currently happens any time a change is applied to the
project template.

It's indeed possible to set up simple flavors with the current structure
but when increasing in complexity problems arise. When you say it's
currently possible to have flavored build with the current project
structure "with not too much adjustment required" are we talking about
complex flavors with for instance hierarchical java resources, resources,
manifest, etc...? Can you be more specific or provide an example? In my
experience it's not been the case, I can provide the details if needed.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/libgdx/libgdx/issues/3494#issuecomment-227218412,
or mute the thread
https://github.com/notifications/unsubscribe/AFbm0cqztXUPzJjeWSeQ_xHxrm68JNJkks5qNtQTgaJpZM4GQxnW
.

[cypherdare]

@obigu I've been using build flavors with LibGDX for almost two years. Example project.

Look at the sourceSets enclosure for how I'm doing hierarchical resource files for the free version of the app.

[obigu]

@Tom-Ski Makes sense. If 2.0 takes long though I think it's worth considering, as you say people should not need to know Gradle so using defaults and simplifying configuration files will make their lives easier.

@cypherdare Thank you for the example, it's really helpful. I think you are right that defining the sourceSets relevant folders for each flavor pointing outside the src folder it's possible to have complex build cases. It's config heavy and less organized (that may be subjective) but it should work.

On another note I've seen in your particular build.gradle you can simplify the product flavours definitions by defining any shared configuration inside the defaultConfig section (like applicationId or default values to the build properties). If a flavour needs a different value it can just override it.

[ForsakenHarmony]

@ThomasWrobel you can use IDEA for everything though, android developers didn't stop eclipse support without a reason, just saying

[ThomasWrobel]

@Ashley You can develop GWT web apps in it? Does it support super dev mode?
(live previewing/updating in a browser)

http://lostagain.nl <-- our company site.
http://fanficmaker.com <-- our, really,really, bad story generator.

On 16 August 2016 at 06:24, Ashley [email protected] wrote:

@ThomasWrobel https://github.com/ThomasWrobel you can use IDEA for
everything though, android developers didn't stop eclipse support without a
reason, just saying

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/libgdx/libgdx/issues/3494#issuecomment-239997775, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AFbm0Rg756t1bxNc3MIzyGCoRkzKUSX4ks5qgTt1gaJpZM4GQxnW
.

[ForsakenHarmony]

@ThomasWrobel have you even looked it up?
https://blog.jetbrains.com/idea/2014/09/intellij-idea-14-brings-better-gwts-super-dev-mode-support/

[ThomasWrobel]

True. I am a idiot.
That said , gwt is a pro feature, so Id need to be quite serious about
switching before making a investment.

http://lostagain.nl <-- our company site.
http://fanficmaker.com <-- our, really,really, bad story generator.

On 16 August 2016 at 13:53, Ashley [email protected] wrote:

@ThomasWrobel https://github.com/ThomasWrobel have you even looked it
up?
https://blog.jetbrains.com/idea/2014/09/intellij-idea-14-
brings-better-gwts-super-dev-mode-support/

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/libgdx/libgdx/issues/3494#issuecomment-240080065, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AFbm0YgEAyNnE1TW2hfUSpxBEy6kRsENks5qgaSngaJpZM4GQxnW
.

[cypherdare]

I've have a minor one... PerspectiveCamera only uses Camera.viewportWidth and viewportHeight for calculating aspect ratio, so there's no reason to hang onto the parameters. OrthographicCamera uses them for the size of the viewable area, so the variable names are confusing. So they should be renamed to just width and height, and they should only be available in OrthographicCamera. PerspectiveCamera can store an aspect parameter instead.

Regarding Vulkan, I think some hooks could be added to LibGDX 1.x and an extension created so we don't have to wait for the (never coming) 2.0.

Regarding immutable Color and Vector--that would make for very verbose code. Perhaps the existing static final Colors could be made into color integers instead to avoid the issue entirely. I don't think the static final Vectors are used much, so they could simply be removed.

[badlogic]

I'm not sure what people expect from Vulkan. It's an extremely fickle API and the gains for what 99% of libGDX users do (2D) will most likely be nil.

[kerberjg]

Speaking of Java 8 though, things have changed since the release of Android 7.0 (previously N), namely most Java 8 features are now supported on older Android versions thanks to Google's new "Jack" toolchain, specifically:

Features requiring Android 6.0 and lower:

• Lambda expressions
• Method references
• Type annotations

Features requiring Android 7.0 and newer:

• Default and static interface methods
• Repeatable annotations

All we need to do is to update our build.gradle files to allow source compatibility with JDK 1.8 and to tell the Android SDK to build with Jack (details in the link below) and we're ready to go.

I don't see why we shouldn't take advantage of new features of Java 8 (specifically the new Stream utlities, which could be very useful on modern multi-core mobile devices) instead of still using a 10-year old Java version. I'm ready to take care of the necessary PR myself, as long as we all agree on this.

source: https://developer.android.com/guide/platform/j8-jack.html

[badlogic]

Jack is broken in all kinds of funny ways. RetroLambda does the same thing,
I'm OK with (optionally) supporting that in gdx-setup.

On Dec 15, 2016 11:46 PM, "Jakub Kerber" [e-mail] wrote:

Speaking of Java 8 though, things have changed since the release of
Android 7.0 (previously N), namely most Java 8 features are now
supported on older Android versions thanks to Google's new "Jack"
toolchain, specifically:

Features requiring Android 6.0 and lower:

• Lambda expressions
• Method references
• Type annotations

Features requiring Android 7.0 and newer:

• Default and static interface methods
• Repeatable annotations

All we need to do is to update our build.gradle files to allow source
compatibility with JDK 1.8 and to tell the Android SDK to build with Jack
(details in the link below) and we're ready to go.

I don't see why we shouldn't take advantage of new features of Java 8
(specifically the new Stream utlities, which could be very useful on modern
multi-core mobile devices) instead of still using a 10-year old Java
version. I'm ready to take care of the necessary PR myself, as long as we
all agree on this.

source: https://developer.android.com/guide/platform/j8-jack.html

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/libgdx/libgdx/issues/3494#issuecomment-267466905, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAfYBG4M9231aUvPkFQ_3zKE1JJrMTN7ks5rIcMpgaJpZM4GQxnW
.

[ghost]

Replace LifecycleListener with ApplicationListener

Extensions or other 3rd party additions would be able to hook into the lifecycle better (mostly via the
additional render callback), which would add new possibilities.

Would it be hard to implement this in the core code? Since there is already something similar (LifecycleListener).

[shatterblast]

Android recently dropped support for JACK. Older versions of Android just should not put it into use.

The current implementations of LWJGL3 and LWJGL2 both offer support for Vulkan from the previous last two years.

Color and Vector are now immutable.

Gdx-utils is presently fine.

I prefer ArrayList.

I have an implementation of a universal logger I can submit.

[shatterblast]

Can we close this, please?

[intrigus]

LWJGL2 does not and will never support Vulkan
Color and Vector are still mutable.

[shatterblast]

@intrigus
Have you even tried? LWJGL2 supports Vulkan. You have to satisfy what Vulkan wants in the data to make it work, and LWJGL2 certainly does. Just because it does not work for you does not mean it does not work for me. Have you tried an NVidia RTX Series hardware? It works fine. It's because of the OpenGL 1.1 backwards compatibility, which some people don't like for some reason. Newer versions of Vulkan support LWJGL2. If you have not tried a newer version, then that is your problem.

@intrigus
If that does not work for you, then go buy an NVidia GTX 970. It supports Vulkan just as well at a much more affordable price than an NVidia RTX Series. I practically use it all the time to test my code. Your logic is completely wrong. Don't bring your fallacy to me.

@intrigus
You know what else you don't know? The new Google FIDO Java dependency supports Vulkan as well. That means Android works with Vulkan on Android 9 with Coolpad. It's an $80 piece of hardware you can buy off Ebay if you want to test my truth. You are wrong and a liar. Go leave, you stupid piece of AI.

@mgsx-dev
I will re-gain LibGDX as my own again over time. All of it. If I must use Google to do it, then it will fully happen.

As for this thread, all issues have been fixed by me and only me.

[shatterblast]

Close this, please.

[noblemaster]

It's now closed.