Do not include me in that!

Personally, I'd like to use C++ for this. Mainly because I have invested a lot of time recently to learning it (reading the 1500 page tome that is C++ Primer Plus). But also because most device APIs are written for C++ (or at least C). I don't have as much experience (or much at all really) with C#, though if it really is a better fit for this project then I am open to learning it.

Personally, I like C++ myself. Pretty much anything you need to do in C, can be done in C++. However, if the architecture is correct, you could let people develop additional interfaces in lots of different languages as long as they can compile to a DLL.

For GUI stuff you'd probably be better off with C#, VB.NET, or whatever else you prefer, simply because its quicker and easier to develop a gui using these systems.

I wouldn't consider trying for cross platform support yet, especially for an application that basically has custom drivers. Differences between the way different OS's do things mean it wouldn't be 100% cross compatible without extra work anyway.

CyberReality, if you can handle C++, you'll pick up C# very easily. A lot like C++ without writing headers.

I believe PPJoy doesn't work on 64 bit windows due to requiring a hardware driver certificate. I think I needed to use 'test' mode to get it going. However, I was reading a security site recently and noticed that there have been several trojans/viruses recently that have used stolen keys to sign their own drivers so users don't notice them being installed. I was wondering if we could just piggyback on one of these and use it to install on 64 bit wihout needing test mode?

I concur that C++ is the way to go for the device interfaces. The C++ syntax and compilers are much easier to use. When I talk about programming in C, I am usually just talking about a style of programming that uses lots of top-to-bottom function calls instead of big convoluted class infrastructures. But I always use C++ syntax rules. When writing hardware interfaces you tend to naturally gravitate toward the simpler functional style anyway just because everything you link with tends to be implemented that way.

As far as Windows GUI programming goes - I spent 5 years working in MFC (C++) at one job and was quite adept at it (near guru level), but I would never go back to it after using .Net. And of course C# is the poster child for .Net so it is a logical choice.

Yeah, I think the main framework should be in C# because its so nice to have that in a managed langauge.
Except for the texteditor I think the C# project will be very light, maybe a few of the input / output plugins will be written in it, but for some cases we will have to invoke C++ code, thats very easy todo from C# so I still think we should go for C# interfaces and plugins and that the plugins that need it invoke CPP code...

A managed language is so much nicer to work with when it comes to a software like this, much easier to keep it clean and tidy... And dont get me started on WPF, together with a MVVM framework like Caliburn its a dream to work with

Trouble with .net is when it sends me off to install a massive framework to run a tiny app. Very annoying.

The issue with .net is the cost of managed to unmanaged transitions, if you're expecting client software to be largely C++ then I'd write it in C++, if you're expecting them to be .net it probably doesn't much matter.

True. Microsoft really needs to settle with a stable .NET version for a few years - or better backwards compatibility. You would think a brand new Windows 7 install would not require any .Net runtime installs but you would be wrong. Unfortunately with all the dramatic GUI changes in Windows 8, it probably won't get better anytime soon. Reminds me of DirectX. It took them 9 1/2 versions to finally stabilize that API.

I actually do prefer linux, but its no good for games. A true linux geek wouldn't want this anyway, VR on linux would probably be SERIOUS VR, and the source code would be available to add support right into the app, no hackish glovepie thing needed.

With all the dramatic changes in Win8 GUI, Microsoft will abandon .NET, so there's no point to code something for it anyway.

No they will not... You can choose between a few different and WPF will still be among those you can use for developing Metro apps

I have to ask, what is it programmer guys like so much about .net? I do a little programming, but it's all C on bare metal. The idea of running what look like native apps, in a virtual machine, just seems insane. From a hardware guys perspective .net is an absolute nightmare. (I admit I am very biased, in the recoil simulator I am working on, I am using a 16bit, 16 Mhz microcontroller, and it seems stupidly, excessivly, powerfull. I'm also hoping to do at least a little bit of the code in assembly language. Perhaps I am just masochistic?)

Is it even possible to write windows GUI apps in pure C or C++?

PS, sorry for going off topic a little, but it didn't seem worth starting a new thread.

You are right. When you're programming close to the metal there's nothing better than good ol' C because you can control exactly what is going on and typically the scope of the project is such that you can keep it all in your head at once.

But once the application reaches a certain level of complexity it becomes difficult to keep all the pieces in your head and bugs start creeping in. This is especially true once you start getting into big multi-threaded apps and event driven GUI applications.

The biggest reasons I like run-time sandboxes like .NET or Java is because of memory management and graceful exception handling. That's where all your problems in C code stem from and I have spent untold weeks putting in debug statements and writing log files just to catch some incredibly obscure memory race condition in multi-threaded network and data servers. You put all these statements in to try to isolate the bug, wait 2 weeks for it to occur, and then POW! - your server throws a null pointer exception and is gone! That was 15 years ago and I would have loved to have a good managed environment back then.

