Jump to content

  • Log In with Google      Sign In   
  • Create Account

We need your help!

We need 7 developers from Canada and 18 more from Australia to help us complete a research survey.

Support our site by taking a quick sponsored survey and win a chance at a $50 Amazon gift card. Click here to get started!


Member Since 08 Jul 2009
Offline Last Active Aug 13 2012 01:46 PM

Topics I've Started

Achieving oldschool platformer physics

26 July 2012 - 02:10 PM

I am using Box2D, with a world made by arbitrary polygons, and I can't get for the life of me the oldschool platformer feeling.

I am talking about moving at a constant velocity when you press the left/right keys, moving up/down on slopes at exactly the same way as on horizontal surfaces, and simple jumps.

I tried playing with friction, gravity, using impulses or setting velocity directly.

The issue is, no matter what I do, something works physically correct, which isn't really what I want.

If friction is set to 0, and the velocity is set directly (if left is pressed, move left, if right is pressed, move right, if neither is pressed, set to 0), the player moves correctly on horizontal surfaces, but would slip on curves for some reason, jump when stopping to move upwards (still there is still velocity in the Y axis), and jump sideways when starting to move downwards, still gravity doesn't catch up immediately.

If friction is set to 1, and the velocity is set directly (as above), the player doesn't slip from slopes, but still jumps upwards and sideways when stopping to move while going upwards or starting to move while going downwards respectively.
In addition, the payer gets stuck while going against a wall to his sides, but that can be solved by checking if he is in the air or not.

If friction is set to something very high, and I use very large impulses instead, while controlling manually the maximum velocity that the player can get to, then the player can't go up slopes (even the tiniest one) - he just gets stuck in place, and he also moves very fast when in the air (but this, again, can be controlled by checking if the player is in the air or not).

Is there a decent way to get the feeling of old platformers, or is Box2D not suitable for this?


Cleanup at end of program

22 July 2012 - 04:40 PM

Does one need to clean up OpenGL resources when a program finishes?

I can't think of any not-annoying way to clean up global resources in an SFML project, since the window (and thus context) gets destroyed before my resources.

Do they leak to VRAM, or does the context take them with it?

Is there any decent design to delete global resources before a program ends (and before the window is closed)?


Reduce memory output of 2D tile map

01 July 2012 - 01:41 PM

I made a normal 2D tile map code in WebGL some time ago, having 6 vertices consisting of positions and texture coordinates per tile.

The texture coordinates pointed to a specific texture in a dynamically generated texture atlas.

And so, every tile took 96 bytes (12 2D vectors).

This weekend I finally tried instanced rendering in C++, and together with a texture buffer and a texture array, I could render any amount of tiles using merely one byte (index to the texture) per tile, which made the code quite fast, and very small in memory output.

So, I am now thinkig of ways to reduce bandwidth also for pre OpenGL 3 code.

What I have in mind is having a constant matrix in the vertex shader that will hold the four vertex positions that make a unit quad.

Each vertex sent to the shaders, then, will have the tile number it belongs to (32 bits uint), the vertex number in the tile (0, 1, 2 or 3), and the texture number.

The correct vertex position will be selected from the constant matrix;
vec2 position = positiohMatrix[vertexNumber];
With this position two things happen: first, the texture coordinate is set to it, with inversed y value (1 - position.y), and then the tile number is used to move the vertex to its correct place, assuming each tile is one unit, and using a uniform to tell how many tils there are per row.

The texture index and texture coordinate will then move on to the fragment shader.

Here, the correct texture coordinate will be generated using uniforms that tell the size of each texture in the atlas, and then it's a simple texture lookup.

While this should work, each tile is still quite big - 36 bytes (6 per vertex).

I am wondering if someone has better ideas to reduce the memory output.

Thanks :)

Skeletal animation with vertex shader

19 February 2012 - 01:25 PM

So, I finally want to change my slow (relatively) software skeletal animation to reside in a vertex shader.

I created a 2D Wx1 texture containing all the bone matrices (where W is 16 floats per matrix), had to use a 2D texture because I am using WebGL which doesn't support 1D textures.

