Delta Engine
»
Support
»
Platforms
»
Use of external libraries
Joined: 8/22/2011(UTC)
Posts: 10
Thanks: 2 times
|
Let's say I want to use a third-party .NET library in my game - case in point, the LuaInterface library to use Lua as a scripting language in the game. Would that library then automagically also work on all platforms supported by the DeltaEngine? Or would that cause compatibility problems? In the case of this specific library, the LuaInterface page does say "Note: Since v2, LuaInterface has some dependencies on the VisualC++ runtime library", I'm not sure if that will affect something.
|
|
|
|
|
|
Medals:  Joined: 8/20/2011(UTC)
Posts: 1,421
Location: Hannover
Thanks: 18 times
Was thanked: 97 time(s) in 92 post(s)
|
It is pretty easy: Anything that is pure .NET will work on all platforms, except if there are some features not supported like SQL code or if some platform does not implement some methods. But we do a good job catching those issues and converting them into code that works on each target platform.
Now the problem with LuaInterface is that it is just an interface to the real Lua, which is written in native c. This won't work on any other platform without recompiling lua on each platform and writing custom support for it (certainly possible, but not that easy. I have written wrappers myself for several console platforms).
Since Lua is a pretty cool language and not that complex I thing we will be able to fully support it before v1.0. I have written down a feature request for it.
|
 1 user thanked Benjamin for this useful post.
