spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Moin,

ich will euch hier kurz eine kleine OpenSource-Bibliothek vorstellen, die ich im Zuge der Splatter-Portierung geschrieben habe.

SNIIS (Gesundheit!) Simple Non-Intrusive Input Library
Link: https://github.com/Schrompf/sniis
Lizenz: WTFPL oder vergleichbare

Funktion:
SNIIS stellt alle Arten von Eingabegeräten auf den Desktop-Plattformen Windows/Linux/MacOSX zur Verfügung. Unterstützt werden mehrere Mäuse und Tastaturen sowie natürlich alle GamePads, Controller, Joysticks. Deren Eingabeelemente können dann mittels Action Mapping auf abstrakte Eingabekanäle abgebildet werden, um halt die klassische Neubelegung der Steuerung zu ermöglichen. Im Detail:

- mehrere Mäuse und Tastaturen auf Win/Mac/Linux mit sauberer Nutzer-Integration - kein Suchen mehr, was denn nun die erste Maus ist, wie z.B. bei Trine :-)
- Non-Intrusive - übernimmt *nicht* die Game Message Loop. Braucht deswegen aber gelegentlich externe Informationen, um arbeiten zu können.
- einfacher Build - einfach ein Rudel C++-Files mit dem Projekt mitkompilieren, zur Benutzung ein einzelnes Include ohne weitere Abhängigkeiten.
- einfacher Code - kein AbstractFactoryAdaptorPattern-Mist. Ich meine Dich, OIS.
- Action Mapping, also Abbildung von Eingabeelementen auf Spielaktionen, mit Kreuzübersetzung zwischen analogen und digitalen Controls
- optional mit Tastenwiederholung
- optional mit menschenlesbaren Namen für die Eingabeelemente, z.B. für's Optionsmenü, wo man die Steuerung neu belegen kann

Ursprung:
Das Ganze ist umfangreich basiert auf Object-Oriented Input System, was ich bald ein Jahrzehnt lang vorher benutzt habe. Das musste ich aber für "Mehrere Mäuse/Tastaturen" bereits kräftig umbauen, habe außerdem den XInput-Patch für saubere XBox-Controller-Unterstützung integrieren müssen, und Tilman/Sternmull hat damals das ActionMapping noch obendrauf gepflanzt. Und spätestens, als ich OIS dann unter Linux benutzen wollte und der nur noch in Crashes gerannt ist wegen der Konkurrenz um irgendwelche Systemnachrichten, war's vorbei damit.

Probleme:
Einige. Ich hoffe da auf den OpenSource-Effekt.
- fehlende Tastenbenamung auf OSX
- fehlende Benamung aller anderen Controls, also Maus und Joysticks
- unsaubere Übersetzung von HID-Buttons auf Virtual Keys unter OSX
- unschöne RawInput-Nachrichtenbesorgung auf Windows - kommt man da irgendwie eigenständig ran?
- noch völlig unfertige C-API

Andere Libs:
- ManyMouse - feines kleines Ding, angenehm unprätentiös, aber halt nur für Mäuse, und kein Remapping
- "Simple cross-platform gamepad library" von TigSource - ebenso kleines feines Ding, aber halt nur GamePads/Joysticks/usw., kein Action Mapping
- und halt OIS - quasi tot, ziemlich "objektorientiert" verbastelt, konnte nur einen Teil von dem, was ich brauchte

Danke :-)

Hat jemand eine Idee, wie ich in meiner Update-Funktion RawInput-Nachrichten bekommen könnte, ohne dass ich die Nachrichtenschleife des Programms übernehme? Also wirklich nur die RawInput-Nachrichten, ohne in ner BusyLoop mit dem Hauptprogramm zu konkurrieren, Nachrichten zu verlieren oder dem Hauptprogramm welche wegzunehmen?

Das wär nämlich der finale Ritterschlag, mit dem ich die Lib dann auch in C# oder Java anbieten könnte oder als Plugin in den Unity Asset Store setzen könnte.

Ich belese mich mal zu Hooks. Hoffentlich gibt das keinen Ärger mit irgendwelchen Virenprogrammen. PeekMessage() wollte ich eigentlich nicht, weil ich nicht weiß, wann und wo die RawInput-Nachrichten entstehen. Wenn ich mich durch die MessageQueue durch-peeke, hab ich im Endeffekt auch nur ein Wettrennen um Nachrichten mit der Haupt-Nachrichtenschleife des Programms.

Ich kopier hier mal meinen Text ausm ZFX rein, weil ich gerade heftig stolz bin.

-------------
It's mating ridiculous, but it works!

In der dürftigen RawInput-Doku gibt es auch einen Verweis auf GetRawInputBuffer(), was die Buffered-Version ist, die ohne Zuarbeiten von der Message Loop auskommt. Diese Funktion ist der kritische Teil, weswegen ich nun meine Input-Lib nicht mehr in UpdateVorMessageLoop(), HierNimmDieseRawInputNachricht() und UpdateNachMessageLoop unterteilen muss. Ab jetzt reicht ein einzelnes Update(). Und diese Änderung sollte es jetzt auch ermöglichen, die Lib auch von C#, Java aus benutzen zu können oder sie als Plugin in den Unity Asset Store zu stellen.

Der Trick: GetRawInputBuffer() ist auf 64bit-Windows verbuggt! Die RawInput-Nachrichten stecken in sowas:


Und auf 64bit-Windowsen ist data um 8 Byte verschoben. Das Problem ist Microsoft seit mindestens 2011 bekannt, aber die einzige Reaktion war, es als Note in die Doku mit aufzunehmen. Also hab ich mittels GetProcAddress() und IsWow64Process() ermittelt, ob ich das Buggy-Offset einberechnen muss, und dann in diesem Fall eine kleine fiese Zeigerbastelei ausgeführt, womit ich jetzt final korrekte RawInput-Daten gelesen bekomme.

Was für ein wirrer Mist. Aber ich freu mich, dass ich es rausgekriegt habe.

Danke :-)

Und "Arbeiten" ist dann doch etwas übertrieben. GetRawInputBuffer() liefert einem leider nur die seit der letzten Nachrichtenschleife aufgelaufenen RawInput-Ereignisse, wie ich jetzt feststellen musste. Die seltenen RawInput-Ereignisse, die nach meiner Abfrage und vor Abschluss der Spiel-Nachrichtenschleife reinkamen, gingen verloren. Deswegen habe ich mich jetzt zusätzlich per SetWindowLongPtr() vor die spiel-eigene WNDPROC gehängt und sammle auf die Art die sonst verlorenengegangenen Input Events noch ein.

Hässlich, das Ganze, und eigentlich ein unwürdiger Zustand für Softwarearchitektur im Jahre 2015. Aber was soll man machen.