I refactor a lot when I'm coding unimportant things and very seldom for work stuff. The reason is simple: refactoring almost always makes your code better, but it almost never saves time.

Better to have a task queue per context.

You have to be a bit careful... if putting things onto the task queue is going to be done by many threads, then it too needs a lock of some kind (eg. a mutex). This being the case there is a deadlock risk if one thread has the queue lock and wants the OpenGL context lock at the same time as another thread has the context lock and wants the queue lock, you're doomed.

Luckily the fix is simple: don't allow anything to ever hold both locks at once. If you need to read the queue then copy the result somewhere and release the lock before starting work on the dequeued task.

(When this style of fix is inapplicable what you have to do is define a strict nesting order for your multiple locks, so that you always acquire A before B before C etc. That fortunately isn't applicable here.)

[Upsides]

Whilst there are many potential ways to do this I would urge you to seriously consider using Unity's built-in Component architecture (your option 1).

Upsides
* The entire language and system is designed to support this well.
* It's really easy to use.
* You can add property-specific data and methods effortlessly.
* Allows you to easily support multiples of the same property where appropriate.

Downsides
* A bit heavyweight (but this won't matter unless you're making thousands of objects with lots of properties each).
* Syntax can be slightly verbose at times.

If you really don't like that option, my second choice would be to add a single Component wrapping a Hashtable. Hashtable lookup is a bit slower than just checking a boolean, but this difference is unlikely to ever matter and it means you can get/set properties easily at runtime.

Without a maximum value the only thing you could do is an asymptote. For example:

y = 1 - e^-x

Seems like a good approach, but there are still two potential problems:

1) You need an asymptote at the low end too.
2) You'll get a lot of very similar values out depending on the real range of the numbers.

Problem 1) is relatively easy to avoid, for example by scaling the outputs for positive x into the range (0.5,1) and then mapping -f(-x) into the (0,0.5) range.

Problem 2) is, in general, impossible to solve without knowing something about the input values. However, if (say) 523 is known to be a typical input value then amending the function to something like y = 1 - e^-(x/1000) should give a slightly better spread of output values.

So, I have two Rigidbodies, rb1 and rb2. I need to do a few calculations and obviously mustn't mix the two up.

Today my code would have been on average more often correct if I'd flipped a coin for which one to use each time.

Hey, wait a sec... do you think I maybe might get it right more often if I gave them more descriptive names?

Is this what's this about?

Sort of. But the big drawback with an approach like J-Snake's halfFloat is that you can't just use it like an abstract number and hope it still has the properties you want.

For example: Suppose I multiply together two halfFloats with values A.B and C.D respectively. The result is NOT a halfFloat with value (A*C).(B*D) because you also get the cross-terms A*C and B*D... and these cause problems because you have to split them up and put the integer part in one internal field and the float part in the other internal field.

Why is this bad? Because now your exact integer parts are partly dependent on the (presumed inexact) float parts of the input values. So in particular, the not-subject-to-error property of halfFloats does not survive multiplication.

Now for some applications - presumably including whatever J-Snake is working on - that's fine and isn't a problem. But in the general case the problem of cumulative errors in float calculations is not addressed by halfFloats, which greatly limits their scope. In particular, by far the most common instance of this problem in modern gaming is physics simulation which involves a great deal of matrix multiplication.

In that case, your custom shader is right (negating x), but swapping the left and right images would be wrong (as that should introduce a mismatch).

Hmm... I see what you mean. This is what I get for testing it with the real textures and skybox rather than plugging in a set of test images.

Thanks for your help!

So did it have mismatched face edges at the seams? Or was the sky to the left reflected on the right of the object?

No, no mismatches. The sky on the left was reflected to the right. The problem is - as far as I can tell - that the cubemap support works exactly like a skybox so looking at your reflective object is exactly like looking through a little window at a skybox. Which is wrong, since there's no reflection.

Easy test: write some text on your skybox/cubemap. What we want it for it to be readable in the sky, but appear as mirror-writing in the reflection on the object. This is not what happens by default. (Unless I messed up somehow, which is entirely possible.)

My problem with the mechanism you're proposing is that I don't see why gamers would want to put money towards it. Greenlight is free for gamers to express support for a game. Kickstarter works like a preorder. But here you seem to be suggesting that gamers pay money but receive nothing in return.

OK, I've managed a (rather nasty) workaround. Swap the Left and Right images for the Cubemap, then use a custom shader like this:

Code:

Shader "Reflective/FlippedDiffuse" {
Properties {
_Color ("Main Color", Color) = (1,1,1,1)
_ReflectColor ("Reflection Color", Color) = (1,1,1,0.5)
_MainTex ("Base (RGB) RefStrength (A)", 2D) = "white" {}
_Cube ("Reflection Cubemap", Cube) = "_Skybox" { TexGen CubeReflect }
}
SubShader {
LOD 200
Tags { "RenderType"="Opaque" }

CGPROGRAM
#pragma surface surf Lambert

sampler2D _MainTex;
samplerCUBE _Cube;

fixed4 _Color;
fixed4 _ReflectColor;

struct Input {
float2 uv_MainTex;
float3 worldRefl;
};

void surf (Input IN, inout SurfaceOutput o) {
fixed4 tex = tex2D(_MainTex, IN.uv_MainTex);
fixed4 c = tex * _Color;
o.Albedo = c.rgb;

float3 wr = IN.worldRefl;
wr.x = -wr.x;

fixed4 reflcol = texCUBE (_Cube, wr);
reflcol *= tex.a;
o.Emission = reflcol.rgb * _ReflectColor.rgb;
o.Alpha = reflcol.a * _ReflectColor.a;
}
ENDCG
}

FallBack "Reflective/VertexLit"
}

