Sign in to follow this  

Windows Longhorn and Game Development

This topic is 4832 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I just have a couple of questions concerning the subject. First off Im working on a pretty big game project and engine at the moment. Ive been on it for month and will be on it for quite some more time. Now Im wondering as to what the impact on developers will be. Obviously not even microsoft can force all the game companies to switch to C#. Anybody here have any insite as to wether game companies will switch? 1.) How will c++ be handled? I heard thingas like windows will popup a warning message telling the user its a risk to open the app. That would be horrible since it looks very unprofessional and may even stop some people from using the software. Is this true and what are game companies going to do? 2.) My game and engine consists of multiple dll's. I dont know too much about c# but is it easily possible to mix c++ and c# dll's. So basically at some point I just use my c++ engine and have a c# game dll. I guess what it comes down to is, how long will programming games in c++ continue to be the standard and a professional looking project. Or will I be overly conservative if I wait longer with a transision? -CProgrammer

Share this post


Link to post
Share on other sites
Quote:

1.) How will c++ be handled? I heard thingas like windows will popup a warning message telling the user its a risk to open the app. That would be horrible since it looks very unprofessional and may even stop some people from using the software. Is this true and what are game companies going to do?


I cant see C++ going away, even in the mid to long term future. For a start there is just too much existing code written in c++. However, more companies will probably start writing managed c++, which is c++ which compiles to .net byte code.

Quote:

2.) My game and engine consists of multiple dll's. I dont know too much about c# but is it easily possible to mix c++ and c# dll's. So basically at some point I just use my c++ engine and have a c# game dll.


If your engine was written in managed c++ it would be very simple to load that up and use it from any other .net lanaguge.

This article talks about what managed c++ is, and about if c++ as a language is going to go away.

Alan

Share this post


Link to post
Share on other sites
Longhorn won't be here for about another year. It is also silly to expect an immediate changeover, even if a technology becomes "obsolete." Therefore, even if there is no future in C++ (a fairly ludicrous suggestion), it'll take upwards of five years for it to die out.

And yes, native apps run unaltered on Longhorn.

Share this post


Link to post
Share on other sites
Game developers need C++ in its plain form for the gamecube and PS2 platforms and presumably their successors. XBOX2 and later may run .NET (?) but since PS2 is the biggest console...
Game developers aren't going to port their C++ across to .NET happily - many would possibly just drop the PC.

Share this post


Link to post
Share on other sites
Thanks for you answers, they make me feel a lot better already.

Oh thanks for the article.

Concerning managed c++: In your opinion is it possible to port large portions of unmanaged c++ code to managed easily?
Are we talking serious work here?
Oh Im using OpenGL, SDL and DirectX in my project.
Will IJW even do my type of project? And are there noticeable drawbacks using IJW?

-CProgrammer

Share this post


Link to post
Share on other sites
Quote:
Original post by CProgrammer
Concerning managed c++: In your opinion is it possible to port large portions of unmanaged c++ code to managed easily?


Well I think one of the best things about the VSNET compiler is the /CLR switch, I find it just phenominal.

Lets say you write your application in unmanaged C++ and when Longhorn comes out you want to have a managed version available for people.

You can compile with the /CLR switch which will let your code run in a managed environment, it's the magic switch! Now obviously you lose a little bit of performance by doing this, but not by a huge amount at all. Of course porting to managed C++ you will get better speed, but if you wanted a temporary solution when Longhorn is launched this is an option.

Also you can wrap your unmanaged C++ libraries with managed C++ and call from there, which you can take into future consideration. I mean Epic, Valve, iD, etc are not going to be re-writing their codebase to managed code any time soon, but I do think that once Longhorn debuts you will see managed versions by wrapping their existing codebase.

Share this post


Link to post
Share on other sites
One of the biggest issues with Longhorn will be the split up of DirectX. Direct3D will become WGF and be used by the desktop. The rest of DirectX is being split up as well. DirectPlay will be superseeded by the xbox live tools. DirectSound and DirectMusic by XACT and DirectShow by a new media SDK. So DirectX as we know it will dissapear.

Within Longhorn the driver architecture is altered so video card driver code is moved from kernal into user space hopefully to cut down on crashes. The graphic card becomes virtualised so you cannot grab all its resources but must share it with other apps. Apps will write to their own back buffers and then these will be amalgamated to make the desktop.

My concern is that WGF may be driven more by the requirements of the OS fancy effects than games - but I may be being paranoid :)

