Unity: Week 1

By Shamus Posted Friday May 26, 2017

Filed under: Programming 89 comments

Like I said last week, I’ve been dabbling in C# and Unity. Thanks so much to Riley Miller for suggesting these Unity Tutorials in the comments. These are exactly what I was looking for. They’re some of the best tutorials I’ve ever read, actually. They’re text-based, they have code you can copy & paste, they do visually interesting things so they’re fun to tinker with, they show all the steps you need, and they have little roll-out asides if you need some extra help. They begin with a simple base program and then modify it up to interesting levels of complexity rather than dumping four pages of inscrutable source on you and then trying to untangle it after the fact. Good stuff.

I’m afraid I haven’t learned enough to explain anything useful yet. But I know some of you are curious how it’s going, so here are a bunch of random “first impressions” type thoughts.

Unity Is Faster Than I Expected

Oooh! Shiny!
Oooh! Shiny!

One of the tutorials I did was this one, which is deliberately designed to tank your framerate. (The point of the exercise is actually to build a framerate counter.) The exercise has you create physics objects and have them smash into each other until your computer can’t keep up. You can see my version (pictured above) varies from the original, mostly because it was tremendous fun to play with. The project has a kind of sand-boxy appeal.

It was shocking how well the engine held up under unreasonable circumstances. I had a couple thousand objects in the scene at once. All of them were active physics objects. I actually had some code that kept applying force to them to “stir” them around the central sphere. This meant that none of them were ever at rest, but were constantly moving, sliding, and bumping every frame. Every object was able to cast shadows on any other object, from three different lights in the scene. The camera was aimed right at the center of the action so very few objects could be ignored during rendering. The thing ran like a champ, keeping the FPS above 100 until the object count hit 5k or so.

Yes, other game engines can do this. But I was getting this performance on a middle-range machine from interpreted code that hadn’t been optimized at allBecause, not knowing the pitfalls of Unity, I wouldn’t know how to do that yet.. I got this this wonderful simulation running with less than 100 lines of my own code.

MonoDevelop is Not Fun

Okay, this stuff all seems pretty cool, but... WHERE DO I TYPE MY CODE?
Okay, this stuff all seems pretty cool, but... WHERE DO I TYPE MY CODE?

The Unity workflow is strange. You spend a lot of time working in this editor (pictured above) with a 3D preview window. You can create game objects, construct hierarchies of game objects, set up your scene, position lights, build prefab objects, import models, and do all kinds of other cool stuff. The Unity editor can do everything… except edit code. Which is, you know, a pretty fundamental thing when developing software.

For coding, it invokes a whole separate application called MonoDevelop. And it’s awful. It’s sluggish to start. That wouldn’t be a big deal except for a problem I’ll get to in the next paragraph. The two programs aren’t very well integrated, so I can’t just use a hotkey to run the program from the code editor. (There’s a hotkey to “run” but it doesn’t do anything. I imagine it works as intended for non-Unity programs, but it isn’t able to invoke Unity properly.) So I have to keep alt-tabbing between the two programs to compile and run. I have to compile in MonoDevelop so I can see my errors while the code is in front of me, and then I alt-tab over to Unity and it stalls for a split second while it does an additional compile of its own. Then I can test my program. It makes for a lousy workflow.

Worse, MonoDevelop has a completely obnoxious bug where it will lose the ability to paste text into your code. This failure is absolute. You can’t paste with the hotkey, from the context menu, or from the main menu. Pasting text just stops working for no reason with no error message. This is really annoying when you’re doing a lot of tutorials with blocks of boilerplate code and long mixed-case variable names. Which, yeah. Guess what I’ve been doing all week?

On top of the copypasta bug, the code coloring sometimes gets totally confused and makes a mess of things. The code coloring in this image is way wrong.
On top of the copypasta bug, the code coloring sometimes gets totally confused and makes a mess of things. The code coloring in this image is way wrong.

That’s like a spreadsheet randomly losing the ability to add things. It’s so random and yet so fundamental to the use of the software I can’t believe the problem exists. The most common suggested remedy is to close MonoDevelop and re-start it. (And remember it’s sluggish to start.)

I don’t know when the bug first appeared, but it goes back to at least 2013. While searching for answers, I did find this:

Someone posted that the workaround was to (for some unfathomable reason) press CTRL LEFT ARROW then CTRL RIGHT ARROW, which would apparently make Mono Editor behave itself again. To which someone replied “WHY THE FCK IS THIS STILL NOT FIXED?!” That question was posted a year and a half ago.

I don’t know what’s happened to Mono Editor in the year and a half since then, but whatever they’ve done:

  1. This bug is STILL NOT FIXED.
  2. Ctrl+Arrow Keys thing no longer fixes the problem. (Assuming it ever did.) So you’re back to closing and re-opening the software.

Simply horrendous.

I think Unity really ought to have a built-in editor. Barring that, the external editor shouldn’t have bugs in basic features. Barring that, I’d like some assurance that flagrant, well-documented bugs might be addressed in less time than it takes to earn a bachelor’s degree.

What About Visual Studio?

