for (int i = 0; i < some.Length; i++) {
    // Code
}

If you know that the length of whatever you're iterating is going to be less than 256 (0-255) you can use byte instead of int, if you aren't completely certain, you can probably get away with ushort (0-65,535). This will free up 24 and 16 bits as compared to int respectively, it's not much, but it can add up. You can also pre-lock the length into a variable to help speed things up. The reason this works is because for loop check their condition (second block) every single iteration. This means that you are accessing the length property every single iteration. Accessing a member of a class is more expensive than accessing a single variable, and thus adds up over many iterations. The performance change might be slight, but it adds up pretty quickly, especially if you are iterating through hundreds of pieces of data every single frame. So, what should the for loop look like? Well, like this:

byte length = some.Length;
for (byte i = 0; i < length; i++) {
    // Code
}

The Standard Equations

$$\Large{\begin{align*}x\prime\ &=\ x\ +\ tv\cos\theta\\y\prime\ &=\ y\ +\ tv\sin\theta\ -\ \frac{1}{2}gt^2\end{align*}}$$

Rearranging and Replacing

$$\Large{\begin{align*}x\prime\ -\ x\ &=\ tv\cos\theta\tag{x.1}\\d\ &=\ tv\cos\theta\label{x.2}\tag{x.2}\end{align*}}$$

$$\Large{\begin{align*}0\ &=\ y\ -\ y\prime\ +\ tv\sin\theta\ -\ \frac{1}{2}gt^2\tag{y.1}\\0\ &=\ h\ +\ tv\sin\theta\ -\ \frac{1}{2}gt^2\label{y2}\tag{y.2}\end{align*}}$$

To make things more obvious, we will replace the differences with a single variable, namely $\large{d\ =\ x\prime\ -\ x}$ (where $\large{d}$ is the intended travel distance), and $\large{h\ =\ y\ -\ y\prime}$ (where $\large{h}$ is how high the projectile starts relative to its ending height).

Eliminating $t\!\!\!\;$ ime

In order for this equation to work, time cannot be a factor. In truth, it really doesn't matter how long the projectile takes to get there, just that we arrive. If you need time later, just divide the range by the $\large{x}$ velocity component. Since the $\large{y}$ equation has a quadratic for time, we'll solve that one.

Using the condensed height equation in $\large{\eqref{y2}\!}$ , we can solve using the quadratic formula (and some basic negation cancellation).

$$\Large{\begin{align*}t\ =\ \frac{v\sin\theta\ \pm\ \sqrt{v^2\sin^2\theta\ +\ 2gh}}{g}\label{t}\tag{t}\end{align*}}$$

Since we know that what is coming out of the square root is positive, we can eliminate the possibility of a negative option as being the one we ultimately want. The projectile is supposed to be moving forwards after all.

The Heart of the Matter

Now that we have time eliminated from $\large{\eqref{t}\!}$ , we need to plug it in to the $\eqref{x.2}$ equation.

$$\Large{\begin{align}d\ &=\ \frac{v\cos\theta}{g}\left[v\sin\theta\ +\ \sqrt{v^2\sin^2\theta\ +\ 2gh}\right]\end{align}}$$

Then we need to solve that monster for $\large{v}$ . We start by moving $\large{g}$ over, and distributing $\large{v\cos\theta}$ .

$$\Large{\begin{align}dg\ =&\ v\cos\theta\left[v\sin\theta\ +\ \sqrt{v^2\sin^2\theta\ +\ 2gh}\right]\\\nonumber\\=&\ v^2\sin\theta\cos\theta\ +\ v\cos\theta\sqrt{v^2\sin^2\theta\ +\ 2gh}\\\nonumber\\=&\ v^2\sin\theta\cos\theta\ +\nonumber\\&\ \sqrt{v^4\sin^2\theta\cos^2\theta\ +\ 2ghv^2\cos^2\theta}\end{align}}$$

We then isolate the square root and square both sides to eliminate it, and consolidate common terms.

$$\Large{\begin{align}dg\ -\ &v^2\sin\theta\cos\theta\ =\ \nonumber\\\ &\ \sqrt{v^4\sin^2\theta\cos^2\theta\ +\ 2ghv^2\cos^2\theta}\\\nonumber\\d^2g^2\ -\ &2dgv^2\sin\theta\cos\theta\ +\ v^4\sin^2\theta\cos^2\theta\ =\nonumber\\&\ v^4\sin^2\theta\cos^2\theta\ +\ 2ghv^2\cos^2\theta\\\nonumber\\d^2g^2\ -\ &2dgv^2\sin\theta\cos\theta\ =\ 2ghv^2\cos^2\theta\\\nonumber\\d^2g^2\ =&\ \ 2ghv^2\cos^2\theta\ +\ 2dgv^2\sin\theta\cos\theta\end{align}}$$

We continue to eliminate like terms, extract the velocity component, and re-balance.

