This site is no longer active and is available for archival purposes only. Registration and login is disabled.

iPaq h38xx blitting?


iPaq h38xx blitting?

Postby Gregory Torres » Sep 15, 2002 @ 1:42am

<table width="15%"></table><table width="60%"><A HREF="http://www.amazon.com/exec/obidos/ASIN/0310228638/gamingrepubli-20"><IMG SRC="https://ssl-images.amazon.com/images/P/0310228638.01.TZZZZZZZ.jpg" border="0" alt="cover" hspace="3" vspace="3" align="left"></A>
If You Want to Walk on Water,<br>You've Got to Get<br>Out of the Boat.</table>
Gregory Torres
pm Member
 
Posts: 5
Joined: Sep 15, 2002 @ 1:39am


Postby goodbye » Sep 15, 2002 @ 1:45am

goodbye
pm Insider
 
Posts: 901
Joined: Jul 21, 2002 @ 4:17am


Postby Digby » Sep 15, 2002 @ 2:01am

Ugh. It's not a GAPI bug! This is entirely Compaq's boneheaded move in their display driver.

The screen on the 38xx series of devices is oriented differently from the previous iPaqs. Rather than expose this new orientation through GAPI, they used a feature of GAPI called "gxdma" to expose an intermediate buffer to applications that is oriented the same as previous iPaqs. This intermediate buffer is copied to actual display memory each frame when your app calls GXEndDraw. This extra full-screen copy operation is causing the performance hit you're experiencing.

This was done for compatibility reasons because some popular games didn't test the GAPI caps bits and just assumed that if they were running on a iPaq the screen layout/config was the same. Rather than having these existing games not run on the new iPaqs, they decided to take the perf hit in the name of compatibility.

The good news is that if you want to write your app to the actual video memory address and not pay the perf hit, you can read this thread for how to do it.

Digby
pm Insider
 
Posts: 1011
Joined: Apr 29, 2001 @ 1:53pm


Postby goodbye » Sep 15, 2002 @ 2:16am

goodbye
pm Insider
 
Posts: 901
Joined: Jul 21, 2002 @ 4:17am


Postby Gregory Torres » Sep 15, 2002 @ 4:22am

Wow!

Thank you for the amazingly quick replies. I'm glad to know it's easy to fix this problem, although I like using GAPI returns just so it works universally. I guess that won't help me, though :P

-Greg
<table width="15%"></table><table width="60%"><A HREF="http://www.amazon.com/exec/obidos/ASIN/0310228638/gamingrepubli-20"><IMG SRC="https://ssl-images.amazon.com/images/P/0310228638.01.TZZZZZZZ.jpg" border="0" alt="cover" hspace="3" vspace="3" align="left"></A>
If You Want to Walk on Water,<br>You've Got to Get<br>Out of the Boat.</table>
Gregory Torres
pm Member
 
Posts: 5
Joined: Sep 15, 2002 @ 1:39am


Postby Digby » Sep 15, 2002 @ 5:21am

Well if you're a GAPI "purist" then you should be calling GXIsDisplayDRAMBuffer and if it returns TRUE, then don't use your own back buffer created in system memory. Instead, use the buffer returned by GXBeginDraw as your back buffer and compose your frame to that. This avoids a full-screen copy operation that you would be doing if you created and managed your own back buffer.
Digby
pm Insider
 
Posts: 1011
Joined: Apr 29, 2001 @ 1:53pm


Postby britcode » Sep 15, 2002 @ 3:34pm

My code for the workaround/hack. Think it's okay. Feedback more than welcome.


// See if the device is an iPAQ 3800
memset(&DevName,0,sizeof(DevName));
SystemParametersInfo(SPI_GETOEMINFO,sizeof(DevName)>>1,DevName,0);
if (_wcsicmp(DevName,L"compaq ipaq h3800")==0) Draw3800=1;

// Find out about the primary surface (the screen)
GXDisp=GXGetDisplayProperties();
memset(&Prim,0,sizeof(Prim));
Prim.w=GXDisp.cxWidth;
Prim.h=GXDisp.cyHeight;
Prim.xp=GXDisp.cbxPitch;
Prim.yp=GXDisp.cbyPitch;
if (Draw3800) { Prim.xp=-640; Prim.yp=2; }

...
// Get access to the real screen
if (Draw3800) Scr=(unsigned char *)0xac0755a0;
else Scr=(unsigned char *)GXBeginDraw();

...
if (Draw3800==0) GXEndDraw();
britcode
 


Postby Phantom » Sep 15, 2002 @ 8:28pm

Give me some good data and
I will give you the world
User avatar
Phantom
pm Insider
 
Posts: 913
Joined: Feb 21, 2001 @ 8:14am
Location: Houten, Netherlands


Postby britcode » Sep 16, 2002 @ 4:03am

britcode
 


Return to Windows Mobile


Sort


Forum Description

A discussion forum for mobile device developers on the Windows Mobile platform. Any platform specific topics are welcome.

Moderators:

Dan East, sponge, Digby, David Horn, Kevin Gelso, RICoder

Forum permissions

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum