Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

Geek Culture / DBPro and Managed DX

Author
Message
Sonic
22
Years of Service
User Offline
Joined: 10th Sep 2002
Location: UK
Posted: 10th Nov 2003 05:06
So called facts:
If one is to believe Microsoft's DX team, Managed DirectX 9 is only 2% to 5% slower than native Win32 code.

Microsoft are actively pushing the RAD tool angle to games develoment houses.

Microsoft recommends that future engines should be built again from the ground up to take advantage of this slower speed "Yeah but you'll have the game out by Xmas with all those features you wouldn't have time for otherwise. Besides, PCs are getting so fast now....blah".

The only real downsides then is the very slight performance hit and the fact that games would need to go out with a DX redist AND the .NET Framework.

An opinion:
From what I've gleened, Managed DX is a pretty major dumbing down of the DirectX API. No longer do you need to subclass the SDK examples to find the elusive X model or bitmap loaders, its all there ready for you by way of the framework objects, at the flick of the intellisense. Not only that but assuming you use VB.NET or C# then your code is only fractionally slower than native C++. C++.NET? Why bother unless you have very specific requirements!

One would think that this will open up DirectX and D3D programming to an even wider potential audience than the ActiveX Control version for VB shipped with DirectX 7.

Questions:
Although vastly cheaper and simpler than Visual Studio, since Microsoft have rolled out Managed DirectX 9, isn't DBPro in danger of colliding somewhat with C# or VB.NET as a popular very-high-level RAD language for developing games?

Also, is one to presume that C++ is under threat as the games programming language of choice if Managed DX becomes popular. Not that you can't program managed code in C++ of course, but C# would appear to be made for the job.

And will that mean that "native code gurus" currently coding in C++ for the various platforms will now need to re-skill in the .NET framework and scap their old engines to keep up with the new generation? I bet they're chuffed!

And ultimately, would this mean that aspiring games coders would do well to learn Managed DX as a valid entry point to game programming employment.

Or will the touted 5% speed increase always tempt games development houses away from managed code?

Questions, questions.. any answers or opinions?

"My ignorance amuses me..."
http://www.victory-road.co.uk
CattleRustler
Retired Moderator
21
Years of Service
User Offline
Joined: 8th Aug 2003
Location: case modding at overclock.net
Posted: 10th Nov 2003 05:21 Edited at: 10th Nov 2003 05:22
I didn't read your whole post - I will, but was sleepy at the moment. regardless of %'s, the managed code stuff is going to be "forced" one way, sooner or later -- LONGHORN is managed .NET objects so anyone who intends to use the new OS is forced into managed/.NET. better? worse? I dunno but changes they are a' comin'

again I didn't read your post yet - just a thought - as muttled as it may be

-RUST-
MicroMan
21
Years of Service
User Offline
Joined: 19th Aug 2003
Location: Stockholm, Sweden
Posted: 10th Nov 2003 06:50
I've already seen a couple of them scoff att .Net in the netzines out there, so it's not that far fetched that they are chafing in their collars right now. But what to do? What to do?

As long as Microsoft has 95 percent of the OS market in the western world, particularly in the segment that matters as far as games are concerned, they can pretty much decide what they want and the industry, short of a user revolt to Mac or Linux, will have to follow unless they want to feel how it is not to have gainful employment.

I've looked at the VB .Net side of things tonight while I'm waiting for an animation to finish rendering, and I kind of like what I see about the new .Net VB. If it wasn't so expensive I would probably buy it. Perhaps when one of my apps get really big and sell a million copies, lol.

But I see problems there as well. I see problems there as well...

cheers,
Microman

-----
They SAID that given enough time a million monkeys with typewriters could recreate the collected works of William Shakespeare... Internet sure proved them wrong.
-----
Shadow Robert
22
Years of Service
User Offline
Joined: 22nd Sep 2002
Location: Hertfordshire, England
Posted: 10th Nov 2003 07:06
Managed .Net code is just the overhaul of COMs for the Compile on Demand Windows age.

The reason it's almost as fast as Native DirectX is actually because it compiles specifically for that machine when you run it... and though 2-5% may not seem like much to you, this is actually a huge speed difference in terms of gaming.
Remember this is 2-5% per function call, so although it is comming close to DirectX speeds what you end up with is something actually very close to the speed of DarkBASIC Pro.

It can trounce Visual Basic's 3D ... but next to Native Coding that performance distance does add up and very very quickly.
And personally I hate Manage coding, as it's like VB

Object Orientation gone mad, i'm happy with only one or two object levels not 20 blumming something.


To Survive You Must Evolve... This Time Van Will Not Escape His Fate!
900mhz | 256mb | FX5200Ti 52.16 | Dx9 | WXP-Pro
MicroMan
21
Years of Service
User Offline
Joined: 19th Aug 2003
Location: Stockholm, Sweden
Posted: 10th Nov 2003 10:16
And another question is, where exactly is the speed gain? In the math functions or in the jumping around? Most computer programs spend 80-90 percent of their time jumping around from place to place, and only perhaps ten percent on the juicy bits. If the speed gains are in the code shifting parts, then it's not really going to amount to much...

Code gets 2-3 percent faster to that subroutine, and then spends just as much time calculating a complicated shader operation... I don't know if we've won that much. But then again, I don't know what they say exactly, so I can't really tell.

-----
They SAID that given enough time a million monkeys with typewriters could recreate the collected works of William Shakespeare... Internet sure proved them wrong.
-----
Sonic
22
Years of Service
User Offline
Joined: 10th Sep 2002
Location: UK
Posted: 10th Nov 2003 22:49
Quote: "Object Orientation gone mad, i'm happy with only one or two object levels not 20 blumming something."


