Twisted Pixels #2 – Doing Graphics!

 

 

Previous post: Twisted Pixels - A Mobile Game Development Diary (Day 1)

Doing Graphics!

What is the best way to do 2 dimensional graphics on Windows Mobile? To some degree, it depends on your development strategy. Silverlight and Flash is getting a lot of good press for browser based applications, but have not really penetrated the mobile browser world yet. .NET is pretty powerful for drawing text and shapes, but is surprisingly weak in its support of bitmapped graphics. Since what I want to do work with low-level bitmap graphics, it looks like I’m going to have to work with C++ and native code, at least for the present generation of Windows Mobile (Windows Mobile 6.1 and 6.5). I love how easy .NET is to use , however it is not really meant for this sort of programming at the moment.  Native code is going to produce the fastest application, and that’s always a good thing too.

I checked the documentation in MSDN and it seems that DirectDraw is the way to do graphics in native code. Direct3D is tempting, even for a 2-D game, but there is spotty hardware support (and the new software emulator that ships on some hardware is, well, software).

Note: Although the Windows desktop has moved on to more recent APIs for display tasks, Windows Mobile, because of its lower graphics horsepower, still uses these older Win32 APIs.

Speed Bump: The SDK contains several DirectDraw sample applications that look like they will provide a good starting point for a project, but unfortunately, there are complications. All of the samples except one use back buffers to speed up and improve display quality. That’s great; however both the Windows Mobile 6 Professional and Windows Mobile 6 Classic emulators contain (virtual) display drivers that do not support a back buffer, so the samples will not run in emulation. Hardware support is not much better – 3 of the 5 apps require hardware flipping chain support, which few (if any) devices support. That leaves two samples, one of which requires hardware overlay support, which only a few devices have so far.

Fortunately, the one remaining sample works both on hardware and in the emulator; a port of the classic directX sample “Donuts”, which is a space shooter using colorful animated sprites. Try loading this sample, found in the default SDK location: C:\Program Files (x86)\Windows Mobile 6 SDK\Samples\PocketPC\CPP\win32\directx\DDraw\Donuts2, and run it in either of the emulators. Software emulators are not known for their speed, and these are no exception. The frame rate is low and the game (although good looking) is difficult to play using the emulator controls. Still it works, and that is what we need to see at the moment.

The performance on the emulator makes me curious to see how live hardware performs, so next I’ll take a short detour and set up Visual Studio to use a real phone as the target device.

Testing and Debugging on Real Hardware

I did some research to see what Windows Mobile hardware has the best range of features, and came up with several candidates. Of these, the one I could get my hands on the most quickly was a HTC Diamond. This is an excellent touch screen phone with GPS and Accelerometer, which seemed like a good place to start my efforts.

First the good news. I attached a usb cable to the new Diamond, set up the Windows Mobile Device Center in Vista to sync with the Diamond.  Visual Studio was already set up to debug to hardware (how easy is that?) so I selected the Diamond (“Windows Mobile 6 Professional Device”), and clicked the “Start Debugging” button. Within a few moments, a series of applications and DLLs were downloaded to the phone. Each of these caused a security dialog to be displayed on the phone. I allowed all of these. The last to download was the app (Donuts2.exe) and here I hit a snag.

Speed Bump: Apparently, the security settings on this particular phone don’t allow unsigned applications to be installed. The error message displayed in Visual Studio is shown below:

 

The error suggests using the Device Security Manager to change the settings and try again. Since I did not recognize the name of this tool I did a quick web search and came up with a Windows Mobile 5.0 power toy on MSDN. This did not sound quite right (surely there was something more recent) so I searched on MSDN for more hits, and discovered that this tool is now a feature in Visual Studio 2008. Again, it’s almost too easy – there it was under the Tools menu in Visual Studio.

 Toolbox: The documentation told me that the Device Security Manager is a tool that allows developers to set up devices with different security profiles for testing purposes. Very useful – add that to the toolbox!

