Frozax Games' Development Blog

See the Trailer

Archive for the ‘programming’ Category

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 »

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 »

Box2D.XNA : a great 2D physics engine

Friday, February 5th, 2010

Box2D is a 2D physics engine created by Erin Catto. On Win/Mac, I used a very early version of Box2D (it was released nearly two years ago!). I just made a few specific changes for the game. Of course, as I told in a previous article, XNA games must be made in C# and Box2D is made in C++. I could find multiple open-source projects of ports of Box2D in C#. They are based on the last version of the C++ engine and a lot of changes occured since I developed Spring Up!. It means that to use a C# port, I have to adapt a lot of my physics code. But this is a good thing for the following reasons:

I will have the new version of the engine : there are probably some debug and optimisations.
New features : can be used to improve the game
Lots of C# code already written, I won’t have to port it myself.

Among the two or three C# ports available, I decided to go with Box2D.XNA. This port is written by Brandon and Nathan Furtwangler and they are doing a very good job! They are very active: when I fixed them a bug, they put it back in the code base in less than a day and they port the changes of the C++ version very quickly.
Compared to the old C++ engine I was using previously, the new version has been greatly improved, here are some examples:

Dynamic/Static/Kinetic types are included on bodies, no need to play with infinite mass directly.
Collision filtering is now included in the API. I developed my own system in Spring Up! but throw it away in C#.
Motors are included. I also developed basic motors myself in C++.
More joints types: only one type was available.
Collision detection includes polygons, not just only circles and rectangles.

As I’m still working with the level editor, I started to include new features in Spring Up! Here is a simple video showing a new possibility made with Box2D.XNA (showing motors, complex shapes, joints and collision detection).

As you can see, the gameplay does not seem that interesting in this sample but it’s just made to test the dynamics for now. I will concentrate on level design later and I am sure I will face a lot of difficulties.

In conclusion, if you need 2D physics in your game, use Box2D, and if it’s for XNA, use the Box2D.XNA port!

Tags: box2d, physics, video, XNA
Posted in Screenshots / Videos, XNA, programming, win/mac to x360 | 1 Comment »

Video : Level Editor

Tuesday, January 26th, 2010

I am mostly working on the level editor. I was not sure when I started this project that I would need a specific level editor. But Spring Up! X360 needs some serious changes in the level design to improve the quality and to adapt to the X360 platform, therefore I need this new level editor. Working on tools with C# is great : it’s really powerful and efficient! Technically speaking, the level editor is just a Game Component (DrawableGameComponent XNA class) of the Game. When the “Editor” component is created, all the new mouse and keyboard shortcuts are available.

As you can see in the video, here are some features implemented: create, move, rotate and delete items and targets. You can set up objects as static, dynamic or with a motor. There is also a snap feature. And as the game is running at the same time, you can play directly in the editor.

You can also see some of the new shapes that will be available in Spring Up! XNA : a triangle and pentagon.

That’s it for today, I hope you liked it!

Tags: level editor, spring up, video
Posted in Game Design, Screenshots / Videos, XNA, 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 »

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 »