I hear ya and that is what I was most interested in. Microsoft would argue that they met a deal of resistance from the Game Dev community when DirectX first came out (probably because it was crap but still...) and that sort of view is to be expected.

Its likely that Microsoft will push this technology very hard indeed and its interesting that a Framework target language like VB.NET or C# when used with Managed D3D is not much more complex to program that DarkBASIC yet would yeild result similar to native C++ code (apparently).

In some ways VB.NET could be easier if you're using VB.NET/C# for day to day stuff as well.

Managed code could put the aging C++ in the shade somewhat as unless you're wanting to do the stuff that managed code does for you, why would you bother as you'd at least have to learn all the new Managed stuff to get your app off the ground. And you can throw that Native Code engine away while you're there as well! Why not just switch to C# as you're gonna end up with the same byte code anyway?

"My ignorance amuses me..."
http://www.victory-road.co.uk
CattleRustler
Retired Moderator
21
Years of Service
User Offline
Joined: 8th Aug 2003
Location: case modding at overclock.net
Posted: 10th Nov 2003 23:33 Edited at: 10th Nov 2003 23:34
There is a managed/unmanaged boundary - all of the original classes are there so the developer doesn't have to relearn a whole slew of dx syntax, and it is possible to add managed pieces to existing unmanaged code so you don't have to scrap entire works. MS does mention, however, that it is recommended to do a full ground-up rewrite as opposed to trying to "port" something from unamanaged to managed.

Since longhorn is a while off in the future it's not critical for gaming houses to get into the managed dx stuff "today", but with the length of development cycles for some of these games, the game house should seriously start considering implementing the new version of DX (Managed .NET). Oh yeah, not to mention that the new OS will be 64bit as well.

Interested to see which development houses take the plunge first...
(I am sure they are all looking at already whether or not they admit it publically)

-RUST-
Shadow Robert
22
Years of Service
User Offline
Joined: 22nd Sep 2002
Location: Hertfordshire, England
Posted: 10th Nov 2003 23:59
people will always use C++, no matter if Microsoft try to phase it out ... the difference is they've created a standard with Visual C++ and like it or not, it's simplicity over the other language is actually what is preffered.

There isn't alot of support for Python and Visual Basic is used for it's RAD abilities, in a way so is C#.
However if everyone were as jazzed about the Hyper-OOP C# w/Managed DirectX as Microsoft would like to believe, then we'd actually all be using DirectX COM right now.

Fact of the matter is, programmers prefer everything to be more basic sometimes without sarificing thier connection with the Low-Level. And thats what Managed Code does unfortunately.
I can tell you this for nowt, although Software Development houses for applications will change over - there is no doubt about that, i'd bet a small fortune that the game dev community will shun it just like they've shunned other changed suchas GUID and .Net controls.

Game Dev your suppose to get your hands dirty in the engine, not keep them squeaky clean uptop ... Microsoft will no doubt find like with DirectX, people will be reluctant to change without being force, and if they are - then it is greatly possible that alot of houses will either stick with the lower specification that supports what they want (Dx7.0 <- Dx8.0 was a great example of this) or they will switch over to OpenGL.


To Survive You Must Evolve... This Time Van Will Not Escape His Fate!
900mhz | 256mb | FX5200Ti 52.16 | Dx9 | WXP-Pro
Sonic
22
Years of Service
User Offline
Joined: 10th Sep 2002
Location: UK
Posted: 11th Nov 2003 01:34
Interesting, so CattleRustler you seem to be of the opinion that, in the longer term, Game Dev houses will need to ultimately scrap their existing engines (as MS advise) and rewrite in managed code (maybe C#??), wereas Raven, if i undertsnad correctly, is willing to bet a small fortune that the Game Dev community will shun Managed Code altogether and would prefer to move over to OpenGL if they have to in order to maintain control over their code.

So we have two scenarios:

1) The Game Dev community embrace Managed DirectX, and therefore Managed framework code in general, and reap the touted rewards in
increased productivity at the expense of control and speed.

2) The Game Dev community shun this automatic memory management model and fly directly in the face of the whole new Microsoft Software ethos.

My questions would then be:

If "1" is true then doesn't C++ get replaced by C#?
If "2" is true then well, what happens when everyone is using Longhorn, what happens when DX10,11, 12 comeout boasting lush new features and effects-for-free. What happens when you can write killer apps but no-one buys them becasue they are using an OS that is only to be programmed for in a managed fashion?

Maybe you are both right, perhaps Game dev is about to be split down the middle, perhaps we'll see box art with "100% Native Machine Code" written on in large gold letters to distinguish one game programming method from the other.

My (limited) view is that Microsoft have seduced the game community with DX now. They can do what they want. They could start charging for dev kits or licenses. In actual fact they are saying "move in our direction or ultimately lose this tool you've come to rely on".

Wouldn't it be a turn of events to see the MS OS get stabbed in the back by the game Devs as they scuttle off to write fast code under OGL, and when managed only Longhorn is released then all the serious gamers have switched to linux and are enjoying the full power of their expensive graphics cards/Memory cards.

"My ignorance amuses me..."
http://www.victory-road.co.uk
CattleRustler
Retired Moderator
21
Years of Service
User Offline
Joined: 8th Aug 2003
Location: case modding at overclock.net
Posted: 11th Nov 2003 03:07
Yes this is all very interesting. But I am not in any debate with anyone about anything. I just found it incredibly exciting that I was programming in VB.NET and I was making neat stuff happen on the screen (albeit from an SDK tutorial) from a DX9 Class that wasn't a COM object. It was just like when I made a cube spin for the first time in DBP .I have been singing the praises of OOP on these forums for a while (maybe too much) and although I love DBP I wish it was more OOP-Oriented (but that's just my tastes/don't start the whole DBP-OOP discussion again, please) So now what I am seeing in front of me is the tools to program DirectX games, but in my new native language VB.NET. The other stuff I mentioned was stuff I heard, read or inferred - just as general info. The whole reason I bought dbp was because I couldn't program in C++/DX but now I can, in a true OOPL on par with C++ and C#

