Visual Studio 2008 64 Bit Issues

I’ve been running the XNA Unleashed examples using Visual Studio 2008 Standard, XNA Studio 3.2 on Windows 7 64-Bit.
One of the examples is a simple console application accessing functions from an XNA game library project. Every time I’ve run the project I’ve received a BadImageFormatException when the console tries to load the library.

Most of the MSDN blurb suggests changing the build type to x86. These 32 bit executables should run just fine using WOW64. But still the error appears. I haven’t found a definitive solution to this issue, but I have a suspicion it may be related to the XNA 3.2 libraries being used (or some issues surrounding unmanaged code – but XNA is managed?)

I’ve been sceptical about using some of the Express editions for extensive projects in the past as I’ve been unable to add additional projects to a solution (and working with code libraries with web projects has been a pain). Also VS2008 is a full edition with all the tools installed. I encounted the multiple projects issue in 2008, but there was a checkbox hidden in the options to show the solution file.

I downloaded VC# 2010 Express and haven’t had any issues. The solution is visible by default and allowed me to add a console application and a games library in the same project. The XNA 4.0 Game Library template was available after download, which was pretty nifty (typically in the past you’d have to reinstall the extension in order for the functionality to be visible – remember .NET 2.0 and lower being available in IIS?).

Also, the format of the XNA object framework hasn’t changed between 3.2 and 4.0 for the examples covered in the book which is great!

Performance Improvements

Another interesting titbit from the XNA book – when defining game structures, use the simplest types available. This facilitates less code generation and improves garbage collection.

When initially defining the structures at the Magee day, I completely forgot how to create an array of class objects (pretty simple in retrospect). Instead I used list collections. These are framework friendly objects which provide plumbing to allow you to easily add, find and remove list items.

I went back through the code and replaced these collections with simple class arrays. The FPS counter is now in the high 26s/low 27s consistently.

Fail!

I implemented the isDirty flag on the game squares and am getting a blank screen again. Back to the drawing board (or the XNA book).

Capturing Framerates

I’ve taken the framerate example from the XNA book and inserted it in the phone app. A couple of observations:

1) Debug.Writeline outputs to the Visual Studio output window.
2) Changing Window.Title compiles and runs but is not visible on the phone.
3) gametime only provides elapsed game time (not elapsed real time). In the XNA Windows example both properties were available, but displayed exactly the same time.

The frame rate wavers between 26/27/28 frames per second. This is OK (the human eye notices anything under 25 frames per second), but this does not provide a great deal of wiggle room with any additional logic. The next stage will be to add conditional sprite updates (discussed in a previous post). If the game square bitmap has not changed then it shouldn’t require a redraw.

A Step back…. XNA Unleashed

After fiddling with the sprite rotation issue for a while I came to the conclusion I didn’t know enough about the XNA environment to really tinker.

I have a copy of Microsoft XNA Studio 3.0 Unleashed by Chad Carter, and Visual Studio 2008 Standard with XNA Studio 3.1 installed. Just from reading the first three chapters I’ve picked up a few points that can help.

1) The update/draw cycle of the application is determined by the screen’s refresh rate. This prevents unwanted flicker. In order to measure the true frames per second, you can switch this setting off, and make measurements of the redraw based on the internal timers used by XNA.

2) The Systems.Diagnostics namespace provides a debug.WriteLine function to print debug messages to the screen (though any full blown XNA functions should be used with caution as the mobile application is running on the .NET compact framework – a subset of the full functionality available under the normal .NET doodah).

3) I’ve been trying to improve the performance of the TD app, by marking the game squares as dirty if they needed refreshing. If this boolean was false, they wouldn’t be drawn. This resulted in a blank screen. I was convinced this was due to the back buffer being empty when the next graphics update came along (therefore I needed to build the full screen). I found this snippet of code in the fullblown XNA project in the draw function:

GraphicsDevice.Clear(Color.CornflowerBlue);

