For progress on the development of a gamepad for blackstone please go to the end of the thread.
was pondering the problem of playing non-touchscreen games on the hd and the lack of control options.
In a basic form what is needed is 8 way direction control and a number of buttons that can be pressed simultaneously:
There are three options that I think are worth investigating:
1) general g pad controls simulated by g sensor plus additional buttons created on a SIP or shell for the games.
2) a software shell that places a touchscreen dpad on one side of the landscape screen and have the light sensor and front camera on the other side as buttons. A keypress would be simulated when the ssensor is covered by a finger. Perhaps the back camera too? This would allow many games to be played, I think.
3) Calculated multitouch. When a resistive screen is multitouched I think this produces an intermediate result between the two touches.
If you created a shell that had precise positions of all the buttons worked out multitouches could be mathematically calculated and then sent as simulated keypresses... n effect creating a virtual and invisible keypad in the middle that only becomes active when more than one button is pressed.
For example pressing up and the (a) button creates a virtual touch in the red circles etc.
If actual touches are intercepted and only virtual touches sent as keypresses this could also work.
My question is for the technical people out there who know much more about this device than me... is there any obvious reason you can see that one or all of these methods would not work?
was pondering the problem of playing non-touchscreen games on the hd and the lack of control options.
In a basic form what is needed is 8 way direction control and a number of buttons that can be pressed simultaneously:
There are three options that I think are worth investigating:
1) general g pad controls simulated by g sensor plus additional buttons created on a SIP or shell for the games.
2) a software shell that places a touchscreen dpad on one side of the landscape screen and have the light sensor and front camera on the other side as buttons. A keypress would be simulated when the ssensor is covered by a finger. Perhaps the back camera too? This would allow many games to be played, I think.
3) Calculated multitouch. When a resistive screen is multitouched I think this produces an intermediate result between the two touches.
If you created a shell that had precise positions of all the buttons worked out multitouches could be mathematically calculated and then sent as simulated keypresses... n effect creating a virtual and invisible keypad in the middle that only becomes active when more than one button is pressed.
For example pressing up and the (a) button creates a virtual touch in the red circles etc.
If actual touches are intercepted and only virtual touches sent as keypresses this could also work.
My question is for the technical people out there who know much more about this device than me... is there any obvious reason you can see that one or all of these methods would not work?
Attachments
Last edited: