quote:Original post by Coder

quote:Original post by johnnyBravo
if you don''t care about being dependent on microsoft , c# n directx is fine

That''s one big misconception about dotNET. dotNET is a standard now, and there are two open-source implementations under development: dotGNU, and Mono



Muhammad Haggag
Bitwise account: MHaggag -

I wholly agree with .NET becoming a standard. Although many people hate being dependent on Microsoft, there is nothing they can do about it. Trust me on this: the average computer user is not going to try saving a couple hundred $$$''s to be hassled by Linuxes non-user friendlyness. And if the avg. user is high on Microsoft, guess what operating system we developers are attracted to developing on? You got it! Microsoft Windows!!!
So rest assured the .NET standard is here to stay.

Sagar Indurkhya

AP: What''s not so good about unmanaged DirectX?

I''ve not used DirectX before and I''m a C# newbie, but what I''ve seen of both might just win me over from C++/OpenGL. I''m seriously hacked off with C++ in particular: everything takes so long to develop compared to C# or Java. IME, at least.

What do people think about cross-platform capabilities of .Net? Obviously DirectX won''t work, but OpenGL might?

quote:Original post by Anonymous Poster
C# is much easier than C++, also for DirectX programming.
However, the Managed DirectX isn''t that good ;-/

Well, i found Managed DirectX very good
It`s even much simpler than regular, unamanaged DirectX... Try to use DirectSound for example. Or, even better, how do you play MP3 file in unamanaged DirectX? In Managed DirectX it is done by a single line of code
It really takes much of .NET stuff, like massive overloading, enums, properties, collections... can use ''foreach'' for device enumeration and similar stuff...
Very well made...

And please don`t tell me that it performs bad in Axiom engine, it`s like saying that openGL sucks because it works bad in Unreal engine...
It`s problem in Axiom engine coding, not managed DirectX...

Current managedDX shortcomings/problems:
- Some bugs in D3DX functionality (especially mesh functionality, it seems). These can waste a lot of your time if you bump into one of them.
- No DirectShow.

Muhammad Haggag
Bitwise account: MHaggag -

quote:Original post by Coder

quote:Original post by johnnyBravo
if you don''t care about being dependent on microsoft , c# n directx is fine

That''s one big misconception about dotNET. dotNET is a standard now, and there are two open-source implementations under development: dotGNU, and Mono

If you''re working with DirectX you''re pretty much tied to Windows anyway, it''s kind of a moot point. It would be quite a long time before Mono/dotGNU AND DirectX (DirectGNU?) could be done to a reasonable level of performance.


Stay Casual,

Ken
Drunken Hyena

quote:Original post by DrunkenHyena

quote:Original post by Coder

quote:Original post by johnnyBravo
if you don''t care about being dependent on microsoft , c# n directx is fine

That''s one big misconception about dotNET. dotNET is a standard now, and there are two open-source implementations under development: dotGNU, and Mono

If you''re working with DirectX you''re pretty much tied to Windows anyway, it''s kind of a moot point. It would be quite a long time before Mono/dotGNU AND DirectX (DirectGNU?) could be done to a reasonable level of performance.

I have to greatly disagree here, Ken
As far as I know, Tom Miller wrote the managed DirectX layer alone. Maybe I''m wrong, but still, the managed layer is a very thin layer that can be *easily* written around GL instead.

As for the performance, that''s not much of an issue IMO, because we''re only wrapping. Minimal time is being spent in the .NET layer.

The problem with mono and dotGNU, is that they''ve got a *lot* of missing functionality, and they''ll need a lot of time to do it, based on their current pace (and when they do, MS will have released .NET 2.0, most probably).
I''ve actually attempted to help the guys (by participating in development), but - as always - was killed by the difficulty of getting linux-centric stuff to run on windows (so that I can code under windows). It needs Cygwin to run on windows, so I downloaded it. Still, it complains about missing tools, and I was so annoyed after that that I''ve ignored it for a while (and now I don''t have time ).

I still do hope that I''ll be able to do something for dotGNU sometime.

Muhammad Haggag
Bitwise account: MHaggag -

quote:Original post by Coder
I have to greatly disagree here, Ken
As far as I know, Tom Miller wrote the managed DirectX layer alone. Maybe I''m wrong, but still, the managed layer is a very thin layer that can be *easily* written around GL instead.

As for the performance, that''s not much of an issue IMO, because we''re only wrapping. Minimal time is being spent in the .NET layer.

The managed DirectX layer is a DX layer on DX, the mapping is trivial. Mapping D3D to OGL isn''t a big deal, it''s been done many times before. What about D3DX? That is a huge amount of highly optimized code with a lot of proprietary IHV info in it. Easy to replicate? I don''t think so.

What about DirectInput and DirectSound and so on? Not to leave out DirectDraw either since it''s in Managed DX.

Like dotGNU/Mono/etc it''s easy to hit some of these and claim it''s been done, but realistically to have a DirectX emulation layer with similar performance is a really big deal. Wrapping the core D3D code is a drop in the bucket, it''s the rest of DX that will be the issue.



Stay Casual,

Ken
Drunken Hyena

quote:What about D3DX? That is a huge amount of highly optimized code with a lot of proprietary IHV info in it. Easy to replicate? I don''t think so.

- There''s no need to provide a helper library that is as fast as D3DX. Remember that the suggested goal is not to replace DirectX on windows, it''s merely making it portable. This port doesn''t need to be as optimal as the windows one, it just has to be good enough to run things at reasonable speeds. It''s better than nothing

Heavy-weight engines are still being written in C++. I think that the next couple of years will see light-weight apps/engines/games being written with managedDX (by lightweight, I mean games that don''t do loads of processing, and winforms-based multimedia apps)
- Many Many games have been released *without* D3DX (on windows and other platforms) and have excellent performance. It''s quite possible and relatively easy, if you have those who can do it. Given that dotGNU/mono are open-source, they''ll most definitely find some interested assembly hackers
- There are free, optimized math libraries available from AMD and Intel (and others as well)
- What are you referring to regarding proprietary info, exactly? Cache sizes and similar? These can be retrieved via DX9 for DDI9 drivers, as far as I recall, so you can do that for all the cards that support it and use that info.
Even if these aren''t replicated, it''d still be OK to live without them (Using a common-sense cache-size would work good enough for most types of hardware, for example).

quote:What about DirectInput and DirectSound and so on? Not to leave out DirectDraw either since it''s in Managed DX.

- For sound, there''s OpenAL. It''s not as deep as DSound, as far as I know, but it''d get you the most important functionality done. i.e. You can ship with it.
- Basic input support in any OS covers the essential ground. Using that, you can get the very common immediate/buffered keyboard and mouse input to work right (and that covers the FPS/RTS/RPG genres, at least).
If there''s more advanced input support on *n{i,u}x-based systems - even if it''s not as uniform, or full-featured as DInput - you could get some sticks and pads running too.
- DirectDraw is basic hardware-accelerated 2D output. XFree86 ships with drivers supporting 2D drivers for almost all hardware, and 3D support for many/most (not sure about this 3D thing). I don''t think it''d be that hard to do the most commonly used DirectDraw functionality. Not sure about the more advanced DDraw stuff.

The point is, for anything exposed by some DirectX API, but we can''t do, we do one of the following:
- Report it as not-supported (through the caps system)
- Fallback to a reasonable lower setting that''d work
- Fail

Muhammad Haggag
Bitwise account: MHaggag -