Frozax Games' Development Blog

Posts Tagged ‘programming’

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 »

3 Simple Tips to Avoid Memory Allocations with XNA/C#

Friday, May 21st, 2010

Long time without posting. I’ve spent a lot of time working on the game, contracting art, buying sound effect and music assets, designing the levels… New screenshots/video should come very soon.

Anyway, back on topic: when developing from C++ to C#, I found out very strange that you can allocate memory but you cannot free it and have to let the garbage collector do it. But I finally got quickly used to it and found it quite handy… Until I found out that garbage collection is not free and usually causes framerate drops, especially on X360.

Using the CLR Profiler (screenshot above), you can easily see where you are wasting memory (well, it can be scary the first time you see it but in fact, it’s easy). I nearly removed all my runtime allocations with this tool, here are the few tips that can be useful:

1. Be careful with the class string

String is allocating memory every time it returns a new string. StringBuilder is the key to the problem. I didn’t even know what StringBuilder was before working on memory and now I use it everywhere I need to take care about memory. There are some awesome tips (and source code) about StringBuilder on Gavin Pugh’ blog. Especially this and this. You have everything you need now

2. Reuse your lists

I had multiple sections of code creating a temporary List<> in order to add elements to need a special treatment. This was in an update function in my case. It is handy and fast to write code like that, but it allocates memory. To fix this, I know have the List<> as a member of the class. I clear it and reuse it when needed. When creating a list, you should use the constructor with an int used to define the default capacity of the list. (List<Vector2> l = new List<Vector2>(64) for instance).

3. foreach loops

I converted my foreach loops in C++ like for loops and it saved me some allocations. Memory allocated due to foreach loops on lists is showing up in the CLR Profiler as System.Collections.Generic.List<T>.

Conclusion

I hope you’ll find this useful. In Spring Up Harmony, I still have some run-time allocations, mostly in the particle engine, when a new fx is launched (I use Mercury for now). However, it seems that the garbage collector is not causing hick-ups therefore I’m ok with it.

Tags: memory, performance, profiling, programming, XNA
Posted in XNA, profiling, programming | No Comments »

Yes, multi-threading in XNA/C# can be that simple!

Wednesday, April 14th, 2010

I never really liked multi-threading, because of all the additional problems it creates: synchronization, deadlocks, concurrent access to memory… But with my recent experience with multi-threading in XNA/C#, you can really do simple and efficient optimizations.

While looking for possible performance improvements in Spring Up Harmony for Xbox 360 (PC), I have seen a simple situation really suited for multi-threading. You can see that situation with the following screenshot of my in-game profiler (click to enlarge):

I have two tasks with performance issues since I started to run the game on Xbox 360 : the dynamics of the background effect and the computation of the estimation of the launch of the ball (running a simplified physics simulation multiple times, through Box2D.XNA). On this screenshot, these tasks are called VelGrid.U(9) and Launchers.U(14). The first part of VelGrid.U (Comp.Balls,10) uses the data of the physics simulation but DynaColLines(11) doesn’t. Therefore, the VelGrid.DynaColLines and Launchers.U are totally independent with each others. No data is shared between these code sections. Perfect candidates for my initiation to multi-threading in XNA!

The e-book found here (recommended in multiple threading articles) is really awesome and helped me find the algorithm I need to use. I want to start the Launchers.U at the same time than VelGrid.DynaColLines and wait until both are finished. I know this is not optimal, but it allows me to simplify the problem and avoid so many threading pitfalls.

I just have to use two AutoResetEvents. The Launchers.U section is created in a thread and waits for a “Go” signal from VelGrid. After doing its job, it sets a Ready signal so that VelGrid knows when to carry on after doing its own stuff. Two different cases can happen, depending on which section finishes before the other.

Here are screenshots of the in-game profiler showing the differences (taken on X360). Every code section prefixed by a * means it’s executed on the thread.

Case 1 : The code on the main thread completed before the code on the worker thread:

The Velgrid section has to wait for the Launchers to complete, shown with the red arrow.

Case 2 : the code on the main thread completed after the code on the worker thread:

The thread is idle while the main thread still works (red arrow).

With this simple threading mechanism (coded and tested in a few hours only), I have been able to optimize the game. In the basic test level shown here, instead of 2.3 + 3.1 = 5.4 milliseconds spent on the main thread for both features, the game now spends 3.6 milliseconds, running two threads at the same time (33% gain). In this test scene, the Velgrid.DynaColLines is “free”.