$$\Large{\begin{align}d^2g\ =&\ \ 2hv^2\cos^2\theta\ +\ 2dv^2\sin\theta\cos\theta\\\nonumber\\d^2g\ =&\ v^2\left(2h\cos^2\theta\ +\ 2d\cos\theta\sin\theta\right)\\\nonumber\\v^2\ =&\ \frac{d^2g}{2h\cos^2\theta\ +\ 2d\cos\theta\sin\theta}\end{align}}$$

Using trig identities we can simplify the equation, and keep like terms.

$$\Large{\begin{align}v^2\ =&\ \frac{d^2g}{2h\cos^2\theta\ +\ d\sin2\theta}\\\nonumber\\v^2\ =&\ \frac{d^2g}{h\cos2\theta\ +\ h\ +\ d\sin2\theta}\end{align}}$$

We're pretty much done here, just need to take the square root and integrate it into code. 

Solution

$$\Large{\begin{align}v\ =\ \sqrt{\frac{d^2g}{h\cos2\theta\ +\ h\ +\ d\sin2\theta}}\end{align}}$$

Where:

$$\Large{\begin{align*}g\ &=\ 9.81\ \text{(or whatever your gravity is)}\\h\ &=\ y\ -\ y\prime\\d\ &=\ x\prime\ -\ x\end{align*}\\\arctan(\tfrac{h}{d})\quad<\quad\theta\quad<\quad\frac{\pi}{2}}$$

Putting it into Code

Coding it is pretty straight forward, below is an example function that I wrote to handle doing the mathematics of finding the velocity.

// This function determines the required velocity to reach the range at the given height and angle
private float DoTheMath(float distance, float height, float doubAngle)
{
    // The lowest angle is a direct shot at an infinite velocity
    float lowestAngle = Mathf.Atan2(height, distance) * 2;
    
    // If the angle doesn't fall within the (lowestPossible, 90) range, there is no solution
    if (doubAngle >= Mathf.PI || doubAngle <= -lowestAngle) {
        return 0;
    }
    
    // I figured this equation out after working through the standard physics equations. See: http://wp.me/p35fKy-4k
    return Mathf.Sqrt((9.81f * distance * distance) / (height * Mathf.Cos(doubAngle) + height + distance * Mathf.Sin(doubAngle)));
}

Raycast Basics

What exactly is a raycast, how does it work, why is it so expensive? A raycast has an origin and a direction, like any vector, and is literally cast, or thrown if you will, into the scene. The process basically involves going through every object, then checking ever vertex, face, and edge, for an intersection. Even with rigorous optimization this can be checking against hundreds of elements, and this is what makes it computationally expensive.

How it's Used

While it is relatively expensive, it is exactly how the scene is rendered. On my desktop that means 1680 x 1050 = 1,764,000 raycasts per frame just to display what is going on. On my tablet it's 1920 x 1200 = 2,304,000 raycasts per frame and 960 x 540 = 518,400 for my phone. So while it is an expensive calculation, remember that it is happening half a million to two million times a frame just to render, so doing it another 30 or so times is no worse than a 6 x 5 grid of extra pixels.

• One finger tap = left mouse button
• Two finger tap = right mouse button
• Menu key =
  • Middle mouse
  • Windows key
• Home button = HOME key
• Back button = ESC key
• Power button = END key

Note:

After testing with my tablet, I could not confirm any other keys besides the back button. The menu key did not even show up.

Public Variables

In a earlier post I made mention of public variables, specifically in a class-based architecture. One of the dangers of public variables is that anything can change their value. When testing Napkin Western (working title) on a tablet, some of the variables were corrupted from the values set in the Inspector. The values changed from 6 and 15 to 2.435e-43 and 2.643e-45 respectively.

Solution

What's the solution? Simple, set the access to all your variables, functions, enums, etc. to exactly what they should be. Make only variables public that absolutely need to be. Then take advantage of the [HideInInspector] to keep certain public variables hidden, and [SerializeField] to show hidden or private variables. This way things won't get accidentally modified, and you will have access to all the pieces you need while retaining the proper level of access.

Problem

One place where this is particularly the case is shader debugging. This is the actual problem that prompted me to find such a solution. Being a Unity project for mobile devices, Napkin Western must be tested on its target platform, from time to time. In this particular instance, my nifty hand-crafted shader specifically took issue with the mobile device for no apparent reason. Since compiling for the platform takes a fair amount of time, and all I needed to do was make minor changes to find the issue, I had to come up with another solution.

Solution

The solution? Make 6 different versions of the shader; yes, 6. Each version had one thing to test within its code. That way I could independently verify each of 6 different components to see if any of them were the cause of the problem without having to compile the game 6 times. Then I loaded in some spheres and gave each one a different version of the shader.

Result

So, what ended up being the problem with my awesome custom toon/cel shader? Oddly enough, nothing you would expect. It ended up being the fact that I tried to condense my code by using a ternary instead of an expanded if/else statement. I never caught this because it worked fine during the standard visual tests yet, for some odd reason, when testing on the various available Android devices, it resulted in an all black shader effectively always evaluating the ternary to false.

What are objects?

