Quote:Original post by bleb
Ah! That's where the confusion lies. I would still call a JIT VM a VM. I would wager that the ardently pro-Java AP shares this view. Glad that's cleared up.

Yep according to actual definition (and proper computer science) parts of the CLI would be a VM in that respect. Although you can't say that an application built on the CLI runs on a VM as that would be misinformation, but there are VM components of the CLI in order to get things compiled to the target platform.

Quote:Original post by Avont29
no no, that was me that made the post about c# and unix and , etc. i forgot to put in myname and password

Yeah, you do that alot. Instead of double posting small bits of new text under large quotes, why not just make the second post a "err, ^that^ was me" stub in the future? And no, he said too accurate. Not inaccurate. Unless you meant accurate (I can't tell).

I prefer Linux as an environment over Windows, personally. But I'd rather not have to dual boot into Windows just to play a quick counterstrike match or whatever - and then back. Plus most people have financial constraints. Less money shelled out for an OS/extra hard drive/system = more money for games, no?

Games are the only reason I keep Windows installed.

Something too accurate could mean. He on purpose used a dictionary definition to confuse anyone. (Something like a different definition in dictionary, and a common usage between experts in the field.) ^_^

Quote:Just confirms that c# is 10% stolen java and
90% recipes of how to match the oriented Spaghetti
classes.

Funny because often so right on the track.

Quote:There is one new thing. The people behind .NET are competent

These two gave me a nice laught.

However if you didn't mean it as an irony, as would be sugested by cursive, you might look at this.

Quote:The real problem we have with C# apps are the intermitent freezings
(few milisecs that is blocking everithing) of the whole system (XP and 2K)
when gc kicks in.

This was a common behavior of Java applications a few years ago. It's quite surprising considering the MS has (had?) access into the SUN code bases.
So my point stands.

C# is not going to beat C++ in game programming, but supplement it. Even today,
almost all larger titles are *systems* in themself, having a programming language which allows to program that *system*, but the systems itself will be programmed in C++.

So C++ is even today usually not used to program a game, but to program 'game systems'. If these systems are general, you may even call them game engines, if they are not so general you will usually not really notice the system.

No one in the foreseeable future will code a complicated physic or behaviour
technique in C#, or in Java, or in LUA, or in Python. However, the stuff that
glues all these bells and whistles together to make a game can be coded in
*any* language - e.g. there are several titles using Python.

C# brings because of origin a tight integration with some platforms. If this is
of use for you, well, you should use it. If you possible target a platform where
this stuff isn't available - well, you are out of luck ...

Cheers
Alex

Quote:Original post by MaulingMonkey
Sidenote: I hate both C# and Java. I hate Python too, ...

This begs the question: Is there something you don't hate? Common Lisp? (Lispers are usually the ones hating everything but one language, so it's a safe guess)

Quote:Original post by Emmanuel Deloget
I don't think that Sony can say anything if one of the development team want to use mono and C# to devellop their game, but obviously neither Sony nor Microsoft will publicly support this (Microsoft for obvious reasons, Sony because they don't even know what a devellopment environment is [just kidding]).

I wouldn't be surprised if Sony actively discourage it.

Quote:Original post by Promit

Quote:Original post by Kylotan
Looking at the source for that, I wouldn't consider it very telling. Some of the slowest parts seem to be MS lib functions.

Standard library functions, whose implementations tend to be relatively similar across compilers and platforms.

No... MultiByteToWideChar wasn't a standard C++ call the last time I checked. Nor was _lstrcpynW. And 'operator new' is implemented in many different ways. Library efficiency is certainly important but you can't meaningfully generalise from a tiny example that focuses on 2 or 3 non-standard calls.

Quote:If the C++ coder and the C# coder manage to tie, but the C++ coder wrote 5 times as much code, then the C++ coder got beaten. That's the scenario I envision when you're dealing with extremely skilled coders writing extremely high performance code.

Yet if the example given was valid - which I don't really think it is, but anyway - 2 skilled coders wrote code, the C++ coder wrote 6 times as much, but got a version 33% faster. That's a massive amount in game development terms, and highly significant. We're used to long development cycles. We're not used to slow games...

Quote:Original post by Saruman
Why the hell are people always trying to talk about consoles that they will never be porting their games to? You won't be doing PS3 games unless you are part of a large studio, which would have an existing codebase, hence would not be using c# even if it was available.

The original post was:
1- Do you think that other corporate such as Sony will adopt managed language ??
2- Is it the time now to go with c# in game programming ??

Therefore PS3 games are as valid a subject as any.

Quote:Original post by Anonymous Poster

Quote:Original post by MaulingMonkey
Sidenote: I hate both C# and Java. I hate Python too, ...

This begs the question: Is there something you don't hate?

Nope. There are languages I hate less though. Like Ruby. But I hate Ruby too, due to it's shitty C/C++ interop among other things.

It is for this reason the concept of writing my own language hits the project ideas billboard in my brain every few months.

Quote:Original post by Daerax
Yes. You are.

