On Friday night I had the urge to release something for Oculus Quest, so I dug out Blobby Tennis, which I already tweaked to work on the Quest, made a build and put it on SideQuest, the most amazing way to sideload all things Oculus Quest and Go and any other android based VR device. With Oculus tightly controlling the games released on Quest, SideQuest found quite some popularity.It also shows in the download numbers, which now after about 4 days are just about to reach 1000, which seems pretty good for VR side loading.

Blobby Tennis for Oculus Quest can be downloaded here for free: https://sidequestvr.com/app/253/blobby-tennis

It's exactly the same game as on PC, but without shadows. But actually the performance headroom I had before is gone, so I think the shadows may be turned on, except not visible cause it's missing some minor parts in my Vulkan renderer...

I replaced my zombies with some more zombie like models and started tweaking the graphics :)

Environment

My static environment is sharing a single lightmap texture which I baked in Blender. The static detail objects such as chairs and beds all share another lightmap. My lightmaps have a resolution of 4096x4096 and are later compressed using astc (with a block size of 6x6) for android and BC4 (the quality using BC1 was unusable) for windows/linux/macos. To do the lightmap UV layout I used the "Texture Atlas" plugin for blender (which I believe is a default plugin included in blender, but disabled).
The biggest challenge here are seams when mipmaps are being used in the distance, but wasting more texture space for bigger margins or using a mipmap bias for sampling the texture helps to hide those.

All lighting in this screenshot is baked:

Zombies

I wanted the Zombies to be effected by lights, one approach would be to check the lightmap below them and use that color, but getting that color takes a bit of work which I wasn't willing to put in at this time. Instead I made it easier by rendering another lightmap into a plane at a height of 1.5m inside the corridors. My levels are all on the same height anyway so just using a plane works great. I chose a plane that is big enough to fit any level and allows me to just use the texture directly in the Zombies fragment shader with hardcoded values for scaling and shifting so the texture pixels align with their correct position inside the level.

That texture is then sampled in the fragment shader and effects the ambient value and a very basic diffuse light source from above the zombie (all my lights are on the ceiling, this "light" is just hardcoded). I combine this with some weaker light from below the zombie as fake indirect light to make it look a bit more interesting.

The shader code for this looks like this:

float3 normalizedWorldNormal = normalize(vert.worldNormal);
float lights = saturate(normalizedWorldNormal.y) + saturate(-normalizedWorldNormal.y)*0.3; //These are the lights from above and below using lambert diffuse shading
float brightness = texture1.Sample(linearRepeatSampler, (-vert.worldPosition.xz + float2(38.0, -12.0))/80.0).r; //My plane is 80x80m and one of it's corners is at (38.0, -12.0)
float3 light = ambient * (brightness * 0.6 + 0.3) + lights * brightness * 2.0; //The final term to multiply with the zombies texture color, the numbers are the result of trial and error.

This is it in action:

Zombies also have a drop shadow. I am not completely happy with how it looks and may end up tweaking it some more. It uses a light for each zombie that darkens the level geometry within it's radius. This can also be seen in the video above. My shader supports 8 of those.

Doors

I started out with having a fixed ambient value for every moving door which I manually assigned in my level json files. I came up with some acceptable values, but this does not adjust when moving the doors for example. The new idea here was to reuse the plane lightmap from above.
All I did for the doors was blurring that lightmap a tiny bit to remove some artifacts and use the lightmap pixels as ambient values for the door. There are lots of cases where this is not perfect and doors tend to be too bright from one side due to the lightmap rendering being without doors, but it looks much better than before.

Floor

I've been experimenting with reflections using mirrored geometry and a transparent floor before, but the bigger level got too big for this to run smooth. Instead I am now using static cubemap reflections. The cubemap is rendered in blender using the "Render Cube Map" plugin (https://github.com/dfelinto/render_cube_map), I then use the command line tool "cmft" (https://github.com/dariomanesku/cmft) to blur it. And then a shader to mix these reflections into the floor based on angle using a fresnel approximation:

float3 incidentVector = normalize(vert.worldPosition - cameraPosition);
float3 normalizedWorldNormal = normalize(vert.worldNormal);
float3 reflectionDir = reflect(incidentVector, normalizedWorldNormal); //Reflect camera direction on the surface normal
float3 reflections = texture2.Sample(linearRepeatSampler, reflectionDir).rgb; //Get pixel position

float reflectionFactor = 0.3 * pow(1.0 + dot(incidentVector, normalizedWorldNormal), 5);
color.rgb = lerp(color.rgb, reflections, reflectionFactor);

Ideally the cubemap should be created from the camera position mirrored along the reflecting plane. In my case about 1.8m below the floor, but I had some problems with clipping away the floor in blender. Also this cubemap is not moving with the camera, so I chose a position in the middle of a corridor, which doesn't work that well for rooms. But making it a bit blurry helps with hiding how wrong it actually is and it looks a lot more interesting than without the reflections and is quite cheap.

Particles

I also added some particle effects, but I am not exactly great at making those. One for breaking doors and another one for exploding zombies. I kinda like my broken door particle effect, while the other one is still not quite right. There is nothing very interesting about these. My particle system is generating a mesh for each particle material on the CPU where each particle has 4 vertices. Each vertex has the particles position, color and it's position in the quad. The vertex shader then transforms the vertices into a camera aligned quad and the fragment shader samples the texture and multiplies it with the vertex color. The result is a very flexible and decently fast particle system that works fine for low to medium amounts of particles.

Here is a video of all these changes together:

Z Mission was the game my team developed during one of InnoGames game jams about 1 year and a half ago. It was a simple puzzle game with zombies, with the goal for the player to get out of wherever he is by evading zombies and luring them out of the way and trapping them behind doors. We used the at the time latest version of Rayne as game engine and while I didn't bring a VR headset to the game jam, we did develop it with VR in mind.

When Oculus released the Oculus GO a bit later that year I wanted to prepare Rayne for the Oculus Quest by remaking Z Mission as Project Z for the GO, which just like the Quest uses Android. I thought I could turn this into a full little game within maybe 4 - 6 months, as always that estimate was very wrong :).

