[Unknown Target]

Is there any way to add hooks to the code that would lock into TIR's code without requiring that the SDK be implemented into the EXE? There was also a program running about the internet awhile ago that let you use a webcam to do the same thing TIR does using regular light - I'm sure that's open source and could be somehow implemented.

[Nuke]

GlovePIE is a program that lets you map different controls to different inputs. You can map keyboard keys to a virtual joystick, joystick input to a virtual mouse, etc.

It also uses a scripting language so that you can modify inputs to match your needs so you could for example add a deadzone to a joystick, make a linear stick act on a logarithmic scale and probably a lot of other things.

sounds pretty good. im glad theres other people developing stuff like this. i wish there was an open source vitrual stick though.

Is there any way to add hooks to the code that would lock into TIR's code without requiring that the SDK be implemented into the EXE? There was also a program running about the internet awhile ago that let you use a webcam to do the same thing TIR does using regular light - I'm sure that's open source and could be somehow implemented.

ive used 2 webcam based head tracker programs on the internet. one was open source. though neither has the performance or compatability that the track ir has. i also tried writing a script for the trackir mouse emulation, but i cant seem to get the cameras to move.

[WMCoolmon]

Is there any way to add hooks to the code that would lock into TIR's code without requiring that the SDK be implemented into the EXE? There was also a program running about the internet awhile ago that let you use a webcam to do the same thing TIR does using regular light - I'm sure that's open source and could be somehow implemented.

The easiest thing would be for someone to create a DLL that internally handles the lowlevel functions of interacting with the TrackIR, and provides a few very high-level functions to the EXE that it could use.

Since TrackIR is Win32-only, this wouldn't impact cross-platform friendliness any more than implementing the code in the EXE would.

From a legal standpoint, the issue that I see possibly cropping up from that message is that other open-source software would also be able to use the same DLL to use TrackIR as well. I don't remember seeing anything in the legalese, but I did not fully research the DLL idea.



What I'd planned to do for BtRL was to create a high-level interface, much like you would for the DLL idea. However, all of the code that directly referenced the SDK would be stored in a separate source code file that only I had access to, and the code contained in CVS would be toggled with a compiler flag (So that you could compile it without the SDK, and there wouldn't be any errors due to the missing source code file). This would also hide the actual SDK functions, but it would also prevent any other programs from accessing the TrackIR device, at least through C functions.

Even though the source code would be in the EXE, it would be compiled and the only way to get at it would be to start disassembling the EXE in some fashion - something that any other application making use of TrackIR would also be vulnerable. (It's the nature of an executable)