I switched over to Visual Studio for editing my Unity C# code. I’ve said in the past that I’m a fan of VS, and I think it’s the only truly excellent thing Microsoft has ever made. So doing my Unity coding in VS makes a lot of sense.

Sadly, it’s awkward. Sometimes it works. Sometimes it doesn’t. For example if I try to use any of the editor-based classes – which is important for really getting the most out of Unity – the whole thing refuses to compile in VS and spews out linker errors. So I’d have to edit the code in VS and then have the Unity editor compile it. (And the way Unity reports compiler errors makes this kind of impractical anyway.)

To be clear, I’m not really blaming either Microsoft or Unity about this. I understand why this kind of thing happens. This is not the native Unity environment, and both Unity and Visual Studio change often enough that it’s hard to maintain the makeshift bridge between the two.

I’ve sunk an hour or so into trying to untangle these problems, but there are a lot of different pitfalls with similar-sounding error messages and honestly it’s really hard to know if a particular solution is for my particular problem, or if implementing it won’t simply create more problems.

This wouldn’t piss me off so much, except this is exactly the sort of stupid bullshit C# is supposed to solve. People have been telling me for years how nice it is to use C# because you don’t have to worry about linker nonsense or library compatibility problems because it Just Works™. And yet here we are. I’m barely a week into the language, I’m still working my way through the training wheels tutorials, and here I am reading obtuse compiler messages, searching forums for answers, fiddling with settings I barely understand, and generally spending time not writing code.

And yes, this is technically a problem with Unity and not C# itself, but the point is that the ages-old C++ problems remain. Using amazing and complex tools makes for amazing and complex integration problems.

In any case, the choice between Visual Studio and MonoDevelop comes down to figuring out which one is the lesser of two evils. I can use the development environment that becomes useless if you import the wrong packages, or the development environment that needs to be restarted every 20 minutes because it can’t paste. I think the VS problem is more debilitating, but the problem with MonoDevelop makes me more angry.

Despite All This, Unity is Pretty Fun

This program just flings random shapes at the sphere in the middle, where they slide or bounce off. Most fall into the abyss, but a few land on the little platform under the sphere. Click to see the tutorial this is based on.
This program just flings random shapes at the sphere in the middle, where they slide or bounce off. Most fall into the abyss, but a few land on the little platform under the sphere. Click to see the tutorial this is based on.

Development environment agonies aside, Unity is really fun to play around with. It’s really good at making programs where generic primitives can smash into each other using physics and lighting, without you needing to do any of the legwork associated with that sort of business.

It’s strange, because to a certain extent Unity makes very hard things very easy, but sometimes it makes easy things hard. On Wednesday I had three goals:

  1. Set up a first-person scene with realtime shadows.
  2. Add 3D sound.
  3. Make it possible to switch between walking around, and flying around.

The first two should have been a lot of work but were trivial, and the third should have been fairly easy but instead proved impossible at my current knowledge level. I gave up because it felt like I was still a few tutorials short of knowing how to implement this properly.

I could nitpick lots of little confusing moments like this, but what I’m going through is basically par in terms of learning a new language / game engine. This is a hard thing to do and there are always confusing moments and headaches when you’re climbing a learning curve.

So that’s my first week or so with C# and Unity.

I really wish someone would fix that bug in MonoDevelop.

EDIT: I have found a workaround for the copypasta problem in MonoDevelop: Right-click the tab at the top of your source file and from the dropdown menu copy the path to the file. That will un-jam the MD clipboard and allow you to paste again.

 

Footnotes:

[1] Because, not knowing the pitfalls of Unity, I wouldn’t know how to do that yet.



From The Archives:
 

