Irrlicht Lime is a .NET wrapper for Irrlicht Engine

Announce new projects or updates of Irrlicht Engine related tools, games, and applications.
Also check the Wiki
Foaly
Posts: 142
Joined: Tue Apr 15, 2014 8:45 am
Location: Germany

Re: Irrlicht Lime is a .NET wrapper for Irrlicht Engine

Post by Foaly »

AltSoftLab wrote: I think you can create some code tests for those types. For example, check the size of type, check field offset, etc. It's not many types and I think they don't change often. If you use only 1 vertex, it's not a problem. But when you use vertex array - it's a problem! I need to create Color object each time when I need to set a color. But Color in Irrlicht is just a UInt32 value. Also YOU ALWAYS COPY S3DVertex in Draw2DVertexPrimitiveList. Every render operation. It's not good at all! In other words, I think structures must stay structures.
As I said I'm already working on replacing some classes by structs. The problem is, it's a lot of work (I have to replace every!!! access) and I will always have to update these structs in the future.
I will continue working on the usual IrrlichtLime until this 'branch' is finished.
AltSoftLab wrote:Also some times Dimension2Di generate Exceeptions. Yes... Some times it try to delete already deleted native object. Simple structure, but many trubbles. I think it owned by any other Irrlicht object and deleted by it. So when you try to delete it then you are wrong... It's another reason to use structures.
Could you please add an example where this happens? It should work well, because the native object is duplicated for each instance and the Garbage Collector isn't supposed to finalize objects more than once as far as I know.

Foaly.
AltSoftLab
Posts: 15
Joined: Thu May 01, 2014 5:53 pm
Contact:

Re: Irrlicht Lime is a .NET wrapper for Irrlicht Engine

Post by AltSoftLab »

Foaly wrote:
AltSoftLab wrote:
AltSoftLab wrote:Also some times Dimension2Di generate Exceeptions. Yes... Some times it try to delete already deleted native object. Simple structure, but many trubbles. I think it owned by any other Irrlicht object and deleted by it. So when you try to delete it then you are wrong... It's another reason to use structures.
Could you please add an example where this happens? It should work well, because the native object is duplicated for each instance and the Garbage Collector isn't supposed to finalize objects more than once as far as I know.
Foaly.
Hi! Sorry, but I didn't have time to debug this (you can do it by yourself). It's happens some times and exception info goes to Console in AltSketch Irrlicht Demo. Yes, I looked into your template, and it seems to work right in theory. But exceptions occures on practice...
It's good to detect this issue. But you can also set object to null after deleting and check it before.
AltSoftLab Team
Be Individuality - Choose Alternative ©
http://www.AltSoftLab.com/
Domenus
Posts: 1
Joined: Sun Jul 13, 2014 2:50 pm

Re: Irrlicht Lime is a .NET wrapper for Irrlicht Engine

Post by Domenus »

Hello everyone ! I would like to thank you for this excellent wrapper.

I have two questions for you:
1. is Irrlicht engine still in developement ? will the 1.9 version come out eventually ?
2. i see, that Lime is now in 1.4 version, which was released a year ago. i would like to ask, what version of Irrlicht engine is current Lime wrapping ? will you develop new Lime version ? and which changes was made in Irrlicht engine since Lime 1.4 came out ?

thank you for answers, and have a nice day :-)
CuteAlien
Admin
Posts: 9620
Joined: Mon Mar 06, 2006 2:25 pm
Location: Tübingen, Germany
Contact:

Re: Irrlicht Lime is a .NET wrapper for Irrlicht Engine

Post by CuteAlien »

1. Yes, Irrlicht is still in development and we're planning a 1.9 release (and also have plans for a 2.0 release). But time we have for development varies wildly.
Can't answer 2.
IRC: #irrlicht on irc.libera.chat
Code snippet repository: https://github.com/mzeilfelder/irr-playground-micha
Free racer made with Irrlicht: http://www.irrgheist.com/hcraftsource.htm
greenya
Posts: 1012
Joined: Sun Jan 21, 2007 1:46 pm
Location: Ukraine
Contact:

Re: Irrlicht Lime is a .NET wrapper for Irrlicht Engine

Post by greenya »

Hi Domenus,
all the changes between releases of Irrlicht Lime you can find in changes.txt file.
Wrapper doesn't support all the Irrlicht functionality, but it has a lot necessary things, you can get what is possible to make from the examples. The very latest version of the wrapper is in the SVN trunk. You have to build it to use it, sorry for inconvenience.
Foaly
Posts: 142
Joined: Tue Apr 15, 2014 8:45 am
Location: Germany

Re: Irrlicht Lime is a .NET wrapper for Irrlicht Engine

Post by Foaly »

The current Irrlicht Version wrapped by Lime is svn rev 4886.
If you need special feature in IrrlichLime or have an idea you can ask here.
bdpdonp
Posts: 68
Joined: Sat Oct 10, 2009 6:35 am

Re: Irrlicht Lime is a .NET wrapper for Irrlicht Engine

Post by bdpdonp »

I am working on an intense project utilizing Lime. The requirements have changed (what else is new). I am trying to verify that Lime will still work on OSx and/or Linus with mono installed. I know irrlicht itself will work but as lime is a wrapper, not sure if it will. Right now no Linux or apple box or I could test it myself.
greenya
Posts: 1012
Joined: Sun Jan 21, 2007 1:46 pm
Location: Ukraine
Contact:

Re: Irrlicht Lime is a .NET wrapper for Irrlicht Engine

Post by greenya »

I never saw an example using Lime working in Linux (or Mac).
I'm afraid it is not possible. Using Mono you can write C# code and run on Linux, but Lime is a wrapper which uses native Windows DLL (Irrlicht.dll) and provides user with easy to plug-and-use IrrlichtLime.dll. It cannot work without native Irrlicht dll. Probably it is possible to compile it somehow, but I cannot comfirm that.
vytek
Posts: 1
Joined: Sat Sep 06, 2014 10:52 am

Re: Irrlicht Lime is a .NET wrapper for Irrlicht Engine

Post by vytek »

Hi,
first of all thank you for you very good wrapper!

I checkout the entire source from SVN. I have Visual Studio Professional 2012 on Windows 8.1. I start the project SLN and all goes OK. Visual Studio import the project to new versione for Visual Studio 2012 (12.0). I compile all the solution and I see in /bin directory there are all files.

But when I run for example first program there is an error:

'01.HelloWorld.exe' (Gestito (v4.0.30319)): caricato 'C:\WINDOWS\Microsoft.Net\assembly\GAC_64\mscorlib\v4.0_4.0.0.0__b77a5c561934e089\mscorlib.dll'
'01.HelloWorld.exe' (Gestito (v4.0.30319)): caricato 'C:\Users\Enrico\Desktop\Irrlicht\code\bin\Debug-x64\01.HelloWorld.exe', simboli caricati.
Eccezione non gestita di tipo 'System.IO.FileNotFoundException' in Modulo sconosciuto.
Informazioni aggiuntive: Impossibile caricare il file o l'assembly 'IrrlichtLime.dll' o una delle relative dipendenze. Impossibile trovare il modulo specificato.
'01.HelloWorld.exe' (Gestito (v4.0.30319)): caricato 'C:\WINDOWS\Microsoft.Net\assembly\GAC_MSIL\mscorlib.resources\v4.0_4.0.0.0_it_b77a5c561934e089\mscorlib.resources.dll'
Il programma '[5964] 01.HelloWorld.exe: Gestito (v4.0.30319)' è terminato con il codice 0 (0x0).

System.IO.FileNotFoundException assembly 'IrrlichtLime.dll' (unknown module) ???

It is impossible. The file IrrlichtLime.dll is in ten directory and also irrlicht.dll versione 1.9.0.0.

Path is correct and reference to irrlichLime.dll is correct.

I don't understand? What is the problem? Can you help me?

Could you create a zip file with binary IrrlichLime.dll as versione 1.4? (I try it and it works fine!)