This was also a good opportunity to get the Vulkan renderer working and to feature parity with my Metal and D3D12 rendering. But because of just a few random hints of the GO getting support for Vulkan but no actual support yet, I started out implementing it on Windows first which worked out quite alright. I am sure there are a lot of things that can still be optimized and some I already improved and I am not taking advantage of multithreading in the renderer yet, but most things are just very similar to D3D12 but with more consistent naming. The one big annoying thing with Vulkan is shader compiling. Because while it is of course possible to include a shader to spirv compiler in the engine, it's not exactly part of Vulkan which just wants spirv memory blobs. With my system of having an Übershader and enabling features by recompiling it with different defines turned on, this was a problem. As a result I ended up writing and assigning specialized shaders that I precompiled by hand (using a spirv compiler obviously). Which was turning into a lot of work to maintain... I solved this recently by automating the process of having one HLSL shader that gets recompiled for all possible permutations for the 3 different rendering APIs (more about that in another post maybe).

While the Vulkan rendering was starting to work decently what I really wanted was making it work on the GO.

First I tried the Vulkan samples for android on the GO. They just worked which was a good start, but because there was no support for the Oculus SDK it didn't do anything VR and was just using the GO as a single screen and not using any of the sensor data. This gave me some hope on finding a workaround so I started porting the engine to android. It took a day or two until it was all kinda working. But still no VR.

Looking at the available Vulkan extensions it turned out that there was some functionality to share memory to OpenGL ES 3.0. I did get this to render into an OpenGL surface, but the Oculus SDK wants to handle the swap chain textures for me which somehow ended up complicating things more than I wanted to.

Around the same time or maybe earlier, Oculus released experimental Vulkan support for Unreal on GO. Turns out it was part of their latest SDK release at the time but they didn't include any headers yet. After a day of scraping the symbols for it and trying to turn it into something that would work, I gave up and contacted their developer support. As a member of their Oculus Start developer program I am entitled to special developer support and apparently these support tickets are very useful. A day later they got me in contact with the developer who was actually implementing the Vulkan support and I got all the headers and information I needed (which became part of one of their SDK releases a month or two later).

Their Vulkan support seems to be using the same shared memory technique I was trying to use, but as it's implemented on their end it allows them to copy less data around then I would have had to do. Anyway the result was fully working Vulkan support on the GO! BUT performance with MSAA was very bad and there is no support for fixed foveated rendering with Vulkan. Also no debugging tools have been working for Vulkan at that time. I decided to just accept those problems and carry on with what I had.

I created a first set of levels and had some friends and family try it, but it turned out to be too hard and frustrating, so I came up with even easier first levels and only very slowly making it more complicated. Not being good at level building slowed my efforts down a lot. I considered making a simple editor for these levels a couple of times but always decided to just go with blender as my requirements were very low. I am definitely regretting this decision now as it would have improved my productivity a lot and gotten me more and better levels in the end. Maybe even an editor to include in the game for users to create even more levels. Anyway, my motivation to create more levels was very low (and still is).

A month or two later I went to Oculus Connect 5, the Oculus developer conference to spectate Echo Arena, talk to some Oculus developer support people and watch some talks. I scheduled a support session (and included the things I wanted to talk about), but when I went there most of them were gone and nobody specific to my problems was around (mostly MSAA, but also some other things). The guy I talked to did write down my email and said he'd get back with some answers (but never did). Fortunately when I was just about to leave someone else came in who had some ideas about why my MSAA was being slow (I reused a quite big render target that could fit both eyes and while it didn't seem like it was fully resolved twice, he said it there may be an unresolve pass before the second eye renders which can be very slow. Anyway I eventually split it into two eyes, which improved performance a lot) and were to find someone else that could help me who was just doing a talk. I went to see most of that talk and then talked to him. He mostly just confirmed things I already new, but maybe he remembered me when they made RenderDoc work with Vulkan on GO earlier this year.

When a friend asked me about Linux, I updated the Linux support Rayne used to have and also tried to make the game work with SteamVR on linux, but it kept causing a random crash, so eventually I gave up (may get back to it in the future). While very slowly working on the first 10 of the 15-20 levels I wanted to have, I also started updating a UI module that Sidney started a few years ago and made it work with in game textures. It's using Skia, which is a UI library from google, which was or still is used on android and for Chrome some way and it has a CPU, OpenGL and Vulkan backend for the rendering. It's somewhat low level, but has basic text rendering and can do all kind of shapes and images. For simplicity I am using it's CPU rendering, which after some performance issues with transfering the data to the GPU has been fast enough for what I need. I initially wanted to implement my own fully hardware accelerated vector rendering, but just getting the data prepared for it seemed like a lot of work.

The levels were still the thing holding me back and I spent some time on prototyping other projects:

• A multiplayer boxing game with a multiplayer audience that could walk and talk outside of the ring and sign up for matches which would then teleport them into the ring when ready. It's ugly, very limited, but a decent proof of concept based on the code I already had for Swords.
• An asymmetrical multiplayer horror game for VR, which I intend to spend more time on after finishing Project Z.

But because I really want to eventually finish Project Z and release it mostly for GO, but also for other VR headsets before really working on something new, I started posting requests for someone to help me create good looking levels for the game based on the levels I already had. Eventually I found someone who agreed to make them for the low price I was willing to pay. He eventually gave up but gave me a very high quality base to work with, but I ended up putting most of it together myself and baking the lights and everything. The actual modeling and texturing work he did do was very good.

Now I am stuck with levels again. I did finish putting together those first 10 levels I had and decided to only do 4 more levels which I also put together already but with some flaws I want to fix. Which is again slowing me down as I am too much of perfectionist apparently... Not in terms of making the game perfect, but in terms of fixing overlapping polygons, small holes in the geometry and getting the shading just right without too many artifacts.

And some more information about the game itself:

• There are 4 different Zombie types: A melee zombie, a ranged attack zombie, a zombie that can break through doors and a zombie that attacks other zombies as well as the player and also gets attacked by them if too close.
• There will be 14 levels, most very short, some bigger and harder though.
• I do intend to change the Zombie model and recently implemented the animation system I had in old Rayne into the new Rayne. As a result zombies can be animated now.
• Total play time for a first playthrough is probably gonna be a bit more than an hour (I can do it in 10-15mins).
• Zombies may or may not end up glowing in the end, it doesn't look great but it tells the player where they are and makes the game less frustrating.
• There are some quite useless stats shown in the menu for each level such as total number of deaths and fastest time (all for local player only, stored on device).
• I intend to sell the game for 4.99€ on all platforms.
• It's currently not taking advantage of positionally tracked controllers as grabbing door handles and pulling/pushing them takes a lot longer than just getting close to a door and pressing a button and would make the game a lot harder.

I hope to get it released before halloween.

Or that's what my blog probably looks like... Anyway, I thought it's time for a change and switched my blogging software away from Anchor to Ghost. I also switched from Apache to Nginx and and from my own ugly mailserver setup to a more automated one using mail in a box. Everything is still hosted on Linode as it has been for a while.

