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

[samco]

Check out Seong and I's launch vids for OpenFIRE!

[ThatOneSeong]

For those wondering why things are so quiet here:
We've actually been pushing several updates throughout the summer, for both the firmware and desktop app to improve capabilities and general user experience! In fact, I've pushed the latest versions just a few hours ago as of writing.
Timely updates may not be posted as much on the forums here, apologies - but there's still plenty of work to be done on OpenFIRE.

We also accept, and encourage, contributions from other users! If you have some changes in mind you'd like to make, and know C++ and/or have familiarity with Qt, setting up a build environment is as easy as copying/pasting a few lines, and pull requests will be reviewed as they come.

You can follow all of our updates on the public GitHub repositories:
Firmware releases
Configuration App releases

And if you'd like to support our efforts financially, you'll find various links on the OpenFIRE group's page - and being the primary code contributor, I also have a Ko-fi you can directly tip to as well.

[ThatOneSeong]

Big* OpenFIRE Announcement!
okay maybe not that big, but

Some people have asked, and we've listened: OpenFIRE now has official* MiSTer FPGA support!

There's an open thread on the OpenFIRE issues board that lays it all down, but the gist you'll need to update the firmware to the one linked and download and replace a patched MiSTer executable on your boot medium of choice.
This makes OpenFIRE the first lightgun system ever that introduces automagic MiSTer compatibility, meaning no switching input modes required from the user to hotswap between PC and MiSTer! However, you will still require a PC to calibrate the OpenFIRE gun against the TV you plan to use with your MiSTer. We are working on an OpenFIRE Toolbox script/program that will allow for the gun to dock with the MiSTer like with the Desktop App and perform simpler maintenance on the microconsole itself, including PC-free calibration.

Because the MiSTer-side patch itself and the heuristic for auto-communicating with the guns might be temperamental, we are asking any and all users of MiSTer FPGA to test OpenFIRE with their setup to ensure that it's stable before submitting the patch to upstream MiSTer-dev.

As always, none of this could have happened without supporting the development team. If you like this update and want to see more cool things in the future, please consider supporting the team! You'll find various links on the OpenFIRE group's page - and being the primary code contributor, I also have a Ko-fi you can directly tip to as well.