libGDX 1.9.5 released

libGDX 1.9.5

Christmas is almost here. Have a libGDX release. Here’s what’s new (plus a ton of bug fixes, see the commit logs on GitHub).

[1.9.5]
- Upgraded to MobiDevelop's RoboVM fork version 2.3.0, update your 
- Upgraded to GWT 2.8.0 for faster compiles and better compile output
- Fix NPE swallowing "video driver unsupported" error on LWJGL 2 backend.
- Allow window icons to be set in Lwjgl3ApplicationConfiguration or Lwjgl3WindowConfiguration.
- Allow window icon and title to be changed in Lwjgl3Window
- API Addition: ApplicationLogger interface, allowing easier access to custom logging
- DefaultRenderableSorter accounts for center of Renderable mesh, see https://github.com/libgdx/libgdx/pull/4319
- Bullet: added FilterableVehicleRaycaster, see https://github.com/libgdx/libgdx/pull/4361
- Bullet: updated to 2.85, see: http://bulletphysics.org/wordpress/?p=456
- Updated iOS native build scripts to iOS 10.1 and TVOS 10.0
- API Addition: BitmapFont#blankLineScale.
- Fixed rounding of Drawables in ProgressBar. Allow rounding to be disabled with setRound().
- Updated LWJGL3 backend to LWJGL 3.1.0, see https://blog.lwjgl.org/lwjgl-3-1-0-released/
- LWJGL3 backend now supports non-continuous rendering, see https://github.com/libgdx/libgdx/pull/3772
- API Change: Lwjgl3WindowListener.refreshRequested() is called when the windowing system (GLFW) reports contents of a window are dirty and need to be redrawn.
- API Change: Lwjgl3WindowListener.maximized() is called when a window enters or exits a maximized state.
- API Change: Lwjgl3WindowListener.deiconified() removed, combined with .iconified().
- API Change: Lwjgl3Window.deiconify() renamed to .restore() since it can also be used to de-maximize a window.
- Lwjgl3Window now has a maximize() method, and windows can be started maximized using the window or app configuration's setMaximized() method.
- NinePatch can now be drawn rotated or scaled.
- NinepatchDrawable is now a TransformDrawable.
- API Change: Group add* methods no longer remove and re-add the actor if it is already in the group, instead they do nothing.
- API Change: g2d.Animation is now generic so it can support Drawables, PolygonRegions, NinePatches, etc. To fix existing code, specify the TextureRegion type in animation declarations (and instantiations in Java 6), i.e. Animation myAnimation = new Animation(...);
- TiledDrawable throws unsupported operation if trying to draw rotated/scaled. #4005
- API Change: DragAndDrop now puts default position of drag actor at pointer location. The original default offset from the pointer was (14, -20).
- Added ShaderProgramLoader for AssetManager.
- BoundingBox#isValid now returns also true when min==max, see: https://github.com/libgdx/libgdx/pull/4460

Please update your projects as usual.

If you use MobiDevelop’s RoboVM fork make sure to update your Eclipse/IntelliJ IDEA/Android Studio plugin to version 2.3.0.

If you use the GWT plugin in Eclipse and don’t run your GWT project via Gradle, make sure you update your GWT plugin to version 2.8.0.

Happy coding,
The libGDX team

libGDX 1.9.4 released

libGDX 1.9.4

