07-16-2008 06:42 AM
I am porting a game for the Blackberry using the existing code base, however I seem to be coming across a strange problem.
All the button keys work perfectly in game, however I am trying to get the trackball on the curve to function as directional presses and the click/ball press to function as fire, but it seems to not function. The key presses get recognized and I can capture the key code however, the flag does not stay on long enough for me to capture the event as if it call key pressed then key released straight after. Anyone seen this before? Can I prolong the event so it stays on for at least a frame without hacking the thing? Or do I have to go into the Blackberry APIs in order to do this and drop canvas altogether.
Any help is very much appreciated.
07-16-2008 08:43 AM
If you're using MIDP APIs on the BlackBerry for a game, you will run into a variety of issues -- mainly around performance and input. I have found that it is far more reliable to use the native BlackBerry APIs for gaming on the BlackBerry. You have full control that way and can process inputs reliably.
As a general rule of thumb though, I suggest processing input asynchronously from painting/game ticks or you are liable to encounter issues like you note.
07-16-2008 10:49 AM
The key presses get recognized and I can capture the key code however, the flag does not stay on long enough for me to capture the event as if it call key pressed then key released straight after. Anyone seen this before? Can I prolong the event so it stays on for at least a frame without hacking the thing?
Can you elaborate on what you are doing here and/or post some sample code? What BlackBerry handheld software version are you testing on? You can find this under Options, About on the BlackBerry.
07-16-2008 12:35 PM
I have an array of booleans which on a key press, get set to true and hence on release, get set back to false in the canvas keyPressed( int ) and keyReleased( int ) methods.
In the game loop, there is a check to see if the key has been pressed this frame, so it checks to see if the particular button is true or false.
Using the keypad, this works fine as the flag is set long enough for the engine to recognize that there has been input (it gets reset the next frame). Using the trackball, it seems the whole process happens so quick that the flag is more or less reset instantly and hence on updating the game, the flag is always false and never recognized.
I can hack it, but I was thinking there were ways in which I could use RIM callbacks to do it properly without having to change the canvas class completely, and hence increase porting times.
The phone version is Blackberry 8320 v184.108.40.206 (platform 220.127.116.11)
Thanks for the help
07-16-2008 12:46 PM
You have a race condition between your two thread: Event thread and Game thread. Since they act asynchronously, in your case, there's no way to guarantee that your event thread will process the keydown before the keyup occurs. You need to use a different method of tracking the keydowns and keyups that does no involve one single flag as you need to be able to detect, independently, if a keydown and/or keyup occurred in the time between your game thread's last check of the flags.
This will not be a problem localized to the BlackBerry, it's a design problem with the way you're flagging key events. One simple solution is to use two sets of flags: one for keydowns, one for keyups. This was you can track each event separately. And get 4 states:
- key has not been pressed or released
- key has been pressed but not released
- key has been pressed and released
- key has been released but not pressed (i.e. the key was held down for more than one game tick)
Obviously you can increment the flags rather than use them as binary options to detect multiple events as well for the same key.
if you use the RIM APIs, you'll still have to simulate the keyUp event form the trackball as it does not have the keyDown/keyUp state that a key does. I'm not sure the behavior in the MIDP side on BlackBerry as I only use the native classes.
07-17-2008 06:23 AM - edited 07-17-2008 06:29 AM
It appears the problem is related to the handset not recognizing/processing the trackball as a system key press. I was obviously on the complete wrong tracks.
I will just implement keylistener for the trackball and hopefully it will be problem solved, unless there is a way of capturing those presses as commands instead?
Cheers for all the help and apologies for the wild goose chase.