There was no real reason for this change and no major challenges in setting it up because Linode has a big library of good How To articles for almost everything. It took a bit longer than a day with most of the time spent on getting my old web projects Lilly rettet Weihnachten, Glow and some other thing I once did with some friends, which is all required some minor changes or mysql or php to work.

And just like the last time I updated my web setup, maybe I'll be writing more again. I've definitely been working on some things and it shouldn't be hard to find something worth writing about.

What can I say... after writing my previous blog post about Project Swords I started downloading the open beta of the VR game Echo Arena and couldn't stop playing since.

In Echo Arena two teams try to get hold of a disc and to score into the opponent teams goal in 0g. The players move around with small boosters attached to their wrists, a bigger booster attached to their head and by grabbing on to surfaces and pushing themselves off them. The maximum speed for each of those movements is capped to a quite low maximum but can be raised by holding on and launching off of other players.

Even though I am quite prone to motion sickness this games fast and fluid locomotion system felt good to me from the start. It's a ton of fun and I am actually really good at it.
The game eventually got released while still lacking important features that have been and still are being added to the game such as playing in fixed parties and spectator mode. There are also sometimes server issues and random crashes, but most of the time it works and it's great.

Echo Arena is the second VR game (next to Unspoken) getting pushed to become a competitive esports game. To do this Oculus works together with ESL and Intel to organize competitions with a big price pool they call the VR Challenger League. Teams in North America and Europe can compete in weekly cups for 50€ price money per person each week and points to qualify for offline events. The first of those offline events was the North American regional tournament at Oculus Connect 4 and the next one will be the EU regionals held at ESL One in Hamburg. The best teams of both regions will eventually meet in the world cup held in Poland as part of IEM Katowice. The winning team during regionals wins 3.5k€ per person and it's about twice that for the world cup. Considering that it's a new game with only few teams competing and that they are paying for the trips and hotels for the qualifying teams, this is really nice.

In Europe there are only 7 actively competing teams at the moment and I am in one of those called "Jacks" based on the character from the game Lone Echo, which is the single player part of Echo Arena and the player character is essentially the same robot everyone plays in Echo Arena and he is called Jack.
We keep having one of us not able to compete and have to find substitute players, but we still managed to win the first 3 cups, skipped the fourth completely, played well in two more and won the latest one again. As full team we haven't been defeated yet, qualified for the regionals and should have pretty good chances to go to Poland early next year. We are currently placed second in the EU league and will hopefully get back be the best team in points :).

Here is us playing against our biggest opponent "Ding!":

There are videos from all the previous cups on our youtube channel: www.youtube.com/channel/UCS2y476rtK33oKc_aRG5ZXA

If you own a Rift and haven't tried Echo Arena yet you should because this is the best VR has to offer right now and it is amazing.

So what happened to Project Swords?
I didn't directly work on it for a while, but I didn't give up either and the engine got some massive improvements in the last months :). I'll hopefully post about that soon.

Blobby Tennis

I just launched Blobby Tennis on Steam and the Oculus Store as a very small, but free VR experience. Turns out that getting anything VR released on those two platform is currently very easy, as all it took was submitting it to the Oculus Store using their developer dashboard, while I had to send an email to some Valve address and got a developer invitation in return.

While this was and still is very exciting, it is too early to draw any conclusions or anything, but I might write some more about it in the future.

Masterplan

But Blobby Tennis was really just a short stop on a longer plan of me making VR games. What I have now is a somewhat well working game engine with a DirectX 12 renderer and VR support, but a still limited feature set (no animations, no particles, only very hacky post processing and probably a lot more...).

My next and much more ambitious project is a VR multiplayer sword fighting game. I don't expect to be able to turn this into a realistic sword fighting simulator, but I want to make the most out of what's possible without hard haptic feedback.
The amazing working title is "Swords"!!1111
The great thing about this is that I can easily get a first prototype working with only few assets and keep iterating and expanding it for as long as I want to hopefully turn it into an enjoyable game.

And while doing all this I'll try to write a new devlog every now and then about my progress and problems I encountered along the way.
And then the game is released, highly successful, I can start working on something new and pay other people to keep this game going and that is pretty much the plan :D

Oh and also I'd like make the game accessible to others while still in development and at some point begin charging a small amount of money for it, when it gets closer to completion.
I am not at a point where I got something to release, but I hope I will be by maybe the end of july.

For a first public build of the game I want to have some kind of moving around together in multiplayer with basic ingame voice chat.

Physics Problems

I am using bullet physics for the physics simulation, mainly because I have been using it in many projects before and while having lots of issues it always kinda worked in the end.

One big problem I already had to solve for Blobby Tennis was attaching the racket to a hand. It turned out that using a constraint was somewhat unstable and especially caused some way too random behaviour when hitting the ball. Sometimes the ball was accellerated far too little and sometimes it just flow out of the map.

For some reason the solution was to directly set the acceleration of the racket to stay at the hand position.
Which in my code looks like this:

RN::Vector3 speed = GetWorldPosition() - _racketBody->GetWorldPosition();
speed /= delta;
RN::Quaternion rotationSpeed = GetWorldRotation()*_racketBody->GetWorldRotation().GetConjugated();
RN::Vector4 axisAngleSpeed = rotationSpeed.GetAxisAngle();
if(axisAngleSpeed.w > 180.0f)
   axisAngleSpeed.w -= 360.0f;
RN::Vector3 angularVelocity(axisAngleSpeed.x, axisAngleSpeed.y, axisAngleSpeed.z);
angularVelocity *= axisAngleSpeed.w*M_PI;
angularVelocity /= 180.0f;
angularVelocity /= delta;

_racketBody->SetLinearVelocity(speed);
_racketBody->SetAngularVelocity(angularVelocity);

While I represented the racket collider as a compound of just two cylinders to approximate the rackets head, I want objects such as swords and shields to have an accurate physics representation. Bullet offers basicly two solution for this:

• btGImpactMeshShape - Can handle concave and even changing meshes, but it is supposed to be slow and somewhat unstable.
• Convex decomposition and then using either btConvexHullShape or btConvexTriangleMeshShape - A compound of butConvexHullShape objects seems to be the recommended way to do it.