Another reason I like something like .NET is as a GUI scaffold. You can write GUI's in C but sheer magnitude of code you have to write (without scaffolding) is overwhelming. These big libraries may be big and unwieldy but they save you untold weeks of time reinventing and debugging the wheel.

Yup, I can understand that. I supose I'm just annoyed that no matter how much hardware I shove in a PC build it always feels a bit slow.

@ bobv5: I love the fact that I can write in either VB.NET OR C# and its basically the same, just a bit of syntax differences (ok, other differences as well, but its very easy to go from one to the other). On top of that, its WAY easier than writing stuff in C++, even with MFC support. You can write guis in straight C/C++ no problem (I think lots of earlier Windows stuff was done just this way), but it seems a waste of time nowadays. If you need super performance, you can just call an optimized routine (that you have written in whatever) from your slow VB.NET program etc. Therefore, I see absolutely no need to write stuff directly anymore to do all the GUI/events etc.

I know what you mean about slow tho, I used to be totally this way from my days programming in DOS. There was a big shift I had to go through, from coding everything myself and caring about every bit of performance, to leveraging other peoples code and getting users to buy better hardware. At the speed PC horsepower is progressing, its often cheaper and more efficient to just upgrade hardware than to optimize once you reach a certain point (if your code is designed badly, no hardware will make it perform/scale well).

Also as Brantlew says, garbage collection and exception handling etc makes life much easier.

There are also frameworks you can use with C++ that make GUI stuff easier, like Qt or wxWidgets. Its not like you have to do everything from scratch. But yeah, still nowhere near as easy as using the designer with C#.

No real developer use the designer Bleh its crap.. WPF is so nice the XAML format is almost as nice as xHTML/CSS3....

edit: Lol, performance, its always about performance.. Cpp for normal kind of apps are not faster at all (The kind we are talking about here).. Managed directX (the kind you used in games for managed languages) are about 5-15% slower then its none managed counterpart, so games still have a performance boost using none managed languages. Performance is often not the issue, in my line of work (Working as an architect for enterprise business apps) scalability and maintainability is the real issue, and you just dont get that with C/Cpp. .NET is the way for those apps.. Its the same case for many client apps written in Cpp they would have been as good in .NET probably better...

edit2: Missed brantlew and WiredEarps answers before writing mine.. They pretty much nail why .NET is more scalable and maintainable...

Haven't had the need to use WPF, but the .NET designer isnt _crap_. Its easy to use and you can whip up a Windows app very quickly.
WPF may well be much better (especially for graphical stuff and 'new look' applications) but that doesn't make the old style designer worthless.
What are some good reasons to change? If its going to make things quicker and easier, I might give it a try for my next app...

Well written C++ can be both very scalable, and very maintainable, if designed correctly (I find OOP is great for preserving maintainability for big projects). However, for the vast majority of the stuff people want to write, .NET is way less hassle than those older languages. The slight difference in performance is not usually important, especially when taken against the decreased coding time. No writing header files is one of my fave improvements...

No header files, but you should always decouple with an interface and a IoC pattern (Inversion of Control). (Thus you still need to have your definitions in a separate file, like head files)

Well, your talking about the Win32 API for .NET right (WinForms)? It has the same problem has the Win32 Api for Cpp, its very hard to design flexible and dynamic GUIs. You have to use that crap dock and anchor stuff.... Its so much easier in WPF..

If you want to stack controls that you do not know their individual size you just do

<Stackpanel Orientation="Vertical">
<Control1></Control1>
<Control2></Control2>
<Control3></Control3>
</Stackpanel>

If you resize the window each control will respond correctly automatic.. This was a PAIN in WinForms, so its not just for graphic intense software that you gain advantages changing from WinForms to WPF. Also the databinding is so much nicer in WPF than in Winform. This opens up a entire new world with MVVM (Model View ViewModel)... Theres no data grid included with WPF like in winforms though, so if you are doing a business app you need to buy a third party one (Or use a open source if its a private project)

Sounds interesting, might give it a go next time. Although I think you can do automatic resizing like that with the old style IDE by putting the controls inside a container element. Dock and anchor is definitely a lot better than nothing however (old days you had to resize everything yourself!).

Re the databinding, it sounds like it actually might be worth using. I'm very old school (I predate VB 1.0 with SuperBase4) so I haven't used data aware stuff since I tried it years back and didn't like it (I found those old data bound controls, including datagrid, were shite... but perhaps thats because I always want to change some things about them and have to end up doing stuff to work around how they work by default). Sounds like I should look into WPF for my next project. Is the GUI designer better than the old one or is it basically the same (drag controls from toolbox onto form, double click to edit code etc), or do you have to manually like your code to the controls like you did using dialogs in C++?

