C++ G-Sensor Klasse für Device Emu und PocketFrog/PocketHAL

Ich hatte mir mal eine Klasse für den HTC G-Sensor gebaut, vor allem weil ich nirgends Möglichkeiten finden konnte, dann auch Code im Mobile Device Emulator testen zu können.
Auch fehlte mir ein simples aber brauchbares Event Handler System auf Basis von Callback Handlern.

Diese Klasse soll all denen helfen, die entweder im Mobile Device Emulator mit dem G-Sensor experimentieren wollen oder mit PocketFrog/PocketHAL oder anderen Game Lib's schaffen und den G-Sensor umsetzen wollen.

Verwendung des G-Sensor in PocketFrog

Bitte auch in GSensor.h und Sensor.cpp schauen, der Code ist recht gut dokumentiert, allerdings in schlechtem englisch .

1. Erzeuge Datenmember in deiner myGame.h und inkludiere die G-Sensor deklaration

Code:

#include "GSensor.h"

class myGame : public Game
{
    ...
public:
    HINSTANCE   m_hInstance;
    GSensor     m_GSensor;
};

2. Speichere hInstance ins Datenmember

Code:

int WINAPI WinMain( HINSTANCE hInstance, HINSTANCE, LPTSTR, int )
{
    _Module.Init( 0, hInstance );

    myGame game;
    myGame.m_hInstance = hInstance;

    myGame.Run();

    return 0;
}

3. Initialisieren des G-Sensor in myGame.cpp

Code:

bool myGame::GameInit()
{
    Display* pDisplay = GetDisplay();

    ...

    m_gSensor.Initialize( g_hInstance );  // initialize G-Sensor system
    m_gSensor.WaitToInitialize( 1 );      // wait 1 second

    return true;
}

Wie hier recht gut zu sehen ist, es wird eigentlich nur das Instance-Handle der Anwendung gebraucht um den G-Sensor zu initialisieren.
Das sollte in allen möglichen Anwendungstypen möglich sein.

Wie bekomme ich die Daten vom G-Sensor

Die Klasse bietet eine ganze Reihe an Methoden an.

für den Tilt-Sensor:

DWORD GetSensorData( PSENSORDATA a_pSensordata );
DWORD GetAngleX( void );
DWORD GetAngleY( void );
SHORT GetTiltX( void );
SHORT GetTiltY( void );
SHORT GetTiltZ( void );

Für den Gesture- und den D-Pad Sensor

bool IsPaneTouched( void );
bool IsPaneLeftTouched( void );
bool IsPaneRightTouched( void );
bool IsPaneWheelTouched( void );
bool IsPaneWheelCenterTouched( void );
BYTE GetPaneLeftTouchedX( void );
BYTE GetPaneLeftTouchedY( void );
BYTE GetPaneRightTouchedX( void );
BYTE GetPaneRightTouchedY( void );
BYTE GetPaneWheelAngle( void );

und für den Wechsel der Orientierung

ENUM_ORIENTATION GetOrientation( void );

Wie wird das Callback Event Handler System verwendet

Zuerst, jeder eigene Event-Handler hat diese Signatur:

Code:

void OnMyEvent( void );

Definiere für jedes gewünschte Event je eine eigene Funktion mit der obigen Signatur.

Einen CAllback Handler verbinden

Die Klasse hat drei Callback-Handler Systeme:

A: Events beim ändern der Orientierung

enum ENUM_ORIENTATION
{
ORIENTATION_LANDSCAPE = 0,
ORIENTATION_REVERSE_LANDSCAPE = 1,
ORIENTATION_PORTRAIT = 2,
ORIENTATION_UPSIDE_DOWN = 3,
ORIENTATION_FACE_DOWN = 4,
ORIENTATION_FACE_UP = 5,
ORIENTATION_UNKNOWN = 6
};

B: Events am Gesture-Sensor

enum ENUM_GESTURE
{
GESTURE_ROTATION_CLOCKWISE = 0,
GESTURE_ROTATION_COUNTERWISE = 1
};

C: Events am Touch-Pad Senor

enum ENUM_TOUCH
{
TOUCH_PANE = 0, // Einer für alle!
// oder separat, benutze TOUCH_PANE und die folgenden nie zur gleichen Zeit
// denn Touch_PANE wird dabei auch immer aufgerufen!
TOUCH_PANE_LEFT = 1,
TOUCH_PANE_RIGHT = 2,
TOUCH_PANE_WHEEL = 3, // gesture pane
TOUCH_PANE_WHEEL_CENTER = 4
};

