Jump to content

Davaris

Members
  • Posts

    285
  • Joined

  • Last visited

Posts posted by Davaris

  1. Interesting. I thought LUA was just bare bones. I've never used it before, outside of following a few LWs tutes.

     

    As for C# I like it almost as much as Python, because it has .NET and enforces a few rules to keep me out of trouble. I don't know if it will have the speed to do what I want to do yet, but I guess I'll find that out sometime this year. :D

  2. In other words: If you're worried so much about minor performance issues such as this one over development speed, have a look into C++ or C, which run faster but develop slower.

     

    My chief concern is standards, so people can use libraries they have built up without having to maintain different versions for different engines. However if the speed difference is as great as claimed, then I'd think again.

     

    As for C++, I've been there and done that and now I prefer languages that are easier and more enjoyable to use. Case in point, if Python wasn't so slow, I'd be using that instead of C#.

  3. I just looked up XNA and Vector3 is struct there as well.

     

    Anyway as I said above, for fundamentals like Vector3, Point, string, etc, it might be an idea to see what the consensus is on the popular 3D engines using C#. As most programmers have built up libraries and game code, they won't want to maintain two versions if LWs C# is the odd man out.

     

    Not that I am saying LW C# is the odd man out. The only ones I have checked is DirectX, Unity and XNA.

     

    EDIT:

    I just found this. Perhaps it is an argument for keeping Vector3 as a class?

     

    http://dotnetperls.com/static-constructor

     

    You want to determine the performance hit for static constructors in the C# programming language. Microsoft and many developers warn that static constructors on a type impose a substantial overhead. Static constructors are also called type initializers, because they refer to types, not instances. Here we test static constructors in the C# language and determine if they are useful.

     

    === Static constructor performance test in C# ===

     

    Class 1: Has static constructor

    Time: 3208 ms

     

    Class 2: No static constructor

    Time: 319 ms

  4. Other than that the actual code for the type will not change so unless you are seeing any performance problems using these types, changing them from classes to structs now is just premature optimisation.

     

    I'm thinking more in terms of assumptions people make, when they're building their games. With pass by value, or pass by reference, you can make changes to pass by value, without altering the original value. But if its pass by reference, then you alter the source.

     

    So if there is one standard used by other engines and we are the only ones doing something different, then it can isolate us - if you get my drift. Anyway I don't know how much of a big deal it is, when it comes to doing conversions. I guess it depends on how complex the game part of your engine is.

  5. Not from my experience. Unity seems to only be C# or Javascript (their own version of it)

     

    http://unity3d.com/support/documentation/Manual/Plugins.html

     

    Plugins - Pro only feature

     

    Unity has extensive support for C, C++ or Objective-C based Plugins. Plugins will work in standalones only. They are disabled when building a Web Player for security reasons.

     

    This is supposed to be pro only, but I have been told there is a way to do it with the free version.

  6. How can they be the best of the best if they choose C#? With C++ you can have value type classes too, so there is no such limitation that classes can be only references.

     

    But this is C# not C++. Also who are you referring to MS, or Unity? DirectX can be used in C++ or C#. Unity can be used in C++ and C#.

  7. There must be a reason why Unity and Microsoft chose structs over classes.

     

    I just checked C# 3.0 Pocket Reference:

     

    Structs

    A struct is similar to a class, with the following key differences:

    • A struct is a value type, whereas a class is a reference type.

    • A struct does not support inheritance (other than implicitly

    deriving from object).

     

    A struct can have all the members a class can, except:

    • A parameterless constructor

    • A finalizer

    • Virtual members

     

    A struct is used instead of a class when value type semantics

    are desirable. Good examples of structs are numeric types,

    where it is more natural for assignment to copy a value rather

    than a reference. Because a struct is a value type, each

    instance does not require instantiation of an object on the

    heap. This can be important when creating many instances

    of a type, for example, with an array.

     

    At any rate you may want to investigate why they chose structs over classes, because MS and Unity hire the best of the best, so I assume there is a very good reason for why they both made the same decision.

     

    Anyway its up to you guys. I just thought I'd point it out. :P

  8. I really like the grid lines thing you have there. Michael Betke has something similar in his asset demos and it reminds me of pen and paper RPGs. ;)

  9. IF anything was to change, it would be the ToString, not the Parse.

     

    Which would lead us to:

    public override string ToString()
    {
       return string.Format("{0},{1},{2}", this.X, this.Y, this.Z);
    }

     

    As long as it works in XML, that's fine by me. I am using what I assume is ToString to save and Parse when I'm loading.

     

    This is how I'm using it:

     

    // Saving

     

    XElement entry_list = header.Element("Entries");
    
    entry_list.Add(new XElement("Entry",
    new XElement("Key", entry.Key),
    new XElement("Value", entry.Value),
    new XElement("Type", entry.Value.GetType().Name)));

     

    // Loading

     

    XElement key = x.Element("Key");
    XElement value = x.Element("Value");
    XElement type = x.Element("Type");
    
    switch (type.Value)
    {
    case "String":
     mCurrSD.Put<string>(key.Value, (string)value.Value);
     break;
    case "Boolean":
     mCurrSD.Put<bool>(key.Value, bool.Parse(value.Value));
     break;
    case "Int32":
     mCurrSD.Put<int>(key.Value, int.Parse(value.Value));
     break;
    case "Single":
     mCurrSD.Put<float>(key.Value, float.Parse(value.Value));
     break;
    case "Vector3":
     mCurrSD.Put<Leadwerks.Vector3>(key.Value, Leadwerks.Vector3.Parse(value.Value));
     break;
    }
    

  10. public override string ToString()
    {
    return string.Format("X:{0} Y:{1} Z:{2}", this.X, this.Y, this.Z);
    }
    
    public static Vector3 Parse(string value)
    {
    string[] values = value.Split(',');
    return new Vector3(float.Parse(values[0]), float.Parse(values[1]), float.Parse(values[2]));
    }

     

    The Parse function above is looking for ',' which doesn't exist. Here is the fix:

     

    public static Vector3 Parse(string value)
    {
    char[] delimiterChars = { 'X', 'Y', 'Z', ':', ' ' };
    
    string[] values = value.Value.Split(delimiterChars, StringSplitOptions.RemoveEmptyEntries);
    
    return new Vector3(float.Parse(values[0]), float.Parse(values[1]), float.Parse(values[2]));
    }                    
    

  11. From what I have read, you can mark parts of the code to be non compliant. I don't know if it can still be used with these collections though.

     

    http://www.devarticles.com/c/a/C-Sharp/Making-Your-Code-CLS-Compliant/

     

     

    You can apply the CLSCompliant attribute on an assembly (or a program element) and have the compiler check if your code is CLS (Common Language System) compliant. This means it works properly when consumed by other .NET languages. For example, you can place the following attribute on your .NET AssemblyInfo.cs files:

     

    [assembly: CLSCompliant(true)]

     

     

    Some of the things the compiler checks:

     

    Class and member names cannot differ only by case. For example, you can't have one property named Counter and another named counter. This is important for cross-language compatibility since VB .NET isn't case sensitive.

     

    Overloaded class methods cannot differ only by out or ref parameter designations.

     

    Publicly exposed members cannot start with an underscore ( _ ).

     

    Operators can't be overloaded

     

    Unsigned types can't be part of the public interface of a class

     

    Unfortunately, although you can apply the CLSCompliant attribute in VB .NET, the VB .NET compiler doesn't check for CLS compliance. In VB.NET 2005, this has apparently been fixed.

  12. I'm using Wintellect's Power Collections for .NET

     

    http://powercollections.codeplex.com/releases/view/6863

     

    and am getting warning messages like:

     

    Argument type 'Leadwerks.Vector3' is not CLS compliant

     

    whenever I declare a Leadwerks type.

     

    I found the cause is this line in Wintellect's algorithms file:

     

    // Everything should be CLS compliant.
    [assembly: CLSCompliant(true)]

     

    Does anyone know what the problem is? Is it an issue with Leadwerks itself, or is it the C# wrapper?

×
×
  • Create New...