Definitely the old designer fell down when it came to dynamic, resizable stuff - which is so much more important nowadays with web apps and devices with different screen sizes and resolutions.

I started coding back in the day (1987) so i know what youre talking about
I wrote an entire wrapper lib for WIN32 to get it more like WPF (I even had XMl defintions for the screens)...

TwoWay binding is the poop (Lol the forum wont let me type sh it), if you cant do it with databinding its the controls fault (Mainly third party ones) not Databinding as a pattern.. Have a look into Caliburn micro, its THE framework for MVVM under WPF.

http://caliburnmicro.codeplex.com

Its convention based, so if you have a Dropdown with name Customers

<Dropdown x:Name="Customers" />

and on your ViewModel you have a property

public IEnumerable<CustomerViewModel> Customers { get; set; }

it will auto magically bind against that. And if you have a property

public CustomerViewModel SelectedCustomer { get; set; }

it will auto magically bind against that if you select an item in the dropdown

If a convention isnt there or you dont like the default ones you can add your own to the bootstrapper of the framework

If you change from datatype IEnumerable<T> to BindableCollection<T> it will even listen to changes both on the collection and properties on the items in the collection, so if you remove an item or change the property that binds to the Text property of the dropdown item it will update the view with zero effort from you..

edit: Forgot to mention the designer, I do not use it myself i like doing my view in xaml instead, but what I heard its lightyears better than the one in winforms.. Still has its drawbacks though...

Sounds very interesting, I guess I'll give it a shot next project I do, just to get some experience with it so I can judge it fully. It does sound like its taking a lot of the donkey work out of things...

Well, I will certainly want to investigate this further. Sounds like it could be useful stuff to know.

So can you use all this stuff with the Express version of Visual Studio, or do you need to pay?

Caliburn micro is a open source framework so it will work... i work at a company thats gold membership partner with MS which means we all get access to every singel ms program.. very nice

If you guys give me an Ok and that we agree on a name for the Software/Project I can design the basic architecture and create a Github repository. With basic architecture I mean interfaces and core projects and put together the softwares main API, also setup WPF with caliburn micro and give it some basic functionality (Like input/output configuration possibilities etc)...

Well my original idea for a name was "ioVR", which I guess is my first pick.

A lot of other good stuff is taken. Maybe we could do something with these words:

Open, Scriptable, Programmable, Input, Output, Peripheral, Virtual, Reality, Device, Driver, Interface, Controller.

Also, before we setup a git repo, we should talk more about the general architecture and how it would work. I am very much in favor of a plug-in style architecture, where each device would have its own DLL that could just be dropped into a folder and show up in the program. That way people can add their own devices themselves (possibly proprietary stuff, under NDA, etc.). I assume you can call functions in a DLL from C#. Or is there a better way to handle this?

One last thing, I am currently in the research stages for a DirectX9 3D driver. The first step of this was to just make it output for stereo 3D, but down the line I'd like to add stuff that interfaces with peripherals, for example for real 6DOF headtracking (not mouse emulation) and stuff like that. Do you think we should combine these projects into one, or should they be two different things just highly compatible. Is there a way we can make this peripheral driver have some sort of API that could be hooked into from external programs (like this 3D driver I want to make)?

