OK, so I know most intelligent people are tired of the MS bashing that 
goes on, but I still couldn't resist the title :)

Anyway, a few days ago I downloaded the free XNA studio* to give it a 
try.  I read a bit on C#** over the last couple of days, decided it 
might be worth trying out (it couldn't be worse than Java, and I gave 
*that* a try), and tonight fired up the studio to look through some of 
the tutorials and examples.

I must say, I'm quite impressed with a couple of things in it.

1) The project frameworks provided are incredibly robust and complete. 
Creating a new project from a template sets up a decent game framework 
that can be extended and customized with ease.  Game properties like 
framerate limits, constraints on video resolution, etc can be set with 
one line of code due to the layout of the data structure.  At best with 
C++ game libraries I've looked at, I've had to copy & paste not only 
several files of generic code to get a working app, but also hunt 
through the Project Settings to look out for anything that might cause 
problems.

2) Resource manage is *incredibly* easy.  In the "Solution Explorer", 
simply bring up the context menu and choose "Add Existing" or "Add New", 
give it a name (and select the file if it aleady exists), and it's 
imported into the correct directory.  Loading the resource in your code 
is as easy as one line, and you only specify the resource name as a 
handle - you don't have to worry about the actual file name or directory 
at all.

3) It "compiles" extremely quickly compared to C++.

4) The included documentation seems complete and informative.

In about 15 minutes, I had a bouncing ball and a framerate counter. 
Mind you, this is the first time I've *ever* done anything with either 
C# or XNA Studio.  It was very easy to get into, and I feel like I at 
least know where to look for everything I need.

This weekend I'm going to start work on a larger test project to see how 
it handles.  I'm interested to see how I respond to working on something 
larger, and if I'll remain as positive and hopeful after a few days with it.

*For those of you who are not aware, the XNA Studio is a special 
packaging of Visual Studio designed specifically for creating casual 
games on the XBox and Windows platforms.  Amateur game developers are 
allowed to upload their games to the XBox Live Marketplace, where anyone 
on Windows or an XBox can play them.  If I end up liking C#, then 
playing my games with friends will be one more reason to get an XBox 360.

**I won't comment on the language until I've used it a bit more.

-- 
...Ben Chambers
www.pacificwebguy.com

Post a reply to this message

Chambers <ben### [at] pacificwebguycom> wrote:
> OK, so I know most intelligent people are tired of the MS bashing that
> goes on, but I still couldn't resist the title :)

Not everyone. :)

> 1) The project frameworks provided are incredibly robust and complete.
> Creating a new project from a template...

Incredible amounts of easy and ready-to-go templates and wizards are to be
expected from companies looking to attract developers for their platforms.

Open-source generally just provides the essential functionality and leaves it to
the user community to provide added value in the form of documentation,
tutorials, plugins and templates scattered through many websites... ;)

> 3) It "compiles" extremely quickly compared to C++.

*Anything* compiles extremely quickly compared to C++.  Just don't perform the
same.

Except, of course, if it really is a wrapper to underlying functionality written
in C/C++...

Post a reply to this message

Chambers wrote:
> OK, so I know most intelligent people are tired of the MS bashing that 
> goes on, but I still couldn't resist the title :)
...

So the ones that aren't tired of it aren't intelligent ?

;)

-- 
Tor Olav
http://subcube.com

Post a reply to this message

nemesis wrote:
> Chambers <ben### [at] pacificwebguycom> wrote:
>> 1) The project frameworks provided are incredibly robust and complete.
>> Creating a new project from a template...
> 
> Incredible amounts of easy and ready-to-go templates and wizards are to be
> expected from companies looking to attract developers for their platforms.

True, but it's still annoying to have to spend so much time to set up a 
project with other tools.

Like I said before, I want to see how I feel after doing something a 
little larger with it :)

-- 
...Ben Chambers
www.pacificwebguy.com

Post a reply to this message

nemesis wrote:
> *Anything* compiles extremely quickly compared to C++.  Just don't perform the
> same.

With JIT compilers and such, I'm not sure how you can be so sure. :-)

-- 
   Darren New / San Diego, CA, USA (PST)
     "That's pretty. Where's that?"
          "It's the Age of Channelwood."
     "We should go there on vacation some time."

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> nemesis wrote:
> > *Anything* compiles extremely quickly compared to C++.  Just don't perform the
> > same.
>
> With JIT compilers and such, I'm not sure how you can be so sure. :-)

Look for the top:
http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=all&calc=Calculate&xfullcpu=1&xmem=0&xloc=0&binarytre
es=1&chameneosredux=1&fannkuch=1&fasta=1&knucleotide=1&mandelbrot=1&meteor=0&nbody=1&nsieve=1&nsievebits=1&partialsums=
1&pidigits=1&recursive=1&regexdna=1&revcomp=1&spectralnorm=1&hello=0&sumcol=1&threadring=1
with memory performance taken into consideration as well, it only gets worse:
http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=all&calc=Calculate&xfullcpu=1&xmem=1&xloc=0&binarytre
es=1&chameneosredux=1&fannkuch=1&fasta=1&knucleotide=1&mandelbrot=1&meteor=0&nbody=1&nsieve=1&nsievebits=1&partialsums=
1&pidigits=1&recursive=1&regexdna=1&revcomp=1&spectralnorm=1&hello=0&sumcol=1&threadring=1

