Sign in to follow this  
  • entries
    67
  • comments
    89
  • views
    51527

No Thumb-Twiddling Here!

Sign in to follow this  
LachlanL

652 views

I've been doin' stuff... I promise!


Man, have I ever been the lurker lately. Haven't done any posts since before the Easter weekend. Speaking of Easter, had me a nice lazy weekend. Had some friends over and did some stuff at church, but otherwise nice & quiet.

So what have I been doing?


I hear you ask? (or maybe you're already pressing "back" on yer browser [razz])

Well, I had more than one religious experience on the w'end. I was noticing that many of the new samples in the DX SDK are C# only and I remembered hearing that C# is somewhat based on Cpp. So out of curiosity I did a quick google and found this article about the differences between C# & Cpp (there's also one on that page about .Net). Didn't sound too bad. I also remembered that the XNA framework first came out for C# and then I stumbled upon this guy's page.

WOAH



That pretty much sums up my reaction. Scene-graphs, shaders, post-processing, models, octtree culling, quaternion cameras and more in 12 tutorials? He even has the beginnings of a scene-editor in there! Granted I had already implemented most of that stuff in my current editor, but XNA just made it all look so EASY! Plus he shows how to seperate the engine into a nicely-packaged dll for quick plugging into your demo/game/editor in a snap. I knew I was hooked. So a few quick downloads later (C# 2005 Express, XNA, latest DX SDK) and I was already hacking away at my own version.

So a few days of coding and learning C# as I go and I have the following components looking decent: scene-graph, octtree with frustum-culling, batched shader system (all objects are batched together "per shader" for drawing), camera system and model-loading. I've got some bugs to fix, but after that I'll be setting to the task of implementing a scene-editor using windows forms & the new engine.

Why???????


Yes, yes, I already had a working scene-editor with many of the features I've already described above, implemented in cpp. There were a few reasons for "starting over" in C#. First off, I'll admit I was bedazzled by what C# and XNA could offer. The IDE is a pure joy to work with. The features of the language and Visual Studio 2005 mean I can break ground on new components quickly and relatively cleanly. I have my reservations about performance and memory use, and I'll have to wait for some stress-testing to check those, but at the moment I'm fairly optimistic that those will be very minimal hits.

I want to focus on getting my project out the door (well, more accurately, into a playable state) as soon as possible and XNA is certainly something that will help me achieve this. While I'm a little dissapointed in some of the missing features (no built-in text or GUI support), I'm sure these will be rectified in future releases and on the whole, I'm very impressed. In terms of something that will prevent me from having to reinvent the wheel, while allowing me the flexibility to create the engine with the features I want, I'm pretty impressed.

The other main reason for the change was that I've realised that having a mesh-editor in my scene-editor was heaps of overkill. I'll mainly be working with an external editor (probably blender atm) and importing the meshes into my scene as .x files. Again, this is for ease of development. While having an integrated mesh editor in your scene-editor is cool, the time spent maintaining it and keeping it "usable" was eating into game-dev time majorly.

I'm planning to have some screenshots to show later in the week. But for now, you'll have to be satisfied with my textual droolery. Really, anyone who is interested in getting into 3D engines (although it's not really for complete noobs) in a nice simple framework would do well to take a look at the tutorials above. It doesn't result in a complete engine, but would get you well on your way.
Sign in to follow this  


13 Comments


Recommended Comments

Quote:
Original post by LachlanL
There were a few reasons for "starting over" in C#. First off, I'll admit I was bedazzled by what C# and XNA could offer. The IDE is a pure joy to work with. The features of the language and Visual Studio 2005 mean I can break ground on new components quickly and relatively cleanly.


Heh, I see that "initial shock" a lot. C# makes life pretty nice, but it certainly wears off a lot once you realize that your C#+XNA application is more or less impossible to distribute to any non C#+XNA developers. [sad]

Share this comment


Link to comment
Impossible to distribute? The XNA redistributable is 2MBs in size and I think the .Net 2.0 runtime is something like 20MBs. It might require users with dinosaur computers to download a few things, but it's hardly "impossible".

Share this comment


Link to comment
Quote:
Original post by Scet
Impossible to distribute? The XNA redistributable is 2MBs in size and I think the .Net 2.0 runtime is something like 20MBs. It might require users with dinosaur computers to download a few things, but it's hardly "impossible".


You also need to keep in mind that C# is an interpreted language, so while you may be able to get decent speeds you'll probably have a really tough time matching up with native C++. Additionally there's the portability aspect (to linux, for example), but seeing as you are using direct x, that wasn't much of an issue to begin with :-)

Share this comment


Link to comment
"realy tough time"? That's bullcrap. It's compiled at runtime, and it has no problem matching the speeds of most C++ programs. It's all a matter of knowing how to use it. There are plenty of crappy, inefficent C++ programs out there and I'm sure there are for C# as well. It has nothing to do with the language.

As for portablility, I'd argue C# is more portable then C++ since the same executable can run on Windows, Mac and Linux.

Anyway I'm tired of having to defend it. If you don't want to use it, I don't care, but don't tell other people it's crap when it's not.

Share this comment


Link to comment
Quote:
Original post by Scet
"realy tough time"? That's bullcrap. It's compiled at runtime, and it has no problem matching the speeds of most C++ programs. It's all a matter of knowing how to use it. There are plenty of crappy, inefficent C++ programs out there and I'm sure there are for C# as well. It has nothing to do with the language.


THere are plenty of inefficient C++ programs out there, but none of them are compiled to MSIL before being sent on to an interpreter. It's the same difference between C++ and Java - one is native, one is interpreted. Because that extra step is there, it'll always be slightly slower at its best. Granted, .NET mitigates this problem by being able to control the virtual machine and the target platform, but the problem still exists.

Additionally, I never stated that it's crap. I said that it can never be as fast as C++ in some situations. Are those situations rare? Yeah, probably. Do I know what they are? Not off the top of my head. Does that change the fact that interpreted languages are slower than native? No.

Disclaimer: I spent 2 years as a .NET coder, so I have experience in both. C# is indeed a great language and a worthwhile learning effort for every coder, even though it is owned, operated, and maintained exclusively by Microsoft.

edit: Note that these speed differences are only applicable for fully optimized code with equivalent versions in both languages. To compare anything else really doesn't make sense, as the programs themselves will not be the same (and thus any benchmark will be equivalent to saying "My add1toaNumber program runs faster than your fullandawesomezbuffer implementation!"

Share this comment


Link to comment
Quote:
Original post by Scet
Impossible to distribute? The XNA redistributable is 2MBs in size and I think the .Net 2.0 runtime is something like 20MBs. It might require users with dinosaur computers to download a few things, but it's hardly "impossible".


End users need MDX as well, which is even bigger. I guess the right word is 'impractical'. I've been using C# and .NET for a few years now, so I know first-hand that tons of people a) don't have the needed prerequisites, and b) just plain don't want to download them. It's unfortunate, but that's how it is. [sad]

Share this comment


Link to comment
Hey, thanks for the input guys. [grin]

Yep, as I said in my post, I'll have to wait for some stress-testing to see what the performance is actually like in practice. I'm willing to bet, however, that most performance issues would be down to my implementations, rather than the language itself.

In terms of raw productivity, yes, I'm pretty bedazzled. The features of the IDE, .Net (specifically it's generic collections & some other bits and bobs) and C# allow me to "just get things done" on my code much faster than previously. I'm not looking to make the next Doom 5, so if there's a small performance penalty (which would most-likely be at application-load time) then I'm happy to wear it.

