Can't play the demos

[PiprTuff]

Please ensure you have given all the following requested information in your report.

Issue details

I can't run/play/download any of the demos located in this site:
https://libgdx.com/wiki/start/demos-and-tutorials
If I choose WebGL/GWT, it opens a new site but nothing is there. If I choose Android, nothing downloads.

Reproduction steps/code

Even if you think your issue is trivial to reproduce, please supply a SSCCE that demonstrates your issue. This saves time on our end, and makes it much more likely that your issue will be fixed.
You can find barebones templates here

Version of libGDX and/or relevant dependencies

Please provide the version(s) affected.

Stacktrace

//Please provide the stacktrace if applicable 

Please select the affected platforms

• Android
• iOS
• HTML/GWT
• Windows
• Linux
• macOS

[Frosty-J]

These demos are all very old. They don't follow current best practices (will stretch at different aspect ratios; run at wrong speed at non-60Hz refresh rates; contain bugs; don't make use of newer classes) and not all of the links work (Super Jumper and Vector Pinball are missing; The Plane leads to wrong game). Depending what you're looking for, Simple Open Source Projects and the Showcase may be better references.

Are you using Safari? I know it's a strange question when you mentioned Android, but the web demos still work in Chrome and Firefox on my end but not Safari for iOS (which newer libGDX projects do work in). If you're on Android, note that the online versions aren't mobile friendly.

For ones that do have working links, you can download for Android and desktop by copying the link and pasting it into the address bar. Depending on your browser's security settings you may have to change http:// to https://. For others, you'll have to build the code yourself.

---

To whom it may concern, how could we best deal with binaries? I'm willing to build new versions (best done with GitHub Actions of course) for all but iOS as I did for GWT recently on itch.io (link to Discord discussion and desktop JAR; requires access to the libGDX Discord server to view) which could go on the website (@crykn) and/or each demo's Releases tab.

I'd probably have to generate a new Android signing key, assuming the original is lost to time. It may be easier to maintain if the demos are a single project, but this doesn't work with how it's currently separate repositories. And obviously I don't want to add to the list of ignored pull requests.

[PiprTuff]

OK. By the way I was trying to view the web demos from the Android device.

However, I have another thing to say. The build.gradle file in the Android subproject defines a copyAndroidNatives task which copies the native JNI libraries from the associated zip files to the libs directory, everytime any package related task is run with Gradle. This is a bit time consuming and redundant. But if I you look at the JMonekeyEngine's native library packaging system for Android, you will see that there is no need to define a task in the Gradle's build file, just need to implement the library in the dependencies block. The native library is automatically packaged to the APK by the AGP, only if needed. So it would be better if the same process is implemented in libGDX. And the 4 different Android native libraries may be put in a meta library, lets say 'native-android'. So we can define only one to get all.

[Frosty-J]

Hmm. Which browser? Samsung Internet (based on Chrome), Firefox and the LineageOS Jelly browser could load Space Invaders. That should cover most of the options, unless you have JavaScript disabled.

Yeah, we should probably see if something can be done about copyAndroidNatives. In libgdx/libgdx#6811 (pending review) it's been changed to run on merge and JniLibFolders - dunno what difference this makes.

Having the native libraries as separate dependencies sounds like it could potentially be a divisive topic, and not just due to probably being a breaking change. In libGDX 1.10.0, armeabi (ARMv5, ARMv6) libraries were dropped, so anyone upgrading had to remove the line defining it from build.gradle. It caused quite a bit of confusion, with many people also removing armeabi-v7a, causing their game to not work on most 32-bit devices. If there was some sort of "meta library", this grief could have been avoided. At the same time, I do think it's nice to be able to pick and choose, but the libraries aren't all that big, especially with AAB removing unneeded ones, so I don't know how many people actually go removing x86, for example, to save space.

[PiprTuff]

Hmm. Which browser? Samsung Internet (based on Chrome), Firefox and the LineageOS Jelly browser could load Space Invaders. That should cover most of the options, unless you have JavaScript disabled.

Google Chrome browser on Xiaomi Redmi 8A, running Android 10, armeabi-v7a.

Having the native libraries as separate dependencies sounds like it could potentially be a divisive topic, and not just due to probably being a breaking change...

Why do you think it would be a braking change? 😕
Now we have to define a custom configuration called 'natives', use this configuration in dependencies block to define the native libraries, then define 'copyAndroidNative' task and tell package task to depend on it.

But if those libraries are themselves published as Android libraries (not Java libraries) containing the JNI files in proper directory, then we just have to define those simply by the 'implementation' keyword, and don't need to define custom 'natives' configuration, 'copyAndroidNative' task and on...

I do think it's nice to be able to pick and choose, but the libraries aren't all that big, especially with AAB removing unneeded ones, so I don't know how many people actually go removing x86, for example, to save space.

Off course, it is. I didn't mean to replace all the 4 libraries with a single one. I meant that if someone needs quick setup (targeting all 4 architectures) then he just needs to define just one meta dependency which will fetch the 4.

Another thing to notice... The built APK contains the 'com/badlogic/gdx.gwt.xml' file, which is redundant. It should be excluded in the 'packagingOptions' block. I found it after running this command while in the root project directory:

jar -tf $(find . -name *.apk)

[Frosty-J]

Oh, I thought you meant to replace the current 4 with 1. And yeah, GWT stuff makes its way into other builds - I've particularly noticed this when using libraries such as formic and haven't found a good way to have GWT-exclusive assets. For most projects you can also remove the default shader (think it's only used for 3D) and font.

[crykn]

To keep track of this in a single issue, I'm copying over my comment from #222:

@Frosty-J is right, at the moment they don't seem to be hosted anywhere. If badlogicgames.com doesn't come online again, we should definitely think about transferring them to libgdx.com. The easiest way of achieving this would probably be to build them automatically via GitHub Actions and then deploy the GWT builds to GitHub Pages (similarily to what we do in the https://github.com/libgdx/libgdx-wiki-examples repo). The desktop and Android downloads could be provided via the releases tab of the corresponding repos.

Regardless of that, going forward we should probably think about what we want to do with the demo projects. We might want to archive a few of those/maybe even replace them, considering they are all quite old, have a bunch of open issues/PRs and it's a hassle keeping them up to date.