Frozax Games' Development Blog

Posts Tagged ‘porting’

Android Game Development with libGDX

Tuesday, September 27th, 2011

After selling games on PC, Mac and Xbox 360, I want to develop games on mobile plaforms, and I will start with Android. I chose Android instead of iPhone for two reasons:

It’s cheaper: my Mac is a PowerPC and you need a Mac Intel for iPhone development. Also Android phones are cheaper than iPhones.
Java is similar to C# : I have C# games ready to be ported to mobile. As Android uses Java, it’s a great platform for me to port those games.

My last X360 game, Don’t Feed the Trolls is a great fit for mobile: quick gameplay sessions and not requiring too much processing power or memory. I therefore decided to port it to Android.

I started to look for available 2D game libraries on Android and after hesitating between AndEngine and libGDX, I chose libGDX. I will describe here some features and my thoughts about this library.

What I like

Complete API

It’s a simple but complete API. We often see libraries with only rendering support, but with libGDX, you can do rendering (2D and 3D), audio, file management and input (touchscreens). There are also a few useful utility classes and tools (more on this below).

Box2D

There is also a port of Box2D, the physics library used in Spring Up Harmony (PC, X360). If I ever want to port Spring Up Harmony to Android (probably), the physics part should be easily portable.

Open Source

I like to have access to the source code of libraries I use. I find it reassuring and when debugging, it’s good to be able to step into libraries source code.

Activity

There is currently quite a lot of updates and bug fixes, by the creator of the lib (Mario Zechner) and by community.

Bitmap Fonts

There is a tool available to create bitmap fonts. This is very similar to the tool I used on XNA (SpriteFont2 Texture Tool) so porting my existing code was very easy.

Desktop Version

If you ever used the Android Emulator of the SDK, you are probably aware that it’s terribly slow and not really usable. I didn’t buy my Android Device yet, but can still work on the game and test it properly because libgdx also compiles for desktop java.

Don't Feed the Trolls for Android running with the Desktop version of libGDX

Texture Packer

This is another great tool, used to pack many textures in one. I usually don’t care much about texture size and texture memory waste when developing on X360 but this is important on mobile devices due to their limitations. Some features of this tool:

Grouping small textures in textures pages (power of two).
Strip transparent pixels on the borders of textures. This required quite some tweaks and update in my own fgDrawSprite class and rendering functions to manage properly, but this is really a great way to save memory and disk space.
Has an incremental option to avoid generating everything when updating only some resources.
Can be called from the game itself in the desktop version. A good practice is to automatically call the packer in the desktop version, and use the generated assets in both Desktop and Android.

This is really a time saver tool.

What I don’t like

Lack of documentation

There is no good and centralized documentation. You need to look for information on the forums, in the source code and/or on blog articles. Due to the activity of the library, I sometimes find out that I’m using old stuff that is not supposed to be used, because it’s deprecated and has been replaced by something else. The parameters of some API functions are not always properly documented too. For instance, I had trouble using a rendering function and found out that the rotation parameter was an angle in degrees (it’s usually in radians in the libraries I used before).

Reverted Y-Axis

I found this very strange but in all the 2D APIs I used, the coordinate system used the point (0,0) as the top-left corner, with X going right and Y going down. In libgdx, the Y axis is going up, and the 0,0 is bottom-left. I had to change some rendering functions to take this into account.

Android Specific

Doing Android specific code is not very clean because the lib is supposed to work on desktop and Android. I guess this is also because of Java, and I wished we could have some preprocessing to condition Android specific code. There are many workarounds, because the Android application overloads the Desktop application. So you can create empty methods on Desktop that are overloaded only in the Android project with Android specific code. I hope this won’t get too messy when I’ll work on very specific and touchy stuff such as in-app purchases.

What I don’t know

Performance

I don’t own an Android device yet and did not test other API, so I can’t really talk about the performance of the API. According to users, it is faster than most other APIs.

Conclusion

Using libGDX is a good and easy way to start developing Android games. For now, I’m happy with this library and you can see on the screenshot above that development is going well. I will probably release a few games with it.

If you tested different Android libs or have anything to add, feel free to comment about it.

You can find out more about Frozax Games or me on twitter, facebook or g+.

Tags: Android, libgdx, porting, programming
Posted in Android, Don't Feed the Trolls, programming | 3 Comments »

First Run on Xbox 360 : Problems and Solutions

Friday, April 2nd, 2010

I decided about a month ago to start working on the Xbox 360 version of Spring Up in April. I think it can be interesting to share my experience about that.

Part 1 : XNA Creator Membership

Basically, you just need to pay creator membership (99 € for one year in Europe), launch XNA Game Studio Connect on your console and that’s it.

Problem 1 : You have problems to redeem your XNA account to a new X360 profile?

