Landscape Mode: Coordinates and cursors sometimes translated

[Ludimate]

I wonder if anyone has any idea on what might be affecting stylus coordinates and cursor keys mappings in landscape modes?

I've observed that applications running in a landscape VGA device (Dell x51v) with HI_RES_AWARE, that is in full VGA resolution, get all stylus coordinates correctly - that is 0,0 is the top-left corner of the landscape screen. However, removing HI_RES_AWARE causes the QVGA emulation mode to kick-in and an application running in landscape receives stylus coordinates with the 0,0 being the portrait 0,0 - coordinate translation is needed in this case.

The same thing happens with cursor keys - they are well translated in landscape VGA but the codes on QVGA are as if the cursor was in portrait orientation. These are the real Windows keyCodes (VK_UP, VK_LEFT, etc.) not PHAL GetKeyList() key codes which might already be "rotated" (PHAL appears to "rotate" cursors in VGA, so they don't work).

Trying in the VS2005 emulators set to landscape always works as in the VGA scenario above (although PHAL never displays well).

PocketFrog is not being used, just plain PHAL set with an orientation set to match the current device orientation taken from ChangeDisplaySettingsEx. The PHAL display is always fine in any orientation, but there are stylus coordinates and cursor codes translations magically being done in VGA and not on the QVGA non-HI_RES_AWARE mode. In fact if you look into PocketFrog's code, it seems to do these QVGA translations (in DeviceToLogical()) but they appear not to be needed on VGA devices.

Just to summarize, in an Axim X51v:
- Native VGA Landscape:
Stylus 0,0 is landscape top-left, cursors key codes (VK_*) are correctly syncd with landscape orientation

- QVGA Landscape emulated by windows under a native VGA:
Stylus 0,0 is the portrait top-left, cursors key codes are syncd with portrait orientation

- Native QVGA Landscape:
? - not yet tested


The way out of this problem could be to understand when these "magic" coordinate and cursor codes translations are *not* done by windows mobile:
- Only in QVGA emulation mode? In this case - how to detect it?
- And is PocketFrog DeviceToLogical-like translation also needed in any native QVGA device?
- Could it be related to PHAL using GAPI? Is so is there a way to detect its use? I'm guessing the problem will not happen in GDI blitting? (Thierry help!)

With all WM5 devices supporting landscape and many new resolutions that WM 6 will bring, landscape will be more and more used, so this is quite a problem...

Thanks for any information,

Jorge Diogo
Ludimate - http://Ludimate.com

[Ludimate]

An update on this issue: I received a few more reports from people with different devices and it appears that there is not a pattern for the stylus and cursors mapping. It varies between devices with the same characteristics, as far as I can see.

So I just moved on with this solution: each time the PPC build runs in QVGA and it's not in orientation DMO_0 I display an "Input Calibration" screen (shown only once) where the user is asked to click with the stylus in a part of the screen and after that to press the up cursor key. This way I derive and store the mappings for that orientation, solving the problem.

No such problems in VGA, where the mapping is always correctly done by Windows.

Noticed that when PHAL runs, possibly due to GAPI, the orientation angle (as retrieved from the OS by the usual method) is also mapped! For example suppose when the game launches the device is in DMO_90; after the PHAL display is created, orientation is set to DMO_0 till the PHAL display is deleted, after which the orientation is again retrieved as DMO_90. Any orientation changes that the app does while PHAL runs are also mapped with respect to its fake DMO_0 (but usually mess the screen).

Best Regards,

Jorge Diogo
http://Ludimate.com

[jaguard]

Yes, Landscape is totally broken. Whenever user runs it in windows landscape, stylus reports wrong coordinates. I don't really care and recommend users to run in portait (which is fun, since games themselves are landscape), but this is what Thierry didn't make work. Might be because he abandoned pocketfrog before WM5 was actually released, and on-the-fly swithing was introduced there.
And so the same problem is everywhere(pocketfrog, pockethal), whatever devicetological functions should do, they just dont work at all. Or maybe don't always work, which is much like the same.

[Kzinti]

So let's make it work. Ludimate is currently testing a DirectX Mobile built to fix issues with the Blackjack devices. Once this is done, I will attack the input orientation issues.

[Kzinti]

Fixed in 1.0.3.