Current .NET compatibility

[CrimsonShadow]

Duncan Mac Leod, do you think it possible to get the two newly compiled *.dll files and an example of how to implament it from you. This would really help out the development of our world editor application, thanks in advance

Okay - we are coding a Toolset on Irrlicht for our upcoming RPG, too...

http://www.excelsior-online.org/downloa ... ne_builds/

or use our Mirror-Server:

http://secondary-download.excelsior-onl ... ne_builds/

Our additions to IrrlichtDevice are:

IrrlichtDevice - Overloaded. Initializes a new instance of the IrrlichtDevice class.

public IrrlichtDevice(DriverType); // exists in irrlicht-0.10.0 .NET

public IrrlichtDevice(DriverType,int); // NEW in our Custom Build

public IrrlichtDevice(DriverType,Dimension2D,int,bool,bool,bool); // exists in irrlicht-0.10.0 .NET

...therefore you can call in C#:

//create a winform
//create a panel on the Form

IrrlichtDevice device = new IrrlichtDevice(DriverType.OPENGL, (int)this.panel1.Handle);
device.ResizeAble = true;

...we have only tested the Custom Build with one small sample app., yet! ...and only on OpenGL - USE AT YOUR OWN RISK!
...IMPORTANT: we have removed ALL Window-Captions/Borders/etc. on any Window created by the Engine, so you also won't have Borders/etc. if you are not calling our new overloaded Method using the original ones - THIS IS WANTED BY DESIGN and not a bug!

Have Fun,
Duncan
--
Tucan Entertainment

WARNING: this Custom Build of Irrlicht is NOT supported! THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED...

Wow. Thanks for making that available. It'll definitely make content editors easier to make and I guess you could put all the menus, etc. on the outside of the widget now so not having the 2D GUI elements isn't that big a deal.

It's nice to see people working on the .NET stuff. (And of course it's nice of niko to write the engine in the first place and make it available. )

-CrimsonShadow

[AlexL]

Thank you for your willingness to make this avalible Duncan Mac Leod, but sadly I can't get either of the URL's you gave me to work If you have the time, could you email it to me at AlexLoren@gmail.com and with your permision I could setup a mirror for it.

[enni]

... but sadly I can't get either of the URL's you gave me to work

try this
http://frostbite.isn-portal.de/excelsio ... build_0.1/
or this
http://213.202.239.10/excelsior-online_ ... build_0.1/
they're the same

[niko]

I did some modifications on your Engine Code and some on your .NET Wrapper 'Irrlicht.NET' Code and had to rebuild both (Engine and Wrapper) from Source...

Ah, nice that it worked.
Why did you have to change the c++ version too, did I put a bug in there or was something missing?

[Duncan Mac Leod]

I did some modifications on your Engine Code and some on your .NET Wrapper 'Irrlicht.NET' Code and had to rebuild both (Engine and Wrapper) from Source...

Ah, nice that it worked.
Why did you have to change the c++ version too, did I put a bug in there or was something missing?

No - not a bug - I 've only removed all Captions/Borders/etc. to have plain engine windows without a sys-menu, max.-box, etc.

This is wanted by Design - not a bug of your Engine!

modified CIrrDeviceWin32.cpp

Code: Select all

                DWORD style = WS_POPUP;

                if (!fullscreen)
                        //style = WS_SYSMENU | WS_BORDER | WS_CAPTION | WS_CLIPCHILDREN | WS_CLIPSIBLINGS;
                        style = WS_CLIPCHILDREN | WS_CLIPSIBLINGS;

                AdjustWindowRect(&clientSize, style, FALSE);

Code: Select all

        if (!getVideoDriver() || FullScreen)
                return;

        LONG style = WS_POPUP;

        if (!resize)
                //style = WS_SYSMENU | WS_BORDER | WS_CAPTION | WS_CLIPCHILDREN | WS_CLIPSIBLINGS;
                style = WS_CLIPCHILDREN | WS_CLIPSIBLINGS;
        else
                //style = WS_THICKFRAME | WS_SYSMENU | WS_CAPTION | WS_CLIPCHILDREN |