All just MHO
Thanks

-RUST-
Shadow Robert
22
Years of Service
User Offline
Joined: 22nd Sep 2002
Location: Hertfordshire, England
Posted: 11th Nov 2003 03:46
well personally i know what i like... and to be honest what the Game industry uses really speaks for itself.

A Games Programmer will always choose C/C++ over any other language, this is really a given. Whereas an Application Programmer will choose C#/Visual Basic.

The question is why?
Well for an application developer, speed and system access isn't a priority. What is on thier agenda is RAD, Rapid Application Development.
These guys want results and they want to see them working within hours and days... As long as the application is simplistic to access from all areas then they're happy bunnies.

However on the other hand we have a game developer. What is most important to these guys is being able to access every aspect of the system to squeeze every last drop of speed out of it, to meet the demands of thier artists. They also need more simplistic levels of coding.

Oki so the last statment might seem a contradiction in terms when comparing C# w/Managed Dx to C++ w/Instance Objects ... but is it?

To an application developer oftenly you only have to worry about one task at a time, ie Linking a Database to the CodeSence or such things. So working around 20odd object layers seems like childsplay to remember, right?
Difference with a games programmer is what they're doing is trying to tie together 20odd layers at the same time as is.

So when you get to having to remember what object is to what, not to mention your own objects and you end up with entire lines which are just a single object instance ... well to put it mildly, both types of programmers are worrying about different things and a different number of interactions at any given time.

So a games programmer craves a more intuative language, whereas an application programmer will crave a better linked language.

Hopefully you can understand my point here, on why i believe that Managed Dx isn't going to become a standard.
For a games programmer to be honest, it is just to damn complicated and requires remembering far too much.

There are more important things to remember and be thinking about in a game engine than "does the dxinstance.object.mesh.shader object have an array or lettered object extentions?!"


To Survive You Must Evolve... This Time Van Will Not Escape His Fate!
900mhz | 256mb | FX5200Ti 52.16 | Dx9 | WXP-Pro
MicroMan
21
Years of Service
User Offline
Joined: 19th Aug 2003
Location: Stockholm, Sweden
Posted: 11th Nov 2003 04:22
Possibly, then maybe not. The game engines do have a lifespan, after all. The shift to managed code needn't happen tomorrow, but it may take a few years as the lifespans of the game engines go out. In the continual development work the base for the game engines may incorporate managed code.

Trying to predict the future three or four years ahead in the computing business is like trying to predict what the world will look like in five hundred years.

Coming from an app background, I wish there was more app-like stuff because then I would feel more comfortable. But that's just my feeling, and not necessarily my logic. And as the computers keep doubling their speeds within an eighteen month span all the time, perhaps an app-like structured approach to coding will become necessary rather than the seat-of-the-pants-give-me-all-options-now-or-my-code-will-be-horribly-slow approach will die out because of the complexity reasons that faster computers and higher requirements on content will bring.

cheers,
Microman

-----
They SAID that given enough time a million monkeys with typewriters could recreate the collected works of William Shakespeare... Internet sure proved them wrong.
-----
Shadow Robert
22
Years of Service
User Offline
Joined: 22nd Sep 2002
Location: Hertfordshire, England
Posted: 12th Nov 2003 00:58
yeah but no matter how fast hardware engineers give us speed... us game developers find a way to increase the demand on that speed 10fold ^_^

what is ever edged towards is every more details and interactive worlds giving a more full on game experience, be the technology is capable of handling it or not.

Tomb Raider back in '96 was a good example, and Angel of Darkness Recently was another very good example.
Developers always want to push the bounderies and as such we need as much control and speed as possible...

as i've said, don't doubt some companies will - but in general everyone is actually extremely happy with development as is.
As Shaders are being introduced, the reason they're being embraced so readily is because they actually bypass the graphics drivers for the larger part and give developers once again FULL access to the Graphics Processor
This is what DirectX was suppose to do in the first place, and by making it managed actually heads DirectX one step backwards to what it was originally intended to do.


To Survive You Must Evolve... This Time Van Will Not Escape His Fate!
900mhz | 256mb | FX5200Ti 52.16 | Dx9 | WXP-Pro
Sonic
22
Years of Service
User Offline
Joined: 10th Sep 2002
Location: UK
Posted: 12th Nov 2003 03:37
Quote: "by making it managed actually heads DirectX one step backwards to what it was originally intended to do.
"

I have to agree here - DirectX was introduced to encourage/aid game devopment through windows as the overhead of windows was a problem.

By making it managed, it is putting itself at odds with that totally.

Perhaps Managed DX will go the road of D3D Retained Mode, as in it gets you up and running quickly but you wouldn't actually use it to write a game!

"My ignorance amuses me..."
http://www.victory-road.co.uk
CattleRustler
Retired Moderator
21
Years of Service
User Offline
Joined: 8th Aug 2003
Location: case modding at overclock.net
Posted: 12th Nov 2003 06:41
I think you guys might be underestimating the power and purity of the .net framework as a platform, as opposed to com. Remember this is just the first step towards a new thing that could benefit all of us - I know it's already benefitting me...2 days ago I knew squat about directx, let alone being to write vb code for it, now its like...



