Page 1 of 1

The Ipaq 38xx and GX.DLL

PostPosted: May 19, 2002 @ 1:43am
by Dave

PostPosted: May 19, 2002 @ 2:23am
by Dan East

PostPosted: May 19, 2002 @ 12:53pm
by Hosed

PostPosted: May 19, 2002 @ 1:43pm
by Dave

PostPosted: May 19, 2002 @ 2:32pm
by Hosed

PostPosted: May 19, 2002 @ 3:07pm
by Malmer

PostPosted: May 19, 2002 @ 10:35pm
by MQ
Microsoft and Compaq are well aware of the problem. The GX.DLL is distributed by MS and is the same on every platform. The OEM's display driver is what actually exposes the hardware capabilities and screen address. Microsoft has no control over this.

The iPAQ 38xx devices use a new 16-bpp display. The connector on this display made it such that the display had to be oriented 180 degrees from the display on the 36xx devices. In an attempt to be backwards compatible with some poorly written apps, Compaq decided to emulate the orientation of the 36xx devices by using a GXDMA buffer under the hood. To add insult to injury, their routine for rotating the buffer 180 degrees each time the app calls GXEndDraw takes almost 20 ms. I don't know what they are doing in that loop, but I've written some simple C code to do this and it measures around 5 ms.

All of this just goes to show you how much Compaq cares about the game development community. Perhaps things will improve with the HP merger.

PostPosted: May 19, 2002 @ 11:44pm
by Dave
Ah - gotcha. So it's the device driver to blame, not gx.dll.
Is it possible to talk directly to the device driver in the same way gx.dll does?

PostPosted: May 20, 2002 @ 1:47pm
by Hosed

PostPosted: May 20, 2002 @ 6:58pm
by Dave
Thanks - I did a search and found a lot of talk along the same lines as I'm doing right now (damn you Compaq etc! ;)

However I did notice that people have reported the Compaq driver *does* return IsDRamBuffer as TRUE if called correctly (after Init), so it seems Compaq didn't do too bad.

So the best algorithm would probably be:
1) If DRamBuffer is false, use the screen pointer returned by GAPI because it's not a buffer, it's direct.

2) Else, check you are certain it's an iPAQ 38xx. If it's an iPAQ 38xx, use 0xac0755a0,-640,2

3) If you aren't certain it's an iPAQ 38xx, use the GAPI information.

Would you agree?
(By the way, is there a risk of deleting data on the disk if 0xac0755a0 is used, and it isn't the screen address? Is the 32Meg directly mapped to the processor all the time?)

PostPosted: May 20, 2002 @ 7:27pm
by Dan East
BTW, it appears that writing to that address on an E-200 can cause a Hard Reset. Yesterday Matt Keys downloaded the latest 38xx version of Pocket Genesis for his E-200 (which is what the website said to use for all PPC 2002 devices), which caused a hard reset on initialization. The 36xx version worked fine.

Dan East