This week we have been adding support for Legacy/DirectInput Joysticks on Windows, since it seems that do not work quite right, as in MindShake worked perfectly, we have ported the code. In that sense we liked Unity, as it is easily expandable. If something is not supported, you can create a dynamic library in C and fix it.
In the visual aspect, this week we focused on the background, creating a small shader for the sky, and adding some distant elements (such as mountains) to create depth. We have also created another small shader to simulate lava you can find on some rocks, and finally we added the shot of snails.
Apart from this, we have decided to reimplement the physical for the main character toward the world, because sometimes was not working quite right. It was initially implemented by colliders and triggers, but we thought it might work better using raycasting. The downside is that we had to redo a lot of work, but we are happy with the result.
Finally, we decided to move to Unity, for this project (FairyTales) at least, as we would love to carry this game to consoles, and it seems the easiest way to get it.
During this time we have been adding many improvements to our game engine, and we wanted to create new versions of all our games, so you can enjoy them.
Some of these enhancements are:
- Improvements and modernization of the the Renderer
- Improvements in the Texture system
- Improvements in all the Window Managers (especially in the IOS version)
- Better integration with IOS
- Improved Touch manager
- Improvements in the main class of our game engine (Device)
- Improvements in our image loading library
- Improvements in our audio library (BrainWave)
- Improvements in all of our entities (Sprites, Meshes and Texts)
- Improvements in the Material system
- Improvements in the SceneManager
- Improvements in our License system
- Improvements in our Math library
- Improvements in our Collision system
- Improved text rendering
To summarize, now our game engine is even easier to use, more efficient and looks better.
We leave you some samples so you can see the most obvious changes (using exactly the same textures):
(Pulsa sobre las imágenes para poder apreciar las diferencias)
Now we are expecting Apple to aprove theese versions.
Currently we are using OpenAL API for our audio driver, and thanks to the AL_EXT_STATIC_BUFFER extension, at least offered in MACOS X and iOS, we achieved a 2500% gain in performance when transferring audio data.
What is offered by this extension?
Basically the function alBufferDataStatic, that allow us to send to OpenAL directly a memory buffer managed by us, so that OpenAL does not have to reserve extra memory (the corresponding malloc or realloc), and make a copy of our data (memcpy) in its own reserved buffer. Thereby achieving a performance boost (around 2500% in the iPhone).
We have seen some controversy on the Internet about using this extension.
On the one hand it is recommended by Apple in their Technical Note: OpenAL FAQ for iPhone OS, but many people (in the Apple forums) seems not to understand well what does this function, misusing it, and therefore do not getting the desired results.
A clear example is to send to OpenAL a buffer (using alBufferDataStatic) and afterwards release it, (which is exactly what you have to do when using alBufferData). In this example, of course, the sound can’t be heard well…
Rule of thumb:
If you use alBufferData you must release your memory.
If you use alBufferDataStatic you must handle your memory.
Some bad practices with the use of this function are contained in the blog of Ben Britten: alBufferDataStatic: Why You Should Avoid it, which in our opinion does not say do not use it, but do not use it unless you know exactly what are you doing.
In any case, we have concluded that we are able to reserve a memory buffer and then do not forget to free it, or use it after being released, so we will use it ^_^
Finally we have updated BrainWave, our 3D audio library. Highlights in this version include:
- Streaming audio (AU / SND, CAFF, AIFF, WAVE, OGG).
- Improvements and optimizations in the codec system (signed / unsigned integer 8, 16, 24, 32, 64 bits, float 32, 64 bits, A-Law, Mu-Law, IMA-ADPCM, MS-ADPCM. Big Endian and Little Endian. Mono and Stereo).
- Fixed some minor bugs.
OpenGL has several ways to set the texture mapping, one of the most interesting is called ‘Wrap’ (GL_TEXTURE_WRAP_?) This feature indicates how that is going to repeat the texture or be mixed with the border color when they exceed the specified coordinates [0, 1].
Here we offer a brief description of the various wrap modes in OpenGL:
- GL_CLAMP: Clamps the texture coordinate in the [0,1] range. In the limits the color of texture is combined with the color of the edge.
- GL_REPEAT: Ignores the integer portion of the texture coordinate, only the fractional part is used, which creates a repeating pattern. This is the default value.
- GL_CLAMP_TO_EDGE: Sets the texture coordinates to [1/2N] (where N is the size of the texture) texels within the texture. This prevents to draw the border color. Available since OpenGL 1.2.
- GL_CLAMP_TO_BORDER: Sets the texture coordinates to [1/2N] (where N is the size of the texture) texels outside the texture. This allows to draw the border color without mixing with the texture color. Available since OpenGL 1.3.
- GL_MIRRORED_REPEAT: The coordinates are set to the fractional part of the texture coordinate if the integer part is even; if the integer part is odd, then the texture coordinate is set to 1 – the fractional part of the texture coordinate. Available since OpenGL 1.4, or with GL_ARB_texture_mirrored_repeat extension, or since OpenGL ES 2.0, or with OES_texture_mirrored_repeat extension.
Since a picture is much more explanatory than any description, we believe it is better to add it to this mini tutorial.
Note: The sample image has the border color set to red (GL_TEXTURE_BORDER_COLOR) so you can well appreciate it.
Once we have done CCustomMesh, the next logical step was to add 3D support for MindShake.
Now MindShake can mix sprites with 3D objects, and they behave the same way and you can happily mix them in each layer, add behaviors to them and so on.
We’ve added a new object to CObjectLayer, it is a generic mesh. So, now you can mix sprites, texts and generic meshes in the same layer.
In addition, a mesh can be composed by submeshes, and you can assign different ways of rendering for each submesh: Points, Lines, LineStrip, LineLoop, Triangles, TriangleStrip and TriangleFan.
These meshes are fully editable and you can add and modify at any time: VertexPosition, VertexColor, VertexTextureCoords, VertexNormal. Finally, tell that the user can add VertexIndexes if the mesh is not linear.
Otherwise, it behaves like an ordinary sprite.