Since I took these screenshots, I have made a few more changes : now, the whole Box2D update used while the game is in motion is threaded too.

Last important thing to know, on Xbox 360, you must choose which core to use for your thread. Just read the msdn page about the SetProcessorAffinity, everything you need to know is here. You can see in this article that I still have a few cores available

In conclusion, if you have independent sections of code that take some time to run, you can improve that very quickly using this method.

Tags: multi-threading, onscreen, performance, profiling, programming, screenshot, Xbox 360, XNA
Posted in Screenshots / Videos, XNA, Xbox 360, profiling, programming, spring up harmony | 4 Comments »

On-screen profiling for XNA

Wednesday, April 7th, 2010

A few days ago, I read an article called Among Friends: How Naughty Dog Built Uncharted 2. The interesting screenshots on the third page gave me the urge to create what I call an “on-screen profiling” tool for Spring Up XNA. I talked before about profilers and how to use them to find which sections of your code need to be optimized. But a visual tool is really handy, because it’s real time, and with Edit and Continue on PC, you can even see your improvements live!

So, I spend some time working on it, and here is a sample screenshot (click to enlarge):

The bars show the timeline of the current frame. In the bars, there is the name of the section. For clarity, all profiled sections are also displayed in plain text with the following informations: Name, Time elapsed this frame (in millisecond), smooth time elapsed, percentage of the 60 fps frame (16.6 ms). The vertical magenta line is the limit of the 60 fps frame. On this screenshot, my objective of 60 fps is not met, there are some bars displayed after it

I am really happy with the results, you instantly see where optimization is needed and you also see the results quickly. For instance, after seeing the previous screenshot, I concentrated on the “Velgrid.D” section (section drawing the background effect that is seen in motion here). After some improvement, it still was not fast enough. I noticed that the problem was simply the overhead of calling SpriteBatch.Draw more than 5000 times. I therefore decided to write my own vertex+pixel shaders and you can see the result here:

It’s now so fast that we can’t even see the name of the section in the bars and I have to have a look at the list to see the exact time taken by this section of the game (number 15).

The profiling works obviously on both Xbox 360 and PC so I could compare both hardware. As I could read here and there, the X360 build is much slower than the Windows one. I made two screenshots of the same scene with a scale of the bars so that the length in pixels of the full frame is around the same on each platform. Here is the screenshot of the windows build that you can compare to the first screenshot of this post:

The “slower” sections are not the same. Globally, the X360 is better at using its GPU and the PC using its CPU. Of course, this is heavily dependant on the PC platform. For information, I am using a 3.4 GHz computer with a X850 graphics card.

And just for fun , the first screenshot of the profiler on X360, before I started any optimizations:

The frame took 165% of my objective target frame (60 fps). I can’t even see it all on screen. I am now at 75% of the frame, and with an additional feature (glow around objects, section 9 on the second screenshot).

So the small amount time taken to make this in-game tool is very well spent. It’s obviously quicker than running a profiler and waiting for the results, even if it’s not as precise. And the great thing is that this was easy and interesting to program

Tags: fps, framerate, onscreen, performance, profiling, programming, screenshot, Xbox 360, XNA
Posted in Screenshots / Videos, XNA, Xbox 360, profiling, programming | 3 Comments »

Backup your work with ease

Tuesday, March 23rd, 2010

We all agree that doing backups is really important to prevent dramatic data losses. I have always been pretty lazy about that topic and usually rarely backup anything, or not very often. I think the problem was that I didn’t find easy ways to do it. For my current project, I do backups nearly everyday and thats not taking much time, if any. Here is what I do:

Source code : Perforce

It’s not really “backup” but I think it’s important to use proper source control to save your code. Having the history of the code is a wonderful feature. I especially like what is called Time-lapse view in Perforce because you can see instantly when was added a specific (buggy) line of code.

Most people go with Subversion (SVN) but I chose Perforce and I really like it. It is free only for two or less users so it may not suits you if you have a big team. It is very easy to set up, I usually run both the server and the client on the same computer. I use my iBook to connect to the server when doing Mac ports.

Perforce can also be used for resources but I don’t do it because having different revisions for resources takes up a lot of disk space.

Resources : SyncBack

