|
|
|
Junior Member
 
Group: Forum Members
Last Login: 9/28/2011 5:42:42 PM
Posts: 17,
Visits: 165
|
|
As many of you may know, the Wiimote works with standard Bluetooth and there are a number of freeware programs that can read the Wiimote state and use it to control the cursor onscreen. I'm currently working on getting the Wiimote to work in Eprime, but haven't succeeded yet. There are two key problems:
(1) The standalone programs that poll the Wiimote can be run prior to starting Eprime, but once an Eprime script is going it lowers the priority on all other processes, making the external Wiimote program almost useless.
(2) Although source code for accessing the Wiimote state is available, I have not yet found one that can be compiled into a dll that Eprime can access (there is a well-known dll available, but it's written specifically for .NET, and can't be accessed by Eprime).
So....HELP PLEASE!!! 
-Matt
|
|
|
|
|
Forum MVP
Group: Forum Members
Last Login: 2 days ago @ 5:27:05 PM
Posts: 707,
Visits: 2,733
|
|
Matt,
Are you sure that EP cannot access .NET .dlls? Since EP itself relies on .NET, that would surprise me. Many years ago I got access to standard Windows .dlls just following the documentation for the Declare statement in the E-Basic online help, and the process seemed rather generic, I had no idea that some .dlls would require specific languages for access.
-- David McFarlane, Professional Faultfinder
|
|
|
|
|
Junior Member
Group: Forum Members
Last Login: 9/28/2011 5:42:42 PM
Posts: 17,
Visits: 165
|
|
David,
Thanks for the quick response! I haven't been working on the Wiimote project for about a month, so my memory is a little rusty (plus after trying several other software packages, it's a blur!). But what I remember is downloading Brian Peek's .NET .dll for the Wiimote:
http://www.codeplex.com/WiimoteLib
The main problem I ran into when trying to run the .dll functions within Eprime involved an access error, i.e., "Specified DLL function not found, Error #453". I didn't dig much deeper at that point, but assumed it was a compatibility problem.
Looking back, there are a few possible explanations. In particular, I wasn't able to register the .dll in XP...when trying, I got "...DllRegisterServer entry point was not found. The file can not be registered." So I did make sure to use the full path to the .dll when calling it in Eprime, but maybe failing to register it was an issue.
Let me know if you have any advice or guidance.
Thanks again,
Matt
|
|
|
|
|
Forum MVP
Group: Forum Members
Last Login: 2 days ago @ 5:27:05 PM
Posts: 707,
Visits: 2,733
|
|
mattatsiuc (7/18/2008)
The main problem I ran into when trying to run the .dll functions within Eprime involved an access error, i.e., "Specified DLL function not found, Error #453".
If I saw that error then I would suspect that the .dll file does not contain that function, or maybe not by that exact name. I would check my Declare statement very carefully, and then I would wonder if the documentation for the .dll were correct. After that I might start thinking about weird incompatibilities. But really, if the function exists, and you have the correct name and file, then Declare should at least find it before you ran into any further incompatibilities in using it.
In particular, I wasn't able to register the .dll in XP...when trying, I got "...DllRegisterServer entry point was not found. The file can not be registered."
This still sounds to me like the function does not actually exist in that .dll file.
So I did make sure to use the full path to the .dll when calling it in Eprime, but maybe failing to register it was an issue.
I don't even know if a .dll has to be registered before you can use use it, so that is something to explore. I like to start from success, so here is my plan of attack: I would start with something that I know must work, e.g. a standard function from a standard Windows .dll file, and get that working with a Declare. If you can't get that to work then nothing else matters. Once that works, I might try purposely unregistering the .dll (I would of course pick a non-critical .dll!) to see whether I could still use it with a Declare, etc.
Let me know if you have any advice or guidance.
Sorry I can't provide much more help than that. And I'll be tuning out for the next few weeks, so I wouldn't be able to reply any further until then anyway.
Regards,
-- David McFarlane, Professional Faultfinder
|
|
|
|
|
Junior Member
Group: Forum Members
Last Login: 9/28/2011 5:42:42 PM
Posts: 17,
Visits: 165
|
|
David,
Great minds think alike: I've pretty much pursued the same ideas you raise--EXCEPT for unregistering a .dll!!--and still haven't cracked the nut. In particular, I had no trouble declaring and running standard Windows API functions. I've also kept open a VB session, to see what I can get working in VB but not Eprime. For the most part if it works in one it works in the other, and vice versa.
I should also note that the documentation with WiimoteLib is extensive and pretty clear, so getting the header declared correctly doesn't seem to be the problem.
Anyway, safe travels and thanks again for your input!
Given that the Wiimote is such a versatile input device, and with just a few tweaks it could be a great asset for the Eprime community, I may contact the "higher-ups" and try to escalate my question. 
Matt
|
|
|
|
|
Junior Member
Group: Forum Members
Last Login: 9/28/2011 5:42:42 PM
Posts: 17,
Visits: 165
|
|
I just realized, for Nintendo Wii "newbies", that I've left out a lot of information:
(1) I figure we all know (by now!) that the Wii runs about $250 for the base system, and includes a hand-held wireless remote (Wiimote) that not only has a set of conventional buttons, but perhaps more importantly...
(2) Built-in accelerometers that indicate the position/motion of the Wiimote in 3 dimensions, and...
(3) Built-in IR sensors, that act as a secondary system for localizing the Wiimote in 3D
(4) The base system comes with a (deceptively-named) "sensor bar". It is no such thing...the sensor bar is actually a panel of infrared (IR) lights, while the REAL IR sensor is on the front of the Wiimote!
But here is the best part!
(5) If you have a computer with a Bluetooth card (or $10 USB dongle), it will pick up the Wiimote signal! This means you can buy a $40 Wiimote off the shelf (forget the $250 base system) and you have a hand-held, 3D pointing device that your computer can access! Very nice.
(6) You don't need the so-called sensor bar, but you *do* need an array of IR lights for the Wiimote to be properly calibrated. One cheap solution is to buy a battery-run third-party sensor bar (attach it to the top or bottom of your computer monitor) for about $15.
If anyone is interested in trying the Wiimote as an input device, or maybe just view some demo video, feel free to chime in...we can exchange links and ideas. In the meantime, here is a very, very cool example of how the Wiimote can be used to create a 3D video experience (check out the third video)!
http://www.baekdal.com/future/User-Experience/multi-touch-whiteboard/
Matt
|
|
|
|
|
Forum MVP
Group: Administrators
Last Login: 2/1/2012 1:26:10 PM
Posts: 652,
Visits: 1,441
|
|
| E-Basic is capable of calling DLL entry points and manipulate COM/ActiveX Automation objects with some limitations (see below). The library that you desribe here appears to be a "managed .NET library". Without going into this too technically (there are a number of books and google - search for Managed Assembly), a .NET object does reside in a .dll but does not have any public/usable entry points by E-Basic. It can only be used from another Managed .NET application that can consume it. So you'll either have to find a "wiimote" ActiveX object or create a traditional .dll or ActiveX wrapper around these libraries to be able to be called by E-Basic. A quick google search did not on the surface provide any alternatives. I did find a number of resources where people have created .NET Managed and C++ callable libraries. Making a proxy wrapper around these is outside of the scope of the support I can provide, but I can offer some direction if this is going to be pursued. As with any device, I also have to throw in that PST cannot claim any timing information in regards to using a wiimote. I am not privy to the technical specifications for BlueTooth, but since it is wireless and works on an enumeration bus there could be some variable delays. Similar to USB, bluetooth may be set up default where it can transfer quickly in bursts but does not provide a consistent connection method. Of course there is the debounce and hardware latency issues with the buttons too. E-Basic limitations for calling .dll are most noteably...
1) Do not support the BYTE data type
2) Do not support the use of early binding with a .tlb Type Library (must use late binding through CreateObject)
3) Do not support routines that attempt to access the dispaly hardware directly.
|
|
|
|
|
Forum Newbie
Group: Forum Members
Last Login: 2/2/2011 7:48:28 AM
Posts: 7,
Visits: 98
|
|
Hello,
I came across this message board in search for a way of applying the Wiimote to E-prime. Was this issue ever resolved?
Unfortunately I'm not that technical and can't address the issue myself, also the last post doesn't look all that hopeful, but a year has passed and perhaps someone came up with something clever?
|
|
|
|
|
Junior Member
Group: Forum Members
Last Login: 9/28/2011 5:42:42 PM
Posts: 17,
Visits: 165
|
|
Rorschach (8/25/2009)
Hello,
I came across this message board in search for a way of applying the Wiimote to E-prime. Was this issue ever resolved?
Unfortunately I'm not that technical and can't address the issue myself, also the last post doesn't look all that hopeful, but a year has passed and perhaps someone came up with something clever?
Yeah I'm sorry to report that I don't know of any progress on this issue. I'm really flummoxed by it because the Wiimote is such an obvious and intuitive input device, and more importantly, incorporating it into EPrime looks like a pretty straightforward problem: the two huge assets are (1) it is a Bluetooth device, and (2) EBasic should have access to the necessary APIs or dlls to read the Wiimote state. At least in principle.
My secret hope (has it been a year???) was that Brandon or someone with the appropriate skill set would be "tasked" by PST to set up the functionality as perhaps an add-on or extension. As a university researcher in psychology, my programming skills are sufficient, but where they fall short is interaction with hardware. I've hoped to find a CS student who could write the dll in C for me, but I seriously doubt that will happen anytime soon.
Sorry for the doom and gloom. At the very least, it would be interesting if PST set up a small user survey, and found out (among other things) whether there is an interest in "newer" technologies like this. I'd be willing to bet (for the $40 investment in a Wiimote) that many users would jump on it.
Please let us know if you learn anything more!
-Matt
|
|
|
|
|
Forum Newbie
Group: Forum Members
Last Login: 2/2/2011 7:48:28 AM
Posts: 7,
Visits: 98
|
|
Thank you, I will.
I'm poking around here and there, but so far not much luck I'm afraid.
|
|
|
|
