Jump to content
  • Advertisement

Archived

This topic is now archived and is closed to further replies.

MrScruff

Level Editor : C# or C++

This topic is 5651 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

Hi, I am about to start coding a new level editor to take advantage of the future technologies available in NV30 class hardware and Directx9. However, having been happy with C++ for many years I am well aware of its strengths and weaknesses, speed and memory leaks respectively in my experience. I was wondering whether any of you consider C# to be a viable alternative to C++ in this instance. DirectX9 will have a managed C++ interface to C#, and I only need support Windows 2000 and above. The downside is I have heard the floating point performance of C++ is disappointing, which could be a problem with complex mesh tools etc. I do like the idea of being able to leave memory allocation behind me, as despite my own occasional mistakes, I have had to deal with extremely buggy code written by others who are less careful with their memory management. I don''t intend to start a language war, as I belive both to be extremely useful in certain circumstances. I am just unsure which camp a level editor falls into, as it straddles the worlds of Windows application and real-time graphics. Cheers, Scruff

Share this post


Link to post
Share on other sites
Advertisement
Yeah, it would definitely work pretty well to code your level editor in C#; The RAD tools will make coding the UI a lot easier, and if you find a specific routine is killing performance in C#, you can always make a managed-code C++ class that''ll do the job.

Share this post


Link to post
Share on other sites
Exactly what I would suggest. C# is absolutely fantastic for developing Windows Form apps, and you could code just wrap the game specific code in C# managed classes.

.NET''s code interoperability is freakin cool

Share this post


Link to post
Share on other sites
Hmm... interesting, cheers for the info guys. I''ve been looking into the managed C++ thing and am intrigued, does anyone know the performance hit by calling C++ functions from C#? If its OK I might just wrap all my maths in a set of Managed C++ classes and do the implemetation of algorithms in C#.

As a side note what are the performance implications of templates in C++, as I am thinking of generalising my maths library (all vectors, matrices and so on) to allow for the new 64 and 128 bit gfx pipelines in DX9.

Thanks in advance, Scruff

Share this post


Link to post
Share on other sites
quote:
Original post by MrScruff
As a side note what are the performance implications of templates in C++, as I am thinking of generalising my maths library (all vectors, matrices and so on) to allow for the new 64 and 128 bit gfx pipelines in DX9.



Unlike virtual functions, templates have no run-time cost. It's strictly equivalent to rewriting a different function or class for each different instanciated type.

Thus

template <class T> class Foo { /* stuff using T */ };

template <class T> void DoStuff( T arg ) { /* stuff using T */ };

Bar a;
Quux b;
Foo<Bar> c;
Foo<Quux> d;

DoStuff( a );
DoStuff( b );
DoStuff( c );
DoStuff( d );


is equivalent to


class Foo_Bar { /* stuff using Bar */ };
class Foo_Quux { /* stuff using Quux */ };

void DoStuff( Bar arg ) { /* stuff using Bar */ };
void DoStuff( Quux arg ) { /* stuff using Quux */ };
void DoStuff( Foo_Bar arg ) { /* stuff using Foo_Bar */ };
void DoStuff( Foo_Quux arg ) { /* stuff using Foo_Quux */ };

Bar a;
Quux b;
Foo_Bar c;
Foo_Quux d;

DoStuff( a );
DoStuff( b );
DoStuff( c );
DoStuff( d );


You pay and compile-time cost as the compiler generate the instanciated class/function definition from the templates, but that's it.

As for 'code bloat', it's no greater than it would have been if you had explicitely defined all those functions and classes yourself - though only those you actually used will be generated.

Documents [ GDNet | MSDN | STL | OpenGL | Formats | RTFM | Asking Smart Questions ]
C++ Stuff [ MinGW | Loki | SDL | Boost. | STLport | FLTK | ACCU Recommended Books ]


[edited by - Fruny on December 6, 2002 5:10:34 AM]

Share this post


Link to post
Share on other sites
quote:
Original post by Fruny
As for ''code bloat'', it''s no greater than it would have been if you had explicitely defined all those functions and classes yourself - though only those you actually used will be generated.

Hrmm... Couldn''t the same template be instantiated multiple times in different translation unit? Furthermore, f and f will generate two different functions, but if the function had been defined simply as f(int), an implicit conversion would have occured.

Cédric

Share this post


Link to post
Share on other sites
doesnt managed c++ generate the same MSIL code as c#? i am probably wrong, but wouldnt coding the graphic stuff in managed c++ give you no performance boost?

Share this post


Link to post
Share on other sites
I don''t know anout C# but I would still reccomend it. You can create the GUI much faster, which is important for an editor. Its not like FPS matters either, you just have to see the level

My editor is in VB, but its not 3D

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
quote:
Original post by MrScruff ...does anyone know the performance hit by calling C++ functions from C#?
I''ve used managed c++ code from c# in a project, and made a few hundred calls per second from c# to mc++ with quite low cpu usage. So I don''t think that will cause you any problems.

If you want details, I suggest you ask on news://msnews.microsoft.com/microsoft.public.dotnet.framework.performance or http://discuss.develop.com/dotnet-cx.html

If you more details, please post the results here. It would be interesting to know

Share this post


Link to post
Share on other sites
quote:
Original post by jharkey
doesnt managed c++ generate the same MSIL code as c#?

An MC++ assembly can contain both managed(MSIL) and unmanaged(x86) code.

EDIT: Changed from "A" to "An"


For those who believe in God, most of the big questions are answered. But for those of us who can't readily accept the God formula, the big answers don't remain stone- written. We adjust to new conditions and discoveries. We are pliable. Love need not be a command or faith a dictum. I am my own God. We are here to unlearn the teachings of the church, state, and our educational system. We are here to drink beer. We are here to kill war. We are here to laugh at the odds and live our lives so well that Death will tremble to take us -- Charles Bukowski

[edited by - Arild Fines on December 6, 2002 2:38:50 PM]

Share this post


Link to post
Share on other sites

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!