I tried all of them and the btGImpactMeshShape didn't want to collide with my ground plane for some reason, so I didn't really bother with it any further.
There is some utility code in bullet to do a convex decomposition of arbitrary meshes, but doing this at runtime every time is very slow and also the algorithm used is somewhat outdated. Fortunately there is V-HACD V2.0 including a well working blender plugin!
The plugin is even nice enough to create a unique material per generated mesh, which allowed me to just merge and export them as a single model into my custom format and can now just load it and generate a shape for each of the meshes.
While all this worked great from the start, it turned out that the resulting collision shape was WAY too big.
It took me a day to find out that bullet applies additional margins to all it's shapes. It is possible to turn them off, but not recommended, instead the mehes used for the collision shapes are supposed to be scaled smaller in a special way that correctly takes the generation of the margings into account. I didn't manage to figure this out in blender, but bullet provides a utility function to do so in its btConvexHullComputer class:

btConvexHullComputer *convexHullComputer = new btConvexHullComputer();
btScalar actualMargin = convexHullComputer->compute(vertices, stride, margin, 0.001f);

Here 'margin' is the preferred margin, '0.001' makes sure that the hull doesn't get too small and 'actualMargin' is the actual margin value used to shrink the mesh. I am then creating the btConvexHullShape using the vertices in 'convexHullComputer->vertices' and setting the shapes margin to 'actualMargin'.
While not 100% accurate, the resulting collision meshes are working good enough for my current needs. There are still issues where two objects (sword and shield) can pass through each other, especially at the cracks between two convex hull shapes, if only enough force is applied. With both my objects following a hand, this is still way too easy to accomplish. I hope that adjusting the forces is going to be good enough in the future, but it may not be...

What's Next

While not finished with physics any time soon, I want to get networking in soon, but am somehow most excited to start out with the voice chat. For this I first need audio playback. I used OpenAL soft before, but it's a bit limited in terms of correct audio physics. So I just started implementing a somewhat custom audio solution utilizing Steam Audio and libsoundio.
I am probably going to use the Opus Audio Codec reference implementation for the voice chat codec and enet for networking.
I'll probably write more about all that in future devlogs :).

As you may or may not have noticed, I switched the blog software from pants to Anchor. I reposted all posts, so their date is wrong but the content is still the same.
I switched mostly because the few people making pants cool also started switching to other blog systems. Also I kept getting a message every few months from my host that they had to kill the process, because it used up too much RAM.
Anchor so far seems nice and simple.

GGJ17

I also participated in the Global Game Jam 2017 in January, as usually at InnoGames. This time Sidney joined me and together with an Artist and a Gamedesigner, we made a Game Boy game for the original Game Boy. We wrote it in assembly and while it took us a while to get going, we are really happy with the result.
We used RGBDS for the tools to build an actual rom for the game, IntelliJ as IDE and GBT Player for the music playback.
We used a cartridge reading roms from an SD card to play on a real device.

The game is called Sushi and can be downloaded including the Emulator BGB which we also used for testing from the GameJam website: Sushi

If you start writing a 3D graphics engine, the basics usually consist of loading mesh, texture and shader data and getting it to the GPU in a way that enables the GPU to run the shader with the mesh and texture data as input. To load the texture data in a plattform independent way, easy formats to get started with are TGA, BMP and PNG (with a lot of help from libpng...). Much better for a real game are usually compressed formats such as S3TC that can be decompressed by the GPU while rendering at no performance cost. But at least I have a lot of PNG files laying around I want to test with and I don't really feel like converting everything until I have a real asset pipeline going.

However, just loading a PNG file and then using it for rendering, results in massive aliasing with a moving camera for all surfaces that are not directly in front of the camera:

The solution is of course mipmapping, by using lower resolution versions of the same texture depending on the screen pixels size on the textured surface, the aliasing can be eliminated:

In OpenGL there is a function called glGenerateMipmap, which automatically generates those mipmaps for a given texture. DirectX until DirectX11 has a method called GenerateMips doing the same thing.
Both are using the GPU and are somewhat fast as a result.
Turns out that both new rendering APIs Vulkan and Direct3D12 got rid of this functionality.
The easy solution would be to just generate the mipmaps on the CPU, or well, have an offline process generate them and ideally combine that with a compression format such as S3TC. If you don't want that, Vulkan has a helpful vkCmdBlitImage function that copies a source texture to a destination texture by downsampling it. It is very easy to find this when researching the topic and while it took me a while to get it running, it kinda just works.

The Code

For Direct3D12 on the other hand there is no such blit function and I just found some people talking about Microsofts samples. And yes, after some digging it turned out that the MiniEngine has functionality to generate mipmaps using a compute shader. But since I am not building on top of the MiniEngine and because it has quite a few layers of abstraction it isn't very much plug and play...
I copy pasted it all together and somehow made it work. It is quite far away from the MiniEngine code and absolutely not the way to do it, but it is something to get started with that should mostly just work, as everything needed is in one place:

