Msvc++ .net???

[Neom]

Does anybody know what HL2 was programmed with .NET(7.0) or 6.0.Because there are some diffs that some types require code changes @@ to a lot of thing(depedning how much code @@)anyways does anybody know.

 

[Mr. Bildo]

Originally posted by Neom
Does anybody know what HL2 was programmed with .NET(7.0) or 6.0.Because there are some diffs that some types require code changes @@ to a lot of thing(depedning how much code @@)anyways does anybody know.

Although I can't say for sure, I would be 99% positive that no part of HL2 is done in .NET, or at least none of it is C++ managed code. It's very possible that they used Visual Studio .NET as the IDE, but wrote only native (unmanaged) code.

Once DirectX becomes part of the .NET Framework, you may start to see games running on the platform, but at this point it would be nothing short of ridiculous to do so, since you'd have to either use GDI+ or DirectX via InterOp. No point in either.

Steam, on the other hand, I think could find value in .NET...

-Mr. Bildo

 

[Neom]

acctuly that all i wanted to know if they used the IDE because both complier are kinda diff even if u hanve .net frame off.using the same code i could compile in 6.0 i couldnt in 7.0

 

[Mr. Bildo]

Hmm.. yeah.. that's different. There is really no way of knowing for sure if there are going to be incompatabilities. Assuming they use the MSVC++, 6 vs. 7 shouldn't have any serious issues. I mean, after all, it's gotta end up native API anyway. Now, if they're using some other compiler, that could be a different story. Also, are they using COM, ATL, MFC, any technologies like that? I don't know if that info is available about the SDK yet.

You could check out msdn and see if there is a compiler diff matrix or something.

Personally, I haven't run into any problems using VC++ 7.0, but since I write business apps for a living, and not games, the amount of C++ I've written since .NET came to be has dropped steeply.

-Mr. Bildo

 

[MrD]

Since .NET uses automatic garbage collection it is unlikely that anyone would want to write a game such as Half Life 2 in it, because you do not have control of when its gonna go off on one. To get those nice steady frame rates you need to be very careful about when you go about loading and destroying things, and certainly can't afford to leave it up to the OS (ie. CLR).

Not to mention compile-on-demand. Ahh, thats the first time you alternate-fired that weapon, please put up with a couple second delay while I go off and compile that part of the code for you. Unless you compile it all up front, can you do that in .NET i'm not sure??

Anyway, that was complete off-topic.

 

[Mr. Bildo]

Actually, the garbage collection in .NET is one of it's highlights and is very well implemented.

At first it may seem that GC bloats memory, but once you understand the threshold mechanisms you begin to appreciate the way it optimizes reallocation on the heap. Another overlooked advantage is that the CLR has very low-level control of the OS and optimizes CPU performance in regards to memory management. Again, using the threshold concept it will wait to "clean-up" if it's far from a threshold if the CPU is being taxed. Once the CPU is let up a bit, it will then go ahead and collect. This can be a huge advantage in a web application when often the CPU is crunching like mad, but little memory is actually being pushed around. That kind of memory management is simply tedious to code by hand.

I'm personally a big fan of GC.

-Mr. Bildo

edit: too early in the morning to spell...

 

[Echelon]

i doubt they used something like c# as language for hl2. maybe theyve used .net 7.0 as developer environment. i doubt they want everyone to install .net for being able to play hl2, even if it's part of the hl2 installer. also, steam doesnt use .net does it?

 

[MrD]

re: garbage collection

When I was banging on about garbage collection, I wasn't trying to say it was crap, just that it isn't much good for games. Personally I like garbage collection, it is one of .NET's strongest features IMO.

 

[Fallout2man]

Visual Studio .NET does not equal .NET programming only.

It comes with C/C++ C#, J#, and vb compilers. Only C#/J# must compile to CLR. So while they probably used .NET as the development environment and .NET's C++ compiler it was not compiled to CLR but actual instructions.

 

[Owskie]

i know valve used some C++

 

[MrD]

Originally posted by nietzsche
I guess we must have had different experiences with garbage collection in the past.

We certainly have!

I would be interested to know how you prevent it from garbage collecting mid-way through a frame render (ie. is there some kind of global flag you can set or something) ?

 

[Ares]

Just for fun, as a very NEW beginner in C++.. everything you just said was VERY VERY VERY confusing. I'm only a few weeks into my first C++ class (school class, mind you).. I hope it get's less confusing when listening to programmers talk, as I move up the experience ladder.

 

[MrD]

If I actually stop and think about this then it makes perfect sense. You are unlikely to be allocating/deallocating much memory in the render-loop anyway. I guess it just requires some thought about what you are actually doing, which is true of anything when you are optimizing for performance.

Still, there is something about .NET that just makes it feel... bloated.

 

[MrD]

Originally posted by Ares
Just for fun, as a very NEW beginner in C++.. everything you just said was VERY VERY VERY confusing. I'm only a few weeks into my first C++ class (school class, mind you).. I hope it get's less confusing when listening to programmers talk, as I move up the experience ladder.

Yes, and then one day you'll find yourself disagreeing with someone

 

[Vulcan3d]

Mr D,

I don't think you'd have the kind of problems you describe. Generally, GC takes care of objects not currently in use. So, midrender, a CGenericActor class wouldn't be collected. You should be able to force GC(can in Java), or otherwise it runs when you get close to running out of memory. Objects initted and no longer in use are collected to free up memory. Now if somehow you are using too much memory, and not enough memory can be freed up, you would get an out of memory exception.

To me, the real fear of writing a game engine in .net is the ease with which CLR can be decompiled. Even with an obfuscater covering up your tracks. I just wish I knew of a way, if one exists, to do what the JIT compiler does, permanently. Write my code in C#, and have it spit out machine language. Until I can find that out, I'll be sticking to writing in C++, and avoiding any managed code.

Right, the JIT compiler (or on demand compiling as you called it) could be a pain in mid app, but on the bright side, it does keep a machine language version around for the next time you run it. Unless there is a precompile option(don't know yet), you could have a little public method in every class that runs on startup (Yuck!)

.Net seems no more bloated than, say, Java. But I am beginning to grudgingly accept the fact that high-high level languages may be here to stay. Some of us will just have to go through the whole "Real programmers don't use Pascal" debacle again.

But to answer the original post, there is a simple way to find out which version of the IDE valve uses. The code is out in the wild, I'm sure somebody(perhaps a somebody reading this thread?) out there found it and downloaded it. Try opening the project in VS7.0. If you get an error telling you it needs to update the project to load it, then they used VC6.0. VC6 would make sense simply because development on this project started in 1998 or 1999, and the golden rule says don't change tools mid-project.

K

 

[Fallout2man]

In a screenshot someone posted I saw .dsp files, that'd indicate Visual Studio 6.0 or lower, as 7.0 and above use .vcproj and .sln files.