I mean, ok, it's a spinning triangle, from a tutorial but you know what - I am a hell of alot closer to my personal goals because of what ms is doing these days. Don't get me wrong I am NO fan of ms, in fact I fought with some skank on the phone who was trying to charge me $1700 for the Visual Studio .NET Ent. Arc. UPGRADE which was selling on their site for $30 a couple of months ago!! (Those money grubbing, blood sucking, rat b*stards!) Anyway all I can say is this is their first step. So what if right now there is a 2-5% performance hit. Who's to say that in 2-3 years that couldn't be down to under 1% or negligable, then would managed .net dx suffice? I think people are going to stick with what they know-for as long as they can, it's only natural - a comfort zone. But again, I'd like to see what happens over the next couple of years as the new os approaches release and the managed dx stuff get more and more refined. It may fail, it may not - time will tell.

-RUST-
MicroMan
21
Years of Service
User Offline
Joined: 19th Aug 2003
Location: Stockholm, Sweden
Posted: 12th Nov 2003 11:29
I honestly don't care what language I use, as long as the language doesn't get in the way of my creativity, either by forcing me to pay attention to it or by hindering me from doing what I want to do... If managed code will help me write games, I'll cheer it on, and from what Cattlerustler says it will probably do that.

Different people have different focuses. Some admire the elegance of code, while other want to create a good game feeling and tell a good story. I'm definitely in the latter category. I just want to make this game I've got in my head, and if a wooden pallet and a chisel would help me do that in a good way I'd use the wooden pallet and the chisel in a heartbeat.

I'm looking into Visual Basic .Net for the reasons Cattlerustler has mentioned here and before, because it seems to be a hefty improvement over the old version -- which was only good for apps after all. I'm used to VB, and think it a fair language. I'm learning to like Pascal more and more because it too is a fair language.

Neither is without flaw, but one could find flaws in anything. There are definite flaws in C++ too. It's all a matter of your personal taste and personal attributes, I think. C++ is best for some, while for others it would be a lesser choice.

I know in what category I fall, and I think it would be smart for people to drop the defensive posture for their pet tools and ask themselves what their work goal is, and then choose the tools that will get the work done in the best way. If managed code is a good tool to use for some people, then by all means lets have managed code.

On the other hand, let's not have it for those that don't like it. The computer games biz is a big place and spans five continents. I'm sure there's room for everyone.

-----
They SAID that given enough time a million monkeys with typewriters could recreate the collected works of William Shakespeare... Internet sure proved them wrong.
-----
kingius
22
Years of Service
User Offline
Joined: 16th Oct 2002
Location:
Posted: 12th Nov 2003 13:39
The move to managed code is really driven by security. Anyone remember the critical flaws in direct X that were patched recently?

The CLR is able to prevent buffer overflows because it checks every single buffer in a managed program, so the programmer doesnt have to.
CattleRustler
Retired Moderator
21
Years of Service
User Offline
Joined: 8th Aug 2003
Location: case modding at overclock.net
Posted: 12th Nov 2003 17:23
well said MicroMan.

To each his own.

-RUST-
IanM
Retired Moderator
22
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 12th Nov 2003 19:58
As the JIT compilers improve for managed code, the difference will disappear.

There is also the future possibility that managed code will also start to run faster than directly compiled code.

Directly compiled code is limited in that you cannot compile your code to produce optimal machine code for every machine out there. If the managed code is compiled on your machine (JIT), it has the opportunity to know everything about your machine and produce the optimal code for it.

I think that making up your mind on the managed code subject is very premature at this moment.
CattleRustler
Retired Moderator
21
Years of Service
User Offline
Joined: 8th Aug 2003
Location: case modding at overclock.net
Posted: 12th Nov 2003 20:07
exactly

-RUST-
heartbone
22
Years of Service
User Offline
Joined: 9th Nov 2002
Location:
Posted: 12th Nov 2003 20:46 Edited at: 12th Nov 2003 20:50
IanM: "I think that making up your mind on the managed code subject is very premature at this moment."

Consider this, all programming is based on binary, the rest is just extensions. There are important considerations here other than purely technical. Considering the source of the managed code directive, the motivations of and the history of that entity, I feel secure in making up my mind about the concept of 'managed code'. Or for any other proprietary programming 'convention' proposed for corporate profit and the exclusion of alternatives.

The more you see, the more you know.
The more you know, the more you see.
Shadow Robert
22
Years of Service
User Offline
Joined: 22nd Sep 2002
Location: Hertfordshire, England
Posted: 12th Nov 2003 21:09
well i can tell you for a fact the guys here hate Managed Dx, but then as far as they're conserned they're now using an OpenGL OpenAL Engine based from WarcraftIII's for thier current projects.

But that said it's how we all end up programming, and alot of game developers just don't like Managed Dx ... even slightly.
For the exact same reasons they will not touch VB with a 10ft Barge Pole.

Sorry, you guys might love it, and feel it increase development speed and such ... but its like the difference between and Automatic and Manual Car.
The Auto Might reach the same speeds as the Manual, but there are just a few things you cannot achieve in an Auto ... and the worst part is that in a few cases you can feel "out of control" of the vehicle. Although you can't literally ever be in full control, it's a matter of priority when your hurtling down a racetrack at 150mph+ that you never feel "out of control".

perhaps that will explain it better


To Survive You Must Evolve... This Time Van Will Not Escape His Fate!
900mhz | 256mb | FX5200Ti 52.16 | Dx9 | WXP-Pro
Kevin Picone
22
Years of Service
User Offline
Joined: 27th Aug 2002
Location: Australia
Posted: 12th Nov 2003 21:25
"well i can tell you for a fact the guys here hate Managed Dx, but then as far as they're conserned they're now using an OpenGL OpenAL Engine based from WarcraftIII's for thier current projects."

Three questions..

1) Who are these guys.. ??
2) Where is 'here' meant to be ??
3) What projects ??



