Windows Longhorn and Game Development
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.
Quote:Original post by Trip99Which differs from the current situation how?
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.
Because nowadays IHVs can badger Msoft to add a specific CAPS flag to a point release of the SDK.
Author
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
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
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.
OpenGL will be accessed as before.
SDL will work as before.
Author
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
Quote:Original post by CProgrammerCorrect.
That would mean I have to change almost nothing...
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?
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 OluseyiQuote:Original post by CProgrammerCorrect.
That would mean I have to change almost nothing...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?
Author
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 itQuote:Original post by OluseyiQuote:Original post by CProgrammerCorrect.
That would mean I have to change almost nothing...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
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
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement