Possibility for Ogre on Xbox360 through XNA

[Bekas]

Sometime ago, one of the XNA developers mentioned that the Xbox360 .NET framework allows unsafe code (pointers etc.), it's just that you cannot P/Invoke into unmanaged code. I thought that pointers were unusable, so when I read this it sparked my interest in the possibility of Ogre running on XNA.

I've managed to get Eihort Ogre compiled with /clr:pure option, which produces a pure managed code binary (not mixed native/managed). Surprisingly, freetype gave me the biggest trouble for getting it compiled and linked properly, OgreMain was smooth sailing compared to that.

The "proof of concept" can be downloaded from here. (requires the VC++ 8 SP1 binaries).
It's the CameraTrack demo + OgreMain + RenderSystem_Direct3D9 + Plugin_OctreeSceneManager + Plugin_ParticleFX into one pure .NET executable.
'NativeOgre.dll' contains the win32-specific code (like the window proc) and native D3D code (the .NET executable P/Invokes into it).
'FreeImage.dll' is native FreeImage. (I'm not sure whether it's necessary to get it compiled to pure .NET; its functionality could be replaced by XNA classes).


AFAIK the steps to make it fully runnable on XNA would be:

-Replace the P/Invokes to VC++ binaries (MSVCR80.dll etc.) with managed code
-Replace the P/Invokes to d3d9.dll and d3dx9d.dll with a XNA-specific RenderSystem.
-Replace the P/Invokes to FreeImage.dll with equivelant XNA functionality or get it compiled with /clr:pure as well.
-Substitute the 'calli' CLR opcode functionality ('calli' isn't supported by the Xbox CLR)

The manipulation of the .NET executable can be done with Cecil


Unfortunately, I don't have an Xbox360 to start "hacking" on it and I have no intention on getting one (I'm not much of a gamer anymore). If there's interest by the Ogre community for donating to the "Ogre on XNA by an Xbox360 + Creator's club submission" fund, I'm willing to volunteer my time on it.

But I'm sure everybody will think it's an elaborate scum to get a free Xbox, so feel free to flame away

[pjcast]

Wow, those are some interesting thoughts you are having!

In regards to freeimage, I don't see why it should not be added, it has many useful image codecs & a liberal license; though, I don't know what XNA supoprts in terms of images.