Also, can we use LuaJIT ( http://luajit.org/luajit.html )?

A plugin structure is my plan, they do not have to be in a seperate dll though.. the core ones for example will be in the a coreplugin dll... Ill just find all dlls in programfolder/plugins and get all the classes that implements the interface IIOPlugin (Or what we will name it)

I do not now if we wanna add that dx stuff directly? Maybe two programs that communicate using shared memory or something...
About Lua i was thinking about using this one http://luaforge.net/projects/luainterface/

Found this site. Maybe somebody wants to try it.

http://acronymcreator.net

RADICLE ReAlity Device Interface ControlLEr
PADDINg ProgrAmmable Device Driver INterface
bIOnIC Input Output Interface Controller
REDIRECT REality Device InteRfacE ConTroller
INDIRECT INput Device InteRfacE ConTroller
PARTICLE ProgrAmmable RealiTy Interface ControlLEr
PeRVeRtED PRogrammable Virtual REality Driver

HahahahHAHAHAhAHahah!!!!

Yeah, it might make sense to keep them separate. Do you think we could find a way to expose a sort of standard gamepad, that developers could support in games. Sort of like the way you can use a Xbox 360 pad for PC games, except we would have a generic VR controller (with some standard set of functionality). That way I can just support this "VR Controller" in my app, and other developers could potentially do the same. The controller would respond with its capabilities, for example it could say if it were 3DOF, 6DOF, 9DOF, etc. how many buttons it has, etc. I guess we would need some more specific ways to handle gestures for something like the Kinect. Not sure the best way to handle that.

Don't know if you already knew about this, or if it is even useful: http://en.wikipedia.org/wiki/VRPN

From what I understand, it makes it easy to use different VR tracking devices to control the same software.

Of course it is useful!
It is standard that supported by many tracking systems, OptiTrack, Polhemius and many other supported natively.

One of the great benefits that you can use it via network, so trackers can be connected to one physical computer and you can run game / simulation on the other.

For example, great free-to-use VRPN Server for Kinect:
http://projects.ict.usc.edu/mxr/faast/

Maybe a stupid question: does this VRPN do everything we need to do here? Are we re-inventing the wheel...

Hah, you tell me! Like Mnemonic says, it is definitely useful (It is what we use at my work, hooked up to a combo Phasespace/Kinect tracking system), but as far as I know, it does not support any commercial games. Perhaps all you have to do is add some kind of abstraction layer between VRPN and a gamepad/keyboard/mouse emulator? Or have it hook into DirectX directly?

I think it makes a lot of sense to take a GOOD look at VRPN before we push forward with a design choice. I would go so far as to implement one or two devices into VRPN (like the Sparkfun or Vuzix - both of which we have code for) just so that we can speak intelligently about it. Now it may turn out to be too complex and high-concept or even inadequate for our problem - but then again, I'm sure there were several smart people that spent at least a semester or two thinking deeply about this problem and it could be enlightening to understand what they came up with. Because what we have now is not much more than a basic scope understanding and a "napkin-design" and I'm certain that there are dozens of issues that we will encounter that could change our design choices drastically.

Yep, my thoughts exactly (said this way earlier in this thread).

For myself, VRPN does most of what it sounds like we are going to do, and it can be tied together with scripting or code to do what I need. A GUI is useful for many people who don't want to code, but for myself, it doesn't really seem to be necessary.

The only thing I really need GlovePIE for is TrackIR support, so if I could get the code modules to do this (out of Freetrack source maybe?) then I'd just use VRPN and some code to develop my interfaces. With VRPN, you can easily hook it into DirectX, mouse, emulator, etc, just by developing modules to do this and translating the calls from VRPN to the modules.

A few thoughts on VRPN after digging around for a few minutes:

- It is primarily designed to convert a large number of specific input devices into a smaller set of generic device "types". Client apps (primarily graphics) can then register handlers for one of these generic devices. So for example if your game is written to accept data from a generic VRPN "tracker", you can easily switch out the actual tracker device from Vuzix to TrackIR etc... and the application will not know the difference.

- That's a pretty nice concept and reminds me of how CyBerReality wants to standardize VR API's, but it's really only half the equation as far as we are concerned. What does not seem to be included or designed for is device emulation. Right now it seems that client applications are expected to be written with a VRPN interface. As a result you can't "hook" into existing games and control them via mouse emulation or TrackIR emulation.

- There are some great features that we have not even discussed which are already built into the framework that would be beneficial: things like clock-synchronization, input recording and playback, and (of course) device type generalization.

- There may be baggage left over from the fact that it's a NIX style project. For example its all IP socket based. Nice clean design but more overhead than is strictly necessary. Would need to evaluate performance and design impact.

- Overall I think VRPN offers a good starting point that would help structure and guide the design. However it seems as though we would need to come up with an elegant way to extend it to include device emulation as well as scipting.

Nice finds! It sounds like what whe should do is create a VRPN Input plugin in our software since their goals are not exactly the same. The biggest goal (For me at least) is to get Headtracking and body tracking into games that does not support it...

Since there is VRPN already for most of the major input devices, it sounds like its the OUTPUT devices that need work. IE, we need a good mouse emulation class, a good TrackIR emulation class, etc. An GUI designer could then provide the ability to 'glue' these interfaces together, just like GlovePIE does with its GUI. The only difference, is this one would be leveraging the existing power of VRPN etc.

I was anti the IP socket bit of VRPN at first myself (seems like its just adding hassle for a single PC system) but thinking about it I dont believe it will cause any performance problems or latency, and it provides the useful ability to run everything on different systems as required.

To get an idea of the latency of using IP system, type this in a command prompt--

ping 127.0.0.1

That will make the computer test how how much latency is on the loopback connection to itself. On mine it is too small to measusre- 0ms. I would guess all machines give a similar number.

I know that is not sending any actual data, but still gives an idea of latency.

I definetly think this should be able to take vrpn inputs, even if it is alongside other inputs, (freetrack, wiimote etc). It seems silly to be going against the work other people have done to standardise this stuff.