Jeder Event-Typ hat seinen eingenen Connector.

Beispiel für Orientation Events:
Handler verbinden

Code:

m_GSensor.ConnectCallbackHandler( 
    GSensor::ORIENTATION_PORTRAIT, 
    OnOrientationPortrait );

Der Event-Handler hat dabei folgende Signatur:

void OnOrientationPortrait( void );

Also wird für jedes gewüschte Event je eine Funktion geschrieben und diese dann per ConnectCallbackHandler mit dem G-Sensor verbunden.
Den Enum (oben) sind die möglichen Handlertypen leicht zu entnehmen.

Beispiel für Gesture Events:

Code:

m_GSensor.ConnectCallbackHandler( 
    GSensor::GESTURE_ROTATION_CLOCKWISE, 
    OnRotateClockwise );

und ein Beispiel für das Touch-Pad:

Code:

m_GSensor.ConnectCallbackHandler( 
    GSensor::TOUCH_PANE_LEFT, 
    OnLeftPaneTouched );

Beachte: Der Tilt Sensor hat kein Event-Handler System!
Dessen Daten können nur per Polling abgefragt werden.

Verwenden des G-Sensor Emulator-Mode für den Windows Mobile Device Emulator


Kommentiere Zeile 7 in GSensor.h aus, das ist alles!

Wenn Du das gemacht hast werden eine ganze Reihe weiterer Methoden für den Emulator Mode aktiv. Mit diese können die Daten im G-Sensor verändert werden.

bool SetOrientation( ENUM_ORIENTATION a_enumOrientation );
void SetSensorData( PSENSORDATA a_pSensordata );
void SetAngleX( DWORD a_dwAngleX );
void SetAngleY( DWORD a_dwAngleY );
void SetTiltX( SHORT a_sTiltX );
void SetTiltY( SHORT a_sTiltY );
void SetTiltZ( SHORT a_sTiltZ );
void SetPaneTouched( bool a_bIsPaneTouched = true );
void SetPaneLeftTouched( bool a_bIsPaneLeftTouched = true );
void SetPaneRightTouched( bool a_bIsPaneRightTouched = true );
void SetPaneWheelTouched( bool a_bIsPaneWheelTouched = true );
void SetPaneWheelCenterTouched( bool a_bIsPaneWheelCenterTouched = true );
void SetPaneLeftTouchedX( BYTE a_byPaneLeftTouchedX );
void SetPaneLeftTouchedY( BYTE a_byPaneLeftTouchedY );
void SetPaneRightTouchedX( BYTE a_byPaneRightTouchedX );
void SetPaneRightTouchedY( BYTE a_byPaneRightTouchedY );
void SetPaneWheelAngle( BYTE a_byPaneWheelAngle );

Wenn Du Daten änderst, werden die verbundenen Callback-Handler aufgerufen!

Du kannst so testen, wie sich die Anwendung verhält - wenn sie bestimmte Sensordaten empfängt.
Klar ist natürlich: Der Emulator-Mode bietet nur eine Schnittstelle um die Sensordaten zu manipulieren, den G-Sensor wird nicht wirklich emuliert.
Er liefert die Daten, die Du ihm gegeben hast, nicht mehr und nicht weniger.
Immerhin, zum Testen im Geräteemulator ist das schon mehr als genug.

Wenn Du z.B. SetOrientation(...) aufrufst werden auch alle dazu gehörenden Sensor-Werte geändert:
AngleX, AngleY, TiltX, TiltY, TiltZ und - wenn verbunden - auch der dazu gehörende Event Handler aufgerufen.

Im echten Gerät muss man die Daten dann nicht von Hand setzen, der Rest bleibt aber gleich. Von daher nutze ich den Emulator-Mode recht intensiv.

Ich hoffe die Klasse ist hilfreich für dich.
Viel Glück und hab Spaß damit!


Grüßle CF

Downloads:
GSensor.h: http://www.desktophilfe.de/down/GSensor.h
GSensor.cpp: http://www.desktophilfe.de/down/GSensor.cpp

Hier noch eine kleine Orientierungshilfe:

