Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: Unknown Target on August 04, 2007, 08:24:55 pm
-
I think this was mentioned many ages ago, but nothing ever came of it. I would really like to have some more complex view commands in FSO, like flyby, the ability to rotate the view, locked spot (i.e. the camera doesn't rotate with the ship) the ability to use it with a mouse or hat stick...any possibility anytime ever? :)
-
Lock spot works. I think you press enter when in rotating view and it locks the camera.
-
It locks the camera to the ship - I mean where the camera stays put and the ship rotates around freely (Rather than having to choose between rotating the camera and having the ship stay put, or rotating the ship and having the camera stay locked onto it).
-
there are sexps to do all these things
-
That may work in theory, but it should be built into the game anyway, not at the discretion of the mission builder IMO.
-
seeing as i just got my trackIR, it would be cool if the engine supported it.
sexp aqnd scriptable view capabilities exist. the sexp ones are more or less for cutscenes and in mission cinematics. the scripted cameras are somewhat more versatile.
-
your talking about dynamic eyepoints...that require cockpits too not look weird.
-
IIRC the camera view point stuff is in the road map for 3.7 ish.
I had a look at the code the other day and decided that as I didn't understand 3/4 of the abbreviations it probably wouldn't be a good idea to try and hack it around. I may have another look in a week or so to see if I can work anything out (when i have more time).
I was looking at improving the look up / look back / look left / look right locked views to something more useful.
I was looking at a TrackIR then decided that a Wii remote strapped to my headset would work just as well even if it does look a little silly :-/
-
im really liking my track ir. the only gripe i have is the fairly closed sdk. i hear they will practically give it to anyone who asks for a copy, however youre only allowed to use it for comercial games (i havent read the eula on it yet). but d2xxl is using it so i figure the scp could too.
that aside you still can get 2 axis mouse emulation. i didnt like it too much because the track ir seems best used in absolute coords, which a mouse cant do. lua can be written to use this to set view angle. though i cant find the time or energy to write the damn script.
theres also a 3rd party util to output to a ppjoy virtual joystick driver. it works ok until you hit f12 to recenter. so you essentially have to exit your game to reset your viewpoint. you get a 6dof camera control via this route. but the con is most games dont use absolute joystick axes, rather they use an axis to represent a rotational acceleration or velocity. mechwarrior 2 is the only game i know where your joystick provides absolute control. for games to use track ir joystick emulation. you would need that mw2 style controllability.
none the less its a new kind of device (for gaming anyway) and no standard interface exists for it yet.
-
im really liking my track ir. the only gripe i have is the fairly closed sdk. i hear they will practically give it to anyone who asks for a copy, however youre only allowed to use it for comercial games (i havent read the eula on it yet). but d2xxl is using it so i figure the scp could too.
It was considered acceptable to use it for BTRL. I was going to implement it, before time issues got in the way, and I eventually sent the device back without getting much chance to try it out.
However, while I did have it, I took a look at the SDK and given the features of the device, I can't think of anything that would be immediately easier to use. Adding a scripting interface for it would be incredibly easy, at least relatively speaking.
The biggest issue is that it's closed source, so none of the code could be added to CVS. Basically this means that you would have to have a separate source code file containing all direct references to the API, and/or an entirely separate DLL loaded by Freespace 2. (It's Windows only, anyway, so it wouldn't be like you would be breaking compatibility if you wrote the DLL loading procedure correctly.)
There would probably be some conversion issues, too, to translate the values from the TiR SDK into FS2 equivalents, but that's more a process of trial and error than design.
I believe the SDK itself is free, so long as you have the device already.
Native support is definitely preferable though, due to the features that TiR offers through 6dof that a mouse simply cannot ever emulate (Not the kinds of mice that I use, anyway).
Now it would be nice if some thought was put into the scripting interface, so you could have some kind of unified device control and be able to pass a joystick, mouse, keyboard, TrackIR or whatever to a function and have it work with it in the same way without recoding, if appropriate. Basically have some kind of base class and make it extendable for extra dimensions, and then have the individual derived classes.
Individual devices could then be accessed through an array, and you could transparently offer the ability to upgrade the API to support multiple devices. (Why the hell you would want multiple TrackIR headpieces is not beyond me, you could probably do something pretty cool by attaching them to your arms or something and implementing a virtual reality thing. But that's the kind of thing that would take a lot of hard work and might land you on Slashdot.) I don't think the TrackIR API supports that sort of thing atm, but you could still do something like have the array and only have the first value return a valid entry eg
cs.TrackIR[1] = realThing
cs.TrackIR[2] = noThing
cs.Joystick[1] = realThing
cs.Joystick[2] = realThing --Pedals
cs.Joystick[3] = noThing
cs.Mouse[1] = realThing
-- etc etc...
Now the fun part of this would be if you wanted to make use of all this with hooks. With the keyboard, making hooks is easy if you ever figure out how to repeatedly use the values returned by the polling functions for the keyboard. You just have to translate them into ASCII, or translate the ASCII into keycodes, and compare the two.
$KeyPress: A
$On Key Press: [
--Do something interesting
]
Now with the TrackIR I'm not sure what you'd do. You have several different gradient movements you can make, but it has no definite buttons to press (a joystick would, and you'd have to do something similar to a keyboard). I'm guessing you'd just end up defining a generic TrackIR field, and ones for various axis
$TrackIR: 1 -- Only executes for first TrackIR device events
$On TrackIR: [
--Poll current device values and figure out what to do
]$TrackIR Axis: Rotate X
$On TrackIR: [
--Poll current device values etc
]
In the first example, all events from the first TrackIR device would be captured. In the second example, all X rotation events would be captured. (For those of you not familiar with TrackIR, it's capable of distinguishing between rotating your head and actually moving it, in all three dimensions.
And just for the hell of it:
$Joystick: 1
$Joystick Button: 4
$On Joystick: [
--Fire ze missiles
]
-
it would be nice to have imput data from the keyboard and joystick(s) in lua, no matter what. something like io.joyAxes[1] or maybe io.joyAxes['Absolute Throttle'] as well (so you can get axis data by axis id or by the name of its bound function in the game). this also helps with my problem with using the physics vars to extrapolate the stick positions for working cockpit controls, which isnt always as predictable as id like.
so far my expierience with the device is that it either magically works, or it doesnt. the configureless nature of the device makes it one of the easyest controllers to set up. you can tweak the control curves so that you can adjust the amplification of the head motion. so you can get as big or as small of a view arc as you like. this thing is pretty cool cause it lets me stick my virtual head out the window of my piper cub in fs2004 :D
a dll to gather the data from the trackir and to pass the results to lua as an orientation matrix and a vector offset would make it real easy to implement a camera script. all i would need to do is multiply the view matrix with the ship orientation matrix to get the proper camera matrix, and then do a rotateVector() to the offset, followed by subtracting it from the eypoint position. i believe thats all i need to create a camera.
-
What you could do, if it wasn't already noted, was simply add mouse support to FS2, and then set TrackIR to imitate a mouse (which I believe is in the TIR config profile) - then you have a working TIR (minus the 6 DoF).
-
the mouse emulation isnt as good as it seems, it doesnt have the absolute coords youd need. so if you turn your head more than the range allows, it throws your view out of whack and you have to hit f12 to recenter. i tried this in fps games and its a rather annoying thing. 2 axis track ir support through mouse emulation is entirely possible now, through scripting, assuming you use a joystick. if you have a mouse and a track ir it would be one or the other.
the mouse/joy look button would be good if you could mouse look without crippling your flight controls. and to be able to do it without holding both an axis and a button. you cant padlock with it and you cant use what an enemy to the side of you is doing to decide how to manuver in real time. view controls should always be independant from the flight controls. if joy axes for the camera are added, then tir could be used with the ir2joy util (sort of).
-
So, what's wrong about asking NaturalPoint if we can have the SDK for TrackIR? They seem eager to include the SDK in as many games as they can, evidenced by one thread I saw on the NaturalPoint forums where one of the developers was interested in contacting the X-Wing Alliance Upgrade guys to see if they can implement TrackIR functionality into XWA. I'd imagine they were disappointed when they discovered that the XWAUP doesn't have the source code at all. So they'd probably also be much more eager if we implemented TrackIR in Freespace 2 since it's, you know, possible. :P
-
the trackir sdk is closed source and cant be added to cvs.
-
How does D2X-XL have TrackIR support when its also open?
-
probibly by not including the trackir sdk. it looks like d2xxl puts the track ir support into a dll, the code for which is not open source. i believe this is what they call dynamic linking. this is how you use an open source library like sdl in a commercial game. you dont compile in the library, you just link to the dll for that library.
-
There may be another option.
GlovePie is also closed source but it can translate the TrackIR inputs into absolute values on joystick axis (from what I've read. I dont have a TrackIR so cant really test.). It uses the ppjoy driver to simulate an 8 axis stick with 16 buttons and hat switch. These joystick axis can be mapped to multiple different input devices. so theres room for 4 axis control from a joystick and 3 axis view rotation from the TrackIR.
To implement full 6dof for the view you would need to have support for multiple Joysticks used at the same time in the game.
EDIT: scratch that. The ppjoy driver supports 16 analog axis and 32 buttons (including pov hat).
-
is that the same thing as tir2joy? i think ive already mentioned that possibility. assuming the angles are absolute it should work fine that way. perhaps you could go talk to deidel about his dll he wrote for d2xxl. sence freespace was built on top of the descent 2 codebase its practically the same game engine so it should in theory fit in just well. it should be legal too so long as you sign a seprate agreement with natural point.
-
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.
-
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.
-
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.
-
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)