Solution 1 : Do not mix up your forum name and GamerTag. Yes, this one was easy but it took me at least 30 minutes to find out what was happening.

Problem 2 : XNA Game Studio Connect does not recognize your account as premium when you launch it even though you paid for membership?

Solution 2 : You have to wait for some time (a few hours, maybe half a day) and everything will be fine. Quite frustrating, I know.

Part 2 : Compiling your game for Xbox 360

Microsoft made something simple : just right click on your project in Visual C# and choose “Create copy of Project for Xbox 360″. I took my main project and all the dependencies were converted too.

Problem 3 : You have very strange compiling errors? When converting Box2D.XNA, I had weird errors such as “Class C does not implement inherited abstract member M” AND “no suitable method found to override M”.

Solution 3 : Make sure you use the proper version of assemblies. I don’t know why but the converter put assemblies of XNA 3.0 instead of 3.1. Using 3.1 assemblies fixed my problem.

Problem 4 : The code does not compile but it works fine on Windows?

Solution 4 : Make sure you do not use windows specific code. You will be able to see warning icons if you have invalid assemblies in your Xbox 360 projects. If you want to keep windows specific code, just use #if WINDOWS / #endif so that it compiles properly on Xbox 360. In my case, my level and dialog box editors are only available on windows because it needs to create XML files.

Problem 5 : You can’t build your XNB data from XML using your own classes?

Solution 5 : Make sure the Content projects still have references to windows builds. Resources are built on the development computer, using the windows assemblies.

Part 3 : Running the Game on Xbox 360

Problem 6 : Code 3 Error?

Solution 6 : When you have Code X errors, it is because the console hangs without being able to break or throw an exception to the debugger. To track this problem, I simply traced the code I suspected. As the problem happened on a specific action, I could easily see where was the problem. My problem was just a null pointer access that happens only when there is no savegame. I always have a savegame on PC, so I did not see the problem before. The strange fact is that when I traced the code the second time, I properly had the NullPointerException.

Problem 7 : Your game is slow?

Solution 7 : I knew Xbox 360’s are usually slower than PCx with XNA but I was still very surprised my I ran my game for the first time. I immediatly launched a release build to try to reassure myselft but it’s still quite slow. I am not sure what is the problem for now so I will improve my profiling code to see which GameComponent is the problem.

Conclusion

That’s it for my first run on X360. I hoped this helped some of you!

Tags: content pipeline, performance, porting, problems, Xbox 360, XNA, xna game studio connect
Posted in XNA, Xbox 360, programming, win/mac to x360 | No Comments »

Win/Mac and X360 differences (3) : XNA Content Pipeline

Wednesday, January 13th, 2010

In this post, I’ll talk about the XNA Content Pipeline. When I first tried to load a resource in the XNA game, I was trying to do as usual : opening a file and reading it using standard file reading functions. However, on XNA you have to use the Content Pipeline provided and to be honest, they have made a very good work with that. This pipeline can load some known file formats (jpg textures or wav sounds for instance) but you can extend the pipeline for your own custom formats.

I used many different types of file format for Spring Up!, for instance:

TGA for 32b images (I used TGA because it’s a very simple file format)
SWF for menus, level description and physics definition (ShockWave Flash, using the gameswf library)
WAV for sounds
OGG for music
Custom text files for translated texts and particle definition (called RSC and PRT)
Custom binary files for various data (DAT files).

The XNA Content Pipeline is really integrated into your XNA game project. You just add the resource to your project and when you compile it, the data is imported and converted in a XNB (XNA Binary File) using a Content Importer. This XNB file is generated for the right platform. It means you do not have to bother about little/big endian of the platform (Windows or X360). Once the resource is in your project, you create game objects with only one line of code. For instance, you can add a texture file to your project, and then load it using the following code:

Texture2D my_texture = Content.Load<Texture2D>("texture");

There are many file formats handled by XNA but when using specific data, you have to develop your own custom Content Importer. As told in a previous article, I will not port gameswf for many reasons so all the data I have in SWF files has to be included in another way into the X360 game. I started to include one of the most important data : the definitions of the levels. To do this on X360, I developed a quick XML exporter in the PC version of Spring Up! Then, I read the XML with my custom Content Importer. The XNA Game Studio then generates the XNB. The following diagram shows the flow of the data:

: Levels data flow in Spring Up!

Now that my importer is in place, I can read a level definition using the following code:

LevelDef level = Content.Load<LevelDef>("level01");

And that’s it!

I have three importers already in place in the current version:

Sprite : binary format containing position and size of a sprite in a texture page. It was my first importer using XNA. It could (should?) have been XML. Original PC data was in the SWF, it is exported in binary from the PC game.
Level : position and type of items of the levels of the game. Original PC data was in the SWF, it is exported in xml from the PC game.
Physics : the definition of the physics properties of the items (size, shape, mass). This one is not completed yet, I still have pivots and joints to include. Original PC data was in the SWF (in actionscript code), it is exported in XML from the PC game, too.

