I've seen that .Net CF 3.7 doesnt have the directx ( Direct 3d) libraries and i was wondering if microsoft decided to delete them and not continue using directx with .net cf or if it's only because the 3.7 version is a beta and lacks many things.
Apart of that, i don't know what new things has 3.7 version, is there any changelog? because if there aren't important changes, i consider it may be better to continue using .net cf 3.5.
No follow up?
I'm curious if anybody has any more information on this matter. I'm currently using a slightly older version of NRGZ's EnergyROM with a Touch Pro and am unable to use Diamond Hologram because of a TypeLoadException stating that Microsoft.WindowsMobile.DirectX can not be found.
There's a chance that the rip of the unreleased .NET CF 3.7 was incomplete (though the GAC is pretty straightforward) or the pre-release state of it could also be used to rationalize missing assemblies, but if I were to take a random crack at it, I would guess that they're working on XNA for Windows CE/Mobile since it's based on CF and runs on Windows, XBox 360 and Zune it would be a logical step for Microsoft (just as they stopped supporting Managed DirectX on desktop editions), though it does seem a bit unfair to developers of existing applications since the desktop edition was not shipped with the framework, but rather with the DirectX SDK whereas this was deployed in the framework.
Is there a chance that someone could test using the 3.5 version on a 3.7 runtime? If the CLRs are compatible (and they seem to be) then it should still be able to load the assembly, and if binding works at all similar to the desktop framework we could probably just copy it into the directory of the application path, rather than GACing it.
After some searching around this is better discussed in the original CF 3.7 thread since it has been brought up. I'll repost my thoughts there and see if someone can help with experimenting.
http://forum.xda-developers.com/showthread.php?p=4060348
Not sure if this should be posted in the aforementioned thread, but it has long been rumoured that MS would phase out Direct3D by Windows Mobile 7, in favour of OpenGL and OpenGLES. Hope this helps at all.
GL
Well, I'm not so sure MS will ever officially support GL since it's a "competing" product to DirectX. In fact, to me it seems very unlikely. While they have been supporting community solutions and open source work more lately, generally Microsoft makes an effort to have developers use Microsoft technologies which in turn makes applications dependent on Microsoft and therefore users dependent on Microsoft. They have (arguably) the most powerful, useful and time-saving development tools which keeps many developers (like myself) developing applications that are inherently designed for their operating systems.
XNA, on the other hand is a Microsoft technology that is gaining a lot of traction and is directly related to the .NET Compact Framework, which is what leads me to believe they'll choose that route. With the right love and care a single XNA game can be played on PC, XBOX 360 and Zune and it seems likely that supporting the platform that .NET CF was first implemented on is only a matter of time. It's been rather surprising to many in the XNA community that MS hasn't already supported it, since their original press releases strongly indicated support for it. One thing's for sure: while there is an XNA Game Studio built on top of Visual Studio, there will probably not be any MS initiative to build a GL game studio.
http://www.microsoft.com/presspass/press/2004/mar04/03-24xnalaunchpr.mspx
To be fair though, that doesn't necessarily mean they won't implement the Windows Mobile version of XNA using OpenGL ES, though it seems likely that the architecture is designed more toward DirectX. Still hardware manufacturers could play a huge role in this decision.
Related
Hi,
Unfortunanately there isn't yet a lot of information available out on the net regarding development using Microsoft.WindowsMobile.DirectX namespace.
I am hoping we can start a new forum section dedicated to just this? What do you guys think?
I've only been working with it for about a week now, and I am struggling to find helpful information, and am figuring out a lot of things through trial and error (note the SDK documentation is quite thin too!).
Is there anyone else on this site that is keen to collaborate and share DirectX experiences?
i'm very interested in but i failed in basics (look here) and nobody here seems something to know about that.
one year before i gained few expieriences in direct3d. its similar but not the same to develop for mobile...
did you get running the examples of d3d from the ms mobile sdk?
heggenhugo said:
did you get running the examples of d3d from the ms mobile sdk?
Click to expand...
Click to collapse
Yea, all the examples (not) in the SDK worked. I put "not" in parentheses because it took me a long time to locate them as the are no longer included as part of the .Net compact framework SDKs or the DirectX compact framework.
I am working on a simple app now that will determine the hardwares capabilities, allowing developers to quickly discover which devices their apps/games will run on. But I am still only just getting used to the environment also.
could you send me please (or link) a working example? it would be enough to see how to create a d3d window. i want to develop an application that uses the g-sensor to navigate in a little 3d environment (for instance turn around a cube or sth like this).
ty
VB.Net D3DM Samples - DirectX Capabilities App
Here are all the MS provided examples. I have not tried them all, but most of them work (on my device). The emulators run them, but very very slowly.
I have also attached the ActiveX Capabilites Test.exe application I created which will show you exactly what DirectX features are available on a particular device.
It requires .Net 3.5 to be installed.
View attachment VB.zip - Vb.Net samples
View attachment 250790 - DirectX Capability Test (install to device)
A good start
Anyone looking to get started on Mobile DirectX Development, should start with the fundimentals of the Managed DirectX Runtimes.
I recommend "Managed DirectX 9 Kick Start - Graphics and Game Programming" by Tom Miller. It's a good start into the world of Managed DirectX.
Looks like Silverlight is the platform for creating Windows Phone 7 apps, finally.
http://www.crn.com/software/222900433;jsessionid=ZSTDUKCIARR4FQE1GHPCKHWATMY32JVN
I hope so, SIlverlight rocks, so much better on my PC than Flash but yet it isnt widely adopted, hopefully if WP7S has Silverlight this will boost its use
Finally!
It is indeed a very logical step.
I was trying to make a "fancy" UI on WinMo 6x and it's damn hard (that will work blazing fast). And search for a Silverlight for WinMo... and it was there... and it was showed on the TechEd 08... but never released... and I was like:
-Oh ... come on... how long does it take to port it??!
This is almost like a "duh" story but it's good to have a "source" saying it.
Silverlight will be for lightweight stuff and XNA 3 (4?) will be for Games, etc.
Imagine being able to write one app and have it work on multiple platforms with little or even no code changes. Silverlight supports multi-touch on Windows 7 too.
XNA and Silverlight. No native apps - see attach.
Can you already create SL applications for the WinMo?
DMAND said:
I hope so, SIlverlight rocks, so much better on my PC than Flash but yet it isnt widely adopted, hopefully if WP7S has Silverlight this will boost its use
Click to expand...
Click to collapse
Yes silverlight rocks and i am learning it right now.
afma_afma said:
Yes silverlight rocks and i am learning it right now.
Click to expand...
Click to collapse
Know any application? Link?
Developing .NET CF on WM6 is a -pain-. Even if you want to do something as simple as draw a transparent image you have to delve into P/Invoke which feels like hacking. If they get .NET development under WP7 working simply and effectively, then I think it will be a great step forward. I've used WPF extensively and it is a great platform to work on. I've no reason to think Silverlight is any different.
My only concern is how they'll restrict the distribution and installation of applications. The openness of the Windows Mobile platform has always been a big draw, and if they do an Apple and try to restrict how I publish and obtain apps then not many people will see a reason to switch from such an established and successful platform.
Okay, so since the unlocked emulator has a file manager and task manager, does that mean it would be possible to extract them and run them on an actual WP7S device? And if that was possible, would it also be possible to extract the Native APIs from these apps? I'm fairly certain that they use Native APIs because ordinary apps can only access their own directory. I'm not very smart with these things, so sorry if it's obviously impossible or something.
It's wince - the native API is always there, where do you want to extract it from? Also some people figured out most WP7 apps from the emulator ROM are written in native as well. it's always here.
But you can't just put file manager on a WP7 device because there's no access for you to put anything on it, except apps from Marketplace you got the picture? even if we could cook our custom ROMs in the future the only thing we could do is throw in our own DLLs, services or background tools on it and customize it a little. I still doubt you'd be able to develop real WP7 style apps like a file manager or registry editor because the GUI is supposed to be written in Silverlight/XNA. And from those frameworks you can't access the native API unless Microsoft would add support for it.
101% dumb phone. If you think about it then WP7 is even WORSE then iphone.
But what if you could use Visual Studio to load it onto the device? If you look around in it, there is an option for that.
Actual devices will have to be unlocked for developement purposes to allow sideloading through Visual Studio and even then I doubt the system would be able to deploy native code. Developer phone means a yearly fee for membership in the MS developer programm.
I don't think that using native APIs from managed code would be impossible in the SDK - carriers, e.g. will be allowed to use it, but for normal applications the Security Context in .Net would prevent the programm from calling them (Code Security Managers are configurably available in Java and .Net from the beginning, so i believe that would be what MS uses to block access).
And of course programs using those wouldn't get on the marketplace.
Oh, too bad then, but thanks for your response anyway!
Fdo35 said:
Okay, so since the unlocked emulator has a file manager and task manager, does that mean it would be possible to extract them and run them on an actual WP7S device? And if that was possible, would it also be possible to extract the Native APIs from these apps? I'm fairly certain that they use Native APIs because ordinary apps can only access their own directory. I'm not very smart with these things, so sorry if it's obviously impossible or something.
Click to expand...
Click to collapse
Okay, the issue here is the lack of a few key DLLs: Windows 7 Series will not offer GDI most likely (I'm downloading the emulator set now, and will confirm this soon) and will lack comctl32.dll and the like, removing these functions. As it's been stated before, like Windows 7 uses the 6.1 NT Kernel, Windows Phone 7 series uses the 6.5 Windows CE kernel, at least, last that I've heard. It would then be both possible to bring Windows Mobile 6.5 DLLs over, but anything that calls GDI will not work. Solution? Make a mock GDI that uses the new render.
This isn't new either, Windows 7 uses WPF more than ever (Which composes most of the games as well as Windows Media Center), which is a 3D accelerated and fancier way to draw to the screen, and Windows 7's GDI subset has been updated to allow hardware acceleration granted the graphics card allows it (It's actually something the video card driver must tell Windows, as MSDN states)
Deploy native code, no. Run it, of course
I'll be investigating the possibility of native code here shortly. Chances are, you will need to set the target to ARMV6, and set the compile type to Native, not Windows. Most developers, if not all, probably have overlooked this.
I would expect that it'll require privileged access to run native code, so you'll need to solve the code signing problem.
ThymeCypher said:
Okay, the issue here is the lack of a few key DLLs: Windows 7 Series will not offer GDI most likely (I'm downloading the emulator set now, and will confirm this soon) and will lack comctl32.dll and the like, removing these functions. As it's been stated before, like Windows 7 uses the 6.1 NT Kernel, Windows Phone 7 series uses the 6.5 Windows CE kernel, at least, last that I've heard. It would then be both possible to bring Windows Mobile 6.5 DLLs over, but anything that calls GDI will not work. Solution? Make a mock GDI that uses the new render.
Click to expand...
Click to collapse
Well, I doubt things like comctl.dll and some other things like GWES will be that big of an issue once Platform Builder 7 is released and we can just generate these components ourselves. Hell, adding back GDI support (if those rumors aren't just lies) may be as easy as replacing the GWES with a less crippled one generated by Platform Builder. Maybe GDI support is still compiled in but just doesn't output directly to the screen using the default graphics driver implementation. That's how the Dreamcast implementation of Windows CE was. To even see apps like IE on the screen, you need to copy the contents of the standard WinCE GDI output to a DirectDraw surface.
What I'm more worried about is the hackability of the hardware/software. I'm really hoping it's not as insanely locked down to the point to being unhackable like every Zune.
do you think Platform builder is still available for WP7? Since MS won't allow the OEMs to modify the OS I doubt that. Do you have a source? You've seen an announcement from MS or something?
RAMMANN said:
do you think Platform builder is still available for WP7? Since MS won't allow the OEMs to modify the OS I doubt that. Do you have a source? You've seen an announcement from MS or something?
Click to expand...
Click to collapse
Platformbuilder is for the OS, which is Windows CE. There is still some debate as to what version the emulator is running, leaving alone the possibility that the actual version of the OS may be different at release.
If the CE6R3 camp is right, you can get platform builder for that right now, though you wont have telshell.exe (WP7 replacement for explorer.exe), and the WP7 specific apps. It would be an interesting exercise to see if they could be run on CE6R3. If no one beats me to the punch, I plan on trying this for myself when I am less swamped at work.
If the CE7 camp is right, you will have to wait till MS releases that version to the public. And they WILL release it because there are far too many embedded systems outside of phones that run on CE for them to neglect it.
No, I was talking about the generic Windows CE 7.0 Platform Builder and not the OEM specific OAK for WP7S. Unless MS plans to completely drop their generic Embedded Windows CE offerings, I see no reason why PB 7.0 will not be released and help with hacking WP7S (if it is even based on 7.0). You always needed to be a large ODM and sing an NDA to use a Platform Builder addon/OAK for the MS platforms like Pocket PC. Those almost never leak and I can't imagine this would be much different.
RAMMANN said:
do you think Platform builder is still available for WP7? Since MS won't allow the OEMs to modify the OS I doubt that. Do you have a source? You've seen an announcement from MS or something?
Click to expand...
Click to collapse
Yes, platform builder was used to build leaked wp7 arm image.
d:\wm700_6176\platform\common\src
\soc\qcom_v1\oal\power\sleep.c
It is from from nk.exe
use dumpbin.exe to get all methods in dll/exe
I'd like to extend my gratitude to RustyGrom and others (if there are any) for the work on unlocking the developer builds of WP7, but I was wondering what where we are in relation to 'rooting' WP7 so we can run our own unsigned binaries and possibly even getting the stock Windows CE shell and software running on WP7 instead of the Metro UI.
I've heard unconfirmed and uncorroborated rumours of Microsoft's plans to allow native development eventually, but my friends who work at Microsoft really give me the impression that the Managed-only rule is here to stay, in which case it will be up to people like us to get it working.
My initial thoughts are that the hardware HTC and other mfgs produce will have a firmware flash function, so it's just (in my naive mind) a matter of dumping the ROM, making the right changes, and re-flashing the device, assuming there isn't a requirement the new ROM image is signed by Microsoft or the OEM.
Windows CE wasn't built with a hypervisor in mind (unlike the PS3) so I'm curious as to how the sandbox is implemented, and how an attack could be forged against the platform. If we get something working on the emulator would it work on the physical devices?
IIRC policies are requested by xml configuration files located in a .xap.
I haven't yet looked deeply into this, but I would assume it works similarly to CE5.x/WM6.x: that is, if the .xml requests a higher security level than the norm (say, SECLEVEL_EXEC_NATIVE_CODE for example), the .xap deployment system would check the .xap certificate against the internal certificate store. If a match is found to the right security level (Root at first, later OEM, probably never User), the application is allowed to install, if not, the installation is denied.
So, elevating privledges to execute native code should be easy to do with filesystem level access, we inject our own certificate to the root certificate store, sign the .xap with that certificate, and deploy away.
NOTE: This is an educated assumption, i've not actually examined the restriction system in depth yet.
Sortof. You could use those "Interop" methods and go native. It worked for me with a lot of tough luck.
The word windows and "Rooting" should never ever be used together. The term rooting obviously is being grossly misused.
Root is the user in linux that is given full and complete access to all system resources.
tyrannus said:
Sortof. You could use those "Interop" methods and go native. It worked for me with a lot of tough luck.
Click to expand...
Click to collapse
P/Invoke and Interop don't work on WinPho because the functionality required is disabled in the sandbox environment, or possibly not even present in the version of the CLR they're using.
Look, it's W3bbo!
Tom Servo said:
Look, it's W3bbo!
Click to expand...
Click to collapse
Wtflol. Hey Toiletbrush, haven't seen you around for a while. Didn't you get banned from C9 or something?
(I'm still active on SA btw, just under a different username)
Naw, I was on an Anti-MS binge for three years until few weeks ago. Took Oracle screwing up OpenSolaris. That and I wanted a Windows Phone. Kinda useless without Windows.
Mod edit: Please watch your language
For the main:V can't run wp7 on our HD2
I am thinking of the other way around, getting xaml and xap to run on wm6, the hd2 is quite capable of running them. Wp7 runs cf3.7 and we can start from there. Maybe we need to identify the required assemblies and copy them. Defiantly it won't be fully supported, launchers will not work for example but it might be a good shot.
I'm not a core coder or hacker, but when it comes to logic I'm optimistic, it might be possible.
I would love to see silverlight running on wm.
You are really optimistic.
WP7 is compiled against armv7, where WM is compiled against armv4i...
ARM v7 has nothing to do with .net assemblies, that us why we need .net cf to run apps built using .net
Now the question is, is the .net cf responsible for running xap packages or is it another framework (like on pc, you need sl runtime)
Afak, it is the cf.
Please correct me if I'm wrong.
I read every post and understood nothing. You guys are on another level with your tech jargon. Lol.
Sent from Android HD2 using XDA app
anaadoul said:
ARM v7 has nothing to do with .net assemblies, that us why we need .net cf to run apps built using .net
Now the question is, is the .net cf responsible for running xap packages or is it another framework (like on pc, you need sl runtime)
Afak, it is the cf.
Please correct me if I'm wrong.
Click to expand...
Click to collapse
The JIT compiler (or what is used in CF version) that loads assemblies is compiled against armv7 and these assemblies can't be run on our compiler.
OndraSter said:
The JIT compiler (or what is used in CF version) that loads assemblies is compiled against armv7 and these assemblies can't be run on our compiler.
Click to expand...
Click to collapse
Assemblies are not compiled against a platform or a CPU Architecture, they are compiled against a .NET Framework version to an IL.
The JIT is the different one, it is a native code so it is compiled to V7 in Windows Phone 7, but we have it already (JIT) compiled against ArmV4 (as in .net cf)
anaadoul said:
Assemblies are not compiled against a platform or a CPU Architecture, they are compiled against a .NET Framework version to an IL.
The JIT is the different one, it is a native code so it is compiled to V7 in Windows Phone 7, but we have it already (JIT) compiled against ArmV4 (as in .net cf)
Click to expand...
Click to collapse
Unlike Java, the IL that .NET compiles is actually CPU specific. This is why you can specify the CPU type when compiling a (desktop) .NET application (either x86, x64 or Itanium).
XAP files on Windows Phone 7 run on top of a modified version of Silverlight. Silverlight has its own runtime engine, and does not reference the .NET libraries at all (they just happen to share namespaces and classes to make coding easier). To get WP7 applications to run on WM6.5 you would need to recompile Silverlight.
TehPenguin said:
Unlike Java, the IL that .NET compiles is actually CPU specific. This is why you can specify the CPU type when compiling a (desktop) .NET application (either x86, x64 or Itanium).
Click to expand...
Click to collapse
Not true. The MSIL itself is CPU-independent. The reason you can chose to specify the architecture when compiling is for .NET Applications that depend on external native-code libraries. Obviously, in those cases, the default "Any CPU" option just causes a nightmare, as the framework then chooses the architecture of the JIT compiler, meaning different dependencies for different machines. Selecting an architecture inserts data telling the JIT compiler what architecture it must use.
That said, what you go on to say about Silverlight is true. Silverlight does not depend on the .NET Framework on the desktop, or the .NET Compact Framework on CE or WP7 (though the compiler for Silverlight does require the .NET Framework). Strictly speaking, the only thing they share in common is the CLR, the libraries are all recreated and re-engineered for their specific purpose. The Libraries share the names simply to enable software developers to re-use as much desktop code as possible.
(Note: I think this is all correct, though I'll be the first to admit that I am much more experienced with Desktop .NET than the mobile equivalent).
Silverlight on WP7 will undoubtedly have native dependencies too, just like the .NET Framework and the .NET Compact Framework (both make extensive use of existing Windows APIs, of course).
Therefore, it'd take a Moonlight-style project (The Mono equivalent of Silverlight, enabling Silverlight applications to run on Linux) in order to bring Silverlight to Windows Mobile classic.
hounsell said:
Not true. The MSIL itself is CPU-independent. The reason you can chose to specify the architecture when compiling is for .NET Applications that depend on external native-code libraries. Obviously, in those cases, the default "Any CPU" option just causes a nightmare, as the framework then chooses the architecture of the JIT compiler, meaning different dependencies for different machines. Selecting an architecture inserts data telling the JIT compiler what architecture it must use.
That said, what you go on to say about Silverlight is true. Silverlight does not depend on the .NET Framework on the desktop, or the .NET Compact Framework on CE or WP7 (though the compiler for Silverlight does require the .NET Framework). Strictly speaking, the only thing they share in common is the CLR, the libraries are all recreated and re-engineered for their specific purpose. The Libraries share the names simply to enable software developers to re-use as much desktop code as possible.
(Note: I think this is all correct, though I'll be the first to admit that I am much more experienced with Desktop .NET than the mobile equivalent).
Silverlight on WP7 will undoubtedly have native dependencies too, just like the .NET Framework and the .NET Compact Framework (both make extensive use of existing Windows APIs, of course).
Therefore, it'd take a Moonlight-style project (The Mono equivalent of Silverlight, enabling Silverlight applications to run on Linux) in order to bring Silverlight to Windows Mobile classic.
Click to expand...
Click to collapse
If silverlight doesn't need the .net cf then
1) why is it included in wp7 (.net cf 3.7)
2) how can we use compiled assemblies (.net) inside silverlight?
Sent from my HTC HD2 using XDA App
anaadoul said:
If silverlight doesn't need the .net cf then
1) why is it included in wp7 (.net cf 3.7)
2) how can we use compiled assemblies (.net) inside silverlight?
Sent from my HTC HD2 using XDA App
Click to expand...
Click to collapse
1) XNA uses the .NET framework
2) The assemblies must target the Silverlight runtime, as such any assembly compiled for the .NET runtime will not work
anaadoul said:
1) why is it included in wp7 (.net cf 3.7)
Click to expand...
Click to collapse
I don't know, maybe because a lot of the base system's written in not-Silverlight managed code?
Hey there!
I'm wondering if OpenGL games, like Quake III, can be ported just like they did for Android with Kwaak3.
Does WinPho7 support OpenGL ES in addition to DX9c?
Best Regards Mr.Sir (Gustaf)
I googled around and it appears that XNA will be the only choice besides silverlight for app/game development. So if you can somehow port an OpenGL came to XNA, then yes.
Mr.Sir said:
Hey there!
I'm wondering if OpenGL games, like Quake III, can be ported just like they did for Android with Kwaak3.
Does WinPho7 support OpenGL ES in addition to DX9c?
Best Regards Mr.Sir (Gustaf)
Click to expand...
Click to collapse
Nope. It's only what you will find in XNA. There are several samples people have posted for porting on xbox 360; same code will work on the phone with VERY little changes.
So, seriously guys, no native support? I mean, when i was working at NDrive they had everything written in C++ with interfaces for each device. I doubt that any sane company will rewrite its software completly just to compete in a niche...
Even in .NET CF you COULD do some PInvokes which kinda allowed you to attempt to run a managed version of OpenGL (.NET sucked and still sucks for serious game development, obviously) which was slow as hell, but at least it was there.
So please, native support!
ei05035 said:
.NET sucked and still sucks for serious game development, obviously) which was slow as hell, but at least it was there.
Click to expand...
Click to collapse
That's why it is entitled with XNA
Yup Buddy but its gud because you have to code only one time and then you can able to convert it for using on other platforms..
And by several platforms you say M$ based ones. I mean, most companies (i can give you the example of NDrive as I was there for a while) would rather code in C++ and create interfaces for specific platforms. No native code support kills it. I don't see companies renaming extensions to .cs, enabling unsafe code (pointers, etc) and giving it a good dose of whisfull thinking.
Oh and when I meant that XNA sucked for serious gaming i meant really. AAA games don't rely on that. They rely on GPU manufacters SDKs and on the good ol' DirectX SDK. This is if they don't have some housemade engine (like Crytek) similar to Shiva3D or Unity (but custom tailored).
I mean, seriously. In .NET CF 3.5, give it a go, try to natively rotate an image and resize it without manually processing the bitmap information to do so (and at the expense of CPU usage). I had to rely on DxSprites and OpenGL when I needed.
XNA is, as it was already mentioned, game-wise, a game-loop oriented tool with a few PInvokes to DirectX...
ei05035 said:
And by several platforms you say M$ based ones. I mean, most companies (i can give you the example of NDrive as I was there for a while) would rather code in C++ and create interfaces for specific platforms. No native code support kills it. I don't see companies renaming extensions to .cs, enabling unsafe code (pointers, etc) and giving it a good dose of whisfull thinking.
Oh and when I meant that XNA sucked for serious gaming i meant really. AAA games don't rely on that. They rely on GPU manufacters SDKs and on the good ol' DirectX SDK. This is if they don't have some housemade engine (like Crytek) similar to Shiva3D or Unity (but custom tailored).
I mean, seriously. In .NET CF 3.5, give it a go, try to natively rotate an image and resize it without manually processing the bitmap information to do so (and at the expense of CPU usage). I had to rely on DxSprites and OpenGL when I needed.
XNA is, as it was already mentioned, game-wise, a game-loop oriented tool with a few PInvokes to DirectX...
Click to expand...
Click to collapse
If you are so gung-ho, you could write wrappers in C++, compile the DLL and pinvoke your calls.
tyrannus said:
If you are so gung-ho, you could write wrappers in C++, compile the DLL and pinvoke your calls.
Click to expand...
Click to collapse
Exactly! Honestly for me it is the way to go. It's not that i don't like C# or .NET, quite the contrary. I'm just sorry that they lack the portability some projects require. And for me, WP7 not having native code support is a real buzz kill. What do you think?
It does have native code support but you need Microsoft's permission to get the SDK. I'm pretty sure game companies will have it if they want to make use of the GPU as much as possible.