Kevin Picone
Play Basic - Visible Worlds - Kyruss II
[url]www.underwaredesign.com[/url]
Shadow Robert
22
Years of Service
User Offline
Joined: 22nd Sep 2002
Location: Hertfordshire, England
Posted: 12th Nov 2003 21:29
1) pass
2) pass
3) pass

^_^ ... you remember last time i happened to say where i worked, don't want that whole bag of chips again as it was a nightmare


To Survive You Must Evolve... This Time Van Will Not Escape His Fate!
900mhz | 256mb | FX5200Ti 52.16 | Dx9 | WXP-Pro
Kevin Picone
22
Years of Service
User Offline
Joined: 27th Aug 2002
Location: Australia
Posted: 12th Nov 2003 21:33
What a surprise.. You could also email me. I'm a curious soul

Kevin Picone
Play Basic - Visible Worlds - Kyruss II
[url]www.underwaredesign.com[/url]
Shadow Robert
22
Years of Service
User Offline
Joined: 22nd Sep 2002
Location: Hertfordshire, England
Posted: 12th Nov 2003 21:40
lol oki i'll email you later when i finally get the hang of this computer and can find the email thing


To Survive You Must Evolve... This Time Van Will Not Escape His Fate!
900mhz | 256mb | FX5200Ti 52.16 | Dx9 | WXP-Pro
IanM
Retired Moderator
22
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 12th Nov 2003 22:31
@Heartbone,

I have no concrete views on managed code at the moment - I haven't used it seriously enough yet.

But consider this ... although MS was the driving force behind this managed code idea, the analysis and design of that code was handed out to a third party.

Also consider that MS has effectively 'given away' VM and compiler source code for third-parties to use and abuse as they wish ... this bandwagon may be too big to be controlled by a single entity, even one as big as MS.

I guess we'll just have to wait and see how it turns out.
Sonic
22
Years of Service
User Offline
Joined: 10th Sep 2002
Location: UK
Posted: 12th Nov 2003 22:46
"Wait & see", "each to their own", are all valid and wise words and I admit I'm kinda on the fence myself

MS has released alot of info and teh SDks are out for this stuff so I'm hoping soe sort of an informed opinion might be reached.

I can see why Managed DX would attract a small development house or an Indi (much like many of the guys and gals here) in that it could offer improved productivity. Plus you could leapfrog years of hard work by established developers in building their low level classes by adopting a more modern language and approach to achive comparable (at present) results.

By the same token I can see Raven's point about a dedicated professional team's reluctance to go this way. If it aint broke why fix it? For sure there are many unaswered questions about Managed DX anyway. Can MS point at ONE SINGLE medium/large game made using
that technology? No they cannot.

But times do change. Maybe machines are fast enough now that the focus is less on speed of draw and more on how it all feels and plays. Ok I did say MAYBE!

In 2 versions of DirectX (7 to 9) we've seen the back of D3D Retained mode, DirectDraw get dropped and came back, inclusion of shaders and to cap it all several brand new never-seen-before programming languages (VB.NET, C#, J#).

If it's true that JIT compilation could have an ultimate advantage, if you add to the fact that "100% Managed Code" on the box could sound every bit as sexy as "100% Machine Code" to the average punter then perhaps the (understandable) objections by the big names might start to drop away. Perhaps they have a method to compile to various platforms, Managed DX might just be one of them (I think Renderware has this ability?).

I confess I've done very little D3D Coding myself, just a little in VB6 (lol - how quaint eh? Bless) but comparing the Managed VB.NET snippet posted above (which compiled to 12K BTW) against a similar app written in C++ & D3D8 then, apart from the Windows stuff (WinMain & WinProc), they do appear to be pretty similar and doing the same things.

On the .NET side you have type saftey objects used (via nice intellisense) and on the native side you have obscure (to me) Constants defined in some header file you never see.

The info from MS seems to be that, unlike Retained Mode, Managed D3D allows access to everything so one might have to start to question the "loss of control" argument. Assuming MS have done as they've said, what exactly do you lose control of?

Not to draw any conclusions or anything but if we imagined, for a moment, that Managed DX became really popular, maybe first with Indi's and then up the chain to the big boys as the versions improved it, then we end up in a situation where poor old DarkBASIC Pro is left vying for position in a RAD marketplace now competing almost directly with Microsoft, and C++ is seen as surplas to requirements in a similar way that many regard ASM as not worth the bother now. It would also be worth noting that in this scenario products like DarkBASIC would feel the pinch first.

Not that DBPro hasn't got LOADS going for it, including price, but as an Indi, wouldn't it be nicer to use the same language you do for your business appz to create games rather than learn a propriatory version of BASIC that is not really suited to other kinds of App development than games.

Hehehe, now I sound like an MS fanboy, just an observation, feel free to flame...

"My ignorance amuses me..."
http://www.victory-road.co.uk
MicroMan
21
Years of Service
User Offline
Joined: 19th Aug 2003
Location: Stockholm, Sweden
Posted: 13th Nov 2003 02:14 Edited at: 13th Nov 2003 02:16
We might reach some sort of "consensus" on this thing by looking at another field entirely, if the comparison is applicable. Look at what happened in the motion picture industry with the advent of the usable video camera.

There were guys and gals, and still are, that swear loyalty to the good and trusted old 70 mm film and say that no decent movie can be done without them. And to a certain point they are correct. In the hands of a master a 70 mm film easily technically outstrips anything produced on video.

But does that mean that video is bad for the movie business? Does it mean a dilution of the movie business? Of course not. It's meant a revitalisation of the movie business in many parts of the world where producing 70 mm film is just prohibitively expensive, and where the technical challenges of such a production are just to great competencewise.

