Hi, for my bachelor thesis I want to develop a small 3D engine for the PocketPC (2003 and WM5). I think there are only 2 APIs for this: OpenGL ES and D3DM. I´ve been playing around with those two 3D APIs for a few days. I´ve tried some tutorials with basic stuff, e.g. initialization, render a textured cube and so on. The GLES samples are fine, they are running in an acceptable framerate on my iPAQ 1950 (300MHz). But the D3DM samples are very slow! A one triangle sample runs under 10 fps (the samples are from msdn). Before I tried the samples D3DM was my favourite because I can write in C# (I like the class hierarchy of the CompactFramework) and I wrote some DirectX stuff before. But now GLES seems to be the better one. What do you think? Do you have any experience with these APIs? Can I use GLES under C# (are there wrapper classes for it?) Why is D3DM so slow? Thx! [Edited by - yoursort on January 13, 2006 4:32:51 AM]

The iPAQ series are based on the 'Bulverde' processor (intel PXA270 class), which features a hardware 3D engine made by Imagination Technology (aka PowerVR MBX-S). I suspect the OpenGL ES driver is using the 3D hardware, where D3DM has been left in its original software version.

I don't think the Ipaq 1950 has any hardware support for 3D, you're probably thinking of the Axim 50v, which has the PowerVR chip. The PXA270 doesn't have any specific 3D support, so both D3DM and GL ES should be running completely in software.

Having said that, I don't know why one is slower than the other. I do remember that Intel provides an XScale optimized GL ES library mostly for the transformation part of the pipeline, so if your GL ES implementation uses the Intel libs maybe that's the difference.

I also think that my iPAQ has no hardware acceleration.
And I have a 300MHz Samsung SC32442 processor, not an Intel XScale, so I cannot use the XScale optimized libraries. I use the normal "vincent" library from sourceforge.net.

I wrote a few sample programs in both OGLES and D3DM which displayed from one to 16 triangles, with optional toggles for lighting, texturing and transparency. On my iMate Jam (O2 XDA to most of you) the performance was around 7-8 times better in OGLES with a single triangle and no options. With all options and 16 triangles OGLES was fairly slow but closer to 20 times faster than D3DM. This was running Windows Mobile 2003- apparently Windows Mobile 5.0 based devices are supposed to have much better D3DM support so the performance hit might not be as bad but it's still pretty clear in my mind that OGLES is the way to go.

Are you using C# for the D3D app, and native C++ for the OpenGL-ES app? Unless a lot has changed in the PocketPC world, I wouldn't count on doing any realtime 3d with C# on that platform (without hardware acceleration, at least).

I've performed similar tests using Hybrid and Vincent OpenGL ES drivers on Intel XScale platforms and D3DM outperformed both of them.

If I had to guess I'd say that this isn't a problem with D3DM per-se, but rather the particular implementation of the D3DM driver on your iPaq. It has a Samsung CPU, right? If so, it wouldn't use the fast Intel XScale driver that I tested.

BTW, D3DM wasn't available on WM2003 devices, so I have no idea how you were testing it.

@ AVigesaa:

Yes that´s right, I´m using c++ for GL|ES and c# for D3DM. I cannot imagine that writing managed code can causes a heavy performance reduction on a so simple example programm, but I should try the unmanaged d3dm samples to check out the perfomance with c++.

@ don:

Yes I have Samsung processor in my iPAQ but I thought these are 100 % compatible to XScales?!
Maybe it doesn´t uses the optimized implementation.
I´m running Mobile 5 and not 2003. I have no answer how Anonymous Poster tested d3dm on a 2003 device.

Do you have any good resources for GL|ES and D3DM? I found www.typhoonlabs.com and http://www.zeuscmd.com/ very usefull.

Thx for your replies.

Yes, I would say that using C# is responbsible for a lot of the speed difference between the two. I'd like to see your results using unmanaged c++/D3DM.

yoursort:

You can determine which D3DM driver you have by calling IDirect3DMobile::GetAdapterIdentifier.

The Intel XScale has some additional instructions over the common ARM instruction set. Their D3DM driver uses these and as such won't run on non-Intel CPUs. Besides, you can't really blame Intel for their driver failing to run on a competitor's CPU. :)

If I can find a 1950/1955 around here I'll try some of my benchmarks and post results to this thread. Single triangle type of benchmarks don't mean much though unless your game only renders a single triangle.

AVigesaa:

The apparent performance difference between using C++ and C# would vary depending on what else is going on in the system. For example, if you're drawing very little it will appear like the C# overhead would be quite large, however once the majority of the time per-frame is spent elsewhere (i.e. in a software rasterizer filling pixels) I would imagine that the difference in the API interface will be a minimal portion of the time it takes to execute your render loop.
I do agree with you though that if you're trying to compare OpenGL ES to D3DM that you should use the same native interface with the two APIs.