By request, here is the port of the old Dynamic 2D Shadows sample to XNA 4.0, on Windows Phone 7.
There may be performance improvements that could be done. I just took the old code, made the changes so it runs on WP7, and added touch input.
So you want to make a landscape game, or a game that supports both portrait and landscape mode in your Direct3D game for Windows Phone 8… I had quite a few requests for such a sample, and documentation out there is really, really scarce for this subject. I spend a few days looking at what was available for Windows 8 apps and managed to convert and adapt that to Windows Phone 8 too.
In Windows Phone 7, with XNA, this was automatically handled for you. You just needed to specify what orientation you want and create a backbuffer of correct size, and everything else (rendering, input) just worked. In Windows 8 apps, you have two options: you can let the system automatically rotate the image for you, or use the more optimal method of doing the rotation yourself and using the IDXGISwapChain1::SetRotation method to tell the OS that you did this manually. But for performance reasons, the option of automatic rotation is not available on Windows Phone 8, so we’re stuck with having to manually take care of everything: rotating stuff before we draw them, and processing input values to fit them to the new orientation. There are several things that we need to do in order to support other orientations besides the default Portrait one.
The first things to do will be to specify what orientations you want to support, and then respond whenever the orientation changes.
Go to your IFrameworkView implementation (normally ProjectName.cpp), and navigate to the SetWindow method. This will be called when the window for the app is ready, and the app can subscribe to windows events, and do whatever other configurations it might want.
To specify what orientations your app supports, you can set the values of the DisplayProperties::AutoRotationPreferences property. By default, this is set to only support Portrait. To be able to react when the orientation changes, you’ll need to also subscribe to the OrientationChanged event.
There’s a list of Best of 2012 with Xbox Games on Windows Phone up on Xbox.com, and I’m really happy to say that Chickens Can’t Fly is one of them!
You can get the game from the Windows Phone Store here:
Working on a sample regarding Orientation in a Direct3D app on Windows Phone 8, I came upon the need to clarify why I’m writing some math code in a specific way.
Coming from XNA to C++/DirectX11 might occasionally be confusing. Once source of that confusion can be in ‘when’ and ‘how’ matrices are used, namely row major vs column major representations and row-vector vs column-vector mathematics. Shortly, in a row major representation, the matrix is represented as an array of rows in memory; while in the column major, the matrix in represented as an array of columns in memory. There’s also the difference between row-vector math and column-vector math, which affects how transformation matrices are represented, and the correct order in which various operations should be made. For more details on the mathematical aspects, see this and this. A nice analysis of all these four aspects, which I totally recommend anyone to read, can be found here: Row major vs. column major, row vectors vs. column vectors.
For OpenGL and GLSL users, it’s been quite clear for some time now: column major representation and column vectors.
For DirectX, it’s not always that simple, and here are some reasons why:
One thing that can be off-putting when migrating from XNA to Direct3D on Windows Phone 8 is the empty default project template. In XNA projects, an empty project simply contained the Game1.cs class, with all it’s overriding methods that you could place code in and start working on the game. The rest of the code was hidden inside the framework’s bowels.
When creating a new ‘Windows Phone Direct3D App’, you get no less than 10 code files. At the beginning, you can get away with not looking into most of these and just start modifying the CubeRenderer.h and CubeRenderer.cpp files (as I suggested in my Getting Started post), but eventually you will need to understand what goes on in the other files and add code to them, which is what this short dissection is for.
As I wrote in my previous post, Windows Phone 8 does not support WIC components, which means that unless you want to write a .png loader manually, you need to have your textures in .dds format. Which is actually quite a good thing, since .dds supports hardware texture compression, if you need to save on memory. The only issue is that .dds is not a common format, and most image processing software don’t support it out of the box.
So let’s take a look at various ways we can convert images from common formats (.bmp, .png, .jpg) to .dds, starting with manual conversion, and ending with an msbuild script to do the work for us.
As the name says, this will require you to convert each image manually, which is quite a pain if you have a large number of images, or if you want to be able to make changes to an image and quickly test them. Here are some options for manual conversion:
- NVIDIA Texture Tools for Adobe Photoshop – If you’re lucky enough to have Photoshop at your disposal, the NVIDIA Texture Tools is a plugin that allows you to export images to .dds format, with lots of options including format, DXT compression, mipmaps, etc.
- Visual Studio 2012 – The latest version of Visual Studio has a basic image editor built in, and it supports saving images in the .dds format. Just click File->Save as…, and you’ll be able to select .dds from the list
The disadvantages of a manual conversion process should be quite obvious, so let’s find a better solution.
Custom Build tool using texconv.exe
The idea is to add images to the WP8 project, and have them converted to .dds at build time. To do this, we’ll need a command line tool that can convert textures to .dds. (more…)
One of my favorite things about XNA was the ability to just start Visual Studio, create a new project, and start adding game code. My purpose in the next few blog posts will be to try and make 2D game development using Direct3D on WP8 a bit more accessible (as I would like it) using any resources I can put my hands on.
Direct3D on Windows Phone 8
We’ve known for some time that Windows Phone 8 will support native development and Direct3D, and the SDK is finally here. Nokia has a nice little summary of other WP8 features on their developer site.
Some things to note about Direct3D on Windows Phone 8:
- It’s useable through the DirectX11.1 API
- It only support Feature Level 9.3
- No Direct2D, no DirectWrite
- No WIC (Windows Imaging Component)
The prospect of going to C++ and Direct3D might seem a little daunting (and rightfully so), but with a bit of courage, help, and guidance, it’s not that bad. Of course, there are lots of other options, if you feel like it, but they are beyond the scope of this blog post; XNA 4.0 is still supported in the Windows Phone 8 SDK, and I hear some engines like Unity, Cocos2D, Ogre3D are coming this way. And you can always look at SharpDX and Monogame, once they’ll support Windows Phone 8.
But let’s get back to Direct3D.
Previous parts in this mini-series:
In this third and final part of this series of samples related to postprocessing on WP7, we’ll handle two effects: pixelate and radial blur.
We’ll start with the following ‘scene’
This one’s a quite easy one, and even with shaders the process would be similar. But when using shaders, this could just be one step towards more interesting effects, like Bloom.
The effect we want to achieve is the have the initial image, and give it a pixelated look, with large blocky pixels. The short of it is: scale the image down into a buffer that is 16 times smaller, and then scale it back up, and draw it using Point filtering.
First step is to create a small randertaget. (more…)
For the first part of this mini-series, please read: Postprocessing effects on WP7, Part I
Starting from where we left of, this part will be focused on a single effect: random noise.
My original inspiration for this was the subtle ‘film grain’ effect seen in the first Mass Effect, though by no means do I think my version is anywhere near in quality and subtleness. Actually, I kinda pushed it to be more visible for the sake of this article.
The effect was simple enough to obtain, and with a bit of playing around with UV coordinates, it can be animated and looks decent.
The first thing I did was take a picture of static noise. These are easy enough to find or to produce. Here’s the one used in the sample.
As I write these words, I realize that there might be easier ways to get this on the screen, like drawing it with additive blending and a very low alpha. However, my wish was to add noise and ensure that the colors are not brightened too much. (more…)
One of the things I miss most when programming for Windows Phone 7 are shaders. As you can probably see in the other samples of this site, I am quite fond of them, so they were greatly missed in all my time working with XNA on WP7.
All this is about to change soon, as Windows Phone 8 will support DirectX and shaders. But of course, as a developer, you can’t forget WP7 users, so ideally you would want to have at least some effects also available in the WP7 version of your game. So I thought I’d share some of the tricks we used to make postprocessing effects on WP7 in Chickens Can’t Fly. Of course, not all of the effects you’ll see here actually made it into the game. Some were just experiments that were ultimately left out of the game, but maybe you’ll find use for them in your own games.
In this part, I’ll show two effects that use Color Blending to obtain some color manipulations.
In case you haven’t worked with color blending before, feel free to read the following articles:
- What is Color Blending?
- Cornflower Blue’s articles on Alpha Blending: part 1, part 2, part 3. There are rather old, but then again… so is color blending. The theory still holds.
Still here? Good
The main takeaway from these articles should be this formula:
FinalColor = (SourceColor * SourceBlend) + (DestinationColor * DestinationBlend)
The meaning of all fields here is:
- FinalColor – the final color that will appear on the screen
- SourceColor – the color of the pixel being drawn
- DestinationColor – the color of the pixel currently in the render target
- SourceBlend and DestinationBlend – parameters we can tweak to obtain the effects we want
Going through all the possible values for these fields is out of scope of this post, and is covered in the above articles. Let’s now get to something more interesting. (more…)