Presumably working with this kind of always-on environment places very strict limitations on your code?

Thinking about games I've worked on, there's usually a substantial warm-up phase at the start in which all sorts of data structures are initialised and files loaded in from storage etc. If a hot swapped script changed anything, all the live data would somehow need to be ported over to the new version of each changed script. Reloading from storage wouldn't be an option, because that's not really a hot swap (and the data might have changed). But in general moving the data across isn't just a copy, because the old data might not be in the right format for the new script.

The lighting in the scene is a big feature and I like what you've done with it. Your shadows are maybe a bit off, though, so it might be worth tweaking some of them a bit. In particular, it's worth thinking about how the shape of an object affects the shape of shadows falling across it. For example, the woman with the pink necklace has a shadow across part of her face. This shadow passes across her forehead, eyebrow, eye socket and cheekbone as a straight line on the picture. This looks odd to the reader, because we know what contours those facial features should have and the light wouldn't look that way.

A half-shadowed face would look more like: this. Of course you don't need to be anything like that precise with a cartoon style, but having roughly the right shadow patterns helps things to look convincing.

Interesting result! 

Being a natural skeptic I had to test this for myself. And indeed btata is correct. On my machine there is a performance saving of about 30%.

Here is the code I used, in case anyone spots a flaw in my test setup or wants to experiment:

Code:

using UnityEngine;
using System.Diagnostics;

public class TestJIT : MonoBehaviour {

 // This is a test to verify an inefficiency in Unity's built in Vector multiplication
 // Original observation and optimised code by btata on the TIGSource forums

 // To use this test, create an empty scene, add an empty game object, add this script to it, then run.
 // The results appear in the Console panel.

 // These three public variables can be adjusted in the inspector with the code running to test the behaviour
 // of the different implementations. If you see very low timing numbers, increase the number of cycles. To test
 // the efficiency of avoiding a constructor call, set useConstructor to false. To test Unity's built-in
 // implementation, set noCall to true.

 public int cyclesPerFrame = 1000000;
 public bool useConstructor = true;
 public bool noCall = false;

 public void Update() {
  if (noCall) {
   // The Unity built in implementation always uses a constructor
   useConstructor = true;
  }
  Stopwatch sw = Stopwatch.StartNew();
  Vector3 v = new Vector3(-1,0.1f,100);
  float s0 = 0.5f;
  float s1 = 2.0f;
  if (useConstructor) {
   for (int i=0; i<cyclesPerFrame; i++) {
    if (noCall) {
     v *= s0;
     v *= s1;
    } else {
     v = multiplyWithConstructor(v,s0);
     v = multiplyWithConstructor(v,s1);
    }
   }
  } else {
   for (int i=0; i<cyclesPerFrame; i++) {
    v = multiplyWithoutConstructor(v,s0);
    v = multiplyWithoutConstructor(v,s1);
   }
  }
  UnityEngine.Debug.Log("Time taken: " + sw.ElapsedMilliseconds + " ms");
 }

 private Vector3 multiplyWithConstructor(Vector3 a,float d) {
  return new Vector3(a.x * d, a.y * d, a.z * d);
 }

 private Vector3 multiplyWithoutConstructor(Vector3 a,float d) {
  Vector3 result;
  result.x = a.x * d;
  result.y = a.y * d;
  result.z = a.z * d;
  return result;
 }

}

To keep it simple, the optimized version avoids calling the constructor.

So, as per my original comment above, is this not in fact a change of functionality? I assume it works in your specific use case, but in general multiplying a Vector3 by a float might need a new instance in order to avoid side effects. Or am I hopelessly confused about something?

Reminds me (and I bet bateleur, too), of the bad old days of Flash development.

<clutches whiskey bottle> <mutters darkly>

Hang on a minute, though... Unity's Vector3 is a value type, so won't it cause problems if you change the implementation that way? For example...

Code:

function multiplySomeVectors(Vector3 v, SomeClass someObject) {
 someObject.setVectorValue(v * 2.0f);
 someObject.setOtherVectorValue(v * 3.0f);
}

If the implementation of * does not create a new Vector3, won't the call to setOtherVectorValue get passed the wrong value? (Specifically 6x rather than 3x the input value passed to multiplySomeVectors.)

Now I'm just checking if the fragment is within the radius of the sphere instead.

You also seem to be doing something slightly cleverer to get the white faces where the sphere cuts a "blue" object in the foreground or a red one in the background? Part of it is just rendering as white any fragment very close to the radius, but how do you get white pixels in places where there isn't a triangle at all? Or do all the meshes have double-sided geometry with a different material on the inside?

Aha, thanks. So basically just AssetDatabase.LoadAssetAtPath() - that's nice and easy! 

For a project I'm working on I have a custom EditorWindow I use for various things. One of the things I now want to do with it requires a Material. The Material already exists, but it's not clear to me how to get a reference to it from the EditorWindow script.