It terms of being able to ship to end-users, that is something that concerns me. Like I said, I'm not looking to make the next Doom 5, so people are unlikely to want to download in the order of twenties of MB of "infrastructure" just to play my game. I'll have to look into this a bit more.

Share this comment


Link to comment
EvilStickMan, sorry to disappoint you but in those two years you have apparently not learned that neither C# nor Java are interpreted.

If you want to know how the Hotspot JVM works then have a look at this: http://java.sun.com/javase/technologies/hotspot/

Share this comment


Link to comment
Well, after a bit of poking around I'm a bit happier with my choice. Looking at this page regarding the next release of XNA, I'm pretty sure that some of the things I was worried about will be fixed (or included). And that also in the not too distant future.

Anyway, with regards to the "interpreted language" thing, I was under the impression that the code was compiled into native on application-start. This would result in a slight pre-processing hit, but hardly a performance issue? Am I missing something?

Also, there's disagreement about the distribution thing. Some people say that you need extra stuff, others say you just the XNA redistributable (easy 2MB), DirectX (assumed) and .Net 2.0 (I'd say that anyone who hasn't already installed that, should anyway!). To be honest, it doesn't make sense to me that they'd make people download huge amounts of extra stuff to play XNA games. XNA is meant to just sit on top of DX (and replace MDX) after all. Perhaps in the earlier beta versions you needed to distribute MDX as well, as it used some MDX functionality?

Share this comment


Link to comment
Quote:
Original post by LachlanL
Anyway, with regards to the "interpreted language" thing, I was under the impression that the code was compiled into native on application-start. This would result in a slight pre-processing hit, but hardly a performance issue? Am I missing something?


Nope; you're right on the nail. The JIT compilation allows .NET programs to have (more or less) native-calibre performance.

Quote:
Also, there's disagreement about the distribution thing. Some people say that you need extra stuff, others say you just the XNA redistributable (easy 2MB), DirectX (assumed) and .Net 2.0 (I'd say that anyone who hasn't already installed that, should anyway!).


Users will definitely need: XNA resdistrib, Managed DirectX, .NET Framework 2.0, and SP2. Most people have the last one, but I'm surprised how many 'average users' just don't have MDX or .NET 2.0.

Quote:
To be honest, it doesn't make sense to me that they'd make people download huge amounts of extra stuff to play XNA games. XNA is meant to just sit on top of DX (and replace MDX) after all. Perhaps in the earlier beta versions you needed to distribute MDX as well, as it used some MDX functionality?