Another issue is Microsofts desire to make graphics cards provide more similar functionality. So say all WGF 1.0 graphic cards will need to be the same. Microsoft would like to do away with the CAPS flags which is the standard way of IHVs adding their own spins. I just cannot see the IHVs going for this. We will see.....

Share this post


Link to post
Share on other sites
Quote:
Original post by Trip99
Another issue is Microsofts desire to make graphics cards provide more similar functionality. So say all WGF 1.0 graphic cards will need to be the same. Microsoft would like to do away with the CAPS flags which is the standard way of IHVs adding their own spins. I just cannot see the IHVs going for this. We will see.....


The IHVs have no choice in the matter, MS define the standard, they have to work with in it, thats the way it is. Going against the grain and not working with MS just isnt an option as you're competitor would jump in and take all the sales.

Still, theres always OpenGL [grin][wink]

Share this post


Link to post
Share on other sites
I believe most of it is 2006. This info came from the GDCE I attended a couple of weeks ago and I am writing it up for my website at the moment. The roll out of the XBox tools for Windows (under XNA) is happening now and over the next few months. The 'getting rid of caps' thing may be longer term.

Share this post


Link to post
Share on other sites
Phantom - I think you could be right about OpenGL. The IHVs will still be able to provide cool stuff via the extension mechanism but it will not be available to WGF programmers until it is standardised by msoft.

Share this post


Link to post
Share on other sites
Well at the moment my engine dynamically loads a dll which acts as a link between DirectX/OpenGL and the Engine.
So if /CLR will run my dll's on longhorn then all I have to do is rewrite the helper classes. A bummer but I feared worse.
However if WGF will be different altogether rewriting helper classes may become a problem.
Does anyone have an article about the new SDK's?
Also will there be any changes on OpenGL? SDL?

-CProgrammer

Share this post


Link to post
Share on other sites
Quote:
Original post by _the_phantom_
you dont have to /clr your DLLS, they will run just fine as native code with longhorn.

OpenGL will be accessed as before.
SDL will work as before.


Wow now this just amazed me.
Are you serious.
That would mean I have to change almost nothing because I have the game in one dll, engine in another and helper classes in a 3rd.
The exe just creates a window and calls some imported functions.

Amazing. Now will there be any performance loss or the like with the managed dll's?
Oh wait DirectX and the like will probably still be a problem since the old directX dll's probably wont run.
Well then its just the window and the DirectX helper classes, not the end of the world.
I feel much better already.

Thanks everyone.

-CProgrammer

Share this post


Link to post
Share on other sites
Quote:
Original post by CProgrammer
That would mean I have to change almost nothing...
Correct.

Quote:
Amazing. Now will there be any performance loss or the like with the managed dll's?
Not intrinsically. If a user decides to sandbox all unverified applications, then there might be a slight performance hit - but not because of anything you've done.

Quote:
Oh wait DirectX and the like will probably still be a problem since the old directX dll's probably wont run.
Incorrect. Remember, this is why DirectX was built on top of COM, to provide a mechanism for dynamic dispatch. There will be middleware in place to ensure that existing DirectX applications will continue to function.

I mean, you don't really think Microsoft expects everyone to rewrite all of their code, ever?

Share this post


Link to post
Share on other sites
not 100% correct... reading the /clr restrictions, I've found that when using /clr, dllimport and dllexport is not permitted in classes. Since my engine exports classes to be used as the interface with the engine, I can't use the /clr with it


Quote:
Original post by Oluseyi
Quote:
Original post by CProgrammer
That would mean I have to change almost nothing...
Correct.

Quote:
Amazing. Now will there be any performance loss or the like with the managed dll's?
Not intrinsically. If a user decides to sandbox all unverified applications, then there might be a slight performance hit - but not because of anything you've done.

Quote:
Oh wait DirectX and the like will probably still be a problem since the old directX dll's probably wont run.
Incorrect. Remember, this is why DirectX was built on top of COM, to provide a mechanism for dynamic dispatch. There will be middleware in place to ensure that existing DirectX applications will continue to function.

I mean, you don't really think Microsoft expects everyone to rewrite all of their code, ever?

Share this post


Link to post
Share on other sites
Quote:
Original post by vicviper
not 100% correct... reading the /clr restrictions, I've found that when using /clr, dllimport and dllexport is not permitted in classes. Since my engine exports classes to be used as the interface with the engine, I can't use the /clr with it