|
|
|
|
Joined: 8/22/2011(UTC)
Posts: 10
Thanks: 2 times
|
Ah, I understand. It would indeed be quite cool to have Lua support.
For the time being, I have rewritten my scripting to use IronPython, since that is a pure .NET interpreter. It uses Microsoft's Dynamic Language Runtime framework but as far as I know that's also pure .NET so it should work right? IronPython seems significantly slower than Lua though.
|
|
|
|
|
|
Joined: 8/24/2011(UTC)
Posts: 95
Thanks: 6 times
Was thanked: 2 time(s) in 2 post(s)
|
Originally Posted by: HellBlazer  Ah, I understand. It would indeed be quite cool to have Lua support.
For the time being, I have rewritten my scripting to use IronPython, since that is a pure .NET interpreter. It uses Microsoft's Dynamic Language Runtime framework but as far as I know that's also pure .NET so it should work right? IronPython seems significantly slower than Lua though. MonoTouch and Mono for Android doesn't support any dynamic languages, so I guess Your app would not run on those platforms ( http://ios.xamarin.com/Documentation/Limitations and http://android.xamarin.c...ocumentation/Limitations). Benjamin Nitschke wrote:
Since Lua is a pretty cool language and not that complex I thing we will be able to fully support it before v1.0. I have written down a feature request for it.
I wonder how You are going to achieve this - writing own Lua iterpreter? I think it would be (ahem) "easier" to do some CLR->whatever instruction set compiling scheme, so DE would not require even C#. All .NET languages (that compile .net il) would work. You already use LLVM as a backend (monotouch/monoandroid) so a little(or much) hacking would be only required instead of writing and own compiler. My 2 cents. Edited by user Wednesday, September 7, 2011 9:06:50 AM(UTC)
| Reason: links
|
1 user thanked saviilsy for this useful post.
|
|
|
|
Joined: 8/22/2011(UTC)
Posts: 10
Thanks: 2 times
|
Originally Posted by: Santtu Syrjä Oh. Dammit.  While I'm at it (and before I code something stupid again), is the Linq syntax supported by Mono / Xamarin / all DE platforms? Edited by user Wednesday, September 7, 2011 9:40:03 AM(UTC)
| Reason: Not specified
|
|
|
|
|
|
Joined: 8/24/2011(UTC)
Posts: 95
Thanks: 6 times
Was thanked: 2 time(s) in 2 post(s)
|
Originally Posted by: HellBlazer
While I'm at it (and before I code something stupid again), is the Linq syntax supported by Mono / Xamarin / all DE platforms?
Can't say about all of the DE platforms, but Mono for Android/iOS SHOULD support Linq. They list it as "supported assemblies" and do not list it on unsupported ones. Small addition : Read somewhere that Xamarin is eyeing to support scripting and dynamic languages in their mobile platforms, no release date or confirmation though, so Your work might no be in vain  Edited by user Wednesday, September 7, 2011 10:05:33 AM(UTC)
| Reason: Not specified
|
|
|
|
|
|
Medals: Joined: 8/20/2011(UTC)
Posts: 1,421
Location: Hannover
Thanks: 18 times
Was thanked: 97 time(s) in 92 post(s)
|
Originally Posted by: HellBlazer Ah, I understand. It would indeed be quite cool to have Lua support.
For the time being, I have rewritten my scripting to use IronPython, since that is a pure .NET interpreter. It uses Microsoft's Dynamic Language Runtime framework but as far as I know that's also pure .NET so it should work right? IronPython seems significantly slower than Lua though. IronPython is pretty cool, I like it very much also and one of my projects from a few years ago was to implement my own language similar to IronPython on top of the .NET DLR. However, DLR is not supported on many platforms: iOS, WP7, Xbox 360. And it might work on others, but is supported or implemented very well. The main problem here is that Reflection.Emit is needed, but not allowed or supported on those platforms (by Microsoft, Apple and Xamarin). Lua is an easier thing to support. Btw: IronPython should be MUCH faster than most scripting languages because it is compiled into .NET byte code and most features are very optimized. Some things are slower yes, but in most performance tests I did (math heavy) IronPython was way faster than Python or Lua itself.
|
|
|
|
|
|
Medals: Joined: 8/20/2011(UTC)
Posts: 1,421
Location: Hannover
Thanks: 18 times
Was thanked: 97 time(s) in 92 post(s)
|
Originally Posted by: Santtu Syrjä Originally Posted by: HellBlazer Ah, I understand. It would indeed be quite cool to have Lua support.
For the time being, I have rewritten my scripting to use IronPython, since that is a pure .NET interpreter. It uses Microsoft's Dynamic Language Runtime framework but as far as I know that's also pure .NET so it should work right? IronPython seems significantly slower than Lua though. MonoTouch and Mono for Android doesn't support any dynamic languages, so I guess Your app would not run on those platforms ( http://ios.xamarin.com/Documentation/Limitations and http://android.xamarin.c...ocumentation/Limitations). Benjamin Nitschke wrote:
Since Lua is a pretty cool language and not that complex I thing we will be able to fully support it before v1.0. I have written down a feature request for it.
I wonder how You are going to achieve this - writing own Lua iterpreter? I think it would be (ahem) "easier" to do some CLR->whatever instruction set compiling scheme, so DE would not require even C#. All .NET languages (that compile .net il) would work. You already use LLVM as a backend (monotouch/monoandroid) so a little(or much) hacking would be only required instead of writing and own compiler. My 2 cents. I think you imagine this from a way to complicated side in .NET only. There is absolutely no problem linking to native libraries (except on WP7, where this is not supported). So the lua library can just be compiled on iOS, Android, Windows, etc. and then is used from C# with a layer like LuaInterface. Another thing we have investigated was to support .NET scripting, which works quite nice too on most platforms and can even be supported on others with pre-compilation. In any case, we did not have any time yet to work on high level features like scripting. I think we first would need an powerful editor (like Unity) or some kind of in game scripting to make sense of all this. Surely coming, but not now. More likely in a couple of years.
|
|
|
|
|
|
Medals: Joined: 8/20/2011(UTC)
Posts: 1,421
Location: Hannover
Thanks: 18 times
Was thanked: 97 time(s) in 92 post(s)
|
Originally Posted by: Santtu Syrjä Originally Posted by: HellBlazer
While I'm at it (and before I code something stupid again), is the Linq syntax supported by Mono / Xamarin / all DE platforms?
Can't say about all of the DE platforms, but Mono for Android/iOS SHOULD support Linq. They list it as "supported assemblies" and do not list it on unsupported ones. Small addition : Read somewhere that Xamarin is eyeing to support scripting and dynamic languages in their mobile platforms, no release date or confirmation though, so Your work might no be in vain Yes, Linq is working just fine and we use it from time to time in the Delta Engine. Gladly it also works on all Microsoft platforms now (the .NET compact framework was always lagging behind the full framework in features). However linq is not very useful without some data to process and since there is no sql support on most platforms, you won't need it as much. What works fine is a db engine like http://siaqodb.com/ which uses linq and works fine on all DE supported platforms :) About scripting: Yes, I also think better support is coming in the future, but just like the Delta Engine just supporting something is usually not enough, it needs to be supported very well (documented, help, tutorials, tested on each platform, optimized, etc.). If you just want to hack something in for your game, it is usually much easier (up to 10 times less work involved).
|
|
|
|
|
|
Joined: 8/24/2011(UTC)
Posts: 95
Thanks: 6 times
Was thanked: 2 time(s) in 2 post(s)
|
Originally Posted by: Benjamin Nitschke
About scripting: Yes, I also think better support is coming in the future, but just like the Delta Engine just supporting something is usually not enough, it needs to be supported very well (documented, help, tutorials, tested on each platform, optimized, etc.). If you just want to hack something in for your game, it is usually much easier (up to 10 times less work involved).
Aye. I rather sacrifice scripting altogether if I can run my application on every platform DE advertises. Rely on basic things so it can be built on all platforms. C# is not so hard to code so do Your scripting there (or that's how I see it) 
|
|
|
|
|
|
Joined: 8/21/2011(UTC)
Posts: 28
Thanks: 1 times
|
Lua is nice to have, but its more close to C++ and there is no full managed port for it, so won't fully work on platforms
like WindowsPhone and Xbox 360, but i would propose to use C# or VB .NET as its fully supported with Xna 4.0 and you can deploy your game to WindowsPhone7 and Xbox 360.
Hope this helps.
|
|
|
|
|
|
Medals: Joined: 8/20/2011(UTC)
Posts: 1,421
Location: Hannover
Thanks: 18 times
Was thanked: 97 time(s) in 92 post(s)
|
Well there was a project many years a ago (LuaIL, website went down many years ago), which was a pure .NET port, but I think development stopped and while it was kind of usable, it still had the same problems of not working on certain platforms (Xbox 360, iOS, etc.). If anyone is interesting in trying out to use Lua in C# check out these links (or many others you will find all over the internet): http://code.google.com/p/luainterface/ (not much updates since 2009/2010) http://ttuxen.wordpress....embedding-lua-in-dotnet/ (another way to directly embed lua in C#) Edited by user Wednesday, September 7, 2011 9:20:36 PM(UTC)
| Reason: Not specified
|
|
|
|
|
|
Joined: 8/22/2011(UTC)
Posts: 10
Thanks: 2 times
|
Originally Posted by: Benjamin Nitschke However linq is not very useful without some data to process and since there is no sql support on most platforms, you won't need it as much. True, but it's sometimes just an elegant way to work with collections. Originally Posted by: Santtu Syrjä Aye. I rather sacrifice scripting altogether if I can run my application on every platform DE advertises. Rely on basic things so it can be built on all platforms. C# is not so hard to code so do Your scripting there (or that's how I see it) C# is certainly a fine language, and I'm using it for the main game code. The point of adding a scripting language is that it's interpreted rather than compiled, and thus can be used more dynamically. That way, I can write a scene editor for the game, with the possibility of saying, for instance, when the player clicks on this object, execute this bit of script. Every scene/level/whatever can then be just a description of its components and possible actions, while the C# core engine interprets that description and renders to screen and handles inputs. Otherwise every scene needs to be hard-coded and compiled and that just seems tedious and inefficient.
|
|
|
|
|
|
Medals: Joined: 8/20/2011(UTC)
Posts: 1,421
Location: Hannover
Thanks: 18 times
Was thanked: 97 time(s) in 92 post(s)
|
Btw: Adding C# script support in your own tools is no problem under windows. Just make sure to include all scripts when using the Launcher to deploy your game on other platforms that do not support scripting (yet), then it still will work out 
|
|
|
|
|
|
Joined: 8/24/2011(UTC)
Posts: 95
Thanks: 6 times
Was thanked: 2 time(s) in 2 post(s)
|
In my ventures in the web universe I came a cross with this : http://jint.codeplex.com/It is a pure c# javascript interpreter that does not use reflection (so it should work in WP7 and XBOX360 environment too!). It is quite stable as I have read (not tested), fairly often updated and easy to bind Your functions/whatnot into it. I plan to use it as a scripting stuff for my projects tho, there is no other scripting library that I have seen which is capable running in x360, wp7 and xna environment. And because it is "purely" interpret, don't expect performance miracles... It should work great in scripting npc behaviour etc but do the heavy lifting in C# side.
|
|
|
|
|
|
Medals: Joined: 8/20/2011(UTC)
Posts: 1,421
Location: Hannover
Thanks: 18 times
Was thanked: 97 time(s) in 92 post(s)
|
Thanks for the link, looks promising. I will try it out and see if it is any useful or just too slow as you suspect. I have written Lua support for Xbox and PS3 a few years back (native) and worked some time on the LuaIL project (which was quite unfinished and never reached a useful state, LuaInterpreter was what we ended up using in .NET and Lua directly on the C++ side). I don't like the Javascript language much, but if it works out of the box with this interpreter, it is worth a shot supporting it. Not sure if the passing of external methods can be generalized, otherwise it looks very cumbersome to do anything useful with scripts.
|
|
|
|
|
|
Joined: 8/24/2011(UTC)
Posts: 95
Thanks: 6 times
Was thanked: 2 time(s) in 2 post(s)
|
Yea, javascript is kinda lame BUT it is still a functional library. And You could potentially steal some Unity's users(js being the main lang for unity) and introduce new html/js coders to DE. win-win i think.
I think that lib/interpreter meets the needs of scripting. You could automate the script binding but then You'd lose control over the process... I do it manually all the same.
Performance wize, I think it doesn't matter as long as it doesn't take seconds or minutes to run.
Main problem with scripting in C# is the absence of a method to unload assemblies. I have one project aimed at DE that is REALLY content heavy. Everything is content/behavior related "scripting" and it would mean a BIG executable. Since we cannot dynamically load assemblies and the size of the executable matters in mobile platforms, the Jint solves this problem fully. I can load/unload everything as they are nothing but string.
|
|
|
|
|
|
Joined: 8/22/2011(UTC)
Posts: 2
|
Originally Posted by: Santtu Syrjä Main problem with scripting in C# is the absence of a method to unload assemblies. http://msdn.microsoft.co...us/library/dd554932.aspx
|
|
|
|
|
|
Medals: Joined: 8/20/2011(UTC)
Posts: 1,421
Location: Hannover
Thanks: 18 times
Was thanked: 97 time(s) in 92 post(s)
|
Good stuff, we also use a lot of AppDomains and assembly unloading in some tools (like the Launcher, SampleBrowser, for testing, etc.), but this does not work on any other platform (mobile, console, etc.), they all won't allow unloading, so scripting is a good choice there (it is also much easier to use on Windows) ^^
|
|
|
|
|
|
Joined: 8/24/2011(UTC)
Posts: 95
Thanks: 6 times
Was thanked: 2 time(s) in 2 post(s)
|
Originally Posted by: Benjamin Nitschke (DeltaEngine) Good stuff, we also use a lot of AppDomains and assembly unloading in some tools (like the Launcher, SampleBrowser, for testing, etc.), but this does not work on any other platform (mobile, console, etc.), they all won't allow unloading, so scripting is a good choice there (it is also much easier to use on Windows) ^^ Exactly. "Assembly loading - Reflection emit is the only mechanism that is supported for loading collectible assemblies. Assemblies that are loaded by any other form of assembly loading cannot be unloaded." -> Not available in mobile/console. Also I bet the AOT arm compilation limits what things can be done to loaded assemblies as their function changes a lot when moving to mobile space. For example the whole executable is loaded to memory prior to run since no dynamic linkage is permitted in some mobile platforms(ios, xbox...).
|
|
|
|
|
|
Joined: 8/24/2011(UTC)
Posts: 95
Thanks: 6 times
Was thanked: 2 time(s) in 2 post(s)
|
Ok, just did a bit further research and Jint is unusable with mobiles. They added Reflection.Emit after 0.8.9 version thus making Jint no more usable with CF.NET (wonder why they added it since there are many more performant JS interpreters in the .NET world, the must-have selling point of Jint was the support for medium sec clr).
Well anywho, I need a scripting language at some point in the future and the search continues. I think I might roll my own eventually which is simple parser/interpreter... Seems there is a demand for scripting language for XNA/medium sec. Don't expect it to be speed miracle but extendable.
|
|
|
|
|
|
Medals: Joined: 8/20/2011(UTC)
Posts: 1,421
Location: Hannover
Thanks: 18 times
Was thanked: 97 time(s) in 92 post(s)
|
If you have not seen it, other people tried porting Jint to MonoTouch & Co. already and with v0.8.9 it worked after some work: http://jint.codeplex.com/discussions/247783I still have it in the list of libraries we want to support some day, but that list is only growing bigger and bigger ^^
|
|
|
|
|
|
Joined: 8/24/2011(UTC)
Posts: 95
Thanks: 6 times
Was thanked: 2 time(s) in 2 post(s)
|
Yea I saw it, thought it seems it would be a hack that is not maintained by the original devs. This http://code.google.com/p/shyscript/ gave me an idea of really REALLY simple parser. Though the interpreter is made in a way that made small amount of vomit enter my mouth but nonetheless, it is great proof of concept for a small scripting language. I prefer doing it on my own if it comes to that, after that make a project that other can contribute (just like TEF). I'll do (at some point) a proof of concept of scripting language with NO language constructs/types just to prove a point of creating an "empty" language where people can easily add own types/functions and what not. And I'll be in contact Benjamin if You want some sort of automatic generation for bindings.
|
|
|
|
|
|
Medals: Joined: 8/20/2011(UTC)
Posts: 1,421
Location: Hannover
Thanks: 18 times
Was thanked: 97 time(s) in 92 post(s)
|
Sounds great. The Shyscript project looks interesting as well, but you are right, I don't think many people will want to write scripts in this language and it probably is not fast or anything.
Again, I personally think the best option is to discard scripting altogether as it is mostly not allowed by Apple or Microsoft and it is slow on all mobile platforms. Instead use scripting when necessary in Windows and compile it down to normal game code when building for a mobile platform. This gives you all the scripting benefits at development time while still having great performance at runtime on the mobile platforms. Easiest option here is C# scripts (which are a little cumbersome, but after a while stuff really gets useful and you stay in one world).
|
|
|
|
|
|
|
Bingbot,
OceanSpiders 2.0
|
Delta Engine
»
Support
»
Platforms
»
Use of external libraries
Forum Jump
You cannot post new topics in this forum.
You cannot reply to topics in this forum.
You cannot delete your posts in this forum.
You cannot edit your posts in this forum.
You cannot create polls in this forum.
You cannot vote in polls in this forum.
Login