Wednesday, April 30, 2014

GDX 1.0

Well, after I said that I wasn't going to bother getting the gradle build working, it's time to eat my words.

About a week or so ago, Mario (the man behind libGdx) announced that they finally were officially releasing version 1.0 of libGdx. I've been dragging my feet about trying to keep up with changes to the library, as it's not completely backwards-compatible, and I didn't want to get on the treadmill of trying to keep changing my code to stay up-to-date. But after some consideration, I figured a 1.0 release was worth migrating to.

The biggest change between my old version (from about a year ago) and 1.0 was the directory structure and build scripts for your game. Like I mentioned before, they switched to a gradle-based build system (which is quite nice), and with that came some rearranging of the project directories.
libGDX has this cute little project creation UI that you can use to get everything set up correctly.

I figured the easiest route would be to create a new blank project using their nice project creation tool, then move all my code into the right places in it, and see if it would build. So I spent about 15 minutes copying source files all over the place until it was all in the right place, and tried building it. That's when the myriads of errors showed up (which I was expecting, with all the library changes over the past year).

Most of the compile errors were pretty simple to fix: they removed support for OpenGL ES1.x and now use 2.0, which just meant I needed to just change from using Gdx's GL10 class and instead use GL20 -- changing the name was enough, as the functionality I was using was the same across both of them.  There was also a change in the class hierarchy of one framework class I was using (SpriteBatch), so some of the methods I was overriding in a few places had to have their method signatures changed. Simple stuff.

When I got to actually running the game, it got a little more complicated. For the UI/HUD bits, I use a set of classes called Scene2d, which act somewhat like a traditional ui toolkit, letting you add groups/images/widgets/etc in a treelike graph to display on the screen and respond to input events.  Unfortunately (for me) they changed how the scene was mapped to the current GL viewport, in a way that caused all of my UI to be messed up -- they changed from 0,0 being the corner of the screen, to 0,0 being the center.  Ugh.  Because I had coordinates for my UI bits scattered throughout my UI classes, I really didn't want to have to figure out how to translate all of them.  So I eventually I gave up on doing it how they wanted, and just extended their Stage class (the base group that all scene elements get added to) to translate everything back to how it was originally.

So now everything was building. It was a relatively simple matter, then, to update my main build script that jenkins uses to just call the gradle build, and everything appears to be working so far.

So now I can get back to writing actual code.

Next post: squashing bugs related to leaving/resuming the app.  Oh, and I just realized that I never did post again about what I ended up doing with the minimap. I guess I need to do that as well.

No comments:

Atari QuadGames

Well, the first prototype adapter is finished, Quad-Joust is undergoing testing (ie making my kids come down to the basement and play it wit...