next »

[Layl]

I'm pleasantly surprised how many people are saying C#. I like it as a language, a lot. I was shocked to see Unity using it, but I'll take it. I've been thinking about porting my old unfinished 3d engine from c++ to c#, but I dread the OpenGL wrappers I'll need to find. I know I tried once, didn't like any of them.

Has anyone ever tried .NET native? http://msdn.microsoft.com/en-us/vstudio/dotnetnative.aspx

I haven't tried it but I don't think it would make much of a difference in performance. .NET already compiles your code to machine language at runtime (it JIT compiles it). There's a big advantage of having that JIT there for optimizing the machine code for specific architectures.

Most notably, the upcoming Microsoft SIMD ( http://www.nuget.org/packages/Microsoft.Bcl.Simd ). It can support different SIMD architectures easily by simply compiling at runtime for the architecture your CPU supports.

[Interface]

powershell huh? I REALLY need to learn that. Especially considering my line of work involves build management.  I guess I can see how that could work as a scripting language. It would certainly be more terse than C#.

A while back I remember someone posting about using C# as a scripting language for their C# engine. They just used the API compile stuff to rebuild the script layer while the game was running.

Well, beyond powershell as a language itself, you could just define some C# code at runtime and run it. You can also just load any .net dll and instantiate classes etc. (including command line tab-to-complete-or-iterate on class names, method names, etc).
We use it for builds actually, and it's a great language for that kinda stuff.

[Krux]

I found an interesting talk from Jonathan Blow (Braid developer)

[Canned Turkey]

I haven't made anything with it yet, but python's pretty dang fun to mess around with.

[tjcbs]

I've found it very very hard to move away from c++. It is so easy to get used to the freedom it offers, and chafe at the relative restrictiveness of other languages.

[HFCRacer]

Right now Objective C, C++
In the past Assembly (which I really miss)

[VampireSquid]

Favorite language, once the code is written: C++
Favorite language, before the code is written: C#
Least favorite language:  Probably C++

[Sik]

In the past Assembly (which I really miss)

x86 assembly? Eh, not so really fond of it although at least it's quite usable (though I haven't messed that much with it, so I probably need to use it more to form a proper opinion about it). Way more fond of 68000 assembly though, it's a lot easier to program for.

[jgrams]

Way more fond of 68000 assembly though, it's a lot easier to program for.

Hear hear. Newer RISCs like PPC and ARM just aren't the same. 68K has to be about the nicest assembly language ever.

[Boreal]

Fingers crossed that OpenGL Next ends up using a painless shader assembly language.

[Sik]

I guess nobody cared about that since as far as I know Direct3D now doesn't support assembly for its shaders either (only HLSL), although the fact OpenGL doesn't allow prebuilt binaries that work on every system (when Direct3D does) is annoying (the problem is that without them you have to compile the shader and that increases the loading time).

[Boreal]

OpenGL's current shader system is a mess.  It has been announced that OpenGL Next will allow you to submit shader IR to the driver, although Khronos hasn't expanded on any details.

[Elideb]

I'd say D (although I haven't used it beyond some simple programs). Fast, pretty and with some incredibly beautiful features. If only it had C#'s Linq and Rx...
Second, C#, which is the one I use the most, either for games (Unity, the old XNA) or tools.
And for scripting I loved the time I spent with Python while working on build pipelines for EA. Or managing websites with Django.

Regarding Jonathan Blow's proposal of a new programming language for games, I get the impression he simply does not like some parts of C++ at all. In my opinion his two hour talk can be summarized as D++. Which is funny, because D intends to be something like C++++.

Also, some of the ideas he proposed were nice, but the approach seemed the opposite I'd expect. Like the marker for "this memory region is managed by me; free it in my destructor", which should really be "this memory region is managed by someone else; don't free it in my destructor". The first case is the common scenario, the second the exception that needs highlighting.

[mildspring]

My current preference is with C#. Familiar syntax, nice features like LINQ, don't have to deal with releasing memory, a lot of libraries, easy to find support on stack overflow, etc.

[HFCRacer]

In the past Assembly (which I really miss)

x86 assembly? Eh, not so really fond of it although at least it's quite usable (though I haven't messed that much with it, so I probably need to use it more to form a proper opinion about it). Way more fond of 68000 assembly though, it's a lot easier to program for.

68000 of course. To be exact, I was talking about the Amiga.

[Raptor85]

c++, no contest 

over the years tried many many other languages (pascal/java/haxe/python) but in the end always end up moving right back after getting frustrated at language restrictions (forced GCs/forced exceptions/dynamic typing/inheritance restrictions/etc...)

[tjcbs]

I'd say D (although I haven't used it beyond some simple programs). Fast, pretty and with some incredibly beautiful features. If only it had C#'s Linq and Rx...

If only D had kept the preprocessor, or better improved it as they improved c++, instead of the asinine decision to do away with it, it could have been the One True Language.

[Netsu]

Favourite to write in: SML
Favourite to work in: C++
Favourite to make games in: whatever Unity offers, C# currently

[Boreal]

I'd say D (although I haven't used it beyond some simple programs). Fast, pretty and with some incredibly beautiful features. If only it had C#'s Linq and Rx...

If only D had kept the preprocessor, or better improved it as they improved c++, instead of the asinine decision to do away with it, it could have been the One True Language.

Personally I think the preprocessor is what's holding back C++.  Template expansions, references to external functions, and private members (for struct sizing) should be resolved at link time, not compile time.

[Geti]

While I agree that the preprocessor is an all too familiar evil, wouldn't link time fiddling with struct sizing and templates preclude or at least make difficult linking against (extern c) cpp from c? Or how would that work?