//_mipMapTextures is an array containing texture objects that need mipmaps to be generated. It needs a texture resource with mipmaps in D3D12_RESOURCE_STATE_PIXEL_SHADER_RESOURCE state.
//Textures are expected to be POT and in a format supporting unordered access, as well as the D3D12_RESOURCE_FLAG_ALLOW_UNORDERED_ACCESS set during creation.
//_device is the ID3D12Device
//GetNewCommandList() is supposed to return a new command list in recording state
//SubmitCommandList(commandList) is supposed to submit the command list to the command queue
//_mipMapComputeShader is an ID3DBlob of the compiled mipmap compute shader
void D3D12Renderer::CreateMipMaps()
{
	//Union used for shader constants
	struct DWParam
	{
		DWParam(FLOAT f) : Float(f) {}
		DWParam(UINT u) : Uint(u) {}

		void operator= (FLOAT f) { Float = f; }
		void operator= (UINT u) { Uint = u; }

		union
		{
			FLOAT Float;
			UINT Uint;
		};
	};

	//Calculate heap size
	uint32 requiredHeapSize = 0;
	_mipMapTextures->Enumerate<D3D12Texture>([&](D3D12Texture *texture, size_t index, bool &stop) {
		if(texture->mipMaps > 1)
			requiredHeapSize += texture->mipMaps - 1;
	});

	//No heap size, means that there was either no texture or none that requires any mipmaps
	if(requiredHeapSize == 0)
	{
		_mipMapTextures->RemoveAllObjects();
		return;
	}

	//The compute shader expects 2 floats, the source texture and the destination texture
	CD3DX12_DESCRIPTOR_RANGE srvCbvRanges[2];
	CD3DX12_ROOT_PARAMETER rootParameters[3];
	srvCbvRanges[0].Init(D3D12_DESCRIPTOR_RANGE_TYPE_SRV, 1, 0, 0);
	srvCbvRanges[1].Init(D3D12_DESCRIPTOR_RANGE_TYPE_UAV, 1, 0, 0);
	rootParameters[0].InitAsConstants(2, 0);
	rootParameters[1].InitAsDescriptorTable(1, &srvCbvRanges[0]);
	rootParameters[2].InitAsDescriptorTable(1, &srvCbvRanges[1]);

	//Static sampler used to get the linearly interpolated color for the mipmaps
	D3D12_STATIC_SAMPLER_DESC samplerDesc = {};
	samplerDesc.Filter = D3D12_FILTER_MIN_MAG_LINEAR_MIP_POINT;
	samplerDesc.AddressU = D3D12_TEXTURE_ADDRESS_MODE_CLAMP;
	samplerDesc.AddressV = D3D12_TEXTURE_ADDRESS_MODE_CLAMP;
	samplerDesc.AddressW = D3D12_TEXTURE_ADDRESS_MODE_CLAMP;
	samplerDesc.MipLODBias = 0.0f;
	samplerDesc.ComparisonFunc = D3D12_COMPARISON_FUNC_NEVER;
	samplerDesc.MinLOD = 0.0f;
	samplerDesc.MaxLOD = D3D12_FLOAT32_MAX;
	samplerDesc.MaxAnisotropy = 0;
	samplerDesc.BorderColor = D3D12_STATIC_BORDER_COLOR_OPAQUE_BLACK;
	samplerDesc.ShaderRegister = 0;
	samplerDesc.RegisterSpace = 0;
	samplerDesc.ShaderVisibility = D3D12_SHADER_VISIBILITY_ALL;

	//Create the root signature for the mipmap compute shader from the parameters and sampler above
	ID3DBlob *signature;
	ID3DBlob *error;
	CD3DX12_ROOT_SIGNATURE_DESC rootSignatureDesc;
	rootSignatureDesc.Init(_countof(rootParameters), rootParameters, 1, &samplerDesc, D3D12_ROOT_SIGNATURE_FLAG_ALLOW_INPUT_ASSEMBLER_INPUT_LAYOUT);
	D3D12SerializeRootSignature(&rootSignatureDesc, D3D_ROOT_SIGNATURE_VERSION_1, &signature, &error);
	ID3D12RootSignature *mipMapRootSignature;
	_device->CreateRootSignature(0, signature->GetBufferPointer(), signature->GetBufferSize(), IID_PPV_ARGS(&mipMapRootSignature));

	//Create the descriptor heap with layout: source texture - destination texture
	D3D12_DESCRIPTOR_HEAP_DESC heapDesc = {};
	heapDesc.NumDescriptors = 2*requiredHeapSize;
	heapDesc.Type = D3D12_DESCRIPTOR_HEAP_TYPE_CBV_SRV_UAV;
	heapDesc.Flags = D3D12_DESCRIPTOR_HEAP_FLAG_SHADER_VISIBLE;
	ID3D12DescriptorHeap *descriptorHeap;
	_device->CreateDescriptorHeap(&heapDesc, IID_PPV_ARGS(&descriptorHeap));
	UINT descriptorSize = _device->GetDescriptorHandleIncrementSize(D3D12_DESCRIPTOR_HEAP_TYPE_CBV_SRV_UAV);

	//Create pipeline state object for the compute shader using the root signature.
	D3D12_COMPUTE_PIPELINE_STATE_DESC psoDesc = {};
	psoDesc.pRootSignature = mipMapRootSignature;
	psoDesc.CS = { reinterpret_cast<UINT8*>(_mipMapComputeShader->GetBufferPointer()), _mipMapComputeShader->GetBufferSize() };
	ID3D12PipelineState *psoMipMaps;
	_device->CreateComputePipelineState(&psoDesc, IID_PPV_ARGS(&psoMipMaps));


	//Prepare the shader resource view description for the source texture
	D3D12_SHADER_RESOURCE_VIEW_DESC srcTextureSRVDesc = {};
	srcTextureSRVDesc.Shader4ComponentMapping = D3D12_DEFAULT_SHADER_4_COMPONENT_MAPPING;
	srcTextureSRVDesc.ViewDimension = D3D12_SRV_DIMENSION_TEXTURE2D;

	//Prepare the unordered access view description for the destination texture
	D3D12_UNORDERED_ACCESS_VIEW_DESC destTextureUAVDesc = {};
	destTextureUAVDesc.ViewDimension = D3D12_UAV_DIMENSION_TEXTURE2D;

	//Get a new empty command list in recording state
	ID3D12GraphicsCommandList *commandList = GetNewCommandList();

	//Set root signature, pso and descriptor heap
	commandList->SetComputeRootSignature(mipMapRootSignature);
	commandList->SetPipelineState(psoMipMaps);
	commandList->SetDescriptorHeaps(1, &descriptorHeap);

	//CPU handle for the first descriptor on the descriptor heap, used to fill the heap
	CD3DX12_CPU_DESCRIPTOR_HANDLE currentCPUHandle(descriptorHeap->GetCPUDescriptorHandleForHeapStart(), 0, descriptorSize);

	//GPU handle for the first descriptor on the descriptor heap, used to initialize the descriptor tables
	CD3DX12_GPU_DESCRIPTOR_HANDLE currentGPUHandle(descriptorHeap->GetGPUDescriptorHandleForHeapStart(), 0, descriptorSize);

	_mipMapTextures->Enumerate<D3D12Texture>([&](D3D12Texture *texture, size_t index, bool &stop) {
		//Skip textures without mipmaps
		if(texture->mipMaps <= 1)
			return;

		//Transition from pixel shader resource to unordered access
		commandList->ResourceBarrier(1, &CD3DX12_RESOURCE_BARRIER::Transition(texture->_resource, D3D12_RESOURCE_STATE_PIXEL_SHADER_RESOURCE, D3D12_RESOURCE_STATE_UNORDERED_ACCESS));

		//Loop through the mipmaps copying from the bigger mipmap to the smaller one with downsampling in a compute shader
		for(uint32_t TopMip = 0; TopMip < texture->mipMaps-1; TopMip++)
		{
			//Get mipmap dimensions
			uint32_t dstWidth = std::max(texture->width >> (TopMip+1), 1);
			uint32_t dstHeight = std::max(texture->height >> (TopMip+1), 1);

			//Create shader resource view for the source texture in the descriptor heap
			srcTextureSRVDesc.Format = texture->_format;
			srcTextureSRVDesc.Texture2D.MipLevels = 1;
			srcTextureSRVDesc.Texture2D.MostDetailedMip = TopMip;
			_device->CreateShaderResourceView(texture->_resource, &srcTextureSRVDesc, currentCPUHandle);
			currentCPUHandle.Offset(1, descriptorSize);

			//Create unordered access view for the destination texture in the descriptor heap
			destTextureUAVDesc.Format = texture->_format;
			destTextureUAVDesc.Texture2D.MipSlice = TopMip+1;
			_device->CreateUnorderedAccessView(texture->_resource, nullptr, &destTextureUAVDesc, currentCPUHandle);
			currentCPUHandle.Offset(1, descriptorSize);

			//Pass the destination texture pixel size to the shader as constants
			commandList->SetComputeRoot32BitConstant(0, DWParam(1.0f/dstWidth).Uint, 0);
			commandList->SetComputeRoot32BitConstant(0, DWParam(1.0f/dstHeight).Uint, 1);
			
			//Pass the source and destination texture views to the shader via descriptor tables
			commandList->SetComputeRootDescriptorTable(1, currentGPUHandle);
			currentGPUHandle.Offset(1, descriptorSize);
			commandList->SetComputeRootDescriptorTable(2, currentGPUHandle);
			currentGPUHandle.Offset(1, descriptorSize);

			//Dispatch the compute shader with one thread per 8x8 pixels
			commandList->Dispatch(std::max(dstWidth / 8, 1u), std::max(dstHeight / 8, 1u), 1);

			//Wait for all accesses to the destination texture UAV to be finished before generating the next mipmap, as it will be the source texture for the next mipmap
			commandList->ResourceBarrier(1, &CD3DX12_RESOURCE_BARRIER::UAV(texture->_resource));
		}

		//When done with the texture, transition it's state back to be a pixel shader resource
		commandList->ResourceBarrier(1, &CD3DX12_RESOURCE_BARRIER::Transition(texture->_resource, D3D12_RESOURCE_STATE_UNORDERED_ACCESS, D3D12_RESOURCE_STATE_PIXEL_SHADER_RESOURCE));
	});

	//Close and submit the command list
	commandList->Close();
	SubmitCommandList(commandList);

	_mipMapTextures->RemoveAllObjects();
}