Even if I am not using real source control for resources, I backup my resources using SyncBack Freeware. In my current setup, it creates a zip file of my root project directory. To save space, I use filters. For example, I do not backup intermediate files made by the compiler or EXE files because they can be built from the source. Same for graphics file, I keep the original resource but don’t save the final png files. About every two or three weeks, I rename my backup with the date of the day and I keep two or three versions of resources.

SyncBack is very easy to use and there are also more complete SE and Pro version (shareware).

Online backup : DropBox

dropbox In addition to a local save on another drive in case of a disk crash, it is also important to keep your backups off-site, just in case. First, I used a feature in SyncBack that sent the backup to a FTP. But I now use DropBox, an online service that automatically synchronize a folder on your hard drive with an online storage. All you have to do is to set up SyncBack so that the final zip ends up in the folder you synchronize with dropbox. A few minutes later, it is up-to-date online, on a safe and distant server.

DropBox allows you to have multiple users and private folders but I didn’t try yet. However, I plan on using Dropbox for my future works with art and audio contractors if possible. The free service of DropBox is limited to 2 Gb. There is a paying service and a referral program to get more space. If you plan to subscribe, please use this link so that I can get a 250 Mb bonus!

Conclusion

Doing backups is useful only if you do it automatically or at least very regularly. The tools presented here really allows you to do that. Do you use these softwares too? Do you use even better tools?

Tags: backup, dropbox, perforce, programming, syncback
Posted in programming | 1 Comment »

Measuring game performance : framerate is not everything

Thursday, March 11th, 2010

I am currently having a few problems with performance in Spring Up XNA. I have two features that are too expensive in processing power : the background effect and the computation of the preview trajectory of the ball.

I know these features are not usable at this cost because as soon as I activate one of them, my framerate drops and the game does not run at 60 FPS. When your game runs at 60 FPS, everything’s fine. When it does not, how can you tell how “far” you are from it. And because XNA is trying to catch up when your game is slow, this is even more obscure (there is a very good article on Shawn Hargreaves Blog about this topic called Understanding GameTime).

fps Therefore, in order to have accurate and useful performance information in real-time , I am displaying on screen the time spent to compute and draw the last frame, in milliseconds.

This is done easily using the Stopwatch class. This class is standard C# system library, it is not part of XNA. It is very easy to use:

stopwatch.Reset();
stopwatch.Start();
// Code to time here
stopwatch.Stop();

You just have to time the whole Update and Draw functions. Then you can read the number of milliseconds directly in the ElapsedMilliseconds member of Stopwatch. However, as this value is a long type, I prefer to compute the number of millisecond more precisely using this code:

(float)StopwatchUpdate.ElapsedTicks/(float)Stopwatch.Frequency*1000.0f

And to display it properly, I use the following formatting:

string fps = string.Format( "fps:   {0:00.0}\nupdate:{1,4:00.0}\n
draw:  {2,4:00.0}", _fps,
(float)StopwatchUpdate.ElapsedTicks/(float)Stopwatch.Frequency*1000.0f,
(float)StopwatchDraw.ElapsedTicks/(float)Stopwatch.Frequency*1000.0f );

I first thought that the numbers would change so quickly that it would not be usable but it’s pretty constant in my game. I can see huge differences when disabling some GameComponents. It is also useful to see if you spend more time in the update part or the draw part. You must have separated game logic and rendering properly, of course.

I told before in this blog that you must not spend time optimizing when you do not need too. But having this few lines of code is harmless and can be useful while adding new features:

If you see that you spend 5 more milliseconds in this session than in your previous one, you may need to have a closer look at this new code.
As Spring Up XNA is heavily using dynamics (through BOX2D), I can also compare the performance of the different levels.
You can see when a single frame takes much longer to update/draw (choppy framerate).

Hope this helps!

Tags: fps, framerate, performance, programming, XNA
Posted in XNA, profiling, programming | No Comments »

NProf : A Simple, Efficient and Free XNA Profiler (3.1 and 4.0)

Sunday, February 14th, 2010

Update: I have many visitors coming here from search engines. So here is a quick update if you want to use NProf with XNA 4.0. When you run NProf with your game, if the UI of NProf stays empty after running your game, it’s because you are running a XNA 4.0 game. There is a workaround here: Run NProf.exe with a .bat containing:

set COMPLUS_ProfAPI_ProfilerCompatibilitySetting=EnableV2Profiler
NProf.exe

Original post:

On its google code page, NProf is described as a statistical profiler for .NET applications. Good news: XNA being .NET, it can be used to profile games.

