Make.bat for building stuff in windows command promt

This post is going to be about building stuff from Command Prompt in Windows. I really like Visual Studio now that I’ve gotten used to it, but this wasn’t the case always. Few years ago I really wanted to make a game with C and SDL2. I had some trouble setting up SDL2 for Visual Studio so I decided to just build it by hand. I was doing the development mainly with OS X and wanted just to test the build in Windows.

I was using Makefiles in OS X and figured that I’d install Make for windows. This turned out to be a chore and after a while I decided to continue without Make. Building the project in command prompt was easy enough while the project contained just few source files, but when the project got larger, building everything by hand became a chore.

So, I decided to dust off my rusty Batch skills and created a build script. Years later, at work, I decided to just test something out quickly and remembered that I once created a Batch-script for building C stuff in Windows. And that was what led me to write a post about the script.

The script has some limitations, but should be enough for simple projects.

I don’t remember anymore if I borrowed parts of this script somewhere, but it seems simple enough for being made by me.

Environment settings

The build script requires some environment settings to work, so in this first part I will walk you through them. We set the environment stuff in a separate script so that it can be used with other projects also. This script can be executed from the build script or you could run it when opening the Command Prompt.

@echo off
:: This BATCH file can be used with cmd.exe:
:: Create a new shortcut for cmd.exe with "/k <location_of>env.bat"
echo [NOTE] Running env.bat.. Setting up some really really important stuff!
set BENV=x86_amd64
echo [NOTE] Build environment is set to %BENV%
:: Comment USE_VIRTUAL_DRIVE if you don't want to use it
set USE_VIRTUAL_DRIVE=1

if defined USE_VIRTUAL_DRIVE (
    if exist "w:" (
        echo [NOTE] w:\ already initialized! 
        cd /D w:
    ) else (
        subst w: c:\work
        cd /D w:
    )
) else (
    echo [NOTE] Virtual Drive disabled
)

:: set SDL2 to PATH
set PATH=%PATH%;C:\work\SDL2\lib\x64\;
:: SSH PATH
set PATH=%PATH%;C:\CVS\OpenSSH-Win64;

:: CVS Path. 
set PATH=%PATH%;C:\CVS\;

:: Set RSH Thingie
set CVS_RSH=ssh

:: Initialize the Visual Studio environment (to get 'cl' and 'link')
set PATH=%PATH%;C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\
call vcvarsall %BENV%

:: Initialize GIT environment. Or don't..
set PATH=%PATH%;C:\Program Files\Git\bin;C:\Program Files\Git\cmd

:: Mark the development environment as set. Should be the last thing you do
set DEV_ENV_SET=1

Don’t mind the CVS or GIT if you don’t need them. This Batch-file sets the required environment variables and Visual Studio build environment settings.

It also ‘mounts’ the work directory to drive w:. It can be disabled by commenting out the setting of USE_VIRTUAL_DRIVE. 

The most important part in this is the call vcvarsall %BENV% which sets the build environment stuff. You can get the possible architecture choices with vcvarsall /help. For me the help outputs: x86_amd64, x86_arm store, x86_amd64 10.0.10240.0, x86_arm store 10.0.10240.0,  x64 8.1, x64 store 8.1.

In the final line we set the DEV_ENV_SET variable to 1. This value will be used by the build script to determine if environment settings were set.

Build script

