Marshalling your data for Socket/IO? Maybe not.

By | Programming | No Comments

Hi again!  Today I’ve been working on send variable sized data packets over from my client to server using the simple TCP components I mentioned in this post <link here>.

I have a few different classes that I want to serialize to byte[]s and send over the wire.   After reading a few suggestions online, I decided to try Marshalling.

With marshaling, you can copy the bytes as they are stored in memory – which is exactly what I needed.


            //Serialize data

            int size = Marshal.SizeOf(data);

            byte[] dataArr = new byte[size];

            IntPtr ptr = Marshal.AllocHGlobal(size);

            Marshal.StructureToPtr(data, ptr, false);

            Marshal.Copy(ptr, dataArr, 0, size);


This copies the byte[] into dataArr.

Here’s Microsoft’s documentation


The only caveat with Marshalling is that you have to explicitly define the size of each property in your class.  And as I mentioned earlier, I was sending variable sized data packets.  Sometimes the property of my class would be quite large (ie. 500Kb) and other times really small (ie. 128 bytes).

[StructLayout(LayoutKind.Sequential, Pack = 1,CharSet = CharSet.Ansi)]
    public class HtsSenderPacket
        [MarshalAs(UnmanagedType.ByValArray, SizeConst = 300000)]
        public byte[] ScreenCapture;
        public HtsSenderPacket()
            ScreenCapture = new byte[300000];

So I defined my ScreenCapture property to be a very large byte[].  I didn’t fill it all most of the time, but  I still was forced to send 300000 bytes.  So marshalling isn’t really the way to go for this case.  However, if you do decide to go this route, be sure to include the attribute:

[MarshalAs(UnmanagedType.ByValArray, SizeConst = 300000)]

I forgot this at first and was only sending the address and not the value.

Since marshalling wasn’t going to work for me, I ended up writing my class where I include the size of the variable property.

