Match skilled people with the projects that need their talents.
Authors
Recent Posts
See AllAll In
Recently I've been devoting time statring up an offshoot from last semester's RCOS project. One of the major hurdles when developing Reroot was dealing with simulating input. When we started the project, we figured we wouldn't have a problem finding a library that was (1) open source, (2) cross platform and (3) suitable for Reroot (i.e., needed to be compatible with games, etc.). There were several options that fit these requirements for detecting input, but as we found out, existing projects for emulating input only met one of these requirements, and there was absolutely nothing cross platform.
We decided that we would have to develop the input emulation on our own. Since Windows was our top priority, I implemented that first, and left room where Linux and other OS implementations could go. Even with just Windows, there were some unavoidable problems. Many games (those using DirectInput) look for input at a lower level than OS input events, meaning the standard OS API calls won't reach them. Turns out there is a work around that works for most keys, but non-printing keys (such as the arrow keys) still won't be picked up by these programs. It appears to be possible somehow, there is at least one program (closed source) that manages to do so without additional drivers or services. I'm attempting to reverse engineer it, but in the mean time, most of Windows keyboard and mouse simulation is complete.
Anyways, I had planned to seperate the input simulation code into its own library so others would have access to cross platform simulation (though I don't imagine the demand is huge). I've started to do so, as the "All In" library. In the past couple of weeks, I have begun porting the code to C, set up a CMake project to build both static and dynamic libraries, and a simple test program that reads in scripts of input commands and executes them with the DLL. I've started the Linux portions of the code too. Right now basic mouse stuff is working in Linux.
I chose to port the code to strictly C for maximum portability. It's been a little more work than I anticipated, usually because of little deviations between C and C++. I've also tried to make it as adaptable as possible to other OSes as possible. Once most of the meat of the library is done, I plan to write a C++ wrapper for better integration into object-oriented programs.
Creating a test program is something I should have done right away when working on Reroot. When working on Reroot, becaues it would take too long to pair a phone everytime I tested an input, testing was normally done by calling the function from a GUI event. Although faster than using an actual phone, this was still clunky and slow. With the test program, to test a new input, all I have to do is type something like "MOUSE CLICK LEFT" and run the program to test an input. It's a lot faster to recompile the DLL and test program than the whole Reroot binary too. So, lesson learned, don't be afraid to invest some time upfront if it will save you a lot of time and effort over the course of the project.
The rest of the Linux functionality should soon follow. Following that, if I can get access to a OS X system to test on, that will be my next priority. Otherwise, I'll start looking into simulating joysticks.
The repository can be found here: https://github.com/nevilc/allin
Slides
Looks like I forgot to post my slides before I left last week: https://docs.google.com/presentation/d/1fgm82bIyJalgl_zyg1QyFj2vM6BkEYH-H02pcdiIyRc/edit
Feedback
After being away last week without Internet, here's a post about some of the suggestions I've gotten about the project.
After the RCOS presentation, a couple people had suggestions for the system. One was a concern about people misjudging their abilities in a given skill, and whether there would be a mechanism to mark someone else's skill ranking as inaccurate, if, upon teaming up with someone, you found they couldn't deliver what they promised. Judging one's self is difficult, and I don't want users to ever feel 'punished' because they thought they were a little better than they were. I'd rather try positive re-enforcement: users should correct their own skill rankings, because doing so will get them better matches, not because others will contest it otherwise. The skill rankings are mostly intended as a search tool primarily, they are no replacement for looking through real code that user has written, or interviewing them personally. As another way for humans to check a another's qualifications, I plan to implement 'references,' other users on the site who can vouch for his or her abilities. When a group has a positive experience together, they will also be able to add each other as references, allowing others to get an outside perspective of another's abilities.
I was also pointed to Harvard Catalyst (http://catalyst.harvard.edu/) by my Dad, which is a site with many similarities, designed to connect medical researchers within Harvard and other participating institutions. One of Catalyst's major strengths is its ability to automate gathering user information. This way, a new user does not have to spend an excessive amount of time filling in prior work, etc. For example, Catalyst scans a user's uploaded scientific papers and picks out colleagues and relevant keywords. Reducing the commitment required to setup a new account would really help the project to reach a critical mass. While scanning research papers won't be useful for most projects, github/Google code/Bitbucket accounts are a great source of information about a programmer's experience, and at the very least, github already tracks statistics such as programming language breakdown. Keyword scanning in project readme files could even establish areas of interest. It probably won't make it in over the summer, but the faster a user can get their account set up, the better.