Ich bin immer mal gefragt worden, warum Event basierte Callback Handler UND Polling in der Klasse drin ist.
Der Grund hierfür ist recht einfach. Während es den meisten kleinen App genügt, die wenigen Sensordaten dann abzufragen, wenn sie gebraucht werden (was vollkommen normal ist beim Tilt-Sensor), wird es komplexeren Sensorabfragen schon sehr aufwändig.

Will man in z.B. einem Game-Loop ständig wissen, ob sich die Orientierung geändert hat und erst dann reagieren - wird man feststellen über 95% der Pollingabfragen waren umsonst, da sich die Orientierung seltener ändert.

Welchen Sinn macht es also, diese Daten ständig abzufragen und den eigenen Loop unnötig zu belasten? Keinen!

Durch das Callback-Eventsystem kann die App auf die Änderung der Orientierung reagieren ohne aktiv den Status pollen zu müssen, die App ist also passiv und lässt sich ganz bequem informieren wenn sich was geändert hat.
Während also das aktive Sensorpollen zu mehr als 95% umsonst ist, wird die App bei einer Änderung benachrichtigt und das genau zu der Zeit wo es passiert. Der Unterschied ist erheblich!

Nehmen wir jetzt noch andere Sensordaten, die sich seltener ändern, wie z.B. gesture (Wheel) oder die Pads, dann wird der gesamte aktive Pollingaufwand schon fast inakzeptabel hoch. Das summiert sich immer mehr und man fragt sich wo die schönen FPS geblieben sind, die man mal hatte...

Ein Vergleich dazu: Du wartest auf ein ganz wichtiges Packet, hast daheim noch viel zu erledigen aber schaust alle 30 Sekunden zur Türe raus ob der Postbote schon da ist. Macht das Spaß?

Ist es nicht besser zu sagen - ich mache meine Arbeit daheim, der Postbote klingelt (mein erwartetes Event!) wenn er da ist?

Wem die Infos nicht reichen soll halt weiter pollen... .

Nur mal so zur Info: die meisten Anwendungen des Hobby-Programmierers verbraten in Schleifen mind. 60% der verfügbaren CPU Zeit und das genau genommen mit NICHTS tun.

Version 1.3 ist online, kann über die beiden obigen Links runtergeladen werden.
Über Feedback würde ich mich natürlich auch freuen

Grüßle CF

Hi CF,

auf der Suche nach Infos über die G-Sensoren bin ich auf Deinen Beitrag gestoßen. Wollte mir die Klasse gern mal anschauen ... aber die Links sind "leer", d.h. die Files existieren nicht. Könntest Du sie noch einmal online stellen?

Vielen Dank und beste Grüße,
skydiver

Hey skydiver,

die Files sind wieder on.
Kannst Dich bei Fragen gerne melden, über Feedback würde ich mich auch freuen.

Schönes Wochenende!
CF

Du darfst die Files sonst gerne auch hier als Anhang hochladen

Zitat von yjeanrenaud

Du darfst die Files sonst gerne auch hier als Anhang hochladen

Danke das ist mir schon klar .
Ich habe aber lieber selber die Kontrolle über meine Files, zumal ich so auch leichter Updates drüber bügeln kann.
Bisher hat sich wohl eh noch niemand für den Kram interessiert.
Naja ist erst mal wieder on...

Grüßle CF

Klar war ja nur ein vorschlag. Finde ich super, dass du die Klassen teilst!

Zitat von yjeanrenaud

Klar war ja nur ein vorschlag. Finde ich super, dass du die Klassen teilst!

Wir verstehen uns schon .

Hi CF,
also ich muss zugeben dass ich gerade erts meine ersten Schritte bei der Softwareentwicklung für WinMob gehe. Mein Background sind fast 20J C/C++ im Unix-Umfeld aber auch größere Projekte unter Windows, haupts. MFC-bas.. Deswegen verzeihe man mir die oder andere "blöde" Frage
Ich habe eine kleine dialogbasierende Demo-App geschrieben und Deine Klasse wie beschrieben verwendet. Beim initialisieren bekomme ich die Fehlermeldung, dass "HTCAPI.dll" nicht auffindbar ist. Das ist nachvollziehbar, sie ist tatsächlich nicht da. Die Frage die sich mir stellt ist, wie fragen die Applikation auf meinem HTC Touch HD, die aktuell erfolgreich mit dem G-Sensor arbeiten, diesen ab? Irgendeine Idee?