This is one of those embarrassingly fundamental questions that seems somehow impossible to get an answer to via search...

I'm making a game in Unity. I have a Skybox. I have a Reflective-Diffuse shader. I have a Cubemap for use with that shader that uses the same image set as the Skybox. This must be standard, right?

And yet when I make an object with the corresponding material and look at the reflection in it, what I see is wrong. Instead of looking like a reflection of the bit of skybox that's behind me it looks like a non-reflected image of the bit of skybox that's behind me.

This isn't what I want, of course, but more to the point it seems like it can't possibly be what anybody wants! So, what do I do about this?

Things I've already tried:

* Writing my own shader, inverting the X and Z axes of IN.worldRefl. (This doesn't work because it shouldn't work, I just didn't think it through properly.)
* Leaving the Cubemap blank for the material and hoping it will autoconstruct one from the Skybox. (The shader code makes it look as though it will. Actually it doesn't.)
* Making big sad eyes at my monitor in the hope that it will fix itself.

Anyone got any better ideas? This problem must be completely standard, right? Either that or every single Cubemap in every Unity game has this problem and nobody has ever noticed. Or (horrifyingly) is everyone just X-flipping all their Skybox images, unnecessarily doubling the data storage space? (Pleeease let it not be that!)

I think I need to figure out a better way to check when images have loaded instead of a optional callback

The method I use (Flash, not Air, but should be the same) is to hook all possible events so that completion doesn't get missed:

Code:

loaderInfo.addEventListener(ProgressEvent.PROGRESS, updateProgress);
loaderInfo.addEventListener(Event.COMPLETE, loadComplete);
addEventListener(Event.ENTER_FRAME, loadingCycle);

This is, of course, a huge hack... but there isn't really any downside. The loadingCycle function (and updateProgress) both just call loadComplete when they notice loading is done, like this:

Code:

function loadingCycle(event:Event):void {
 var info:LoaderInfo = stage.loaderInfo;
 var frac:Number = info.bytesTotal / info.bytesLoaded;
 if (frac >= 1) {
  loadComplete(event);
 }
}

In my simple collision engine, I resolve collisions between AABB bodies by finding the shortest intersection vector, and adding that to the position of the AABB body. This works almost perfectly, unless the body gets stuck between two other static bodies.

If you want to handle this kind of thing perfectly, you need to write your whole collision system to be correctness-preserving. This is a MASSIVE complexity increase over what you're doing at the moment. Basically, every time something is about to move you need to compute all the consequences of that move (potentially involving all sorts of objects pushing each other in various directions) and then work out how much of the original move is possible (maybe none at all). With this kind of system, the situation above cannot arise in the first place.

A reasonable compromise solution, which is easier to write, is to use a multi-pass system. So in your example above, instead of pushing the block all the way outside the lefthand scenery, you push it by only one pixel. Then, in the same frame, you run collision tests again and so on, maybe 10 times or so. When pushes happen from both sides at once, average them and round down.

How come proprietary stuff is awesome in Chrome, but bad in IE? Hypocrites!

It's not awesome in Chrome. Unfortunately the entire history of the web is all about people using content types which weren't really a good idea. Anyone besides me old enough to remember the controversial Netscape extensions to HTML? In retrospect, they were a pretty good move. Also, sometimes horrible proprietary stuff has a happy ending - Flash went from being the worst thing ever to a pretty good games platform.

Here's an actual question that should illustrate the kind of things I am trying to learn. Most of the games I've ever worked on are state machine driven. You have different states, push/pop/transition between them, and the core logic for any given section of a game is controlled in its respective state. From what I've gathered thus far, Unity doesn't seem to use this set up. Which is fine, but my question is: do scenes in Unity effectively act as the logical state? And if that's the case, how is the best way to structure the core logic of the main "state" when you want to have multiple scenes loaded at once?

If you're trying to do something to a very short timescale you're going to have a hard time if you fight against the way Unity wants to do things. A scene is intended to be an encapsulation of a complete mode of the game. So, for example, the attract mode, the options screen, the hiscore table or (most often) a level. Don't put more than one scene on the screen at once. You can, but it's a lot of added complexity you don't have time for.

The main way to set up state machines and control logic generally in Unity is via scripts. Scripts must be added (as components) to GameObjects in order to run. Use the Awake() and Start() methods for setup and then Update() or FixedUpdate() for per-cycle processing. All scripts are objects. The source file for a script defines a class (in the usual object oriented sense). Add variables to the class to store whatever state you need.

You can add multiple scripts to the same GameObject if you like. Enabling and disabling different scripts can be a nice simple way to implement the effects of state transitions.

Ideally, objects should communicate by having variables which point to one another and using them to call methods on each other. However, for a quick-and-dirty way to hack together some communication on a tight deadline you can use static fields in your script class to communicate references to useful objects globally.