But filmmaking like gamemaking, IMHO, has nothing to do with the underlying technology. None of us goes to the movies to admire the creative uses of blue filters on that dolly shot in the canyon. None of us I would think loads a game to examine in detail the technical aspects of the game making solution. They are incidental to the experience of the medium.

I would argue that the advent of video in the movie business has meant that a lot of great story tellers and great filmmakers have gotten a shot -- people that aren't great technically but who are great visually.

For that reason I think that managed code may -- and I'm still a bit on the fence yet -- be something similar. Perhaps it will allow people that are great at making game experiences to emerge, despite the technology.

And I, for one, think that would be a great thing.

-----
They SAID that given enough time a million monkeys with typewriters could recreate the collected works of William Shakespeare... Internet sure proved them wrong.
-----
Shadow Robert
22
Years of Service
User Offline
Joined: 22nd Sep 2002
Location: Hertfordshire, England
Posted: 13th Nov 2003 06:39
you right Microman... it is... and as such the industry will always use what it prefers and perceives as the best whilst the home user will always use what is easiest and most accessable.

this really has little to do with Dx to be honest, this has more to do with Microsoft wanting people on THIER systems only.

Swapping from C++ to C#
Swapping Dx from an C++ DLL format to a .Net DLL/WHQL format

They've seen that Dx is finally leaking onto Linux and they want to put a stop to it, whilst trying to make out that they're making development easier for everyone. When truely what they're giving are developers a harder time with the Development Cycle.

People said with C there is no reason for ASM
People said with C++ there is no reason for C
Now its being said with C# there is no reason for C++

But we still use ASM, we still use C, we still will use C++
Hell BASIC is now seriously outdated, but just look at how strong it is now.

C# SHOULD be the replacement of Visual Basic, there are no two ways around it... but C# even with Managed .Net still is too slow and complex for some companies (dev wise), so they stick to Visual Basic.
Game companies like the low level of C++, they also like the lowest level of ASM.

Neither are going away anytime soon - and unlike C++ Microsoft can't just make thier own version that offers improvements for thier OS this time. They can't simply offer the token Developers Library.
This time they have to SHOW why it is more viable and better to program games in a language so foreign to console development and totally platform dependant that it will be worth while developers getting into it.

That's why i'm confident that Managed Dx will never catch on in games, your sacrificing far too much far too quickly. The Industry thrives on change, but this is just too much... is as big a leap as DX was in the first place.
Perhaps not from the adverage Joe pov, but from the developers it is.

a new language, and new setup for dx to learn and remember, a new layout to understand and a new way to program that needs to be learnt.


To Survive You Must Evolve... This Time Van Will Not Escape His Fate!
900mhz | 256mb | FX5200Ti 52.16 | Dx9 | WXP-Pro
CattleRustler
Retired Moderator
21
Years of Service
User Offline
Joined: 8th Aug 2003
Location: case modding at overclock.net
Posted: 13th Nov 2003 07:02
Raven, you speak of VB like we are still using VB4! You really haven't kept up on it's improvements from 5 thru .net, have you?

"C# should replace VB, no two ways around it"

WHAT! VB.NET and C# are the same! Where do you think the Common Language Runtime and Managed Code comes from? how it's possible? Because the languages are the same, operating against all the same bass classes, only diff being the syntax. C# is for C++ guys to be comfortable, VB.NET for VB guys to be comfortable - end of story. When C# is compiled and VB.NET is compiled, the output is EXACTLY the same.

I am not trying to attack you or start a flame war but please stop trashing vb when, out of all the topics you seem very knowledgable on, vb's advancements over the past 3 versions (5,6,net) isn't one of them.

-RUST-
las6
22
Years of Service
User Offline
Joined: 2nd Sep 2002
Location: Finland
Posted: 13th Nov 2003 08:58
Quote: "None of us goes to the movies to admire the creative uses of blue filters on that dolly shot in the canyon. None of us I would think loads a game to examine in detail the technical aspects of the game making solution."


I wouldn't be so sure about that...

Keyboard not detected. Press F1 to continue.
MicroMan
21
Years of Service
User Offline
Joined: 19th Aug 2003
Location: Stockholm, Sweden
Posted: 13th Nov 2003 14:32 Edited at: 13th Nov 2003 15:31
@Raven
Well, we disagree. I don't think it's important what tools you use as long as you get the job done. If that tool is c++ or VB .NET (which IS a very strange beast) is beside the point. If that tool is managed code or not is also beside the point.

Games are narratives, not technology. Whatever tells the story best decides the tools, and you got to have people to tell stories, and the people with the best stories tend to be the ones that can't be bothered with spending five years learning the API structure of Windows before they can even START to think about getting their ideas out of their head.

I think you should take a look at VB .NET. I've been playing around with it on my friend's laptop for a few days now, and even though I'm thoroughly confused and recognize little from the previous version, I've learned this.

There is the compiler, and it has three user interfaces: C++, C# and VB.

It doesn't matter which user interface you choose. It doesn't matter at all, because whether or not you choose to put C++ or VB into the compiler at the front, what comes out at the back is the same thing. All the three languages use the same runtimes, the same library. Language choice has become a matter of taste in Visual Studio .NET.

Nothing more.

-----
They SAID that given enough time a million monkeys with typewriters could recreate the collected works of William Shakespeare... Internet sure proved them wrong.
-----
IanM
Retired Moderator
22
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 13th Nov 2003 15:19
@Raven, I don't think you read my previous post ...

The VM and compilers for managed code has been given away (excluding the optimisers - which means nothing when you port to a new processor). How does this force you onto a MS platform? There are many platforms having VM's written for them, including the MS arch-enemy, linux.

I actually think that this is MS's way of widening their audience for their applications rather than their platforms.