If this were runtime code I'd either have a reference from an object in the scene or use Resources.Load, but neither of these is OK in this case. I can't reference from the scene since this EditorWindow is a debugging tool which needs to work with any scene. I can't use Resources.Load, because that would cause the Material to be added to the runtime resource bundle, which is wrong.

What's the best way to do this? Failing that, what's the least horrible hack that will work?

Prepare to have your mind blown by this article.

https://twitter.com/dolphin_emu/status/891570452291649539

Sort of the reverse, actually, because I know too many perfectionist software geeks. Right from the start of the article I guessed what they were going to do and was thinking: No! Don't do that! Async is fine! That solution is completely overkill... but of course they did it.

He wants to measure in pixels per frame though, not per second.

True, but sometimes in order to really answer a question correctly you have to step back from it a bit.

Specifically: movement is not a thing one would normally process per frame. A frame is a video display concept and simulation has nothing to do with that since it's not 1995 anymore.

So yes, absolutely do all motion processing in FixedUpdate where possible. If there's some good technical reason for doing it in Update() then something like this might work:

Code:

unprocessedTime += Time.deltaTime;
 while (unprocessedTime > my_cycle_duration) {
  unprocessedTime -= my_cycle_duration;
  processOneCycle();
 }

Filled in.

For future polls, use more checkboxes and fewer radiobuttons - a number of these questions had radiobuttons for answers which were not mutually exclusive.

A quick aside... if all you want to do is call a thing after a delay, you can use the Invoke method on MonoBehaviour.

PlayerPrefs are too easy to hack to get "free skins".

Was assuming the OP meant in game currency.

If it's real money then PlayerPrefs is no good for an even more important reason: if the registry entry gets cleared for whatever reason that wipes the skins!

As an aside, if you were to have stuff loading and unloading with a granularity as fine as seen in that GIF it would cause you some really horrible problems. Unity, like many garbage collected environments, can suffer from uneven performance if you thrash the garbage collector. As such you don't want to be doing frequent allocations of any kind during gameplay.

The video you've linked is about following exactly this principle: not doing things during gameplay.

qMopey's solution is mostly good, but does suffer from a problem which the original code also suffers from: dot product with the desired direction will give you the same result for both left and right angular deviation and consequently doesn't do what you want.

There are various solutions to this, but the simplest one is probably to dot product your local transform.right with the desired direction. Positive results then mean right turns and negative results mean left turns and the method works.

(I'm assuming this is Unity, but if not: transform.right is the vector 90 degrees clockwise from your facing.)

I think that maybe some people are just naturally better and pick it up quicker. However, I think for the most people can overcome the barrier with the right environment and teaching.

Your case study demonstrates the value of environment and teaching, but not that they are sufficient. My experience has been that where "nature vs nurture" questions arise, the answer is almost always "both".

The one problem with making programming easier, which is the way we are currently going about this problem, is that the way we are doing it is by hiding and never mentioning some of the low level aspects. (...) Python is the go to language in education for a while, it's one of the easiest languages to write and understand but we still haven't seen an increase in pass rates

Low level issues and teaching people to program aren't really the same thing. Python is a good tutorial language precisely because it lets you get straight to the programming without too much fussing over issues which aren't intrinsic to the activity.

I contend that once someone can program confidently, it doesn't much matter what language they work in. The problem is that it's a long, difficult process to get to that point.

The first thing I see or hear on most beginner programming courses/tutorials is "Programming is difficult/not easy". If someone lacks self confidence, this warning could cause them to not try very hard as they already believe they will fail. In the end is it really necessary that we point out that programming is difficult? We could just say that programming is a skill that requires hard work to master.

This is more teaching theory than programming, so I'll leave it to the professionals! There's a fine line to tread there between not putting people off and misrepresenting their chances. (And of course different students start at different confidence levels.)

Interesting research, thanks for posting.

My guess would be that the reason for the high dropout rate is because - like maths - programming is a skill which you can't necessarily acquire just by putting in the hours. Sure, it helps, but at the end of the day some students will just hit a wall.

If we want more programmers, maybe we should try to adopt Grace Hopper's approach and make programming easier?

[Non-Modular]

This being the grumpy old programmer room, though, I have to say that you're doomed whether you go for modularity or not.

Non-Modular: You can never change anything because every class in your 200 class project depends on everything else, from public variables to undocumented timing quirks.

Modular: Everything's perfectly independent of everything else, but you have 3000 classes and one of them's called AbstractCollectionCallbackUICache and you don't even remember what it does. Also, you can't so much as print "Hello, World!" without setting up a coroutine and passing in 17 parameters.

It's for an icon rendering system to spit out little renders of meshes.

Unless there are literally thousands, I'd give them a camera each.

The reason is performance. A thousand cameras doesn't actually take a ridiculous amount of memory, but moving one camera a thousand times involves changing its transform each time and that's actually a fairly expensive operation (because Unity does a lot of automatic work behind the scenes every time you do it).