89 thoughts on “Unity: Week 1

  1. Esp says:

    If you ever do learn how to fix that error, please post about it, because I’m having the same problem and it’s driving me crazy.

    Edit: Nevermind, I figured it out.

    1. thatSeniorGuy says:

      Now that’s just evil.

    2. Mousazz says:

      A special place in programmer hell for you, sir!

    3. Primogenitor says:

      See, this is a funny trolling – but real story, I once found a post like this on Stack Overflow for a problem I was having that I had written. Yes, I was trolled by my past self.

      1. TheJungerLudendorff says:

        That’s some programming karma if i’ve ever seen some.

    4. Canthros says:

      Who were you, DenverCoder9?

      What did you see?!

  2. Misamoto says:

    I’ve dabbled in Unity a couple of years back, and found that VS is so good that it’s simply impossible to go back to monodevelop later. Basically, VS ruined other IDEs for me. I also don’t remember there being any actual integration problems, everything worked together quite nicely. Are you maybe missing the integration plugin?

  3. Daemian Lucifer says:

    That question was posted a year and a half ago.

    Reading that image,its actually worse.The last comment was from the year and a half ago,but the ctrlarrowed response was from 2014.

    1. 4ier says:

      Just above the image, Shamus acknowledges that it goes back to at least 2013.
      Yes, the problem is more than a year and a half old, and that’s the point. Why is it STILL not fixed yet?

      1. TheJungerLudendorff says:

        Is there even anyone still developing it?

        I mean, i’d hope so considering how popular Unity is, but you never know.

  4. Joshua Fox says:

    I’m not sure what version of Visual Studio you’re using, but newer versions are far more friendly than the earlier versions used to be. In some cases a reinstallation of Visual Studio might be necessary if something got messed up behind the scenes (not Unity’s fault, it happens sometimes with VS). But after that, you should be good to go. I just built a new PC with fresh installs of everything, and Visual Studio was the default code editor in Unity, no fussing about necessary.

    1. Ryan says:

      …but newer versions are far more friendly than the earlier versions used to be.

      QFT. Anything before 2013 is kind of painful, period, and 2012 was particularly so.

      2013 is very usable since it has so many tools and add-ons developed for it. 2015 has some nice improvements, but not enough to justify switching (unless you were specifically needing newer versions of .Net not available in 2013), and even then 2017 is available now.

    2. Elemental Alchemist says:

      Too bad you don’t have access to the source code, eh?

      I still don’t understand why anyone that can actually code would be using Unity. It’s baby’s first game engine, and all its advantages are focused around that.

      1. goeuts says:

        What engine would you recommend for someone who can actually code?

      2. Piflik says:

        Can you actually code and talk from years of experience with different engines? While I agree that the barrier of entry is lower for Unity, compared to Unreal or (shudder) CryEngine, it has grown to be competitive with those engines. A good editor does not make an engine bad or for beginners. Unity has its limits (just like any engine), but these are unconnected to the user’s ability to code.

      3. Some nerd says:

        Last I checked, Monodevelop was open source.

  5. CMaster says:

    When I installed the latest version of Unity I worked with, it installed VS community edition, and auto-launched that from Unity (for editing C# assets). Older versions used monodevelop, but recent versions seemed to integrate straight to Unity.

  6. Daemian Lucifer says:

    Barring that, I'd like some assurance that flagrant, well-documented bugs might be addressed in less time than it takes to earn a bachelor's degree.

    They did address it.They fixed the bug that allowed you to fix the program without restarting it.What do you mean their goal was not to make the program more frustrating?

  7. PeteTimesSix says:

    I don’t think I could go back to MonoDevelop after using Visual Studio. Even if the IDE itself weren’t better and faster, the debugging integration between Unity and VS is almost flawless and I can’t work without my breakpoints anymore.

    I realize this is a bit of an “are you sure it’s plugged in” kind of question, but you did grab Unity VS tools, right?

    1. Shamus says:

      That link you posted? I’ve clicked on it from a few different sources, but when I get to the page it’s just ADVERTISES that a plugin EXISTS. I can’t find any download link.

      1. Daimbert says:

        I’m guessing that the download of Visual Studio gives you a version that works with Unity.

      2. Ivan says:

        I was going to suggest this also. Unfortunately, my source for that stuff is an Education Software portal setup by my Tafe, so I can’t point you to where I got it from. That link, yeah..

      3. Daemian Lucifer says:

        Theres this one tucked under marketplace,for some reason.

        1. Kyte says:

          That’s the visual studio extension marketplace, the place where you buy and or download visual studio extensions.

          Which VS tools for unity is.
          So yeah. You can also grab it by going to the tools menu and selecting manage extensions. (not the same as add-ons!)

      4. Bubble181 says:

        https://msdn.microsoft.com/en-us/library/dn940025.aspx seems to have the different versions of Tools for Unity depending on VS and Unity versions, though I don’t know if that’ll work for you?

      5. Binamrad says:

        On the linked page there is a “documentation” link under the “Download visual studio” button, if you follow it and then click on the “Getting started” link from that page, you are taken to a page that shows different versions of the plugin. Follow the link to the plugin you want, and there should be a download link on that page.

      6. Piflik says:

        Unity VS was integrated into Unity a while ago. The Plugin is no longer needed. All it ever really did was add the ability to ‘Attach’ VS to Unity, so you can debug properly. If you attach VS to Unity, you can add breakpoints which will be triggered when the game runs in the Editor. This feature is enabled automatically now, if you launch VS from Unity. All you need to do is check the “Editor Attaching” checkbox when setting up your external IDE in Unity.

        Edit: I think I misremember slightly…you DO need the Plugin for VS, but you don’t need an additional plugin for the Unity Editor anymore. So disregard the paragraph above…

        However, I recommend getting Resharper, if you want to seriously write C#. It also has an addon for Unity, so it doesn’t suggest using C# features that aren’t availible in Unity yet (Unity haven’t updated their compiler for quite a while…they want to finish their IL2CPP project first, which compiles into C++ before machine code…Unity is still using C# version 3.5). It is not free, though, unless you’re a student. They (Jetbrains) also have their own IDE in development (Ryder), which you can get a beta for. It might be useful for people, who aren’t completely absorbed into VS yet. Like Resharper it has superiour IntelliSense, which makes it mostly unecessary to read C# docs or to actually compile your code to find compiler errors. I am not sure if you can attach Ryder to Unity for debugging , though, since I haven’t used it very much (I am absorbed into VS)

        1. Tim Keating says:

          Or you can skip Resharper and go straight to using Project Rider, which IMHO kicks Visual Studio’s ass around the block.

          EDIT — ah wait, you said that. Oh well, here’s a link, to prove that I can still add value: https://www.jetbrains.com/rider/

  8. lethal_guitar says:

    But I was getting this performance on a middle-range machine from interpreted code

    Keep in mind that not all of Unity is implemented in C#. Also, C# is not purely interpreted: It has a JIT-compiler which will (at run-time) generate native machine code for often executed functions.

    1. Tim Keating says:

      Truth. Where performance gets challenging with Unity is if you have a large number of objects getting created and destroyed, as sometimes the GC will wake up and go “oh, ima nuke your framerate for a couple of seconds while I take care of this, kthxbye.”

  9. Andrew says:

    Echoing some of the other comments here:
    1) Which VS are you using? The new ‘community’ ones are free
    2) I assume you have Unity tools for VS installed? (I think it comes with Unity now)
    3) You don’t compile Unity code with VS (I mean you can, but it takes effort) you just alt-tab back to Unity and let it do it. (Yes it’s a strange workflow if your used to doing everything in VS).

    Also, in a slight defence of MonoDevelop the version included in Unity is really old, the new one is a lot better but doesn’t have the changes that make it work with Unity. I think they’ve pretty much abandoned updating it since MS decided to get friendly with them (they bought Unity VS, etc.)

    Kinda surprised about the perf thing, Unity is terrible at perf (though most of me experience is console stuff so, eh?)

    1. Piflik says:

      Unity is not terrible at performance, inexperienced developers, who think pasting some assets into Unity is the same as developing a game, are terrible at performance.

      1. Cuthalion says:

        Responding to, “Unity is terrible at performance,” with, “No, you’re a terrible developer,” is not productive.

        1. Tim Keating says:

          Yup. Every single developer who makes games now knew nothing at one point.

  10. Hollywood says:

    Have you looked into Unreal? It uses C++ instead of C#, and its default editor is Visual Studio, which does a hell of a good job. Intellisense picks up on everything, and you can compile and run from VS in most cases (need to use the Unreal editor’s compiler for some editor-integrated things). Plus its multithreaded by default, not like Unity which (last I looked) is still a pain in the ass to force to use more than one thread.

    1. Writiosity says:

      Doesn’t Unity also still use a max of two cores regardless?

    2. Amstrad says:

      Yeah, I was going to make my own comment about this, but honestly UE4 basically solves all of Shamus’s biggest gripes about Unity. Seems like the obvious choice to me.

      Also I am very biased considering all my goofing around with game dev has been in UE4 thanks to Blueprints allowing me to do so (I can’t program in a useful language).

    3. Matt Downie says:

      Given the right installation setup, Unity also integrates correctly with VS.

    4. Piflik says:

      It’s not really that bad. You can use threading code just as you would in native C# code. Unity is not thread safe, however, so you need to enforce that yourself, but that’s also the case if you code without Unity.

  11. Warclam says:

    This is a funny thing for me to read, because I do all my work in C# + Unity. Flipping back and forth between Visual Studio and Unity to code, then compile and run? That’s just normal to me.

    I use VS on my Windows box, but MonoDevelop on my Mac and I’ve never had it fail to paste like that. Weird.

  12. Daimbert says:

    For various reasons I’ve been puttering around with various development languages. So far, I’ve focused more on RAGS, HTML/JS (and might pick up React), and Python. From this, Unity might be an option that I’d look into because I’ve seen some amateur things done in Unity and they look pretty good (as well as Ren ‘Py).

    For me, though, the biggest issue is art assets. I have no ability to draw, but might want a wide variety of 2-D and 3-D character and object models. RAGS isn’t bad since you can use pictures, but for 3 -D artwork I’d want some option with some set models that’s easy to modify if I want to do something myself. Are there any options out there for things like that?

    1. modus0 says:

      The two cheapest options for 3d characters would be Poser and DAZ Studio.

      The base DAZ Studio program is free, and comes with a few figures, but some of the program add-ons, as well as new figure morphs, textures, clothes, poses, hair, props, etc., will cost.

      Poser isn’t free, but comes with a wider range of features than the base DAZ Studio does (and the cost of Studio add-ons to get similar functionality will end up near the cost of Poser). Poser is also fully compatible with the older DAZ3d products (just about anything pre-2009), and is sort of compatible with the recent content, using a DAZ3d-made importer.

      One major difference is that Poser doesn’t use a proprietary code format like DAZ Studio. All of Poser’s content files are saved in plain text format, allowing one to go in and easily fix issues in the files themselves.

      Both program’s current version have two render engines: Studio has the 3delight and NVIDIA I-Ray render engines, while Poser has Firefly and Superfly (a fork of Blender’s Cycles renderer). Both I-Ray and Superfly are Physically Based Render engines.

      As for learning the software, I believe all the DAZ Studio info and tutorials is primarily accessible at the DAZ3d site, or their Youtube page; while Poser has Renderosity and the Smith Micro Poser forum. Of course there are probably quite a few other locations where one can find information about how to use the two programs.

    2. Philadelphus says:

      If you want the absolute cheapest 3-D modeling program, Blender is a fully-featured modern modeling, rendering, texturing, lighting, animating, etc., etc., program available for the grand price of $0. One caveat is that Blender’s UI is a bit…quirky, and apparently different from other major 3-D modeling programs, so while it’s quite efficient when you learn it it can take some time to get up to speed (and your muscle memory may betray you if you’ve used other such programs, though I don’t know personally as I haven’t used any others myself).

    3. Daimbert says:

      Thanks. I’ll look into these.

      1. Tim Keating says:

        You might also consider Modo Indie, which is available through Steam. I switched to using that when I got fed up with the lack of progress on Blender’s UI.

        Edit: Not free (nor open source), but cheap, and has IMHO the best user interaction model of any 3D modeling software.

  13. Slava Tutushkin says:

    Hey, Shamus.
    Just try this one as IDE for C# and all you pain is gone:
    https://www.jetbrains.com/rider/

    Don’t forget to install https://github.com/JetBrains/Unity3dRider into the UnityEditor.

    Feel free to ping me if you have any problems with that thing :)

    1. Rob says:

      As much as I love JetBrains (they have my eternal loyalty for Kotlin alone), recommending an Early Access IDE – and one that will have a price tag attached once it’s properly released at that – probably isn’t the best idea. ;)

      1. Piflik says:

        I second this. JetBrains are great, and I probably couldn’t go back to a time before using Resharper, but Rider is not a replacement for VS (yet).

  14. No One says:

    A gotcha to keep an eye out for Shamus. Make sure you keep your Unity project code base in a compiling state as much as you can, and for goodness sake, DON’T shut Unity down when the code base is NOT in a compiling state. If you do and you’ve added editor features or custom build steps and such, they will NOT be available the next time you start up Unity until you fix the code (even though they were available in the editor session at the time the code was broken).

    So, avoid potential headaches, and always make sure your code compiles clean (or at least major error free) before you shut Unity down.

    1. Matt Downie says:

      Another Unity warning: it doesn’t normally autosave before you test your game, and if your code hits an infinite loop, the whole environment tends to lock up and any unsaved work you did in the editor is lost.

      1. Piflik says:

        That is my biggest gripe with the Unity Editor. There should be a way to stop the game, if it hits an infinite loop, without killing the Unity process. For example make the Editor and the game in th editor separate threads/processes.

  15. Paul Spooner says:

    One of the neat things about Unity is you can roll-out your “games” to a web-based player. Any chance you can upload your practice programs so we can play with them?

  16. Riley Miller says:

    I’m so happy to help!
    In my experience unity is easy to get into but has a lot of fiddly bs. Parts of it are mature, fully featured, and well documented. Other parts are…not.
    Happy coding! Love to see more programming content on the blog!

  17. Geoff says:

    Our Tech Artist uses and highly recommends Visual Studio Code for coding in Unity, its a Lite version of VS and includes Unity plugins and settings. Its also free.

    1. David says:

      I will second this … I pretty much exclusively use Visual Studio code for stuff at work now, it is a fantastic editor and it looks like it has unity integrations.

      Very lightweight/fast editor and the plugins give you the power of the sluggish IDE’s but without slowing things down.

  18. Kian says:

    How are you acclimating to C# a week in?

    From what contact I’ve had with it, the biggest difference with C++ seemed to be the special treatment classes get compared to other kind of variables. Whereas in C++ your user defined types can go on the stack or the heap at your discretion, C# puts your classes on the heap and handles everything through references and only “structs” and built in types can ever go on the stack.

    Never understood why people say “C# doesn’t have pointers” when it obviously does, it’s just that they’re in disguise (which I feel makes things more confusing, not less).

    1. 4th Dimension says:

      Actually C# supports ACTUAL pointers, since they need that to be able to call functions developed in C++. The only problem is while it supports WORKING with pointers, the support for allocating memory is dodgey and more problematically none of the inbuilt functions will accept pointers. So they are only used for the above, to be able to call functions and methods in unamanaged libraries.

      So what you do is make a wrapper function around it that allocates memory and converts to pointers if it needs to pass data to the function, and does in reverse (copy from pointer unmanaged memory into a managed array) for the output.

      But yeah, pointers are there, only their use is HIGHLY discouraged.

      1. Kian says:

        You’re mixing up two different things there: memory management and pointers. What you are describing is that manual memory management is possible in C#, but only in special circumstances. And yes, you need pointers to do it in C#. But in my own C++ code, I never use pointers for memory management (I use smart pointers, totally different thing!)

        A pointer is a variable that points to another object. You can make a pointer change what it is pointing at without altering the previously pointed thing.

        And in C#, all your class variables are basically pointers. They start as nulls, you “new” an object on them or assign to them, and if you assign a different object to them, you are effectively changing the pointer, not copying the contents of the second object onto the first object.

        1. Piflik says:

          No, 4th Dimension is correct. You can use actual pointers in C#. With * and all the pretty stuff you know from c++. All you need to do is wrap that section of your code in an ‘unsafe’ block. To use unsafe blocks in Unity is a bit more involved, but it really only requires to add a single file into your assets folder (add a textfile called ‘smcs.rsp’ and add the line -unsafe; this adds the unsafe parameter to the compiler options and allows you to use unsafe code). I once implemented a fast inverse square root, just for giggles, in Unity (never profiled it to see if it actually has a performance gain on modern CPUs). Never had the need to actually use actual pointers, though, but the option is there.

        2. Xeorm says:

          Pointers are variables that point to a spot in memory. In practice, they’re used primarily to point to objects, yes. It’s a mistake to treat them as only pointing to objects though, as they can be used for more. As an example, using pointer arithmetic to go through an array is perfectly valid in C++. You can’t do the same in C# because C# makes a big deal about memory management. It tries very hard to separate memory from the user.

          They’re similar, but not the same.

          1. Piflik says:

            As I said above, you can absolutely do that in C#, but only within an ‘unsafe’ block.

          2. Kian says:

            A valid pointer points to either an object, null, or ¨to “one past the end of an array.” Pointer arithmetic is only valid within the bounds of an array, and the result will point to an object (or to “one past the end”).

            You can’t portably point to arbitrary memory. Thinking that way about pointers is not supported by the standard and will eventually lead to hard to debug errors.

      2. Groboclown says:

        I think 4th Dimension’s comment was saying that pointers are in use in C#, but they’re disguised as object references. So that a simple assignment operation (a = b) assigns the variable a to the object pointed to by b, rather than making a copy of the object.

        That said, you’re right that, in unmanaged code blocks, C# also allows raw pointer access.

    2. Retsam says:

      Reminds me of this bit from The Night Watch (one of my favorite bits of programmer humor).

      Pointers are real. They're what the hardware understands. Somebody has to deal with them. You can't just place a LISP book on top of an x86 chip and hope that the hardware learns about lambda calculus by osmosis. Denying the existence of pointers is like living in ancient Greece and denying the existence of Krackens and then being confused about why none of your ships ever make it to Morocco, or Ur-Morocco, or whatever Morocco was called back then. Pointers are like Krackens””real, living things that must be dealt with so that polite society can exist.

      That being said, I’ve done both, and I’m much happier not having to manually manage pointers and such. “Pass objects by reference, pass primitives by value” just makes a lot of sense to me and I don’t really care to do things other ways. (You can think of it as “pass everything by reference, but primitives are immutable.”, even if it’s not literally true at the implementation level)

      Sure there are times when you can get optimizations by manual pointer management, but that doesn’t make it a style I want to actually use for day-to-day use.

      Saying “C# has pointers, they’re just in disguise”, is a bit like saying “C++ has Assembly JMP instructions, they’re just in disguise as loops”. It’s certainly true, but it doesn’t actually impact the usage of the language in a meaningful way.

      (And if you think that the above quote is a defense of C++, it goes on to compare a C++ source file to the Necronomicon “a wicked, obscure document that's filled with cryptic incantations and forbidden knowledge”)

      1. Kian says:

        That being said, I've done both, and I'm much happier not having to manually manage pointers and such.

        But you are manually managing pointers. Every time you need to check if a value is null, say when you need to distinguish between a null string and an empty string (something so common C# literally has the String.IsNullOrEmpty method), you are dealing with a pointer. They’re called “object references” in C#, but they serve the same purpose raw pointers do in C++, except for being less clear about it.

        Ok, they’re garbage collected pointers, but while that solves some issues, you can still create memory leaks with them. So you still need to keep track of who is holding on to what and how long. Same as with shared_ptr in C++.

        1. Retsam says:

          I don’t see how using references is “manually managing pointers” for any normal definition of those words, any more than a loop is “manually managing assembly JMP statements”. You don’t need to teach someone pointers before references, any more than you need to teach them assembly before you teach them a higher-level language, even if all languages are ultimately built on assembly.

          And I really don’t see how you think references are “less clear” than pointers. It just seems like you’re more familiar with pointers than references, and so they’re weird to you. Yes, I guess pointers more accurately model the underlying machine state, but arguably the whole point of high level languages is to be able to not have to think of the underlying machine state, as much as possible.

          1. Kian says:

            I don't see how using references is “manually managing pointers” for any normal definition of those words, any more than a loop is “manually managing assembly JMP statements”.

            Well, it would help if you explained what you think “manually managing pointers” means, but for my part, it means keeping track of if a pointer actually points to an object or is null (you can’t call instance methods on null pointers since there is no instance), or if two different pointers point to the same instance, so that a change through one pointer is visible through a different pointer you haven’t called any methods on (something to be wary of during swaps or assignments, for example).

            Replace every time I said pointer above with “object reference” and you find the situation is the same in C#.

            As for why I say they’re less clear, consider this stack overflow question and the selected answer: https://stackoverflow.com/questions/3507383/equalsitem-null-or-item-null

            There are actually several different methods you can call to compare object instances. Given two object instances a and b, you could write:

            Object.Equals(a,b)
            Object.ReferenceEquals(a,b)
            a.Equals(b)
            a == b
            These could all do different things!

            This is the result of trying to pretend that you don’t have pointers, you have no clear way to distinguish the thing pointed from the thing doing the pointing (the pointer).

            Compare the situation with C++’s pointers: if I have a pointer, I can only compare the pointer against another pointer, not against an instance of the object type the pointer points to. It also marks a clear distinction between identity (are these two things the same thing?) and equality (do these two things have the same value?).

            You determine identity by comparing addresses: two pointers to the same address point to the same thing. You determine equality by comparing the pointed things themselves in whatever way the things are determined to be compared (two strings have the same value if the text they hold is the same, even if they’re two different copies of the same string).

            You still want to know these things in C#, but as the stack overflow question shows, conflating the concepts of object and reference results in confusion when you want to disambiguate them.

            1. Retsam says:

              Yes, with references and pointers you have to deal with some of the same problems, like keeping track of whether they’re null or not. I don’t think that means that “references are the same as manually managing pointers” (why, by my definition means actually having language constructs for setting, changing, and dereferencing pointers), just that “references are an alternative to manually managing pointers, which have some of the same benefits and drawbacks”.

              Conveniently, though, modern languages are moving away from having null references in the first place. (The famous “billion dollar mistake”) C#, for example, highly recommends consistent use of the Nullable type, which encapsulates the “is this null?” logic into the data structure itself, making it a compile error to forget the null check.

              As for why I prefer references, passing everything by reference (and keeping your objects on the heap) means that I don’t have to define copy constructors, copy assignment constructors, move constructors, move assignment constructors, or destructors for any of my classes. All of those become unnecessary (and the first four are specifically unnecessary because everything is pass by reference).

              Sure, maybe if I want to distinguish between identity equality and value equality for objects, I’ve got to be careful. C#’s particular situation seems a bit nutty thanks to operator overloading, I spend more time in the JS world where equality is always an identity check for objects and a value check for primatives. If I need a “value equality” check for objects, I can implement that myself or use a utility, but I rarely find that necessary.

              1. Kian says:

                (why, by my definition means actually having language constructs for setting, changing, and dereferencing pointers)

                But C# has exactly that. You “set” it when you either new a variable or assign it another reference. You change it when you assign null or another reference to it, and you dereference when you call a method on the object through the reference. The only difference is you call it a reference instead of a pointer.

                Conveniently, though, modern languages are moving away from having null references in the first place.

                You mean modern languages are finally catching up to C++, which has had non-null references from the start? Just need to wait now for modern languages to decide that having your references be immutable (meaning you can’t reseat them to point to a different object after initializing them) is a good idea too, and they’ll be where C++ was 27 years ago :P

                As for why I prefer references, passing everything by reference (and keeping your objects on the heap) means that I don't have to define copy constructors, copy assignment constructors, move constructors, move assignment constructors, or destructors for any of my classes.

                Best practice since C++11 (6 years ago, so relatively recent) is not to do any of those for classes in C++ either, since you automatically inherit them from your data members. Only resource management classes, which are few, need to worry about those anymore, and most are included in the standard library.

                Kind of drifting away from my own point though now.

                1. Richard says:

                  In C++, references simply cannot be null, while pointers can.

                  To put it another way, if I have a reference in C++, it’s assumed to be a real object while pointers might not be.

                  So I guess that C# doesn’t have references at all – it only has “smart” pointers.

                  That’s one key difference.

                  The manual memory management of C++ means that the object itself might not exist even though there is a reference or the pointer is not null, which is a different matter that C# does try to fix.

    3. Kyte says:

      Classes are not handled special.
      Every single object in C# can be classified as one of two things: Value type or Reference type.
      This decides the kind of copy semantics your object will have.

      In a value type, aka a struct, your object has pass by value semantics, that is, it will live within the variable’s storage location and will be copied to new storage locations if needed (passing an argument to a function, for example). Since the data is a copy, changes don’t propagate back to the caller. Ints, floats and Vector3s are examples of value types.

      In a reference type, aka a class, your object will have pass by the reference semantics, aka a reference to the storage location with the data is passed. This lets functions mess with the caller’s variable contents. Strings are reference types. You can also pass value types by reference using the ref or out keyword.

      You’ll note there’s no mention of memory above. How and where the object lives depends entirely on the compiler and jitter. In the most common case, aka a desktop computer, the compiler will analyze the lifetime of the object, and decide if it’s long lived or short lived. If it can prove it’s short lived, aka it won’t be accessible once the function ends, it will assign the variable to the stack (or perhaps directly on a register!). Otherwise it will go to the heap. Structs can be proven via static analysis that they are short lived in most, but not all, cases. (counterexamples include variables captured in a closure). Classes are much harder to analyze, so the compiler opts for the safer option and assumes they are always long lived, hence they always go to the heap.

      Incidentally, this is why mutable structs are not a great idea. The changes don’t propagate which leads to easy to make bugs.

      Pointers exist but for the most part are an implementation detail.

      1. Kian says:

        Saying “stack” and “heap” was shorthand, but ok. It’s the part where C# distinguishes between reference and value types that I wanted to draw attention to. That’s what I mean by “special treatment”.

        Technically the C++ standard never speaks of stack and heap either, it only says that objects have a given lifetime, with automatic lifetime being inside a given scope and dynamic lifetime being from new until delete is called. The implementation could make automatic variables live in the heap if it wanted to.

        The point being, this is a decision you make in an object by object basis in C++, independently of whether it’s a class, struct or built-in. User defined types follow the same rules as built-ins, they don’t get special treatment.

        1. Kyte says:

          I still don’t see how it’s special treatment. It’s the same across the entire language, whether user defined or built in. Ints/floats/bools/bytes derive from the same System.ValueType as your structs, and you can still define semantics on an object by object basis by applying new/ref on ref/value types to get value/ref semantics. Obviously it’s more cumbersome but that’s because the design favors consistent use of semantics for the sake of correctness.
          From a C# point of view (and unlike Java) there is no difference between built-ins and user-defined objects.

  19. Ilseroth says:

    You were talking about having troubles with number 3, I’m sure you probably did find it, but the “Character Controller” component you can add to objects has a whole load of functions that make building a character ridiculously easy. It’s not perfect, but for quick dev it is super easy.

    Also thanks for finding that workaround to monodeveloper. Usually I am pasting from one code inside it to another, so it isn’t an issue; but I’m also completely acclimated to it so I don’t spend much time with other people’s code at this point, but still helpful when I gotta do it.

  20. krtk says:

    I fiddled around with Unity a couple of years ago, and I think I had a different copy-paste bug in MonoDevelop. Context menu worked fine, but for the hotkeys to work I had to hold down Shift or have Caps Lock on (naturally, not the best way to write code).

  21. sheer_falacy says:

    When you mention “long mixed-case variable names” as a problem, it makes me very concerned about that IDE. Because autocomplete is one of the most useful things an IDE can do for you, and it makes that mostly a non-issue. Visual Studio is fantastic at it.

    1. Cuthalion says:

      I think the issue here is that he’s not typing names of variables he’s already defined. He’s copying tutorial examples, and typing them out manually is slower than copy-pasting, especially when they’ve got boilerplate and long variable names. Of course, once he’s typed the name once, I would expect the IDE to autocomplete the next time, which might be what you were getting at.

  22. Philadelphus says:

    Oh man, not being able to (easily) copy-‘n’-paste is the worst. It’s one of those little niggles that makes me surprisingly irritable. It’s usually the fastest thing to annoy me whenever I have to use Windows these days and realize I no longer have access to my beloved middle-mouse-click auxiliary clipboard. (Or even software running natively on Linux that hasn’t yet picked up all the native tricks, *cough*Steam*cough*.)

    1. Cuthalion says:

      This is funny to me, because I can’t stand middle-click paste! I idly tap mouse buttons while I’m thinking or reading, and sudden, unexpected pastes are far worse than just pressing ctrl+v (or ctrl+shift+v) with my left hand. I was appalled when I looked into disabling it and found I’d have to fiddle with some Deep Settings beyond my novice comprehension.

      Instead of, you know, just clicking a toggle in the mouse settings. (Seriously, why can’t I?)

      1. Philadelphus says:

        I am sorry to hear of your plight, but that’s funny to me too, because back when I first encountered it at work I would have paid good money (like, $10″“$15) for a program for my personal computer that would give me the same functionality on Windows. But as far as I could tell at the time no such program existed (unlike the program that let you scroll whatever window your mouse was over), and it’s no coincidence that a few years later I switched to Linux at home…

        I guess it’s such a huge productivity booster that it never entered the heads of the programmers that anyone would ever want to disable it, but there should probably still be the option.

        1. Cuthalion says:

          Honestly, if I weren’t so twitchy, I’d probably like having middle-click paste. In any case, I’m glad you’re getting good use out of it! :D

          1. Philadelphus says:

            Yeah, too bad there doesn’t seem to be an easy way to disable it (without disabling all middle-mouse button functionality, I did a quick search on the subject). I guess just try to keep the cursor out of text entry fields? :D

            Thanks for being a sport, by the way, upon reflection I was a bit worried I’d come off as the kind of person who gives Linux a bad name.

            1. Cuthalion says:

              Not at all. :)

  23. C# must be pretty difficult code to learn. Your recent posts on coding have caused me to learn more about it, even though I still really suck at it.

  24. Fasteir says:

    Does Unity support swapping graphics APIs in case of wanting to test performance with DirectX 9/11/12 and OpenGL/Vulkan?

  25. Neko says:

    Aaaah ClearType my eyes

  26. Mender says:

    So how was week 2? :)

  27. Madwall says:

    Are you going to continue this series, or have you dropped it completely?

Thanks for joining the discussion. Be nice, don't post angry, and enjoy yourself. This is supposed to be fun. Your email address will not be published. Required fields are marked*

You can enclose spoilers in <strike> tags like so:
<strike>Darth Vader is Luke's father!</strike>

You can make things italics like this:
Can you imagine having Darth Vader as your <i>father</i>?

You can make things bold like this:
I'm <b>very</b> glad Darth Vader isn't my father.

You can make links like this:
I'm reading about <a href="http://en.wikipedia.org/wiki/Darth_Vader">Darth Vader</a> on Wikipedia!

You can quote someone like this:
Darth Vader said <blockquote>Luke, I am your father.</blockquote>

Leave a Reply

Your email address will not be published.