Thanks in advance.
Regards
Foaly
Posts: 142
Joined: Tue Apr 15, 2014 8:45 am
Location: Germany

Re: Irrlicht Lime is a .NET wrapper for Irrlicht Engine

Post by Foaly »

So your problem is that you want the head revision of Lime, which doesn't compile correctly, but the release 1.4 works?

Well, if you really can't wait for the next Lime release, I could upload it for you somewhere.
But the trunk version may not be as stable as a release and it is sometimes in an inconsistent state (I will soon implement IEquatable for all value types, etc).

And I don't know why your compile doesn't work...
Did you already look into the import log?
And did you recompile the example before starting it?
Foaly
Posts: 142
Joined: Tue Apr 15, 2014 8:45 am
Location: Germany

Re: Irrlicht Lime is a .NET wrapper for Irrlicht Engine

Post by Foaly »

Hello!
I'm writing here, because I want to know what others think about some changes I'm planning to make at IrrlichtLime. I'm still not sure how to call all the classes, and maybe someone has ideas to improve this concept even more.

I want to make Lime easier to use and more .Net-ish.
Currently there are some parts which feel pretty complicated in connection with collections:
- in MeshBuffer the return type of the Vertices property is Object and it returns an array depending on the vertex type, which is a copy
and there are UpdateVertices and UpdateIndices methods which were introduced, because there is no write access with the Vertices property
- in SceneNode the Children property returns an array, which can give bad performance, if e.g. a user just wants to know how many child nodes a node has
- etc.

So I want to add 3 new classes, which make things like that more consistent and easier to use:

NativeArray<T>
  • An array like class which keeps connected to the underlying array.
  • Access by index.
  • Has a ReadOnly property which tells whether writing to it is possible.
  • Count property.
  • Has a ToArray()/ToList() method, which converts it to T[]/List<T>
  • Replaces for example "native" arrays with pointers (T*) and other fixed size collections.
NativeList<T>
  • A list like class, which provides access to an underlying list with dynamic size (like irr::core::array<T>)
  • Access by index.
  • Has a ReadOnly property.
  • Count property.
  • ToArray()/ToList() method.
NativeEnumerable<T> (/ NativeIterable?)
  • Provides access to an undelying type, which has an Iterator, but no access by index. (like irr::core::list<T>)
  • Has a GetIterator() method. Can be iterated in both directions.
  • Always read-only.
  • Count property.
  • Can be used in foreach loops.

I hope I did not make any bad mistakes in planning this and I would be happy to know what others think about this.
greenya
Posts: 1012
Joined: Sun Jan 21, 2007 1:46 pm
Location: Ukraine
Contact:

Re: Irrlicht Lime is a .NET wrapper for Irrlicht Engine

Post by greenya »

Just want to clarify some decisions. :)
- in MeshBuffer the return type of the Vertices property is Object and it returns an array depending on the vertex type, which is a copy
That is because vertex itself can be different type. And there is no templates in managed C++ (at least at point that i was writing it), so i decided to return Object and clarify this is the doc (intellisense). So basically user need to do annoying type-casting. The-not-bad solution would be defining new class like "VerticesArray", which will be a bridge from .NET to native C++ and which will be handle internally any type of vertices.
and there are UpdateVertices and UpdateIndices methods which were introduced, because there is no write access with the Vertices property
That's right. Some distinct class (like i described above) would cover this too easily.
- in SceneNode the Children property returns an array, which can give bad performance, if e.g. a user just wants to know how many child nodes a node has
This is something that i added for being quite .net-ish :) One of the "magics" of managed world is an incredible ability to debug things. When you set a break point and get all the info on the variable you can think of. The debugging becomes an easy process. Ofcause, having this method will make noob people to use it just to iterate nodes. But you still can get node by its index, get total amount of child nodes (just like native Irrlicht has it). This flaw (a "Children" prop) can be covered by making distinc class, which will implement IEnumerable and other necessary interfaces. It will ask needed node just when its actually needed.

