Ooo, I like this one.

I kinda like this one. Simple and generic. Joysticks are sort of universally understood as a control mechanism.




(either that or some sort of stylized pie)

More of a cake though

Maybe if the cherry on top was a joystick - that would be sort of cute. But I'm no graphic artist. I think the plain joystick works better.

What do you guys think?

I like.

Cool.

Thanks for mentioning FreePIE in the nthusim hmd thread, brantlew - I had been completely overlooking it.

I'm not much of a programmer, but I think I might have some insight in avoiding some of the obstacles that FreePIE is running into. Hopefully you'll be willing to implement a fix

I don't think the sensors are the only ones causing drift. In fact, I wouldn't be surprised if their effects were just a small fraction of the issue. You can't emulate a mouse by just piping the tracker's delta values into the mouse emulator. Consider this case: In a FPS, the vertical viewing limit is +/-90 degrees from center. If you take your mouse and point the player's view at the limit looking up, all further mouse delta values are null. You can keep adding delta values, but the view won't change, yet as soon as you move the mouse to look down, the view changes - you don't have to make up for all the wasted positive delta values. So if you don't account for this, you will have immediately introduced drift. This perfectly explains why CyberVillain didn't have this issue when he disabled the vertical limiting in UDK. What you have to do is have a profile for the game that decalres minimum/maximum vertical viewing limits. So you have to be tracking some of your own delta values in FreePIE to account for for movements that extend outside of the game's limits.

As I've mentioned in the nthusim hmd thread, it might be nice to emulate a joystick so that you can have pretty stable tracking in games that have a "look spring" option - at least for vertical tracking (not good for horizontal tracking because it continually moves player orientation until the joystick is centered.

I'm sure there are still some other issues, but I really think this is the biggie.

Well that's true, and it can get even more complicated than that because tracker angles naturally hit a discontinuity at that high angle and then "flip" orientations so that the yaw spins 180 and the pitch starts moving back down towards 0. But the angles are all pretty crazy at the top and can create havok on the player view - even in an absolute coordinates system. But I think generally this is something you can handle heuristically in the script instead of the tracker interface.

But when we are talking about drift we are generally talking about the sensor angles becoming offset from their starting orientation over time. This is truly at the sensor and has to be fixed with some type of calibration. Another kind of drift is specific to mouse emulation and has to do with the game poller de-synchronizing with the mouse delta stream. If the poller misses a mouse update or two, then that also creates drift.

The drift isn't so much of an issue if you are using a gun controller, or mouse or whatever. Something else to control the view in addition to the head-tracker. Then its easy to re-adjust to the proper angle.

Maybe you can avoid issues at that the extreme ends of sensor input, by placing sensor angle limits a bit lower than the game's limits. I totally agree that it should be programmable via script (cool!) than somehow hard-coded in the program.




At least drift at the sensor level can be corrected fairly quickly in-game. But if you haven't been calculating the estimated vertical angle in the game, it would be somewhat more tedious to recalibrate (at least if you don't have a joystick). I haven't paid any attention to see if games still have re-centering as a hot key option - would be very useful.

I was thinking about potential polling issues. I'm assuming there's a buffer on the emulator side, so I don't know how the poller would miss an update (unless windows is doing some funny business in-between). Unless the buffer overflows, I can't see that there would be anything except some jitter. But again, if most games still feature re-centering, it's not as big a deal.


Having headtracking on my mind when I came across this thread, I walked in with tunnel vision - totally neglecting the big picture and spirit of FreePIE. I appreciate the work and effort that has been put into it, and am looking forward to trying it out with my Rift

Cheers!

Thanks. I've been neglecting the project, but I'm going to put some effort into it in November in preparation for all the custom support that people will want for the Rift. In particular I think Wiimote IR, Hydra, and Oculus SDK are all must-haves for the Rift release.

I think I might try poking and prodding in the code myself. And hopefully I might even be a little useful

Quick question - do you know if I can compile the code with the free version of VS?

Yes, I use VC# Express 2010. It complains when you load it, but it compiles fine.

the test projects will be excluded so just make sure you do not include the .sln in the pull request if you make one

I now realize everything I mentioned could indeed be done in script, I'll try tackling it there. That still leaves me wondering about mouse polling misses. Is there a buffer between the emulator and windows api mouse calls? Is there any reason to worry about mouse updates from the emulator being dropped?

The behavior would be different on different games and different computers. There is a small system buffer available but it's up to the developer to utilize it properly. Ideally the game engine would have a dedicated polling thread that was given high priority and managed buffered mouse input. Under these circumstances it's hard to miss a mouse update.

Most games I've seen the source for, poll the input before each render though. Meaning you get the same input poll frequency as the screen sync

Hmm,.. So it sounds like if you're updating the mouse deltas substantially faster than the rate the game polls at, you would eventually overflow any buffer. Is there any way of detecting when a game polls for the mouse data, and not send off the values until then, or right after?

@MSat: Not that I am aware of. But it's a good argument for having a configurable update rate in FreePIE.

http://www.mtbs3d.com/phpBB/viewtopic.php?f=139&t=15354

