Photon with Unity iPhone

thetnswe

Does the unity wrapper of the Photon runs on the Unity iPhone and Android? Or Do I have to use the Native SDKs to do that?

Tobias

Edit your project settings to: ".Net 2.0 subset" and use: "Strip Bytecode".
Then the Unity lib will export and work fine on iOS devices.

We couldn't test Android yet but Unity does a good job in their exports. I expect it to work.
Let us know if you could give it a try.

dreamora

Does the library by now use a plugin?
Cause .NET sockets are iOS Pro / Android Pro only, the non pro has no sockets.

thetnswe

So.. If it uses a plugins, I need Pro license to make it work.. Is that right?

dreamora

No if it uses plugins then it works with both iOS versions as plugins are not pro limited on mobile.

But if it uses sockets, then you need Unity Pro + iOS Pro to use it

Tobias

We're not using a plugin for the sockets on either system yet.
Dreamora, do you know a good resource to learn more about Unity plugins? I can't promise anything but it might be possible to build this.

dreamora

Unity uses the standard .NET DLLImport way for "plugins" / Addons, on any platform

For android though, given you want to change it there as well, I would first check if you can use the Java Binding classes the UnityEngine namespace offers since 3.2 / 3.3 instead of going with a plugin because plugin on Android at worst means Unity / .NET -> DLLImport -> C -> JNI -> Java -> whole thing back (unsure to what degree socket etc is present on the NDK level thus the whole rat tail till up to SDK / Android OS)

Tobias

Ah, I got that wrong, I guess. So plugin = assembly dll?

dreamora

No plugin really means non .NET code (C decl on iOS and C -> JNI -> JAVA on android)

But the way you bind in this native code on Unity is the DLLImport - Marshaling path that you use to interface with unmanaged code in any .NET application. (so the stuff you find in the InteropServices namespace)

Kaiserludi

As we initially decided to bring Photon to Unity, we also considered the option of offering our native clients for Unity, but we still only offer them as static libraries, not as .dlls. It would mean additional afford, to have native .dlls for Unity and of course it would be a littel more complicated to use for you to call code through the langauge barries instead of directly using .NET code from within the scripts. Of course natively accessing the sockets coul be a littel bit more performant, but the Mono-code should be quite optimized, I guess and we would have to wrap the code anyway, convert all data we pass through to a format, the native libs would understand, wrap the code, so probably there would not be gained much performance, if any, and in the end, Photon is a network solution, there is nothing gained by savin a few ms, if we could this way, when you have latencies of hundres of ms. In addition back then in Unity 2.x times nativeplugin were Pro-version only, anway (as far as I know, they still are on non-mobile platforms, aren't they?). Last but not least we are a company and have to finance projects somehow and probably most customers of a non-free Photn-license for Unity will use the Pro-Version of Untiy anyway. Well, of course this keeps out people, starting small, not being able to buy the Pro-version, only using Photon free licenses, too, but grow big later and even the ones, that never will go beyound a free license are still able to recommend us. So, possibilities like offering native-Photon dlls (or as an alternative a version of the .NET dll, which is accessing a sockets-only native dll internally) will always be considered. Since our first Untiy-clients the Untiy-community has become very important for us, so perhaps we will offer native support for Unity iPhone Basic one day, it definitely will not be next week or so, but the main-reason for not offering such an option until now is, that there ws no demand. No one ever asked for it, so if there is demand, it maybe could come.

dreamora

I think there are a few things to clarify:

1. Outside the mobile space System.Net isn't a pro only thing, so desktop and web are unaffected.
2. On iOS, there are no DLLs being used actually (does iOS support .so at all? Never used them so not sure)
It binds against binding code thats there in some source form. As such it would be possible for interested users to write an own small layer to bind against the already offered native iOS support if they really are interested (perhaps a slightly larger layer if it uses callbacks, to intercept them in a safe environment and work with a message queue between it and unity).


Fully understand your position and with the options you offer anyone really interested can easily overcome the limitation (never understood why UT added the socket or movie limitation anyway, movies take like 60 minutes to integrate an own solution on plugins, makes the artificial fuckup laughable)

Kaiserludi

1. Yes, we are aware of this. If it wasn't, we maybe have not offered Photon for Unity Non-Pro at all.
2. Yes, now that you are taking about it, I remember, no .dll support on iPhone. Thats the reason, why you have to use static frameworks there, although dynyamic frameworks are the more typically approach on osx.
Of course everyone could write a small wrapper .dll about our native static libs. I was thinking about mentioning this option, but it would end up in maintenance work for you, as you always have to look at our native API on every release of a new client-lib version and make sure, you update your wrapper accordingly to any possible API-changes.

dreamora

Kaiserludi wrote:

1. Yes, we are aware of this. If it wasn't, we maybe have not offered Photon for Unity Non-Pro at all.

Wasn't aware of that, thanks in that case

Kaiserludi wrote:

2. Yes, now that you are taking about it, I remember, no .dll support on iPhone. Thats the reason, why you have to use static frameworks there, although dynyamic frameworks are the more typically approach on osx.
Of course everyone could write a small wrapper .dll about our native static libs. I was thinking about mentioning this option, but it would end up in maintenance work for you, as you always have to look at our native API on every release of a new client-lib version and make sure, you update your wrapper accordingly to any possible API-changes.

Actually its much easier.
never looked at the native (intended to do so to hook it into iTGB but I never got there) but if it offers some headers you can at best reduce it to nothing but defining the static extern functions (if it uses callbacks it becomes more tricky but you can bind even that against code on the .NET side, it just has to reside in a System.Object descendant, nothing that extens from unityengine.object due to the lack of thread-callback safeness from other threads). In that case the maintanenance work for someone going that path is quite minimal.
If the stuff is ObjC at the time (don't think so, from what I recall its C++ or even C) you would write a small extern C binding layer but then you are again on the level above.
Just to ensure we all talk about the same thing here: Unity can interact with static libraries on iOS due to how DLLImport("__Internal") works which binds the defined external function against an internal one which is then resolved at compile time to AOT (as JIT does not exist for iOS so it ends as native ARM iOS code which is in a much better position than normal DLLImport on all other JIT capable platforms), all thats required is that the linker can find it
So no "dll creation" involved or alike if anyone wants to go that path.

Kaiserludi

1. Well, there woul have been not much use for Photon on a platform not supporting sockets of any kind, wouldn't it?
2. Actually you have the choice between all three C, C++ and objC, which are all provided in our native lcient sdks (well, objC only for iOs and osx, only the two others on rest of the native platforms). Yes, we also use callbacks in the native API, in that way its very much like the one, you are used to in .NET. We tend to keep the clients as similar as possible betwwen different languages, so their users have not to start at point zero again on learning the API, if the come from a different client. The native client core is written in C and the C++ and objC API are provided as wrapper-APIs on top of the C-Core, not doing much more than proving a nicer API. If we would write a C# binding, we would probably bind to C or C++ for better portability of that solution to potential other platforms, as objC isn't used very much on platforms not provided form Apple. I suppose, C++ would be the better alternative of the both, although adding a bit more overhead due to the additional wrapper layer, but it would make things mroe easier in terms of memory managment due to C's lack of destructors (I have not much experience in language bindings and no idea, if it would be possible at all to allocate memory in one language and deallocate it in another one.