Now that the required environment variable are set, we can use the build script. This a bit long, so I split the script into smaller chunks. The whole script and an example sources are in Github: batch_build (https://github.com/jkelanne/build_batch).

@echo off
if "%1" == "clean" goto clean

The first thing the script does, is to check if clean was given as an argument. If so, the script jumps to the line containing the clean-label (line 64) and deletes the build-directory.

:: Get the parent directory name. This will be used for the name of the executable
for %%a in ("%~dp0\.") do set "PARENT=%%~nxa"

If we’re not cleaning, the script will get the parent directory name which will be used as the name of the output executable later.

The for-loop will get the the files in  %~dp0\., which in this case will only be the parent directory where the script resides (because of the \.). The %~nxa will take only the filename and the extension of the of the output. The a in the rightmost part can be misleading, because a is also used for the file attribute when using %~-notation. But because it’s the last character in it, it is regarded as the variable a in the for loop.

if defined DEV_ENV_SET (
    echo [NOTE] development environment already initialized!
) else (
    if exist "..\env.bat" (
        call "..\env.bat"
    ) else (    
        echo No env.bat found!
    )
)

The script will then check that the env.bat was executed and the DEV_ENV_SET is defined. If the environment variable was not defined, it tries to execute the env.bat. I usually keep the file inside the parent directory.


:: The compilition process can be splitted into smaller chunks if needed
set BDIR=build
set ODIR=%BDIR%\obj
set IDIR=%BDIR%\include
set SRCDIR=src

:: If you need different include paths, set them here
set INCLUDES=

if not exist %BDIR% mkdir %BDIR%
if not exist %ODIR% mkdir %ODIR%
if not exist %IDIR% mkdir %IDIR%

After checking that the build environment is set, we define few directories. BDIR is the directory where compiler and linker outputs will be placed. ODIR stores the object files, and the script stores the project headers in IDIRSRCDIR is the source directory. Note: the script won’t work if you store source files in subdirectories under SRCDIR. I’ve been using it for small projects mainly.

The script then creates the directories if they don’t already exist.


:: copy incude files to %IDIR%
echo Copying includes..
for /r %SRCDIR%\ %%g in (*.h) do (
    copy %%g %cd%\%IDIR% >NUL
    echo   Copied %%g  %cd%%IDIR%
)

Next part of the script (lines 30-35) will copy the headers from the source directory to IDIR. I don’t remember what the point of this was, but there most likely was one.


:: Extra compiler options
set CFLAGS=/W4

:: Extra linker options
::set LDFLAGS=C:\work\SDL2\lib\x64\SDL2.lib C:\work\SDL2_image\lib\x64\SDL2_image.lib C:\work\SDL2_ttf\lib\x64\SDL2_ttf.lib
set LDFLAGS=

Up next are the compiler and linker flags. In this example we use only the /W4 argument, which enables the warning levels 1-4.

In this example we don’t use any externals libraries so LDFLAGS-variable can be left empty. In the comment above, we have an example for SDL2 libraries. Because we set the SDL2 library path to PATH in env.bat, we could use only the library names here.


echo Compiling..
:: We're compiling and linking in two steps. We could also run the cl with '/link /out:executable.exe' argument
:: For more information about the compiler opitons, see:
:: https://docs.microsoft.com/en-us/cpp/build/reference/compiler-options-listed-by-category?view=vs-2017
for /r src\ %%g in (*.c) do (
    echo   Compiled %%g
    if "%INCLUDES%" == "" (
        cl %CFLAGS% /Fo%cd%\%ODIR%\ /nologo /c %%g /D_WINDOWS
    ) else (
        cl %CFLAGS% /Fo%cd%\%ODIR%\ /c %%g /I %INCLUDES% /D_WINDOWS
    )
)
echo Done compiling...

Now that the variables are set, we can compile the sources. The cl-compiler doesn’t like if we have an empty set of includes after the ‘/I’ argument, so we need to check if include paths are set. Note: The if clause here isn’t totally safe and will probably break if there are quotation marks inside it.

The argument /Fo sets the object output directory. /nologo argument disables the the compiler logo. Because we’re compiling and linking separately, we have to use the /c argument when compiling. /I sets the include directories for the build. /D just passes a _WINDOWS definition to the C preprocessor. The /D is there for example only. I used it to determine how to handle operating system specific stuff.

echo Linking...
echo   Link directory: %cd%\%ODIR%\
link /nologo -debug %cd%\%ODIR%\*.obj %LDFLAGS% -out:%cd%\%BDIR%\%PARENT%.exe
goto done

After compiling comes linking. We use the same /nologo argument here to suppress the linker logo. Visual Studio C compiler and linker can both be used either with – or / argument prefixes. The outcome is same either way. The debug argument creates debugging information and I’m not sure if it’s even necessary here. The debugging information is stored in the program database file (PDB) and can be used with a debugger.

The next part in the linker command defines that we’re going to link against every obj-file inside the ODIR. After input files comes the libraries if we need any (LDFLAGS). And finally we set the output file to parent directory name.


:: If clean was given as an argument
:clean
echo Cleaning!
rmdir /s build
goto done

:done
echo Build done

The bottom part of the script contains two labels: clean and done. The ‘done’ label is just a way to skip the cleanin part if we’re not running ‘clean’.

Conclusion

This post turned out longer that was planning, but I felt that I had to explain some of the stuff in these scripts in more detail. The script has served me quite well, but it has it’s limitations. Batch-syntax is quite bad in my opinion and I don’t tend to use it much these days. I could have done this with python or some other language, but Batch comes installed in every windows.

The one thing I would improve, is the source file handling. At this point, the build works only if the sources are stored directly under the SRCDIR. I don’t plan using this in complicated projects, so there’s really no point. Don’t even know if I need this script anymore.

I was going to explain how to install the Visual Studio C/C++ compilers and linker without Visual Studio IDE, but apparently that is not possible anymore.

C# Attributes – Caller Information

As I started venturing into Unity3D and C# I found myself missing couple of useful preprocessor macros from C. The three macros I was missing the most were __FILE____LINE__ and __FUNCTION__. One could argue that those three are the closest thing to what one could call Reflections in C.

I didn’t know what the equivalent for those macros were or if there even was one in C#. Albeit, I was mainly doing thing inside Unity3D so this wasn’t even an issue. So I did some research on Reflections for the blog and eventually also on Attributes and I stumbled upon this thing called Caller Information.

Although Caller Information isn’t really the same thing as the macros mentioned earlier, I think it’s close enough. With Caller Information you can obtain information about the caller to a method.

Here’s a little example of how those preprocessor macros can be helpful.

printf("[%s:%s()::%d] Warning: Input string is empty\n", __FILE__, __FUNCTION__, __LINE__);
// Output:
//  [utils.c:rstrip()::256] Warning: Input string is empty

Right away you can see where the warning was generated, and if you need to react or even disable the message, you will locate it instantly.

As far as I know, C# doesn’t provide anything similar to this. So, we’re going to make something that produces similar outcome.

using System;
using System.Runtime.CompilerServices;

namespace Attributes_Caller_Information_01 {
    class Program {
        static void Debug(string value, 
            [CallerMemberName] string name = "",
            [CallerFilePath] string filePath = "",
            [CallerLineNumber] int lineNumber = 0) 
        {
            Console.WriteLine("[{0}:{1}()::{2}]\n\t" + value, filePath, name, lineNumber);
        }
        static void Main(string[] args) {
            Debug("Just a simple example");
        }
    }
}

// Output:
// [<pathname>\Program.cs:Main()::16]
//        Just a simple example

There might be a better way for handling this, but for this short post, I think this example is sufficient enough. The important bits here are the CallerMemberNameCallerFilePath and CallerLineNumber, which are part of the System.Runtime.CompilerServices. It’s required that what ever variable is defined after the attribute is defined with a default value. That’s all there is to it.

Unfortunately those attributes cannot be used when calling the method, so you can’t use them like this:

Console.WriteLine("{0}", [System.Runtime.CompilerServices.CallerFilePath]);

For more information about the the Caller Information, check the documentation.

Conclusions

The solution is quite ugly and I might return with a better implementation at some point. I would have liked to extend System.Console.WriteLine() and add Caller Information fields to that extension, but it seems that it’s either impossible or unnecessarily difficult.

Caller Information attributes can still be useful when debugging with a shotgun. Meaning that if you’re really not sure where the issue is within your code, you could insert dozens of Debug() messages and see how far the execution goes. Still, it’s a stupid idea. Using breakpoints and a real debugger would be much better option.

 

 

About writing

Throughout primary and secondary schools, I always had problems with languages. Not just Swedish but with English and Finnish too. The skills never seemed to stick. I’ve always liked reading, but the main issue was in producing sane language or sentences to paper. I struggled with this a lot. My language grades in primary and secondary schools were horrible. Still I’ve always yearned to be better at writing.

Nowadays my language skills have improved a lot; especially in English. The main reason is that I mostly read in English. There weren’t that many good sources for learning programming in Finnish and thus I was “forced” to improve my English skills. Video games, pen and paper RPGs, board games and Magic: The Gathering were also good way to get motivated to get better at English.

In 80’s and 90’s Finland was a good place for getting an ear for English mainly because there weren’t that many dubbed cartoons or movies. Stuff intended for preschool kids were usually dubbed, but after that it was either reading the subtitles or not watching. I’m not quite sure how the dubbing is handled nowadays, but I think the amount has increased.

I’m not going to say much about talking the language. Like most Finns, I’m really self-conscious about my horrible English pronunciation and am a bit scared of talking. Not every Finn is embarrassed about the pronunciation, for instance the couple who are doing the The Hydraulic Press -channel in Youtube. I find it really awesome that they can speak what Finns usually call rally-english so freely

Concerning this blog, I think I am a bit too critical about my writing. I’m fairly confident with my grammar and spelling. But I just can’t seem to get the tone, tempo or structure right. I don’t like the sentence structures I come up with. Also, I pay much attention to the repeated uses of same words and phrases.

The criticality of my own writings is the biggest reason why it takes me a long time to create a post from start to finish. Just can’t seem to be satisfied with my posts.

What’s the point of this post? For one, I thought I’d convey some of the things that are going through my mind when I’m trying to put thoughts into words. One of the reasons for this whole blog thing is to improve myself. Not just technical skills but writing skills. This is not a plea to give me support or anything. Just some ramblings that came into mind while writing.

 

Unity3D Reflections – Part 2 – Limiting Access

In the last blog post we discussed how to do runtime-coupling or dependency injection using Reflections. I mentioned that I don’t think it’s really safe, because there wasn’t any way to control the injection. You could block the injector with adjusting the protection level for the property or by not using property for holding the reference. I think that’s the wrong way around the problem.

We could leave the disabling of property injection to the component, but don’t really like it. I’d much rather have a system where the user has to enable the injection for the property.

We’re going to use Attributes to handle the enabling of injection for the properties. We’re going to use the project from the last post and add on to it. But first, let’s scratch the surface of Attributes.

Attributes

Attributes are simply a way to attach metadata to your assemblies, types, methods, properties and such. Attributes can be easily accessed with Reflections. Attributes are attached to parts of code with square brackets and you most likely seen them used in Unity3D code.

Couple of examples from unity and C# itself

// Unity specific Attributes
// Hides the public variable from the inspector
[HideInInspector]
public Vector3 direction;

// Displays a header in Unity3d inspector
[Header("Player Health")]
public int health = 0;

// Set's the available range of the variable in the inspector.
[Range(0, 100)] 
public int speed = 0;

// Marks the private field to be serialized
[SerializeField]
private string name = "Some name";

// C# specific attributes
// Marks the class to be serializable
[Serializable]
public class SomeClass { /* ... */ }

// Imports the GetKeyState() method from user32.dll.
[System.Runtime.InteropServices.DllImport("user32.dll")]
public static extern short GetKeyState(int key);

 

An attribute is defined when a class inherits from System.Attribute class. Today, we will use only the bare minimum to create a CustomAttribute for our example project. For more details about the Attribute class, see Microsoft System.Attribute documentation.

I’m not going to use any of the predefined Attributes here. I’m planning on writing couple of posts about StructLayoutAttribute and as short one on Caller Information. Might do others too, if I find anything interesting.

The code

This is going to be short and simple. The amount of code we have to do to enable the EnableInject-attribute is almost criminal. To begin with, we need to create a class for the attribute. I’m going to call it EnableInjectAttribute.

using System;

[AttributeUsageAttribute(AttributeTargets.Property, AllowMultiple = false)]
public class EnableInjectAttribute : Attribute {
    public EnableInjectAttribute() {

    }
}

The AttributeUsageAttribute isn’t really necessary. It’s used to add limitations to the CustomAttribute. In our case, It makes the EnableInjectAttribute to be only usable with properties. Some of the other possible targets were mentioned in previous part. AllowMultiple part prevents us from using the EnableInject multiple times for a single property. It’s here mainly for displaying the option for enabling or disabling multiple usage.

Now we need to change the Injector itself.

using System.Reflection;
using System.Linq;
using System;

public static class Injector 
{
  // Simple static injector
  public static void InjectProperty<T>(GameObject gameObject, T dependency) 
  {
    // Go through the child objects
    foreach(Transform child in gameObject.transform) 
    { 
      foreach(Component childComponent in 
              child.gameObject.GetComponents<Component>()) 
      {
        // Using the power of LIQN to get the settable properties for 
        // the Components where we can read and write the value and 
        // is of type T
        var properties = childComponent.GetType().GetProperties().Where(
          prop => prop.CanRead && prop.CanWrite).Where(
            prop => prop.PropertyType == typeof(T));

        // If nothing of suitable type is found, properties variable 
        // should be null
        if(properties != null) 
        {
          foreach(PropertyInfo pi in properties) 
          {
            // Use SetValue of System.Reflection.PropertyInfo to set the value
            // of the property
            var a = Attribute.GetCustomAttribute(pi, typeof(EnableInjectAttribute));
            if(a != null) 
            {
              pi.SetValue(childComponent, (object)dependency, null);
            }
          }
        }
      }
    }
  }
}

I decided to show the whole code for clarity’s sake. (The highlight in PrismJS isn’t working correctly. Not sure why.) The code changes are on lines 31-36.

We call the GetCustomAttribute() for the PropertyInfo pi. We are only interested in attributes of type EnableInjectAttribute. Next we just check if the EnableInjectAttribute was found, and inject the dependency.

The last bit of code we need, is the part where we use the EnableInjectAttribute with the RigidBody property.

using UnityEngine;

public class Gravity : MonoBehaviour 
{
  // This is the property we'll be set with Injector.PropertyInject<>()
  [EnableInject]
  public Rigidbody GravityRigidbody 
  {
    get; set;
  }

  public float gravityForce = -9.81f;

  private void FixedUpdate() 
  {
    // Just to be sure, check if GravityRigidbody was set correctly
    if(GravityRigidbody != null) 
    {
      GravityRigidbody.AddForce(Vector3.up * gravityForce, ForceMode.Acceleration);
    }
  }
}

We don’t need to use the Attribute part of the attribute name when using it here.

Whole project is stored in github: https://github.com/jkelanne/Reflections-part_02

Next in the series

I’m probably doing a shorter post next time. It’s about something I ran into while exploring the Attributes: Caller Information. It’s not really needed in Unity3D or at least in the form I’m going to be using it. It’s something I was missing coming from C/C++.

Unity3D Reflections – Part 1

Those of you who are already familiar with managed languages might be familiar with reflections. Me, having a longer background in unmanaged programming languages, reflections as a concept are new and shiny. Reflections provide the ability for the program to examine and modify it’s own structure and behavior at runtime. In this post we are only going to be using a small portion of functionality provided by the C#’s System.Reflection library. Mainly, GetType()GetProperties() and SetValue(). Today, we are going to implement a simple way for injecting dependencies (properties in this case) to a child object (prefab). The example i’m using here is just an example. I tried to keep it as short as possible. In the example project we’re going to use dependency injection to pass parent object’s RigidBody component to a prefab which will apply acceleration force to that RigidBody component.

Unity Part

Let’s first create the Unity-editor stuff. We’ll need a 3D plane, a cube and an empty GameObject. Plane should have a collider by default, so no need to add anything. For the Cube, we’ll add a script named Cube.cs  and a RigidBody3D component. Rename the empty GameObject as Gravity, add Gravity.cs script and create a prefab out of it. Finally, add the newly created prefab under the Cube GameObject. The prefab part isn’t really necessary.
That’s all of the Unity-editor stuff done. Next up, the code.

C# Part

In the Cube.cs all we really have to do is to call the Injector.InjectPropert<T>() which will be covered in the last code snippet. We’ll give it the parent object to whose children we want to inject the given Component.
// Cube.cs
using UnityEngine;

public class Cube : MonoBehaviour 
{
  // Use this for initialization
  private void Awake() 
  {
    Injector.InjectProperty<Rigidbody>(
      this.gameObject, this.GetComponent<Rigidbody>());
  }
}
Next up is the code for the Gravity-prefab object. The important part is the public Rigidbody GravityRigidbody property. The rest of the code is just for demonstration purposes.
// Gravity.cs
using UnityEngine;

public class Gravity : MonoBehaviour 
{
  // This is the property we'll be setting 
  // with Injector.PropertyInject<>()
  public Rigidbody GravityRigidbody 
  {
    get; set;
  }

  public float gravityForce = -9.81f;

  private void FixedUpdate() 
  {
    // Just to be sure, check if GravityRigidbody was set. 
    if(GravityRigidbody != null) 
    {
      GravityRigidbody.AddForce(Vector3.up * gravityForce, 
          ForceMode.Acceleration);
    }
  }
}
Finally the most important part, Injector.cs. I decided to make it static and to keep it generic. We could define it under Cube.cs, but we might want to use it elsewhere. The most important parts of the code are the way we get the properties for Components (lines 19-21) and how we set the value for given Component (line 31)
// Injector.cs
using UnityEngine;

using System.Reflection;
using System.Linq;

public static class Injector 
{
  // Simple static injector
  public static void InjectProperty<T>(GameObject gameObject, T dependency) 
  {
    // Go through the child objects
    foreach(Transform child in gameObject.transform) 
    { 
      foreach(Component childComponent in child.gameObject.GetComponents()) 
      {
        // Using the power of LINQ to get the settable properties for 
        // the Components where we can read and write the value and 
        // is of type T
        var properties = childComponent.GetType().GetProperties().Where(
          prop => prop.CanRead && prop.CanWrite).Where(
            prop => prop.PropertyType == typeof(T));
        
        // If nothing of suitable type is foundt, properties variable
        // should be null
        if(properties != null) 
        {
          foreach(PropertyInfo pi in properties) 
          {
            // Use SetValue of System.Reflection.PropertyInfo to 
            // set the value of the property
            pi.SetValue(childComponent, (object)dependency, null);
          }
        }
      }
    }
  }
}
On the lines 19-21, what we’re doing is just getting all the properties from a Component under a child which can be written to and read from and are of type T (which is the RigidBody in our case).  If GetProperties() returns anything else than null, we know that we have a match. GetType() is quite straightforward. It returns the instance of Type class that contain information about the the object’s type. See Microsoft’s documentation for more information. We’re only interested about the GetProperties() method here. GetProperties() returns the list of properties. We’re using Liqn to go through the result. In line 31, we use System.Reflection.PropertyInfo.SetValue() to set the value of the property. Microsoft’s documentation defines SetValue as:
public virtual void SetValue (object obj, object value, object[] index);
  • obj – The object whose property value will be set
  • value – The new property value. Which in our case is the reference to Cube’s RigidBody
  • index – Optional index value. In our case this can be left as null. This is only used when dealing with indexed properties.

Limitations and problems

As you might have already noticed, the way we’re forcing the RigidBody to Cube’s children isn’t really that safe. We might have solved the coupling issue and made our lives a little bit easier, but at the same time we’re burdening ourselves with the notion that now we might have to handle disabling dependency injection for some parts of the code. What if two or more scripts wants to inject dependencies to the same child object? We’ll figure out ways to limit the Injector in some other post. GitHub link: https://github.com/jkelanne/Reflections-part_01

Hello World

This is the hardest part of this first blog entry. I should probably introduce myself somehow, but don’t really know what to say. Could say something about my hobbies and interest, but are they really that interesting? Anyhow, one of my longest hobbies has been programming, just can’t seem to get enough of it. I love learning new programming languages and techniques. For the past year or so I’ve been learning Unity3D and C#, and it’s been a blast. I also love baking, but I’m not that skilled so writing about it would be mainly embarrassing. There might or might not be some baking photos on my Instagram page (@null_pntr). I also read a lot, but this blog will most likely not contain any book related stuff. I also love video games, but lately I’ve just been too busy with other stuff and haven’t played anything for ages. Just reading about games and watching other play is enough for now.

My background

I’ve been programming on and off for the past 20 something years, though only around 10 years as a professional. I got my degree of Bachelor of Engineering from the Turku University for applied sciences. I specialized in embedded systems software and been working in that industry for the past 10 years. The company I’m currently employed at makes stuff that can be considered as medical devices. Most of my work related code is done using C and C++, but this blog is going to focus more on thing I do on my spare time. These things might include stuff in C and/or C++, but for starters I’m going to focus on Unity3D/C# stuff. Although, I have a blog series in mind which is related to Unity3D and will contain stuff in C++. I have a longish background in Linux, but will most likely not write anything about that. Unless I find something really interesting to write about.

Why I decided to start blogging

The main purpose for this blogs is learning. For me, one of the most effective ways of learning and instilling understanding of stuff, is to teach them to others. So the purpose is pretty selfish, but don’t mind if as a coproduct someone out there finds my rambling helpful. The other reason is my dislike of video tutorials and guides. Usually you waste 5-10 minutes just to realize that the provided solution or explanation doesn’t really suit your problem. With written stuff you can pretty quickly see if the text contains information related to your problem. Videos can be helpful too, but mainly for getting new ideas and viewpoints on things. The final reason is just that I might have done something awesome and really want to tell people about it. Or at least I think they might be awesome.

Some planned blog subjects

I have couple of blog series mind. The first one will be about Using C# reflections in Unity3D. Reflections are something totally new to me due to my background in unmanaged languages. The series will contain stuff about enabling dependency injection using reflections; Using reflections with ScriptableObjects; How reflections can aid you with Unity3Ds custom editor views. Second series I’m thinking about will be about Native DLL’s in Unity3D. We’ll create two simple DLL’s and use them in Unity3D. The example project won’t be anything really useful, but I’m thinking about using some exotic hardware with this. The reason for two DLL’s is: one will be made using unmanaged C++ and the other will be made using managed C++. Using managed DLL’s will be easier, but just in case one might require a “legacy” library in their project we’re going to check out usage of unmanaged DLL’s too. I might do a series about Finite State Machines and Tracker Mod music, but not really sure about those yet. I might include the Finite State Machine thing as an example for creating elaborate custom editor inside unity. The one big issue with these ideas is the size. I will put all of the example projects to GitHub. I’m not sure if I’m going to  include non-programming posts yet. At some point there might be things that I want to write about that aren’t technical. I’m still new to this blogging stuff so we’ll just have to wait and see.

Doges

Finally here are some pics of my dogs, enjoy.
Her name is Peppi.
And she’s called Kerttu (or Kepa)