If I knew from the beginning that the game would be developed on XNA, I would have done differently. The fact that I’m porting an existing product made me choose this solution of creating the exporters on PC and reimporting the data in XNA Game Studio. Ideally; I would have createed a level editor (with a Windows XNA project probably) saving data in XML. Then I’d use the content importer to put the resource in the XNA game and read directly the XML for a PC/Mac game (see diagram below).

: Possibility for a multi-platform PC/Mac/X360 project

As I plan to improve greatly the game, it is still possible that I will develop a specific level editor to be able to create new types of objects and physics items.

That’s it for my basic introduction to the XNA Content Pipeline. If you have any questions about the use of the pipeline, about importers or anything else, feel free to ask in the comments section below!

Tags: content pipeline, porting, programming, resource, spring up, XNA
Posted in XNA, programming, win/mac to x360 | 1 Comment »

Win/Mac and X360 differences (2) : Screen resolution and aspect ratio

Monday, January 4th, 2010

The second “Win/Mac and X360 differences” post is about the aspect ratio and resolutions of the screen. This may not apply to all games as more and more casual games nowadays can be played on multiple resolutions included the X360 ones. However, I decided to write a post about it because that’s a problem I am facing at the moment.

Most PC/Mac casual games are only developed for a 4:3 resolution (640×480, 800×600 or 1024×768 generally). However, on X360, resolutions are mostly 16:9. In fact, the 1280×720 resolution is recommended by the XNA developers to ensure the game works on every video adapters. Spring Up’s resolution on computers is 800×600, and it will be 1280×720 on XNA, as shown on the first screenshot revealed last month.

Of course, there is a difference in the number of pixels, but the biggest problem is the aspect ratio (from 4:3 to 16:9). The following picture illustrates the problem.

: aspect ratio differences

The blue sections represent the X360 screens and the green sections represent the PC screens. The first illustration shows how the 800×600 screen fits in the 1280×720 screen without any change of resolution. That’s the easiest way to do and what I did for the first screenshot of the game. Basically, you don’t change anything, you just render your game in the center of the X360 screen.

On the second illustration, the PC screen is enlarged so that it fits with the height of the X360 one. This is a 1.2 scale that transforms the PC screen in 960×720. You can see there are blue portions on the sides. That’s what Peggle did (see XBLA screenshot). They just added some (useless?) stuff on the sides to fill the gaps.

There is a third solution that scales the PC screen so that the left/right borders match with the 1280 width of X360. This is a 1.6 scale. In this case, some pixels are lost on the top and bottom if you keep the 4:3 aspect ratio.

I do not want to scale the objects of the game (balls, fans, launcher…) because I prefer pixel perfect sprites (one pixel of the texture is exactly one pixel on the screen). Consequently, in Spring Up!, I will probably move the items that compose the levels so that I take up more space on the screen. A good point to this solution is that it will contribute to correct one problem of the game stated earlier: objects will less likely be stuck due to extra spacing between targets.
I will also tweak the level design to “fill the blanks”, mostly on the left and right sides.
As the background is made up of tiles of 100×100 pixels, I just have to draw more tiles so that’s not a problem.
The walls will of course need to be moved to the sides of the screen.

Another detail that sometimes bother people that don’t think about it right from the beginning is the “title safe frame”. On X360, it is required that every important instruction on screen is displayed in the inner 80% of the screen. In 1280×720, that is 1024×576. On Win/Mac, I have many important information on the borders of the screen (bonus bar, score, level). I will need to change game design here to pass this requirement. I keep that in a corner of my head for the moment and will decide how to do it when working on the UI.

That’s it for resolution and aspect ratio, feel free to comment!

And happy new year!

Tags: aspect ratio, porting, resolution, safe frame, screen, spring up, XNA
Posted in Game Design, XNA, win/mac to x360 | No Comments »

First Screenshot of Spring Up! on XNA

Tuesday, December 22nd, 2009

Here is the first screenshot of Spring Up! XNA. It was made using a windows build of the XNA project.

: Click to Enlarge

This screenshot was taken two days ago, just before starting to work on the game and physics code. Here, the rendering components and textures are properly imported to XNA. Background generation is using RenderToTexture (it was a software generation of a texture in Win/Mac). Game items are properly displayed, with the launcher and receiver in place. It is clear that I will have to make choices to handle the difference of resolution (from 800×600 to 1280×720).

So this was quite fast, and I don’t think I will have much trouble with the game specific code. However, I am already having difficulties with the physics part. And with Christmas coming very soon, I will probably not spend a lot of time working.

If you have any questions/remarks, feel free to comment!

Tags: porting, screenshot, spring up, XNA
Posted in XNA, programming, win/mac to x360 | 1 Comment »