Unity Community


Page 8 of 9 FirstFirst ... 6789 LastLast
Results 141 to 160 of 170

  1. Location
    Gold Coast, Australia
    Posts
    3,594
    Quote Originally Posted by Ippokratis View Post
    NPSF3000 :
    Ok, you type fast !
    Wow I never realised how good I'm getting at touch typing - I still look down a lot though

    </Considers investing time in proper mastery>.

    It is less verbose to create a simple class.
    That's a classic example.

    It's less verbose to create a class but it hides the important fact that not every class has to be a monobehaviour.

    The time it takes to create a proper C# class is no different (Unity creates it based on a template for you) - the cost of a limited mindset, at least in my experience - huge.

    Lastly, your brain recognizes code patterns and fluff - it's not like you actually read every line every time you see a class.

    So yeah, this fits my opinion [though I don't think I've mentioned it yet this thread] UnityScript is for Scripting, C# is for programming.

    Though while we are at it, why include System.Collections?

    It is less verbose to access components
    Nope - look at your code it's near identical. Furthermore the including of the using and class servers no purpose as you've already covered it. Don't make me accuse you of double counting :P

    Code:  
    1.        transform.localPosition = Vector3.zero; //fixed
    2.         print(transform.localPosition.y);

    It is less verbose to deal with Types
    First time I've seen that function used.

    Code:  
    1. var GO = new GameObject("Player",typeof(MeshRenderer), typeof(MeshFilter) );  //Fixed


    I *think that it is possible to access the Extentions class via javascript, I am not aware of how to code it in UnityScript. It seems to me that "extensions" in the context you used it is the ability of creating new classes that extend the functionality of existing ones. Some things work, other not, the implementation is not as complete as in C#, hence my argument on viewing C# more suited for components creation.
    That's pretty much my knowledge of it. Though anyone tells me they need to do the 'hardcode' stuff in C# and the light stuff in US and i'll go on a rant about how US is nothing more than a turning-incomplete parasitical monster :P

    I need to point out that all you've pointed out are trivialities 'making simple things simpler'. Powerful things like events, extensions, linq, structs, lambda, properties, ref/out etc. are harder to do/less clear in US IIRC.

    I tried to go back to US for a client. Problem was is everything I'm used to doing was so poorly documented it was too costly to be worth the while.

    Time is an asset - no doubts. Fast made, readable, reusable code, fast, maintainable code, add yours. Perhaps coding is about balancing between those desirable outcomes. I still believe that real time applications should have fast code as a priority but I respect your POV. Perhaps I should add that a priority doesn't mean the only priority, to make my POV clearer.
    I'll just repeat what I said earlier. I do network programming. It's very complicated [hence my love for C#]. However I sit down and analyse the performance of every single action - down to the BIT on occasion. I've yet to run into a performance bottle neck that required micro-optimization but constantly struggle to manage the interactions between my systems.

    There are situations where performance is important - but wait until you can actually PROVE that that's so before wasting time on optimizing.

    I cannot keep up with this, you write too fast ! Swords down :P
    Dude, this is my sword :P

    Man that was a long time ago.


  2. Location
    Montreal, Canada
    Posts
    1,436
    If you worry about Delegate/Event speeds, NEVER use any built-in MonoBehaviour functions. Avoid all Awake, Update, On____, because these are absolutely massively slower than delegate invocation.

    In fact, proper use of these structures can be improving speed, for A) They have built in advantages like Linq/IEnumerators ability to only initialize(in some instances) the elements it is going to be using rather than all possible elements, while maintaining a small code base. This helps garbage collections/allocations, and can provide you with less memory use.
    And B)for Delegates/Events/etc.. you need to take into account you are not having to call X.Get() before invoking your functions, or call find() or grab proper references at the time you need to invoke these functions.

    In some situations Delegate calls in C# are as fast (and possibly even faster in edge cases) than virtual function calls: http://stackoverflow.com/questions/2...tes-vs-methods

    And Regardless you are going to have thousands to tens of thousands (or more) of other bottlenecks taking up more relative time that could be optimized easier and faster, long before cutting into the readability, debugability and overall ease of use these structures provide.

    In the proper situations these save you programmer time ($) and processor time. The amount of time spent to create equivalent systems and structures costs you time, and time is money.

    If you use C#, don't ignore these features under the assumption that they are somehow slower than more basic systems, and don't dismiss programmer time as a valuable asset when programming.

    Overall calling these things slow is wasteful and harmful to actually creating something. Do you use ++i instead of i++ in your loops, so that they can run faster? These are never problem areas with the current computing power (even on handhelds), and trying to solve these problems means less time spent actually finding the real bottlenecks, cause no-one writes even close to perfectly optimal code.

    The same things apply to stuff like Ref/Out(potentially less work done to invoke the function stack allocation wise), Structs(less Garbage Collections, Heap Allocations), Properties(Compiler has some micro-optimizations over functions in some edge cases). These are built to be used and be advantageous over their existing systems. They are not slow, they are not ineffecient(any more than anything else). But their still all Micro-Optimizations and their real benefits are programmer ease of use.
    Last edited by Ntero; 02-09-2012 at 03:01 PM.


  3. Location
    Athens, Greece
    Posts
    1,061
    Hi NPSF3000,

    I am trying to decide, should I create now a RTS - FPS - MMORG to prove you how wrong you are ( all of you ! ) or should I bite the bullet and start learning a thing or two about C# ?
    Jokes aside,
    Here's a slightly better example:
    Just out of curiosity, in this hypothetical scenario, could you integrate somehow a buffer in your code so you do not have to load the entire "Oxford.csv" in memory ? Or I get it wrong and this is exactly what the StreamReader does ? ( I am not playing smart here, since I played a while back with some big text files, I have this question ).

    The key is to evaluate all the costs, and give the best solution.
    Perhaps I have not expressed my POV correct, since you had to specify this. I totally agree with you on this one, since it is not clear from my previous post, I clear it here.

    Though while we are at it, why include System.Collections?
    Just because it is in the examples unity provided, thanks for pointing out that it is not needed.

    Don't make me accuse you of double counting :P
    My sword AGAIN !

    First time I've seen that function used.
    It is a (kinda) recent GameObject constructor. Had to deal with lots of in-Editor gameObject generation and found it handy.

    need to point out that all you've pointed out are trivialities 'making simple things simpler'. Powerful things like events, extensions, linq, structs, lambda, properties, ref/out etc. are harder to do/less clear in US IIRC.
    ...So yeah, this fits my opinion [though I don't think I've mentioned it yet this thread] UnityScript is for Scripting, C# is for programming.
    ... Problem was is everything I'm used to doing was so poorly documented it was too costly to be worth the while.
    I am getting bored of agreeing with you, let's fight !

    Overall, I am not arguing that less verbose is the A-Z in programming or that this specific quality justifies to use UnityScript for creating Nuclear Plants Operating Systems. You suggested that UnityScript isn't less verbose, I provided some "Stupid examples" that show some cases in which it takes less characters to achieve same results in UnityScript.

    There are situations where performance is important - but wait until you can actually PROVE that that's so before wasting time on optimizing.
    I do want my code to run fast - not at any cost though. I am not qualified to create light-speed code in any language and if someone claims that creates high performance applications using a scripting language ( as far as I get it in the Unity context C#, UnityScript and Boo are scripting languages ) it sounds like a joke to me.
    I just try to make "less slow code", as I understand it. The c++ core does the job, I script the game logic and I try not to script in a way that slows things down even more. Again, not at any cost, we are on the same boat on this ( I hope you know how to swim ).

    Thanks for taking the trouble to explain all those c# advanced features, it is really appreciated. I am not saying "Do not use it, 'cause it is slow", I am just pointing out that they have a cost that one should consider as another factor aside the flexibility they provide.

    Ntero :
    Thanks for getting into trouble to provide all these examples, it is much appreciated. I agree with you, all your points are valid, thanks for sharing your views.

    I really enjoy such discussions, I certainly learned many new things, thanks a lot for the feedback,
    -Ippokratis
    Last edited by Ippokratis; 02-10-2012 at 01:05 AM.
    Colored Shadows
    Batching Tools
    : Batch draw calls easily.
    Toon Shader Mobile: Good for mobile, fast and beautiful.
    Toon Shader Desktop: Good for desktops, more advanced.
    Thyella : A small game prototype on Kongregate


  4. Location
    Gold Coast, Australia
    Posts
    3,594
    Quote Originally Posted by Ippokratis View Post
    I am trying to decide, should I create now a RTS - FPS - MMORG to prove you how wrong you are ( all of you ! ) or should I bite the bullet and start learning a thing or two about C# ?
    What I'm preaching is well established! Eve uses python, Pikkoserver uses Erlang, Photon uses Lambdas, Unity uses C#. All slower than assemble :P. That said, C# allows more micro-opts than US :P

    Just out of curiosity, in this hypothetical scenario, could you integrate somehow a buffer in your code so you do not have to load the entire "Oxford.csv" in memory ? Or I get it wrong and this is exactly what the StreamReader does ?
    As long as you don't call something stupid like sr.ReadToEnd() this is exactly what a StreamReader should do. How do I know this? Well think of it this way: What happens if the stream is a TCP socket, streaming audio etc. In these situations it ranges from impractical to impossible to contain all data in memory.

    It is a (kinda) recent GameObject constructor. Had to deal with lots of in-Editor gameObject generation and found it handy.
    Ahh nice. I've generally left that aspect of U3D alone.

    You suggested that UnityScript isn't less verbose, I provided some "Stupid examples" that show some cases in which it takes less characters to achieve same results in UnityScript.
    And as we've covered and agreed on, that's just a small aspect of the entire picture. BF can do somethings cleaner, clearer, more efficiently and less verbosely than any other language I know of. Still not going to use it as anything more than a mental exercise.

    I just try to make "less slow code", as I understand it. The c++ core does the job, I script the game logic and I try not to script in a way that slows things down even more. Again, not at any cost, we are on the same boat on this ( I hope you know how to swim ).
    Don't worry, I'm a Certified Diver, First Aider and Bronze Medallion [Life Saver].

    Thanks for taking the trouble to explain all those c# advanced features, it is really appreciated. I am not saying "Do not use it, 'cause it is slow", I am just pointing out that they have a cost that one should consider as another factor aside the flexibility they provide.
    Exactly - what you need to do is learn what those costs are.

    Get VS C# Express. Learn to make console applications.

    Benchmark and test.

    Get C# in depth and use google + stack overflow to learn more about the features available and how they are used.

    On occasion, post your ramblings to paste-bin http://pastebin.com/u/NPSF3000


  5. Posts
    74
    I agree that C# has many advantages over UnityScript, but lets not forget that UniytScript does have one important advantage that C# will never have: Rodrigo Barreto de Oliveira .

    Rodrigo works for Unity and is also the creator of UnityScript's mother language Boo. UnityScript already saw important improvements in 3.x which included several missing features from C# while still keeping UnityScript's unique advantages. If you look at Boo you will also see that it already supports some of the C# features that are missing in UnityScript. For example, ref parameter support and creating (not just consuming) generics.

    Boo also has one extremely powerful feature that is not availble in C# or UnityScript, syntactic macros (not to be confused with C/C++ style preprocessor macros). Adding syntactic macros to UnityScript would allow you to write UnityScript code that runs at compile time (no runtime costs) that makes changes to your code before it runs. While I recall reading aboout Anders Hejlsberg considering adding syntactic macros to C# years ago it may never get them while Boo already has them and the potential for UnityScript to see them in the future seems much greater.

    That isn't to say that C# doesn't have its own special advantages like its mainstream status and support from Microsoft. But I believe with Rodrigo working at Unity, UnityScript and Boo have a bright future.

    Today pragmatically speaking I would start most new Unity projects in C#, but that could change in the future.


  6. Location
    Phoenix, AZ
    Posts
    1,251
    Quote Originally Posted by snoopbaron View Post
    I agree that C# has many advantages over UnityScript, but lets not forget that UniytScript does have one important advantage that C# will never have: Rodrigo Barreto de Oliveira .
    This is an excellent point, and something people usually overlook in advanced technical discussions about Unity: You can use Boo to extend the compiler toolchain. Check out Rodrigo's talk from Unite 2010: http://unity3d.com/support/resources...ng-and-plugins
    Matthew Wegner
    Current Project: Aztez
    Elsewhere:
    Founder, Flashbang Studios
    Partner, Indie Fund
    Editor, Fun-Motion
    Co-Chair, IGF


  7. Location
    Gold Coast, Australia
    Posts
    3,594
    Quote Originally Posted by snoopbaron View Post
    I agree that C# has many advantages over UnityScript, but lets not forget that UniytScript does have one important advantage that C# will never have: Rodrigo Barreto de Oliveira .
    Until he decides to have an epiphany and release the language specs, I'll still be a skeptic. FWIW all those features could all ready be implemented - we are just waiting for monkey to hit the right keys and take notice :P

    Quote Originally Posted by Matthew View Post
    Check out Rodrigo's talk from Unite 2010: http://unity3d.com/support/resources...ng-and-plugins
    Very nice. I could certainly use some of those features...


  8. Posts
    126
    Quote Originally Posted by NPSF3000 View Post
    Until he decides to have an epiphany and release the language specs, I'll still be a skeptic. FWIW all those features could all ready be implemented - we are just waiting for monkey to hit the right keys and take notice :P
    Boo and UnityScript are both open source, so you can see for yourself if they are implemented: https://github.com/bamboo
    I agree that a formal language spec would be nice rather than interpreting source code, but it is nice to have the source when you have questions.


  9. Location
    Phoenix, AZ
    Posts
    1,251
    Quote Originally Posted by NPSF3000 View Post
    Very nice. I could certainly use some of those features...
    As far as I know you can manipulate the entire compilation process with Boo (ie, Boo scripts could manipulate compilation of your C# stuff)...
    Matthew Wegner
    Current Project: Aztez
    Elsewhere:
    Founder, Flashbang Studios
    Partner, Indie Fund
    Editor, Fun-Motion
    Co-Chair, IGF


  10. Location
    PA, US
    Posts
    1,134
    I don't see a big deal, As a current Javascript(Web) programmer its not all that different than Web Js Yeah granted there are differences and it probably should be named Unityscript, but its not, atleast not at the moment. So no need to make it a big deal...

    Oh and a side note I program in C# but if i cant figure out how to do something in C# i try it in UnityScript and since i have a background in Javascript(Web) I usually figure it out and port it to C# so knowing Js is not a real set back not atleast in my mind...
    Last edited by KingCharizard; 02-13-2012 at 03:11 PM.

    Now I do not have skype I dont like Skype but I had to break down and start using it


  11. Location
    Seattle, WA
    Posts
    1,124
    Sorry to bump this but I've been reading some object oriented javascript books unrelated to unity and guess what?????? I see "use strict" cited as why unityscript is different from JS, but strict mode has nothing to do with Unity, it's part of ECMA5, which most modern browsers support natively, and it IS USED outside of unity for javascript based applications.

    Also javascript is classless but it can be used just like any OO language, go buy 2 books called "Javascript design patterns" + "pro javascript design patterns", they're amazing....


  12. Location
    Pennsylvania
    Posts
    2,954
    Quote Originally Posted by lmbarns View Post
    I see "use strict" cited as why unityscript is different from JS.
    Well it's actually "#pragma strict" in Unity, and has been around since before ECMA5. Regardless, there are way more significant differences than that between UnityScript and web JavaScript.


  13. Location
    Ryazan, Russia
    Posts
    781
    Quote Originally Posted by squidbot View Post
    The #1 reason I like JavityScript:

    In C#
    Code:  
    1. delegate int AnonFunIntInt(int i);
    2. delegate string AnonFunStrStr(string s);
    3.  
    4. void test()
    5. {
    6.   AnonFunIntInt mult = (x) => (x * x);
    7.   AnonFunStrStr addStr = (y) => (y + y);
    8. }

    In JavityScript
    Code:  
    1. function test()
    2. {
    3.   var mult = function(x : int) {return x * x;};
    4.   var addStr = function(s : String) {return s + s;};
    5. }

    Multiply by however many different callback types you have.
    Code:  
    1. void test()
    2. {
    3.     var mult = new Func<int, int>(x => x * x);
    4.     var addStr = new Func<string, string>(y => y + y);
    5. }

    Code:  
    1. var isZero = new Predicate<int>(x => x == 0);
    2. var print = new Action<object>(Debug.Log);
    3.  
    4. print(isZero(10));


  14. Location
    Gold Coast, Australia
    Posts
    3,594
    @ Alex - good to see someone else notice the issue with that argument - though me and squidbot have already slaughtered a few villages in our 'debate' :P

    After much though the best I came up with is this:

    Code:  
    1. var mult = function(x : int) {return x * x;};
    2. var addStr = function(s : String) {return s + s;};
    3.  
    4. var mult = function((int x) => { return x * x; });
    5. var addStr = function((string s) => { return s + s; });
    6.  
    7. var mult = function((int x) => x * x);
    8. var addStr = function((string s) => s + s);

    That's right, 'implicit' typing of lambda :P

    Best bit is that once you understand how it works you get the best of both worlds. The ability to create specific delegate types should the API's you call need them, but also a simple generic system that will work in 95%+ of cases. Much like the var itself - works most of the time but you can explicitly type should you desire.


  15. Posts
    14
    As a new guy to the forums, and someone with limited exposure to C# and UnityScript, I started out with UnityScript.

    Since then, when I have had to ask around for additional help, all the code i was provided was in C# (the guy who i ask is a C# guy), i found that i wrote better code without all the shortcuts that UnityScript provides.

    Now this might be due to me just starting out, and needing the extra structure it provides, but have moved to C# and am much better off for it.
    Illiteratereviews.com Tech & Game reviews, with a will-full disregard for grammar.
    Illiterategames Follow my (mis)adventures, as I attempt to develop an indie PC game.


  16. Posts
    886
    Everyone should just switch to Boo.

    Why?

    Because it has the coolest name.
    Animators create LIFE.

    Talk about games... or anything, at http://www.gamertype.com


  17. Location
    Australia
    Posts
    1,331
    I'm going to put my horridly uneducated opinion in here and say :

    This:
    Code:  
    1. yield WaitForSeconds(1);

    Is why I use UnityScript.

    !$#$ing IEnumerator my bum. (enlighten me to other options for the love of shinji)
    $2 for a fast and simple character solution for speedy prototyping!
    http://forum.unity3d.com/threads/119...52#post799952"

    $2 for 22 damage sounds, you can't go wrong!
    http://forum.unity3d.com/threads/114...mage-Sounds!-2!


  18. Location
    Gold Coast, Australia
    Posts
    3,594
    Quote Originally Posted by Alec View Post
    I'm going to put my horridly uneducated opinion in here and say :

    This:
    Code:  
    1. yield WaitForSeconds(1);

    Is why I use UnityScript.

    !$#$ing IEnumerator my bum. (enlighten me to other options for the love of shinji)
    If the biggest problem you face in code is changing void to IEnumerator you've not got any problems worth talking about :P


  19. Location
    Australia
    Posts
    1,331
    It makes me feel lethargic, but alas, I am but a whinging man.
    $2 for a fast and simple character solution for speedy prototyping!
    http://forum.unity3d.com/threads/119...52#post799952"

    $2 for 22 damage sounds, you can't go wrong!
    http://forum.unity3d.com/threads/114...mage-Sounds!-2!


  20. Location
    Montreal, Canada
    Posts
    1,436
    Once you realize that you can make your own IEnumerator types, it becomes much more interesting, not so much integrating into Unity's Coroutine system, but to make your own, or create complex collections or buffered utilities.

    Also realizing that yield is a type of return value can help in understanding what it is you are doing with that code. Always good for people learning to code. adding 'return new' to the yield and 'IEnumerator' to the function definition makes sure that what you write maps better to what it is that's created.

    I like concise typing, but I think that hidden functionality and logic, and implied conversions are only going to hurt the beginner, and obscure advanced functionality.

Page 8 of 9 FirstFirst ... 6789 LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •