Update roadmap

[Frosty-J]

About https://libgdx.com/roadmap/...

• AWT Support for LWJGL 3: Is this still in progress?
• Box2D Update: Should be changed to in-progress per Update box2d libgdx#5948 (comment).
• Console Support: No change here. SwitchGDX still exists and supports some of the extensions.
• Geometry/Tesselation/Compute Shaders: Progress has stalled? The branch it links to was last committed to in 2017. CC: @mgsx-dev
• gdx-video Resurrection: Can we mark this as completed/remove it? Version 1.3.3 has released and it's in a more stable state than it was, albeit with limitations like no alpha channel. CC: @SimonIT
• Kotlin-Compatible Web Backend: Probably beyond "Planned" now. TeaVM is integrated into gdx-liftoff. I've never had a straight answer on if it's production-ready or still experimental and have not tried it myself. CC: @xpenatan @tommyettinger
• TiledMap Extension: The link to lyze237/gdx-TiledMap is dead and I haven't learnt much from its other references. CC: @BoBIsHere86

Are there any new items to add to the roadmap? I'm not looking to change it straight away since I'm rather occupied for the next fortnight, so first-PR-first-served.

[BoBIsHere86]

In regards to the TiledMap stuff, all I know is that the idea to break the tiled maps stuff off into it's own thing is something I recall people had wanted to do for long time because of the slow libGDX release schedule. But I don't think the push for it ever officially went full steam ahead. Or maybe it did, and I just missed it.

But, back when I started my initiative a few months ago to annoy everyone into getting the current TiledMap issues and PRs cleaned up. I did so because I thought, well... there's tons of these piling up and as a user of Tiled. I would love some new features. Plus ,if we ever did want to break it off into it's own thing. It would probably be best to fix all these bugs and open PRs first and get us to a clean slate to work from before we get serious about it.

But that's all the input I can give on this subject. I am just a simple libGDX user and occasional PR pusher. Nothing more. 😄

[SimonIT]

I think gdx-video is on a good way. Yes, it's still missing some features, but I think some people are already using it and it gets some contributions from time to time. (I also heard for the first time that alpha channel support is wanted. But it makes sense when I think about it)

[tommyettinger]

TeaVM isn't official and I personally don't think it's as stable as GWT, but for people who use Kotlin it is the only game in town to target the web. However, it may not be exactly stable yet, but the new WASM backend is sometimes massively faster than GWT in some of my unrealistically strenuous benchmarks, particularly on code that uses long math (GWT has always been both very slow at long math and dependent on it for most operations that need to be the same cross-platform, like seeding for procedural generation). The WASM code is currently in a "dev" version for TeaVM itself and a "-SNAPSHOT" version for xpenatan's libGDX backend, and I don't know how much longer it will be for it to get more stable. There are currently some challenges involving how much heap it needs to have allocated at the start, and those don't have a clear answer yet for all cases that I know of. I think as the WASM code gets truly stable, we should consider making the libGDX backend official, it's really that much better than GWT at raw performance for some key aspects right now, and a substantial part of the userbase uses Kotlin or some other language.

[crykn]

Thanks for bringing this up, @Frosty-J! I just made some minor improvements to the page to fix the biggest issues.

The initial idea of the roadmap was for the contributors to update the page whenever they had some major idea/plan etc., but that may have been too optimistic. Also the page may suggest a more coordinated approach behind libGDX's development than there is – it is pretty clear that changes to libGDX are mostly driven by the needs of the people willing to implement them.

I think, I'd be nice to find some overarching goals the libGDX project could strive for in the next couple years, but it's not so clear who would put that vision forward and who would find the time to work on it. IIRC, @Tom-Ski suggested some time ago that we should come up with some ideas and then involve the community in figuring out for what there's really a need. Other suggestions were implementing a bounty program for some of the more sought after requests. I also think we should probably pick up a couple new members to the libGDX team because that always breathes new life into the project, but I digress...