Interesting thread! I'm always late to the party


I was thinking something like this could work:


mouse.DeltaX = mouse.GetDeltaX + Xvar

Of course, the GetDeltaX function is made up. The thinking is FreePIE makes a call to the OS API to get the mouse values and clears the buffer. It then updates the deltas and sends it back to mouse.DeltaX.

I don't think it's a global shared buffer. I think each mouse signal broadcasts a mouse message to separate queues for each listening process.

I wish you weren't right, but I did some reading and I see what you mean. Having multiple separate mouse instances is an unfortunate feature. One thing I can't find out is if the DirectInput buffer accumulates all the deltas in one value - if so, that could alleviate the issue. I wonder if there's an easy way to get the frame rate from the GPU? Setting a maximum update rate works, but it would be nice if it could do it automagically

Its not that easy actually, you need to access the real time clock, and I'm pretty sure the game wont like that... But I havent had time to test this out

Is there step by step instructions on how to get freepie running? I have downloaded the official version, however I do not have any lua scripts present?

FRAPS (http://www.fraps.com/) is a benchmark tool that you run on DX or OpenGL games. One of the main features is that it can display the FPS. So it's definitely possible, but I admit that I have no idea how difficult it is.

While I have no conclusive proof, I get the impression that deltas do indeed get accumulated in the various windows API's mouse delta variables, and then cleared on read (unless the application requested absolute position). The only buffers - in DierctInput at least - appear to be for events such as keyboard/mouse button presses. So I would have to imagine Windows isn't just dumping mouse deltas. So, "assumptive" tracking is preserved.

One of the problems I can see with emulating the mouse without feedback from the game is the possible discontinuousness of tracking when switching from say first-person action view, to something like an in-game menu. One solution might be to intercept the keyboard/game pad's menu buttons, so that you can save the current tracking state, and start a new one. Then when it's closed, load the previous state and correct the tracking if necessary. Though this might be difficult if not impossible with games utilizing complex in-game menus.

There are none included, look here for some example ones

viewtopic.php?f=139&t=15052

just to test it out you could just do


its should print the mouse delta in teh watch window

Perfect - was able to get the mouse delta in the watch window

It was mentioned that the Iphone code was implemented into the build... do I still download the lua files seperately.

Thanks again!

@space123321: I don't currently have any example scripts up for the iPhone, but I will post one this evening. Please note that you must also purchase the Sensor Data app for iPhone to get this working. Also note that the iPhone has a significant stutter in it's tracking feed and may not be to your liking.

http://itunes.apple.com/us/app/sensor-data/id397619802?mt=8

Thanks again all!

I posted some more detailed information about using the iPhone

http://www.mtbs3d.com/phpBB/viewtopic.php?f=139&t=15484

was planning on realsing a new version tonight, but crashes when using diagnositcs:watch forces me to wait. Hoping for a release tomorrow

any chance of wii remote plus (wiimote with built in motion plus gyro) support?

I dont own one personally so can't help you there, maybe brantlew or someone else with the hardware could do it?

Uploaded 0.4.211.0 Lots of changes see first page for info

Hi as you can see I'm new here so I hope this is in the correct place.

I like my racing games and have never considered using head tracking until a friend put a Trackir headset on my head, hooked.
The price of the trackir was a total shock to me so I started playing with freetrack and found it to be good enough for what I will be using it for.
I've been playing a particular racing game but it has no support for head tracking or the ability to set the mouse to look around while driving.
In the game settings menu it allows me to set all the look functions Up,Down,Left and Right to the Xbox 360's left thumb stick which give a nice smooth look around but this is not optimal when using a Logitech wheel and driving at the same time.

In Freetrack I can setup the tracking to move the mouse for U,D,L,R.
Before having to learn this scripting , would it be possible to use FreePIE with FreeTrack to emulate the left thumb stick of a Xbox 360 controller with out having to use PPjoy

Hope that makes sense to you all.

Thank you

Madascanbe

XBox 360 gamepad emulation is not currently supported. PPJoy is supported but I am not sure whether that will emulate the gamepad joysticks.

Does it have to be a 360? FreePIE support emulating standard joysticks/gamepads

Check out the ppJoy plugin in freepie


edit: Missed that you didnt want to use ppJoy. Thats the only virtual DirectcX driver around

It's not that i don't want to use PPJoy it's more that it will not install on my system. Windows 7 64bit home
I have tried putting the OS into test mode and using driver signing software but everything i try just fails. I have read somewhere else it has something to do with using the home version.

Thank you for your reply's, think I will have to wait for the game to add Track IR support.

P.S. Just seen this bit "Does it have to be a 360? FreePIE support emulating standard joysticks/gamepads"
I only have a 360 pad so, yes it need to be a 360 pad.

I use Win7 Enterprise x64 and it works if I put it into Test mode, I didnt find anything on the net stating that it would be a difference with Home edition? Does it says test mode in the bottom right cornor? If not it wont work.



edit: If you use a Xbox 360 or not doesn matter, does the game support any DirectX device?