Windows Mobile managed graphics APIs?
Author
I've been doing some development on Windows Mobile for the last few months and have constantly run into the same problem over and over again: I can't find a high performance graphics API (2D or 3D) that I can use from .NET CF.
My options seem to be as follows:
- GAPI: deprecated and no managed interface.
- GDI: easy to use and very accessible, but terrible performance.
- Direct3D: managed interface available but performance on my HTC Touch Pro 2 is abysmal (in the MSDN samples I typically get about 0.1 fps, much to my surprise, I was under the impression that this device had hardware acceleration enabled).
- DirectDraw: no managed API available. I found a wrapper on codeproject.com (http://www.codeproject.com/KB/mobile/WindowsMoibleManagedDDraw.aspx) but when I tried to use it for anything non-trivial I got continuous out of memory errors upon launching my app, which I don't think were my code's fault.
- OpenGL: no managed API available.
- GapiDraw: looks perfect and has an open source C# wrapper available, but if I decide to release any of my apps as shareware I need to somehow find $1000 to buy a license, which is probably more than I'll ever make back.
That appears to be it.
Am I missing something here? Are there any other options I'm overlooking?
When I see the huge volume of professional looking games being released for the iPhone, it makes me very frustrated that I can't seem to produce anything similar on Windows Mobile simply because there's no graphics library available.
Can someone please show me the light?
Hmm. I'm guessing you have to build it yourself and hope it works okay. There's no chance of SlimDX gaining Compact Framework support, let alone mobile device support. Your D3D mobile performance issue sounds like a driver problem, though.
D3DM perf is highly dependent on the driver supplied with your device. It sounds like your OEM put the D3DM Reference Driver on the device instead of developing a driver of their own. That driver is designed to generate "golden frames" for driver verification purposes and does the majority of its rendering calculations using floating point math, hence it's very accurate, but also very slow.
There has been some work in the public domain in getting a managed wrapper around OGLES. This might be a place to start: http://code.google.com/p/acidframework/. There's another OGLES managed wrapper on http://www.koushikdutta.com/2008/08/net-compact-framework-wrapper-for.html. Good luck!
There has been some work in the public domain in getting a managed wrapper around OGLES. This might be a place to start: http://code.google.com/p/acidframework/. There's another OGLES managed wrapper on http://www.koushikdutta.com/2008/08/net-compact-framework-wrapper-for.html. Good luck!
I just had a conversation with some one last week about this. Capable graphic program interfaces exists, but depending on your OEM you may have gotten a cheap low powered implementation of the interface. HTC is known for doing this.
The HTC devices that I have used have slow graphics performance because instead of properly implementing the DirectX interfaces HTC decided to use the Microsoft Reference Implementation (which was never meant to on on actual hardware). The reference implementation for the DirectX interface will usually result in frame rates measured in seconds per frame instead of Frames per second. If you use the DirectX interfaces you may want to ensure that when your program is running that it isn't running against a reference implementation driver. Some of the later HTC devices use an implementation targeting the devices processor (such as the HTC P3452) but those devices have slow processors (around 200MHz) so it still leaves much to be wanted.
If you were to run your program on a difference device (such as the Samsung Omnia) the performance results will be vastly different. While the Omnia doesn't use hardware a hardware implementation of the graphic functionality they do use an implementation that was optimized for the processor in the device.
For Direct3D it is easy to get the driver name in two lines of code.
AdapterListCollection al = Manager.Adapters;
string driver = al.Default.Information.DriverName.ToString();
If you get back "d3dmref.dll" then your device is destine to have poor performance and there's not much that you can do. I've got a precompiled version of the above in a program that displays the results in a message box. Hope this helps.
http://j2i.net/blogs/home/archive/2009/07/18/identifying-your-direct3d-driver.aspx
All that being said, I think you may be better off creating a game in a native (C/C++) language instead of a managed language (C#), especially if performance and low[er] memory consumption are your goals.
The HTC devices that I have used have slow graphics performance because instead of properly implementing the DirectX interfaces HTC decided to use the Microsoft Reference Implementation (which was never meant to on on actual hardware). The reference implementation for the DirectX interface will usually result in frame rates measured in seconds per frame instead of Frames per second. If you use the DirectX interfaces you may want to ensure that when your program is running that it isn't running against a reference implementation driver. Some of the later HTC devices use an implementation targeting the devices processor (such as the HTC P3452) but those devices have slow processors (around 200MHz) so it still leaves much to be wanted.
If you were to run your program on a difference device (such as the Samsung Omnia) the performance results will be vastly different. While the Omnia doesn't use hardware a hardware implementation of the graphic functionality they do use an implementation that was optimized for the processor in the device.
For Direct3D it is easy to get the driver name in two lines of code.
AdapterListCollection al = Manager.Adapters;
string driver = al.Default.Information.DriverName.ToString();
If you get back "d3dmref.dll" then your device is destine to have poor performance and there's not much that you can do. I've got a precompiled version of the above in a program that displays the results in a message box. Hope this helps.
http://j2i.net/blogs/home/archive/2009/07/18/identifying-your-direct3d-driver.aspx
All that being said, I think you may be better off creating a game in a native (C/C++) language instead of a managed language (C#), especially if performance and low[er] memory consumption are your goals.
Author
Thanks to everyone for your responses.
I tried the Acid Framework and managed to get this to compile, but as there is no documentation available I couldn't get a huge amount further. I took some of the Windows (non-mobile) tutorial projects and got the first one to compile and run, but when I closed the app window and returned to the main device front page, the tutorial image was left half rendered all across the screen which looked terrible. The other tutorials wouldn't compile at all, as the API is obviously very different between the Windows and WindowsMobile versions. I've currently abandoned this as a possible solution.
The OGLES wrapper looks like it has potential, but appears to be very primitive in its capabilities at the moment. I don't want to use an API that could let me down at any time by failing to implement some function that I need.
Thanks j2inet for the information about the D3D interface. I downloaded your driver check application and it confirmed that the HTC Touch Pro 2 is using the software reference driver. What a pity. I had assumed (naively, perhaps) that after all the fuss that was made about this a year or two back, HTC would have started shipping a proper driver with their new devices (this only came to the market about 2 months ago). Obviously not. I continue to assume that the OpenGL driver is better, I'll have to investigate this and see.
I think I've reached the same conclusion as you regarding using a managed language for high performance games. I've no major problem with using C++, but everything is just so much easier in .NET. Moving to C++ means I have to set up yet another environment and deal with another load of configuration and compilation issues -- I'm getting too old for all this! ;-) Looks like it may be the only way to go though.
I think that's a real pity and is hugely letting down Windows Mobile as an entertainment platform. Apps are being churned out at a really high rate for other mobile platforms, and I know this in part because they are new, exciting and fashionable. But I'm certain that WM is more than capable of keeping up with this (in terms of quality rather than quantity). The lack of easy to use development tools just prevent a much greater barrier to entry than they should.
I tried the Acid Framework and managed to get this to compile, but as there is no documentation available I couldn't get a huge amount further. I took some of the Windows (non-mobile) tutorial projects and got the first one to compile and run, but when I closed the app window and returned to the main device front page, the tutorial image was left half rendered all across the screen which looked terrible. The other tutorials wouldn't compile at all, as the API is obviously very different between the Windows and WindowsMobile versions. I've currently abandoned this as a possible solution.
The OGLES wrapper looks like it has potential, but appears to be very primitive in its capabilities at the moment. I don't want to use an API that could let me down at any time by failing to implement some function that I need.
Thanks j2inet for the information about the D3D interface. I downloaded your driver check application and it confirmed that the HTC Touch Pro 2 is using the software reference driver. What a pity. I had assumed (naively, perhaps) that after all the fuss that was made about this a year or two back, HTC would have started shipping a proper driver with their new devices (this only came to the market about 2 months ago). Obviously not. I continue to assume that the OpenGL driver is better, I'll have to investigate this and see.
I think I've reached the same conclusion as you regarding using a managed language for high performance games. I've no major problem with using C++, but everything is just so much easier in .NET. Moving to C++ means I have to set up yet another environment and deal with another load of configuration and compilation issues -- I'm getting too old for all this! ;-) Looks like it may be the only way to go though.
I think that's a real pity and is hugely letting down Windows Mobile as an entertainment platform. Apps are being churned out at a really high rate for other mobile platforms, and I know this in part because they are new, exciting and fashionable. But I'm certain that WM is more than capable of keeping up with this (in terms of quality rather than quantity). The lack of easy to use development tools just prevent a much greater barrier to entry than they should.
Quote:Original post by AdamDawes
Thanks j2inet for the information about the D3D interface. I downloaded your driver check application and it confirmed that the HTC Touch Pro 2 is using the software reference driver. What a pity. I had assumed (naively, perhaps) that after all the fuss that was made about this a year or two back, HTC would have started shipping a proper driver with their new devices (this only came to the market about 2 months ago).
Wow, I would have thought that they would at least ship their devices at least with an optimized driver instead of the reference implementation.
Quote:Original post by AdamDawes
I think I've reached the same conclusion as you regarding using a managed language for high performance games. I've no major problem with using C++, but everything is just so much easier in .NET.
I agree! .Net isn't considered a Rapid Application Development environment for nothing! :-)
Quote:Original post by AdamDawes
I think that's a real pity and is hugely letting down Windows Mobile as an entertainment platform.
I also agree here. Unfortunatly HTC is the face of Windows Mobile. They have the largest WM market share. But their choices are based on maximizing profit which translates into making hardware decisions that satisfice. I am using a Samsung Omnia right now for development. While it doesn't have a video accelerator Samsung installed a proper driver that takes advantage of the phones hardware and processor characteristics. It is a world of difference higher in performance than the HTC devices that I have.
Author
Hmm. It looks like I may have been too hasty in dismissing Koushik Dutta's managed OpenGL ES wrapper that Don suggested above. Today I stumbled across the following thread in xda-developers:
http://forum.xda-developers.com/showthread.php?t=511363
This uses the OGLES wrapper to produce some benchmarks, and on my Touch Pro 2 they run very nicely indeed. Lots of others are reporting good performance on other similar devices too.
And best of all, the author has included sourcecode, which is written in C#, and which compiles and runs perfectly. That should be a fantastic starting point for creating a game.
By the way, thanks for posting your DirectDraw tutorial on codeproject.com, j2inet! (http://www.codeproject.com/KB/mobile/WiMoBubblePuzzle.aspx). This looks exceedingly useful and I'm sure many others will appreciate this. Unfortunately it looks like DirectDraw is a no-go for HTC devices running TouchFlo3D as they all fail as soon as a call to CreateSurface is made with an out-of-memory error (http://blogs.msdn.com/windowsmobile/archive/2009/04/17/twisted-pixels-3-memory-mysteries.aspx). I can't find any solution to this. Which is a real blasted nuisance...
So it looks like there may be hope yet using OpenGL in .NET -- just need to find some more time to experiment with this now. :-)
http://forum.xda-developers.com/showthread.php?t=511363
This uses the OGLES wrapper to produce some benchmarks, and on my Touch Pro 2 they run very nicely indeed. Lots of others are reporting good performance on other similar devices too.
And best of all, the author has included sourcecode, which is written in C#, and which compiles and runs perfectly. That should be a fantastic starting point for creating a game.
By the way, thanks for posting your DirectDraw tutorial on codeproject.com, j2inet! (http://www.codeproject.com/KB/mobile/WiMoBubblePuzzle.aspx). This looks exceedingly useful and I'm sure many others will appreciate this. Unfortunately it looks like DirectDraw is a no-go for HTC devices running TouchFlo3D as they all fail as soon as a call to CreateSurface is made with an out-of-memory error (http://blogs.msdn.com/windowsmobile/archive/2009/04/17/twisted-pixels-3-memory-mysteries.aspx). I can't find any solution to this. Which is a real blasted nuisance...
So it looks like there may be hope yet using OpenGL in .NET -- just need to find some more time to experiment with this now. :-)
Quote:Original post by AdamDawes
By the way, thanks for posting your DirectDraw tutorial on codeproject.com, j2inet! (http://www.codeproject.com/KB/mobile/WiMoBubblePuzzle.aspx). This looks exceedingly useful and I'm sure many others will appreciate this.
Glad you liked it! I wouldn't really call it a tutorial though. Was more of a description of a program that happened to use DirectDraw. I'm actually working on a tutorial (there's no telling when it will be done) that covers a great deal more than what was mentioned of DirectDraw in the article for that program.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
