Development

Let us have a look at the eventing or observer pattern. This pattern is based on the raising and handling of events. Events are a mechanism for the communication between object that allow us to build loosely coupled applications that can be easily extended.

At a high level this pattern functions as follows:
An object (known as the Publisher) defines a contract (delegate method) to which other objects (knows as Subscribers) must comply in order to be notified of a certain condition occurring in the Publisher object. This is achieved as follows, when a certain state is reached in the Publisher object an event will be raised, which will then trigger all the Subscriber objects to react by executing the method defined within the individual Subscriber objects that matches the delegate method as defined in the Publisher.

Now let us have a look at an example:

First let us create the Publisher, here we have to do three things:
1. Define a delegate which will act as the contract between the Publisher and Subscribers.
2. Define an event based on the delegate.
3. Raise the defined event.

Extension methods allow us to add methods to existing classes without changing the class’ source code, nor by inheriting from the class. Extension methods are more relevant when wanting to add a method to a class from which one cannot inherit, such as sealed classes.
Just note, you cannot use extension methods with a static class as extension methods require an instance variable for an object in order to be utilised.
Let us look at an example, here we will add an extension method to the string class, which is a sealed class (i.e. you cannot inherit from this class).

A delegate is a form of a type-safe function pointer. More simply put, it is an object that knows how to call a method, i.e. a reference to a method. Delegates are useful as they assist us in writing flexible and extendable applications.

Delegates are useful when using the eventing design pattern also known as the observer pattern. The eventing or observer pattern consists of an object, called the subject or publisher, which maintains a list of dependent objects, called observers or subscribers, and notifies them automatically of a state change in the subject-object by raising an event and then calling a method on the observer objects by using a delegate. We will cover this pattern in more detail when I cover events in a separate post.

So, in this basic example we have a class KillerRobotActuator which declares a delegate:

public delegate void KillerRobotActionHandler(KillerRobot robot);

Any method that complies to this signature can then be added to this delegate and in the DoAction method where the following is executed:

actionHandler(robot);

All the methods that have been added to the actionHandler will then be executed.
We can see in the Main method of the Program class that a new KillerRobotActionHandler is declared and three method references are added to it as below:

And then finally the DoAction method on KillerRobotActuator is executed, passing in the above declared actionHandler containing references to the three methods:

robotActuator.DoAction(“The Geek”,actionHandler);

All three the methods that are referenced by the actionHandler comply to the signature defined in the delegate declaration in the KillerRobotActuator class. i.e. a void return type and an input parameter of type KillerRobot.
It is also worth mentioning that of the methods referenced, two are contained in a separate class RobotActions and the third is a static method declared in the Program class, so methods from multiple different class locations can be added as long as they comply to the signature of the delegate declares.

Generics refer to the method of creating classes and methods in a way that defers the specification of the type or types associated with the class or method until it is declared and instantiated.

What this means in plain english is that you can define a single class or method that can be utilised with multiple types, thus resulting in less and tidier code.

So let us have a look at an example. Firstly let us look at some code that is not generic. Here we have a class which consist of a list of integers, it has a default constructor as well as two methods, one to add an integer to the list and the other to return the sum of all the integers in the list.

This is very straight forward, however if I would like to use this class with a data type other than int (for example a float or a double) I would need to define a new class for each data type. This can be overcome by utilising Generics. Below is an example of how this can be implemented:

In some cases you might want to put a restriction on the types that can be utilised to implement a generic class of method, this can be achieved by utilising constraints. For example the class we defined above can be restricted to types that implement the IComparable interface by simple changing the first line as follows:

public class KillerRoboticsGenericList<T> where T : IComparable

Some additional examples of constraints are:

where T : Product

This restricts the type of T to an implementation of the class Product or any of its child classes.

where T : struct

This restricts the type of T to the value type struct.

where T : new()

This restricts the type of T to an object with a default constructor.

Multiple Constraints can also be appled at the same time, for example:

A Generic class can be defined to utilise multiple types, for example:

public class KillerRoboticsGenericList<T,U,V>

It is also worth mentioning that the default c# List class used in the above examples also utilises generics, along with all the other predefined c# collections contained in System.Collections.Generic.

I hope this post has been useful and I will be posting on some additional C# topics, such as Delegates, Lamda Expressions, LINQ, Extension Methods, etc. over the next few months.

15 Years ago I wrote a small game called Hellspawn and I rediscovered it again when I was going through some old backup discs. It is a top down shooter and was developed in Borland C++ Builder (I think version 6). It was a very basic game (especially looking back now) from when I was still a very inexperienced developer, still studying to get a degree.

The purpose of this series of posts was to look at ways to experience VR at home for the lowest cost possible. In Part 1 of DIY VR, we took a look at using a smart phone and a Google cardboard compatible headset to stream computer games to the phone in stereoscopic 3D. The main problem with this approach was that it was still relatively expensive as it required a smart phone (iOS or Android) to function.

