FreePIE official thread

[shent1080]

The juddery mouse in the top left corner was happening to me too, look over previous posts between me and cyber and you should get your answer, or at least get half way there.

[CyberVillain]

New version out, biggest change is new GUI with Visual Studio like docking.
See first post for download link and complete changelog

[mahler]

New version out, biggest change is new GUI with Visual Studio like docking.
See first post for download link and complete changelog

Works well here. I'll do some more testing later this weekend.

[CyberVillain]

New version out, biggest change is new GUI with Visual Studio like docking.
See first post for download link and complete changelog

Works well here. I'll do some more testing later this weekend.

Nice that it works, saw that you forked FreePIE, working on something?

[mahler]

Nice that it works, saw that you forked FreePIE, working on something?

Yes I have some ideas, but don't like to announce anything to prevent myself from making false promises

[CyberVillain]

btw, I see that you often delete and recreate your Github FreePIE repo, instead keep your fork and merge in the changes from my master. Add a remote upstream

Code: Select all

git remote add upstream https://github.com/AndersMalmgren/FreePIE.git

And then merge

Code: Select all

git merge upstream/master

[mahler]

btw, I see that you often delete and recreate your Github FreePIE repo, instead keep your fork and merge in the changes from my master. Add a remote upstream

Thanks for the tip.
I actually thought of the same thing yesterday because 10 minutes after I forked you merged your Avalon branch.
Definitely easier than deleting/forking.

[CyberVillain]

Once you master Git you are in heaven, so much nicer than Team foundation that we have at the office

[nateight]

As I learn more about FreePIE I'm increasingly excited by it. Several thousand Rift backers are about to be forcibly (if happily) thrown into reassessing their input rigs, and I believe you're well on your way to building a foundational piece of the coming revolution. Kudos! I'm attempting to play my part by filling several input device voids in the short term and creating Rift-focused games in the long term (and I'm Python coder of intermediate skill thrilled with your choice of scripting language), so you may be seeing a lot of me around MTBS. I'll try not to throw my usual walls of (unnecessary?) text at you or pester you with too many questions (though I have many), but I do have two for you right now:

Is there a place to read about FreePIE's licensing structure? The obvious nature of this project is to provide a framework both for gamers and software developers to use freely, but is there any potentially troublesome GPL code or somesuch involved that may impede adoption by commercial entities unwilling to open their sources?

Would it be rude of me to ask for a rough ETA on WiimotePlus support? I'm currently focusing on a hardware project that could be of significant interest to the VR community, but it will very shortly require full Wiimote sensor access (and "Expansion Port" access) to progress. I may need to investigate VRPN regardless and I can always go crawling back to GlovePIE if necessary, but if FreePIE meets my needs I would love to become an active supporter.

Keep up the good work, guys! I'm no kind of expert at any of this but I'll try to contribute whatever testing and documentation I can as I go along.

[CyberVillain]

Welcome to the forum nateight and thanks for your kind words!

Truth be told, I just took the first License that Sourceforge suggested (We were hosted on their site before we moved to Github) and it happened to be GNU General Public License, version 2, http://www.gnu.org/licenses/gpl-2.0.html
The only place that you can read about that is in the About box in the GUI, maybe I should add that to the Readme so its more available to other devs.

We are working on Wiimote support as we speak, the problem is that there is no SDK for Windows that works with newest version of the wiimote (The one with integrated Motion Plus) we are investigating two tracks, my brother and I (CyberRascal on this forum) are trying to isolate the Wiimote code from the Dolphin Wii emulator project since that emulator is working with virtually all existing Wiimotes (Even Chinese copies), the problem with that approuch is that some code is inside the Wii CPU which is not easy available to us.

BillRoeske on this forum is investigating the other approuch which is merging the Linux branch of WiiUse (WiiC) since that version has support for newer motes. Last time he sent me a copy it did not find my Wiimote with integrated Motion plus, I'll have to check with him if he had made any progress.

[nateight]

Truth be told, I just took the first License that Sourceforge suggested and it happened to be GNU General Public License, version 2, http://www.gnu.org/licenses/gpl-2.0.html

Is it too late to reassess that? I know I promised no walls of text, but...

I am not a lawyer and I have only a rudimentary understanding of these licenses, but it would seem that the entire point of the GPL is to demand that any "derivative work" adopt the same license (i.e., publish all source code and allow further works to be built upon it). This is noble, and I while want to ideologically support it, serious problems quickly arise when you start trying to incorporate GPL-licensed code into a commercial project. If you're not actually trying to do that it's one thing, but let's find out for sure; I genuinely hate to be the guy bringing discussions of legalities into this space of free experimentation, but I have a vested interest not just because I want FreePIE to succeed but also because I may one day be someone wanting to use FreePIE in a commercial project.