In the real world each thing, or object, acts independently of everything else with no interconnected reliance. Objects can react to other objects, but do not necessarily depend on other objects. Note: there are objects which are entirely dependent on other objects, but we'll get to that. If you have just started programming you likely will have noticed that the program as a whole runs in a very linear fashion with events occurring in a very specific order. To get around this many programming languages have implemented a class based architecture. Even Objective-C has structs which function in a similar manner.

What is a class?

What is a class exactly? Succinctly, a class is whatever you want it to be. At its most basic level, a class is an object that you define yourself. What a class does is entirely up to you, but you will want to put some thought into constructing it to make sure it behaves as you intended. Classes allow you to group functions, variables, and even other classes into one contained object that does not interfere with other objects.

Interaction principles

Does not interfere? What if it needs to? Well, that's where access identifiers come in. They let you determine what can access the particular variable/function. There are three main access modifiers, and one that is less well known. The three main modifiers are (ordered by access level):

• Public
• Protected
• Private

The last modifier is internal, it is not very well known, and has limited to no use in smaller projects and therefore will only be covered briefly.

Public Access

First is the public access modifier. Public variables, functions, classes, etc. Can be accessed and modified by anything and everything. Some will say that one should never have public data, and others will say to use it with extreme caution. I fall in the latter camp personally. Ideally you only ever want to have a variable public if you want it to be modified by an external process, otherwise it is better to have it be a protected or private variable and then define a public function that allows the data to be read by other processes. To some this does seem much, but it all depends on your security needs, and whether or not you are the only one who will ever work on the project. A good rule of thumb is, "if you do not want it modified by just about anything, don't make it public." One exception is in Unity where a variable must be public in order to allow modification of said variable within the inspector tab(s).

Protected Access

Protected methods can be accessed by the class they are defined in, as well as any other class that is built on top of the class. This brings us to the topic of inheritance, which will be covered briefly before moving on to the private and internal definitions.

Inheritance

To better understand inheritance we need to look at a real world example. Chances are you know what a car is, what it does, and generally how to use one. Most cars function the same, but yet are very different. One main difference is Manual vs. Automatic transmission. Aside from that there are sports cars, luxury cars, commercial vehicles, and many many more. Yet these are all cars, and they all have many things in common: wheels, brakes, an engine, the need for gasoline, a battery, drive shaft, steering wheel, lights, horn, and on and on. To represent this in programming you would create a car class, then you would probably make several other classes based on these for the different vehicle types. To do this you would use the extends keyword followed the class which this class is to be based upon. This new class will have access to absolutely everything that its parent has access too, except private members. As mentioned above, protected members can be accessed only by a class and its sub-classes.

Private Accesss

This brings us to the last of the three main access modifiers: private. The private modifier lets the defined method only be accessed by the class itself, and absolutely nothing else, not even derived classes. Taking the real-world car example, the basic car class would probably define how the engine works to produce thrust, but any sub-class would simply access the accelerate function instead of directly modifying the various engine components required to make acceleration happen. Thus, opening the valves, controlling airflow, fuel injection, ignition sequence, and exhaust are private, and for good reason too. Imagine having to control all of that every single time you wanted one of the cars to accelerate, instead of just pushing a handy little pedal.

Internal Access

The internal modifier is not very well known because it limits access to the assembled package. This means that only this program, and no other program, can access the method. This can be handy if you are building a DLL file and want certain methods public within the DLL, but not available outside of its local program scope. Reading that definition may make you wonder why internal is needed at all since most everything is limited by its scope. The key thing here is classes. In particular you want a class accessible within a DLL for instantiation, but not available outside of it because the name it uses might clash with something else, or because it is a security concern. As aforementioned, this modifier is used very little in smaller projects.

Construction Tips

"That's all well and good," you might say, "but how do I actually use classes in my workflow?" There are a few things to keep in mind when constructing a class, and it can help to diagram out what is to do what well ahead of actually implementing anything. This will prevent you from having to come back and restructure the class an untold number of times.

Instantiation

Classes typically require a public function of the same name as the class which acts as the instantiation method. What this means is that when you define "ClassName obj = new ClassName(a, b, c);" the parameters listed by your favorite IDE are pulled from the function with the same name as the class you are creating, which in this case is ClassName. It is possible, at least in every language I have encountered besides Objective-C, to have multiple, or overloaded, functions with the class name. This will allow for different ways to create the object depending on the circumstances and the amount of information actually required.

Update

In many cases it is also beneficial to have at least one commonly named update function whose function name exists in all necessary classes to provide a simple means of running standard loop logic. That way in the main body of the program you could just iterate through all objects and call their update functions, if they exist.

Input

Likewise it is a good idea to come up with a naming convention for various types of input. Windows allows you to register a listener function for keyboard, mouse, and other input. Within the function it would be very easy to call the respective listener functions of everything in your program if they all had similarly named listener functions.

Final thoughts

Ultimately classes are the best way to have a modular system, and there are very few applications that could not benefit from such an approach. I strongly suggest reading more about classes and the OOP method for your respective programming language. It can only help.