I've also been playing about with a bit of managed code myself today - mixing it in with good-old-fashioned C++ native code
CattleRustler
Retired Moderator
21
Years of Service
User Offline
Joined: 8th Aug 2003
Location: case modding at overclock.net
Posted: 13th Nov 2003 16:22 Edited at: 13th Nov 2003 16:25
right, there is such a thing as managed C++, incase anyone was wondering. You need not switch to C# if you are a hardcore C++ guy although the switch would be pretty painless from what I can see. Also, ms has been saying all along that .NET, since its basis and structure is preserved across XML, cross-platform operability was one of the main focuses in the first place.

@MicroMan, if you need anything in the way of vb.net I am always around to help. Have you the dx9sdk yet? It's a huge dload but it's well worth it (if you are on broadband).


-RUST-
Shadow Robert
22
Years of Service
User Offline
Joined: 22nd Sep 2002
Location: Hertfordshire, England
Posted: 14th Nov 2003 00:33
CattleRustler i have VB 3,6 & 7 and although i can see the large jumps between them all... the coding structure is the biggest enemy.
It's not because the actual language setup is particularly bad for low level stuff (although it doesn't give you access to coding in C or ASM for given instances where i would help development), it's more a case that you don't have a DIRECT control over the source.
sure you can edit it through the form source, however there is no direct coding in the same way that C++ has.

And really when your programming at such a level the language's BASIC nature does get in the way, becuase to make an action easier to achieve doesn't always mean making it more BASIC but just simplifying howto achieve it... there are quite a few instances where C++ is actually far easier the BASIC to achieve things, it might not be a single command for a tonne of commands ... but thats what allows you to keep control.

And Managed C++ isn't C++ - i'm sorry but it's C#, whatever face you wanna put on it ... it is no longer C++ structure and use. Sure i'll compile using C++ .Net ,but thats because it is capable of coding in C# that's all.

And although C# does combine the best of both VB and C++, honestly it is horrible to use for games development. Personally I feel like i'm handing over depth and control to the computer on what to do.
If i wanted to do that i'd program everything within DBP.

This is nothing against DBP, but really thats the level of how everything is being cut back.
And I'm aware that the VM will run on Systems rather than OS's ... however you STILL require the .Net Framework present for them to work, which isn't freely available.

Kinda like how Microsoft have allowed WinAPI out, yet MFC is still closed to them.
You can use one without the other, but MFC has alot more power and far simpler to utilise.


To Survive You Must Evolve... This Time Van Will Not Escape His Fate!
900mhz | 256mb | FX5200Ti 52.16 | Dx9 | WXP-Pro
CattleRustler
Retired Moderator
21
Years of Service
User Offline
Joined: 8th Aug 2003
Location: case modding at overclock.net
Posted: 14th Nov 2003 00:50 Edited at: 14th Nov 2003 02:26
<place holder>
i don't have time at the moment but I will be back

EDIT UPON RETURN:
I read Ian's post below and then raven's below his...

As far as Raven is concerned, sorry but I have not the energy.
As far as IanM, thank goodness for him on these forums, in all respects-helpfulness, intelligence, sensibility etc

...that's not to say Raven is wrong/right or anything I just like IanM's way of thinking and non-preachy style of communication, where certain others tend to try and "tell you" as opposed to "speak with you"

-RUST-
IanM
Retired Moderator
22
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 14th Nov 2003 01:30
Nope, C++ using managed code is *not* C#. They may look almost the same, but under the hood they are chalk and cheese.

Create a native code app, switch on managed code support, import the .NET interfaces ... only two more steps than if you were using standard C++.

You can then combine your unmanaged code with managed code on your own terms, accessing managed code from unmanaged (and vice versa) invisibly (the famous 'It Just Works' ... and it does!) Everything works (with the exclusion of multiple inheritance).

As far as VC++ is concerned, managed code is just another linkage type. Enable assembly output, and you can even check out for yourself that it's native code being produced. It's not really any different than using COM, except that it's actually easier to use.

Yes, the .NET libraries are closed source, but the interface is so well defined that anyone who would be involved in a .NET porting project shouldn't have a problem duplicating the functionality.
Shadow Robert
22
Years of Service
User Offline
Joined: 22nd Sep 2002
Location: Hertfordshire, England
Posted: 14th Nov 2003 01:34
'spose ... but then i don't know many people in game dev who even use COM, its more of a business application feature.


To Survive You Must Evolve... This Time Van Will Not Escape His Fate!
900mhz | 256mb | FX5200Ti 52.16 | Dx9 | WXP-Pro
CattleRustler
Retired Moderator
21
Years of Service
User Offline
Joined: 8th Aug 2003
Location: case modding at overclock.net
Posted: 14th Nov 2003 02:27
are game developers using C++ and directx(any version here) - then they are using COM!!!!

digs in drawer looking for .44 cal. rounds....

-RUST-
Shadow Robert
22
Years of Service
User Offline
Joined: 22nd Sep 2002
Location: Hertfordshire, England
Posted: 14th Nov 2003 03:33
erm... no, but no doubt if i explained it you wouldn't believe me.

COM isn't used for games, period.


To Survive You Must Evolve... This Time Van Will Not Escape His Fate!
900mhz | 256mb | FX5200Ti 52.16 | Dx9 | WXP-Pro
empty
22
Years of Service
User Offline
Joined: 26th Aug 2002
Location: 3 boats down from the candy
Posted: 14th Nov 2003 03:46
LOL.
So DirectX is not based on COM interfaces, no?

Me, I'll sit and write this love song as I all too seldom do
build a little fire this midnight. It's good to be back home with you.
CattleRustler
Retired Moderator
21
Years of Service
User Offline
Joined: 8th Aug 2003
Location: case modding at overclock.net
Posted: 14th Nov 2003 05:12
That's what I am saying. If it's directx then it is a COM Library, period! Yes please explain how it's (DX) NOT com -this I'd love to hear...