It’s well known that in order to optimize, you first need to find what part of your code is slow. That’s where a profiler comes handy, it finds the bottlenecks of your game and then you can optimize what needs to be.

The title of the post says it all, NProf is trivial to use, efficient and free. Once you download it, you select your XNA game executable, play it for some time and that’s it! I spent some time trying to find great profilers when I developed for PC and Mac but could not find anything really usable and affordable. I finally timed critical code sections with custom code and studied the log manually. Fortunately, NProf does all that for me in XNA.

I had a few surprises when I ran NProf. For instance, yesterday I could see that 21% of the game was spent in one method:
Color.Color( Vector3 )

This XNA constructor converts a Vector3 in a Color and it is called a lot in my game to create my background effect (see an old version in motion here). In this constructor, the expensive call is PackUtils.ClampAndRound. I do not have access to this code, but I can use another basic constructor and do the conversion myself. Here is what I ended up doing:

Before

Color col = new Color( vColor +
    new Vector3( start_val, start_val, start_val ) );

After

int r = (int)(( vColor.X + start_val) * 255 );
int g = (int)(( vColor.Y + start_val) * 255 );
int b = (int)(( vColor.Z + start_val) * 255 );
Color col = new Color( ( r > 255 ) ? (byte)255 : (byte)r,
    ( g > 255 ) ? (byte)255 : (byte)g,
    ( b > 255 ) ? (byte)255 : (byte)b );

The new code doesn’t clamp values below zero but I don’t need that feature. The really important thing is that it is now more than 12 times faster than before!

Without NProf, I would not have guessed that this constructor was that critical.

The main problem I see with NProf is that it only profiles your game on Windows and bottlenecks may be different on the X360.

Anyway, I really advise you to run your game in this profiler before you optimise anything. Be sure to use a release build.

Feel free to share your experiences with NProf!

Tags: nprof, profiling, programming
Posted in XNA, profiling, programming | 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 (1) : C++ and C#

Monday, December 28th, 2009

I will write a series of posts about the differences in developing for Windows (or Mac) and working for X360 with XNA Game Studio.

The first post of these series is about the most obvious difference : the programming language.

code

All my PC and Mac games were developed in C++ because that’s the language I’m most efficient with. I developed in C++ for years. Retail X360 games are mainly developed in C++ too, but to work with XNA Game Studio, you have to use C# and the XNA Framework. C# was new to me, but it’s easy to learn when you know other objects-oriented languages.

XNA Framework is also offering a lot of interesting libraries to help develop games. For instance, here are a few libraries I used on PC and Mac that are provided by the XNA Framework:

2D rendering : I used Popcap framework (Win) and SDL (Mac). XNA provides easy ways to draw sprites using the SpriteBatch class.
Audio : I tried Audiere in my first Windows games and now I use SDL_Mixer (Win and Mac). XNA uses SoundEffect and Song classes.
Game management : I used in-house code, XNA provides various helping classes (Game and GameComponent for instance).
Math : I developed my own functions in C++, XNA has all you need (2D/3D Vectors, Matrices…).
Input : I used specific Win32 and Mac functions in C++. Once again, XNA provides easy classes to deal with input (Keyboard, Mouse and GamePad classes). Of course, inputs are different on computers and X360 console. More on this later

But there is still many code to rewrite when porting the game. For Spring Up! there is obviously all the game code, and the physics engine. I am also using gameswf (a flash library) to draw all the UI of the game in Win/Mac. I won’t try to port it to X360 for two reasons : 1) it’s a lot of work, and 2) the UI I made with gameswf must be used with keyboard/mouse. I will probably have to write specific UI code for X360.

C++ code that is not platform specific (like game code or even the physics engine) is quite easy to port. Here are the few adaptations I have to make:

No pointer in C# (well, except unsafe mode but I don’t use that). Basically, it just means removing *’s
No delete. You have to trust the garbage collector. For now, it’s working smoothly but I’ve read some people are having troubles with that.
No include files : that’s awesome! One file only per class is handy.
No STL (even though I don’t use them much) : C# lists are very handy, better than STL and the syntax is also easier to read.

When I have big functions to port, I basically copy and paste the code from C++ to the C# editor, and modify what needs to be modified. Quick and easy. So far, it went pretty smoothly.

Feel free to comment!

Tags: programming, spring up, XNA
Posted in XNA, programming, win/mac to x360 | 2 Comments »