About


What nobody ever told you about passing data to GLSL

 February 22, 13:50(+01:00)


For some reason this was never made clear in ANY tutorial I ever read. For some reason it wasn't evident to me despite being like the very first thing you must do when trying to set up a simple program in OpenGL ES 2.0, or essentially, anything that has to do with GLSL.

In any case, here it goes..


When you want to pass data to shader programs, there are some rules:

1) There are no attributes in fragment shaders. Instead you must use varyings.
2) To set a value to these varying things, you can't pull them directly by using glGetAttribLocation. Instead you MUST use an attribute from WITHIN the vertex shader and pass that value along. E.g.

Declare in both fragment and vertex shader the following varying variable:

varying vec2 varyTextureCoords;

Then in vertex shader ONLY, declare the following attribute variable:

attribute vec2 attrTextureCoords;

In the vertex shader code, pass the value from the attribute to the varying variable:

varyTextureCoords = attrTextureCoords;

3) Finally, uniforms can be declared in both the vertex and fragment shader. But they are not as cool since they cannot change during the execution of the glsl program.


And here is a vanilla superbasic glsl code for myself useful for texturing in case I forget these rules.

glsl: sampleTexturingFragmentGLSLexample.java

-.- 0 comments / Read or write comments

September 05 2011, 12:15(+01:00)




-.- 3 comments / Read or write comments

Character movement in 3D games - what I've found

 July 18 2011, 15:41(+01:00)


Character movement in 3D games is a trickier thing to do than it appears at first sight. Or at least it is for me, which is why I'm sharing this bit of information: I think I finally got it right.

I'll start by speaking about my previous attempts which did not go that well, and their disadvantages

1) Directly modifying the coordinates of the character, based on input.
This is by far the simplest: "if player presses right then character.x += 0.1".
What is the problem here? It makes it harder to account for frame-rate variation, for one thing, but especially makes it hard to implement other cool effects you might want to have, such as slippery surfaces, wind, slowdown due to steep surfaces. In the worst case scenario, it could conflict with the physics engine and make the character "vibrate" when the user instructs it to walk towards a wall. It will technically walk "into" the wall and depending on how the physics engine reacts, the result will be either vibration (the physics engine corrects the character's position to be outside the wall) or even worse: it may trespass the wall (the physics engine "corrects" the character's position to be the other side of the wall).
The "Lanjobot" project had this movement scheme, which made it look funny when the character could scale extremely steep mountains without any kind of slowdown, and people constantly pointed that out to me. I honestly didn't know what to answer because I had no idea how to properly do that (2007 was a long time ago. Not that I've been thinking all these 4 years about character movement (at least not all the time)).

2) Applying an acceleration directly to the player's character.
"if player presses right then character.acceleration.x = 1 and let the physics system take care of the rest. If the player stops pressing right, then slow down the character's speed by quickly ramping its velocity down to 0"
Of course it is a bit more complicated than that - the maximum speed must be capped, but that's the basic idea.
This plays very well with the physics system and feels natural with keyboard controls. It also works with analog joysticks as long as you don't try to suddenly go in the opposite direction to the character's movement. Why is there a difference between a joystick and a keyboard? the details lie in how direction change occurs in the keyboard with respect to an analog joystick.
When you use the keyboard and you change direction suddenly, most of the times there will be a small interval between keystrokes during which braking can occur.




Analog joysticks on the other hand are usually polled by the game engine instead of waiting to receive discrete events. This means the braking phase rarely occurs when changing directions because polling will rarely coincide exactly when the joystick is in the center (or the deadzone for that matter).



This results in having the player's character brake and turn very well when using keyboard, but sliding backwards (moonwalk-style) when using a joystick, which severely complicates actions like jumping from one small platform to another: people will instinctively press the opposite direction after a jump to brake.

This is one of the problems that have affected Memai so far, and in the versions publicly available at this moment it still does, however I am testing the newest method which I thought up a few days ago (it always takes me ages to write).

It is a bit more complicated. The basic idea is this: the character has basically two speeds - one derived from its feet (its actions, its intentions), and one derived from external factors (e.g. someone pushed him, wind, etc). We'll call the first one Va, the second one Ve. Both are vectors in 3D, and the second one can be ignored until the very end (and anyway it is 0 most of the time). There is a friction factor on the floor, which will govern how slippery it is. Lets call that fr.
On each frame, the input is read and the direction the player wants to move, call it Da a unit vector in 3D, is obtained. The magnitude of the current Va is stored in a scalar: Sa. Then, update Sa by applying the acceleration due to the input as if it were in the same direction - in my code this is done by doing Sa' = (Aa*dt), where Aa is the acceleration due to the player's actions and dt is the time elapsed between the current frame and the last- and multiply Da by Sa'. Which will give us the velocity in vector form the player would like the character to actually move in, Va'. Now is where friction factor, fr, comes into play: if the floor is slippery the player shouldn't be able to change its velocity so easily. Let's consider that for fr values close to 0, is when the floor is almost frictionless (for example an ice surface). For fr values close to 1 is when the floor is not slippery at all, so the character can freely change velocity with its own feet. Let's call the definitive velocity in which the character will move based on its actions, Vf. Vf will then be

