Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: Nuke on October 01, 2006, 02:31:32 am
-
i was tweaking my multi optens and i noticed the voie options. i wondered if they still worked so i tried to enable them. it gave me a message that direct capture wasnt working. i asume this means its a neglected feature because if my xfi doesnt support capture, i want my money back :D. anyway is it possible to update the voice communication code to a working status?
-
We've been talking about this a little in the internal forum actually. I've found a bug or two in the original :v: code and wasn't sure if it ever actually worked properly in the first place (there seem to be mixed results).
At this point, just consider it a dead feature. There just aren't the coder resources available to work on this any time soon. Your best bet is to just use something like TeamSpeak for voice until something better is available.
It's on my todo list to gut the code and rewrite it using a newer voice codec which should use less bandwidth and provide much higher quality. But that's for a 3.7 thing since it would go with the newer networking code and new sound code (which will have full EAX, 5.1 3D sound, and capture support via OpenAL ... so hold on to that xfi ;)).
-
new sound code (which will have full EAX, 5.1 3D sound
:eek2:
I want that... now! :)
-
i remember it worked before, not very well but it worked. seems that voice communication is the norm in multigames theese days. wou;d be cool if it worked though.
-
new sound code (which will have full EAX, 5.1 3D sound
:eek2:
I want that... now! :)
Sure... After I get done with the bumpmapping code, shader support, new pilot file code, CVPs, and the new cross-platform launcher. Ie. about 8 months from now. ;)
-
i bet you've heard it a thousand times, but i really should get back into programming and lend a hand :blah:
-
'nother idea, what about built in webcam support. why only use voice communication when you can have video too. use the message box that command usually comes up in and put the webcam video up there. then you can see whos playing in the nude durning multiplayer :D
ok this is too nuts to implement, forget i said anything :D
-
'nother idea, what about built in webcam support. why only use voice communication when you can have video too. use the message box that command usually comes up in and put the webcam video up there. then you can see whos playing in the nude durning multiplayer :D
ok this is too nuts to implement, forget i said anything :D
damn you, i wanted to suggest that. wouldn't that be nice, freespace-styled comms ;)
-
I do like the webcam idea. Don't know that it will ever happen though. Coding support for that aside, it just seems like it would be tough to actually get working properly. I mean, do you always show video for everyone? Only when they talk/breathe/cough/sneeze/wheeze/etc? Does it switch to a different stream if one person interrupts another thereby cutting off the first persons video?
That's just something a good bit trickier than actually coding in webcam support. :)
-
Add in video and you increase the bandwidth requirements exponetially, though.
-
Add in video and you increase the bandwidth requirements exponetially, though.
More, yes. Exponetially, not necessarily.
We have an exact size that the video could be (160x120, since it's a hud animation).
We can do it in a specific 8-bit palette rather than RGB color.
We can limit FPS of it to something like 10FPS for fast (T1/LAN) connections, and less for slower connections.
We can encode it with the voice data and then only transmit video with voice rather than having a full-time stream.
We can restrict video to only those clients who have connection speeds fast enough.
We can further reduce size by using scanlines which would double vertical and/or horizontal resolution.
We can compress the video data (future CVP support means that we get compression tech built in).
And all of this can be done from the client side sending the video in the first place. RGB to 8-bit conversion, plus the specific size, plus vertical scanlines, would mean that a video frame (without compression of any sort) would be 160x60 bytes in size (9.4K). Using compression we could probably cut that by another 80-90%, down to the 1.5K range. At 10 FPS that comes out to be 15K additionally for every second of voice data, 5 FPS would give 7.5K additionally, 3 FPS would give 4.5K, etc. If we ditch the current voice compression tech and go with Speex (the eventual plan) then voice data size drops and could possibly make up the difference.
Not great, but not all that bad either. :)
-
I'm just used to video hammering my bandwidth, I guess...
-
well you could convert the video to 4-bit greyscale at its source and then have the comm menu hud color applied to it. that would be pretty cool. i calculated that (160*60*4)/8 = 4800 bytes per frame times 30 frames (for a 3 second message) means roughly 114k + ~24k for audio (based on a 3 second mp3 at 64kbps) per message. so roughly i figure that 138k would be the size of each message. using image compression might save on some of that. but it really isnt that much if each player is limited to x number of seconds and to y number of messages for every z period of time. making it close enough to real time to be usefull would be the hard part. in flight tactical communication could be trickey.
-
The Webcam would be good if for no other reason than you can scream 'Avenge meeeeee!' down it when you blow up ;)