Each vertex comes with a vec4 of bone indices that point to the appropriate matrix. Currently I set -1 as a "no matrix", since bones might have anything between 1 and 4 bones effecting them.

I am now wondering what would be a decent way to use this in the shader.
As far as I can see, I need to send the shader also the size of the texture in a separate uniform, since a texture fetch takes values in the range [0,1] and I want values in the range [0,number_of_bones].
Once I get to the index, I need to fetch 4 4D vectors to get the matrix columns, and with those construct the actual bone matrix.
To get consecutive vectors, I need to advance the index with the size of one 4D vector converted to the range of [0,1], so 1/(4 * number_of_bones).
Finally, each result of a vertex multiplied by the bone matrix is added to a final position, which is later on divided by the number of bones actually effecting this vertex (I don't know if this is normal, but it's not a format I made for myself so I have to adhere to this).

The following code is a pseudo GLSL code for the above:
float size_of_column = 1 / (4 * number_of_bones); // the size of every vec4 scaled to the range [0,1]
vec3 final_position = vec3(0.0, 0.0, 0.0);
int indices_count = 4;

for (i = 0; i < 4; i++) {
	if (bone_index[i] != -1) {
		float index = bone_index[i] / number_of_bones;
		vec4 column1 = texture2D(bone_texture, index);
		vec4 column2 = texture2D(bone_texture, index + size_of_column);
		vec4 column3 = texture2D(bone_texture, index + 2 * size_of_column);
		vec4 column4 = texture2D(bone_texture, index + 3 * size_of_column);
		mat4 matrix = mat4(column1, column2, column3, column4);
		final_position += matrix * vec4(a_position, 1); // a_position is the original position attribute
	} else {
		indices_count -= 1;

final_position = final_position / indices_count;

Now, I am not even sure if this will work. It sounds like precision issues to me before I even begin writing the real shader, with the texture fetches.

Apart from that, the whole thing looks pretty cumbersome, and a lot more complicated than I would have expected.
I also believe loops are not really supported well on GPUs, no?

On the whole, I really would like to know if this can work (like I said, sounds like precision issues to me, getting values from a range of [0,1] really isn't ideal for arbitrary data), and whether it will actually be faster than doing the same on the CPU. All those texture fetches seem a bit wild (and also creating the texture itself, which is usually between 2 to 4 MB, every frame).

By the way, before you go and tell me to use uniform matrices instead of a texture - I have 60+ bones, and I don't believe older GPUs support that many uniform components. I would like this to be compatible with any WebGL (aka ES2) compatible GPU.


Render fast while keeping data editing easy

13 January 2012 - 11:59 AM

I am making a 2D tile-map based game, and seeing as I tried and thought of many different ways of holding data and rendering, I've finally come here to ask you guys for suggestions.

My problem is like so:
If I make rendering fast, editing the data is slow and painful.
If I make editing data easy, rendering is slow.

I started with the second approach some long time ago (in another game, in fact), before I even knew what buffers and shaders are.
I iterated over a 2D tile map, rendering each tile in turn.
This is super slow because of the huge amount of buffer and texture swaps, and the rendering calls.
However, it made editing the tiles (e.g. changing textures and such) a simple act of changing a number that indicated what texture to render with.

Right now I went to the opposite direction - one gigantic buffer that holds all the tiles, all the textures are combined into a texture atlas, and it is rendered in one call.
While this is super fast (so fast that instead of rendering only the actual tiles visible with a few rendering calls, it was faster to just render the whole thing in one call), it makes editing a big horror movie.
To change textures I need to change data on the GPU, since the texture coordinates must change.
If I want to draw tiles with a different texture, I have to hold two sets of texture coordinates which is a big memory footprint (and I do want this, to show what tile is going to be drawn when editing the tile map in real time).
This is both painfully slow (relativly speaking, but it does jitter if a lot of tiles are edited simultanously), and very annoying to code.

I thought of other ways, such as separating the tile map into groups - one per texture they use - but that makes editing even more slow and painful.

So, I am wondering if there is some way to enjoy both worlds - easily editable data, and fast rendering.

I am using WebGL, by the way, so many features I wouild have liked to have from OpenGL 3+ are not there.