What, exactly, is your intention for FreePIE? If it is strictly for use by individual gamers and researchers there's no problem, but some conversations I've witnessed here suggest you intend for it to be incorporated into games directly by developers to streamline peripheral support (as does the plugin page, though that's all too far above my head for me to be certain). If you want developers to use FreePIE but only when the games they are producing are GPL-licensed and open source, that's also fine - but what games fitting that description can any gamer not an active part of the open source movement name? Not counting remakes, demakes, and clones: FreeCiv (disqualified as a clone of a commercial game), NetHack/Dungeon Crawl/Stone Soup (disqualified as being "like Rogues"), Cube/Cube 2: Sauerbraten (disqualified as not actually being GPL-licensed, rather zlib-licensed), The Ur-Quan Masters (sort-of), and (if the person happens to be a turn-based strategy fanatic and PC gamer) Battle for Wesnoth. If your aim is to target professional or even indie closed-source games, the GPL license is a one-way ticket to Failure Town, because professional game developers are notoriously protective of their code for a variety of very sensible reasons and therefore make pained efforts to avoid any association with GPL-licensed anything. A "permissive" license like MIT or one of the BSDs would be a much better fit in this case, because anyone wanting to use FreePIE in a commercial product would gladly give you attribution - it's the source opening that's the dealbreaker, which MIT and BSD omit.

Even if this all makes perfect sense, if the team is in unanimous agreement, and if it's not too late to switch, though, there's the problem of the libraries you have used or will use to get all these devices working in FreePIE. I can tell you Dolphin and WiiUse/WiiC are both GPL-licensed, which proves problematic if you want to use pieces of them yet have your own work licensed differently. I may very well be making something out of nothing here - what qualifies as a "derivative work" and how FreePIE may be exempt from these restrictions based on fair use or substantial "newness" are the domain of actual lawyers and never entirely clear until decided by a judge - but the fear alone of these issues is supposedly enough to keep many professional programmers awake at night, and definitely enough to keep the legal departments of any game developer large enough to have a legal department from disallowing the use of FreePIE if it isn't licensed in a way that protects their interests. Hopefully someone with more experience can chime in explaining why FreePIE isn't likely to have these difficulties (Dolphin, being software basically designed to enable copyright infringement, is highly unlikely to seek a court case, for instance), but while it's all a major headache you'll be doing yourselves and the project a favor by settling this sooner rather than later.

As for the actual problem: WiiCIS, maybe? This tutorial is clear even to me, but documentation outside the source seems to be otherwise nonexistent. WiiYourself! may be an even better option and it's where I may start before attempting to locate the kludgey mess of a GlovePIE script I once assembled but probably never did get working right. And hey, I'm sure VRPN will be a breeze when these other options disappoint me.

[CyberVillain]

Wouldn't it be enough to MIT the FreePIE.Core.Contracts dll this way game developers can jack into FreePIE best they want, without messing with the other libs licenses. I'm not an expert on the area though, we are probably not doing it right like it is right now. For example I took a quick peak in our lib folder the first lib is AvalonDock and their license is.

http://avalondock.codeplex.com/license

Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.

That is not something we are currently doing, I think I should look through all the libs for next release, if I find time...

edit: If you want you can look in https://github.com/AndersMalmgren/FreeP ... master/Lib see all the libs

[BillRoeske]

Most of this will be review for CyberVillain, but for the benefit of the thread, here is where my progress currently stands:

WiiC seems to be the most fully-featured Wii Remote library we could find. It's a slightly modified version of WiiUse that added Motion Plus support but removed all of the Win32 code. The library itself is written in straight C, which means that it's easy to distribute as a compiled lib or dll.

Last week on Sunday (March 3rd), I created a quick-and dirty local project that ported WiiUse's Win32 support forward into WiiC and compiled to a static library. This, along with WiiC's unmodified test program code, compiled and worked for both an original official Wii Remote and an official Wii Remote Plus for me. The Wii Remote Plus was able to give me full Motion Plus data, too.

On my computer, I'm using an HK-760 Version 2.0 Bluetooth adapter with the official MS Bluetooth drivers. A friend's third-party Nyko Wii Remote Plus didn't seem to stay connected with Windows long
enough to let me test it. The test program on CyberRascal's PC seemed to work just fine with the original Wii Remote but not the Wii Remote Plus, which is a bit of a head-scratcher. At some point I'd like to get a build with some debug spew sent out to him or CyberVillain. I just bought a new laptop to replace my old faithful from 2006. It has a different OS (Windows 8) and integrated Bluetooth, so I should be able to test on that pretty soon, too.

The next step for me will be setting up a real Visual Studio project that compiles to a .dll file that the managed code in FreePIE will be able to wrap, and then put the whole thing up on Google Code so that it doesn't die with my HDD at some point. And so other projects besides FreePIE can use it if they want, of course. Time has been a little more scarce than I'd anticipated, but I'm hoping to get at least that far this week.

[CyberVillain]

Thanks for report! We haven't progressed much since last time we spoke on PM, my brother is doing some progress though, but it still the problem with extracting logic from emulated Wii CPU. I will take a look at the lib nateight lnked too, dont think I looked at that one when I was reviewing all libs

[nateight]

[Wiimote testing continues!]

Great post. It's stuff like this that makes me feel like MTBS is the most exciting forum in the world right now - all these enthusiastic developers hacking away, iterating on old ways of doing things, inventing new ones. The future is bright!

Regarding licensing and compliance, I'm not at all sure if you can license one section of a library when other sections are bound by the GPL; consultations with a software lawyer are recommended in the somewhat near future if you ever plan to engage with commercial entities. I think you're safe to be focusing solely on the code while your userbase is strictly hobbyists, but it's increasingly clear to me multiple voids exist in VR controller driver space for both hobbyists and large game developers - you've already got a great start on filling some of these needs, but it's going to get at least as complicated as I suggest if you want to fill others.

My needed part arrived today and the next step is getting a Wiimote+nunchuck communicating with Windows absent my modifications, so I'm going to see what I can accomplish myself in a day or two. GlovePIE is being utterly uncooperative, so my second line of attack is going to be through VRPN. I'm unlikely to get far - VRPN is giant and scary to a lowly Python hacker with practically no formal training - but I'll post updates if I have anything significant to share.

As for the Wiimote weirdness you're encountering, consider these pages I stumbled over in the previous days: WiiUse developers begin this thread talking about Balance Boards, but by this point in the thread they're talking about the ways in which MotionPlus devices can severely scramble handshaking. Additionally, WiiBrew has a great page about Wiimotes and another about MotionPlus - there are still some unknowns out there, but these pages get as close to the hardware as I've seen. Don't waste your time if these seem familiar or unhelpful, I just thought I'd share on the off chance this might spark something.

Have you see what Baristan6 did with FreePIE? You're definitely on to something here, guys - keep it up!

Okay, installing VRPN now. Here I go. On one. No pressure. It's only a few million lines of C++, what could go wrong?

[CyberVillain]

We have alot of different libs with different licenses, what different is it that we license some parts of our source as MIT?

The only dll a third party software maker must include from FreePIE is the FreePIE.Core.Contracts.dll

[nateight]

We have alot of different libs with different licenses, what different is it that we license some parts of our source as MIT?

That will probably work then; I've never released software for public consumption so I'm entirely out of my depth at this point. That you are aware of the issues I mentioned is enough to quiet my concerns - I'm sure you'll get it sorted out in due time.

In a last-ditch attempt to avoid wrestling with VRPN (and in discovering a few reasons why I shouldn't even bother with it for now), I discovered someone who claims to have WiiYourself working inside UDK. I sent him an email asking if he would be willing to share his code for my project, and if he's open to that I can ask if he'd also let you have a peek if you want. Either way, WiiYourself stood out in my searches as one of the best Wiimote libraries currently available; documentation is thin, but its ancestor was apparently born as a very public project, and both creators seem open to queries if things get really troublesome. BillRoeske sounds like he's very close to having a solution, but if you hit a brick wall with WiiC and Dolphin I definitely think WiiYourself would be worth further investigation. Cheers!

[Direlight]

Glad you guys are still working on it. I hope 2eyeguy will also update Glovepie to work with the new remotes.

I'm finishing up my GP scripts (these should be very useful for VR and are very accurate) and my end goal will be a script archive for GP, FREEpie, auto hotkey etc.


Oculus, in my opinion, should look into Bluetooth 4.0 as it's only 3 ms latency delay. We need 9 axis, bluetooth 4.0 controllers for next generation VR. Wiimotes/move will still work great for mouse, joystick etc. legacy support.

Here's a 9 axis controller:

http://www.youtube.com/watch?feature=pl ... M2ybJhVuFE

PNI says they want to make advanced gaming controllers, so let's hope Oculus partners up with companies like them.

[BillRoeske]

Just a quick update: I'm in crunch mode for work leading up to the Ouya release, so I probably won't have much free time* until our game is locked down and published to the store. If I do have some time, I'll try to get the DLL project put together for my port of WiiC.

* minus some time with the Rift after it first arrives...

[ChrisJD]

http://www.youtube.com/watch?feature=pl ... M2ybJhVuFE

PNI says they want to make advanced gaming controllers, so let's hope Oculus partners up with companies like them.

Always good to see more companies working on the things I want to play with... but that video feels like it's straight out of the 70s

[BillRoeske]

PNI says they want to make advanced gaming controllers, so let's hope Oculus partners up with companies like them.

I claim no insider knowledge, but I believe that PNI is who makes the (rather astonishingly good) tracking component of the Wii U Game Pad.

[Direlight]

Wii U Game Pad

Wish it was modular like the old wiimote.

[CyberVillain]

Direlight, we just might have something to try for you very soon

[rocco156]

Hey everyone,

I was trying to get the motion track mouse stuff to work with my Android phone, but doesn't seem to work.
I opened the port 5555 in my firewall and I do get an response of some sort. I start the Freepie script, I got the Diagnostics.watch in place so I can see what it does, and all that gives me is android.googlePitch 0 once I start the UDP stream from the app. changing to android.Pitch yields the same results. The thing is, in the debug mode on the android app, only the magnetometer gives off a value, the accelerometer and gyro just give off 0 0 0. Is this an bug in my phone? in the app? my phone is the Huawei Ascend G300, and all the sensors work with all other apps.

thanks in advance,

rocco.

[CyberVillain]

@rocco

I moved discussion here http://www.mtbs3d.com/phpBB/viewtopic.p ... 63#p111263

[BillRoeske]

I finally found a few minutes to get my Win32-enabled port of WiiC wrapped up into a proper .dll project and hosted now that our Ouya game is in the final stages of review.

Any interested parties can grab it from here: https://code.google.com/p/wiic-mp/

Some quick notes:

• It should compile out-of-the-box with Visual Studio Express 2012 for Desktop. I also posted a compiled version of it (along with the test program) in the downloads section.
• The library itself is written in C with the proper calling convention decorations, so it should be callable from basically any language that can hook into standard DLLs.
• This is based on the same code used in the static library that I sent the Cyber brothers a while back, so the problem with recognizing their add-on Motion Plus module is probably still around. It does work with my gold Wii Remote Plus, though.

[BillRoeske]

As a quick note about one of those bullet-points, I'm almost positive that the issue with recognizing the separate Wii Motion Plus module is returning a device ID that the library currently isn't set up to handle yet. That could be pretty easily proven out by compiling a debug version of the DLL and sample app and putting a breakpoint in io_win.c around line #102.

[brantlew]

Cool, just in time for Rift release. Just need the last mile to get it into FreePIE.

FYI: I had hoped to get Rift SDK hooked into FreePIE in time for release, but I have had zero free time in weeks. So it will have to wait a while, or maybe some industrious soul will the have the time in a few days. The SDK is a lot more C++ than C so it's not going to be super easy like hooking directly into the Vuzix or Hydra API. It will require a custom bridge dll be created.

[CyberVillain]

Great work, we have made huge progress on our side too with the Dolphin branch.
It recognizes our integrated Wii plus, a standard wii and a China clone (We dont have a seperate Wii motion plus so cant test that). Just some cleanup todo and create a library out of it

[BillRoeske]

Huh. For some reason I had it in my head that you had a separate Motion Plus adapter, not an integrated one. I wonder what's up there, since the library seems to pick up on my integrated Wii Motion Plus just fine. Still, I'm happy to hear that you guys are making good progress. At this rate, it sounds like your Dolphin branch might be ready for prime time first.

Also, for some reason a Nyko clone wouldn't work on my system over here, even as far as making a stable Bluetooth connection to the PC. Weird.

[CyberVillain]

Huh. For some reason I had it in my head that you had a separate Motion Plus adapter, not an integrated one. I wonder what's up there, since the library seems to pick up on my integrated Wii Motion Plus just fine. Still, I'm happy to hear that you guys are making good progress. At this rate, it sounds like your Dolphin branch might be ready for prime time first.

Also, for some reason a Nyko clone wouldn't work on my system over here, even as far as making a stable Bluetooth connection to the PC. Weird.

Ah no, we only have the new integrated one, so once the lib is mature (in a couple of days) maybe someone with a extension wii mote can try that it works too

[CyberRascal]

I'm doing the dolphin wiimote stuff.

A lot of the implementation is actually mine, and not dolphin. The dolphin code is chiefly accessing the devices and pairing with them. I send binary data on the HID level according to the Wiibrew info. Dolphin just need to forward data from games -> wiimote, but I need to actually define these packets and send them at the correct times.

Regarding MotionPlus integrated vs as an extension; It actually registers itself same as the non-integrated MotionPlus, mostly like an extension.

Anyway, I've released the code under the name Dolphiimote on Github if anyone wants to check it out. I need to spend some more time to do proper discovery of extensions/motionplus, but after that it should be pretty usable. I will then integrate it into FreePIE.

https://github.com/maxmalmgren/DolphiiMote

[metronome]

wow it's amazing how quickly this is all moving on the wii, I can't wait to play HL2

Have you had any thoughts about using the JOG sensor? I've got one kicking about and all it does is inhibits the nunchucks movement signals unless it detects you are walking around.... Does that count as a quasi level of immersion? :p ie you have to walk around irl to move ingame....

[CyberVillain]

wow it's amazing how quickly this is all moving on the wii, I can't wait to play HL2

Have you had any thoughts about using the JOG sensor? I've got one kicking about and all it does is inhibits the nunchucks movement signals unless it detects you are walking around.... Does that count as a quasi level of immersion? :p ie you have to walk around irl to move ingame....

JOG is a extension? We will only support m+ out of the box, but CyberRascal is making it so that its easy for other devs to add in support for other Wiimote extensions

[metronome]

yeh it's this thing

http://www.youtube.com/watch?v=oE6mdsuW ... tQ&index=7

HL2 apparently! wonder how they've done that hmmmmm
http://www.youtube.com/watch?v=VvUtKK5S ... -WJr6KwmtQ

Aww cut to happy family playing wii lol... anyway it's little more than a glorified pedometer and just blocks the signal from the nunchuck unless it detects your moving around.... to give you the illusion of ooo look ur moving in game :O

I'll actually be quite surprised if it needs any kind of software support, but I'll give it a go at some point...

[GFD]

Like nateight, I'm also getting very interested in this FreePIE thing! You might see me around here a bit too. I've been using GlovePIE for years, but it's been more of a struggle to use on Windows 7, and I can only imagine it'll be worse when I get a new computer with Windows 8. It looks like I'll need to familiarize myself with Python, but that's the least of my worries.

I'm curious as to the scope of this project for a couple of reasons. Let me put out a scenario here: I have a game (SA2 in this case) that will only accept X360 controllers, but I don't have one. But, I do have a Classic Controller Pro. In the future, would FreePIE be able to allow me to use a CCPro with this game somehow? The only other solution I've found is to use x360ce, PPJoy, and GlovePIE together, but unfortunately x360ce simply will not interface with PPJoy on Win7 x64, and it doesn't look like the developers ever plan to fix that, so I don't really have any way to play this Steam game my friend just bought me. (Using the keyboard to play SA2 is simply not an option. Hideous.)

[CyberVillain]

Hope you going to like FreePIE, we try to keep it as bugfree as possible and it works great on w8

FreePIE can read both Xbox and DirectX joysticks and write to ppJoy would that help?

[mscoder610]

Hey CyberVillain,

I'm playing around with the Generic[6DOF]Plugin as an orientation data source in a project I'm working on. I wrote a simple script to send the roll/ pitch / yaw of my 2 Hydra controllers to another app / game, and that seems to work well.

One note from glancing at the plugin code though - it seems like the line that's creating the memory mapped file should be using "Marshal.SizeOf(typeof(Generic6DOF))*deviceCount" as the capacity (currently it's just using "Marshal.SizeOf(typeof(Generic6DOF))").

[CyberVillain]

Thats just to tell the memory mapper how big the struct is,

Code: Select all

accessor.WriteArray(0, data, 0, deviceCount);

WriteArray / ReadArray takes care of the actual array size

I hope its not a problem for you that the generic plugin isnt released in teh binary yet, im hoping we can get WiiMote support before next release.

Also in the final binary we will have c library that you can use for the generic plugin instead of using the memory mapped file directly

[mscoder610]

If I look at the view accessor's capacity right after creating it, it's 4096 bytes, which is I guess why everything is still working fine right now. But if the capacity (1 struct, 28 bytes) was being strictly honored there wouldn't be enough memory set aside to write all 4 DOF items.

No issues with not having an official binary yet, I'm not near releasing anything yet (still no Rift to try things on). I'd like to mainly target Rift (head tracking) + Hydra (gun aiming) in my project, but let people plug in other trackers if they want with FreePIE and this plugin.