public class HtsPacket

        private byte[] _screenCaptureSize = new byte[32];
        private byte[] _screenCapture; //variable size

        private int CLASS_SIZE { get { return 32 + _screenCapture.Length; } }
        public byte[] ScreenCapture { get { return _screenCapture; } }

        public HtsPacket(){

        public HtsPacket(byte[] screenCapture){
          _screenCaptureSize = HtsEncoding.GetBytes(screenCapture.Length);
          _screenCapture = screenCapture;

        public byte[] ToBytes(){ //Serializes class to bytes        
            byte[] arr = new byte[CLASS_SIZE];
            Array.Copy(_screenCaptureSize, 0, arr, 0, _screenCaptureSize.Length);
            Array.Copy(_screenCapture, 0, arr, 32, _screenCapture.Length);
            return arr;

TCP Socket Programming in C#

By | Programming | No Comments

The last couple of weeks, I had been researching socket programming for our VR Conference project. Unity Networking and Photon both have bandwidth limitations that is preventing us to sharing desktops and other assets, so we needed to write a custom solution.  I did what you are doing… googled.  Most of the examples out there are for small amounts of data.

Take a look at the example from Microsoft:

From the synchronous client example:

You create a new connection (check)
// Create a TCP/IP  socket.
Socket sender = new Socket(AddressFamily.InterNetwork,
SocketType.Stream, ProtocolType.Tcp );

From <>

Then encode and send your data
// Encode the data string into a byte array.
byte[] msg = Encoding.ASCII.GetBytes("This is a test<EOF>");

// Send the data through the socket.
int bytesSent = sender.Send(msg);

From <>

Pretty simple, right?  You think you’re sending a simple packet of data to your server.  But under the hood, your data packet could be broken up into various sized TCP packets.
If this is all you want to send, the server will get it and this example works just fine.

But if you need to send more, you’ll need to allocate a set number bytes to let the server know the size of the data you are transmitting, then read your buffer until you have it all.

 private void ReadCallback(IAsyncResult result)


 Socket socket = (Socket) result.AsyncState;



 int bytesRecieved = socket.EndReceive(result);

 _applicationPacketSize = GetApplicationPacketSize(_listenerBuffer); //returns the value from the first 4 bytes

 if (_applicationPacketSize == 0)


 _tcpClient.Client.BeginReceive(_listenerBuffer, _offset, _listenerBuffer.Length - _offset, SocketFlags.None, new AsyncCallback(ReadCallback), _tcpClient.Client);



 _offset += bytesRecieved;

 OnLogOutput(">> Read {0} bytes of data... new offset: {1}, application packet size: {2}", bytesRecieved, _offset, _applicationPacketSize);

 //Keep reading data until we reach _applicationPacketSize

 //if (_offset < _applicationPacketSize) //keep going, fill buffer

 if (_offset >= _applicationPacketSize) //we got it all and it's complete, the next bytes will be for a new packet


 _offset -= _applicationPacketSize; //start over



 int packetSize = GetApplicationPacketSize(arr);
 //remove the HTS Header bytes

 byte[] data = new byte[packetSize - DATA_OFFSET];
 Array.Copy(arr, DATA_OFFSET, data, 0, data.Length);
 //You can marshal your data to deserialize it to a class

 OnLogOutput("Unable to deserialize the packet");


 if (_offset > _applicationPacketSize) // We have a completed packet, but we have more bytes for the next packet


 byte[] tmp = new byte[MAX_BUFFER_SIZE];

 Array.Copy(_listenerBuffer, _applicationPacketSize, tmp, 0, _offset);

 _listenerBuffer = tmp;



 _tcpClient.Client.BeginReceive(_listenerBuffer, _offset, _listenerBuffer.Length - _offset, SocketFlags.None, new AsyncCallback(ReadCallback), _tcpClient.Client);

catch (ObjectDisposedException exs)  //Socket has been closed.


catch (Exception ex)

 OnLogOutput(">> Error: {0}", ex.Message);

 _tcpClient.Client.BeginReceive(_listenerBuffer, _offset, _listenerBuffer.Length - _offset, SocketFlags.None, new AsyncCallback(ReadCallback), _tcpClient.Client);





Hope this help with your socket programming.

Game Engine Architecture, 2nd Edition Overview Ch.1 part 2

By | Gaming News, Programming | No Comments

Runtime Engine Architecture (section 1.6)?

This is where it delve into the different layers of systems and libraries that comprise the game engine, in my case, Unity.

Here’s a link to Figure 1.15 from the book:

Target Hardware, Device Drivers, OS, 3rd Party SDKs

The bottom four layers are dependent on the platforms your game will be running on.  Unity supports multiple platforms – meaning that under the hood, they use the drivers/SDKs so you can deploy your game on any of the platforms.

Platform Independence Layer, Core Systems, Resources

There isn’t much documentation regarding these layers from Unity.  I did read that Unity uses PhysX by NVIDIA for collision and physics.   It uses OpenGL for graphics…  Everything is nicely wrapped up in the Unity API.

Rendering Engine

In Unity, the rendering engine is broken out into:

Camera: Cameras are components that display what a player will see.  It’s an imaging rectangle floating in your game scene.

Particle Systems: Particle Systems simulate motion using a lot of small 2D images, ie. clouds, fire, liquid.

Meshes: 3D Meshes are the main graphics primitive in Unity.  Unity doesn’t have a built-in modeling tool, but it supports .FBX, .dae, .3DS, .dxf and .obj files.  You can also import files directly from tools like Maya, 3D Studio Max,  Blender, …

For more details:

Textures:  Textures are images (or movie files) that sit over your mesh.  Think of it as a vinyl wrapper over your car.

Shaders: Shaders are scripts that have the math behind calculating the where and the color of each pixel rendered to your camera.  Unity provides built-in shaders and also lets you create custom shaders.

Here’s a great example of how you can use shaders to manipulate the color and vertices of your texture:

Lighting:  In order to calculate the shading on a 3D object, Unity needs to know the intensity, direction, and color of the light that hits it.

I will be adding links to my posts detailing each topic here:

  • Profiling and Debugging
  • Collision and Physics
  • Animation
  • IO Devices
  • Audio
  • Networking
  • Game Play (AI, Scripting…)

Friends Don’t Let Friends Use Interfaces on MonoBehaviour Objects

By | Programming, Trial By Error | No Comments

Interfaces are great and solve many problems in the world of programming, but recently I have come across a scenario where they cause more harm than good in Unity. I am currently developing a VR zombie shooter game which I will simply call ZNN VR since I have yet to decide on a final name yet. You can read up on the current state of the game here.

The Problem

Since we are targeting Vive and Oculus Touch for ZNN VR  we needed to somehow handle switching between the two. The most obvious answer is to detect which headset is being used and programmatically tell the game to use the appropriate game objects. However, everything external to that should be agnostic about which device we are using so we don’t complicate our code with unnecessary if conditions. Read More

Game Engine Architecture, 2nd Edition Overview Ch.1 part 1

By | Gaming News, Programming | No Comments

What’s Game Engine Architecture?

... and why is this book so important?

For anyone that wants to learn more about game development, AR/VR development,  or computer science in general; this book is your Bible.  I’m reading this book and learning Unity’s game engine at the same time.  Unity is a very powerful game engine and has pretty much everything you need to build awesome software without having to know the details of the game engine itself.  They provide a variety of tutorials and robust documentation.  However, I still believe that you need to understand how things work “under the hood” to get the most out of the engine.

My goal is to build a reference guide to better correlate Unity’s game engine with the topics of this book. Read More

Cardboard Zombies in VR – Our Newest Project

By | Announcements, Games, ZNN VR | One Comment

Like many of you, we are excited about the future of VR and have decided a while back to jump in all the way and one of our projects ended up being the re-imagining of our first game ZomNomNom in VR. ZomNomNom was released back in 2012 on iOS and Android and was a zombie shooter built around a mobile phone and tablet interface.

The idea for ZomNomNom was to make something that leveraged the unique capabilities of touchscreen devices. The game is driven completely by tapping and swiping with no need for d-pads or the like. Sure, we did have three on-screen buttons, but they were big and built around the idea of quickly being able to tap to switch your weapons.

So for the VR version of this game we decided to again leverage the unique capabilities of virtual reality and motion tracked controllers.

This time the zombies have come to life in the form of cardboard cutouts! You still play as Red while you try to defend your office Virocorp and prevent zombies from breaking down the office’s doors. The gameplay is something akin to Space Pirate Trainer and Arizona Sunshine. You spend the game on top of a building and pick off the zombies as they try to make it to the doors. Read More

The Oculus Wedge – Custom Oculus Sensor Mount

By | Fun Stuff | No Comments

There comes a point in every Oculus Rift owner’s life when they think they can do better and I am no exception. No, I’m not talking about in my personal life, but the placement of my Oculus Sensors to give me a better tracking space.

My problem is that where I normally place my sensors, one of the sensor’s camera is blocked a bit by one of my monitors I have on an arm and both are blocked by my desk leading to a no-tracking dead-space area right in front of my desk. This became annoying pretty quick when developing when I needed to reach for things on the floor in front of my desk in VR but just simply could not.

Enter, the Oculus Wedge. We designed the Oculus Wedge to fit in your home and be as unobtrusive as possible while still giving you the best experience possible. The revolutionary 100% bio-degradable design gives you peace of mind you are not harming our beloved planet earth… Okay, enough with my terrible Jony Ive impression. It’s just a piece of wood with some holes and stuff drilled through it, but it works pretty damned well and cost me virtually nothing!

Anyway, here is how I built the thing. Read More

Solved: Samsung GearVR application closed unexpectedly

By | Trial By Error | No Comments

As we were preparing to submit our final build of Acorn Assault VR: The Ride to the Oculus store, we encountered a critical app crash during the app launch process via Oculus Home. The message displayed upon selecting our title from the menu read “Acorn Assault VR: The Ride has closed unexpectedly”, which is not a very useful error message. Instead of trial and error, it was time to configure logcat over TCPIP. This is a much-needed step because you can’t debug your VR title via USB debugging since the port is being used by the VR headset. Here are the step by step instructions on getting adb over tcpip setup: Read More

Acorn Assault Throwback Thursday

By | Announcements | No Comments

It has taken nearly three years, but Acorn Assault: Rodent Revolution is launching next week on March 2nd on Steam. We thought it would be fun to jump back in time to see how far this game has really come.

Let’s start from the beginning. Hot off the heals of ZomNomNom, we were ready to start our next game. We had some ideas of what we wanted to do such as doing something 3D and nothing with zombies. Don’t get us wrong, we love our first born ZomNomNom and all the wacky characters, but that market was very flooded and we needed something fresh. Read More