WS_CLIPSIBLINGS | WS_MAXIMIZEBOX;
                style = WS_CLIPCHILDREN | WS_CLIPSIBLINGS;

        if (!SetWindowLong(HWnd, GWL_STYLE, style))
                os::Printer::log("Could not change window style.");

modified Irrlicht.NET.h

Code: Select all

                /// <summary>
                /// Creates an Irrlicht device. This is the main way to start using Irrlicht.
                /// </summary>
                /// <param name="driverType">Type of the driver used to render everything. Choose
                /// between D3D8, D3D9, OpenGL, Irrlicht's Software Renderer and the Null Device.
                /// </param>
                IrrlichtDevice(Video::DriverType driverType);
                IrrlichtDevice(Video::DriverType driverType, int hWnd);

modified Irrlicht.NET.cpp

Code: Select all

namespace Irrlicht
{

IrrlichtDevice::IrrlichtDevice(Video::DriverType driverType, int hWnd)
: Device(0), ManagedVideoDriver(0), ManagedSceneManager(0), ManagedCursorControl(0)
{
        irr::SIrrlichtCreationParameters param;
        param.WindowId = hWnd;
        param.DriverType = (irr::video::E_DRIVER_TYPE)driverType;

        Device = irr::createDeviceEx(param);
    
        if (!Device)
                throw new System::Exception(new System::String("Specified device could not be
created."));

        ManagedVideoDriver = new Video::IVideoDriver(Device->getVideoDriver());
        ManagedSceneManager = new Scene::ISceneManager(Device->getSceneManager());
        ManagedCursorControl = new GUI::ICursorControl(Device->getCursorControl());
        ManagedFileSystem = new IO::IFileSystem(Device->getFileSystem());
        ManagedGUIEnvironment = new GUI::IGUIEnvironment(Device->getGUIEnvironment());
}

That's all !

bye,
Duncan
--
Tucan Entertainment

[Duncan Mac Leod]

Question:
=======
I do not use a loop calling the Engine to render, instead I am using a Timer which calls the Engine to do the Rendering. This works fine and I use the Engine on a Managed Form Control (Panel)... - now on to my question: everytime the Engine window gets activated (i.e. clicking on the window), I loose control over my Windows Application (I cannot click on any other control - if I do so it seems that the Engine absorbs all the Clicks) - the only thing I can do leaving the Engine Window is to use my TAB-Key which activates the next control on my form and I gain access to my WinApp again... - I don't want to use an event receiver - does anyone know how the activated Engine consumes the MouseClicks ..? (just asking to save time to avoid investigating this behavior on my own )

thank you in advance,
Duncan
--
Tucan Entertainment

[Guest]

It does this when you call device->run(). Just don't call that.

[Duncan Mac Leod]

It does this when you call device->run(). Just don't call that.

I don't make that call in my .NET Program - perhaps the .net wrapper does something strange - I will look deeper on its code...

[Duncan Mac Leod]

It does this when you call device->run(). Just don't call that.

I don't make that call in my .NET Program - perhaps the .net wrapper does something strange - I will look deeper on its code...

I noticed that I must not call device.ResizeAble, cause it is responsible for that strange behavior. If I make call to device.ResizeAble (running the engine in a managed widget on a form), the form and all controls on it become unresponsive and the only chance to reactivate the form is pressing the tab-key. And calling device.ResizeAble doesn't make any difference to the resizing behavior of the engine in the managed widget. If you change the size of the widget, the engine does not resize, so it's best not to call device.ResizeAble at all for the moment if you are 'hosting' the engine in a managed control. I'll have to look deeper into the code, maybe I'll be able to fix it, but I want to do first some more experiments with our Application and the Engine - I have lost too much time on this 'issue',,,

Duncan
--
Tucan Entertainment

[niko]

I noticed that I must not call device.ResizeAble, cause it is responsible for that strange behavior.

Ah, thanks for that hint. An easy fix would be to add

Code: Select all

if (ExternalWindow || !getVideoDriver() || FullScreen)
	return;

in the beginning of CIrrDeviceWin32::setResizeAble(bool resize);
Will be in next version.

[Duncan Mac Leod]

I noticed that I must not call device.ResizeAble, cause it is responsible for that strange behavior.

Ah, thanks for that hint. An easy fix would be to add

Code: Select all

if (ExternalWindow || !getVideoDriver() || FullScreen)
	return;

in the beginning of CIrrDeviceWin32::setResizeAble(bool resize);
Will be in next version.

Hi Niko!

Thank you, for confirming that issue! ...but do you consider the immediate return from device.ResizeAble as a wise solution? Plz keep in mind that there is still one problem left: the ability to resize the engine in a managed widget (if the hosting widget resizes) - how would you handle such a task?

Duncan
--
Tucan Entertainment

[Duncan Mac Leod]

I noticed that I must not call device.ResizeAble, cause it is responsible for that strange behavior.

Ah, thanks for that hint. An easy fix would be to add

Code: Select all

if (ExternalWindow || !getVideoDriver() || FullScreen)
	return;

in the beginning of CIrrDeviceWin32::setResizeAble(bool resize);
Will be in next version.

Hi Niko!

Thank you, for confirming that issue! ...but do you consider the immediate return from device.ResizeAble as a wise solution? Plz keep in mind that there is still one problem left: the ability to resize the engine in a managed widget (if the hosting widget resizes) - how would you handle such a task?

Okay - SOLVED the Problem by implementing our own resize-method for external (i.e. engine running inside managed widgets on an .net form) engine windows ...

Our latest custom build features resizeable external windows for managed widgets (i.e. a panel) on .NET Forms and does include all new API additions, which were done by elric (look at http://irrlicht.sourceforge.net/phpBB2/ ... php?t=7020 for more information on elric's additions)...

Plz feel free to download our Custom Irrlicht Engine Build at
http://www.excelsior-online.org/downloa ... build_0.3/
if you are in need of such features for your .NET Application...

Duncan
--
Tucan Entertainment

Code: Select all

//draw a form
//draw a panel
//add Engine to Panel1
device = new IrrlichtDevice(DriverType.OPENGL, (int)this.panel1.Handle);
//
// resize example assuming your Camera is named scCamera
//
private void panel1_SizeChanged(object sender, System.EventArgs e)
{
	if (!this.isEngineRunning) return; // set your own bool to only call resize if engine is running on panel
	if (device.DoResize()) // NEW Method
	{
		Dimension2D dim2dScreenSize = device.VideoDriver.ScreenSize;
		Matrix4 mat4Matrix = new Matrix4();
		mat4Matrix.buildProjectionMatrixPerspectiveFovLH(scCamera.FOV, Convert.ToSingle(dim2dScreenSize.Height) / Convert.ToSingle(dim2dScreenSize.Width), scCamera.NearValue, scCamera.FarValue);
		scCamera.ProjectionMatrix = mat4Matrix;
		return;
	}
	else
	{
		throw new System.Exception("GFX Device could not be resized.");
	}
}

[Guesty]

However, I am currently a little bit confused if I should rewrite the .NET wrapper completely, because those §$% at microsoft seem to drop support for managed C++ and favor C++/CLI slowly: For example the .xml output only works with C++/CLI in the VS Beta. Maybe this wouldn't be a lot of work, just changing some identifiers etc. But if it is, I think I would ignore C++/CLI and keep on pushing Irrlicht.NET forward so it has more features.
Sorry for this confusing text, just thinking loud.

Have you considered wrapping the Irrlicht API in C# instead? C++.NET and C++/CLI is not yet supported by Mono, so it limits the wrapper to Windows only.

A C# wrapper - using an ability known as "P/INVOKE" or "Platform Invoke" - would mean Irrlicht's .NET wrapper would be portable across Windows/Linux along with the engine it binds to.

[Duncan Mac Leod]

However, I am currently a little bit confused if I should rewrite the .NET wrapper completely, because those §$% at microsoft seem to drop support for managed C++ and favor C++/CLI slowly: For example the .xml output only works with C++/CLI in the VS Beta. Maybe this wouldn't be a lot of work, just changing some identifiers etc. But if it is, I think I would ignore C++/CLI and keep on pushing Irrlicht.NET forward so it has more features.
Sorry for this confusing text, just thinking loud.

Have you considered wrapping the Irrlicht API in C# instead? C++.NET and C++/CLI is not yet supported by Mono, so it limits the wrapper to Windows only.

A C# wrapper - using an ability known as "P/INVOKE" or "Platform Invoke" - would mean Irrlicht's .NET wrapper would be portable across Windows/Linux along with the engine it binds to.

Of course, it's only usable under Win32, but that is IMHO much more than any other Engine on the Net has to offer (if you want to use C#)!!!! There is still another Project called Axiom3D (100% C# coded Engine) on the Net, which claims to be ready for use on other Platforms, but the naked truth is that it doesn't run on Mono out-of-the box. We have converted the Axiom3D Project (taken from CVS) to run on MonoDevelop's IDE, but it took more than 20 hours to get it running... BUT: Axiom3D seems to be no longer supported as you can read on the Project's Forums AND the other big disadvantage of Axiom3D is its performance. We were not able to get it smoothly running on a Pentium3 800 MHz!

We have weight the Pros and Cons of many other (OpenSource) Engines, especially for .NET usage, and there was only one choice left to make: IRRLICHT !

Now on to your Question: Doing a Port using Interop / PInvoke is a very difficult and time consuming task (and believe me, I know what I am talking about), so you should be glad that Niko's .NET Wrapper advances very quickly using the Concept of Mixed DLLs. It would be nice to see Niko not leaving the path of coding the wrapper using Mixed DLLs, cause it is the fastest way to bring Irrlicht to C#. So you will soon have a ready-to-run AND complete .NET Wrapper for Win32 to be able to start programming with... - and that's IMHO the most important thing for all C# Users who want to go with Irrlicht! For the concept of porting (doing a Port to Mono/Linux) when your Project is finished, you should encapsulate every call to Irrlicht in one DLL, so you won't have to touch your project after completion - just code another DLL for use on Mono/LinuX, which will do the Irrlicht-specific calls on the Mono-based Wrapper if it will come available.

We have done a lot of Interop / PInvoke stuff in the past trying to port the Crystal Space Engine to C# http://www.excelsior-online.org/images/ ... csharp.jpg, but we have cancelled the Project in favor of supporting the Irrlicht Engine in our Projects (Toolset + RPG) (cause of its leaner API and better handling ), so it's for sure that we'll bring Irrlicht Engine to Mono (C# in Linux) if no one else will do such a Port earlier. BUT: we are in the very beginning with our Projects, so don't count on it that it 'll be done soon (by us)... - maybe someone else on these Forums or you (??) should make the Interop / PInvoke (and we will support you)

...and PLZ don't push Niko into the time consuming Interop / PInvoke Development, cause he is the only one in charge for coding Irrlicht and the .NET Wrapper (on Win32) and I don't think that his resources are unlimited !!

...and a 'BIG THANK YOU' to Niko that there is a supported .NET Wrapper for Irrlicht!

Just my 2 Cents,
Duncan
--
Tucan Entertainment

[Guesty]

For my last evaluation of Axiom I found its performance easily compariable to OGRE3D; it also easily ran out of the box under Linux, apparently, as evidenced by the now defunct Axiom forums and several posts on the RealmForge forums (who have currently forked Axiom due to the lead developer of Axiom suffering rock-star syndrome followed closely by 'nobody's home' syndrome).

I will agree that the .NET wrapper has advanced with significant progress thanks to niko and programming it in mixed mode C++.NET, but I would still like to "keep the doors open" as it were to run applications under Mono. Irrlicht has the most promising potential; of all the engines that had managed interfaces I would rate it second best only to TV3D, which is also, unfortunately, Windows-only. 6.5 promises an incrediblyh nice managed api, though, instead of ugly COM-interop.

Can't fault me for pushing my own interests above yours, can you?

Its the way most humans work.