PocketMatrix

Hi, I've asked a similar question on the GapiDraw forum and had a good look at gapi emulators. To my surprise I realised I had a download in my 'samples' folder by none other than Thierry T.

I am writing a new game using PocketGL but would like to convert my existing game Space Treker written in PocketC to real C using one of the available toolkits. Currently my game works on every device due to the runtime method used by PocketC so many of my registered users have H/PC devices including the J720.

I have just purchased a J710 for road coding (editing only) so I'm in a position to turn out an H/PC version as well as PocketPC so long as I can get a working GAPI. Having seen that you implement PocketFrog using a GAPI emulator I wondered if anyone had looked at making it work on a Handheld like the Jornada 720?

Do you think it would be possible to get PocketFrog working on the H/PC format?

I would love to make PocketFrog work on H/PC devices. Thing is I don't have access to such a device.

Currently I can see 3 issues to be investigated:

1) Dependency on GX.DLL (GAPI). Is there a GAPI implementation available on the H/PC? If not, what is available to directly access the screen? In the end, it is entirely possible to use a DIB as a backbuffer and blit it to the display each frame. In that case, it would be important to know the color format of the display (as to optimize the blit). Also, what are the dimensions of the screen in pixels?

2) Dependency on AYGSHELL.DLL. This is used on PPC to switch to/from fullscreen mode. This can easily be solved by not using static linking to the DLL.

3) Dependency on IMGDECMP.DLL. This DLL is used on PPC to decompress images (JPG, GIF, BMP). Is it available on the H/PC? If so, what are the image formats supported? If not, we will have to find an alternative way of decompressing images (BMP is easy, JPG/GIF is more complicated, perhaps LIBJPG).

Then let's start working on this together =)

$ for a GAPI implementation? That's crap... We should rather implement a generic GAPI implementation based on a simple 565 DIB that covers the entire screen. Assuming the display is in 565 format, the blit should be fast enough for real time games

Meanwhile, we should try to find more information about the display hardware used (frame buffer format and address).

Concerning AYGSHELL.DLL: I'd rather remove the dependancy on this DLL then having people download the stubbed version for HPC. This problem is solved.

IMGDECMP.DLL: excellent... I'm already using dynamic loading for this DLL so there shouldn't be any problem.

What's left: GAPI. Do you have this .LIB? It would probably be easy to reverse engineer the thing and figure out the actual frame buffer address. $49? What a ripoff!

I installed the HPC SDK and surprise: there is an emulator that comes with it!

The HPC seems to be based on Windows CE 2.11 (I didn't know that).

This solves the AYGSHELL.LIB issue as HPC's core library doesn't link to it.


From what I know,

Jornada 680 --> SH3 processor, display address/format is unknown.
Jornada 720 --> ARM processor, display address/format is known.

Is there any other model of HPC?

Hi, The Jornada 720 is the first ARM based HPC. The new one is the 728 based on the 720.

The 680 and the 690 are both SH3. There are numerous HPC machines but HP have most of them.

There are several posts which I came across discussing screen layouts with some info. I think the 680 is discussed on PM. I will find them again. There's a list of devices & screen addresses in another post somewhere.

Many thanks

I've played with the HPC2000 SDK and managed to remove the static dependancy on AYGSHELL.DLL. But this was way too painfull (took me more then an hour!)

Basically, the problem is that the ATL implementation for the PocketPC links to AYGSHELL.LIB for a single function: SHDoneButton. (HPC2000 SDK doesn't). So I was thinking, let's recompile the project but with the HPC2000 as the target: surprise, they forgot to include "stddef.h" in the HPC2000 SDK (but it's there with HPC Pro and Pocket PC 2000/20002), so I simply copied this over (STLport needs it).

PocketFrog is also using a function in AYGSHELL.DLL: SHFullScreen. So what I did is a dynamic loader for the DLL that redirects the two calls.

But now I think this is the wrong approach (it's a little hard to setup the projects, the SDK needs to be modified, etc). If a game developper ever includes aygshell.h or ATLbase.h, aygshell.lib is going to be linked again and the game won't work on the HPC.

It would be much more simple to provide the AYGSHELL.DLL stub you were talking about. This way, no need to go through all the problems I had to go through.

What's left? Still need confirmation of the Jornada 720 frame buffer address and a way to detect it? Is the OEMINFO string available?