#directinput

Pro- el control de $ 70 dolares para el Nintendo Switch será un accesorio popular cuando salga la consola, ya que hemos descubierto que el Joy-Con estándar es un poco estrecho para algunas personas. Un detalle ha salido a la luz que puede hacer que el precio sea un poco más fácil de justificar, El control Pro también funciona en su PC. Control Nintendo Switch Pro El Control Nintendo Switch Pro…

Ministation Game Controller Gamepad for PC Windows TV Android Phone Tablet P lay station Steam OS Supports XInput DirectInput DInput Mode with wired and wireless mode

Ministation Product Description

Please Notice the Android cellphone need to support OTG,Most of the phone support OTG, except the old modle. Due to limitation for the battery transportation, our game controller doesn’t come with 2 AA battery. customer need to prepare by yourself. the wireless mode is working through usb dongle, no bluetooth function,

XInput is the API for “next generation”…

this is an old post from a blog i tried starting before, but i think it deserves a home here now that i'm going to try posting more to this blog.

I've started working on a final project for my music engineering course, and the goal is to create a midi sequencer that runs while a user is playing a video game. The sequencer is controlled by how the user plays the game, so the buttons pressed while playing. Since I don't have much time, I'm doing this as simply as I can and in windows, since I'm more familiar with creating windows executables. To do this, I'm using a Nintendo wiimote as my contoller (since I'm very familiar with using these in a Windows environment), and I'm creating an program to create keystrokes from the buttons pressed on the wiimote to control an NES emulator as well as the midi sequencer. I'm using Nestopia as my emulator, and the sequencer will be created in Max.

Now that you're kind of familiar with my project, I can introduce today's challenge (get excited!!!)! As I mentioned, I'm familiar with using wiimotes from way back several years ago when I used them to create a 3-dimensional head tracking unit to use as an alternate interface when communicating with a computer (aka you can control the computer cursor with your head and two wiimotes). Using the wiiuse c library(I recommend going to archive.org and searching for an old cached version of wiiuse.net if you want to see coding examples), I was able to accomplish most of my goal of getting wiimotes to communicate with the Windows API. With that backbone, my goal, today, was to get a wiimote connected to my macbook (booted into xp) and then communicating with the emulator. sounds simple, right? unfortunately, it was not. The strategy I had been using in the past was to use the sendinput command to send virtual/simulated keystrokes, but it turns out that many games require directinput keystrokes in order to work with joysticks and other similar controllers.

I probably jumped between windows and os x about five times today trying to figure out which one would be simpler to find a solution to this headache. Within os x, I think I tried darwiinremote, wiiji, and osculator, but all of them were only communicating a virtual level, the same as sendinput, so I had no luck getting my wiimote to communicate. I'd still keep jumping back to windows now and then to give something new a try, and once I figured out that I was out of ideas in os x, I decided to jump back to windows for good and search the internet for a solution.

My biggest problem was I didn't know where to start. I didn't know there was a difference between virtual inputs and direct inputs, so I started with basic searches such as 'sendinput not working with emulator' and over time I learned what the true problem was (I was sending virtual inputs instead of direct ones). Next, I need to figure out how to fix this problem, and that's where I ran into many different solutions, but none of them seemed to work. I tried using special header files that people said would work, and even attempting to relearn how to use hooks (which I really didn't want to do), but then I stumbled upon two very helpful stackoverflow pages (page and page, thank you) that helped me understand why my sendinput commands weren't working, and I finally understood the sendinput command, and how to use it.

The most important part of the command is the INPUT structure, and in my case, the KEYBDINPUT structure within that. There are five members to that structure,

wVk: the virtual key-code

wScan: the hardware scan code for the key

dwFlags: describes the key event

time: the time stamp for the key event

dwExtraInfo: additional information about the keystroke

Previously, I had been implementing my code using the wVk member, which only created the virtual stroke, when what I should have been doing was using wScan in order to simulate an actual hardware key stroke (HUGE difference).

To create a hardware key stroke, first set up the INPUT to be of the keyboard type,

INPUT ip;

ip.type = INPUT_KEYBOARD; // Set type to keyboard

The variable INPUT_KEYBOARD is already defined within windows, but if anyone is curious, it's defined as 1. Next, we can set up the keyboard structure, ki.

ip.ki.wVk = 0; // Virtual keystroke isn't used

ip.ki.wScan = 0x1E // Hardware scan code for 'A' key

ip.ki.dwFlags = 0x0008 // KEYEVENTF_SCANCODE flag to specify wScan is used, and wVk is ignored 

ip.ki.time = 0; // No delay

ip.ki.dwExtraInfo = 0; // No extra info

I was able to find a list of directinput keyboard scan codes here. Just change the 0x1E with whatever key you want to simulate. Now that the structure is set up, we can put together the sendinput command,

SendInput(1, &ip, sizeof(INPUT));

The first argument is the number on inputs, which is one in this case, the second is the address of our INPUT structure, and the third is the size of the INPUT structure. It is important to note, that after this command we need to simulate a key up message so that the program knows the key was released. Before that, though, I was fortunate enough to figure out on my own that a short delay should be added in order for the first sendinput to be read, processed, and executed, otherwise, as I discovered, the emulator would read my simulated keystroke except on rare occasions when there was an odd delay of the computer's own doing.

Sleep(200); // Gives time for the key press to be processed

ip.ki.dwFlags = 0x000A; // KEYEVENTF_KEYUP OR'ed with KEYEVENTF_SCANCODE to create a key release

SendInput(1, &ip, sizeof(INPUT));

That's all there is to it. No hooks, and this will be read by direct and virtual input programs, since it is emulating a keystroke from the hardware level.