I'm not familiar with either of these:
-Substitute the 'calli' CLR opcode functionality ('calli' isn't supported by the Xbox CLR)
The manipulation of the .NET executable can be done with Cecil

What exactly is 'calli'? And, what needs manipulation with Cecil?

Besides that.. hmm, quite interesting. Commercial games on the Xbox with Ogre using this would be pretty cool if you could pull it off.. I do not have a Xbox 360 either. Nor do I have funds to get you one Does XNA support assembly loading? Or does it have artificial restrictions on having a single assembly as your app? I believe Xbox360 allows for dynamic library loading, unlike the original Xbox.. If you can load assemblies, then it becomes possible to create closed source applications with XNA + Ogre (assuming that your assumptions are correct, and Ogre can load) - and stay compliant with the LGPL.

Besides that, I don't think porting the DirectX 9 rendersystem to XNA would be that hard. As I understand it, XNA is very similiar to DirectX type of functionality.

Edit - my only problem than becomes, that iirc, only fellow XNA developers who paid for the platform can then play your app.

[cybereality]

Well I have an Xbox360 and a Creators Club membership, so I could test some stuff if you want. The XNA SDK also builds for the PC with the same code, so theres no reason you couldnt develop it fully on the PC. When you output for the 360 there are some additional restrictions, you can't mix native/managed code, limited render targets, etc. But I'm pretty sure you can dynamically link to dlls, so I guess its possible. Very interesting idea.

[Bekas]

What exactly is 'calli'? And, what needs manipulation with Cecil?

'calli' is a low-level IL opcode (the assembly language of .NET). It's used to call a function by address (not by name). It's emitted only by C++/CLI not by C#.

P/Invokes to MSVCR80.dll are hard-wired and can't be removed on the source level, the binary executable needs to be manipulated directly; and there's also the need to remove 'calli'.

The XNA SDK also builds for the PC with the same code, so theres no reason you couldnt develop it fully on the PC

XNA on PC is based on the desktop .NET framework while the Xbox one is based on .NET compact framework. They have important low-level differences (like the calli thing).
But thanks for offering the testbed, I'll PM you.

[dorvo]

There are also some differences between the shaders on PC and XBox 360.

Check out Shawn Hargreave's post on Point Sprites.
http://blogs.msdn.com/shawnhar/archive/ ... -xbox.aspx

[handcircus]

I'd definitely be very interested in this, and would be more than willing to donate towards it.

[Evak]

I'd definately be interested in a way to get Ogre running on 360 XNA easily and will be willing to pay for a good implementation.

Were hoping to port our current project to 360 eventualy, and would prefer something that worked as close to the current ogre API as possible for easy portability.

[Bekas]

It's good that there's interest, hopefully the idea is feasible.

There is no way to send binaries to the Xbox360. Currently the only method is to "deploy" a project from MSGS. So XNA projects built for Xbox360 can only be shared via the complete source code/project file and assets. There is also some sort of digital signature specific to my xbox console, so even if you could rip an xbox binary from the hdd, it still wouldnt run on anyone elses console.

This question applies to those using Xbox XNA: Does the above statement mean that you must have the source of all your .NET binaries, and you can't link to a .NET DLL or deploy a .NET executable unless you have its source ?

[Evak]

I'll be interested to see how things change with the pro XNA developer club.

The current basic one is pretty limiting in how you distribute your applications, but the pro version is aimed at live arcade rather tha a hobyist game club with shaded sources.

MS seem to be quite accomodating to developers who's games they want on XBL Arcade.

[Schmelly]

A little basic question:

I've managed to get Eihort Ogre compiled with /clr:pure option, which produces a pure managed code binary (not mixed native/managed). Surprisingly, freetype gave me the biggest trouble for getting it compiled and linked properly, OgreMain was smooth sailing compared to that.

What does this mean exactly? Can i for example access ogre directly from my .NET application (maybe with C#) without the need of a wrapper like mogre?

[pjcast]

A little basic question:

I've managed to get Eihort Ogre compiled with /clr:pure option, which produces a pure managed code binary (not mixed native/managed). Surprisingly, freetype gave me the biggest trouble for getting it compiled and linked properly, OgreMain was smooth sailing compared to that.

What does this mean exactly? Can i for example access ogre directly from my .NET application (maybe with C#) without the need of a wrapper like mogre?

Even if Ogre gets compiled as a pure managed library. It still needs a wrapper to interface with C#/VB.Net/etc. If, however, you were using CLI/C++ you would not need a wrapper. Compiling Ogre as managed is useful mainly to get Ogre into a managed form to run under XNA - which, afaik, does not allow native dlls, only managed assemblies. At least, that is how I understand it.

[Bekas]

A little basic question:

I've managed to get Eihort Ogre compiled with /clr:pure option, which produces a pure managed code binary (not mixed native/managed). Surprisingly, freetype gave me the biggest trouble for getting it compiled and linked properly, OgreMain was smooth sailing compared to that.

What does this mean exactly? Can i for example access ogre directly from my .NET application (maybe with C#) without the need of a wrapper like mogre?

No, the way it gets compiled to MSIL binary is very close to a C++ compilation. All the classes are empty structs (with the size of the equivelant C++ class) and all (I mean *all*) the C++ methods/functions are dumped into the module type, which is not accessible/usable outside of the assembly.
Even if you compiled to a DLL you stiill wouldn't be able to link to it and call the methods.

[Evak]

OOps hehe sorry was supposed to be Pvt

[joew]

I just figured I would post to let people know that with XNA GSE the only way to execute code on a retail XBox 360 is using C# and by using the XNA Game class. Although for development on the PC you can use any .Net compatible language. Also to clear up a little misconception, the professional version of XNA is not aimed at the development of XBL arcade games, but will be a completely seperate distribution channel.

[pjcast]

I just figured I would post to let people know that with XNA GSE the only way to execute code on a retail XBox 360 is using C# and by using the XNA Game class. Although for development on the PC you can use any .Net compatible language. Also to clear up a little misconception, the professional version of XNA is not aimed at the development of XBL arcade games, but will be a completely seperate distribution channel.

And how could the .Net platform possibly differentiate between IL code coming from compiled C# code, from that of compiled VB.Net code, or even compiled CLI/C++ code?

[joew]

And how could the .Net platform possibly differentiate between IL code coming from compiled C# code, from that of compiled VB.Net code, or even compiled CLI/C++ code?

You can't just copy code over to the 360 and have it run, that isn't how XNA works at all. You have to be using Visual C# Express Edition and the XNA GSE and there is a staging and process of how it is sent to the retail console. There are many other points such as the content pipeline and how textures and other assets are used on the 360, and they are actually staged to the console through Visual Studio.

[Bekas]

@NdotL:
So, assuming that I have a .NET dll and not its C# source, I can't use it on Xbox ?

Also, can you tell me what is the size of a pointer for the xbox CLR ? If you have this line

Code: Select all

int ptrsize = sizeof(void*);

What's the value of ptrsize ?

[dorvo]

@NdotL:
So, assuming that I have a .NET dll and not its C# source, I can't use it on Xbox ?

Also, can you tell me what is the size of a pointer for the xbox CLR ? If you have this line

Code: Select all

int ptrsize = sizeof(void*);

What's the value of ptrsize ?

I would expect that you need to compile the source code using the specific compiler settings that XNA requires, in order to get it to run on the XBox360. So, a /clr:pure build of Ogre is almost certain to not run on the XBox360.

[joew]

@NdotL:
So, assuming that I have a .NET dll and not its C# source, I can't use it on Xbox ?

Correct, using XNA you can only compile and run C# source code on the XBox 360, although for Windows builds you are free to do that.

Also, can you tell me what is the size of a pointer for the xbox CLR ? If you have this line

Code: Select all

int ptrsize = sizeof(void*);

What's the value of ptrsize ?

The 360 uses the compact framework CLR and adheres to .Net standards so everything is predictable to the CF standard.

[Falagard]

There's a post here that says that someone got C++ to work (and deploy) onto the 360:

http://forums.scummvm.org/viewtopic.php ... bc2ee2f896

[Bekas]

Thanks for the link Falagard!

@NdotL:
So, assuming that I have a .NET dll and not its C# source, I can't use it on Xbox ?

Correct, using XNA you can only compile and run C# source code on the XBox 360

Hmm, this page: http://grammerjack.spaces.live.com/blog ... !157.entry
says that deploying a .NET dll not written with C# is possible, any thoughts on this ?

The 360 uses the compact framework CLR and adheres to .Net standards so everything is predictable to the CF standard.

I was wondering whether due to different CPU, pointers are 64bit there (this would kill off the whole idea). But the guy at Falagard's link seems to got a pointers sample working properly..

[johnhpus]

Something that we may be overlooking here is the question of, even if it's possible to use native code, will MS let you publish to XLA if you do?

The word I received (second hand) from MS is that it's not even possible. Given the evidence, I don't necessarily believe that, but if the official line is to tell people it's not possible, they probably don't want you doing it.

[dorvo]

I'm guessing Microsoft would deny your request for putting something up on XBLA if it doesn't meet their standards/requirements.

The issue with /clr:pure builds isn't so much whether or not you can get it to run on the XBox360, but you're not even using the XNA Game Studio. If you're serious about this, I'd suggest waiting to start until after XNA Game Studio Professional is released. It might hold more clues and better options than what's currently available to you.

[Bekas]

The issue with /clr:pure builds isn't so much whether or not you can get it to run on the XBox360, but you're not even using the XNA Game Studio.

Not exactly. Of course you are required to use XNA Game Studio to deploy to Xbox, there's no way around it; what I'm trying to find out is whether you can use a /clr:pure .NET DLL linked with your XNA C# program.

[Bekas]

Something that we may be overlooking here is the question of, even if it's possible to use native code, will MS let you publish to XLA if you do?

Technically speaking, /clr:pure is not native code, it's C++ code compiled as a managed .NET binary; anything that can't be translated to managed code is unacceptable (i.e. x86 assembly code is not allowed with /clr:pure).