Quote:
Original post by Oluseyi
Quote:
Original post by CProgrammer
That would mean I have to change almost nothing...
Correct.

Quote:
Amazing. Now will there be any performance loss or the like with the managed dll's?
Not intrinsically. If a user decides to sandbox all unverified applications, then there might be a slight performance hit - but not because of anything you've done.

Quote:
Oh wait DirectX and the like will probably still be a problem since the old directX dll's probably wont run.
Incorrect. Remember, this is why DirectX was built on top of COM, to provide a mechanism for dynamic dispatch. There will be middleware in place to ensure that existing DirectX applications will continue to function.

I mean, you don't really think Microsoft expects everyone to rewrite all of their code, ever?


Yes its the same here. But whats the solution. If all dll's using dllexport dont work, how do I change them so they DO work.

-CProgrammer

Share this post


Link to post
Share on other sites
Quote:
Original post by d000hg
Game developers need C++ in its plain form for the gamecube and PS2 platforms and presumably their successors. XBOX2 and later may run .NET (?) but since PS2 is the biggest console...
Game developers aren't going to port their C++ across to .NET happily - many would possibly just drop the PC.


it could be a pain to support both .NET and unmanaged C++ on other consoles, it could make an engine less portable which we wouldn't want. In truth though it probably won't be too bad as long as you can avoid most specific .NET extensions and compile to different targets.
As far as I know XBox2 doesn't currently support .NET app's although that could be coming with a future release of the XDK.

As for the whole "when will C++ be obsolete?" question, it probably won't in my lifetime, and i'm only 25 [smile] it's used on every/any platform, across almost every operating system. Windows is just one OS even with MONO on Linux thats still only two little OS's in the big bad world of computing... not to mention legacy app's etc.

Andy

Share this post


Link to post
Share on other sites
Quote:
Original post by NineYearCycle

As for the whole "when will C++ be obsolete?" question, it probably won't in my lifetime, and i'm only 25 [smile]

Andy


If we are talking about the obsolesense (sp?) of C++ as a development platform, you are greatly over-exaggerating (maybe I'm missing some humor here?). I fear you underestimate just how quickly computers are evolving. For example, when it comes to straight forward Windows development (not including mobile devices), Assembly Programming is, for all intents and purposes, obsolete. Within 50 years, I think not only will C++ be obsolete as a development platform, but so will C# and probably a language or two after that.

Share this post


Link to post
Share on other sites
Quote:
Original post by CProgrammer

Oh wait DirectX and the like will probably still be a problem since the old directX dll's probably wont run.
-CProgrammer


DirectX will not go away, it will be supported by Longhorn.

Share this post


Link to post
Share on other sites
Quote:
Original post by bL0wF1sH
Quote:
Original post by NineYearCycle

As for the whole "when will C++ be obsolete?" question, it probably won't in my lifetime, and i'm only 25 [smile]

Andy


If we are talking about the obsolesense (sp?) of C++ as a development platform, you are greatly over-exaggerating (maybe I'm missing some humor here?). I fear you underestimate just how quickly computers are evolving. For example, when it comes to straight forward Windows development (not including mobile devices), Assembly Programming is, for all intents and purposes, obsolete. Within 50 years, I think not only will C++ be obsolete as a development platform, but so will C# and probably a language or two after that.


Computer technologies tend to be fast moving, but stay around forever. At my dad's bank, they still use Windows 3.1 and NT, and use a 20 year old mailing system for internal mails. People don't upgrade quick, and I expect the same with major companies who have billions invested in C++ technologies.

Share this post


Link to post
Share on other sites
Quote:
Original post by bL0wF1sH
Assembly Programming is, for all intents and purposes, obsolete. Within 50 years, I think not only will C++ be obsolete as a development platform, but so will C# and probably a language or two after that.


Assembly will never be obsolete (It kind of is important for compiler development among other things.) Of all the languages ever invented, I haven't ever heard of a single one being obsolete.

Share this post


Link to post
Share on other sites
Quote:
Original post by CProgrammer

Yes its the same here. But whats the solution. If all dll's using dllexport dont work, how do I change them so they DO work.

-CProgrammer


As far as I know, the only way would be to write a managed wrapper around the unmanaged class (or make the class itself managed, ie, put a __gc or __value tag in front of it). With assemblies, anything that's managed and public is exported automatically, and the rest of it is hidden.

Share this post


Link to post
Share on other sites

This topic is 4832 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this