Slashdot Mirror
Is .NET Relevant to Game Developers?
andrew stuart asks: "We've heard an awful lot about how .NET is the future and how .NET signals the end for COM based Windows development, but how far does this go? Is it really the end of COM? Will ALL Windows programming be done with .NET? What about games development? Will games be developed with .NET? If games aren't developed with .NET and Microsoft is killing COM, then what future for games development on Windows? Will there be DirectX for .NET?"
Well, it's pretty much the same thing. (And before that was UCSD Pascal and P-code) Interpreters don't have brute strength speed that assembler, or even earlier C++ had. Sure, they're quick for instantiating a zillion objects from an already loaded class, but are awful for anything doing heavy calculations. For heavy math/memory moving you'll need tighter native compiled code libraries, which I'm already finding to be a headache. That and unless your game runs in a browser, your players will have to have the .net Framework (~20 meg, of which
I note 1.1 is now downloading on Microsoft update.)
So what else does .net have to offer? This whole XML thing? Can't say I've ever considered that
a necessity for game play. Maybe it'll allow the player to enjoy games which are Office compatible
or such, doesn't seem relevant. I feel .net is not for game programmers, at least action games.
Probably fine for strategy games which don't have to do a lot of iterating potential moves.
Then again, maybe this explains the long delays for Star Wars: Galaxies and Duke Nukem Forever...
A feeling of having made the same mistake before: Deja Foobar
At work I've used dotnet for the past year and half full time.
I've built websites with it, I've build desktop apps with it,
I've even built auto-updating distributed apps with it.
Dotnet has some good things to it and some bad things just like
any other technology. Before dotnet, most of my work solutions
were written in VB *shudder*, but when dotnet was released I
switched immediately to C#. C# does some things right that Java
didn't do too well on, but those are honestly pretty rare. IMO,
C# is very much like an immature version of Java. That being
said, Microsoft is pushing dotnet pretty hard.
When it comes to dotnet for game development, it is a
possibility. Mainly because Microsoft is putting so much
emphasis on it. With good native integration into DirectX, they
could push a lot of DirectX developers into using C# or Managed
C++, maybe. It will only happnen if MS can make the integration
fast and tight, and even then I don't think everyone doing
DirectX will use dotnet, it imposes too many rules on you as the
developer and really hides the low level details that are so
critical to many high performance games (yes even using unsafe code). On the other hand it
could be a good language for someone to learn to write games in,
for just that reason.
Of course, that really only applies to people who want to use a
Microsoft product for building games. The ubiquity of dotnet
within the MS world will have little to no effect on the OpenGL
programmers, except that they may need to find a different
editor *if* they have been using Visual Studio.
In reality I think dotnet is what everyone thinks, a competitor
to Java. How many highgrade professional games are written in
Java currently?
Doug Tolton
"The destruction of a value which is, will not bring value to that which isn't." -John Galt
and use OpenGL
For starters you have to use .NET for XBox stuff. :)
The optimisation is also better than VC6 so it makes sense to use .NET for games.
Martin Piper
Owner - ReplicaNet and RNLobby
DirectX 9.0 for Managed Code
.NET .NET
= /library/en-us/directx9_m/directx/directx9m.asp?fr ame=true
(its out already)
With DirectX 9.0, developers can take advantage of DirectX multimedia functionality and hardware acceleration while using managed code. Managed DirectX enables access to most of the original unmanaged DirectX functionality. The following are the managed code languages supported by DirectX 9.0 and documented in the software development kit (SDK).
Microsoft Visual C#(TM)
Microsoft Visual Basic®
Microsoft Visual C++®
Microsoft JScript®
http://msdn.microsoft.com/library/default.asp?url
Were all games based on COM?
.net, but that doesnt mean games will ".NET" based.
Of course not.
Alot of developers are using visual studio
....yawn...
The developers of AC2, developed by another company for microsoft, where given authencation code and chat server code developed by microsoft. The addition of this code has made the game unplayable. Here is a quote about the problem from the microsoft head of the game: " Right now the Chat and Authentication System (the Microsoft technology that handles this entire sort of chat) relies on system calls to another system--one that is not related to the Chat and Authentication System or to AC2--to send out the packets that contain your chat. What is happening is that under high CPU usage (that is, when the game starts reaching its peak), this third system starts to throttle the packets and queue up the game server messages (not to be confused with messages/chat to players)." From what is know about the authentication server and chat they are based on .net technologies. So since microsoft cannot produce its own reliable stuff using .net what is the chance of someone else?
If Microsoft had've written DirectX in C, instead of their freeko C++/COM methods, this would probably be avoided. OpenGL was written in C, and it works fine all sorts of platforms, regardless of what other functions are available. Microsoft has cleaned up much of their in recent versions, but for the longest time DirectX was a nightmare to code in.
.NET for game development, period. I guess I'm old fashioned, but I like my SDK's as simple as possible, something Microsoft doesn't seem to like making anymore.
I won't use
I asked this question at a .Net seminar and the naswer was. Use the non managed version of C++ for game development but NOT the managed code. Two reasons. Managed code is slower. Also calls into and out of the CLR are very slow if you are mixing managed and unmanaged code.
The home of the 3D Socialization and Interaction Engine
Why don't you ask Steve "Developers, Developers, Developers" Ballmer?
I say this, not to be snide (well, okay, a little bit), but to point out that the ostensible strengths of proprietary software are mostly illusory.
Next up, "My boss wouldn't let me run Linux, 'cause there was no one to sue if things went wrong. We subsequently got burned by some MS software, but the license agreement says we can't sue them. How did we come out ahead on this?"
-Peter
It's not like we've even figured out what the hell .NET is yet, right? I've played around a bit with C# (both Microsoft and Ximian versions) and thought, well, this is great but where is this going to take us that Java hasn't?
It's important not to get caught up in the buzzwords, the hype, or the marketing ploy to redefine the paradigm.
For example, just the other day while I was enjoying a meal of Hunan Chicken I was reflecting on the history of chopsticks, and the humor in the whole situation of people getting pretentious in their ability to use them. Aren't people aware that the things were invented in America in the 1800s by Chinese immigrants seeking to differentiate their restaurants in the mining communities? But this is just another situation where marketing has gained such a foothold that myth becomes historical fact, amusingly so when you realize that chopstick use in Asia now far outstrips American chopstick use and that something like 1% of all our lumber exports go towards manufacturing wooden chopsticks.
It's easy to carve new markets out of ignorance, but it doesn't imply relevancy -- far from it. You can slap .NET on a game, but it still comes down to the fundamentals: does it run, is it fun, does your player have a gun? I don't see anything in the toolset that will make development any simpler, and in fact think it'll make it harder to create something that works properly and properly exploits all this expensive hardware people are packing into their systems nowadays.
Try not. Do or do not, there is no try.
-- Dr. Spock, stardate 2822-3.
Will games be written with .NET?
.NET?
.NET than are written for Linux?
Yes
Will all games be written with
No
Will games be written with SDL and OpenGL?
Yes
Will all games be written with SDL and OpenGL?
No
Will more games be written with
Yes
Will it really be any different from the way it is now?
No
Was this article posted just to give zealots a chance to yammer about MS world conquest and other conspiracy theories?
Yes
I don't need no instructions to know how to rock!!!!
DX9 has a managed inteface for most if the core components. MSFT are claiming a few% slowdown over C++ however i think that it pretty much irrelevant nowdays since games programmers seem to be having a hard time keeping up with the vast advances in computing power available to them. If working in .NET drops the framerate from 100 to 95 in exchange for a more productive porgramming environment then i think that it is worthwhile.
Directx9 also includes good integration with vstudio.net that lets you debug your shaders nicely.
There are 2 problems: the documentation is very poor at the moment - i have to find the equivelent c++ function in the help to get any info on what it does - and not all the parts are available (DirectMusic being the most noticable)
-- "Outside of a dog, a book is a man's best friend. Inside of a dog, it's too dark to read."
XML is great for game development. Would I ever distribute a game that uses XML at run time? Probably not. Will I use it for development, and "compile" things down later? Heck yes. A lot of developers forget how nice it is to be able to let your artists play with all sorts of settings and make things dynamically, XML isn't the nicest interface, but easier than bugging a programmer to tweak something for you. However, you really don't need .NET for XML. It's easy to use, sure. However, Xerces C++ interface isn't that bad, and just about anyone can stick a simpler interface on it.
I tend to agree that the CLR is slower than compiling down to machine code. However, I've also seen some pretty cool Java based game development. I think it comes down to the game itself...if it's pushing hardware limits, then .NET is a no go. If it doesn't push the hardware, why not?
- Sighuh?
... at least for now. .NET is a "good" idea in theory. But it's performance is just not up to par compared to the execution times of applications using .NET vs C++.
.NET for the applications. .NET is fairly easy to code many types of applications, but when performance of the final executable is your major goal, then .NET is really not the language for you.
It is the equivelent of placing another abstraction layer on the executable code before it is executed. This inherently decreses performance of the application (its something like the equivelent of writing a game in perl... it relies on the perl interpreter to create the actual executable code which is why something written in perl takes longer to execute then something written in C++ (I know there is a debate on this, but for the majority of cases this is true, however, it is also true that it may be 1000x easier to "code" the application in perl vs C++))
If MS optimizes their interpreter, then in theory, it will eventually become almost as fast as C++, and at that time, it may be worth the benefits of coding in
We were all warned a long time ago that MS products sucked, remember the Magic 8 Ball said, "Outlook not so good"
I mean, I'm not advocating .NET or anything, but the idea of being able to plug perl or python (or whatever else) could be pretty cool for making game mods, dontchathink?
Using .NET to write a full blown, polygon-pushing, 3d-accelerated game would be like shooting off your foot with a nuke. Although, I'd like to be proven wrong :)
I've developed in both.
.NET.
.NET is everything Java meant to be.
If your client platform is only Win32 (and thats 99.9% of people) then there is NO reason to use anything but
I've yet to see a Java app that ran worth a shit. SLOW SLOW SLOW.
There were programs written before Microsoft
came along, and there will be after they're gone.
You've got a brain, use it, don't rely on
others to tell you what to do and how it should
be done.
People keep asking the (dumb) question "but if you build it with .NET then I'll have to have Passport/reveal my shoe size to Microsoft/bring about the downfall of Western Civilization in order to use it, right? WRONG... RTFM. .NET is just an application development framework (a very comprehensive one at that). You may be thinking instead of the erstwhile "Hailstorm," which is not the same thing as the .NET application development framework, and to my knowledge is basically a failed initiative at this point. People who have never developed any .NET code should probably refrain from pontificating about its shortcomings.
.NET, as others have pointed out, and this makes good sense considering how easy it is to call COM code from .NET. To those whining about how slow CLR code is, I suggest you actually try it and benchmark it before opening your mouth... Java it is *not* (hallelujah)...
There is already Managed DirectX for
Could someone explain to me exactly what .NET is good for, that couldn't be better accomplished using Java, or Win32/C++, or PHP? Seriously.
.NET really is cross-platform.
.NET that you can't do better with something else?
I can't see it being useful for games, because it's going to be slower than C++.
I can't see it being useful for cross-platform GUI apps because there's no guarantee that
I can't see it being better than any of the various web development solutions (PHP, cold fusion, etc...)
I can't see it being useful for enterprise server side apps because Java is more mature, more reliable, and has a VM implementation on lots of different platforms.
I can't see it being useful for PDA/Phone apps because the framework is too heavyweight.
So I know that it's new and shiny and Microsoft....but what, exactly, is it good for? What can you do with
The parent article seems to have a vague concept of what .NET is. (Perhaps this is more MS propaganda's fault.)
MS released C#, and that's what they're toting when they talk about ending COM-based windows development, I think.
If you knew what COM was, you might have a better understanding of what Microsoft is phasing out. COM is the Component Object Model. It allows programs to invoke special versions of other software (which has a COM written for it) and call routines out of that software. For example, I could call the spellchecker for MS Word from my email-writing program, assuming the user had Word installed, of course.
I used COM in writing an application meant to automate customer response letters (the user wanted to have Word-compatible documents when the program was finished - a perfect example of COM) and let me tell you: COM is hairy. You have to pass pointers to functions, call functions with nasty parameters... it's a good idea, it just doesn't work inside the C/C++ syntax very well.
Unless you're looking for your game to be able to read and write MS Word files, or print through Excel, games probably wouldn't have used the Component Object Model.
C# apparently has the same functionality that COM did, but probably does it a little more elegantly.
In any case, game developers didn't use COM, and they're probably not using C#. They WILL, however, be using .NET. Because Visual Studio .NET is Microsoft's latest incarnation of their programming IDE and compiler package.
And the later versions (hopefully) contain more and more code optimization. And Microsoft HAS good code optimization: they bought all of Watcom's optimizing people a few generations back (when game programming was done almost exclusively in Watcom).
In short: Visual Studio .NET is probably phasing out COM. This has absolutely no bearing on game programming.
--
Disclaimer: The above statement probably includes half-truths, because real truth is too complicated.
...that DirectX would go away and everyone would start using a more portable language like OpenGL or SDL...but MS would never let that happen and already have DirectX available for .NET
"Some things have to be believed to be seen." - Ralph Hodgson
Along with everything else said about the extra .NET layer, this will work out the same as everything else for developers on Windows: those who look for the best solution to their needs may or may not use it (probably not), but those who blindly follow Microsoft's push - the vast majority - will use it if MS tells them to. Unfortunately most developers only familiar with the Microsoft world do whatever they push. It may seem like COM is dying, but it's the underlying technology to all of .NET until they rewrite .NET to do all the work Win32 already does. So if you want to keep using COM go right ahead, it's not going anywhere for a long time. But Microsoft will be able to push the majority of developers to .NET simply because they'll listen to whatever they're told.
Developers: We can use your help.
..is a bunch of Java developers crying because they have wasted so much time with a failed technology (Java is dead).
Even the suits are starting to realize that if they can actually watch the dropdown box be drawn, it must be Java.
way back when .net was still beta and machines were at least 1/2 to 1/4 the speed they are today I saw a demo of Quake 2 models being rendered in .net flawlessly - and this was using OpenGL and an ultra craptastic laptop.
... but I think many games in the future (maybe 3-5 years) will be using .net simply because it makes developing that much easier.
.NET it actually ran slightly faster than my C++ code (probably because of being able to instantiate and destroy objects better). I am a big believer in .net and can't want for better cross platform support
Fast forward two years with Managed DirectX and you have a pretty decent system for writing games with fewer bugs because you are not likely to encounter certain errors (memory leaks for one). Games like Unreal Tournament 2003 and Doom 3 will obviously be tuned using assmebler and written primarily in C/C++
I have benchmarked some encryption routines I wrote in school back in the day, and they were originally done in Java. The Java code started much slower (stupid JVM - big issues) but once everything was in ram and cruising along it wasn't much slower than C++... with
Check your facts on the chopsticks.
t ensil/chpstck.htm
"Chopsticks were developed about 5,000 years ago in China. It is likely that people cooked their food in large pots which held heat for a long time, and hasty eaters then broke twigs off trees to retrieve the food. By 400 B.C., because of a large population and dwindling resources, food was chopped into small pieces so it could be cooked rapidly to conserve fuel. "
http://www.calacademy.org/research/anthropology/u
My understanding, from the corporate training and seminars i've attended, is that not event Microsoft believes that dot net is stable enough to run in life-or death situations like hospitals and games.
Seriously, ms will continue to support com because com works. Dot net is managed code for a connected environment. It is an easy environment to work in, whereas com is more challenging. Microsoft wants dot net to replace vb, server-side scripting and java, but they acknowledge that c is still more efficient.
It's not like Microsoft developers will have much choice in the matter. The new Visual Studio is bult around .NET, the title gives it away: "Visual Studio .NET 2003."
.NET because they overused it to the point that the term became essentially meaningless. With the newest VS, it boils down to you can use the .NET Framework (think object-oriented, component-based API), try mixing code from different lanaguages with CLI, and run C#. Oh, and it makes easier to use the still betaish ActiveX.
.NET Framework means wrapping your mind around what, for many programmers will be a new way of developing programs. Simply knowing objects by way of C++ won't cut it. Because of that aspect, I don't see that using old languages via CLI will help that much to get killer performance. And, as for C#, I've never liked it that nuch, and while I know lots of folks who will argue over its functionality, especially over Java, and vice-versa, I seldom hear anyone comparing it performance numbers to those of C or C++.
.NET will be the only tools they have for Microsoft OSs. But, will it lend itself to producing killer games? Maybe someday, but I don't see it happening for another couple of years myself. For now, were I a game programmer, I'd be sticking to C and C++.
But, what does that really mean? Good question, Microsoft is backing off from calling everything
Does any of that make sense for a game programmer? Maybe, but since performance is everything to gamers, I suspect it will be a while before we'll see such games. Learning how to exploit
Bottom line, yes, it will get used because for some developers VS
Steven
The rest of the questions asked have already been answered, so I am going to tackle "Is it really the end of COM?"
.NET under the hood...
Uh... Was Windows 95 the end of MS/DOS? Was COM the end of DDE? Microsoft has a tendancy to wrap up stale old code in fresh new interfaces and let their Marketing people slap a new name on it. Sometimes those interfaces aren't all that fresh; ActiveX was mostly just a rename of COM with a couple of extra methods.
So the answer is no. At least not right away. Maybe ten years from now, but by that time Microsoft will be pushing some new technology without admitting that their new thing has
- -
Are you an SF Fan? Are you a Tru-Fan?
VC++ 7 (which uses the VS.NET IDE) might work for games. AFAIK, VC++ 7 generates native Win32 code, while the other languages generate CLR code. .NET code is painfully slow.
I have no idea how fast VC++ 7 is compared to the previous versions, but I know for a fact it's way faster than C# code (and I guess it kicks VB.NET in the balls).
Some of the managed classes might be useful for some aspect of a game (savegames is the only thing that I could come up with right off the top of my head), yet
No, seriously, I just come here for the articles.
Here's one data point: When the SDK came out I compared the framerate of the DirectX samples in C with the framerate of the equivalent samples in C# (most of the samples are available for both, as examples).
.NET code lost some benchmarks, but it won a few and on the vast majority, they were within a few percent.
.NET to write games.
.NET, then they don't have to.
The framerates were very similar - the
There doesn't appear to be any huge disadvantage to using
One big advantage, however, is CPU portability - with two flavours of 64 bit CPUs just around the corner, plus different optimization strategies for P4 vs Athlon, having bytecode that gets compiled for your CPU when the game is run will be a big advantage if you happen to own anything but a P4.
It's doubtful that anyone's going to ship a game CD with an Itanium build of the binaries, but if it's
- Steve
This is great. So many "NO WAY! .NET IS TOO SLOW!" reminds me of assembly programmers saying "C++? Its slow and a memory hog! Games will NEVER be programmed in C++!!"
.Net, or even play some games that were made with directX and .net.
Well, you can read some books on using DirectX9 for
While computers gain more powerful hardware (faster CPUs, bigger memory, etc...) the coding for games will go forward to the newer languages that makes coding easier. You may not like it, but don't worry. There's always jobs for those with assembly knowledge.
And, for what its worth, I think game coding in Java will start becoming a reality in the next five years (and not just on PDAs and mobile phones)...
Good quote, too many chars. Seriously, the slashdot 120 char limit sucks!
While you might not be aware of this, cross-platform solutions have been used, are used and will continue to be used to develop games.
.NET? .NET gaming. Those who use DirectX because there is specific things in DirectX that they can't find elsewhere will move on to .NET. Others will realize that OpenGL is better than DirectX as an API for mostly anything (Don't flame me for the exceptions).
.NET and Microsoft is killing COM, then what future for games development on Windows?
.NET and COM programming in one step.
Will ALL Windows programming be done with
no. A whole bunch of DirectX developers that use it because they don't know any better will probably move on to
If games aren't developed with
For christ's sake... is developing games and DirectX now linked by some kind of godly power? Most of the good games out there (quake anyone?) have been built on multiple platforms and released on multiple platforms because their developers had a clue, which most developers don't. Having used Microsoft stuff for the past years is not a good point while trying to choose which library to base a project on. Finding the most portable and easy to use one is.
There was a discussion earlier this week about writing portable games here on slashdot. I believe you haven't read it so here it the main idea:
* If you decide to write a game from scratch, pick portable libraries right at the beginning of the project
* test that the project compiles and works on both platforms as it grows.
* keep bad code and unportable code out of the source.
That way you can probably get rid of DirectX,
to the 'net? we already know that the phonIE payper liesense softwar gangsters that robbIE is whoring for, are not.
I'm a lowly businessman, but at a Microsoft presentation they were pushing .NET as cross platform (Windows Mac and BSD). Would .NET games be significantly easier to port to any plaform with a .NET framwork?
Degaussing scares the bad magnetism out of the monitor and fills it with good karma.
.NET and C# are not interpreted languages, they get JIT compiled, this is very different from an interpreter.
.NET, once you have you will realise that the overhead is MINIMAL and wonder why you'd ever want to go back to using C++ again.
The performance degradation of using C# over C or C++ combined with Direct X is 95%.
The productivity gains of using C# for application development are potentially 30-50%.
Most games don't use modern CPU's and GPU's fully anyway.
There are so many comments in these replies that are just nonsense and obviously don't come from people who have actually developed software on
.NET is the future, but it's not here yet. It's great for writing small applications quickly, like those corporations use internally. The earliest Microsoft would switch over large applications like Office to fully managed code will be around 2007, because only then will most PCs be able to handle it. 3D games will wait at least a few more years. Right now 95%+ of professional game development is done in C++. COM interfaces aren't going anywhere.
.NET evangelist, would answer with "a resounding no".
In 2010 when we might see a serious move to managed code even in games, then COM might start to quietly go away. But thanks to COM interop via COM-callable wrappers, there will continue to be options for C++ developers for the forseeable future.
And if you utter the words "COM is dead" to any Microsoft-employed programmer, they'll tell you to stop being spoon fed by their awesome marketing division. Even Don Box, father of COM and star
You're a chopstick. How can someone move from .NET to chopsticks? Seriously...I'm calling the BS flag on you.
"Chopsticks were developed about 5,000 years ago in China."(http://www.calacademy.org/research/anthrop ology/utensil/chpstck.htm)
"During the Middle Ages, aristocrats often favored silver chopsticks since it was thought that silver would turn color if it came into contact with poison"(http://www.factmonster.com/spot/chopsticks 1.html)
And no, the "middle ages" were not invented by americans in the late 1800's by amish asian's to distinguish differentiating time periods.
"Middle Ages, period in Western European history that followed the disintegration of the West Roman Empire in the 4th and 5th cent. and lasted into the 15th cent"(http://www.burstnet.com/cgi-bin/ads/ad10126b .cgi/2089/RETURN-CODE)
Yadda, yadda... fall of rome, some time in the "middle", then the 1500's...basically, a long time ago... not so much the 1800's.
Decaffeinated coffee? Kinda like kissing your sister. - Bob Irwin
No chopsticks for you, lazy non-reference-checking fool.
That's the most ridiculous thing I've ever heard. You're probably confusing 'chopsticks' with 'fortune cookies'. But even then you'd be wrong, since they were invented by a Japanese American in this century.
How could an entirely new form of eating utensil take off like wildfire throughout all of east Asia in just 200 years? If they really had that kind of traction, they certainly would have become popular in the US, Europe, and the rest of the world too. You think some uneducated peasant in rural china is going to stop eating with their hands (or whatever) and adopt hard to use chopsticks in order to be 'cool'?
Do you think that the Japanese, while trying to modernize and westernize would replace all their eating utensils with something used only in Chinese restaurants on the west cost of the US?
In conclusion, you're an idiot.
Oh, and Chopsticks were developed about 5,000 years ago in China. It is likely that people cooked their food in large pots which held heat for a long time, and hasty eaters then broke twigs off trees to retrieve the food....By A.D. 500, chopstick use had spread from China to present day Vietnam, Korea, and Japan. The chopsticks to the left, while Japanese, are rectangular in the style of Chinese chopsticks.
autopr0n is like, down and stuff.
Personally, I've coded using managed DirectX 9, using C# for Visual Studio .NET (2001).
.NET yet.
It works great, and I would go beyond the proof of concept/prototype stage, except for the #1 problem: the framework isn't automatically on the desktop yet.
This means more than the performance or features arguments you'll hear from lots of folks. # of desktop installs is key in this case. Fact is, there is no version of windows for users where the framework is there by DEFAULT. Option install = no coding
So, I'm ready...I'd like to code in it NOW, but alas...maybe 2 years away. RELEASE FREAKING LONGHORN SOONER Microsoft! The game community will wait until that happens, IMHO.
Take threading in
When other tools are used like XMLSpy, it works just fine. The default mode for schema creation in VS.NET is to convert everything to a flat table, rather than declare complexTypes and reference those types in top level complexTypes.
This same question was asked of Java back in the day. In fact, I believe ID Software was planning on releasing a version of Quake written in Java. Then came the realization that 3D rendering that pushes hardware to the limits will never be achieved through an Object Oriented Language. It does not have to do with the fact that Java or
1.
2. is there an equivalent linux software solution that one can compare
just a thought.
Writing lightening fast engines optimised to a specific console is only one small part of writing a game.
Writing tools that an artist or designer can use to create content for said engine is a big part (and set to get much, much bigger).
Anything that speeds up the process of getting tools into the hands of the creative people is a Good Thing(tm)
You can still make regular C++ programs with Visual Studio .NET and not have to use the .NET framework.
.NET framework is useless to a game programmer. It adds a lot of bulk and crap that you don't even need in the first place. The first thing you do to make a game is to #DEFINE WIN32_LEAN_AND_MEAN which takes out all the crap. Then you create a window and use DirectX through it.
.NET Framework is basically dumping a bunch of more libraries and components on top of what you already have, increasing the overhead and forcing you to compile into a not-quite .exe
Otherwise,
Looking at the way the CLR works.. you could I guess make a cross-platform game that way. But who cares? All the hard-core gamers have windows boxes and are interested in getting the most FPS out of their games.
As far as I'm concerned, if you really had to break down and use some windows stuff, you could put the MFC crap in too, but it's going to slow down your game.
It's decent for apps but games are high-performance.
Will Pat get a job once he graduates from the mediocre Brandeis?
The answer is no.
There are plenty of reasons why and why not to make a game on .NET. They aren't good or bad just different.
.NET API calls directly onto the OS layer is that they are really just wrappers on the Win32 called via PInvoke. So while the .NET binary maybe portable to whatever platforms that can support the CLR, the underlying Win32 calls need to be supported.
One of the issues with Direct X and other
So the MS dream of a write once run anywhere game is still a bit off. They still need to port Win32 to platforms they are targeting. Maybe this will change in the future but that will progress (or regress) to the mess Java had with UI.
The .NET framework on Windows is entirely dependent on existing Win32 APIs and COM technology. Although Microsoft is encouring people to drop the use of COM and Win32 APIs, they themselves heavily depend on these technologies. As it is now, the .NET framework is just a wrapper around existing APIs (COM and Win32). The C# comipler has been implemented using COM, csc.exe being a wrapper around this COM C# compiler. The VS.NET IDE depends heavily on COM. The .NET framework is huge (more than 3000 classes) but only 15-20% of APIs have been covered by these classes. Apparantly, that is enough to write usual application.
.NET where in I argue if there was a real need for MS to come up with .NET. The statements I made above have been backed up in the article by providing links to the comments that MS employees have made about this.
<plug class="shameless" >
I have written an article called Whats the need for
</plug >
Jalil Vaidya
Rember how many years before game programmers moved away from dos booting games to windows games (for performance reasons) the same thing will happen with dot net. Ask me again in 5 years.
love is just extroverted narcissism
I had a similar question when I was first learning Java; Java works really well for modeling something, while C/C++/Asm work great for speed, so why not use Java for high level game logic and use low level stuff for rendering, calculations, etc (stuff that needs the raw power).
Well it turns out there are game dev studios that already do this. In fact I went to a talk by James Gosling and he talked about how one release of Java was called the "Harry Potter" release, because the game Harry Potter used Java and something while developing the release was broken such that Harry Potter wouldn't run, and they had to fix it.
Anyway, why not do the same thing here? Use C# for high level game logic, and use C++ where needed for stuff that needs to be tuned performance-wise?
As a game developer, I am/will use the heck out of C# and .NET to develop software - just not the runtime portions of my games.
.NET allows me to use or not use various parts of the run time (assuming that we architected the interfaces correctly!) in a way that can both maximize usefulness (it looks like it will in the game!), and unit test the game code in a better environment.
.NET are robust enough for these - the .NET IDE proves that.
.NET are better for windows app development - either you have done it, and understand why MFC and C++ blow chunks, or you are in for quite a pleasent suprise when you write that first tool.
Tool development takes up an increasing amount of my team's time. We have custom tools for art manipulation, sound manipulation, and data warehousing. Not to mention our tool for level creation, which we hope to release with the game. All of these tools need to be robust, have clean interfaces, and be developed and changed quickly, and grow with the run time modules.
Remember that C# and
I won't go into why C# and
-Donut
You could always try SDL.Net if you really must use .Net (it's reasonably fast)
We installed the 8.x version of Timberline, our accounting program.
Not only do you have to reboot each machine about 6 times during the installation (not to mention the installation that required rebooting the server 6 times), the program now requires like an insane amount of RAM and hard drive space, but NOTHING has changed.
All Windows programs are going to be using
I love how fast 'raw' Win32 apps are...
Even in managed mode, the bulk of the work is done in the very much optimized libraries that DirectX consists of. So it is highly unlikely that .NET-based games would be slow.
There may be a problem in A.I. or any other routines that are not-hardware assisted, but with the current level of CPU power (and the future one), this is hardly a problem.
From a developer point of view though, I don't think using SDL+OpenGL is any different...at least you get the additional benefit of the app being cross platform. I am learning SDL today (well, it is very easy, I have already learned it), and I am going to seriously dig in OpenGL from tomorrow, since it is a cross platform solution.
I have been using .NET since September 2001. I wrote an open source 3D engine using C#. It makes use of BSP tree visibility culling, it uses WorldCraft as a level editor, it supports OpenGL and it did support NVIDIA's Cg until they changed their interface. When I released this engine open source back in February 2002 I stated clearly that I thought that .NET would be useful for game development.
.NET 3D Engine
ExoEngine - A C#, OpenGL
PS. Some people notice that in the screen shots the engine is only getting about 10fps or less. This is because it was running without 3D hardware accelleration.
"Based on .NET technologies" is a far cry from being actual .NET code. Does AC2 require the installation of the .NET platform to run? If not, I kinda doubt it's actually using .NET anything under the hood.
Roll your own chat protocols then. It says nothing on what that code is using - is it Web Services? Remoting? Else? This isn't .NET's fault - its chat developers fault.
As authoritively documented on that red sleeve thingy and, more mundanely, on Access Asia.
Sounds like bad code unrelated to the underlying infrastructure. Why does chat have higher priority than game-required packets? Why is the game so sensitive to CPU utilization? Does the networking code account for a high number of dropped packets requiring retransmit?
A bad design in one application != a bad programming API.
Uh...no. You seem to be the confused one here. DirectX was for a long time based on COM, and therefore many many games currently use COM. I think this is what the poster was originally referring to.
Having byte code is like having the source code.
You can take preformance stats and recompile during runtime for a faster slicker application. For that reason byte code should always produce a faster application after a few runs than pre-compiled code.
thank God the internet isn't a human right.
With regard to any great new MS technology:
You can play with it earlier, but you'll be a beta tester, helping to iron out bugs, performance bottlenecks, desperately needed new features, etc.Some people like living in that world for the rush, some people don't have the patience for it.
"Provided by the management for your protection."
Nuff said. .NET rulez.
How many highgrade professional games are written in Java currently?
Do you claim that Java platform games such as Cubis and Bookworm available at Yahoo! Games either earn low marks, or are not written by professionals, or both?
Will I retire or break 10K?
By naming their new framework .Net and focusing marketing on XML, MS has taken advantage of the hype that everyone's eyes are currently on to produce a radically improved API. I'd say
The truth is that Visual Studio 7 is the most comprehensively advanced programming environment I've ever seen and it easily supports a 10 fold increase in programmer productivity versus VS97 due to the quadruple whammy of what I see as Microsoft's first truly pro editing environment, a near complete elimination of language wars by forcing all to be equal in capability and to share objects, a far more comprehensive and easy to use object oriented API than Win32, and the end of the registry and associated DLL hell.
While everyone's watching the bouncing hype ball, 95% of what's good in the framework has been ignored. I believe this is Microsoft's intent.
Where will they go? In two to three years I think we'll start hearing about an OS release that has a CLR interpreter that doesn't run on Win32, but has everything needed natively present to run directly on a kernel. Suddenly, all of the .Net code will be vastly faster and Win32 will be scheduled for deprecation. .Net has nothing to do with the net or with XML, it has to do with replacing the Win32 framework with a new framework. For now, its a framework running on a framework and will thus be slow. Eventually, it will be THE framework doing nothing except what IT needs to do and will cook.
As much as they seem to gripe and make noise about other .Net framework implementation efforts, I think they are really hoping that its done and everyone converts to it. A .Net application running on top of a .Net framework running on top of any of Win32, Linux, or OSX will never be as fast as a .Net application running on a .Net OS. If done with enough slight of hand, its a perfect recipe for a complete coup.
DirectX is based on COM. It uses COM interfaces to encapsulate its routines.
One of the reasons why I hate it.
N4st0r, trixx0r h0bb1tz0rz! Th3y st0l3 0ur pr3c10uzz!
A while ago our MS rep came in for his bi-monthly visit. And he let something slip.
.NET datatypes.
...
.NET server which would pass the 'package' on to the reciepient. [This is all out of memory, which is fuzzy .. so who knows if im getting it all EXACT.]
.NET server (which our REP said would make it a lot more secure than it is now .. har-har) then WHO is going to be making those servers ?
.NET now .. because simply - if it DOESNT get widely adopted than Stage II(tm): Take over the server market by making the desktops REQUIRE MS.NET routing servers, will be as successful as Licence 6.0.
.NET [or Dot-Nyet as my russian friends call it.] is kinda neat. Once you get used to the 10-15% loss of speed. And the higher memory requirements on your servers.
The next desktop version of windows is supposed to be a database structured OS. SO basically everything from word documents, to e-mail, to images are essentially
Sounds kinda cool actually. Now walk with me
Any file could be shared with another computer, by basically sending it to a 'routing' computer.
So e-mail wouldn't be like it is now, nor would web pages, they would be sent to a
What I do remember with shocking clairity was having the epiphany that if everything has to be routed through a
MS is pushing SOOO very hard for
Whats the easiest way to get rid of Apache ? make windows not play with it. They can't control the *nix OS's out there, and they cant put the genie back in the bottle, but they CAN alter their OS to ignore the genie, and maybe make it look like he is wearing a dunce cap.
That being said.
I'm just afraid that this innovation in programming languages is more about gaining control, than improving computer science.
After all - most of our cars still run on gasoline WHY ?
--Ne auderis delere orbem rigidum meum, non erravi pernicose!
We shouldn't be looking at how current implementations of .Net would slow current methodologies in game development.
.Net, there is definitely going to be a use for XML.
.Net currently, it seems to be more of a developing mindset than a language for commercial use right now (as a developer, I infrequently recommend .Net unless there are specific reasons to go with it). Think though how these tools can apply to tomorrows development (both game, application, and networking) methodologies.
I remember back in the 80s receiving an apple magazine with printed basic code for games. It was great, you could always reference the code line by line, very simple.
How could we get information out if we're using this new "object oriented" design? Modify class X with method Y and add the following code?
It's a bad example.
With the new Gigabit ethernet going straight past the PCI bus on new motherboards (875?) we are being given a unique chance to utilize remote computing abilities and storage.
CLR is in it's early incarnation as v1.1. When did we all start respecting DirectX (some of us still may not) over openGL as a graphics standard? For me it was probably around DirectX5-7.
Optimizations to the CLR don't have to be done in each language that compiles into it, but in the CLR itself.
In response to some comments about XML usage in
When building BSPs for games, character models, maps, assets, and other game information, we will eventually be able to bring models over from one game to another thanks to a common language (XML) and possibly common framework (.Net).
I'm not a big proponent of
M$ wants .NET to be the term, then they can copyright the interfaces
Really? For example, copyrighting Webster's dictionary does not give Merriam any monopoly over the English language. Languages are an idea, not an expression, and any copyrightable expression they do have would likely be swallowed up in fair use. Precedents include Lotus v. Borland for menu structure and Sega v. Accolade for program headers. APIs can be patented, but Sun's Java technology is prior art for most of what Microsoft's been doing with the .NET framework.
Will I retire or break 10K?
That was the most paranoid and ill informed rant I've ever read on slashdot. The facts about the database elements of the next Windows OS are all over the internet. It's nothing even close to what you're talking about. It's simply an improved file system.
Screw you. I'm a VB developer, and I'm sick and tired of the instant dismissal of VB as a platform. I have seen so much shit code produced by Perl, C, PHP programmers, it's almost mind-blowing. In the "real" programming world, where the business line wants things done yesterday, VB kicks the ass off of most other languages for speed and ease of maintenance. In summary, FUCK OFF PROGRAMMING ELITISTS!
Ok time so set some of these misconecptions straight. .net is all they see but guess what. DONT USE MANAGED EXTENSTIONS IN C++ IF YOU DONT WANT IT TO BE MANAGED.... To compile to native code in vs.net2003 for c++ you just dont use managed extensions and then you set one compiler flag and Viola you have a win32 native binary. a win32 application is even an option in the new projects menu.
;
1 as long as we have dll's we will have com thats how things work. The next version of windows will actually keep multiple versions of dll's so i dont see how we are getting rid of com any time soon.
2 You can compile un-managed c++ in vs.net 2003 I know for some people the
3.DirectX 9 is both managed and unmanaged. I cant say this for absolute certinty but I believe that the only thing the managed extensions for DX9 are is a series of wrapper classes which makes use of the DX9 dll and lib files. WHich would once again be com. We also have to realize that dx has applications outside of game programming also. The only thing dx is(which isnt a small thing) is a set of wrappers to access hardware, You cant even call them classes because of com. It just makes it so you dont have to worry about 5000 different joysticks when your programming an app.
Granted OpenGL is better for graphics than dx. HOWEVER you dont have input libraries/sound libraries/networking libraries in OpenGL.
TO a comment earlier that said c# is an immature java. I say that statement is entirly off. Ive been programming java for about 2 1/2 years and c# since its initial beta days. Ive worked with a large portion of the JFC and the BCL and I can tell you that the BCL is far nicer to work with. There are things that are totally missing from java like say a representation of a 3d point? or how about a datastructure that represents a cube. both are very simple things that are found nativly in the BCL. Windows.Forms put swing to shame and there are no tools out there that compare to vs.net. Its a superior ide on most levels. Also while it retains some syntactical similarities to java c# is far from being a java clone. C# has what I like to call smart properties which actually can use left and right assignment justification as opposed to java with all the get and set method stuff. Its a waste. Lets see ohh also no operator overloading in java..... But wait its in c#. The bigest thing of all POINTERS. In c# you have access to pointers while java totally blocks them off. A major point I see over java which made a stupid mistake about this in the first place is.... In c# everything is an object and can be placed into a container. Those who have worked in java know the pain of having to store characters in a vector by doing
Character myChar = new Character(myCharVariable)
charVector.add(myChar)
wouldent it be a lot easier to just do
charVector.add('a');
Well java had performance issues with doing it that way. Which I should be grateful they did it that way since if java got any slower it would be unusable.
Well thats some fact and some opinion ill let you sort out which is which. Its also nice to know that in a year and a half c# has provided more functionality and an easier to use set of class libraries than java has since its existance (something like 10 years if im right)
For an example of a Simulation, check out the Terrarium application. It can be found at "GotDotNet" (http://www.gotdotnet.com). I think it provides an example of how .Net can "shine" as a Game Development Platform (extensible design, peer to peer communities, etc.).
tired of that...
Think about it: a bootable CD that has the Linux kernel, drivers, support libraries and your game code.
The two CONs you mention below are show-stoppers:
Game developers may start developing drivers again. (**shudder**)
Will it have drivers for video cards, sound cards, and network cards released two years after the game is published? I don't think so.
No downloading or listening to MP3's in the background
Consumers expect to be able to print, download, etc. in the background while playing a game, or to pause the game and "change the channel" so to speak.
Will I retire or break 10K?
...it is buried right next to BSD. :-)
I am very small, utmostly microscopic.
Unless, of course, you're programming your game using, oh, DirectX, which is all COM.
Vintage computer games and RPG books available. Email me if you're interested.
COM is a royal pain in the rear to code in. Noone denies that it is needlessly difficult to do, so I for one will not mourn it's passing if indeed this is what happens.
Not far enough. No. Probably not. Adapt or die. Eventually, but not at first. It is bright. Yes, or some equivalent.
Most definitely, in fact there already is DirectX for .NET -- it is called Managed DirectX. Microsoft developed version 9 to have an entire set of "Managed" components. These are used by the .NET Framework. I have been using the .NET Framework, C# and ASP.NET since October of 2000 (ASP+ at the time and Beta1). I have been using DirectX since version 5 and was involved with the beta testing of the Managed DirectX since June of last year. It was released in December. I am currently writing a 3D level editor and game using C# and Managed DirectX. The code is much more cleaner than typical C++ code. Since memory is managed there aren't any memory leaks and I have found that most things are just fine with that. However, if there is a part of the program that needs to be sped up (which isn't as much as you might think) then it can be done with "unsafe" code within C#, or even talk directly to unmanaged C++ code.
Either way, the point is COM programming will be going away -- BUT -- it isn't going to immediate, nor does it need to be. The interops in place allow any COM object to be easily used as a .NET assembly. Don't worry, game development on the Windows OS will not be going anywhere any time soon. .NET will help make more robust games, not hinder.
Haven't you people ever played Donkey.Net??? Nothing like driving your car arouns a small 3D area trying to run down donkeys.
I've done some .NET work, and it's apparent that it's designed with security in mind (how cleanly only time will tell).
.NET program. Try just writing the program to do it. Then tell me how you did it, because I couldn't find the API.
Accordingly, it omits many simple functions that you'll find in other Microsoft libraries that access the machine.
Try changing your screen resolution from within a
What you much ralize as well is that you CAN force a .Net binary down to native code. It is still dependent on the .Net DLL (MSCOREE.dll). I have not really had a huge amount of time to experiment on the difference in speed, but it seems like it is possibly an option.
.net core dll it is because it still handles all the errors through it.
BTW if you are wondering why it is still based on the
http://sourceforge.net/projects/cs-sdl/
Adding more to the performance hits i encountered through the last year working with framework is a synchonization point needed for the garbage collection. It is well known problem when GC needs to stop all managed thread to move memory around.
Not to mentioning that it's a nightmarish headache to mix managed and unmanaged memory structures in one programm.
In short: Will you try to programm resource requiring game you will soon sorry you choosed this platform.
I'm not a brake. I'm an accelerator. Just a slow one...
"While computers gain more powerful hardware (faster CPUs, bigger memory, etc...) the coding for games will go forward to the newer languages that makes coding easier. You may not like it, but don't worry. "
:-P
Yeah, someday they might use Perl. Oups, already did that....
Having played a little with Managed DirectX 9 and C#, I can honestly say that first impressions are that while it may not be faster at runtime than C++ (people have argued black is blue against this, however, and report C# & DX9 running faster than C++ counterparts - search gamedev.net), it is certainly much faster to write the drudgery (D3D/DInput initialization, device creation, event handling) with C# and DX9.
Admittedly, it might not be ready for the lime light just yet. But as games get bigger and more complex, and the speed of computers driven ever upwards, I would predict that languages like C# and APIs like Managed DirectX will emerge simply because it's faster to write. Faster-to-write games means more content in same amount of time.
But by all means, try it before you decide against it.
Most people attribute the creation of the fortune cookie to a Japanese American in San Francisco. In 1914 Makoto Hagiwara introduced cookies bearing thank-you notes at his Japanese Tea Garden in Golden Gate Park and served them at the 1915 Panama-Pacific Exhibition, San Francisco's world's fair.
However there are others who contend that David Jung, founder of Los Angeles' Hong Kong Noodle Co., invented the cookies in 1918 as an encouraging treat for the post-World War I unemployed who gathered in the street.
Most people go with Makoto Hagiwara as the inventor though.
This post sponsored by Ninja Burger. "
I work for a company that develops console games - and our codebase is shared across several platforms. Recognising that the article is questioning the use of C# in games (not .NET, Visual Studio .NET does C++ with no problems), C# is useless to us until a compiler is available on all of the platforms we want to develop games for. I don't see the mortal enemies of Microsoft on the console battlefield - Sony and Nintendo - supporting C# in the near future (if ever).
:)
This is an area where something like the D language could do well, as it's a modern language free of Microsoft's stranglehold.
Even better, there will be SDL and OpenGL for Mono and C#; you can certainly write games in those.
Ah, but MS doesn't care if anyone else develops games for PC or any console system.. they've spent millions and millions of dollars hiring the brightest people who would go over to the Dark Side, including some brilliant tabletop RPG people (Jordan Weisman of FASA/WizKids and Mike Pondsmith of R Talsorian . They ran the most excellent online immersive "RPG" promotion for the AI movie (referred to its fans as "The Beast".
So, the bottom line is, MS would probably rather third-party game development stop so that they are the only choice for consumers... which is Redmond's strategy in every other type of software.
It should be. I don't see any reason to proliferate more COM into the world. We still need to interoperate with COM, but I hope no one is building new COM based apps!
Will ALL Windows programming be done with .NET?
Was all Windows development done with COM in the past? No, so why would ALL new Windows development be done in .Net?
Will games be developed with .NET? If games aren't developed with .NET and Microsoft is killing COM, then what future for games development on Windows?
Was COM really all that usefull for game programming in the first place? I doubt the death of COM will make much difference to most game developers.
Read the Fucking Marketing?
No, but it has been said that .COM signalled the death of NET... :-)
Employee of Inrupt, Project Release Manager and Community Manager for Solid
MS created a neat little game called Terrarium to showcase .NET. So they probably do envision a future for games on .NET.
Terrarium
It's 10 PM. Do you know if you're un-American?
What is .NET ?
:wq
For those systems, the interactive basic interpreter would probably be considered what most people thought of as the OS.
If I remember correctly, a number of C64 games were launched directly from the basic interpreter.
LOAD "MYPROGRAM, 8, 1"
or something like that.
As far as the Atari, the reason you directly booted into games was that with only 64k of memory in the system, you *needed* to displace the basic interpreter and free up 16k of RAM that it occupied. It still loaded a stub of the DOS (for disk access) and then would autoload any file named AUTORUN.SYS
Additionally, since the OS was ROM based, the systems were "instant on" (or very close). So shutting down the system to play a game (and vice versa) wasn't a huge deal.
Nowadays, I have a computer with 512Mb ram, and it takes a little bit to boot into the OS, so shutting down the system just to play a game seems stupid. As another poster pointed out, thats what consoles are for. For a general purpose computer, not being able to launch games alongside with other apps would be annoying.
Actually the recommended technique is to load each compiled schema into a new AppDomain, which then uses remoteLoader to load that assembly. If you don't do that, it won't work because it won't unload the assembly. By using a separate AppDomain, it then allows you to unload and reload an assembly. Here is an article that talks about it.
"Will there be DirectX for .Net?"
Yeah, I'm staring at my sdk cd right now. It's called DirectX 9.0. You can get it off msdn.microsoft.com.
iRooster, the Mac OS X a
...more like NotYet!
A big improvement in Direct X 9 is the ability to utilize DirectX 9 in .Net managed code. Download the SDK, it has a lot of good tutorials on this subject. I'm not sure how the performance of this compares to unmanaged Direct X, but if speed is an issue, chances are you're not seriously thinking of managed DirectX anyway.
The Hadmacker
Uh, unless you use DirectX. Which is all COM based.
I prefer cross platform technologies, regardless.
Galileo: "The Earth revolves around the Sun!"
Score: -1 100% Flamebait
Um, it's a tool. Masters learn to use tools to their advantage. As has been nailed into your head already, there already is DirectX for .NET.
Work is calling.
Control the GUI front-end is what MS has done (pretty succesfull) for a long time. A next generation of advanced user interface will obviously happen on the front-end, and they need lower level access to the hardware support. Will a 3D view of an explorer get out of the research labs and make it to the desktop?
I wonder if mono can keep up with this. The lack of a good GUI support with C# mono might become a real obstacle. To move closer to the desktop a lot of good high performing GUI code is necessary. I know there is the GTK# mapping and the WINE struggle. But what about a directX equivalent on the free unix os?
Let's not get too academic. Let's not have the corba failure (too complicated, overdesigned). Will OpenGL do the trick or is this also too complicated.
Change Mono to Stereo and get some dolby filter in there.
Most people miss the big picture for .net because of Microsoft's early hype about web services. Here's the overall plan:
.net framework as possible, stop updating the Win32 API and mark it deprecated (doesn't mean you can't use it, but the official word will be to avoid it for new development). Eventually start changing the underlying system to be something other than Win32, essentially making Windows be a .net environment. This is how Microsoft is going to deal with eventually getting rid of the crusty old Win32 API.
.net, the processor is irrelevant. You can write applications for .net and get them running on Pocket PCs and other devices with minimal effort. Remember, Microsoft supports SH4, MIPS, PowerPC, and ARM processors for Windows CE.
.net is simply going to cause you pain. The sooner you get comfortable with it the better.
1. Move as much Windows programming to the
2. Now that everyone is writing for
In short, avoiding
You're ignoring the fact entirely that DirectX is, in fact, a set of COM objects. Games use COM extensively because of that.
He is thinking about chop suey - not fortune cookies like others have speculated.
There is an extensive article about the history of chop suey on snopes.com that refers to it being served to miners during the 1800's.
http://www.snopes.com/food/origins/chopsuey.htm
Here's another idea: instead of just games, what about digital media - you know, images, movies, mp3's etc...
Such a scheme would make DRM obsolete. Think about it - how do CD's get copied now? The user boots into his OS, and then reads the CD with said OS. With a bootable, encrypted CD, OTOH, there is no OS available to facilitate copying. If you booted into your OS, you could perhaps make a bitwise copy, but even then, you'd still be left with an encrypted image.
The society for a thought-free internet welcomes you.
1) There is no "destructor"
.NET Framework Programming".
2) There is a time limit for Garbage Collection. I believe it's 40 seconds... If ALL Finalizers are not finished in 40 seconds, it just takes the memory back without calling Finalize.
I get this information from Jeffrey Richter's book "Applied
T
---- It puts the lotion on its skin or else it gets the hose again. It does this whenever it's told.
Is .net relevant to anyone?
Any gaming company that wants to stay a step ahead of the others will probably write the rendering engine in C++ in order to milk the latest and greatest processor. But the productivity benefit of a managed language probably will entice game developers to write the overall game in a .NET language. This can provide an edge for a company when they can make a game world twice as detailed and large as the competitor.
.NET has one purpose. To pull all windows programmers into the VB World. You see, C/C++ developers have skill that is just too dangerous. It allows them to write software that competes with things like MS Office.
.NET,
COM was just a mess invented to try and make it easy for VB-ers and C++'ers to share code --- HEAVILY weighed towards the VB side. Even some of the early COM MSDN help files COMPLETELY ignored C++ developers. Every try to use a decent COM object that passes multiple references from ASP? Along comes ASP.NET to fix that problem, though....for a heavy price.
Anyone who has been through dBase, Foxpro, Clipper, etc, etc, knows that runtimes, clrs, or whatever you call them are always, by nature, slower and more limiting than C++. Good luck implementing low level hooks, drivers, or any other needed OS enhancement/work arounds in
unless, of course, MS has seen fit to let you.
The .NET Framework is a replace for the Win32 API. Microsoft realized that the Win32 API had a limited future. Above all Win32 was built on Win16, and still cares alot of baggage.
.NET Framework is largely stubs for Win32, but overtime everything will be rewritten. This will also make the entire API portable (thanks to the CLR), and in time you will see Microsoft move beyond Intel processors.
Microsoft then decided to build a new API from scratch, taking into account everything learned in the last few decades, including lessons learned from Java. Writing a full API from scratch is a big task, so much of the current
if you are developing software you expect people to download, like me, .NET forces users to get a 23meg runtime from microsoft! No modem user is going to take that seriously, so if I want people to even glance at my trial vesion, it needs to be small enough to download. VB6 runtimes are small enough to not piss off most modem users now, so I am forced basically to stick with VS 98 until all versions of windows for the last 10 years have CAME with .net already installed.
Morphing Software
Microsoft has DirectX 9.0 SDKs for C++, C#, and VB.NET. You can even code in C# or VB.NET and OpenGL.
You missed the point. The chat software was written by Microsoft for inclusion into the game and was presumably written using .Net compilers...and it didn't work.
.Net how can the rest of us be expected to?
The point is that if Microsoft can't figure out how to write things that work under
Reason 1: The forthcoming operating systems currently under development at Redmond are going to ensure that all Windows programs use .Net in some way.
.Net runtime) have been executing it as a process. In the future, the CLR will be one of a very select group of processes that will be allowed to interface the kernal, and affect kernal-mode instructions. If you think NT-based systems are protected now, wait until the CLR becomes the runtime for the entire OS and Intel delivers the so-called "Palladium" encryption chip (which is being designed in concert with the next Windows system). The obvious entities that will be allowed to interface the kernal (or rather the kernal will interface them) will be the hardware drivers. The .Net driver framework is not yet publicly available, but rest assured, as soon as Microsoft is ready to unleash Windows .Net, Win32 drivers will not be allowed to interface the hardware. All drivers will be signed with a public key and require a cert to install. Don't have a cert? Sorry, "This is not a Windows driver"
.Net dynamic libraries are signed with a public key. What that means, folks, is that the CLR will be able to verify the author of each and every dynamic library against a certification issued by Microsoft or one of its partners/acquisitions. Forget home-brew apps, they simply won't install and run on .Net Windows OS without a cert, unless MS decides to allow them to install as "unmanaged", in which case they will not have any control over hardware outside of the .Net API, and they will likely have severe restrictions as to what they are allowed to do with the filesystem and communications ports. Oh yes, and the windowing system will be controlled by the CLR as well.
.Net objects will you be able to do anything outside of raw math or data organization in your legacy code.
.Net framework in order to load and use the drivers efficiently (else they could just proxy through .Net, but hey, why proxy when you can just recompile?)
.Net is *NOT* a competitor for Java, it *IS* a wholesale replacement for Win32 and the current Windows operating systems. It has promised support for legacy, but all Win32 legacy will operate through .Net proxies to .Net objects. So no matter how you write your program, if you want it to run on Windows, it *WILL* rely on .Net
But how? You ask? Thus far, systems running the CLR (the
Conclusion: you will not be allowed to interface hardware from "ummanaged" code (because MS says it is "dangerous" to let you do so), and if you could, what would stop you from running viri from the sandbox?
Reason 2: All "unmanaged" code will execute in a sandbox.
Now, all
Conclusion: only by interfacing
Reason 3: Alternative rendering platforms like OpenGL will have to be implemented within the
I believe this is very likely to happen, because Microsoft cannot reasonably refuse to allow competition in this manner without more courtroom appearances (boy, they really took it hard last time though, right?). So you will likely be able to choose something other than DirectX, but I can almost gaurantee to you that DirectX will mysteriously outperform any and all competition. Why? Microsoft has the CLR code, and can easily add undocumented interfaces that allow DirectX to scream and everything else to crawl. They've done it before with Win32; they'll do it again I'm sure.
Overall conclusion:
Please, can anyone supply facts or hyperlinks to confirm this guy's claim that chopsticks were invented in the 1800s?
I really need someone to tell me!
You have amiss conception not all jvms fully intrepret..
IBMs also do JIT as well about 40% of the time..
So does MS's own JVM as well..remember that?
Don't Tread on OpenSource
It seems our good friends at Redmond have taken a day off and are posting loads of crap on /. to promote .NET.
.NET with many collegues in academia and industry.
.NET. We have to change the way we do everything! Couple that with lack of the .NET framework on most client machines and you have a disgruntled developer community. Microsoft wants a revolution in (2) when people don't want it to happen. The development process for Java is 10 times simpler than C/C++/MFC and people are willing to sacrifice control. With .NET, you lose a lot of the control AND development is horrible.
.NET have all the features I really wanted in Java before I understood the clean symantics and logical structure the author's wanted.
.... release VS 7.0 or risk a crippled developer community. Any would-be Borlands, feel free to be the king of the market because MSFT won't release VS 7.0 (without the .net support) until hell freezes over. Also, please consider getting rid of GC in C#. Make the language simpler by getting rid of redundant features. Free advice ... if you want to win, KISS!
I have spoken about the role of
1) Server-side Software lends itself very well to the Java Platform. This is because of Java's maturity, cross platform capabilities, ease of use and vendor support.
2) Client-side GUI's and standalone application are mainly developed with C/C++ using MFC.
3) Web apps are still a contested field. Java, MSFT and others (like ColdFusion, Pervasive Tango, Flash) work well for some parts of the problem and suck for others.
My main concern is (2) above. Most hardcore C/C++/MFC folks are not going to move to
I like the comment that "C# is like an immature version of Java". The comparision can also be made at a platform level. C# and
My suggestion to MSFT
.NET refers to application based on the .NET Framework. This does not mean that the source code for the application was written in the Visual Studio .NET IDE; in fact, an application's source code can be written in Visual Studio .NET and not utilize the .NET framework.
.NET is a .NET friendly IDE that is itself built on the .NET framework. Developing .NET applications requires it no more than writing an Office XP document requires Windows XP.
Visual Studio
Breakfast served all day!
Dude, you have no idea what you are talking about. Please don't post a bunch of fallacy. What, did you install Visual Studio .NET and then put it on your resume? ... blah
Anything Microsoft does from now on should be seen through the longer lens of Windows DRM 2005, or whatever it's going to be called, which will require people to buy brand new Palladium-equipped hardware and will be incompatible with everything that now exists. Somehow they expect to convince everybody to do this, including the 40 million people who are still happy running Win98 on P100's.
.Net really matter as Bill and Steve hold hands and drive their convertible off a cliff?
In other words, Microsoft has finally gone insane. Does
If that was a "5 Informative" then all hope is lost around here.
The poster was talking out of his (arrogant) ass.
first COM, then .NET, what's next? .ORG? .GOV (forced compliance with PATRIOT act) ..?
Is .NET Relevant to Developers?
Not Me..
I work at a huge game shop.
.NET quite extensively for tools. Our pipelines are Win32 based, and with no plans on changing that. The speed provided by the CLR is on-par or the same as their C/C++ countparts. The benefit we've gained is a much quicker turnaround on development and maintainence. Adopting .NET for tools has been a solid win for us.
.NET interface to DX9 seriously, in my opinion. Don't get me wrong, initial tests, along with vendor propaganda all indicate promising performance -- we just have so much vested interest in our C++ libraries... and the fact that the performance isn't 100%... Code portability is quite important to us. Remember that the PC game market isn't actually all that important. Consoles make the game industry... and as much code as we can write should be directly portable or applicable.
We use
Nobody has taken the
Just my opinion, I could be wrong.
The .NET bytecode was designed to make it easy to JIT. Java was not. It's hard to make a JIT to make Java code run fast. It isn't nearly as hard to make a JIT to run .NET code fast.
.NET is really great for developing RAD web applications (through ASP.NET) and developing web services. It has it's place in the enterprise environments and let's face it, C# (and the renovations made to the VB language in VB.NET) makes for a better language than Java2 (as long as you're developing for the Win32 platform). Beyond this scope, .NET has no defined future, and since Microsoft isn't rushing to get CLRs out for other OSs (other than their own of course), I wonder what their long term strategy with it is.
One only has to look at Microsoft's own product line to see that neither COM or native code is something that isn't going away in commerical applications. The latest build of Office (coming to us now a year after the first release of the .NET Framework and VS.NET) is not a managed application, the next releases of SQL Server and Exchange Server will not be a managed applications.
Also, look at what DirectX does, at it's core it's a set of multimedia libraries optimized for hardware. The only thing COM does for DirectX is provide programmers an interface into it. As of the current release of DirectX, parallel COM and .NET interfaces exist into DirectX, but under the hood the majority of the code is very low level and tightly optimized and that will not change.
The original other had good intent, but really only someone who doesn't understand COM and .NET would even raise this question.
It's not the freeing of memory that's relevant in most cases, it's any other clean-up logic that the object runs on destruction. In particular, GC deals with memory release, while deterministic destruction allows idioms for handling any resource, be it dynamic memory, files, locks for thread synchronisation, sockets... Delaying the release of these things is not clever. :-/
But now you need to remember to call it manually, and remember to put it in your finally block so you don't miss it if you're exiting via an exception. If you have deterministic destruction semantics, then once you've created an object, you know that not only its memory, but all of its resources, will be released, and you can tell exactly when if it's relevant, or even speed the process along if your object owns scarce resources. You can't forgot to call a "release" method, and you don't need to call such a method in multiple or special places to make sure it works properly. This approach is safer and more general than the GC/Dispose/finally approach used by some languages.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
Yeah, but calling a couple of DirectX interfaces is a lot easier than writing a COM object that supports IDispatch and connection points (whose bright idea was that?), not to mention that DCOM didn't even work when it came out. COM is a big world, and using it is easier in vanilla C++ than writing it. Visual Basic is another matter but they have threading issues.
This is a legitimate post. Someone meta-mod this as unfair...
"its DOT COM" (sorry, couldnt resist. i could just hear homestar reading this post)
this sig was brought to you by the letter
Microsoft has announced internally and to close partners that Longhorn will contain an entirely new rendering engine. Likely this will be related to DirectX.
.NET and this rendering engine are related in that they will both be core components of the future OS. For now, .NET is just run times and a way to access data. Don't expect anything to change dramatically with the way games are made until Longhorn comes out.
BTW, this information is from Microsoft.
.Net is poor platfrom development. I think it is just poor copy cat of Java.
.Not
I would rather write in Java than do
My friend, you are thinking about "Chop Suey". The presence of the word "CHOPS" in both "CHOP Suey" and "CHOPSticks" probably caused the semantic error in your memory. It's interesting that your memory did recall the time era correctly.
From http://www.foodreference.com/html/fchopsuey.html
Also you may want to use google, at
http://www.google.com/search?hl=en&ie=UTF-8&oe=UT
for more info.
Hey, no worries. Bad memory happens. A very entertaining film called "Memento" explores the tribulations of a man whose short term memory is practically non-existent due to an injury. It is an amazing film, in the genre of "film noire" (violent, not suitable for children), and a tour de force of editing and scriptwriting. I highly recommed it.
Another fascinating film on a closely related subject is "A Beautiful Mind", which is Ron Howard's best film to date. It is a masterpiece. Ron Howard and Jennifer Connelly rightfully received the Academy Award, but unfortunately, Russell Crowe did not, even though his performance was exponentially superior to his performance in "Gladiator".
I mean where's the real problem here? You can't seriously tell me that modern games are still being written head to toe in hand coded assembly. I refuse to belive it, because then I'll never have the career in games I want cause I could never deal with a 100k line assembly program.
Basicly today, most games are in C++ (like doom3) or C (like quake3) and then after it's up and running, someone goes in and tweaks specific functions with ASM code where it'll do the most good. There's no point in doing a hand optimized MMX version of a function that renders the mouse pointer in your stage select screen. However, doing it for your poly culling function that runs a million times a second is probably a good idea.
So, why can't you do this with C#? No reason, C# can call existing compiled DLLs and libs with arbitrary code in them. It doesn't matter if the function in the DLL was made with C, C++, ASM, Delphi, or whatever. So, the game gets made, then you take the parts that really need that extra ASM optimization and put them in lower level code in DLLs you link to. The plus side is your C# code could always detect the CPU type for you and then link to DIFFERENT DLLs with different optimizations.
Where exactly is the problem?
I'd think people would be treating this like the holy grail it could potentially be. Think of the bigger picture. Ok now you have games that are in CLR code. What happens when someone gets a working CLR VM on linux? Do you need to recompile that code to play the same game on it? How bout a CLR VM on the Mac? Think MS might do it themselves? I dunno, what would they save in development costs by only having to make ONE version of office and IE and being able to sell all their existing PC apps to Mac users?
Introducing the new Occam Fusion! Now with sqrt(-1) fewer blades!
So, I worked on CsGL and am doing the new library (which is available as linked off the CsGL homepage). Anyway, from my tests, the .NET examples I've done so far, this includes all of the redbook samples, the majority of the nehe lessons, and a number of others, finds that the .NET versions run between 1-5% slower than the c/c++ versions. Admittedly most of the samples are somewhat simplistic and of course we're ultimately going through the native library and then through (hopefully) hardware accelleration, but to me that's quite acceptable. The main performance issue at this time is array performance, particularly multidimensional arrays, which are extremely slow. However, I understand in the 2.0 version of the .NET framework array performance will be improved, particularly multidimensional arrays.. As always the Mono team is improving performance and support.. Oh I did mention the new OpenGL binding is cross platform didn't I? The new library supports GLUT, as such one could develop cross platform OpenGL apps in their .NET language of choice. It runs fine under Microsoft's runtime as well as Mono on Windows, and I've had reports of many of the samples I've done running under Mono on linux and freebsd. Of course there's bugs (and surprisingly finding linux testers with OpenGL and Mono is like pulling teeth), but hopefully they'll be corrected. It'd also be nice if someone would contribute GLX support, but that's not important for this discussion...
Guess you havent seen DirectX 9's changelog. DirectX 9 has native .net support and they produced some pretty good MSDN documentation on implementing DirectX apps with C# and VB.net.
I think the main reason people don't write games in java is because they can be decompiled.
What does the fact that a binary format can be decompiled have to do with anything? Even x86 binaries can be decompiled.
I just don't know what the hell MS was thinking, OO Basic?
"I just don't know what the hell Bjarne Stroustrup was thinking, OO C?" I don't see anything wrong with adding object-oriented constructions to Basic.
Will I retire or break 10K?
You know some of you people have such a closed mind I wonder how you get along in the world. .Net is anything but slow and you cant tell me different. Why can you not tell me different well perhaps because I am speaking from experience and lots of it and real life experience is the ultimate decision maker. If you use DirectX 9 for gaming you will be fine. Lets just say that you can go much further than Java would ever get you... Oh and what do you mean the days when everyone complained java was slow? Java still is shit ass slow!
"If I was smarter I could rule the world!"
Anyone used Visual Studio .NET lately? It's touted as being an amazing piece of work, written mostly in .NET compatible languages and for the .NET platform. And guess what - it's slow. It's noticeably slower than the previous Visual Studios, even the bubblegum version for web and VB developers. In comparison to the previous Visual C++, it's practically standing still.
.NET does. Visual Studio is not a zippy application.
.NET enhancements you say? Managed C++ is a bloody nightmare. It's really not practical to use it for anything other than tying native C++ code to .NET components. It's also not much easier than using COM components directly, plus you have to limit yourself to .NET management of memory, objects, exceptions, which all add extra cycles you could avoid going totally native.
.NET very quickly, and there's jobs to be had. Just don't buy into the hype we've been force-fed for the past two years about .NET taking over the world.
Furthermore, it's even noticeably slower than, say, Eclipse, a comparable IDE for Java that uses a platform-independent API to native UI widgets, much like
So keep it C++ but with
We're continually fedd technologies from Microsoft that are supposed to be "the next big thing". Look at COM+. Look at ActiveX. The big thing has become old news year after year while other technologies with fewer hard corporate ties expand and proliferate. It's certainly worth learning--Microsoft is pouring the money bucket into
No, Virginia, there is no Santa Claus. The emperor is naked.
Hmmm... it's the wrong question to ask. A much more interesting one is "will there even *be* any major games for PCs in one/two/five years' time?". After all, it's much cheaper developing for xbox, ps2, etc. as you don't have to test on thirty-five different graphics cards, etc. What's more, consoles are steadily increasing in power, and with the advent of consoles with VGA ports and/or HDTV, the last remaining reasons to use a PC for games (higher resolution and a mouse) will go away. Combine that with the cheapness of consoles these days (xbox is now only £130 in the UK, the price of a mid range graphics card for a PC) and what's the point of developing for PC, which has a smaller market and lower returns?
"Dismissed."
A couple of people have mentioned this already, but I'll bring it up again -- developing a game is not just writing your engine. Tools are an incredibly important part of game development, and .NET makes it a hell of a lot easier to write good tools (the kind that artists and designers enjoy using, and use to their fullest extent). A colleague of mine said something to the effect of, "Yeah, working with .NET actually made writing my sound tool fun. And the tool has a decent interface for once, too!" You can also develop things more quickly -- my estimate, based on past experience, is at least a 4x speedup over using C++/MFC.
.NET is not useful in game development is silly. It's already proven its worth.
Sure, you may not write your runtime using the framework (although you certainly could!), but saying that
Wherever there's a will, there's a motorway.
Division Rivals football game.
Karma: Non-existant. Due mostly to the fact that you smell funny and nobody likes you.
Static analysis methods may remove as much as 90% of runtime checks.
...
For instance, such techniques may, on reading code such as:
for(int i=0; ia.length; i++)
{
x = a[i];
}
derive the fact that the check on a[i] is unnecessary because 0=ia.length.
Quote goes after the program name (LOAD "programname",8,1). The most typical form was, of course, LOAD "*",8,1 which loaded the first program on the floppy's catalog.
Tape users got it a little bit easier - just LOAD, or pushing Shift+RunStop.
This was an Obscure Command-Line Interface by today's standards, but the Commodores still came and conquered the gamers' hearts =)
(And what do you mean by "were launched"? They still are =)
COM is a vtable (virtual methods in C++) with simple type casting and reference counting. What's to hate?
If you want to help GPL developing with mono, maybe you can visit this littel info-collecting-project for a Quake engine: http://telejano.berlios.de/wiki3/index.php/quakemo no
Please fill in this wiki entry all relevant info you can collect about the task integrate mono in a Quake engine.
-Woof woof woof!
Ok, I have some to add:
Pros:
- Its new and yet very old, which makes it kina neat.
Cons:
- Games on a network can not use the current system settings, i.e. the correct network card is found and dhcp works. Or even better the phone number for the ISP has to be entered by hand
- Use of persistent media, either the app gets access to a current FAT, NTFS or ext2 partition or, well I don't know, but things as simple as saving games, game settings, network settings (see above) would not work.
- Auto updating - drivers or software without persistent media would be a bitch (see above)
-Jon
this is my sig.
Parts of the .NET framework is tightly integrated with the Win32 API, and is currently not covered by the Mono project. (WinForms)
Java is slow for desktop applications because its graphics library is rubbish, not because the VM is inherently slow.
.NET framework *.
Partly true, but a VM do add some extra overhead.
And about the platform independent part... follow your link and check out the current scope of the mono project. You will notice it currently doesn't cover 100% of the
So basically what we have a "platform independent" framework that currently only works 100% on one platform (No the BSD-port by MS isn't complete, it only covers the standardized parts.)
In my eyes this is not really platform independent at all.
But it may be, in the future, if MS doesn't find it in it's interrest to work against true platform independence.
*) This is in no way meant as a bash directed at the mono-guys, for whom I feel nothing but complete and utter admiration.
"First lesson," Jon said. "Stick them with the pointy end."
You really, really dont know fucking shit about high end computing, do you?
Why dont you grab an IBM mainframe, run Quake on it, then tell the people who bought it they were idiots because its so slow.
Retard.
"work". you fantasize about having a job. i doubt you have any code for peer review. thats what i thought. a baseless groupthinking microsoft zealot asshole.
well, if you want to see some of my code on the web, you can go to the mono project. I did:
- the class status pages, and the corcompare tool that generates them.
- the mono tinderbox.
- the XPath engine.
There's a bunch of other stuff scattered around, but you'll find my name in the easter-eggs for the following:- Visual C++ 2.x
- Visual C++ 4.x
- Visual J++ 1.x
eat your heart out...that XPath link is wrong, it should be here.
Easter egg? does that mean your the pizza coffee bitch? or just a low end tester. You cant even get "on the team"
An unpaid intern gets on an Easter egg, and I'm supposed to be impressed? heh. heheheh. bwahahhaa. heh.
by the way, corlib, nice list of thousands of errors and todos.
and that page "cvs tree" loads like fucking shit, terrible design for that.
Check out bitkeeper's web interface if you need a lesson in not sucking horribly. That was fucking terrible, and I hate Larry McVoy.
Everything so far makes you a FUCKING DUD. You know nothing and do nothing.
interns and temps don't usually appear on the credits, as you'll see if you bothered to find out anything about what you're blabbering on about. i'm not surprised, though, it doesn't really seem like you really know much about anything, but you'd like to think you do.
the whole point of the class status pages is to show the work remaining for the various mono assemblies. the errors and todos are what it's all about. some people thought it was useful.
if you bothered to look at the cvs pages, you'll see at the bottom that CVSWeb is written by zeller@think.de. if you don't like it you should complain to him. the reason i sent you those links is that you asked for some of my code to peer review.
so, what is it that you do (apart from pathetic trolls), pizzaboy?
Well I checked some of the code. Amateurish. You are not in any credits. You wrote nothing. And you inability to simply ignore a "troll" serves as a testament to you know-nothingness. All the "gods of computing" I have ever met would let you tell them, "you are wrong," and they, being intelligent beings, will let you continue on with your broken thinking.
You clearly are the opposite. You are probably the son of a Microsoft weenie and live vicariously through him and his "technical knowledge."
I can see from looking at your online behavior, your projects and your comments and your "endeavors" that I have absolutely nothing to learn from you and you are comical to watch. You are the classical Microsoft zealot-idiot, and you only function in life is to rehash code and coding idioms from others.
You are a bot, an automaton, you are like Lucy wrapping candy at the candy factory. You know nothing about top to bottom execution and implementation, you are cognizant of a very small niche and very much a boxed in thinker.
You will continue to be an insecure, unenlightened mediocre 'programmer,' skirting off the coat tails of real programmers for life. You will never be responsible for anything great, and you know it.
I would call you a life long programming non-contributor. A rehash, a hack, play it again Sam. You are the furthest think from Knuth its not even funny.
So I'll take a cheese Pizza and some a double latte from Peet's. Make it quick, bitch.
man, you're almost as good as Mohammed Saeed al-Sahaf.
yhbtyhlhand. not quite as good as MSS. he was lying. i do not. im simply pointing out truths that obviously get your blood boiling, retard.
yo ho ho and a botle of trollbaiting dipshit freaks.
scratch on up for me and be up out this bitch.
you're mistaken. yes, he was lying. you, on the other hand, are just a fool.
it would be nice somehow. i mean, .net is cross platform so i can finaly play all the games of the world the same day as my fellow windows users.
( i am still waiting for neverwinter nights you know ) .net performence appears to be ok.
now all we need is a .net version of directX since those games are very likely going to use it.
Starting with DirectX 9, Microsoft has started giving tutorials at developer conferences about "Managed DirectX" with .Net. Whether or not .Net will actually be relevant to anyone (let alone game developers) remains to be seen, but one can already access DirectX through .Net.
you are a fucking lampoon. you know that.
yhbtyhlhand. again.
M. Icaza tells you a small, insignificant program is important? And you make it a point in some agrument? Apparently, it only works in IE. Good job Microsoft zealot.
no one cares, reetard fucking fag haken.
no one reading this is paying attention to you because you say nothing technical, do insignificant work on off center projects, and the best part if how easily you are trolled.
fucking retard. does icaza's penis hit the back of your throat when you suck it.?
What's to hate?" Your lack of regard for other platforms, your zealotry for windows. your bias. your inexperience with enterpise computing. your unemployed status. you are an unrealiable FUD machine, spewing lies and half truths
works fine in mozilla last time i checked. i'd say it's more significant than anything you've ever done...
heh, who's trolling who now?
document is nearly two years old and talks about things in a very general manner.
you are sending people links to whitepapers raher than showing a piece of code running differently on the two runtimes. you "evidence" is a fucking whitepaper.
hahahahahahah fucking hAHAHAHAH what a fucking marketing boner you are hahahaha. you are such a little hot mouthpiece of microsoft hahahaha. what a fucking tird.
FUD fud fud.you know how many lies have been promulated by microsoft on the very same site about linux? you think there is eny credibility? im sorry you have no real world examples or experience with it, but hey, just point to a whitepaper with the workd "flaming monkeys" in it.
BWAHAHA fraud fraud fraud fraud.
umm. i have been ever since i wont the original arguments with you. you are the little bitch eating all the troll bait.
HAHAHHAHAHA. what a complete and total fag. taking the bait, BEOOOTCH, and still, not one iota of technical insight, only microsoft fud whitepaper regurgitation. hahahahahah. little birdie with a yellow bill, hopped upon my window sill, cocked his shining eye and said, aint you 'shamedyousleepy head.
BITCH.
if working fine is your code working slow as ass, but still working, i guess it "works"
you know, its funny how easy it is to break that code.
I've been playing around with the a little today. What I've done is
still a little rudimentary, it's mostly something I've wanted to try to
do for a while. It's basically just a collapsible tree echoing the
structure of the XML.
in your own words, RUDIMENTARY. just as i said before, fucker. i dont owe you an explnation for what i do, but lets just say compared to this shit, its far more coplex that this rudimentary crap.
you are a fucking lampoon trollbaiting whore. and you look like a little piece of SHIT. and you reall are a piece of shit. self-admitted rudimentary piece of shit. microsoft zealot loser icaza blowing fake fraud FUD loser.
A combination of its Pseries server which uses 32 Power 4++ processors running AIX and DB2, has knocked spots off HP's Itanium 2 Superdome using Windows Server 2003, and only using half the processors.
The firm said that TPC-C benchmarks showed that its machine delivered 680,613.12 transactions a minute at a cost of $11.13/tpmC, and that's knocked the Superdome off its number one perch.
The firm said HP had taken 18 months to catch up to its performance using its Power chips, and that lead only lasted a few weeks.
It took a further dig at HP and Intel. Adalio Sanchez, general manager of the Eserver division, said: "We don't just assemble boxes with third party components"
READ IT AND WEEP
IBM eServer pSeries 690 Turbo 7040-681
680,613
11.13 US $
11/08/03
IBM DB2 UDB 8.1
IBM AIX 5L V5.2
BEA Tuxedo 8.0
05/09/03
A combination of its Pseries server which uses 32 Power 4++ processors running AIX and DB2, has knocked spots off HP's Itanium 2 Superdome using Windows Server 2003, and only using half the processors.
The firm said that TPC-C benchmarks showed that its machine delivered 680,613.12 transactions a minute at a cost of $11.13/tpmC, and that's knocked the Superdome off its number one perch.
The firm said HP had taken 18 months to catch up to its performance using its Power chips, and that lead only lasted a few weeks.
It took a further dig at HP and Intel. Adalio Sanchez, general manager of the Eserver division, said: "We don't just assemble boxes with third party components"
READ IT AND WEEP
IBM eServer pSeries 690 Turbo 7040-681
680,613
11.13 US $
11/08/03
IBM DB2 UDB 8.1
IBM AIX 5L V5.2
BEA Tuxedo 8.0
05/09/03
A combination of its Pseries server which uses 32 Power 4++ processors running AIX and DB2, has knocked spots off HP's Itanium 2 Superdome using Windows Server 2003, and only using half the processors.
The firm said that TPC-C benchmarks showed that its machine delivered 680,613.12 transactions a minute at a cost of $11.13/tpmC, and that's knocked the Superdome off its number one perch.
The firm said HP had taken 18 months to catch up to its performance using its Power chips, and that lead only lasted a few weeks.
It took a further dig at HP and Intel. Adalio Sanchez, general manager of the Eserver division, said: "We don't just assemble boxes with third party components"
IBM eServer pSeries 690 Turbo 7040-681
680,613
11.13 US $
11/08/03
IBM DB2 UDB 8.1
IBM AIX 5L V5.2
BEA Tuxedo 8.0
05/09/03
Intel reveals Itanium 2 glitch
By Stephen Shankland Staff Writer, News.com May 12, 2003, 12:36 PM PT
CUSTOMERS TOLD TEMPORARY REMEDY: Until the next iteration of chip arrives though, Oliver Wendell Jones writes, "they recommend working around the problem
by underclocking the processor to run at 800 MHz instead of its default 900 MHz or 1 GHz."
Intel disclosed an electrical problem Monday that can cause computers using its flagship Itanium 2 processor to behave erratically or crash.
Read more about Itanium
Customers can sidestep the problem by setting the processor to run at a lower speed, said company spokeswoman Barbara Grimes, and Intel will replace the
processor if customers want. The glitch only affects some chips, and then only in the case of "a specific set of operations in a specific sequence with
specific data," according to Grimes.
"If the customer feels it's the right solution, we'll exchange processors with ones that aren't affected," she said. Intel has developed a simple software
test that can determine whether a chip is affected.
The problem likely is fairly uncommon, Insight 64 analyst Nathan Brookwood said. "These machines have been out there for a year, and it only now is showing
up, so it's got to be fairly rare. If it's something that was more commonplace, we would have seen it a lot sooner, or they would have found it in their
alpha or beta testing."
Still, the problem is a black eye for Intel, which has been positioning its Itanium line to take on high-end chips from Sun Microsystems and IBM for use in
powerful servers with dozens of processors.
"Virtually everybody has these kinds of problems," Brookwood said. "When you consider the hundreds of millions of transistors that go into these complex
designs, it's amazing we don't see these more often."
The Itanium 2 has data protection features and a 64-bit design that can handle vast amounts of memory, making it better suited to high-end servers than
32-bit processors such as Intel's Xeon and Pentium. Its performance has been good enough to boost Windows servers to the upper echelons of the server market,
but the processor family's arrival has been clouded by initial delays and by the difficulties of running software written for Pentium chips.
A computer maker found the electrical problem in stress testing earlier this year, and Intel confirmed it was a problem with the chips, not the software or
other parts of system design, Grimes said. The problem affects both 900MHz and 1GHz versions of the Itanium 2, code-named McKinley. However, it doesn't
affect a faster 1.5GHz successor--called Itanium 2 6M and formerly code-named Madison--that is set for release in mid-2003, she said.
The ripple effect
The problem has begun rippling through the computer industry. IBM said Monday that it has put shipments of its just-released x450 Itanium 2 server on hold
until the glitch is fixed and is notifying customers that have the systems.
"Until we're sure the issues are 100 percent resolved, we're going to keep holding back shipments with the 450," IBM spokeswoman Lisa Lanspery said. "We have
a policy of zero tolerance for undetected data corruption" at a customer site, she said.
The move doesn't affect IBM's overall Itanium plans, which include a server based on the Itanium 2 6M and planned for later in 2003, she said.
Hewlett-Packard, which co-developed the Itanium design and is building the processor family into its entire server line, said computer shipment plans aren't
affected because it's screening affected systems before they ship. The company is working to help customers that already bought the systems.
"We'll do whatever meets the customer's total satisfaction," said HP spokeswoman Kathy Sowards. "We're working very closely with Intel to come to a
resolution for any customers th
Intel reveals Itanium 2 glitch Yes, GLITCH
By Stephen Shankland Staff Writer, News.com May 12, 2003, 12:36 PM PT
CUSTOMERS TOLD TEMPORARY REMEDY: Until the next iteration of chip arrives though, Oliver Wendell Jones writes, "they recommend working around the problem
by underclocking the processor to run at 800 MHz instead of its default 900 MHz or 1 GHz."
Intel disclosed an electrical problem Monday that can cause computers using its flagship Itanium 2 processor to behave erratically or crash.
Read more about Itanium
Customers can sidestep the problem by setting the processor to run at a lower speed, said company spokeswoman Barbara Grimes, and Intel will replace the
processor if customers want. The glitch only affects some chips, and then only in the case of "a specific set of operations in a specific sequence with
specific data," according to Grimes.
"If the customer feels it's the right solution, we'll exchange processors with ones that aren't affected," she said. Intel has developed a simple software
test that can determine whether a chip is affected.
The problem likely is fairly uncommon, Insight 64 analyst Nathan Brookwood said. "These machines have been out there for a year, and it only now is showing
up, so it's got to be fairly rare. If it's something that was more commonplace, we would have seen it a lot sooner, or they would have found it in their
alpha or beta testing."
Still, the problem is a black eye for Intel, which has been positioning its Itanium line to take on high-end chips from Sun Microsystems and IBM for use in
powerful servers with dozens of processors.
"Virtually everybody has these kinds of problems," Brookwood said. "When you consider the hundreds of millions of transistors that go into these complex
designs, it's amazing we don't see these more often."
The Itanium 2 has data protection features and a 64-bit design that can handle vast amounts of memory, making it better suited to high-end servers than
32-bit processors such as Intel's Xeon and Pentium. Its performance has been good enough to boost Windows servers to the upper echelons of the server market,
but the processor family's arrival has been clouded by initial delays and by the difficulties of running software written for Pentium chips.
A computer maker found the electrical problem in stress testing earlier this year, and Intel confirmed it was a problem with the chips, not the software or
other parts of system design, Grimes said. The problem affects both 900MHz and 1GHz versions of the Itanium 2, code-named McKinley. However, it doesn't
affect a faster 1.5GHz successor--called Itanium 2 6M and formerly code-named Madison--that is set for release in mid-2003, she said.
The ripple effect
The problem has begun rippling through the computer industry. IBM said Monday that it has put shipments of its just-released x450 Itanium 2 server on hold
until the glitch is fixed and is notifying customers that have the systems.
"Until we're sure the issues are 100 percent resolved, we're going to keep holding back shipments with the 450," IBM spokeswoman Lisa Lanspery said. "We have
a policy of zero tolerance for undetected data corruption" at a customer site, she said.
The move doesn't affect IBM's overall Itanium plans, which include a server based on the Itanium 2 6M and planned for later in 2003, she said.
Hewlett-Packard, which co-developed the Itanium design and is building the processor family into its entire server line, said computer shipment plans aren't
affected because it's screening affected systems before they ship. The company is working to help customers that already bought the systems.
"We'll do whatever meets the customer's total satisfaction," said HP spokeswoman Kathy Sowards. "We're working very closely with Intel to come to a
resolution for any c
Intel reveals ITANIC 2 glitch
By Stephen Shankland Staff Writer, News.com May 12, 2003, 12:36 PM PT
THE SUNK CPU!
CUSTOMERS TOLD TEMPORARY REMEDY: Until the next iteration of chip arrives though, Oliver Wendell Jones writes, "they recommend working around the problem
by underclocking the processor to run at 800 MHz instead of its default 900 MHz or 1 GHz."
Intel disclosed an electrical problem Monday that can cause computers using its flagship Itanium 2 processor to behave erratically or crash.
Read more about Itanium
Customers can sidestep the problem by setting the processor to run at a lower speed, said company spokeswoman Barbara Grimes, and Intel will replace the
processor if customers want. The glitch only affects some chips, and then only in the case of "a specific set of operations in a specific sequence with
specific data," according to Grimes.
"If the customer feels it's the right solution, we'll exchange processors with ones that aren't affected," she said. Intel has developed a simple software
test that can determine whether a chip is affected.
The problem likely is fairly uncommon, Insight 64 analyst Nathan Brookwood said. "These machines have been out there for a year, and it only now is showing
up, so it's got to be fairly rare. If it's something that was more commonplace, we would have seen it a lot sooner, or they would have found it in their
alpha or beta testing."
Still, the problem is a black eye for Intel, which has been positioning its Itanium line to take on high-end chips from Sun Microsystems and IBM for use in
powerful servers with dozens of processors.
"Virtually everybody has these kinds of problems," Brookwood said. "When you consider the hundreds of millions of transistors that go into these complex
designs, it's amazing we don't see these more often."
The Itanium 2 has data protection features and a 64-bit design that can handle vast amounts of memory, making it better suited to high-end servers than
32-bit processors such as Intel's Xeon and Pentium. Its performance has been good enough to boost Windows servers to the upper echelons of the server market,
but the processor family's arrival has been clouded by initial delays and by the difficulties of running software written for Pentium chips.
A computer maker found the electrical problem in stress testing earlier this year, and Intel confirmed it was a problem with the chips, not the software or
other parts of system design, Grimes said. The problem affects both 900MHz and 1GHz versions of the Itanium 2, code-named McKinley. However, it doesn't
affect a faster 1.5GHz successor--called Itanium 2 6M and formerly code-named Madison--that is set for release in mid-2003, she said.
The ripple effect
The problem has begun rippling through the computer industry. IBM said Monday that it has put shipments of its just-released x450 Itanium 2 server on hold
until the glitch is fixed and is notifying customers that have the systems.
"Until we're sure the issues are 100 percent resolved, we're going to keep holding back shipments with the 450," IBM spokeswoman Lisa Lanspery said. "We have
a policy of zero tolerance for undetected data corruption" at a customer site, she said.
The move doesn't affect IBM's overall Itanium plans, which include a server based on the Itanium 2 6M and planned for later in 2003, she said.
Hewlett-Packard, which co-developed the Itanium design and is building the processor family into its entire server line, said computer shipment plans aren't
affected because it's screening affected systems before they ship. The company is working to help customers that already bought the systems.
"We'll do whatever meets the customer's total satisfaction," said HP spokeswoman Kathy Sowards. "We're working very closely with Intel to come to a
resolution