3. USB Gamepad "programmieren"

USB Gamepad "programmieren"

  • F

    Ne ganz einfache Methode wäre es ein Joystickport zu verwenden. Da könntest Du einfach zwei Lichtschranken anschließen und auslesen. Hat den Vorteil es ist super einfach gebaut und die Software ist sehr schnell geschrieben.
    Nur mit den Reaktionsgeschwindigkeiten weiß ich im Moment nicht genau.

    Der Rechner kann das auf jeden Fall messen. Es sind ja nur Zeiten im Bereich von 1/18 Sekunde.

    Prinzipiell gibt es bessere Busse für solch einen Fall (wenig Daten - hohe Reaktionszeit). Da wären der CAN-Bus, TWI und andere Feldbusse. Nachteil: die Ankopplung an den PC. Da sollte man sich schon mit Hardware auskennen.

    0
  • G

    Hi
    bin gerade dabei mir die Infos zu direct input auf der MSDN Seite anzuschauen. Da könnte man u.U. was mit anfangen.
    Das ganze muss nicht sonderlich unabhängig sein. Ich gehe mal davon aus, das die meisten Direct X installiert haben. Und wenn nicht sollen sie es nachholen;-)
    Hat einer ein gutes Tut zu Direct Input?
    Kann ja nicht schaden wenn man mehrere Infoquellen hat. Das MSDN finde ich nicht immer einleuchtend geschrieben.

    Gameport geht nicht. Die Autos fahren nur extrem selten in der Wohnung rumm wo der heimische Rechner steht. Und viele Laptops haben keinen Gameport.
    Das nen CAN Bus ein klein wenig besser geeignet wäre kann ich mir vorstellen. Aber der ist unter den Heimanwendern doch eher selten zu finden;-)

    Vielen Dank schon mal
    Nils

    PS: Für weiter Ideen bin ich immer offen!

    0
  • S

    1. Bzgl. Plattform war hier nicht gemeint, dass es jeamnd nicht installiert hat (Jeder WinXP-User hat min. Version 8 oder sowieso 9) sondern, dass er es nicht installieren kann weil er zB Linux verwendet. Wenn du aber sowieso Windows verwendest sehe ich da kein Problem.

    2. Um DirectInput zu verstehen reicht eigentlich das Tutorial in der Doku+Samples die mitgeliefert werden 😉

    MfG SideWinder

    0
  • G

    Ich fand vieles in der MSDN auf den ersten Blick auch einleuchtend. Aber manchmal hilft es einfach wenn der selbe Sachverhalt nochmal in anderen Worten erklärt wird. Mal schauen wie weit ich damit komme. Wenns nicht klappt nerv ich euch;-)

    Zur Plattformunabhängigkeit: Das sind zum größten Teil keine Computer Freaks. Da kann man von ausgehen das Windows XP eingesetzt wird. Und wie du schon sagst: Direct X ist auch da. Das ist also kein Thema.

    Ich glaube ich fahre die Tage mal zum Promarkt oder so und hol mir so ein billig Teil.

    greetz
    Nils

    PS: Ich hab nurnoch ne VS 6.0 Lizenz. Sollte aber langen oder hat jemand nen Tipp für ne gute Open Source Entwicklungsumgebung? Evtl. gibts ja gut Eclipse Plugins?

    0
  • S

    Für DirectX ist es das beste wenn du beim VC bleibst.

    MfG SideWinder

    0
  • ?

    Gaunt schrieb:

    PS: Ich hab nurnoch ne VS 6.0 Lizenz. Sollte aber langen oder hat jemand nen Tipp für ne gute Open Source Entwicklungsumgebung? Evtl. gibts ja gut Eclipse Plugins?

    Ich hab vor kurzmem recht gute Erfahrungen mit CodeBlocks gemacht. Wenn du bei VS6 bleiben willst müsstet du dir AFAIK ein älteres DX SDK (8?) besorgen, ansonsten ist das natürlich auch gut.

    Bye, TGGC

    0
  • F

    Du könntest es natürlich auch komplett PC-unabhängig bauen. 😃

    0
  • T

    frosty schrieb:

    Der Rechner kann das auf jeden Fall messen. Es sind ja nur Zeiten im Bereich von 1/18 Sekunde.

    Abe rnur wenn man mit den richtigen Methodiken misst. Das sind rund 55ms, manche Timer können nicht genauer auflösen. Denkt also dran eine brauchbare funktion für die zeitgabe zu nehmen, unter Windows z.B. was wie Google: site:msdn.microsoft.com QueryPerformanceCounter / Google: site:msdn.microsoft.com QueryperformanceFrequency

    0

  • Das Problem ist eher nicht, ob der PC solche Zeiten messen kann, sondern ob der Knopf auf einem Gamepad so schnell reagiert. Also ich hatte sowas mal für meine Autorennbahn mit'm C64 gebastelt, und da musste man mit ganz fiesem Assembler abfragen, denn sonst hat er einfach nicht gemerkt, das der Kontakt kurz geschlossen war.

    Bye, TGGC

    0
  • F

    Das Tastenprellen kann schon zu nem Problem werden. Stimmt! Wahrscheinlich wird der Treiber kurze Impulse herausfiltern und dann kommt man so nicht weiter.
    Tastenprellen kann ne 3/4 Millisekunde dauern.
    Hmm, würd einfach der Sache etwas mehr Hardware spendieren damits läuft. Bin aber auch technischer Informatiker.
    Sonst hängt es von den Methoden zum einlesen ab wie viel Aufwand es kostet das auszulesen. Man kann mal überschlagen wie lang der Knopf gedrückt wird. Vielleicht ließe sich etwas mit einer größeren Flache über dem Knopf was machen. Könnte dann aber Probleme mit dem Gewicht der Autos geben.
    Stell mir das in etwa so vor:

    _________