P.S.: I'm okay with everything you wrote. Just keep in mind following:
- do not overthink on stuff, don't make it to be huge; if something is small and simple, it should remain that; if you cannot find the way to do it - better don't do it at all, because once done, we need to support that;
- do not make changes in native Irrlicht source even if you need a very small modifaction; because we will need to support that change throughout any Irrlciht changes; you can bump a thread on the forum asking devs to make the change; also such approach will let us update Lime in easy way - Lime is dependent only on Irrlicht' header files (and never source files);
- before adding anything new, keep in mind, that thing must be easy to use in C#, the user must not be able to make mistakes (ideally), so the class itself well-written, when you don't need to read any docs, because it just works as most of us would expect;
- please test changes running examples and compilling in different modes (x86, x64, Debug/Release);
- please keep documentation (intellisence) up-to-date; if soemthing wasn't documented (like all GUI namespace) than OK, but if you change some behaivior of the class/method in Video or Core namespace, please do not forget update the doc; remmember, as a .NET-ish programmer you might (just like i) like intellisence and its fill great when all necessary info on the thing-you-just-typing pops up right before your eyes; that is something which is very important not only for novices :)
Foaly
Posts: 142
Joined: Tue Apr 15, 2014 8:45 am
Location: Germany

Re: Irrlicht Lime is a .NET wrapper for Irrlicht Engine

Post by Foaly »

That is because vertex itself can be different type. And there is no templates in managed C++ (at least at point that i was writing it), so i decided to return Object and clarify this is the doc (intellisense). So basically user need to do annoying type-casting. The-not-bad solution would be defining new class like "VerticesArray", which will be a bridge from .NET to native C++ and which will be handle internally any type of vertices.
Well, I wanted everything to be consistent, so the user only sees these three generic classes. They are inherited by the actual implementations internally. (for example "internal ref class VertexArray : NativeArray<Vertex3D>")
But one problem is, that I cannot use the Vertices property anymore, because properties can't be generic. So it's now GetVertices<T>();
do not overthink on stuff, don't make it to be huge; if something is small and simple, it should remain that; if you cannot find the way to do it - better don't do it at all, because once done, we need to support that
Well, I think I've found an pretty good way to "wrap" irr::core::list<T> objects. I've written an template, so I don't have to write an implementation for every class. Now the Children property of SceneNode is only one line:
"return gcnew CollectionIrrListTemplate<SceneNode^, SceneNode, scene::ISceneNode>(m_SceneNode->getChildren());"
do not make changes in native Irrlicht source even if you need a very small modifaction; because we will need to support that change throughout any Irrlciht changes; you can bump a thread on the forum asking devs to make the change; also such approach will let us update Lime in easy way - Lime is dependent only on Irrlicht' header files (and never source files)
I won't.
bruce965
Posts: 3
Joined: Fri Mar 06, 2015 6:24 pm

Re: Irrlicht Lime is a .NET wrapper for Irrlicht Engine

Post by bruce965 »

FYI (as I don't think this has been posted before), this is the output from mono:

Code: Select all

user@linux-mint ~/IrrlichtLime-1.4/bin/Release $ mono 01.HelloWorld.exe 
Method '<Module>:_getFiberPtrId ()' in assembly '/home/user/IrrlichtLime-1.4/bin/Release/IrrlichtLime.dll' contains native code that cannot be executed by Mono on this platform. The assembly was probably created using C++/CLI.
So it won't work on mono, unfortunately. :-(

Anyway thanks for making this good wrapper!
bdpdonp
Posts: 68
Joined: Sat Oct 10, 2009 6:35 am

Re: Irrlicht Lime is a .NET wrapper for Irrlicht Engine

Post by bdpdonp »

I am trying to use lime on updated VS IDE's. VS2013 works fine, but not 2015 CTp.. Under 2015 if it is set to use the 2015 lib and tools it says internal compiler error. But if i set it to use the 2013 tools from 2015 it works.

I desire to check our the new features of net but guess I will stay with 2013 as who knows what else is wrong.
Post Reply