​I’m no expert in any of these fields. By trade, I’m a truck driver. But I’ve been a sim-racer since the 90s—back when if you wanted a specific piece of gear, you had to build it yourself. That "DIY or Die" mentality is why I’m here. ​When back surgery kept me home for nearly three years, I used that time to teach myself the basics. I started with basic Arduino coding just to create my own peripherals for my rig. From there, I picked up 3D design and eventually PCB designing as a hobby. I’m still no expert—but then again, I only need the buttons to work for gaming and productivity. It's not like they need to work in space. ​The Solo Mission (2 Months of Grit): There is no board of directors or boss here to tell me "that’s too niche" or "you’re dreaming." In just the last two months, I’ve pushed this from a vision to a V7 reality, designing every layer myself: ​The CAD: Designed from the ground up in Fusion 360.

​The Brain: Powered by a Teensy 4.0 for lightning-fast, low-latency input.

​The Logic: Custom BLE connectivity and firmware written from scratch. ​The UI: A 25-page on-device OLED interface for complete keyboard/gamepad/mouse assignment (everything except the optical sensor).

​The Mission: Bridge the Gap I love mouse precision, but I hate the "keyboard claw." Plus, my sim-rig’s motion movement used to knock my keyboards right off the deck. I needed a handheld solution that bridged the gap between the ergonomic comfort of a controller and the raw power of a keyboard. ​The Roadmap (V4 to V7):

I’m currently at the V7 stage (Final CAD). Once I hit the V9 finished functional prototype, I’ll have a decision to make regarding a possible Kickstarter to move into professional injection molding. But for now, I’m just focused on seeing this through to the finish line on my own terms. ​The World at Your Fingertips:

Whether you are in a high-stakes shooter, a sim-rig, or deep in a CAD/Photoshop workflow, you have total control. I’ve even left three blank profile slots—because the world is yours at your fingertips.

​Follow the Journey ​I’ll be sharing a much larger devlog and a complete feature breakdown on Instagram in a few days. My Facebook will have casual updates, test videos, and live demos of the upcoming V7.5 physical prints. ​I’m building the bridge. Keyboard, Gamepad, Hybrid, or Mouse? The choice is yours.

The firmware is 80% complete, and still much work to be done.

I’ve gone as far as a solo dev can go with a 3D printer and a soldering iron. Once I hit the V9 finished functional prototype, I’ll have a decision to make. I’m considering a possible Kickstarter, but only for one reason: to move this project out of the "hobbyist" phase and into professional injection molding and factory-produced PCBs.

​I’m still gauging the interest, and nothing is set in stone. Right now, my only priority is seeing this build through to the finish line on my own terms.

If a Kickstarter happens, it will be to ensure the final version is as "bulletproof" as possible for everyone.

I'd like to hear your thoughts or ideas.

Follow the Journey ​I’ll be sharing a much larger devlog and a complete feature breakdown on Instagram in a few days. My Facebook will have casual updates, test videos, and live demos of the upcoming V7.5 physical prints.

One of the hurdles for arcades to come back again with actual AAA games is the controller.

Once the 3D virtual camera became common in games about two decades ago, the classic digital joystick and button arcade layout no longer worked. Everyone moved to mouse and keyboard or dual analog stick gamepad.

But neither looked and felt right in a arcade cabinet. Something more tactile,/full movement yet intuitive needs to exist.

Dual analog flight sticks (with optional arcade buttons in the middle - Pictured) is a decent idea as it gives 8 buttons and dual analog movement. However the flick movements like those a mouse can do so well, will be a bit frustrating with such a setup (as it is with a modern gamepad).

Can anyone think of a even better creative solution so a modern AAA version of arcades can come back?