If you'd rather not, then just say you had the terms mixed up and we'll drop it...

(here comes four pages)

-RUST-
Shadow Robert
22
Years of Service
User Offline
Joined: 22nd Sep 2002
Location: Hertfordshire, England
Posted: 14th Nov 2003 05:14
you by any chance getting interfaces and object models confused here empty, because they are different.

a COM has everything based around a layer depth... simplistic terms this would be like a model

Object -> Mesh -> Face -> Vertex

and you access such data within that given order and layers of the Object.
the Interface gives you direct access to everything around an Object Class...

So rather than getting an objects Vertex Position

MeshPos[0] as vec4 = DxObject.IndexBuffer.VertexBuffer.GetObjectPosition(instance)

you can simply bypass this and go straight to the objects value
lock(DxDevice->VertexBuffer(instance))
{
vec4 MeshPos[0] = GetObjectPosition(*instance)
}
unlock()

obviously those are just hypothetical examples, however it shows clearly the difference between the access means between a COM and a Programming Interface.
It is also showing the reason WHY a games programmer doesn't use it.

With the interface accessed and directly altering JUST one buffer and locking it for use, allows far more direct memory editing and useage. It also allows you to gain multiple accesses to given instances at any given time, allowing faster updating and more control over what your trying to accomplish.

There are many Flavours of DirectX that give you accessing means to the DLLs that reside within Windows - COM is not the Only version there is, and it certainly isn't by far the most open.


To Survive You Must Evolve... This Time Van Will Not Escape His Fate!
900mhz | 256mb | FX5200Ti 52.16 | Dx9 | WXP-Pro
CattleRustler
Retired Moderator
21
Years of Service
User Offline
Joined: 8th Aug 2003
Location: case modding at overclock.net
Posted: 14th Nov 2003 05:19
Quote: "MeshPos[0] as vec4=DxObject.IndexBuffer.VertexBuffer.GetObjectPosition(instance)"


should read

Quote: "MeshPos[0] as vec4(COM OBJ) = DxObject(COM OBJ).IndexBuffer.VertexBuffer.GetObjectPosition(instance)of COM OBJ))"


shall I continue...

-RUST-
Shadow Robert
22
Years of Service
User Offline
Joined: 22nd Sep 2002
Location: Hertfordshire, England
Posted: 14th Nov 2003 05:32
:: rubs temples :: this is going to be futile isn't it, you really don't have a clue about the difference in programming between the two languages and how.

COM OBJ ... why do you put that? Hmm
Component Object Model, this means a Object Class which is dependant.

An Object Class which is dependant, means that it must be working with other object classes in order to have full access.
These Objects are created in Layers of access to the said Classes, each Class before it contains a number of functions which intern will dwindle in thier access to more specific areas.

And Interface on the other hand doesn't give you a dependant Object Class to work from.
Rather it gives you a single access point to create instances of an object, which are then accessable to any given class instance and/or interface instance.

These allows you to control data directly rather than subjectively.

You access between a COM and Interface are therefor the difference between a Linear Access and a Dynamic Access.

DxObject in this case is the Interface Class in C++ and in VB is the Object Model.

Although they may appear to give similar access they're not.
The Vec4 also might seem like an Object, however it is not ... it is mealy a Structured Type of Data, and Structured Data is not an Object Model.

This is why DarkBASIC Professional is not an Object Orientated Language and also why it doesn't support COM Programming.

Although a Class Structure is capable of creating an Object Model, pure Structured Data however is not.

The difference being is that a Class is capable of processing, it is an Active Data source and conditioner ... whereas a Structured Type is mearly a Passive and purely Static peice of data not for manipulation but for storage.

COM works on the emptive of Manipulation, Access and Conditioning.

As i've stated before these VERY different programming methods and means.


To Survive You Must Evolve... This Time Van Will Not Escape His Fate!
900mhz | 256mb | FX5200Ti 52.16 | Dx9 | WXP-Pro
CattleRustler
Retired Moderator
21
Years of Service
User Offline
Joined: 8th Aug 2003
Location: case modding at overclock.net
Posted: 14th Nov 2003 09:44
what os are you programming under?

-RUST-
Shadow Robert
22
Years of Service
User Offline
Joined: 22nd Sep 2002
Location: Hertfordshire, England
Posted: 14th Nov 2003 10:06
mostly Windows, and i know what your going to say ... but DirectX works under BeOS and AmigaOS natively - and neither of them use COM.
Infact AmigaOS only uses C standards. (which DirectX actually has support for)


To Survive You Must Evolve... This Time Van Will Not Escape His Fate!
900mhz | 256mb | FX5200Ti 52.16 | Dx9 | WXP-Pro
MushroomHead
22
Years of Service
User Offline
Joined: 26th Aug 2002
Location: United Kingdom
Posted: 14th Nov 2003 11:58
Quote: "COM isn't used for games, period."


This is some joke right? I haven't seen DirectX running on an Amiga to date, can you provide a link which shows this? There are opengl implementations though.
empty
22
Years of Service
User Offline
Joined: 26th Aug 2002
Location: 3 boats down from the candy
Posted: 14th Nov 2003 13:56 Edited at: 14th Nov 2003 13:56
Quote: " you by any chance getting interfaces and object models confused here empty, because they are different."

?
I don't think you know what you're talking about.

Me, I'll sit and write this love song as I all too seldom do
build a little fire this midnight. It's good to be back home with you.

Login to post a reply

Server time is: 2024-11-24 04:47:34
Your offset time is: 2024-11-24 04:47:34