This is the compute shader code:

Texture2D<float4> SrcTexture : register(t0);
RWTexture2D<float4> DstTexture : register(u0);
SamplerState BilinearClamp : register(s0);

cbuffer CB : register(b0)
{
	float2 TexelSize;	// 1.0 / destination dimension
}

[numthreads( 8, 8, 1 )]
void GenerateMipMaps(uint3 DTid : SV_DispatchThreadID)
{
	//DTid is the thread ID * the values from numthreads above and in this case correspond to the pixels location in number of pixels.
	//As a result texcoords (in 0-1 range) will point at the center between the 4 pixels used for the mipmap.
	float2 texcoords = TexelSize * (DTid.xy + 0.5);

	//The samplers linear interpolation will mix the four pixel values to the new pixels color
	float4 color = SrcTexture.SampleLevel(BilinearClamp, texcoords, 0);

	//Write the final color into the destination texture.
	DstTexture[DTid.xy] = color;
}

Essential things to understand when getting started with D3D12

I had a very hard time understanding descriptors, descriptor heaps and the root signature btw.
Turns out that the root signature has to somewhat fit the shader and describes the shader uniform, texture and sample data. Descriptors, which are also called "views", such as "shader resource views" (SRV), "constant buffer views" (CBV) and "unordered access views" (UAV) and don't have much to do with "Descriptors" such as D3D12_RESOURCE_DESC, but instead tell the root signature where to find the data to be used in the shader. They happen to be allocated on a descriptor heap and since it is not recommended to switch the heap all the time, should all be known before the command list is generated. And then instead of switching the heap, a handle to the elements to use on the heap can be changed all the time. That last part is done with SetComputeRootDescriptorTable, but it is also possible to directly set a limited amount constants. For a bit more context of what I am saying, just look at my code above, as it needs all this.

Edit: Since gamma correct rendering is the right thing to do, I found out that the above code does not work for srgb texture formats as unordered access is not available for those. I solved it by copying my srgb resource into a none srgb resource (rgba_8888_srgb can for example be copied into a rgba_8888 resource) using commandList->CopyResource(dest, src). One issue with this approach is that the mipmap generation is happening in gamma space. I solved it by sampling the four pixels individually and applying a gamma curve using pow(color, 2.2) on the four samples, averaging them and transforming them back into gamma space using the inverse (pow(color, 1.0/2.2)).
Also the above code does not clean up the resources it created. The tricky part is releasing them once they are not needed by the GPU anymore, which is not at the end of the function, but somewhen later. An easy solution would be to submit the command list to the queue and wait for it to finish. The solution I am using is a global fence that is checked every frame and if it is bigger than the one for the frame the command list generating the mipmaps was generated for, a callback on the command list ist called. That callback can then safely release the resources.

About half a year ago I ordered a ticket for Elbriot, which is a small metal festival in the middle of Hamburg. It used to be just one day, but was turned into a two day festival this year with bands such as Sabaton and Slayer playing. I was really looking forward to it.

But then in June another Innogames Gamejam was announced. Bigger, better, Gamescom. The idea was to have a gamejam in one of the big congress halls above the Gamescom during the first three days of the Gamescom. The 50€ ticket included a Gamescom ticket for the three days, the possibility to sleep there and food. So all in all a really nice deal and thanks to founding from Intel and other sponsors they flew in people from all over the world.

Of course I immediately registered :D

Travelling and first day

I travelled by train and got there a day early in the middle of the day and got a cheap room in some hostel close to the Köln Messe (Which all together was still cheaper than the early train on Wednesday).

We were supposed to get our tickets at the Gamescom at 10, so I arrived at 9:20 or something and had to wait until 10... Together with lots of others. It would have been nice if we could have gotten in earlier, but I guess they had their reasons.
I suck at talking to people I don't know, so I was just waiting and eventually got my ticket. Unfortunately they were still preparing the hall for us and didn't let us in, but were nice enough to allow us to drop off our things. I somehow ended up talking to two turkish and a french guy and we decided to take a short tour around the gamescom until the gamejam started.
We lost the french guy somewhere (he told us to go on while he was checking out some booth).

We didn't really get to see anything in these 1.5h but had a good idea of what was were. When we made it back to the location of the Gamejam they let us in and being Artist, Gamedesigner and Programmer we decided to be a team.

At some point there was another Gamedesigner and another Programmer interested in helping us, but I scared them away with my choice of SFML... So in the end we were a team of three people.