Yes, I'm aware theoretically a JITted program running for long should be able to
be extra tuned on the fly and drop irrelevant parts to run faster.  That isn't
reflected in the charts, of course.

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> nemesis wrote:
> > *Anything* compiles extremely quickly compared to C++.  Just don't perform the
> > same.

> With JIT compilers and such, I'm not sure how you can be so sure. :-)

  I have no idea about the principles used in C#, but if it's anything like
Java, the biggest problem is not so much speed as memory usage. In Java
I don't think there's any way around the problem that you cannot create
a data container where each element takes as much memory as the total size
of the members of the object, nothing more. The smaller the object is, the
worse the memory usage overhead relative to this size.

  I actually find it a bit worrying that it seems that no programming
language introduced in the last 20 years which has got some popularity
seems to offer any tools *whatsoever* to create memory-efficient programs
(at least not without resorting to really ugly code which bypasses nice
modular design).

  Many people will say "that doesn't matter, memory amount is increasing
all the time". However, that's only a valid point for programs which use
a *fixed* amount of memory for what they do. In other words, a program
which required a fixed amount of 500 megabytes of memory when written in
a memory-efficient way in C++ 10 years ago may well run ok when written
in Java with a modern computer which has 4 gigabytes of RAM.

  However, it's rather rare that a program uses a huge amount of memory,
and that this amount is somehow fixed. The more usual case is that memory
usage is dynamic, and having more RAM in the computer will allow the program
to perform more than before. In other words, that program which 10 years
ago could perform a certain task with 500 MB of RAM may well be able to
perform a much larger task in a computer with 4 GB of RAM, while the java
version will only be able to perform the same task as the 10yo computer.

  In other words, the same program written in Java will be able to do
less than the version written in C++. And often you just *can't* create
a Java version which would be able to do the same things as the C++ version
with a given amount of memory, no matter what you try. (In some cases
similar memory usage may be achieved in Java, but at the cost of making
the code less modular and a lot more complicated.)

-- 
                                                          - Warp

Post a reply to this message

Chambers <ben### [at] pacificwebguycom> wrote:
> 2) Resource manage is *incredibly* easy.  In the "Solution Explorer", 
> simply bring up the context menu and choose "Add Existing" or "Add New", 
> give it a name (and select the file if it aleady exists), and it's 
> imported into the correct directory.

  Does it have any support for creating a (possibly encrypted) package
from all the resources so that you don't have to distribute a bare version
of your resources directory structure, but instead you can simply distribute
this single package file with your program?

  (There are many reasons why one would want to do this, but the main
reason is that packaging (and encrypting) all the resources is a simple
"anti-spoiler measure": A curious user navigating the directory structure
of the game won't be able to spoil himself about the contents of the game
by simply double-clicking on the files.)

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
>   I have no idea about the principles used in C#, but if it's anything like
> Java, the biggest problem is not so much speed as memory usage.

It's a lot like Java, but not in that respect. C# has things called 
"structures" which you can't inherit from, but are otherwise objects. 
They're basically value semantics. It's part of the type rather than the 
variable (unlike C++), but an integer takes the same number of bytes in 
C# as in C++.  I.e., you can make a struct that takes 12 bytes of 
storage, create an array of 10 of them, and it'll take 120 bytes of storage.

C#'s VM is also more targetted at JIT compilation. For example, at any 
given point in the VM bytecode, no matter how you get there, the stack 
has to have the same types on the stack. So in theory, if you had a 
bunch of registers, you could assign anything that was put onto the 
stack into a register instead. Just as one of many examples.

>   I actually find it a bit worrying that it seems that no programming
> language introduced in the last 20 years which has got some popularity
> seems to offer any tools *whatsoever* to create memory-efficient programs

We already have those languages. Anyway, you're missing Ada. :-)

-- 
   Darren New / San Diego, CA, USA (PST)
     "That's pretty. Where's that?"
          "It's the Age of Channelwood."
     "We should go there on vacation some time."

Post a reply to this message

Warp wrote:
>   Does it have any support for creating a (possibly encrypted) package
> from all the resources 

I thought it was pretty cool that you can encrypt the debug info in 
Erlang with a chosen key, so you can understand the stack traces only if 
  you have that key, for example.  Full source-level debugging with the 
package, but no way to recreate the source without knowing the key.

-- 
   Darren New / San Diego, CA, USA (PST)
     "That's pretty. Where's that?"
          "It's the Age of Channelwood."
     "We should go there on vacation some time."

Post a reply to this message