Rss

Archives for : Android

The libgdx/box2d Jumper tutorial

I have been too busy to finish the tutorial, and I’m not sure when I will get around to it. I know I’ve been leaving a bunch of people hanging for months, and for that I apologize.

However, I have good news. There’s better, neater software available for building graphics and fixtures for libgdx/box2d games: The Box2D Editor. The same person has created a better texture packer GUI and is working on a physics level editor. Way better than anything I was going to be showing you here!

Check out Aurelien Ribon’s Dev Blog.

libgdx, box2d, tiled maps: full working example, part 2/3

This is part 2 of a 3 part post demonstrating how to make a simple side scrolling game using libgdx and box2d. See part 1.

Updated 2011-09-19: Heh, now uses libgdx 0.9.2. No longer has its own Box2DDebugRenderer, figured out a better way using the new Matrix4 argument to renderer. Improved the controls by removing linear damping and replacing it with friction. (I am learning as I go with this, for what it is worth.) Discovered that I made a rather embarrassing mistake in leaving out rudimentary on-screen controls for Android devices. They are still pretty cruddy, though. Maybe I’ll come up with something better, or maybe someone else will and will contribute it? :) Either way is fine.

Updated 2011-09-18: Now uses libgdx 0.9.1.

In part 1 you saw how to make what is essentially a tiled map viewer. After you are through with this part you will have a character that you can move around the screen in a “natural” way, or at least a familiar way. As in part 1, download JumperTutorialProjects.zip for part 2 and follow along as the code is explained.

Continue Reading >>

libgdx, box2d, tiled maps: full working example, part 1/3

This will be a 3 part post demonstrating how to make a simple side scrolling game using libgdx (official project blog), a cross-platform library that allows you to simultaneously build for the desktop and for Android devices.

Updated 2011-09-19: Updated to use libgdx 0.9.2. No code changes required.

Updated 2011-09-18: Updated to use libgdx 0.9.1 (for real this time…) which meant renaming the pack file, TiledMapRenderer to TileMapRenderer, moving and renaming the tiles and pack file (and reindexing) due to new requirements from libgdx.

Updated 2011-06-12: Fixed some graphical glitches reported by Ed (in part 2′s comments). Thanks for all of your help Ed! Additionally, the tutorial is now based on libgdx 0.9.1 (it might have been libgdx 0.9.0 at the time, sorry folks) instead of an arbitrary nightly build, and it uses a modified TexturePacker in place of “manual” pack file generation.

This example is for anyone interested in making Android games, but is unsure where to start. By the end of part 3 you will have a basic Mario-like side-scrolling game with realistic physics, and (hopefully) you will be able to take this example and build something fun.

I’ve learned a few things since writing my previous post on using Tiled Map Editor with libgdx that I’ll apply in this series, things that make building a simple tiled-map game a lot easier. All code found here is released under the Apache 2.0 license, meaning, basically, you can use it for whatever you want. (IANAL, read the license for details.)

This is a much more involved tutorial than you have seen before on this site. There are a lot of different components used here and I tried to avoid cutting corners during explanations.

Continue Reading >>

libgdx, Tiled Map Editor, TexturePacker, and you

libgdx has support for files created by the Tiled Map Editor, allowing you to easily create 2D orthogonal map scenes for your games. Once it’s up and running it is really neat. Getting it all to work requires careful setup, however. Updated 2011-03-20 after finding a critical problem found while following these steps again.

Continue Reading >>

libgdx and TWL: Centering your layout

This won’t be a full on tutorial — it’s late, and I just now figured out how to do this — but I’m hoping that this will be helpful to others who go looking for a way to center their TWL layout within the screen, allowing you to do whatever it is you want around (behind) TWL.

As documented in TWL.java, libgdx is creating a root Widget that is set to take up the whole screen. So, if you want to center a TWL layout you’ll need to do it with TWL methods.

Continue Reading >>

libgdx and TWL

libgdx comes with a build of TWL, the Themeable Widget Library. This library can be used to build user interfaces including components like buttons, scrolling text areas, lists, clickable image maps, and so on. It allows the programmer to theme elements in a manner similar to the CSS. Neat. libgdx’s TWL class uses the SpriteBatch class to render components to the screen.

In this example I’ll describe how to add buttons and text components to a layout, and how to detect clicks on the components. The result will be a simple click/tap counter. This write-up is based on the TWL tests found in the libgdx source tree.

Continue Reading >>

dAST 0.5

So, as I said earlier, I couldn’t help myself. I had to keep working on dAST. I’ve added a whole new control scheme, updated the main menu and game over screens, and added online tracking of scores. I’ve rejiggered the way the graphics are drawn on the screen and tuned the tick methods, both based on a lot of traceview analysis (profiling). I made a new game layout for large devices, but I’ve only been able to test it on the emulator.

The new control scheme is the most exciting update. Instead of having two “virtual joysticks”, the player can draw a path that the ship is to follow, and then fire from the ship while it is traveling. The further the ship travels along the path the larger the score multiplier goes. I received some early feedback (don’t yet have permission to reveal the name) suggesting this sort of control scheme and I’ve finally gotten around to implementing it. I think I like it quite a bit. It should work well on large format devices, but it works OK on phones, too. It has a couple of rough edges, but I think it’s at least ready for a wider “test” to find out what people think of it. As always, I’m collecting feedback (although sometimes it takes me a while to get to it, as was the case here, d’oh…)

Eclipse and the case of the missing R.java

When Eclipse won’t generate/locate R.java (Updated link)

I just recently ran in to an issue where my R.java file disappeared. R.java stopped updating and I thought that going to Project->Clean would resolve the problem, or at least give me a hint about what the problem was. Instead, it left me R-less.

I found the link above, which is helpful in that it gave me a hint that one or more of my XML files has an error, which makes some sense because I was working on one of the layout files at the time. Additionally, that may explain why R.java was not updating automatically.

However, all of the layout files were syntactically correct and removing the layout file I was working on was not sufficient to trigger the regeneration of R.java file. I tried exiting Eclipse to manually create a R.java file. This got me close; upon reopening Eclipse I got the error: “R.java was modified manually! Reverting to generated version!”. Unfortunately, Eclipse just left the new empty R.java in place. A similar result when I removed R.java while in Eclipse.

Finally, after a bunch of searching, I found out how to manually run aapt in order to generate the R.java file

cd $eclipse_workspace/project; aapt package -m -J src -M AndroidManifest.xml -S res -I $path_to_android.jar

and the result was an error displayed to stdout:

AndroidManifest.xml:22: error: Error: No resource found that matches the given name (at 'label' with value '@string/highscore_label').

I couldn’t guess why Eclipse did not put that error in the Error Log or its Console. Finally, the actual problem: I had removed a string that was being used by the AndroidManifest as a label for one of my activities. A pretty simple, stupid error, that Eclipse is apparently incapable of reporting. Well, I hope someone else benefits from this. Check your AndroidManifest.xml strings carefully, by hand.