|
Bill307
Canada9103 Posts
On July 17 2009 04:29 King K. Rool wrote:
How is C# for game programming?
As for C# and XNA, I think the fact that nearly-identical code can run on both a Windows PC and an XBox 360 is great. I also think Visual C# is a terrific IDE.
However, I have a number of gripes with the language and with XNA.
1. XNA's Matrix multiplication is backwards. Seriously. If you have two matrices A and B, and you want to transform A by B, then in linear algebra, you'd write "B * A", but in XNA, you'd write "A * B".
I have a strong math background, so for me, this is the biggest WTF by far.
2. The documentation is ass. A while ago, I was trying to figure out exactly when data was copied from your system's memory to your GPU's memory. Repeatedly, I ran into such detailed documentation as:
http://msdn.microsoft.com/en-us/library/microsoft.xna.framework.graphics.vertexbuffer.aspx
VertexBuffer Class
Represents a list of 3D vertices to be streamed to the graphics device.
Useless.
Another example: I was trying to see how to load a custom Effect file on the XBox 360 without going through the ContentManager, or if this was even possible. I still don't know if this is possible or not, actually: after searching for hours I gave up and changed the way my code worked instead.
After learning much of my Java knowledge by reading its incredibly-detailed API documentation, XNA's documentation was hugely disappointing.
3. C# Properties. Properties in C# are used like variables, but they are accessed through "get" and "set" methods.
For example, suppose you want to change an enemy's hitpoints. In Java, you'd do something like this:
oldHP = enemy.GetHitpoints();
enemy.SetHitpoints(newHP);
Using a C# Property, you would instead write:
oldHP = enemy.Hitpoints;
enemy.Hitpoints = newHP;
When you access enemy.Hitpoints, you are actually calling the Property's "get" method, and when you assign it a new value, you are calling the Property's "set" method.
Maybe you can already start to see why Properties can cause problems... 
3a. The naming convention for Properties.
Suppose my game class has a Camera variable. Naturally it'll be called "camera". Now suppose I want other classes to be able to access it. The C# way is to use a public Property, called "Camera". Great, a variable with the same name as a class!
In general, Properties look like classes or inner classes when you use them. The only visual cue is Visual C#'s syntax highlighting, where classes are written in teal while Properties are written in black.
3b. Properties are operator overloading.
The danger of using public variables is that somewhere down the road, you might want to run some additional code whenever a variable is changed, e.g. to send an event when an enemy loses hitpoints, but if the public variable is being changed directly, then you can't do that.
On the other hand, it's a lot easier to get and set public variables versus having to type GetValue() and SetValue() every time, not to mention having to write these methods. Indeed, it can get tiring to write these methods over and over when 99% of the time, all they do is set and get a variable.
At a glance, Properties seem like a solution to this problem. Syntactically, they're used just like a public variable, but they also allow you to run some additional code whenever a variable is set or retrieved, which is the benefit of writing GetValue() and SetValue() methods.
But they're really just operator overloading, complete with all the problems of it.
Operator overloading abuse aside, 99% of the time, when you see a Property it's going to be simple get/set one, that acts just like getting and setting a variable. So when that 1% case comes up, where the get/set does something else, it can be confusing for everyone, even the original author if he's away from his code for too long. In contrast, when you have to call GetValue() or SetValue(), it's a visual reminder that you might be doing more than just getting or setting the variable.
Needless to say, while I'm forced to use the Properties built into C# and XNA, I completely avoid using Properties myself.
|
Maybe this is just a gaming thing where every milliseconds count but from experience, object allocation is VERY cheap these days (at least in the JVM. I would assume the same in the CLR), in some cases even cheaper than in C++. Object pooling do have their uses but they can be error prone (memory leak, etc) because the scope the object gets bigger. I would say in the majority of cases, it's always better to narrow the scope of your objects. Anyways this is for general programming, but for gaming I may be completely wrong since every milliseconds count.
|
On July 17 2009 20:53 MasterOfChaos wrote:
Did you do any measurements to determine that object allocation limits performance?
And why do you have so many different managers?
@freelander
Simply compress it afterwards?
I think what Bill meant with "Object Allocation limit" is that when you start creating thousands of objects over and over, GC will take a toll. Usually the GC overhead is negligible in business apps as long as you avoid nasty Full GC, but for gaming I would assume everything counts.
|
Germany2896 Posts
I think I have read almost every article about the .net GC in existance because I simply can't get myself to really trust such a beast. The problem is that my current game design uses lots(perhaps 100k) of small objects.
But I guess I'll simply hope that .net 4.0's background GC is good enough.
The one thing I fear the most is not deterministic behaviour. My networkcode(and replays) require that the game runs completly deterministic given the same input on different machines. For example this means I can't use any floats inside the gamelogic(I have implemented a fixedpoint struct). Other things which might get problematic are GetHashCode, iteration over the entries of a dictionary, weakreferences, and probably a lot of features I don't even know about yet -_-
Personally I like properties and the naming conventions of C# a lot, because it's basically the same as in Delphi.
The one thing where they are counter intuitive is if you have a property of a mutable struct type and call a method which modifies it. As the method is called on a copy of the struct(it is returned by value) the property will not be changed. But mutable structs are usually bad style anyways.
|
haha learning java now.
Object oriented is fun
Before:
Is_A_equal_to_B(a,b);
After:
a.Do_I_look_Like_That_Other_Dude(b);
|
Germany2896 Posts
On July 20 2009 16:49 evanthebouncy! wrote:
haha learning java now.
Object oriented is fun
Before:
Is_A_equal_to_B(a,b);
After:
a.Do_I_look_Like_That_Other_Dude(b);
IMO the "Before" part is nicer. It reflects the symmetry of a comparison a lot better than the second one. And the second one has the additional disadvantage that it throws if a==null.
|
Yeap but equals is a method that comes from the Object class. Usually your classes will override the equals method from the Object class so most projects you see will actually use the "Before" part.
|
Bill307
Canada9103 Posts
On July 20 2009 16:34 MasterOfChaos wrote:
The one thing I fear the most is not deterministic behaviour. My networkcode(and replays) require that the game runs completly deterministic given the same input on different machines. For example this means I can't use any floats inside the gamelogic(I have implemented a fixedpoint struct). Other things which might get problematic are GetHashCode, iteration over the entries of a dictionary, weakreferences, and probably a lot of features I don't even know about yet -_-
Wait... what are the odds that floats will be computed differently on different machines? o_Oa I guess it's not much of a problem for me, since our main target platform is the 360. And if a replay fails on someone else's computer, then at least you can always make a recording of the replay on your own computer.
I don't trust C#'s GetHashCode(), either. Java's hashCode() method will "typically" convert the object's reference address to an int, but the documentation for C#'s method was very vague (as usual -_-).
You could probably implement your own Dictionary without too much trouble, imo. At least then you could guarantee it'll always iterate over its entries in the same order.
|
Bill307
Canada9103 Posts
On July 20 2009 22:23 FreeZEternal wrote:
Yeap but equals is a method that comes from the Object class. Usually your classes will override the equals method from the Object class so most projects you see will actually use the "Before" part.
This reminds me of yet another case of bad C# documentation. -_-
Java's equals() method will return true iff the objects' references are equal. This is written explicitly in the documentation.
C#'s Equals() method, however, doesn't say anything about what it will return by default. (*sigh*)
C# does have a static ReferenceEquals() method for that purpose, though.
|
Germany2896 Posts
If I recall correctly GetHashCode returns some strange SyncObjectID which is determined at allocation time for reference types and the hashcode of the first field for structs. And the predefined valuetypes use sensible overrides.
And the floatingpoint desyncs shouldn't be that uncommon since .net generates CPU dependent code, and the x87 and SSE commands return different results for many calculations. My research showed that it is possible to tweak c++ to get reproducible floatingpoint code, but not .net. So I wrote a 32bit fixedpoint struct.
I think Equals() checks the identity for all fields for valuetypes and reference equality by default for reference types. But I never used it myself except for overriding it in my valuetypes to get rid of some warnings.
I only used == operator, ReferenceEquals and equality comparers.
And if you haven't used it so far, check out redgate reflector. My favourite .net "documentation".
|
On July 20 2009 17:52 MasterOfChaos wrote:Show nested quote +On July 20 2009 16:49 evanthebouncy! wrote:
haha learning java now.
Object oriented is fun
Before:
Is_A_equal_to_B(a,b);
After:
a.Do_I_look_Like_That_Other_Dude(b); IMO the "Before" part is nicer. It reflects the symmetry of a comparison a lot better than the second one. And the second one has the additional disadvantage that it throws if a==null.
Hehe yeah but iono, recursion with objects are mad fun
|
On July 21 2009 13:43 Bill307 wrote:Show nested quote +On July 20 2009 22:23 FreeZEternal wrote:
Yeap but equals is a method that comes from the Object class. Usually your classes will override the equals method from the Object class so most projects you see will actually use the "Before" part. This reminds me of yet another case of bad C# documentation. -_- Java's equals() method will return true iff the objects' references are equal. This is written explicitly in the documentation. C#'s Equals() method, however, doesn't say anything about what it will return by default. (*sigh*) C# does have a static ReferenceEquals() method for that purpose, though.
True, Sun did an amazing job documenting Java.
|
|
|
Germany2896 Posts
On July 21 2009 13:43 Bill307 wrote:
C#'s Equals() method, however, doesn't say anything about what it will return by default. (*sigh*)
The Object.Equals documentation is not that bad:
The default implementation of Equals supports reference equality for reference types, and bitwise equality for value types. Reference equality means the object references that are compared refer to the same object. Bitwise equality means the objects that are compared have the same binary representation.
|
Bill307
Canada9103 Posts
Are you joking?!?!
I think I could have figured out from the name "Equals()" that it compares if two objects are equal. Those remarks are completely useless.
Anyone checking the documentation for a method like "Equals()" is wondering, how exactly does it determine whether two objects are equal? E.g. does it compare the references, or does it check every member variable?
On July 22 2009 00:38 MasterOfChaos wrote:Show nested quote +On July 21 2009 13:43 Bill307 wrote:
C#'s Equals() method, however, doesn't say anything about what it will return by default. (*sigh*)
The Object.Equals documentation is not that bad: Show nested quote +The default implementation of Equals supports reference equality for reference types, and bitwise equality for value types. Reference equality means the object references that are compared refer to the same object. Bitwise equality means the objects that are compared have the same binary representation.
I assume by "supports" they mean "implements". But to me, "supports" is just what it can or may do, whereas "implements" is what it actually does. As a result, I probably disregarded that info the first time I read it.
|
|
|
|
|
|
EPT
