An Update

So I havn’t written onto this blog for a while, and there’s quite good reasons for that.

I realized that my engine ran poorly in terms of performance, so I decided to rewrite it, took about 2 weeks to do so, and I’m much more happy with the result, even though not everything is in place, such as the physics system is a bit bugged out, not too much though, but graphically it’s much better, following the footsteps of physically based shading.

And the 2nd reason is that my PC died, the processor was somehow damaged, but I suspect that I was actually given a “broken” pc from the start, as the symptons started early on. So it’s been hard finding any time to program, as I’m currently using an older that does not have support for the newer versions of Directx, which blocks my development for my engine.

Although it’s not because I havn’t been programming at all, I’ve been using my brother desktop for programming when he’s not using it, but he’s rarely away from it, for one reasons, it’s powerful as hell, even though I assembled and selected the parts for it.

And the exams are coming up, which means that I wont have a lot of time for programming or anything close to that, though after the exam period I’m going to resolve the no pc situation.

C++ – The auto key word

A funny remark  which I discovered without realizing it ( Though I’m not the first one… ), is that the auto keyword can be used to access public members with private types, as so:

#include <iostream>
using namespace std;

class FooClass
    struct PrivateFoo
        bool m_bFoo;

    PrivateFoo m_Foo;

int main()
   FooClass foo;

   // The following code will produce an error,
   // you can't access the private type FooClass::PrivateFoo
   FooClass::PrivateFoo* fooPtr = &foo.m_Foo;

   // But this works
   auto fooPtrAuto = &foo.m_Foo;

   // Nothing fancy

   return 0;

So as you know, I can’t use the type PrivateFoo directly, because it’s declared as private, but the auto keyword is permitted, even though it detects the type needed and, well, uses it. I see why is technically is permitted, but, logically, it doesn’t give any sense for me, though it might be usable.

BRDF Shading – Cuboid Engine

So lately I’ve been going around optimizing stuff and implementing new cool features. And I’ve also been going around making things more flexible and removing old deprecated things, which is always good. And, one vital thing, is that I discovered that my blurring shaders we’re extremely heavy, therefore I’m now rendering them in 1/4th of the screens size, increasing performance in a mid heavy scene, from 30 to 50-60 fps.

I’ve never really been a fan of the prebaked lens flares, but then I found this amazing person, who has this great algorithm for generating them, or close:

And the result from this in my engine were better than I expected, so, overall I’m happy with them.

Now on the more serious note, this BRDF shading is a hot topic, and some of it has to do with being physically accurate, and produce great results. So I’ve been reading a bit here and there, but today I tried to implement them, and I’m really satisfied with the result:

Dragon Example, [ Roughness = 0.2, Roughness = 0.5, Roughness = 1.0 ]

d0_2 d0_5 d1

Plane Example, [ Roughness = 0.15, Roughness = 0.25, Roughness = 1.0 ]

p0-15p0_25  p1

General Example [ Roughness = 0.25, Roughness = 1.0 ]

r0_25 r1


This shading model looks exiting, I’m definitely going to look more into it!

Post Materials

As you know post processing is a vital component in today games. So, what I did is that I’ve added a component to the material parser which acts somewhat like a post processing material, made by the user. It follows the same language as the other materials, just some features are disabled.

The user can:

  • Set Linkers ( Communication between shaders )
  • Send Resources (Like textures [1D, 2D, 3D])
  • Change Vertex Shaders
  • Change Pixel Shaders

The vertex shader is preset to generate a full screen quad, which is changeable by the user if needed. For now it seems to work, I tested it using a simple falloff fog shader, works good so far:

shader "PostFog"
		Info = "Some info";

    // Considered to be global
		Texture2D _tPos;
		Texture2D _tScene;

	pass(cull = false;)
			float dz = 0.001f; // Density
			float3 fcolor = {0.5, 0.5, 0.5};

			float near = 1;
			float far = 10;

			float3 position = _tPos.Sample(ss, input.Tex);
			float3 cen = _tScene.Sample(ss, input.Tex);

			float d = length(position - eyepos);
			float l = saturate((d-near)/(far-near));
			return float4(lerp(cen,fcolor, l),1);

The material is created like the following:

CDK::MaterialPost *post_fog = pEngine->CreateMatPost(CeURL("Materials\\Fog.cs"));
post_fog->SetTexture(pEngine->GetPositionMap(), post_fog->getSlot("_tPos"));
post_fog->SetTexture(pEngine->GetCompositMap(), post_fog->getSlot("_tScene"));
post_fog->SetBlendMode(CDK::Blend::Dominant); // Two kind of blend modes: Additive, Dominant(The output color overwrites)

All that CreateMatPost does is:

CeMatParser<CDK::MaterialPost> *m = new CeMatParser<CDK::MaterialPost>();
m->Bootstrap(dev, Url);
return m;

Optimizations are still on the list!

So yeah, it’s been a productive day! :)

It’s Alive!

The AI in the RTS ( A small game I’m slowly developing on) is working, obviously not finished, all they start with is, one building on each team and some resources, from which they automatically start repopulating from, so right now they’re building houses and warriors. :)


I just thought I’d share some screenshots. :)