Chris Muench - writing managed 3D app for mobile devices

Again with the many videos in the short time period - you made me write a download manager in C#!

No, I'm not going to use some Commercial, ad ridden s*** off Download.com.

What percentage of PocketPC supports DirectX?
What's the expected growth of this segment?

I remember doing this stuff at last year's MEDC. I even got to talk to Chris after his session. Fun stuff. It made me want to get a Dell Axim when Window Mobile came out(We got a few DX apps to work on it at my office using the beta for CF  2.0, but I haven't gotten the damn thing yet).

If you want to to try that game, it is called Pocket-Jongg 3D and it looks like there is a free demo version of it. You can download it from handango.

EDIT: hm, looks like that game will not work on a HTC Universal. It throws an Microsoft.WindowsMobile.DirectX.DriverUnsupportedException.

[C]

Khamul wrote:

Again with the many videos in the short time period - you made me write a download manager in C#!

No, I'm not going to use some Commercial, ad ridden s*** off Download.com.

Actually, CNet has a policy stating that no downloads they host will have ad-ware in it. There's no policy against annoying shareware, however

Khamul wrote:

Again with the many videos in the short time period - you made me write a download manager in C#!

No, I'm not going to use some Commercial, ad ridden s*** off Download.com.

http://www.freedownloadmanager.org/

No ads, great bit of software.

Stephen.

I am so loving developing games on the windows mobile platform with managed Mobile DirectX. The integration with VS2005 and the device emulator is fast and some of the new debug tools are handy. 

There are just a couple things to keep in mind because of the reduced functionality on the mobile platform. Obvi, all the shaders and effects stuff in the programmable pipeline isn't included, but the next generation of mobile GPU's will be almost pc-quality..

I am still using OnPaint to render my scenes, like the code in this demo. There was a lot of debate about this in managed DirectX for winforms and Tom Miller posted a 'perfect' render loop using interop to hook into the windows message pump. Is there a perfect render loop that can be implemented in managed mobile DirectX development?

Personally I think performance is good enough using the builtin events and it's better to optimize the game code. But any increase in performance is welcome in pushing the edge

bonk wrote:

If you want to to try that game, it is called Pocket-Jongg 3D and it looks like there is a free demo version of it. You can download it from handango.

EDIT: hm, looks like that game will not work on a HTC Universal. It throws an Microsoft.WindowsMobile.DirectX.DriverUnsupportedException.

It helps to identify the D3DM driver and configure accordingly. On the HTC, a software reference driver cripples D3DM framerates

LINK:
http://blogs.msdn.com/markprenticems/archive/2006/03/10/547983.aspx

(This is WinCE-compatible Win32 unmanaged C/C++ code but hopefully there a similar way to do it in WinCE managed C#.)

"Tom Miller posted a 'perfect' render loop" - I didn't see his render loop, but for games a simple yet effective loop that I use is this (pseudo-code):


while()
{
   PeekMessage(&msg)
   TranslateMessage(&msg)
   DispatchMessage(&msg)
   DoSomethingElseWithMessage(&msg)
   Clear(&msg)

   DoGameLoop()

   Sleep(0) // throw in a Sleep(0) or Sleep(1) if having timing issues
}

That is the basis of it.  You may want to loop to process all messages in the queue before calling DoGameLoop.  And you may want to only call DoGameLoop every 1/60 of a second or something (use QueryPerformanceCounter for timing).  But yeah basically that is it.

Ignore WM_PAINT by simply returning 0 and only draw the backbuffer to the screen in DoGameLoop and WM_ERASEBKGND messages (return non-zero for WM_ERASEBKGND).

Don't actually write game code in WNDPROC, just build a queue of received input and process the queue in DoGameLoop.

It is that simple and will speed up your game whether you are using GDI or Direct3D.


If graphics is another culprit of main slowdown, then figure out whether your platform supports accelerated 2d and/or 3d rendering.  If no 3d acceleration but yes 2d acceleration, then use 2d acceleration to make a faster 3d game (or just write a 2d game).  But to do that you'll need direct write access to video memory, which as far as I know the only 2d graphics API that gets you that is DirectDraw.  Though I don't know if DirectDraw exists for WinCE.

Otherwise you are stuck with GDI/GDI+ (only GDI+ for C#).  And if you use GDI and need pixel access use CreateDIBSection to create your backbuffer HDC's HBITMAP.

Ah yes after a quick search I've come to discover that the [dead and slaughtered in the eyes of Win32] DirectDraw API is a new WinCE API!

http://msdn.microsoft.com/mobility/windowsmobile/howto/windowsmobile5/api/default.aspx

So yes again if your hardware supports 2d acceleration use DirectDraw.

As a test of how slow GDI is, if all you do in your loop is blit the backbuffer to the screen, you'll max out at about 30fps (the test was conducted in XP).  This is when using CreateDIBSection to create a backbuffer whose memory you have direct access to (because to a game programmer SetPixel is the worst function in the world).  Even when using DDB sections instead of DIB, it is a little bit faster but you don't have memory access.

DirectDraw is always blazing-fast and you get direct memory access.  Video memory writes are traditionally faster than system memory writes, and because there is not a huge PCI bus in your way video memory reads may actually be faster too.

If you have a fast software 3d rendering engine at your disposal and a 2d-accelerated WinCE device that supports DirectDraw, you can combine the two to maximize speed.  Like the good-ol days back again!

CodeWarrior wrote:

(This is WinCE-compatible Win32 unmanaged C/C++ code but hopefully there a similar way to do it in WinCE managed C#.)

Thanks for the quick reply, CW!

The interop code for handling messages works fine in CF.

The problems I am encountering have to do with the limits of the managed Forms classes. For one, there is no Application.Idle event in which to peek messages and launch my frame update and render calls. Only Application.DoEvents. Second, there is no WndProc method to override in my managed CF winform. So I am not really sure where to place my hook..

For now I am using Application.DoEvents and concentrating on optimizing game code. 

It seems that german HTC Universals do support Direct3D Mobile, it's just that most Direc3D Games require some device capabilities that the drivers shipped with all german HTC-Universals do not support. I have written a little tool that displays all the device capabilites of the mobile device: D3DMobileDoctor Its quite interesting to see what moible direct3d is capabale of (my device supports textures of the size 2048x2048 ).
I will continue to work on it and include some more Direct3D diagnsotics and troubleshooting.

     Hopefully just single-texture mapped triangles with color blending would be hardware accelerated.

     In one of the games I worked on, the graphics engine programmer did all the lighting and [part of] the transformation themselves (can't calculate lighting manually without some initial transforming).  That allowed the game to be compatible with more types of hardware too (didn't need hardware lighting).

     I'm thinking of porting one of my old Win32 DirectX Apps to Windows Mobile.  Hmm ... thinking ...