Now in part 2 we will look at building a VR headset from scratch. My initial goal was to do this for under $150(USD), however after shopping around and changing some parts out for alternatives I managed to get this down to around $80. So let us get started.

The parts required are:

Toggle Flick Switch

2x LED

1x resistor 150 Ohm

1x Micro USB cable (at least 2 meters long)

1x HDMI Cable (thin ones work best as they hinder movement less, also at least 2 meters long)

Some jumper wires

DC Adapter plug 5V 3A (Raspberry Pi compatible one works great)

Push Button

Google Cardboard Compatible VR Headset (I recommend one with a phone compartment door that opens as it gives better access than the ones which uses a tray that slides in)

6DOF MPU 6050 3Axis gyroscope and accelerometer

Arduino Micro (can use off brand alternative)

5inch RaspberryPi LCD Screen 800×480 with HDMI interface

All of these parts can be acquired on AliExpress for about $80 ($82.78 to be precise), as shown in the image below:

You will also require Tridef3D or similar software (there are some free alternatives, but I have not had a chance to give them a try at present). Tridef3D is used to convert any Direct X 9/10/11 game into stereoscopic 3D. Tridef3D offers a 14-day free trial, which is plenty to give this a try. The full version of Tridef3D retails for $39.99.

Now that we have all the required components, let us begin with the assembly.

Just note that the orientation of the MPU 6050 makes a difference to which of the axis of the gyroscope will be used. For the above code the MPU 6050 was mounted on the side of the headset as shown in the pictures below:

In the event of the MPU 6050 being mounted with a different orientation you might have to substitute between the gx, gy and gz values until the desired configuration is achieved.

For my configuration I am rotating around the Y and Z axis.

Also the numbers associated with calculation of vx and vy might have to be tweaked to get the results (movement speed etc.) you desire.

I also added a push button, that when pressed temporarily disables the gyroscopic mouse movement. This is useful when you want to reset you point of view in games.

I attached all the parts of this circuit to the VR Headset using double-sided tape.

The Wiring

In order to have as few cables as possible connecting to the VR headset I modified the USB cable so that it pulls external power from a DC power adapter (a single USB port will not be able to power both the Arduino and the 5 inch LCD) as well as splitting into 2 micro USBs on one end (one only provided power to the LCD and the other one both power and connectivity to Arduino.) the below diagram shows how the wiring is connected:

For reference a USB cables contains 4 wires:

Red wire – +5V DC

White or Yellow – Data connectivity

Green – Data Connectivity

Black – GND

I also included a switch to turn the power on and off (this is useful to turn off the mouse functionality until it is needed, otherwise it will interfere with mouse movement when it is not desired) as well as an LED to show when the headset is powered on.

Inserting Screen in Headset and connecting all the wiring

The LCD screen is held in place by the clamps in the headset used to hold a phone (it is a snug fit). Then simply connect the 2 micro USBs to the LCD and Arduino respectively (ensuring the plug with the data connections is plugged into the Arduino and that the power only micro USB is plugged into the power socket on the LCD display). Try to run the cables in the extra spaces in the Headset around the screen in order to keep them out of the way.

Lastly connect the HDMI cable to the LCD.

The assembly is now complete.

Connecting headset to PC and setting up software

To connect the headset to your PC do the following:

Plug the DC adapter into mains power.

Plug the USB connector into an available USB port in your PC.

Connect HDMI cable into and available HDMI port on your PC graphics card (You can use a DVI port with an adapter)

Go to display settings and click on detect displays, then set Multiple displays to “Duplicate these Displays” and make sure your resolution is set to 800×480.

Open up Tridef3D and start-up a game.

You might have to play around with each individual games graphical settings as well as mouse sensitivity to get the best results.

For future enhancements I will look at getting a higher definition LCD screen and also work on head movement tracking by using infrared LEDs and a Wiimote (Wiimote used as a IR Camera).

When working on legacy systems you may sometimes find that a wide variety of technologies have been used, and short of rewriting a huge amount of code the only thing that can be done is to create some functionality to map between the different technologies utilised.

I had a scenario where I had to integrate 2 legacy applications utilising different technologies for database access, one utilised ADODB and the other ADO.NET. Due to time constraints I could not change the underlying code of the systems and rather decided to create a helper class to map an ADO.NET DataTable to an ADODB RecordSet in order to facilitate the integration.

My DTtoRSconvert is a static class that resides in the Core.Data.Help namespace. It contains a static method ConvertToRecordSet that takes a DataTable as a parameter and returns a RecordSet. It also has one static private method TranslateType which is used to map between the DataTable and RecordSet Data types.