There was a keynote in the beginning of the jam by Adriel Wallick, which had it's moments, but in my opinion could have been a bit shorter.
Then the theme was announced: Masks

The organisers tried some get to know you games, which weren't too bad, but not really my thing either -.- A nice touch was them trying to split up existing teams of people knowing each other into new teams by having everyone talk to anyone with similar game choices, which seemed to have worked pretty well.
I sticked to my small team anyways but was still trying to find another programmer that didn't only want to do Unity. I failed.

Being the press day of the gamescom it was the only day with the possibility to get to see a few games with less than an hour of waiting. I also had a Sony VR presentation scheduled at 16:30. We took something to write and found a first line to stand in and brainstorm some ideas. This was actually a great idea, but unfortunately the line was too long so I had to leave early for my appointment at sony... When I got back the others finally made to the game and got to play for a really long time. I decided to walk around some more and catched an underwhelming presentation of Mafia 3 (I love the series and I am sure the game will be great. But the presentation wasn't...). Also Playstation VR reminds me a lot of the Oculus DK2, but with lots of interesting adjustments to be made to the headset. If the games are good (and some will be) it makes a solid VR headset.

At this point the gamescom was almost over and we went back to the jam. Somehow we finally came up with an idea for a local multiplayer game.
Then we got dinner which turned out not to be enough for everyone so additionally some pizzas were ordered.
They did learn from it for the next day. But in general the food and drink situation could have been better.

Making the game

Engin, our Gamedesigner was figuring out gameplay details and Can, the artist made some placeholders for me. Then they both went to bed early and I stayed up until 4:30 to get an earlier prototype working. Based on the good experience with Huitzilopochtly I used SFML and Box2D again and was able to reuse some of the basic code I wrote before. In the end it was possible to move around and throw masks.

I got up for breakfast at 9 (I slept behind our table on my very comfortable new sleeping mat with earplugs), Can and Engin were already doing things.
I spent the day implementing the intended mask bahviour and had something fully working an hour after the playtesting on the stage ended in the evening...
By then I also had most of the graphics.

The last night was used for a start screen and sounds and I even made OSX and Windows builds of the game as a test run and finally decided to sleep at 6:30.
Getting up again at 9 was hard, but being the only programmer I didn't really expect to sleep at all and it was enough to get me through the day.
This time the others also stayed up as long as I did, working on additional graphics and improving the start screen.

In the morning I implemented a game over screen and animations for everything. And made Windows and OSX builds. Since we still had 10 minutes until the deadline I spent those adding better transitions between screens and a control screen in the beginning and was done 5 minutes late :D.

The end

The judges were running around and testing the games. I think three actually saw our game and have no idea if that's how it was supposed to be or if there should have been more...
We also managed to crash the game a couple of times when playing ourselves, fortunately it worked for others.
There was an award show in the evening at 7. Unfortunately I had to catch my train by then. I am pretty sure we didn't win anything, but I also don't know who did.

I spent Saturday at the Elbriot, which was also nice :D.

Media

This is us on the second evening...

A short gameplay video of the game.

It can be downloaded on the Gamejam page: Maskplosion

You can also find the other games there.

I own an Ultimaker 2 and upgraded it with the Olsson Block which is a custom heater block that allows for easy nozzle switching.
I used Cura as slicer in the past, but switched to Simplify3D. Simplify3D is faster than Cura (but speed with Cura isn't a problem either) and the slicing quality is better most of the time. Comparing overhangs with both slicers those from Simplify3D just turn out better and it has a great manual support feature. But the default settings seem to have some retraction issues with my printer and just changing the layer height can cause the parts to be extremely weak.
I also setup a Raspberry Pi with OctoPrint and connected a webcam to it. This allows me to monitor a print even if I am not around my printer, so if anything is wrong I can just cancel the print and don't waste a lot of filament. I also attached a servo to my printers on/off switch to remotely turn it on and off.

Materials

While PLA and ABS are the two most common materials in fused deposition modeling, there are a couple of different filament manufacturers with their own takes on materials with different properties.
So far I experimented with PLA, ABS, colorFabb XT and colorFabb CF20.

PLA

PLA has a low melting point (~160°C) and a low glass transition temperature (~60°C) which makes it very easy to print but not suitable for applications were it can get hot (>55°C). It also isn't very stiff and somewhat soft.
In my experience it is hard to do anything wrong with PLA, it just always turns out well and is what my current quadcopter prototype is made of.
I am printing this at 215°C and directly on my build plate at 60°C

ABS

ABS has a much higher melting point (~230°C) and glass transition temperature (~100°C) than PLA.
While these are useful properties for some applications it also makes it harder to print. The main issue I have been having was keeping it fixed on the build plate. Just like everything else, it gets a bit smaller when cooling down, but with the higher temperatures it cools down a lot faster than PLA and pulls it off the build plate. What helps is a higher room temperature and a hotter build plate. A brim is also useful. Some people encase their printers to keep the heat in.
What works for me is turning the heaters on to the maximum, a print temperature of 260° and the build plate at 115°.
My prints didn't turn out perfect, but good enough to use.

colorFabb XT

I think he idea of this is to find a middle way between the properties of ABS and the ease of use of PLA.
The problems are similar to those with ABS, but printing it at similar settings turns out much nicer.

colorFabb CF20

This is the material I would like to use for my quadcopter in the future. It contains 20% carbon fiber and is a lot stiffer than the other materials I tried.
Printing is again at similar settings to ABS. The main problem I have with it is that it likes to stick to the nozzle and build a blobb which then at some point ends up in the print somewhere. This can be acceptable, but sometimes happens to be in critical spots...
Also this one is known for destroying nozzles, so a hardened steel nozzle should be used.

Printing

My current parts are all printed in PLA at a layer height of 0.15mm with Simpify3Ds default speed settings. Most of the frame is using 30% infill, except for the parts the motors are mounted on which use 100% infill. I found out that at 30% they start vibrating extremely, while at 100% there are only very little vibrations.
For this part and the arms I am using a brim because some areas of these don't stick to the build plate without.
Most important for parts sticking to the build plate is to keep the build plate clean. I am cleaning it with spiritus based glass cleaner before each print and it makes a big difference.

I am not exactly great at this whole thing and I am constantly trying to improve things, so this is based on my design at the time of writing which is the result of a lot of trial and error.
I should probably be using a nice CAD tool, but I am not exactly familiar with any so my tool of choice is Blender.
The focus of my design is printability and functionality.
Most important for printability is to avoid overhangs as much as possible because the usually don't turn out as well as you'd wish, even with supports which need to be removed once printing is done and usually require some additonal sanding.

Designing the body

Since the batterie is the biggest and heaviest part, I started my design with that and went from there. But since I got differently sized batteries I also need a way that supports different sizes.
My result looks like this:

The two lower parts are glued together and hold the batterie. The lowest part can be printed in different sizes for different batteries and should hold it tightly. The holes are in there to get air close to the batterie in case it gets warm.
The lower parts together slide into the top part and are held in place by the stick.
The top part can have several slots for the stick to support the different batterie cases.
The center part has some guides for the lower part to make the glueing easier.

This is my printed result for the small batterie:

Designing the arms

Important for the arm length is that the propellers don't touch! PLA but even material with carbon fiber is not perfectly stiff so you should also keep some additional distant between the motors.

The resulting arm length can be calculated with pythagoras (and then some transformations): (radius*2+safety)/sqrt(2) = length

My propellers have radius of 12.5cm, I decided on 8cm space for safte: (12.5*2+8)/sqrt(2) = 33/sqrt(2) = ~24cm

The arms turned out to be a bit longer than that in the end, but I used this as my minimum.

The blue part has holes to fit the scrows for the motor and slides into the actual arm. Both can be held together with a nail or something fitting the small hole at the side of both parts.

The arm has some guides for the cables and space for the ESC:

Because the connection between the blue part and the arm works very well I started out with a similar approach to connect the arm to the body, but for several different reasons it didn't really work out. And while I did print a somewhat working quadcopter with that design and a lot of glue, at some point one of the arms broke off and gave up on my tries to fix it. Instead I changed the connection design:

It turned out to be very stable, but the print quality needs to be high otherwise things won't slide together well and one or both parts will break. Some sanding can also help improve the situation.

Putting the edison on top of everything

I modeled a simple case for the edison, but didn't print it yet, so it may or may not do the job... It does allow for a bit of airflow around the edison which will be facing the bottom of the case because I will have the spark fun display block at the top.

The two highlighted parts will be glued together.

The current state of my quadcopter

It is only missing two more arms, which are half way through printing while I write this. Printing two arms at once takes about 9h at my current print settings. And of course the edison case is also missing, but I'll hopefully get to that in the next few days.
On the coding side I managed to get some controls working to keep the quadcopter to hold its orientation, but I still need to find some good values to make it work with the real thing.
I also experimented printing with carbon fiber filament and plan to replace some of the quadcopter parts with it, but printing it well is a lot harder than with PLA.

Some older photos

Iterations on the arm design, oldest on top, latest not there ;)

The stupid old connection

Two arms with motor and ESC

The whole thing

Somewhat flying...

The Afro ESC supports different ways of communication (PWM, I2C, UART), but PWM is most common for these and those pins are nicely exposed with a JR-Style Servo cable.

The Edisons PWM block did just have the pins exposed as some holes, so I got cables with the counter part (based on the form of the actual contacts, the ESCs have female connectors, so I needed male ones, but based on the overal form of these it would be the other way around, and both ways are sometimes used...).
I soldered those cables to the board and connected a jumper for it to use the system voltage to power the PWM, otherwise I would have had to connect an additional power source to the PWM board.

Also these ESCs have a BEC exposed via the same cable, which is unless otherwise stated a 5V source which can be used to power things. In my case it provides a current of up to 500mA, which causes this to be perfectly within the USB specifications.
The BEC is between the red and brown cable coming from the ESC, while the PWM signal will need the orange and the brown cable. Thus I did not attach the red cable to the Edison via the PWM block but instead cut a micro USB cable in half and attached the BEC of one of the ESCs to the USB cable and plugged it into the Edisons base block to power it with. I didn't not use the power block or anything because the Edison does not support full 5V, but the baseblock does some magic to make it work with USBs 5V.

Talking to the ESCs

PWM or pulse width modulation works by sending a high signal for some amount of time and the receiver measures how long the high signal was sent and knows what to do based on that time.
A high signal is anything above 1.5V or something for most of the RC stuff.
In general in the RC world the high signal (or pulse) has a length of around 1ms to indicate a minimum value (the motor does not rotate/the servo gets rotated to its lowest position) and a length of about 2ms for the highest value (motor at full speed/servo fully rotated). Looking at the sparse documentation of these ESCs I found a lowest value at 1060μs and the value for full power at 1860μs.

Mostly for safety reasons ESCs usually don't allow to start with a rotation, instead wait for an arm value which is something below the minimum value and once that was sent at least one time a speed can be provided.
I used an arm value of about 1000μs but it can also be somewhat smaller and bigger.

The signal needs to be sent constantly though. Any frequency higher than 20Hz or so works, but due to the way some ESCs work there is a habit of sending at much higher frequencies. Just keep in mind that to send a 2ms signal you can't go faster than 1s/2ms = 500Hz. I am currently sending at around 400Hz.

PCA9685

That is the PWM controller used by the Sparkfun block. It is made for dimming LEDs, but also works for other usecases...
It supports 24Hz up to 1526Hz, communicates via I2C and has a 12bit resolution of 4096 steps.
The 12 bit resolution means that when for example operating at 100Hz the resulting 10ms (1s/100) are split into 4096 evenly spaces parts and the pulse length has to be a multiple of 10ms/4096 = ~0.0024ms.
And instead of sending a time to the PWM controller, it expects a number of steps. The PWM controller then scales this with the value it knows based on what its pre scale register is set to. This same pre scale register also sets the signal frequency.

The code

Fortunately Sparkfun provides some code for the PWM block which takes care of the I2C communication and provides some functions to set stuff (but none takes a time directly...).

So far I just wrote some very minimalistic wrapper over their code initializing everything with what they provide as "servo-mode", set a higher frequency (prescaler to 14 for ~400Hz) and then send an arm signal.
Once that is done a speed as value between 0 and 1 can be set for each motor.

I thought I figured out the math for the correct timings, but it turned out that the actual number of steps was quite different, so my math was probably wrong...
I found those by trial and error (prescaler 14):
Arm - 1730
Minimum - 1960
Maximum - 3500

The code is on github.

My toolchain

The Edison runs Yocto in the latest version for it provided by Intel.
I am connecting to it via SSH over Wifi and compile directly on it using GCC.
My IDE of choice is CLion which bases it's projects on CMake and has a feature to directly transfer the files to a server which in my case is via sftp to the Edison.
I plan on improving it by adding custom build configurations running the same stuff I currently use the terminal for, but I am not sure if that will really make anything better...

Profit!