A VM runs code that has compiled to a portable intermediate byte code. Your code is platform independent in that in runs on any machine with a VM which properly implements the functionality of your app. However since your code is intepretated it is horrendously slow and not a viable choice for performance hungry applications.

JIT compilations takes the byte code and further compiles it into native code and makes machine specific optimizations at run time. This is done quite readily since a good bytecode compiler can perform many optimizations on the code beforehand and make the code much more compact and machine translatable. Although startup times are immensley annoying, JIT can acheive at least 98% to 99% (based on numbers on MDX samples and stuff) of traditional offline compiled code. Indeed since games outsource alot of their work to other processing units, extra resource jucing of the JIT can be afforded :D. In addition one may argue JIT may outperform traditional native code in certain cases (especially for loop centric apps) since your most visited sections of compiled code is kept together in cache , allowing as well a good JIT compiler to make rigorous optimaztions and certain assumptions on your code a native compiler might not necessarily be able to make for the OS/machine offline*. Finally since we are in a managed environ our memory is guranteed to not be fragmented i.e. kept together.

Ok, so Java has a form of JIT in the Hotspot compiler, does it mean it doesn't run on VM?

hahahah Anxiously waiting for the response of some C# fanboy.

Quote:Original post by Daerax
In general, the J2EE and .NET provide similar functionality but in my opinion .NET edges out over J2EE. *In my opinion* .NET, my preferance is for .NET for a few reasons. It is fresher and cleaner

Wow, completely subjective, besides the fact that Java EE cannot be compared to .Net at all, since Java EE is related to libraries and services specifically made for businesses (Servlets, EJBs, webservices, assynchronous messaging, etc.) Things that the average Joe or the gamedev Joe won't need.

Quote:Original post by Daerax
- openly learning from both the past brilliant reaserches and mistakes and misimplemntations done on the Java platform.

Like what? "Screw backward compatiblity"? There's a reason for Java to be in
the Enterprise, stop and think.

Quote:Original post by Daerax
Unlike J2EE and Java (which have JIT c'ing too) the .NET CLR, CLS was designed from day one with JIT compilation in mind and its generated intermediate code is more suited for such.

WHAT!?!? This was the most ridiculous claim of the whole website??

Do you have any idea of what you are talking about at all??? Study, study a lot because you seriously need it.

That is, its intermediate bytecode is specifically designed to lend itself well to native compilation when run.

Quote:Original post by Daerax
The interop capabilities and the general support for shared components (allowing for increased code reuse and plugability) is much tighter and again was a major designing motivator on .NET and much less so on J2EE/COBRA which is not strongly a part of J2EE.

Where did you get this from??

Quote:Original post by Daerax
As well, since legacy code is a major factor for Microsoft, they designed support for native dlls to be clean and easy as is possible through PInvoke within the general framework requirements.

Assuming that you work in a Windows only shop, which is not the case with the Enterprise.

Quote:Original post by Daerax
But really, my main preferance for .NET is its incredible support for components and incredibly modular code

How it wouldn't be possible with any OO language?

Quote:Original post by Daerax
And its *Supreme Language independence*. The common type system together with the common language specification makes it possible to seamlessly code in whatever and however many languages you want at the same time. I realize that there are java bindings for other languages available on the java environment but unlike the .NET bindings (which again day one design factor), they are not so clean and just a hassle to work with (warning third person opinion there).

Bullshit. Have you ever worked in your life? How many companies do you know that let the developers freely choose the tools they use?

Language independence is important for marketeers and deluded college students.

Quote:Original post by Daerax
Also, they do not interop very well (if at all?).

THEY DO INTEROP WELL, THAT'S THE WHOLE POINT OF USING OTHER LANGUAGES IN THE JVM!!

THIS IS BIGGEST CRAPPY POST I HAVE EVER SEEN IN A LONG TIME, HOW CAN YOU POSSIBLY BE SO IGNORANT AND YET SO PROUD OF IT?

THIS IS A DISSERVICE TO ANY SERIOUS DEVELOPER, THIS IS AN INSULT TO ANY PROFESSIONAL. THIS WEBSITE MUST MAINTAINED BY KIDS FOR KIDS.

Quote:Original post by Daerax
On .NET, since all languages compile to the same IL you can use whatever CLS compliant code you want in your app and have it treated as a first class member - i.e. it is not loaded specially or something.

No comments on the depths of your ignorance.

Quote:Original post by Daerax
As an example, with 10 minutes of work I made my application fully sprictable and controllable with both Lispish (L#) and python (IronPython). Reflection allows no need for callbacks or any of that annoying gayances. I use Nemerle (and F# here and there where it makes more sense. F# is a light weight full featured impure functional language of the ML dialect which IMO, generates the most effiecient IL for the CLR of all the .net languages) for the game logic itself. You would not imagine how easy an RPG is to code in an OOP semi functional language such as Nemerle which offers algebraic types and (pattern matching over) variants and a Lisp level macro system.

FYI, there are more languages on the JVM than on the CLR. I don't know why people use it as a "marketing point", it can only be explained by ignorance.

Quote:Original post by mikeman
Whether you're right or wrong doesn't really interest me.

So you support misinformation and lies? Because that post was all about it.