Running the tool gave me a chance to connect to the device and change the security from “Prompt One Tier” to “Security Off”. Clicking “Deploy to Device” sent the change down to the device. Clicking on the “Start Debugging” button sent the application down to the device, and this time it started to run.

But that’s where everything went bad. The application failed with the following error:

DONUTS: CleanupAndExit err = CreateSurface FrontBuffer Failed!

It’s easy enough to track down where this error is being generated, just search on the error text in the project’s code files. It looks like this is happening (as we might expect) during a call to CreateSurface. I placed my cursor in the call to CreateSurface and hit F1 to display the reference topic for this command from the help file.

The topic tells me that there are several errors that CreateSurface can return, and since the error message in the code is generic, it does not tell me what in particular is wrong.

To get more information, I set a breakpoint in the code by clicking in the border next to the error message. A red dot appeared, indicating that I’d been successful.

The next time I ran the app, execution of code stopped at the breakpoint, and I hovered my mouse over specific variables to see what their values were. (I really love this feature.) Doing this to ddrval, I saw that the error was “E_OUTOFMEMORY”. That’s a little strange, since I know the device has plenty of memory.

Speed Bump: There was no problem in the emulator, yet the device is running out of memory when I try to run my app. What’s up with that?  Note: I should point out that I suspect that this is hardware related, and so this may not happen on your device. This is a developer diary, so I’ll just describe what happened to me.

Windows Live Search pointed me to the following posts that talk about similar problems and describe how memory is managed and debugged in Windows Mobile.

Slaying the Virtual Memory Monster (https://blogs.msdn.com/hegenderfer/archive/2007/08/31/slaying-the-virtual-memory-monster.aspx)

Slaying the Virtual Memory Monster - Part II (https://blogs.msdn.com/hegenderfer/archive/2007/10/01/slaying-the-virtual-memory-monster-part-ii.aspx)

Visualizing the Windows Mobile Virtual Memory Monster (https://www.codeproject.com/KB/mobile/VirtualMemory.aspx)

Looks like I’ve met a monster. That can’t be good.

Take a break and review these excellent posts, and see if you can make a guess what might be causing the problem.  Once done, join me next week for the next installment of Twisted Pixels.

Next post: Twisted Pixels - A Mobile Game Development Diary: Day Three – Memory mysteries.

Comments

• Anonymous
  April 06, 2009
  A Mobile Game Development is going in very speed . very useful information. http://www.n4i.co.in/category/mobile-and-cell-phones/

• Anonymous
  April 07, 2009
  Is there anything bing done for the 6.5 timeframe to help with Virtual Memory issues, or is that a WM7 thing?

• Anonymous
  April 08, 2009
  Thanks for your comment.  Sorry, but there is not much I can say about un-released products.  When announcements are made, we will do our best to report them here!

• Anonymous
  April 14, 2009
  Have you actually confirmed that the problem here is virual memory? I found your post because I also started Direct Draw programming this week and am currently stuck in the same place with the same error. I think many are relying on your next post to find out how to solve this. Rob

• Anonymous
  April 16, 2009
  I've been having the same problem when initializing the device (Touch Diamond), and I found two workarounds :

• Fallback to single buffer, and manual copy of a secondary buffer to the screen.
• Updating the ROM of my Diamond with a custom one found on XDA Dev... Both ways are definitely not ideal, and I hope you'll have the good solution in your next article :) I have been writing down all the issues I have, and weird behaviors between different devices here : http://www.livingroomfun.info/blog/category/programming/ Good luck with your project, it has been very instructive so far !

• Anonymous
  April 17, 2009
  Thanks for the link and the comments. More posts shortly.

• Anonymous
  May 04, 2009
  One thing I'd find very helpful is if Microsoft could provide a library of basic pixel compositing functions that take advantage of ARM SIMD instructions if they are available. It would have to be #ifdef'd at coding time, probably, but one of the biggest bottlenecks in my past projects is time spent compositing RGBA values which seem exactly up SIMD's alley. Basic ARM isn't a slouch at this given the barrel shifters and a cheap conditional per instruction, but SIMD would be that much better.