Is .NET Relevant to Game Developers? 563
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?"
That Giant Sucking Sound... (Score:3, Insightful)
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...
Re:That Giant Sucking Sound... (Score:2, Insightful)
Your argument sounds very like the "proofs" we were all given that games would always be written in asm, not in C++. Look at what tosh that is.
Re:That Giant Sucking Sound... (Score:3, Insightful)
Re:That Giant Sucking Sound... (Score:4, Interesting)
About your first statement, the only (slight) adcantage that your first statement means is that instead of having an in-game scripting language in your game, you could compile a real scripting engine into your code. Otherwise, there is no use for cross-language games programming.
Porttability hasn't been touched yet. Does anyone think this would help games development to other platforms???
Re:That Giant Sucking Sound... (Score:3, Interesting)
The bigger issue for game development is that memory management is turned over to the system, which takes a lot of control away from game developers... these are people that put inline assembly code to speed up certain sections...
I'd be interested in the .NET experts out there to comment on the parent post. AFAIR, .NET's main disadvantage is the defering of resource management to runtime. Since you can compile it down, that part of th
Re:That Giant Sucking Sound... (Score:5, Informative)
Oh how I fear for anyone whose source of
The memory managment is not "turned over" to the system. There is an automagic Garbage Collector like Java, but you still have control if you don't want to wait for the automagic processes.
Re:That Giant Sucking Sound... (Score:2)
...and just like in Java, that control is less than perfect.
If I remember correctly there is, for example, no way to guarantee a destructor will run for a particular instance before it is recycled.
Is this still true?
Re:That Giant Sucking Sound... (Score:5, Informative)
On the contrary, you have zero memory control in Java unless you use Java objects as JNI wrappers and then do all your memory managment in C. Alternately, you can use JVMPI to trap memory allocs and deallocs and try to control things that way. Or you find a VM that lets you tune and reprogram GC behavior. All objects in Java are subject to the GC. In .NET, there is some support for hand-managed memory, though attempts to limit it exist.
If I remember correctly there is, for example, no way to guarantee a destructor will run for a particular instance before it is recycled. Is this still true?
It was never true. You're guaranteed that finalize() will run on an object before it is removed from memory. What you're not guaranteed is that the object will ever be the target of a collection, meaning finalize() might never run. Additionally, it's impossible to know at what point in time after the running of finalize() (if ever) the object will actually be taken out of memory.
Re:That Giant Sucking Sound... (Score:4, Insightful)
I hear a lot of complaints about the lack of deterministic finalization, but I really have to wonder why people care so much about when the memory is actually freed for a particular object.
Most complaints center around the fact that you don't know when your destructor is going to execute. That's a valid concern, but there is nothing that really separates a destructor from a regular method. If you have some clean-up that needs to happen, put it into a Dispose() method and call it yourself. Pretty simple.
"But the memory isn't freed after I call Dispose()!"...who cares? Just let go of your reference and let the GC handle it. You've executed your cleanup code, so why do you care that there is a block of memory out there that you can't even see that's still allocated? It's not going to leak, so just let the GC do it's job.Re:That Giant Sucking Sound... (Score:5, Interesting)
Technically, you're talking about two different things. Finalization is the "end of lifecycle" processing of an object, beyond which the object becomes semantically meaningless. Removal from memory of the "dead bytes" of that object is something different. The reason people often complain about deterministic finalization is because, without it, you have no control over when the object's cleanup happens. You know you don't need that object anymore, but you can't actually get rid of it. That can be annoying, especially if you come from a C or C++ background and are very much accostumed to being able to control everything.
Being able to control finalization and memory frees (which are technically not coupled in Java or .NET memory managed code) can also be really important when you're either in a small memory space (J2ME) or you're writing server software like a J2EE container. The reason why is because, bascially, you're replacing your intimate knowledge of your own software with some best-guess heuristics. There's little I know of that's worse than a thrashing GC, and this can be avoided if you can micromanage memory collection to happen at more opportune times. Some JVMs (Sun's, most notably) allow you to tune their GCs to help prevent this through a control of the amount of memory given to objects of different ages. This can be quite helpful in performance tuning.
If you have some clean-up that needs to happen, put it into a Dispose() method and call it yourself. Pretty simple.
I don't know enough about .NET to comment, but if there's an interface you can implement to provide uniformity in the call and use of that method, that's great. Java, AFAIK, has no such interface, so hand-made deterministic cleanup is idiosyncratic. That's okay, but it's not ideal. What's more, though, let me ask you this- in some large middleware or object framework following your idea, what guarantee is there that your disposal method won't accidentally get called twice? This could lead to indeterminate states in the system that aren't immediately understood, since there's no check against that implicit. At least with a C++ destructor, destroying the object guarantees that further use of the object is impossible. No such guarantee is available with homespun management. Yes, the roll-your-own you're describing is good enough, but that doesn't mean it's without flaw.
Maybe, but again, think about situations where you're trying to minimize memory use. Deterministic destruction makes memory immediately available again. You can put a new object in that freshly freed memory. With a GC, that may not be possible. Thus, I dispose() my object, which scrubs it clean, then I throw it to the wolves...only they're not hungry just yet. I go to make a new object, and that memory isn't available. On most systems, this will force the GC to mark the dereferenced object's memory as fair game, yes, so this isn't a big big deal, but the decoupling described can lead to ickiness. Also, as I mentioned, having memory deallocation occur synchronously to my call to a destructor means the GC will never thrash. GC thrashing seriously slows a program down, and after thrashing and thrashing, it still might not have the memory you're looking for (for various reasons).
In my experience, the loss of control that results from being in a GC environment is neither as big a deal as its oponents make it out to be, nor is it as little a deal as its proponents make it out
Re:That Giant Sucking Sound... (Score:4, Informative)
That said, "Finalize" in Java and destructors in C# aren't particularly useful. You can't be sure that any managed objects you reference are available during this period, and if you have any unmanaged resources left over, the destructor is a suboptimal place to clean them up, for the 40 second rule and due to the unpredictable time the garbage collector will call these methods. Better to implement IDisposable interface with its "Dispose" method, and provide a "Close" method that calls "Dispose". This give the user more control of cleanup of system resources, but still provides a minimum level of protection for users who fail to protect themselves, since you can fall back on the finalizer if "Dispose" is never called.
Re:That Giant Sucking Sound... (Score:2)
Even when you do raw pointer manipulation in an an unsafe block of code? I thought that the point of pinned pointers and the "unsafe" keyword in C# was so that you could engage in direct memory managment in limited
Re:That Giant Sucking Sound... (Score:4, Informative)
Some comments here:
1. Is it really the end of COM?
We (any
2. Will ALL Windows programming be done with
Sure, you can do the hard core stuff in [Unsafe] C#/C++, leave the rest in
3. DirectX is already available for
4.
5. I personally think it's down to what game you are planning to write. If you want to do Doom III in
6. Summary:
If you are referring to using DirectX 9 with
If you want to do stuff like Diablo/Starcraft in
Don't do Doom III in
jliu
Re:That Giant Sucking Sound... (Score:3, Informative)
As for memory management - as one of the other posters said, you can take control of the GC, but you really mess with it when you do this. - "fixed" blocks prevent the GC from moving chuncks, which really messes with it's perfo
Re:That Giant Sucking Sound... (Score:5, Informative)
CLR doesn't produce slow code. It's NOTHING like when people complained how slow java was. That's because
It won't do MMX optimizations so far, at least not that I know, so that stuff is still done by hand. But DirectX 9 is basically 'DirectX.NET', and the
Most of the stuff we've used in DX9.NET has been very fast, and using the simple interop with native code we've written plenty of MMX/SSE/SSEII optimized methods where we needed them.
In addition to your game needing the
What does this give a game developer? Plenty! Faster development of games with fewer crashes possibly, easier patching of games and auto-updating. Games are a different beast than commercial apps - you don't need versioning so much, you don't need XML, or rapid GUI development. But there's nothing wrong with writing a game in C#, it's just another language, and its plenty fast.
Re:That Giant Sucking Sound... (Score:3)
Aha, there's the rub. If you assume a pure
Re:That Giant Sucking Sound... (Score:3, Informative)
I have (benchmarking is one of my hobbies
Re:That Giant Sucking Sound... (Score:2)
Just received my new computer and surprise surprise, it did not actually ship with .NET Framework, which I have had to install to run #Develop [icsharpcode.net].
Wish Microsoft bundles both Java and .NET - wasn't the whole reason why .NET does not come bundled yet, Microsoft's apprehension of being forced to bundle Java too?
Re:That Giant Sucking Sound... (Score:2)
Re:That Giant Sucking Sound... (Score:2)
Funnily enough, it's not there. Maybe they are pitching XP more at home users? Funny considering my copy is actually XP Professional...
XML Thing... (Score:4, Insightful)
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?
Re:That Giant Sucking Sound... (Score:3, Funny)
Why not? Imagine playing Quake to create your next spreadsheet! "Quick! There's AA51! Where's my BFG9000 when I need it?"
Re:That Giant Sucking Sound... (Score:2, Informative)
IMHO, the value of
Also,
managed code: just as pedal to the metal as native (Score:3, Informative)
The JIT compiler performs classic optimizations such as constant folding, constant and copy propagation, common subexpression elimination, code motion of loop invariants, dead store and dead code elimination, register allocation, inlining, and limited loop unrolling (small loop
.net DirectX (Score:5, Informative)
Another round of bug fixing and it'll be rather good.
Re:."Managed" anything - e.g. net DirectX (Score:2, Informative)
Re:."Managed" anything - e.g. net DirectX (Score:4, Informative)
Re:.net DirectX (Score:3, Interesting)
FYI, the longhorn APIs will be in the microsoft.* namespace. According to the internal docs, there's a precise distinction between what will go into system.* and what will go into microsoft.*, but basi
Dotnet won't rule the world. (Score:5, Informative)
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?
Re:Dotnet won't rule the world. (Score:2, Informative)
Your post is excellent with much more thought than I could cram into mine (office moving day, sigh.) Effectively .Net is intended for business application development, whether on server or client, or client-server. It has the typical rapid (well, unless you get stuck, it being so new yet, help can be hard to find) development
Re:Dotnet won't rule the world. (Score:3, Insightful)
None.
But that is largly because of javas lingering performance issues.
Everything running on a VM has to have some extra overhead compared to native code, but
(In fact, not being platform independent is a plus for MS. They will need something to prop up their OS business in an age of increasingly commoditized*
Re:Dotnet won't rule the world. (Score:2, Funny)
Re:Dotnet won't rule the world. (Score:2)
Re:Dotnet won't rule the world. (Score:5, Interesting)
Of course, that really only applies to people who want to use a Microsoft product for building games.
In reality I think dotnet is what everyone thinks, a competitor to Java. How many highgrade professional games are written in Java currently?
You got me thinking, so I'm going to take a flyer here.
Remember back in the **OLD** days when Atari, Commodore and Apple games weren't launched from the OS, they were loaded from a boot floppy because we really didn't have OS's back then? (Unless you purchased CP/M, of course.)
Well, Knoppix has demonstrated an absolutely ridiculous level of competence at autodetecting hardware, and since . Would the gaming industry consider the possibility of using Linux as a development platform in a trend back to using bootable disks for games?
Think about it: a bootable CD that has the Linux kernel, drivers, support libraries and your game code.
PRO:
[Fully customizable and optimized kernel]
+ [NO OS OVERHEAD or CPU/RAM competition]
-----------------
= [Mad crazy performance out the wazoo regardless of what other spyware crap the boneheaded user has been suckered into installing.]
PRO: OpenGL, Internet Integration, divers filesystem support for saving games to floppy, hard drive, memory card, cdrw, THE INTERNET.
PRO and CON: Potential for DRM and proprietary CDROM file systems to limit piracy and legal backups.
PRO: Their kernels would be open source, so we could see if they were spying on our hard drives or personal data. (This might be a big problem because you're giving their cd exclusive control of your PC to play a game.)
PRO: Reduced support costs - you'd be distributing an embedded system that only includes the drivers YOU specifically choose.
CON: Game developers may start developing drivers again. (**shudder**)
CON: No downloading or listening to MP3's in the background while playing Half-Life anymore, though they could certainly throw in those feature if they wanted to.
Woah... Am I on to something?
Anyone else have any ideas to add?
Re:Dotnet won't rule the world. (Score:3, Insightful)
The task of building a "game" distro would be complex; a game company would have to spend lots of time building it; otherwise, it has to be outsourced. If you're not building it, why are you shipping on only that OS?
Re:Dotnet won't rule the world. (Score:3, Insightful)
Re: not the same as with Atari or CBM (Score:5, Insightful)
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.
DirectX 9.0 for Managed Code (its out already) (Score:5, Informative)
(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
Re:DirectX 9.0 for Managed Code (its out already) (Score:5, Interesting)
The first thing I noticed is that unlike previous versions of DirectX, the managed DirectX API is very different depending upon which language you are using. For example, in C# I used a lot of DirectDraw functions to draw all of my screen elements. When I had my game up and running, I looked into what it would take to port to C++. Well, there is no "DirectDraw" object in the C++ API. According to MS, all of those functions have been folded under the Direct3D object in C++. The names are mostly different, and some of the methods and properties in DirectDraw didn't seem to have directly equivilent methods in the C++ Direct3D API. My question is if they decided to put those functions under Direct3D, that's fine, but why did they make it completely different in C#? Why not just use the same API for all the languages? It's not like C# can't support it.
That, and the documentation was spartan at best. There were several pages of documentation which just had function headers with cryptic parameter type names as the arguments. It sorta reminded me of reading documentation for some of the OSS projects I've developed stuff with. Sure, you can figure it out through educated guesses trial-and-error, but as a developer that's not how I like to spend my time.
Re:DirectX 9.0 for Managed Code (its out already) (Score:5, Informative)
FYI, the DirectDraw interface in managed DX is just a wrapper around making D3D calls. There is no DirectDraw layer ANYWHERE in DX9. The managed interface just makes it easier to do 2D operations, everything ends up going through the 3D driver eventually.
Finally, I agree, the managed DX documentation is no where near as complete as the native DX docs.
Re:DirectX 9.0 for Managed Code (its out already) (Score:3, Insightful)
It's really a question of appropriateness. C# isn't appropriate for games. My guess is that the whole reason for Managed DirectX is to allow apps to do visualization and stuff... so that managers can look at sales figures as a cluster of three-d spheres or something stupid, not to write a 3d shooter with.
That's not to say you couldn't... wrong tool for the wrong job, but you could
Based on what microsoft has done in .net games NO (Score:4, Informative)
Proper implementation would have saved this (Score:2)
I won't use
Re:Proper implementation would have saved this (Score:3, Funny)
But... How would you write efficient code if your functions didn't have helpful names like DDLockBufferAndBlitToSurfaceAndPrayThePointerIsVa
Visual Studio .Net is, Managed code is not (Score:2, Interesting)
Why are you asking us? (Score:2)
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 went down like this (Score:2, Funny)
Steve: yes
Bill: is windows secure and stable yet
It is stormy in the pacific northwest, rains and cold have been present for the past several days
Steve: (sick with the flu, congested, and tired from jumping) not yet
Bill: Dot Net, that's it. (picks up phone) "marketing, this is bill. we're going with dot net, steve says so."
Yes (Score:2)
Re:Yes (Score:2, Funny)
Download "DirectX 9 SDK for C#" (Score:2)
Uh huh (Score:5, Insightful)
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
Re:Uh huh (Score:5, Insightful)
Yes"
Actually No. The only zealous act here is what you say in your 7th point which bashes linux users. The poster asked directly about the future of gaming on Windows. The entire post along with its many questions on how this relates DIRECTLY TO GAMING ON WINDOWS is below if you feel like reading it again.
"We've heard an awful lot about how
Zealot - n.
The most overdone word in the geek lexicon.
No, game development will still be the same... (Score:5, Interesting)
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
The only use for .NET in games... (Score:2)
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 :)
.NET and Passport are not the same thing (Score:2, Informative)
What exactly is the point of .NET? (Score:2, Interesting)
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 beca
Re:What exactly is the point of .NET? (Score:3, Insightful)
Re:What exactly is the point of .NET? (Score:2)
Re:What exactly is the point of .NET? (Score:4, Insightful)
Seriously? I doubt many people will actually pay any attention to the answers.
While it may be slightly slower (and I mean slightly) the problem is easily solved and/or irrelevant. because your calling the highly optimized stuff in DirectX for most of the graphics work your speed issues are minimal and any core routing that is really slowing you down can be coded in something else without forcing the whole project into a less useful environment.
For most developers the issue of cross platform is irrelevant. In general I can support most biz needs via a web service anyway or in Windows. The rest of the world is Mac (and there WILL be a Mac implementation because Office on the Mac is a good cash source) or Linux - and Linux is irrelevant for this type of thing.
Then you haven't looked very hard. The Web controls, event model and code behind features are light years ahead of CF and PHP. mod_perl isn't even a player.
The enterprise level apps I have been involved with are either Intranet based (and this .NET is perfect) or Windows based. In both cases .NET is a great
environment and has strong advantages over Java. Besides, given how much Sun is
throwing their weight around with Java most firms see java as a single source
tool and Sun is a much less attractive partner.
You can cut the framework down for custom applications.
It's as good or better than Java, runs as fast as C++ and is much easier to code for than Win32. The web event model rocks and the ability to mix languages kicks ass.
In short, it's good.
Re:What exactly is the point of .NET? (Score:3, Funny)
Of course it's cross-platform. It runs on 2000, XP and
.NET is also an IDE, and an optimized C++ compiler (Score:5, Informative)
Re:.NET is also an IDE, and an optimized C++ compi (Score:3, Informative)
Uh, unless you use DirectX. Which is all COM based.
I prefer cross platform technologies, regardless.
We could only hope... (Score:2)
On top of everything else said (Score:2)
.Net and Games - It is a reality (Score:4, Interesting)
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
Yes, But (Score:5, Interesting)
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
Is it really the end of COM? (Score:5, Insightful)
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
VC++ 7 might work (Score:2, Interesting)
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
C# vs C, DirectX samples (Score:5, Interesting)
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
Re:C# vs C, DirectX samples (Score:3, Informative)
How good is .NET at heavy calculation? Games are more than just graphics.
If they *were* realistic examples of all the stuff a modern games does, then disregard this post.
Re:C# vs C, DirectX samples (Score:5, Informative)
Some argue garbage collection is expensive, but try calling C++'s "new()" a few million times and see how much you like it then. Memory ALLOCATION in .NET is almost a no-op relatively, and deallocation's only real downside other than non-determinism is that a poor GC (garbage collector) can cause "burps" in performance if it falls behind due to too many objects being created and unreferenced too quickly. Generational GC's like .NET's tend to mitigate this to a large degree.
I suppose if you consistently use 100% of the processor and are allocating objects, eventually the processing overhead of the GC will become apparent, but most programs use the procecessor unevenly, leaving spare cycles for the GC to consume.
C++ will NEVER replace assembly in Game Coding!! (Score:5, Interesting)
Well, you can read some books [apress.com] 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)...
Excuse me (Score:5, Informative)
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,
The future (Score:5, Informative)
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
Question asked of Java (Score:2)
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
Yes! (Score:2, Informative)
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)
Visual Studio .NET or .NET Framework? (Score:2, Informative)
Otherwise,
Looking at the way the CLR works.. you could I guess make a cross-platform game that way. But who cares? All the
Dependency of .NET framework (Score:4, Interesting)
<plug class="shameless" >
I have written an article called Whats the need for
</plug >
Jalil Vaidya
short memories (Score:5, Insightful)
Yes - but not where you think (Score:5, Interesting)
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
Re:Yes - but not where you think (Score:3, Informative)
Remember that C# and .NET are robust enough for these - the .NET IDE proves that.
Visual Studio .NET is for the most part not written using the .NET framework. It was developed concurrently with the .NET framework.
My Exp, with .NET and Game Dev Says Yes (Score:5, Informative)
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.
The framework will be the framework (Score:5, Interesting)
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.
A Caviet for .NET (Score:4, Insightful)
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 ?
Is .NET Relevant to Game Developers? (Score:3, Informative)
Sample game written in VB.net (Score:3, Funny)
Not all windows programs. (Score:3, Interesting)
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
OpenGL and .NET (Score:3, Insightful)
.NET is considerably slower (Score:5, Interesting)
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.
Re:maybe developers would wise up then.... (Score:2)
Re:maybe developers would wise up then.... (Score:3, Interesting)
Re:Doubtful. (Score:5, Informative)
I think you were thinking of fortune cookies, not chopsticks. I can assure you, coming from South-East Asia, that the Chinese, Japanese and Koreans all have been using chopsticks for millenias.
Which is why there was much backslapping when a Chinese archaeologist claimed to have found a fork in a cave in China dated to about 3000 BC - it's not that they have not discovered forks, it's that they have "moved on".
And no, my chopstick handling is still rather poor. I can use it to eat rice though :p
Re:Doubtful. (Score:4, Insightful)
How do you know if the Chinese inventor of the fork just didn't market his or her idea well enough for it to catch on? Either that or maybe people resisted the change since they didn't want to give up the simplicity of braking twigs off trees to eat? Just because a technology is superior doesn't make it the popular choice.
Re:Doubtful. (Score:4, Interesting)
Where did you get that information on chopsticks? It sounded like interesting story to have on hand, so I took a look at Enclopedia Brittanica, which said:
"Chopsticks of bamboo or wood, and subsequently of ivory and precious metals, originated in China as early as the Shang dynasty (c. 1766-c. 1122 BC) and from there spread throughout East Asia. In China, the substitution of chopsticks for knives at the table reflected the ascendancy of the scholar over the warrior as a cultural hero."
Which would seem to indicate that chopsticks were around for several millenia, and also gives some basis for the pretension associated with them. Do you have any further references on the use of chopsticks in mining restaurants in the U.S.?
Re:Doubtful. (Score:5, Funny)
I think that's probably the most easily-disproved wild assertion I've ever read, even on
There should be a special prize or something.
I call bullshit (Score:2)
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
Re:I call bullshit (Score:3, Funny)
Whoa, I could have sworn I saw them as far back as 1998.
Re:Strange... (Score:5, Informative)
Microsoft's marketing droids decided that if they called everything
Re:No. (Score:2)
Re:.NET is used for game development (Score:4, Informative)
That's like saying "I'm running Java!" because you used a Java-to-native compiler and produced an ordinary native EXE, and then ran it without any trace of Java on the system.