/    |    \
     K

    K ist der Knopf.

    Ciao

    0
  • G

    Hm
    Also eine Strecke von 2m wird bei 120km/h in 0,06Sek überfahren.
    Wenn das Auto 20cm lang ist könnte es max 0,015sek den Taster auslösen. Zur Trägheit des Tasters kommt noch die Trägheit der Messung (Schleife, Lichtschranke...) hinzu. Ich kann ja schlecht das Auto über das Pad fahren lassen;-) Nehmen wir mal an das der Schalter nur 0.005 Sek betätigt bleibt.
    In der SDK Doku glaube ich übrigens gelesen zu haben das man min 1000/sek das Pad abfragen kann. Das würde also eine Auflösung von 0,001 ergeben was theoretisch langen würde da in der Zeit das Pad 5 mal abgefragt wird.
    Evtl könte man ja noch nen Flip Flop oder ein haltendes Relay davor setzen?!? Das gibt dann wieder so nen Hardware Aufwand.

    Mal was anderes: In der SDK habe ich gelesen das ich das Pad abfragen muss. Weiß einer ob es nicht möglich ist aus dem Tastendruck ein Event zu generieren?

    Ich habe mir gestern übrigens ein Pad geholt. Auslegeware vom Mediamarkt für 3€. Dann ich ich eigentlich nix falsch gemacht haben. Das läuft zumindest mit dem Demoanw. der SDK von DX 9 problemlos (die sich auch mit VC6 kompilieren lies [irgendeiner meinte ich solle 8.0 nehmen]). Weiter bin ich aber leider nicht gekommen. Ich muss mich wohl erst mal wieder mit dem drumm herum anfreunden. Ich habe bestimmt seid 2 Jahren nix mehr mit VS und C++ gemacht. Irgendwie finde ich Java angenehmer aber das gehört hier nicht her. Wenn am WE schlechtes Wetter ist setze ich mich mal drann. Kann ja eigentlich nicht so wild sein.

    Das mit dem überfahren eines großen Schalters geht nicht. Die Dinger habe teilweise nur 2mm Bodenfreiheit. Das gibt ein witziges Bild wenn dann ein 120KM/h Geschoss über einen 5mm Kiesel fährt. Das sieht aus als würde unter einem F1 Auto eine Handgranate explodieren. Die Dinger fahren und auf einmal heben sie unvermittelt ab 😮

    Vielen Dank an euch alle. Das hat schon einige interessante Aspekte zu Tage gefördert. Ich halte euch auf jeden Fall auf dem laufenden!

    THX
    Nils

    0
  • F

    Aber wie willst Du dann den Schalter betätigen?
    Nen Relais kannste schonmal ganz vergessen -> zu Träge. Und ein Flipflop auch. Du kommst bei den Schaltzeiten in den Bereich des Tastenprellen. D.h. Es wär nicht vorhersehbar ob das Flipflop richtig auf die Eingabe des Schalters reagiert. Zumindest bei asynchronen Flipflops.

    Dann viel Erfolg!

    0

  • Gaunt schrieb:

    Das läuft zumindest mit dem Demoanw. der SDK von DX 9 problemlos (die sich auch mit VC6 kompilieren lies [irgendeiner meinte ich solle 8.0 nehmen]).

    Stimmt, es gibt kein DInput9.

    Bye, TGGC

    0
  • G

    vielleicht deshalb auch das hier:
    #define DIRECTINPUT_VERSION 0x0800 😉

    Oh man. Ich muss mich echt erst mal wieder in C++ eindenken. Irgendwie will da garnix;-) Ich bin momentan ja schon happy wenn ich überhaupt die Oberfläche richtig angesprochen bekomme. So ne kleine Anwendung und so nen Aufwand*lol*

    Naja. Ich schreib jetzt erst mal das Prog und dann denk ich mir was für den Rest aus. Wenn das mit dem blöden Pad nicht hinhaut machts ja auch nix. Die 3€ könnte ich verschmerzen;-)

    THX
    Nils

    0
Anmelden zum Antworten