Multiplayer plugin and WebRTC on iOS

Folllowing this thread: I've been doing some more tests, to see if the approach to use the cordova plugin "iosrtc" inside Multiplayer plugin is doable.

I've modified the Multiplayer "js" files to include the plugin and all his "stuff" (basically the initialization method to ensure that window.RTCPeerConnection is "implemented"), following the instructions of the "iosrtc" plugin.

Then I've exported my game as Cordova target and created a Cordova project in a Mac with OSX, Cordova and XCode installed, to compile for iOS and test inside the simulator.

But my problem is that the method "C2Multiplayer_IsSupported" is behaving "strange". I've checked why but I'm becoming mad because can't figure it out.

This is a screenshoot of a debugging session using the XCode iPad Simulator inside a Mac with OSX.

As you can see if I call "C2Multiplayer_IsSupported" it returns "false".

But calling the "expression" alone it returns "true"!!!

Can anybody explain me why?

It's probably because the C2Multiplayer_IsSupported function's use of RTCPeerConnection refers to a variable in its closure, not a global variable.

Thanks ASHLEY. Don't know what do you mean exactly because I've not digged into all the source code of Multiplayer plugin. That's something beyond my scope and knowdledge.

Anyway... I'm "throwing the towel". Desist to make the Multiplayer plugin run on iOS.

Now using Photon plugin. It runs ok on iOS in our first testing.

Just a shame that iOS doesn't supports WebRTC natively. In my opinion that's something that could "hurt" the adoption of Construct 2 to some people.

jsj

Since your just testing. May I suggest just overwriting the validity check for is supported. I wouldn't do this in the long run. I would also suggest just console.log() each of the checks in the return line. Just to see which one is failing the whole line.

But for starters just force

C2Multiplayer_IsSupported

{

console.log("RTC Peer: " + RTCPeerConnection );

console.log("ArrayBuffer: " + ArrayBuffer !== "undefined" );

console.log("DataView is defined:" + typeof DataView !== "undefined" );

// return RTCPeerConnection && ArrayBugger !== "undefined" && typeof DataView !== "undefined";

return true;

}

ArrayBuffer does exist

https://developer.mozilla.org/en-US/doc ... rrayBuffer

DataView seems to exist too

https://developer.mozilla.org/en-US/doc ... s/DataView

My Guess is the RTCPeer library isn't accessible when it's wanted.

I got it to work. With all functionality from the c2 multiplayer.

No shimming required, apart from some adaptions.

Just keep in mind the cordova library already contains everything required ... so after exporting you are required to take some bits out of the c2 plugin and change the intitiation to use the cordova lib.

RTCPeerconnection and RTCSessionDescription and RTCIcecandidate are already handled by the iosrtc plugin. So remove those definitions in c2mp.js and c2mp-peer.js.

Also add cordova.plugins.iosrtc. to the initiator:

c2mp-peer.js

this:

this.pc = new RTCPeerConnection({"ICe etc etc etc

to:

this.pc = new cordova.plugins.iosrtc.RTCPeerConnection({"ICe etc etc etc

and voila, all work out of the box, even the IsSUpported

Performance is a bitch though

Ashley: this seems cool. Can you integrate it directly in the export?

Ashley: this seems cool. Can you integrate it directly in the export?

Not sure that is smart to trial yet.

Performance is a bitch though

This was an understatement.

The iosrtc plugin bogs down the cpu, causing low fps to just a couple, and causing timeouts in the c2mp, making it drop connections and the iOS client not even able to process all the incoming data. (which in my test was relatively small and using an ipad3)

I have been tampering with the cordova-plugin-webrtc too, which has lots of similarities to the cordova-plugin-iosrtc, but seems to work a lot smoother ... sadly, only half of the functionality .... seems the DataChannel binary stuff is not implemented.

I am relatively new to Mac os development, but if there is someone here on scirra who's a bit more acquainted with the OSX and the debugging tools accompanied with xcode, then please team up with me for a bit, and we'll nail this puppy.

ATM I am trying to rebuild the library, seeing if some other build parameters might favor the outcome.

This is why we avoid relying on any third-party non-browser implementations of browser features. They're always buggy, incomplete or have other major drawbacks like poor performance. Basically unless the library advertises that it passes a comprehensive standards-compliant test suite, it's probably useless. If anyone finds something that actually works smoothly we could think about supporting it more directly, but if not I think it would be better to wait until Apple add built-in support (which rumour has it they are working on).

This is why we avoid relying on any third-party non-browser implementations of browser features. They're always buggy, incomplete or have other major drawbacks like poor performance. Basically unless the library advertises that it passes a comprehensive standards-compliant test suite, it's probably useless. If anyone finds something that actually works smoothly we could think about supporting it more directly, but if not I think it would be better to wait until Apple add built-in support (which rumour has it they are working on).

I have boiled the performance problems down to an implementation problem:

Host, chrome on windows

Peer, chrome on windows

Peer IOS app

I made a test app to track whats happening as my OSX skills are rather poor.

Now I found that the chrome < = > chrome as expected, flawless

but the ios < = >chrome is doing something I can not explain atm

It seem, that the IOS app is sending out like between 2 ,and 4 packages, with something between 250 and 300 bandwidth OUT

but on the chrome end it is receiving 10 to 15 packages, with over 500k of bandwidth .... IN

And this only happens when the IOS is connected.

Also, in the console I see a lot of dropped packages NOT containing the magic number.

So, somewhere in the implementation I am guessing the wrong Send commands are being used, or even double.

I think that if we can get this sorted, it will work as desired. But my skills in RTC are meager.

Ashley

If you I send you the WEBRTC.js file created on on my system, would you mind laying it next to your c2m-* .js files and see where the snag occurs/happens ?

Something tells me you might be able to sort it a lot quicker then I can.

Because, the slowness only occurs when it sending data.

No, I do not want to get dragged in to debugging somebody else's poor-quality non-standards-compliant WebRTC code.

No, I do not want to get dragged in to debugging somebody else's poor-quality non-standards-compliant WebRTC code.

Dragged in lol, cheese ashley .. you can be an arrogant ass at times.

And how the heck do you come up with poor quality none standard ??? Is that your arrogance getting the better of you ?

Seriously ... iosrtc exposes the functionality from google code, and the library is build upon the google build tools ...

w3c compliant and all ....

but ... you just go ahead and shoot it down before even considering it ... wtf do you even come to the forum.

If it doesn't work out of the box, it's broken, and it's not our job to fix it. Why not report it to the developers of the library? I've really had a terrible time with trying to fix other people's stuff, such as spending exasperated days wasting time over terrible CocoonJS bugs back when we supported that, and it ends up killing all productivity. It's far too costly to spend time on that when we still have a lot of work to do on Construct 3 and simultaneously maintaining Construct 2, especially when Apple are probably already working on a well-tested officially supported version of WebRTC. So please don't ask me to get involved with fixing someone else's library.

I had actually just asked you to take a look at the involved scripts, the plain JS files, yours in combination with the webrtc.js file. Not to spent days on end debugging a library.

Seeing as construct 2 does not support OSX, I was not under the impression you would even have an Imac available in your development team, which would render your debugging capabilities to nill.

I must say I find it a bit weak on your end to mention it could kill ALL productivity for a c3 release .. as if you would be trying to get the community to back your decision ... kinda lame if you ask me.

More so, I would imagine participants of this community not minding if c3 would take a week longer to be released if we would have Multiplayer functionality between Android and Itune apps within a couple days.

But that is just me guessing.

Also, you mentioning they are "probably/likely" building their own well tested version .... well ... if thats you just grabbing ideas from your ass, then fine ... but please mention so, so I don't go chasing something you pulled from your butt ....

finer details ....

[quote:2l3cwtym]Apple’s Job Post for WebRTC

WebKit Media Engineer – WebRTC

Job Number: 43451266

Santa Clara Valley, California, United States

Posted: Oct. 19, 2015

Weekly Hours: 40.00

So you might imagine ... this will take a bit longer then "soon"

Oh, and I could also point out they might go With OpenWebRTC, which is compatible with Microsoft Edge ... but not directly with Googles variant. Oh my ......

Update to the current problem with iosrtc:

Construct 2 scripts do something which allows the Datachannel to be used without the need for a local audio or video feed.

The IOS versions all use the WebRTC to make audio/video chat, and all connections are initiated with the need for video or audio.

I been trying to adapt the code to initialize the RTCDataChannel by itself, without the need for the audio/video feed, but so far been unsuccessful.

PS: a neato side fact, there are more IOS apps running audio/video chat implementations with WebRTC, then there are Android apps using WebRTC for communication.

On a related front, the folks at Ericsson say that the latest release of Bowser should enable all compliant webrtc apps on iOS.

This new version of Bowser was release d in early December in the App Store.

Unfortunately, all C2 programs that use Multiplayer that I've tried, fail to run inside Bowser.

They connect fine with the Signaling Server, but the peers can't communicate with the host.

I've tested the standard C2 demo programs, compiling them with the latest version of C2.

Thus, my tests have been 100% with code from Scirra with no modification.

Still, it fails to run in Bowser.

Has anyone had different results?

The folks at Ericsson suggest this is must be flaw with C2, not with Bowser.

Are we sure that C2 is 100% compliant with WebRTC standard?

I bring this up because it raises the possibilities that the problems others are facing on this thread are because of something non-standard in the C2 exports, not because plugins are flawed. Or, if Ericsson is wrong... and the problem is with Bowser itself, it would be good to know that so we're not incorrectly thinking C2 is the problem.

This feels like a useful issue for Scirra to explore a little, not just with Bowser, but with Cordova as expressed earlier in this thread.