This is called every time the screen draw function is called, and would explain why there’s a blank screen! The Windows Mobile 7 version also uses cornflowerblue (Fight Club, anyone?). I’ll check the mobile app to see if this is also the case. If I don’t redraw all the sprites I’m sure the enemy will move quicker. Alternatively, I can increase their stepping to 2 or more (instead of the current 1). My only issue with this would be checking the coordinates of the enemy against path end. When the step is 1, the enemy will eventually increment/decrement onto the correct co-ordinate. With multiple stepping two things could occur:

1) The increment could exceed the path end and the check might not be robust to check for greater than!
2) The increment could exceed the path, and the adjustment to the coordinates will result in an ugly visual step to put the enemy back on the path. Some experimentation required!

Sprite Rotation

OK, time to get up to speed. I’ve left out a lot of technical details about how I’ve got here – mainly because it would take almost a week to discuss My current problem is getting gun turrets to rotate. As I said in a previous post, the spriteBatch.Draw function provides an overloaded method for rotating sprites before they’re drawn.

http://msdn.microsoft.com/en-us/library/ff433988.aspx

Unfortunately, my sprites seem to be rotating around the board The problem may be around the origin of the rotation. I aim to investigate this by temporarily drawing a red dot where the origin is based. Ideally, I’d like the origin to be the centre of the bitmap position, allowing it to rotate in position.

 

 

 

Data Structures

The game currently includes the following data structures:

• A collection of game squares. Each square has a number of properties describing its current state – isPath, isHighlighted, isSelected, Position, hasTurret and RotationAngle.
• A collection of Enemies – Position, Health and Pathsection.
• A collection of Enemy Paths – PathSection and PathEnd.
• GameState – a class containing the collections above, the list of textures and game logic functions.

isPath – A boolean property determines if the game square is a part of the path. During the draw cycle, if isPath is set to false, a bitmap is used to draw the square, otherwise it is left blank.

hasTurret – As stated above, a bitmap is associated with the game square if it is not a path. hasTurret is a boolean variable, and indicates the user has selected a gun turret to be placed on the square. A turret bitmap is drawn on the square if true.

isHighlighted/isSelected – if the user touches a square with their finger, the square’s isHighlighted flag is set. This square is then drawn with the red bitmap. If the user touches the square again, the square isSelected, and it is assumed a gun turret is being placed on that square. At a later stage, I’ll be changing this logic to include a purchase turret button.

Position – Position is used in a number of structures to determine where the object should be drawn. Position is represented as a Vector2D structure – an XNA data type which holds two float values, x and y.

RotationAngle – Static turrets don’t look very convincing. As the enemies pass the turrets, they should swing round to face them. The spriteBatch.Draw XNA method provides an overload which allows the drawn image to be rotated. I’ll talk about this in a later post.

Health – determines the state of an enemy. Will start at 100, and decrease as shots from the turret hit the enemy. As the enemies are enhanced, it will be possible for them to have more health points. At this stage, I’m looking at a simple prototype.

PathSection – This is used in two places, enemypath and enemy. The enemypath structure has an integer pathsection, and a vector2D pathend. The purpose of these two values is to provide a sequence for the enemies to follow. On each draw cycle, the enemy’s path section will be checked. Initially this will be set to 1. In the enemypath structure, the coordinates of the first turn in the path will be associated with the pathsection of 1. The coordinates of the path end and the enemy’s position are compared, and the enemy’s x or y position coordinates will be decremented/incremented as appropriate. There will be no diagonal movement (x and y changing together) as the path is drawn across the x and y axes. When the enemy’s position is identical to the path’s end coordinates, the enemy’s pathsection is incremented. On our test level there are 4 path sections representing each turn in the path.

Gamestate – This class keeps track of the game logic, and creates instances of the required objects. This class, and some of the underlying data structures, are coupled to the XNA framework through the passing of XNA specific types. Functions such as Draw require SpriteBatch objects, and some of the position variables are stored as Vector2D. At a later point, I’ll try to loosen this up a bit. If this game is to port to other platforms, the XNA specific code will have to be replaced. Using a layered strategy, like in MVC would be a sensible option, separating the code logic from the platform implementation.