Language :
 

Backbuffer on the Touch Diamond ???

So I’ve decided to go with DirectDraw as the basis for the graphics in my game. It’s pretty straigthforward to initialize, and there’s quite a few tutorials on it. Well, not that many related to Windows Mobile but still…

I have used a tutorial - Ski Time Mobile - to get myself started. It’s aimed for non-touchscreen devices, with a rather small screen. Anyhow, the initialization routine they use for DirectDraw works fine on the emulator, and on my Axim. But on the Touch Diamond…

The following code is used to determine device capabilities :

    // True if backbuffers and flipping are supported by hardware
    m_bPageFlipping = CheckSurfaceCaps(DDSCAPS_BACKBUFFER | DDSCAPS_FLIP);

I receive true for both the Axim and the Touch, but on this following call :

        ZeroMemory(&ddsdPrim, sizeof(ddsdPrim));
        ddsdPrim.dwSize            = sizeof(ddsdPrim);
        ddsdPrim.dwFlags           = DDSD_CAPS | DDSD_BACKBUFFERCOUNT;
        ddsdPrim.ddsCaps.dwCaps    = DDSCAPS_PRIMARYSURFACE | DDSCAPS_FLIP;
        ddsdPrim.dwBackBufferCount = 1;
        HRESULT lHR;

        // Create Primary Surface
        if (FAILED(lHR = m_pDD->CreateSurface(&ddsdPrim, &m_pDDPrimaryBuffer, 0)))
        {   
            m_bPageFlipping = false;
        }

The creation of the Primary Surface fails, only on the Touch. I can’t remember the error, I’d need to check. Anyway, I thought that I would implement some fallback mechanism. If this call fails, we’re back to flipping our buffers manually.

What scares me is… how many of these weird results would I experience if I had more devices ? Welcome to Windows Mobile I guess :)

This entry was posted on Saturday, April 4th, 2009 at 12:12 pm and is filed under Programming. You can follow any responses to this entry through the RSS 2.0 feed. Both comments and pings are currently closed.

2 Responses to “Backbuffer on the Touch Diamond ???”

  1. Robert van Hoose Says:
    April 17th, 2009 at 4:36 am

    I’m experiencing the same problem with my HTC Touch HD (800×480 @ 192dpi, definitely good looking!). After I rebuilt and modified MS’s dumpmem code to work on my Touch HD, I’ve been profiling the memory on the device. The only possible culprit I saw was: gwes.exe. I don’t know as much as I’d like to about it yet, but although my program has a LOT of space right now between the low DLL load point (currently 0×00FA0000!), gwes.exe’s heap seems to extend above this point. I realize that it’s part of the graphics, windows, and event system. What I don’t know is whether or not DirectDraw surface creation does anything that would cause gwes to try to allocate more heap, etc?

  2. Yannick Says:
    April 17th, 2009 at 7:26 am

    Hi Robert !

    I’ve been looking around for some more information about GWES. Here’s something I found : “It is the Graphics, Windowing, and Events Subsystem, but it does not load the drivers. That is actually handled by another app called device.exe. Gwes.exe is purely for the user interface components and doesn’t deal with the hardware layer.”

    If you check this post http://www.livingroomfun.info/blog/20090416/hardware-page-flip-or-not/ you see that I do not have the problem on the diamond anymore.

    Receiving an E_OUT_OF_MEMORY error, when creating a primary surface with backbuffer, but not getting any error when creating TWO of these backbuffers manually ( and blitting to the primary surface instead of page flipping ) seems to indicate that we have plenty of memory and that the fault is on the driver. However, I must admit that I was targetting system memory for these backbuffers, so maybe it’s something else.

 

 

Copyright 2006-2007 LivingRoomFun.info