Danke

Hallo skydiver,

Programmatisch wird das wie folgt getestet:
- mit LoadLibrary (WINAPI) wird versucht die DLL zu laden, schlägt das fehl existiert die DLL nicht.

Der verantwortliche Code ist wie folgt:

Code:

    HMODULE hHTCAPI = LoadLibrary( HTCAPI_DLL );
    if( NULL == hHTCAPI )
        throw new GSensor::GSensorException( GetLastError(), _T( "Unable to load ") HTCAPI_DLL _T( " !" ) );

Wie hier zu sehen, wird eine Exception generiert sofern das Handle ungültig ist, d.h. die DLL nicht gefunden wurde.
Betrifft in dem Fall die Methode SensorGestureInit der Klasse GSensor, also den Gesture-Sensor. Ich habe leider kein Touch HD (wegen chronischer Armut ), von daher kann ich nicht sagen ob dieser Sensor existiert.

Ich könnte den Code so umbauen, das diese Sensor-Teil auch deaktiviert werden können. Dann ginge halt noch der Tilt-Sensor und der Pane-Sensor (je anch dem was eben vorhanden ist).

Bei Fragen nur raus damit

Grüßle CF

Hallo CF,

danke für die schnelle Antwort. Der Teil mit dem laden der DLL war mir schon klar, das habe ich auch schon desöteren so bewerkstelligt. Der wichtige Teil Deiner Antwort war, dass die Funktion die Du aus der DLL benutzt sich auf nur auf den Gesture-Teil bezieht. Da der HTC Touch HD diesen ja gar nicht besitzt ist auch klar, warum die DLL nicht da war Ich hab' mir die DLL trotzdem mal installiert um so Deine Klasse in einem kleinen Demo-Progrämmchen testen zu können. Ich hab' das Teil mal angehängt, Rotation, Gesture und Touch via CB, Tilt und Angle via Poll (WM_TIMER, 200ms). Ach ja, getestet nur auf einem HTC Touch HD.

Vielen Dank!!

PS: >> Ich habe leider kein Touch HD (wegen chronischer Armut ),
Den hätte ich auch nicht, wenn meine Frau nicht einen neuen Vertrag gebraucht hätte und ich das Teil sehr günstig am Web gefunden hätte

Hey skydiver,

da Du der erste bist der wohl mit dem Kram "rummacht" würde mich mal interessieren wie Du mit der Klasse un dem Code zurechtgekommen bist.
Ich habe ja sonst keinerlei Testergebnisse als die von meinem Gerät .
Hast Du auch mal den DEBUG-Modus getestet?

Grüßle CF

PS: Deinen Test schau ich mir grad mal an

@CF

Meinst Du mit DEBUG-Mode den Simulationsmode (_EMULATOR_MODE_)? Weil ansonsten der _DEBUG_ Mode sich (zumindest bei mir ) nicht wirklich vom Release-Mode unterscheidet. Den _EMULATOR_MODE_ habe ich noch nicht getestet, weil ich "scharf" auf den Sensor war

Falls Du VS2008 benutzt kann ich das Demo-Projekt ja mal zippen ...

Beste Grüße,
skydiver

Joah ich meine schon den EMULATOR_MODE

Also Dein Tool läuft bei mir auf Anhieb, man kann auch schön das "flimmern" vom Tilt-Sensor sehen. Good work
Der Sensor tut, kein Thema - interessant wirds dann bei einer "echten" App, die teilweise auch im Emulator gelaufen ist. Bis jetzt weist Du ja erst mal nur das der Sensor tut und wie man ihn verwendet (immerhin!).

Bin wirklich gespannt ob Du dann noch was richtiges baust.

Ich nutze noch VS2005 und hab schon gesehen das Du ne MFC-App zusammengestrickt hast, von daher muss ich mir den Code nicht zwingend ansehen.
Wäre mal interessant gewesen zu sehen, wie andere mit meinem Code zurechtkommen

Verbessern kann man immer was, ohne Feedback ist halt schwierig...

Grüßle CF

Den EMULATOR_MODE werde ich evtl. heute Abend mal testen.