Summer’s almost over, time for a release! Here’s what’s new (plus a ton of bug fixes, see the commit logs on GitHub.

[1.9.4]
- Moved snapping from ProgressBar to Slider to prevent snapping when setting the value programmatically.
- Bullet: added btSoftBody#getLinkCount() and btSoftBody#getLink(int), see https://github.com/libgdx/libgdx/issues/4152
- API Change: Wrapping for scene2d's HorizontalGroup and VerticalGroup.
- Fix hiero problem with certain unicode characters. See https://github.com/libgdx/libgdx/issues/4202
- Switched to RoboVM fork 2.2.0, fixes incompatibility with Android Gradle plugin and iOS 9.3.4

Please update your projects as usual.

If you use MobiDevelop’s RoboVM fork make sure to update your Eclipse/IntelliJ IDEA/Android Studio plugin. It works with iOS 10 devices, but does not work with the Xcode 8 beta just yet.

In other news, Multi-OS Engine has been open-sourced by Intel. It’s now being maintained by its originator, Migeran, who previously sold the IP to Intel. We will update to the OSS version in the coming week(s) and do another release.

Happy coding,
The libGDX team

Kek or how I’ll waste my free time going forward

Screen Shot 2016-06-30 at 20.52.45-hLBpw5hl7K

It’s been a while since this blog had anything other to offer than “libGDX x.x.x released”. This was partly a result of my engagement with RoboVM, which, as you may have heard, is no more. And while I got plenty of real-world-ish stuff to do going forward, I also feel in need of something to challenge my old-farty brain a little in my spare time. For bonus points, I’d like to share my insights and failures with you. And maybe, and that’s a big maybe, something useful comes out at the other end.

You may be thinking: “But what about libGDX?”. Truth of the matter is, I have not been actively pushing code to libGDX in a very long time, save for some minor coding like the initial LWJGL3 backend, or helping out with the recent iOS backend shenanigans. My day to day (or better week to week) libGDX activities have mostly been limited to staying in contact with our fabulous core team, doing the occasional release, managing a libGDX game jam, or kicking our Mac build slave in the butt. My role has simply changed over the years. I’d like to focus my free coding time on something new. Fear not, I will continue to play the benevolent dictator and keep things going as before.

With all that out of the way, let me throw a bunch of thoughts at you. Using my usual wordy style of writing. Enjoy!

The computer science education gap

Disclaimer:I may use the terms “computer science”, “computing” and “programming” interchangeably. I’m aware of the differences, cut me some slack.

I’ve always enjoyed teaching. Let me rephrase that. I’ve always enjoyed telling people of my failures and successes, in the hopes that they can take something away from them. Past endeavours included writing a 700+ pages book, doing a ton of conference talks and workshops, lecturing at university, educating decision makers at companies, or simply talking about my day-to-day technical work with my non-technical SO.

I have also witnessed how kids are taught “computer science” and “programming” at school. It’s a small sample, but it’s generally not pretty. Kids are “fortunate” to come out of school with basic MS Office knowledge. Programming or basic computing, if taught at all, are mostly limited to Scratch like systems. There’s nothing intrinsically wrong with Scratch-like systems. A big number of scientific studies show that initial acquisition of basic computing concepts appears to be better served by exposing the learner to a visual programming environment. Go hit Google scholar, follow the citation graph of “Scratch: programming for all”. Fun fact: developing games has been identified as the best motivator across age groups and genders by multiple studies (and I conveniently lost the citations…).

However, some studies also indicate that kids themselves don’t feel like what they are doing is “real” programming when using Scratch-like systems. Without them being able to describe what “real” programming entails. It’s akin to giving a kid Duplo when what they really want is Lego Technic. Some manage to stay motivated and eventually make the jump to “real” programming. (Note: I view visual programming systems as “real” programming, albeit limited). Most stop engaging with computing in any shape or form.

And that is fine. While I do appreciate the recent push across the industrialised world for more early-age computer science education, I also recognise that computing does not have to and will not be for everyone. Still, nothing would warm my heart more if we can get more kids (and adults) to leave their walled-garden content consumption machines and join the community of digital makers. The earlier we can plant that seed, the better. But something is lacking.

10520_1-lego

51wkYbxWbIL

I believe there is a missing link between the visual programming systems ala Scratch and the text-based behemoths that make up modern day programming. The gap between Scratch and JavaScript/Python/Go/Rust/C/C++/Lua/C#/F#/Clojure/Java/Kotlin/Scala is huge. Not only is there a switch in input modality that comes with pesky de-motivators like syntax errors, slow typing speed, or concepts that need to be hand-waved away initially (everything is a class, et. al.). The overwhelming complexity of just getting set up and understanding the basic operation of these development environments is to much for many aspiring coding apprentices. On the other end of the spectrum, Scratch-likes are so far removed from real-world systems that the knowledge gained is often insufficient for further study.

On top of these “technical” issues, the social aspects of the communities around Scratch-like systems get lost as well. Trying to enter the circles of “real” programmers can be a rather frustrating experience. While there are exceptions to the rule, most communities I’ve been part of have been downright hostile to newcomers. Furthermore, where would you point a newbie interested in joining a community for “real” development platforms? Most communities are heavily fragmented, and it’s entirely unclear which of these sub communities are most suited for beginners. For something like Scratch, it’s very clear: simply go to the Scratch website and find like-minded people and mentors (and moderators).

And while technically possible, sharing and remixing your and other people’s work is multiple orders of magnitude more complex using “real-world” systems than using projects like Scratch. I view this feature of most educational programming environments to be key in keeping newcomers motivated, offering additional sources for self-driven learning, enabling collaboration, and learning soft and organizational skills.

“But Mario you silly goose, there are a metric ton of such systems out there!”. Yes, there’s a ton of educational programming environments out there. Over the past few weeks, I got to enjoy many of them, including, but not limited to Tynker, Stencyl, Scirra, Snap!, CodeCombat, or MinecraftEdu. The last one is now actually called “Minecraft for Education” after the buy-out of MinecraftEdu by Microsoft. Leaving hundreds of teachers stranded without a backup plan.

Some of them are infuriatingly bad (no undo, slowness, glitches and bug galore) that I’d not recommend them to my worst enemy. Some have a weird understanding of pedagogy. Tynker for example has lessons specifically targeted at girls, including licensed assets from the Monster High brand. Interestingly enough, the lessons for girls on mobile devices are a LOT simpler than those targeted at boys. Because we all know, girls are stupid, right? Many are behind pay-walls or limited to a single platform and device class. (Looking at you, Swift Playgrounds. So close, but no cookie.)

The other solutions in that space are great to introduce extremely basic computing concepts to your kid (or adults), but are a long way from narrowing the gap to “real” development environments.

Project Kek

cute-unicorn-clipart-unicorn4

In short, I want to try creating that kind of missing link vaguely described above. Here’s what I believe are crucial features:

  • Free, open source (I hate money) and as cross-platform as possible
  • A programming language that scales with the user’s experience (imperative, structured, functional, object-oriented), with a low barrier of entry, and a high ceiling of what’s possible
  • A set of standard libraries tailored for each experience level, geared towards game development
  • A self-contained, extendable development environment that iteratively introduces concepts like code structuring, debugging, deployment & packaging, version control, dependency management, etc. and allows collaborative work out of the box
  • Newcomer friendly, localized documentation for all of the above, geared towards self-learning
  • A moderated community hub to share, remix and talk about your creations
  • A way to let educators create and share teaching materials

Yes, this sounds a bit insane. But consider that these features can be scoped. Take a look at Pico-8. It already does a lot of things right in my book. There’s nothing prohibiting the first few iterations to work on a similar complexity level as Pico-8.

I think of it as the training wheels version of a real-world programming environment. Another analogy would be a modernised version of the environments of old like QBasic, Turbo Pascal and so forth. These systems from the pre-internet age came equipped with enough material to let motivated people become self-starters. My hypothesis is that an internet-age version of such a tool might just be the right thing to fill the gap between Scratch-likes and “real” programming environments.

Next Steps

As a first step, I want to protoype the first few features from the list above. This includes the first iteration of the programming language, a minimal standard library, and potentially piggybacking on an existing editor like Visual Studio Code. All of this will be documented on this very blog.

Should the initial prototype be a complete disaster, I’ll try to recycle as much as possible and potentially head off into an entirely different direction. An agent-based, programmable, shared virtual environment could also be an interesting avenue to tackle this problem. From a technical side, this is quite a bit more advanced and resource intensive, which is why I want to hold off on spouting the finer details just yet.

All things considered, I’ll likely fail. But I’ll have a metric ton of fun doing so!