oahda
|
|
« Reply #4220 on: November 06, 2015, 05:05:53 AM » |
|
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.
|
|
|
Logged
|
|
|
|
zilluss
Level 1
|
|
« Reply #4221 on: November 06, 2015, 02:30:19 PM » |
|
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.
|
|
|
Logged
|
|
|
|
oahda
|
|
« Reply #4222 on: November 07, 2015, 12:55:55 AM » |
|
Oh, neat!
|
|
|
Logged
|
|
|
|
BorisTheBrave
|
|
« Reply #4223 on: November 07, 2015, 01:28:43 AM » |
|
Yeah, I'd have thought kernels would look like this in the shader: 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.
|
|
|
Logged
|
|
|
|
oahda
|
|
« Reply #4224 on: November 07, 2015, 02:08:50 AM » |
|
That's exactly how I did my first test!
|
|
|
Logged
|
|
|
|
zilluss
Level 1
|
|
« Reply #4225 on: November 07, 2015, 03:23:20 AM » |
|
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: 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 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.); }
|
|
|
Logged
|
|
|
|
oahda
|
|
« Reply #4226 on: November 07, 2015, 08:54:18 AM » |
|
Oh, and I guess that speeds things up anyhow since nothing has to be recalculated for every vertex.
|
|
|
Logged
|
|
|
|
J-Snake
|
|
« Reply #4227 on: November 07, 2015, 05:51:18 PM » |
|
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.
|
|
|
Logged
|
|
|
|
darkhog
|
|
« Reply #4228 on: November 07, 2015, 07:45:09 PM » |
|
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.
|
|
|
Logged
|
Be a computer virus!I cannot C well, so I stick with simpler languages. There are no impossible things, there is only lack of skill.
|
|
|
oahda
|
|
« Reply #4229 on: November 14, 2015, 02:31:16 PM » |
|
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!
|
|
|
Logged
|
|
|
|
bauer
Level 1
Codes games & makes music
|
|
« Reply #4230 on: November 18, 2015, 04:08:00 AM » |
|
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!
|
|
|
Logged
|
|
|
|
darkhog
|
|
« Reply #4231 on: November 25, 2015, 08:30:11 PM » |
|
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).
|
|
|
Logged
|
Be a computer virus!I cannot C well, so I stick with simpler languages. There are no impossible things, there is only lack of skill.
|
|
|
|
gimymblert
|
|
« Reply #4233 on: December 06, 2015, 10:07:38 PM » |
|
Distance field is super fun and easy
|
|
|
Logged
|
|
|
|
InfiniteStateMachine
|
|
« Reply #4234 on: December 07, 2015, 11:44:52 AM » |
|
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).
|
|
|
Logged
|
|
|
|
gimymblert
|
|
« Reply #4235 on: December 07, 2015, 01:58:29 PM » |
|
|
|
|
Logged
|
|
|
|
gimymblert
|
|
« Reply #4236 on: December 07, 2015, 08:00:46 PM » |
|
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
|
|
|
Logged
|
|
|
|
kverkagambo
|
|
« Reply #4237 on: December 30, 2015, 05:55:20 AM » |
|
I made some animations in the card selection screen and felt happy about it.
|
|
|
Logged
|
|
|
|
pelle
|
|
« Reply #4238 on: January 08, 2016, 02:30:31 AM » |
|
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).
|
|
|
Logged
|
|
|
|
oahda
|
|
« Reply #4239 on: January 08, 2016, 04:15:25 AM » |
|
I can't see any even if I try...
|
|
|
Logged
|
|
|
|
|