Als eine echte App viel mir vor ein paar Tagen (weil bei Google das gleichnamige Logo auf den "Geburtstag" des Spiels hinwies) Tetris als ein intressanter "Playground" ein, in Verbindung mit dem Tiltsensor. Gibt es zwar schon, aber mir gehts wenige um das Spiel selbst als mehr um die grafische Ausgabe. Hab' da reichlich und ziemlich gute Erfahrungen unter Windows gemacht - aber wie schon erwähnt, noch gar keine unter WinMobile.

>> Ich nutze noch VS2005 und hab schon gesehen das Du ne MFC-App zusammengestrickt hast, von daher muss ich mir den Code nicht zwingend ansehen.

Wie meinst Du das? Entwickelst Du "plain vanilla" win32 oder .NET? Plain vanilla wäre für mich auch recht interessant, habe ich früher gemacht. Super Performance aber bei größeren Apps wird's leicht unübersichtlich ...

Beste Grüße,
skydiver

Ne ganz normal plain C++ (ohne .NET und mit, je nach Laune), ab VS2005 pro ist Enwickeln für MS Mobile direkt integriert und entsprechende "Assis" vorhanden. Der Code kann direkt native auf dem Gerät ausgeführt werden oder halt im Emulator.
Von daher sehe ich (noch) keinen Grund auf VS2008 zu wechseln .

MS Mobile Entwicklung ist also in der Umgebung völlig transparent integriert, man wählt halt passenden Projekt-Typ (MFC, Win Api oder sonst was) und kann direkt loslegen.
Debuggen etc. ist bereits vollwertig vorhanden (auch native), was will das Entwicklerherz mehr?

Jo, das hab ich ja auch schon alles rausgefunden. Ich benutze VS2008 beruflich - bis jetzt aber noch nie für Mobile. Hab mir das Mobile-SDK6 runtergeladen (standardmäßig ist nur 5 integriert). Die ersten Demo-Apps habe ich auch auf'm Emu laufen lassen ... noch bevor ich meinen HD hatte ) (so bin ich glaube ich erst auch auf'n Windows Mobile Phone gekommen ...).

Zu VS2008 bin ich gewechselt weil ich gehofft hatte dass es ein paar weniger Bugs enthält und sich wieder mehr auf "Funktion" konzentriert. Ich vermisse immer noch das gute alte VS6.0 ...

>> Ne ganz normal plain C++
Ja, ist MFC im Grunde auch ... ich meinte welchen Projekttyp benutzt Du meistens für WM?

Also wenn's nur mal schnell ein Test sein soll oder ne App mit ordinärer GUI - da meist MFC Projekte, sonst meist Win32.
Klar wird's dann schnell unübersichtlich, aber mir ist das lieber so.
Bei GUI Sachen (für Spiele) nutze ich nur noch PocketHAL/PocketFrog was letztendlich auch wieder Win32 ist.

Mit Bugs im VS2005 habe ich keinerlei Probleme, zumindest nicht seit dem letzten SP.
Das Einzige, was mich im 2005 nervt ist die fehlende Aufgaben-Übersicht (TODO: alle Aufgaben), aber dafür habe ich mir ein Plugin gebastelt.

Ja VS6 war schon gut durchdacht, ich benutze das auch noch beruflich (sowie VS2003 und 2005) - aber auch da hat's Mängel ohne Ende.
Man kommt schon zurecht, wie Du ja sicher selber auch gemerkt hast.

Übrigens bin ich auch erst über den Assi für Win Mobile im VS2005 auf die Mobile Entwicklung gestossen ...
Zuvor hatte ich nen Symbian S60 und damit auch enwickelt, aber das war mehr Krampf als alles andere (Signierung, kostenpflichtige IDE, Abzocke an allen Ecken und Enden).

Grüßle CF

Isss ja putzig ... dann haben wir ja einen ähnlichen "Leidensweg" hinter uns. Ich hatte davor auch ein S60 (E50) ... ich hab' gar nicht erst versucht dafür Software zu entwickeln. Außerdem habe ich sehr WiFi vermisst, was ich brauche um an meine (selbst geschriebene) Home-Automation anzukoppeln. Auf meinem HD bin ich zwar auch noch nicht ganz soweit (ich muss das Interface der Home-Automation noch von CORBA auf plain Socket umschreiben) ... aber ich hab' zumindest schon mal alle "Waffen" dafür parat ...