Mouse Clicks on the Pocket PC

[AndyH]

In another thread, I was testing a game on a Pocket PC and it was behaving differently to the same game compiled for Windows due to the mouse input.

It seemed like mouse clicks were always one behind in the game, and on dialogue screens pressing buttons required a long firm press on the screen but only for the PPC version.

I've not got the source to the game to test more thoroughly so I've been trying to replicate the possible behaviour and here's what I found.

Code (glbasic) Select Expand

SETSCREEN 320, 240,1
LIMITFPS 60

GLOBAL running = TRUE
GLOBAL mx, my, ma, mb

LOCAL t
FOR t = 0 TO 900
LOADSPRITE "test.png",t
NEXT
LOADSPRITE "gui3.PNG", 1000

WHILE running = TRUE


IF KEY(0) OR KEY(200) THEN running=FALSE

MOUSESTATE mx,my,ma,mb

PRINT "Mouse x="+mx+" y="+my+" buttons L="+ma+" R="+mb, 10,10

LOCAL t
FOR t=0 TO 620
DRAWSPRITE RND(899), RND(320), RND(200)+40
NEXT

DRAWSPRITE 1000,30,30

SHOWSCREEN
WEND

PRINT "Mousewait", 10,10
SHOWSCREEN
MOUSEWAITTried several scenarios, but the code above is loading a lot of duplicate sprites and detecting the mouse inputs.  I've not used any mp3's, wav's, various graphics operations, file I/O and other things that might be going on in the original game so obviously this is a limited test.

First of all, the above code with a smaller for loop to display sprites (say 120 instead of 620) ran at full speed.  Mouse x,y and buttons were very responsive.  No problems there at all.

With the for loop displaying many sprites per frame (620), it slows down my Pocket PC.  Mouse responsiveness is still good - keeping up with the screen refreshes although the FPS is not at full speed.

What I did notice was the Left mouse click (variable ma) would rarely register a 1 if I did quick-medium length clicks.  I guess this is understandable because I am probably pressing the pen on the screen and off again in between calls to the MOUSESTATE command.  The X and Y position of the mouse is always updated.

My guess is that original game on the PPC may not always be picking up the mouse button, which is possibly causing the odd behaviour on the PPC but not when running on Windows.  I'd also guess that perhaps there is some other logic dependant upon the mouse clicks registering in the game to make it work correctly.  So the above test suggests this could be the likely cause of the problem.

Question is... will the GP2X exhibit a similar issue as the Pocket PC?  My PPC is not that slow, but it's not a high spec processor and I have no idea how it compares to the GP2X in real terms.

Second question, what is the best way to catch the mouse click events if MOUSESTATE misses them?  Is there a work around?  I've just spotted the MOUSEAXIS() command which can read mouse button states, but I wonder if that would suffer the same problem where it will return the value of the current mouse button state at that point in time (ie: pressing on the PPC's touchscreen or not).

I guess you can compensate in your game to design for a longer mouse press, should you want to support the platform.

[Ian Price]

Well, the above is more or less exactly how I did my game, with a simple MouseState command, Andy, so any info you gain from this would appear to be beneficial to all.

Thought: Maybe the scrolling background in my game is eating up more clock-cycles than a ppc can realisticly handle. If I include an option to remove the background, that may speed things up a bit. Would you mind testing this Andy? This will probably make a big difference.

[AndyH]

Certainly.  Could you put a check in for the keys - cursor up (200) or something similar to quit out of the level so I don't have to do a reset.  The Esc key does not exist on the PPC.

You know the game animates smoothly even with the background.  But it does slow down noticably when the question dialogs pop up... Any ideas what's different there?

[Kitty Hello]

OH dear. The mousestate returns the current state of mouse button/pen. Thus, when you poll the pen, but it's not down at this very time point, you will receive "0".
Hm... I think I'll store the "1" until you poll next time in an update.