Anyone running on a windows treo?

[fast_rx]

I'm wondering if anyone using pocketfrog or PHal is using one of the new treo devices running window mobile. I've gotten reports that there is something strange going on with either the screen drawing or stylus mapping.

They report having to click below my buttons, so it sounds like the stylus has an offset added to it (maybe the values range from 40 to 280 instead of 0 to 240?) It sounds like it is constant across the entire screen, so I don't think it's scaling a x320 screen to the x240 screen.

This is running with phal 0.7.6.

[Kzinti]

The problem is that the GAPI implementation of the Treo 700w says the screen is 240x320. This isn't true. The screen size is actually 240x240. Their GAPI implementation will scale the 240x320 backbuffer to the 240x240 screen, resulting in weirdness.

[Presto]

I had one customer who ran into this problem. The screen was getting compressed to 240x240, and it seems the stylus input was that way too. In the end, I made him a custom build that took the y-coordinate of the stylus and multiplied it by 4/3 before processing.

-John

[Kzinti]

Is the stylus being scaled at all time? Or only when using GAPI? (And PocketHAL).

[fast_rx]

I've sent a test application and haven't heard back yet.

From what I've read in other places, the screen is scaled - but the stylus is not. Hence the need to multiply by 320/240. If both the screen and stylus were scaled, then there wouldn't be a problem, right?

I've also read that including the HI_RES_AWARE resource will 'fix' the problem. I'm not positive if it makes both the screen and stylus 240x240 or if they are both at 240x320...

[Kzinti]

Let me know of anything what you find. The sooner I know exactly what is going on on the Treo, the sooner I can support it in PocketHAL.

[Presto]

The Travel Collection is still in PF 0.7.0, so it's using GAPI for everything. The QVGA backbuffer is getting scrunched to 240x240, and the stylus input is a constant 240x240. Multiplying the y-coordinate by 4/3 is all it takes to make it work correctly. Unfortunately, it's just not as pretty as it should be.

PHAL uses GAPI for the stylus input, doesn't it? Or am I thinking of the hardware keys?

-John

[Kzinti]

PocketHAL doesn't do anything with input... But it does use GAPI for screen access on the Treo (and that's a problem).

The behavior you just described is what I was expecting. What happens if you put in the HIRES_AWARE flag? I suspect it doesn't change anything? (As far as I know that flag doesn't affect GAPI, but I might be wrong).

[BIGBEN]

The Travel Collection is still in PF 0.7.0, so it's using GAPI for everything. The QVGA backbuffer is getting scrunched to 240x240, and the stylus input is a constant 240x240. Multiplying the y-coordinate by 4/3 is all it takes to make it work correctly. Unfortunately, it's just not as pretty as it should be.

PHAL uses GAPI for the stylus input, doesn't it? Or am I thinking of the hardware keys?

-John

What you do to know your game runs on a Treo device?
What happens to graphics? Is it really resized on y?
Or it just shows 240x240 square?
If scrunched means resized - is there any way to avoid this, because it should look awful in games(and also for any bitmap fonts used)!
Are you sure we need to multiply Y-coor by 4/3, not 3/4 for stylus?

Thanks

[Presto]

What you do to know your game runs on a Treo device?
What happens to graphics? Is it really resized on y?
Or it just shows 240x240 square?
If scrunched means resized - is there any way to avoid this, because it should look awful in games(and also for any bitmap fonts used)!
Are you sure we need to multiply Y-coor by 4/3, not 3/4 for stylus?

Thanks

I made a custom build for the guy to see if it would even work. I don't check for device type. (I state right on my product pages that the game is designed for QVGA and VGA only.)

Yes, only the Y gets resized, so it doesn't maintain perspective. He said my options screen looked all grainy, because there's a lot of text on that one. I'm guessing that the Treo simply drops every 4th row... but I'm not sure on that.

Yes, it's definitely 4/3. I tried 3/4 the first time, because that's what happens to the Y-scale of the screen image. A tap at the bottom of the screen, which is normally 319, is only 239 on the Treo, so multiplying it by 3/4 DECREASES it to 179. But you really want to INCREASE a value of 239 to 319, so it's times 4/3. (which actually only equals 318, but close enough)

-John

[fast_rx]

PocketHAL doesn't do anything with input... But it does use GAPI for screen access on the Treo (and that's a problem).

The behavior you just described is what I was expecting. What happens if you put in the HIRES_AWARE flag? I suspect it doesn't change anything? (As far as I know that flag doesn't affect GAPI, but I might be wrong).

This is from an MSDN article about 2003SE - but maybe it still holds true.

GAPI Legacy Support

Applications that use GAPI frequently make assumptions about the screen size based on earlier versions of Pocket PC and Smartphone hardware. To preserve backward compatibility with legacy applications, an emulation layer has been added to GAPI. By default, this layer will scale GAPI drawing to fit the screen; however, a high-resolution-aware application can choose to bypass the emulation layer to have complete access to the display hardware.

To bypass the emulation layer, an application should not call GXBeginDraw or GXEndDraw. Instead, it should call ExtEscape with the nEscape parameter equal to GETRAWFRAMEBUFFER and use the returned frame pointer for drawing.

So I'm a bit confused if HI_RES_AWARE alone would fix it or you would need to use the 'ExtEscape'?

[BIGBEN]

Thank you John for clear explanation!

Could you, please, send him a testing version with the following(I can do the small app build):
Draw first raw with red, second with green, then blue
yellow, white, black, magneta, grey.
8 colors repeated on the screen.

So we would know where Treo does the trick, if it just drops the n'th row(I hope), there would be an easy way to avoid it with a small blank row trick...

And it is much better then adding hiresaware, since it will confuse some people if your game runs not resized on a 1/4 of some true-VGA's screen device

[Kzinti]

So I'm a bit confused if HI_RES_AWARE alone would fix it or you would need to use the 'ExtEscape'?

What you quoted is essentialy saying to not use GAPI and instead use the GETRAWFRAMEBUFFER escape call. This matches my experience: you don't want to use GAPI on non-QVGA Pocket PCs.

Adding the HIRESAWARE flag doesn't change the behaviour of GAPI in any ways.

There is an emulation layer for legacy application, but it only applies to GDI (and not GAPI). That emulation will be disabled by the HIRESAWARE flag. Again this is orthogonal to GAPI functionality.

So what you want to do on the Treo is NOT use GAPI. But then you need to handle a 240x240 display in your game. The alternative solution is to keep using GAPI and scale your vertical stylus input by 4/3.

[BIGBEN]

Well in this case the same thing should happen on other 240x240 devices. Am I right?
In this case GetSystemMetrics(SM_CYSCREEN)should be enough to track this devices.

Kzinti, what should I do to make my game run in PFrog+PHal in not resized 240x240(screen) on Treo?

[fast_rx]

Well in this case the same thing should happen on other 240x240 devices. Am I right?

No. I had another guy with an HP hw6515 that is a 240x240 device. It works fine 'as-is' on that device. I've used display->GetHeight everywhere and the only thing I had to change was to make sure menu items don't fall off the bottom of the screen. Of course, I didn't see it with my own eyes - so it could have been scaling the vertical from 320 to 240.

So what you want to do on the Treo is NOT use GAPI. But then you need to handle a 240x240 display in your game.

How do I tell pocketfrog/phal to not use GAPI?

I am handling the screen resolution properly, I think. It works fine on the new arm emulators in the square configuration - I can even run it on the smartphone emulator at 176x240.