Vf = ((fr)*Va') + ((1.0-fr)*Va)

What this means is that Vf takes into account both the "intentional" velocity Va' and the current velocity Va. If fr is close to 0, Vf will be mostly Va unaffected by Va' which is a rather believable slipping effect, while if fr is close to 1, the character will be able to change direction at any time - the way we expect platform games to work, and quite close to reality (although of course characters in platform games will always be more agile than real people. Blame Mario 64 for that, I consider it to be the game with the best control response for 3D platforming).

Then take speed capping into account. Also when the joystick is in the deadzone or there is no input from the keyboard, braking should occur. There is a slight modification to be made to the braking, as it also needs to take into account the friction factor fr.

The way I handle it is by taking multiplying Va by a braking factor br (which is a scalar), then by the friction factor fr and multiplying it times dt, the elapsed time between each frame, and storing the result in Vb, the velocity vector for braking:

Vb = br*fr*dt*Vb

Vf is then calculated as follows:

Vf = Va - Vb

to avoid "vibration" once Vf is under a certan threshold, it is set directly set to vector 0.

This gives a nice feeling of almost instantly braking on surfaces with friction factors close to 1.0, and braking with difficulty on slippery surfaces with friction factors close to 0. And pushing the controller in the opposite direction will make the character brake faster on these slippery surfaces, as it should be.

Finally after all is said an done, Ve is added to Vf, and the physics system takes care of the rest. Until the next frame.

-.- 1 comment / Read or write comments

Messing about with the iPod

 June 07 2011, 04:56(+01:00)


Well, I gave in and bought an iPod. My main aim is to build apps and games for it, but I also have to admit it's a very convenient portable music player. Also, the camera while not very impressive is nice for spontaneous stuff since I don't always carry my camera with me. The video quality is quite good actually. Three things I really did not like though.

1) the "Music" app does not play Ogg
2) there is no way to have iTunes convert music from the Ogg format into mp4 on transfer (though with a plugin, iTunes can play Ogg-formatted music)
3) when I synced the iPod from iTunes within my mac partition, the music I had added from my windows iTunes library disappeared from the iPod because the mac iTunes library did not have those files

I really did not appreciate iTunes/mac deleting files from my iPod just because it didn't know about them, so I set out to find something that

1) plays Ogg
2) has built-in file-transfer (since all the apps are sandboxed I can't just drop files into the thing and expect them to work)
3) has NOTHING to do with iTunes

Luckily such a program exists in the app-store so I didn't have to code it myself: Capriccio music player.

It mostly does its job:
- plays Ogg, FLAC and many more
- has an ftp server. Super convenient, no cables or special programs required
- has nothing to do with iTunes. It says it can play media from the iPod music library but it actually can't (it hesitates and crashes if you try to force it). Never mind, I couldn't care less.

There's also an ad-supported, free version.

It has a few flaws which are not much of a problem IMO: files need to be added manually to the playlist, does not do UTF-8 for song data and I couldn't care less about the 3D equalizer settings and display, or the fact that it can play media files faster or slower than usual.

All in all, the app is worth it in my opinion. So if you dislike iTunes as much as me and have your music library 80% in Ogg, get it.


-.- 1 comment / Read or write comments

Memai - The game

 May 12 2011, 07:37(+01:00)




Our entry for the Swedish Game Awards 2011 has been sent :) Now we'll wait and see. This is a project I've been working on for almost a year during free time. I dropped hints here and there via twitter (and some obsession with axis-aligned boxes in another blog article).

Here's what the game is about:

"A puzzle game that puts the player in control over gravity while navigating the world of Memai, letting the player solve challenging puzzles and face tricky cheeseburgers!"

If you want to try the game, here's the link:

priv: FINAL VERSION-levelreorder.zip
Edit: GNU/Linux version -> priv: Memai-FINAL_VERSION-GNULinux.tar.gz
Edit2: OSX version -> priv: Memai-FINAL_VERSION-OSX.zip

A trailer will also follow soon :)

-.- 4 comments / Read or write comments

My macbook startup kit for GNU/Linux

 May 06 2011, 06:47(+01:00)


Installing GNU/Linux on my Macbook computer is a huge PITA. So after much experimentation I came up with this set of files, in case I ever require to reinstall GNU/linux on this machine.

The first file (41 MB) contains
- A readme which instructs me to get GCC-4.3 and set export CC=gcc-4.3
- An STA-broadcom driver which works (latest as of today)
- The AppleUSBVideoSupport file which can be used to extract isight.fw for ift-load
- isight.fw for the lulz.
- grub_efi from Ste in the Ubuntu forums. The one who actually got GNU/Linux working on my computer.
- linux-image package 2.6.32.7-OLD_BUT_GOOD which plain works. No isight or sta-broadcom funkiness.
- NVidia 190.53 since it's the last driver I got to work which respected the brightness settings instead of frying my pupils. I might experiment with a few later versions but 270.* is confirmed as pupil-frying so I'm not too optimistic about that.

macbookwhite-5.2-definitive: macbookwhite-5.2-definitive-linux.tar.gz

The second file (170 MB) is the entire compiled kernel tree for the NVidia & STA-broadcom drivers to compile properly, without hassle, and without having to wait for the kernel to compile.

macbookwhite-5.2-definitive: linux-2.6.32.7-compiledtree.tar.gz


The only thing the 2.6.32.7 kernel doesn't do properly but modern kernels do, is sleeping and waking up twice. Oh well.

This blog post is mostly for me, since I might forget where I put the files otherwise, but it might be useful for other people too.


-.- 1 comment / Read or write comments

XML/RSS Subscribe to this blog / Older blog entries