Well, the thing about XNA is that mainstream distribution isn't their main goal. From the information that I've gathered Microsoft is aiming for XNA to be like a game developers' YouTube. Your intended audience is other developers, whether you like it or not. It's even worse for XBox 360 deployment -- end users need C# Express 2005 and your source code. It's for reasons like these that I've decided that despite XNA's prettiness, it's just not viable for distributing games outside of the narrow developer audience. [depressed]

And I'm sorry if I turned this entry into an XNA/.NET war, heh. My intent was only to warn you about some of the pitfalls of using XNA. [smile]

Share this comment


Link to comment
Quote:
Original post by HopeDagger
Well, the thing about XNA is that mainstream distribution isn't their main goal. From the information that I've gathered Microsoft is aiming for XNA to be like a game developers' YouTube. Your intended audience is other developers, whether you like it or not.

Well I'm sorry to tell you that you've gathered some rather incorrect information. It clearly states on the developer blog that they are working hard on figuring out deployment on the PC and XBox 360 to non-developers and they realize that this is a key issue. It is much more important to get the functionality out the door and developers building games and worry about how to distribute them later.

Quote:

It's even worse for XBox 360 deployment -- end users need C# Express 2005 and your source code.

Yes for this initial release you do. But you should have read that in May when the next release comes out there is a binary so people can easily install to windows/360 without needing the source and VS. It's a step towards the bigger picture.

Also for the person that posted:
Quote:

You also need to keep in mind that C# is an interpreted language

I'm sorry to have to break the news to you that C# is not an interpreted language. It looks like those 2 years you spent in .Net development was as a hacker/webmonkey or something as you really have no idea of the core internals of the framework.

Share this comment


Link to comment
Quote:
Original post by Saruman
Well I'm sorry to tell you that you've gathered some rather incorrect information. It clearly states on the developer blog that they are working hard on figuring out deployment on the PC and XBox 360 to non-developers and they realize that this is a key issue. It is much more important to get the functionality out the door and developers building games and worry about how to distribute them later.


Very awesome to hear. I'm glad that MS really is interested in moving XNA into a mainstream developer tool.

Share this comment


Link to comment
Quote:

Also for the person that posted:
Quote:

You also need to keep in mind that C# is an interpreted language

I'm sorry to have to break the news to you that C# is not an interpreted language. It looks like those 2 years you spent in .Net development was as a hacker/webmonkey or something as you really have no idea of the core internals of the framework.


Well then what do you call a language that is 1: not compiled directly to machine code (it is compiled into Microsoft Intermediate Language, or MSIL), and 2: run using a virtual machine (called the Common Language Runtime, or CLR)? If that's not interpreted, then what is?

I know wikipedia is a bad source, but it's right there at the top of the article for intepreted languages: http://en.wikipedia.org/wiki/Interpreted_language -

Quote:

Many languages have been implemented using both compilers and interpreters, including Lisp, C, BASIC, and Python. While Java and C# are translated to a form that is intended to be interpreted, just-in-time compilation is often used to generate machine code.


I don't know where you're getting your information, but obviously there's a disconnect here. After doing a bit more research, I came up with the following (from CSharpHelp.com :

Quote:

Statements like, "C# is compiled and Java is interpreted," are simply marketing spin. Java byte code and MSIL are both intermediate assembly-like languages that are compiled to machine code for execution, at runtime or otherwise.


And the following from GotMono.com (mono is an open source .NET compiler/framework interpreter) :

Quote:

All Mono languages, including C# are compiled with a compiler by the developer. However the output is not a native binary file, but a special bytecode, called CIL (or IL or MSIL). This bytecode is unreadablebut can not be executed by the computer. It is important to understand, that all Mono languages are compiled to CIL, C# as well as MonoBasic.


There's also a discussion on the subject at dotnet247.com. Those are the first three links on a google search of "Is C# Interpreted?", and the consensus is "Yes". When the application is first run, the code is JIT-compiled into machine code.

A C# program can be compiled natively, but it is not done by default. Everything in visual studio .NET is compiled into the MSIL, and eventually into machine code when the code is run. External compilers may compile C# into native code, but at its core the language was developed for and released with the .NET framework, one of the major selling points of which was its ability to utilize different languages in the same application by compiling everything into MSIL, which could then be run as a single program. The point still stands - C# uses JIT compilation to turn itself into machine code when it is run. Sounds interpreted to me. Of course this discussion is obfuscated by scripting languages like python and lua, which are 100% interpreted (instead of JIT compiled at run time). So perhaps the disconnect here is between "light" interpreted languages (c# and java) which are compiled into machine code when they are run, and fully interpreted languages which are interpreted line-by-line. In either case, there is interpretation going on.

Finally, I'm sure your little jab at my coding experience (.NET architect for a fortune 500 company) made you feel better about yourself, but it certainly doesn't make you look less petty. However, I will retract the performance hit statement - as mentioned above by others and then me, since the code is JIT compiled at start it will run as native during execution, so the hit will be at init/load time.

Share this comment


Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now