OpenFIRE - A new Open Source Lightgun firmware & GUI

[samco]

Just have a quick teaser vid for now. But hopefully will have some info in the near future.

[baritonomarchetto]

Nice! Keep us updated

[TapeWormInYourGut]

Looks really nice. If it truly does support the diamond IR configuration then maybe I'll give it a try in my next lightgun build.

[ThatOneSeong]

Looks really nice. If it truly does support the diamond IR configuration then maybe I'll give it a try in my next lightgun build.

It will support diamond layouts, but the main focus will remain the two lightbar configuration.

[ThatOneSeong]

I think it should delight some potential users to know that we have indeed supported such big features as full analog stick support, enhanced feedback support for things such as OLED screens for displaying lives and ammo counts in supported games (through MAMEHOOKER/QMamehook), support for both IR square and diamond IR emitter layouts on a per-profile basis (though priority still remains the two lightbar setup, which does have perfect line-of-sight accuracy), and first-class Linux support for quite a while now. Not to mention we are proud to provide everything in single binaries per supported microcontroller, so the user can drag'n'drop OpenFIRE and be up, calibrated and running within a minute, no matter how you have your board wired up.
And that's just the tip of the iceberg. Hopefully people will enjoy the showcase we'll have to share over the next couple of days as we prepare for the initial launch. And keep those Pico W's handy; you may have use for that wireless chipset yet. 

[TapeWormInYourGut]

It seems that the gauntlets have been thrown down in this lightgun subforum

I thought the analog stick support was a remapping to keyboard arrow keys. I swore that I read that somewhere for the previous gun4all project but maybe I made that up in my mind. So I'm glad you clarified.

[RandyT]

It seems that the gauntlets have been thrown down in this lightgun subforum

This whole forum used to be nothing but "thrown gauntlets".  "sigh" those were the days (not) 

... support for both IR square and diamond IR emitter layouts on a per-profile basi ...

I'm still waiting to see a project do away with the 4 led configurations entirely and opt for 8...essentially the diamond pattern, with extras in the corners (or a different spacing entirely... like 4 light bars).  More LEDs to install, but with the proper code, this could help with larger screens without needing to be so far away or to deal with distortions from fish-eye lenses.  Of course, each set of 4 would need to be grouped and modulated for these cameras to work properly, so the LEDs couldn't be "dumb" anymore.

Probably never happen, but a guy can dream

[ThatOneSeong]

... support for both IR square and diamond IR emitter layouts on a per-profile basi ...

I'm still waiting to see a project do away with the 4 led configurations entirely and opt for 8...essentially the diamond pattern, with extras in the corners (or a different spacing entirely... like 4 light bars).  More LEDs to install, but with the proper code, this could help with larger screens without needing to be so far away or to deal with distortions from fish-eye lenses.  Of course, each set of 4 would need to be grouped and modulated for these cameras to work properly, so the LEDs couldn't be "dumb" anymore.

Probably never happen, but a guy can dream

Ehhhhhhh. There's a couple of things there:

• The SEN0158 module, which is inherently just a Wiimote sensor, only supports up to four points. We literally couldn't go past this even if we wanted to - not without using a whole new camera module entirely. For better and for worse, the Wii cam is the most readily available camera we can have. (Because of open source, there's nothing stopping someone from contributing such a solution, but that might need to be a separate fork unfortunately)
• Eight points would be overkill, and most normal people either couldn't, or can't justify putting a whole array of emitters cluttering every edge of their screens. Some people still have problems with sensors period, let's not make the problem even worse!
• Thanks to Sam's very smart reworked tracking code, distortion from lenses is minimal and I've been able to play within about a screen's width-and-change from the display using the dual lightbars system while maintaining line-of-sight accuracy, which is better than all other open source offerings that came before. So I don't think the change would be really all that necessary.

[RandyT]

• The SEN0158 module, which is inherently just a Wiimote sensor, only supports up to four points. We literally couldn't go past this even if we wanted to - not without using a whole new camera module entirely. For better and for worse, the Wii cam is the most readily available camera we can have. (Because of open source, there's nothing stopping someone from contributing such a solution, but that might need to be a separate fork unfortunately)

I know these parts well.  That's why I stated that the LEDs could no longer be "dumb" and would need to be grouped and modulated.

• Eight points would be overkill, and most normal people either couldn't, or can't justify putting a whole array of emitters cluttering every edge of their screens. Some people still have problems with sensors period, let's not make the problem even worse!

No argument on that front.  However, as screen size increases, so does the distance required to be away from it if one wishes to maintain a solid screen reference.  IIRC, the commercial methods used more than 4 LEDs, likely because in the arcades, screens are big for most shooters and floor space has a premium.  My dream is to be able to use a system like this with a projection screen and the minimum distance required is measured in yards rather than feet.  Also, as the distance one must stand back from a screen increases, the source output must be much higher (inverse square law), so there's that as well.  With 75"+ screens being more and more affordable, this may become more of an issue down the road.

[ThatOneSeong]

Happy Saturday!

Have you been waiting to try out OpenFIRE, or take a peek and a whack at contributing?
Well, wait no more: the first official Release (Candidate*) of the OpenFIRE Firmware & Desktop App are finally public!

*(Release Candidate, for those who aren't into development lingo, means that it's as close to final as we can independently verify on our own, but there might be some bugs we haven't found yet. If you happen to find any, please, make use of the Issues board on the repositories!)

You can find documentation on the respective pages' READMEs, the Firmware's Wiki, or the 'enclosed instruction book' for more information!
And for those who might be following from my prior endeavors, this will be a noticeable improvement in nearly every way. I genuinely hope the people enjoy it. 
Firmware Release
Desktop App Release