next »

[oahda]

However, both of these completely killed the FPS (might be because I generated the kernels every frame for every fragment…

Are you passing the kernel fragments from the vertex shader? I've read that this is faster than accessing them directly in the fragment shader because the driver can optimize the texture access, which is usually a costly operation. Also, applying a 5x5 kernel blur multiple times will have the same results as a one-time blur with a larger kernel and might end up being faster.

Yeah, obviously in reality I would just generate the kernel ones and perhaps even just generate a lookup table once in C++ and then pass that into the shader or something.

I didn't apply anything more than once.

[zilluss]

I don't understand what you mean by lookup table, but from my tests I can say statically sized kernels (and static texture lookups) increase performance greatly. I tried to pass the kernel as an uniform, but the performance was still bad. It might even be better to generate multiple shaders with variable kernel size from C++, but I didn't try it. Instead I created one static 5x5 blur that I applied over and over. As a bonus it gave me a nice "fade in" effect, as can be seen here.

[oahda]

Oh, neat!

[BorisTheBrave]

Yeah, I'd have thought kernels would look like this in the shader:

Code:

vec4 result = vec4(0);
result += textureOffset(tex, p, ivec2(-1,-1)) * 1 / 16.0;
result += textureOffset(tex, p, ivec2( 0,-1)) * 2 / 16.0;
result += textureOffset(tex, p, ivec2( 1,-1)) * 1 / 16.0;
result += textureOffset(tex, p, ivec2(-1, 0)) * 2 / 16.0;
result += textureOffset(tex, p, ivec2( 0, 0)) * 4 / 16.0;
result += textureOffset(tex, p, ivec2( 1, 0)) * 2 / 16.0;
result += textureOffset(tex, p, ivec2(-1, 1)) * 1 / 16.0;
result += textureOffset(tex, p, ivec2( 0, 1)) * 2 / 16.0;
result += textureOffset(tex, p, ivec2( 1, 1)) * 1 / 16.0;

As you are unlikely to want a kernel larger than 11x11, it doesn't take long to whip up enough shaders to play with.

[oahda]

That's exactly how I did my first test!

[zilluss]

I see, I mixed something up. I don't fetch the texture in the vertex shader (as that's not possible) but calculate the final texture coordinates. I don't know of the performance of textureOffset vs. texture2D (with precalculated UV coordinates), since my shader is supposed to work on OpenGL ES 2.0 which doesn't have textureOffset. But I read that at least some implementations can optimize texture access with pre-calculated texture coordinates. Enough talk, heres my implementation (uBlurdirection tells the shader if it's a horizontal/vertical pass)

Vertex Shader:

Code:

attribute vec4 a_position;
attribute vec2 a_texCoord;

uniform vec2 u_textureSize;
uniform vec2 u_blurDirection;

varying vec2 v_blurCoords[5];

void main()
{
    gl_Position = CC_MVPMatrix * a_position;
    
    vec2 pixelDistance = 1. / u_textureSize;
    v_blurCoords[0] = a_texCoord + (2. * u_blurDirection * pixelDistance);
    v_blurCoords[1] = a_texCoord + (1. * u_blurDirection * pixelDistance);
    v_blurCoords[2] = a_texCoord;
    v_blurCoords[3] = a_texCoord - (1. * u_blurDirection * pixelDistance);
    v_blurCoords[4] = a_texCoord - (2. * u_blurDirection * pixelDistance);
}

Fragmen shader

Code:

uniform sampler2D CC_Texture0;
varying vec2 v_blurCoords[5];

void main (void)
{
    vec3 resultColor = vec3(0.,0.,0.);
    
    resultColor += 0.093913 * texture2D(CC_Texture0, v_blurCoords[0]).rgb;
    resultColor += 0.304005 * texture2D(CC_Texture0, v_blurCoords[1]).rgb;
    resultColor += 0.204164 * texture2D(CC_Texture0, v_blurCoords[2]).rgb;
    resultColor += 0.304005 * texture2D(CC_Texture0, v_blurCoords[3]).rgb;
    resultColor += 0.093913 * texture2D(CC_Texture0, v_blurCoords[4]).rgb;
    
     gl_FragColor = vec4(resultColor, 1.);
}

[oahda]

Oh, and I guess that speeds things up anyhow since nothing has to be recalculated for every vertex.

[J-Snake]

J-Snake this is completely unrelated, but your avatar is broken. Just thought I'd mention it.

Don't know what's up with that. This problem occured before but then got fixed by itself after a while. The avatar was set up few years ago and I haven't touched it ever since.

[darkhog]

I'm very happy of my progress with level loading in Computer Virus Simulator. It is surprisingly easy as I can reuse much (almost all) code initially created for loading levels in level editor. Having written it initially with the fact that I will need in-game level loading helped as well.

[oahda]

Got everything set up for deferred rendering like yesterday. Thought something was wrong with my OpenGL setup (specifically that GLSL locations or multiple render targets) wasn't working for hours and it turned out to be a uniform name that I had miswritten. I double checked once and apparently decided nothing was wrong with it, so I didn't go back to check it again until I had no ideas left... Bit annoying, but at the same time very happy to finally have gotten it working.

Now I've just been too lazy to reärrange the shaders since that... But it's working!

[bauer]

Managed to quickly integrate all our Lua code into the executable.

The way I did it was:
1) Start with the boot.lua file and recursively traverse required files, to build up a dependency list with all lua files in the order of inclusion
2) In the order of the dependency list, write the full content of each Lua file into a package.preload[filename] chunk inside a giant lua file (containing all the Lua files)
3) Use LuaJit to create a C header with the contents of the giant Lua file
4) In C code, initialize the Lua state with the contents of the header file, and then run as usual

Was much easier than I had initially thought and works great for release builds!

[darkhog]

Turns out that implementing wander AI for basic enemy in my game isn't as hard as I've thought!

(said before implementing hardest things like wander AI and omitting obstacles).

[InfiniteStateMachine]

F# is pretty fun

[gimymblert]

Distance field is super fun and easy

[InfiniteStateMachine]

So I'm now at the point in functional language where I'm now functional (that's right I said it).

I think one of my favorite things I've learned from this is pattern matching. If I were to make some type of game data editor I'd be tempted to do all the data processing in f# and the gui in c#. That said, at least C# has linq which can function like pattern matching (albeit it's a bit less elegant).

[gimymblert]

[gimymblert]

Distance field is like the matrix, you write a code to make cube, but in fact the cube does not exist, you try to change its dimension and it's distort because it's not a cube. Super fun, super easy.

Now let me jitter the cubes positions without deforming it

[kverkagambo]

I made some animations in the card selection screen and felt happy about it.

[pelle]

Nice, but the way the cards overlap together with the military theme makes my brain see swaztikas, which might be a bit unfortunate (or theme-appropriate perhaps, depending on what game that is).

[oahda]

I can't see any even if I try...