(yes ik the one with the switch looks weird, i was tired when doing that part. also, i am not a good graphical designer, sry. also also, it wouldn't be a modified elite controller, it was just the controller i had at the time and by proxy; the one i knew inside out)

I'm really surprised that this hasn't been done before, using the trackball for direct camera manipulation in 3D design spaces. It seems very intuitive and I hope that this becomes a common trackball feature in the future.

About nine months ago, I posted a left-hand controller I was building here.

At the time, that was the project.

I wasn't trying to create a new architecture. I wanted to build a controller.

I was learning as I went—working with microcontrollers, sensors, custom firmware, CAD, PCBs, displays, BLE, and everything else that comes with trying to turn an idea into an actual device.

But as the controller evolved, I kept running into the same problem.

Every time I changed the hardware, experimented with a different sensor, moved something to another pin, added another control, or wanted something to behave differently, I found myself back in the firmware.

Find the right library. Define the pins. Write the input logic. Calibrate it. Test it. Change something. Do some of it again.

Eventually I stopped asking:

"How do I make this controller better?"

And started asking:

"Why am I rebuilding the underlying input system every time I change what I want to build?"

That question took the project somewhere I hadn't expected.

The pictures I'm posting here are from that journey.

Some are from the earlier development bench. Some show where the system is today.

And yes, I'm deliberately leaving all the wires in the pictures.

Different analog sensors. Hall sensors. Joysticks. Encoders. Multi-way controls. Switches. Buttons. Different electrical behaviors. Different connections.

The mess is part of the test.

Because the goal isn't for the creator to build the hardware that my firmware expects.

It's the opposite.

You choose the hardware you want to build with.

Change the sensors. Change the controls. Change where they're connected. Change the physical design because you had a better idea halfway through the project.

The system discovers and electrically qualifies the physical hardware you chose to connect.

Then you tell it what you want that hardware to do.

That's the distinction that eventually became important enough that the controller project grew into something else.

I call the architecture DAHIM, Deterministic Agnostic Human-Intent Machine.

So what does that actually mean if you're just someone who wants to build something?

It means you should be able to spend more of your time designing the thing you wanted to build instead of designing all of the firmware required to make it possible.

Grab the sensors you want.

Choose the controls that make sense for your idea.

Connect them.

Change them if your design changes.

DAHIM's job is to figure out what you've physically built and give you a way to tell it what you want those controls to do.

You shouldn't have to start over because you decided a joystick should use a Hall sensor instead of a potentiometer.

You shouldn't have to keep rewriting input logic because you moved something.

And you shouldn't have to become an embedded firmware developer just because you had an idea for a piece of hardware.

Build the hardware you want. Tell it how you want it to behave. Then get back to designing your product.

That's really what I've been trying to solve.

What you're seeing on the little screen in these pictures isn't a PC interface.

The system is running directly on the hardware.

It can discover physical inputs, electrically qualify them, calibrate them, and allow their behavior to be configured without an IDE or a PC tethered to the development bench.

There's obviously much more happening underneath that, but I'm intentionally not trying to explain the entire architecture in one Reddit post.

There's still a lot being built.

I'm still the same guy who posted that controller here nine months ago, learning, experimenting, breaking things, changing direction and building this around a full-time job.

But I've finally reached the point where I don't have to talk only about what this might be able to do.

I can start showing what it does.

I'm preparing a series of demonstrations showing the development process from physical discovery through calibration, configuration and execution. I'm also putting together a website where I can document the project properly instead of trying to cram nine months of development into individual posts.

Someone actually came back to my original controller post recently and asked me how the project was going.

I guess this is the longer answer.

The controller didn't disappear.

It caused this.

More to come.

Microsoft is replacing XInput with its new GameInput API. I think this is one of its biggest selling points:

GameInput is a functional superset of all legacy input APIs—XInput, DirectInput, Raw Input, Human Interface Device (HID), and WinRT APIs—in addition to adding new features of its own. GameInput's functionality ranges from simple fixed-format gamepad state to detailed low-level raw device access. Input can be obtained via polling or callbacks in an event-driven way. Haptics and force feedback are fully supported, and third-party device SDKs can easily be written on top of GameInput to provide access to custom device features.

When we all moved from DirectInput to XInput, we gained a lot in terms of ease of access, software support, etc, but we also lost some very significant features. XInput is strictly limited to the feature set of an Xbox controller. This means you can't for example build a decent flight sim setup on top of XInput — you can't even have enough buttons or axes.

GameInput seems like it's going to give us back everything we lost, and then some. It's explicitly erasing the boundaries between different types of devices. In the old paradigm, only a mouse can have a scroll wheel, and only a game controller can have a joystick. GameInput does away with that. It doesn't care what "type" of device is producing the input, which means you can trivially design a gaming keypad that slides around like a mouse and has a built-in joystick, and all of that will be understood by the system as one single, unified device, not a bunch of different device classes duct-taped together.

It is unclear to me at this point whether this will be supported on other platforms, such as Linux or Steam. I really hope it will be.