Back..
April 28, 09:52(+01:00)What?!
Has it already been over a year since I last published something here??
OMVFG.
Well, never too lake to re-take publishing stuff I guess. I will try to keep this space updated more often.
Here's a quick run-down of a few events in the last year:
* Got a job (since late 2011). It is/was in the Interaction Design area in a large and prestigious company in the automotive sector.
* Got an apartment (late 2012) in central Gothenburg. Nice and all, a bit smaller than I'd have liked but not too shabby :)
* Got fed up with Swedish (and in general, European) winter-time. Snow is nice and all, but the long nights in this northern region has kinda got to me. So it is time to move on. Where? When? We will see.
* Quit job (upcoming june 2013). The job I had was very fullfilling and the colleagues fantastic, but it was not games or computer graphics. And since now I have the possibility to do either for at least a year, time to move on!
* Master's thesis (still dragging on). Ugh. But since quite a lot depends on it, the files have been dusted, re-opened and re-edited.. and there is progress. Slowly and stumbling, but moving on.
* Secret project(s) (upcoming 2013). Revealed perhaps too soon to a few people. I still have to take a final decision. And there's always the question of funding, which could change the decision.
I will use this space for self-motivation and to track progress. Meanwhile here's some assorted pretty pictures of different things:
-.- 0 comments / Read or write comments
What nobody ever told you about passing data to GLSL
February 22 2012, 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.
-.- 2 comments / 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
Subscribe to this blog
/ Older blog entries