Planet Maemo: category "feed:ffedab845b17ad5f072a1f90af70d0f9"

Qt5 Battery Component

Mon, 13 May 2013 08:34:00 +0000

After the QUItIndicator trilogy which introduced idea, design and performance of a specific Qt5 QML component there's room for more, right?! Something like this:

This time we have a dynamic QML component for showing the remaining power of your mobile device battery. As a recap, with "Dynamic QML component" I mean someting which utilizes not only basic QML animation properties (position, opacity, scale etc.) but also new Qt5 features (shaders, particles, scenegraph powa!) to appear "more dynamic". Maybe it's just me, but I would love to see UIs really utilizing modern GPUs... and accelerating this progress is one of the reasons why I code these examples and blog about them. Another reason being to rule-the-world, obviously ;-P

Instead of explaining design & features of QUItBattery component I'll let this video to do that:

If you want to use this liquid battery component in your UI: Download the sources from here, copy QUItBatteryComponent directory, import it in your QML and off you go. Happy hacking!

0 0

QUItIndicators: Performance considerations

Thu, 02 May 2013 13:34:00 +0000

(This is part III, please check also parts I and II)

Even with a small component like this, there are plenty of possibilities to improve (or sink) the performance. To make sure that our indicators perform as expected, we'll test them on Nokia N9 and and on Raspberry Pi.

These both devices are relatively low-end by current standards. N9 contains 1GHz Cortex-A8 CPU which is still quite beefy, but GPU (SGX530) on the other hand is getting old and unable to handle more complicated fragment shaders. For RPi these are just the opposite: CPU is slowish 700MHz ARM11 while the GPU (VideoCore IV) is more performant than N9 SGX530. Because of these qualities (and because both support Qt5, naturally) this duo is excellent for our performance ensurement.

So here's a short video showing how our indicators perform on Nokia N9 and on RaspberryPi:

Performs pretty OK on both, right? ProgressIndicator stress test isn't smooth on RPi, which indicates that its CPU can't handle 100 indicators animated like that. So stress test does what it's supposed to, normal use cases perform well.

Even with declarative QML language, good performance doesn't just happen, you need to work towards it. By looking at the sources of these indicators, at least these tips/notes can be made:

BusyIndicator and ProgressIndicator are separate components instead of just one component with e.g. "indeterminate" property. This allows using a more light-weight (only one texture, animating only vertex shader, less properties etc.) BusyIndicator component with indeterminate use-cases. Lesson to learn is to avoid making too general/bloat QML components.
There are four different sizes for indicators, from small (64x64px) to huge (512x512px). These sizes were selected because power-of-two texture sizes are more optimal for GPU. SourceSize property is used to scale and cache exactly the correct sized textures.
BusyIndicator animation is achieved purely on vertex shader. As vertex shader is run once for every vertex instead of once for every fragment (pixel), it can be much more GPU-friendly. In case of an 256x256px indicator, our vertex shader is executed over 650(!) times less than fragment shader.
To keep the amount of vertices as small as possible while making sure animation looks still smooth, the mesh size is allocated based on indicator size. GridMesh resolution for 256x256 indicator is 10x10 while 64x64 indicator manages with a 4x4 mesh.
When using items&images as sources for ShaderEffect and not needing the original one, remember to set its visibility to false to prevent it from rendering.
ProgressIndicator can show percentages in the center and applies vertex animation also for it, which requires that the whole Item is used as a source for ShaderEffect. Initialize of Item as a ShaderEffect source is slightly slower than initialize of Image. This is because Items (with their child Items) need to be rendered into FBO first while Image textures are instantly available. When percentages are disabled (showPercentages: false), Image is used directly and stress test of 162 ProgressIndicators starts pretty instantly. So if you need instantly appearing ProgressIndicators, don't show percentages on them.
Minimize the amount of property changes. Property bindings in QML are so easy to make that without paying attention you may forget to disable those when not needed. As an example, ProgressIndicator percentages Text element visibility was set to false when disabled and it wasn't even used as part of the shader source. But because of an oversight, its text property was still updated whenever ProgressIndicator value changed. That's bad, fixed now to update text only when showPercentages is true. Qt Creator QML Profiler is the tool to use to analyze your code.

So with all this, does it mean that these indicator components are fully optimized? Well of course not! There are still some generalization left and room for improvements. Additinally, although we have tried to offload most of the work from CPU to GPU, indicator animations like these should be run in a separate thread instead of the GUI thread. Only this would allow smooth 60fps even when processing under heavy CPU load. For details, please read this blog post by Gunnar: http://blog.qt.digia.com/blog/2012/08/20/render-thread-animations-in-qt-quick-2-0/

Summing up briefly: When implementing QML components for applications, developers and designers should co-operate closely to bend the design to be as CPU&GPU friendly as possible while still making designers happy. Designers dig perfect pixels, but they also appreciate smooth 60fps. By making wise compromises and utilizing Qt5 correctly, we can deliver both.

Sources of QUItIndicator components & examples are available from: http://quitcoding.com/?page=work#indicators

0 0

QUItIndicators: Design considerations

Fri, 19 Apr 2013 16:20:00 +0000

(This is part II, for the introduction see part I)

The main points of this indicators exercise are to promote Qt5 QML+GLSL approach for building dynamic UI components (part I) and to give performance tips (part III, coming!). But here in the middle, we talk also a bit about design considerations behind these indicators. After all, who cares if your component performs well if it doesn't also look good and fulfil its functionality.

Here's set of design-related notes about QUItIndicators which we wanted to achieve:

The design language should be relatively neutral. Indicators like these may be used in many places, in applications and games, so they should not be too characteristic. And circles are pretty universal, so circles it is. The amount of circles in BusyIndicator is 11, by design. Reason behind this is that ProgressIndicator has one missing from top to mark start/end position, meaning 10 circles. This is optimal for percentages math e.g. when user sees 4 circles highlighted she can count that progress is at 40%. For smaller indicators, less & bigger circles might look better but decision was not to differentiate on these.

Different use-cases call for different kind of indicators. When indicator is only visible briefly and progress can't be tracked, BusyIndicator is the one to use. Some events may take more time and then ProgressIndicator can be used to keep users better informed of how long they still need to wait. With longer taking tasks you could show percentages and make indicator even more dynamic to make it less boring for user to watch. Watching interesting animation makes 5 seconds to feel like 2... So from brief (left) to longer (right) waiting times, indicator to choose from our set would be:

Indicators should fit and be clearly visible on top of any background. Users may wish to place them on white, black or colorful areas and expects indicator to fit there. To achieve this, our indicators use neutral black&white as their base colors and contain inverted version which works better on light backgrounds. It's also possible to define alternative highlight color when the default yellowish isn't suitable. Here are few examples of ProgressIndicators on top of different backgrounds:

Show/hide animations are also important. Too often animated items like these appear and disappear suddenly, breaking the illusion of a fluid component. In our component showing/hiding animations are combination of opacity, scale and vertex position skewing. Strips below show what the animation looks like. This could be made smoother but for performance reasons we use only vertex shader with a minimal mesh size. Fastly animated it anyway looks better than these still images.

Sometimes indicators like these should attract user attention. When the application is blocked until loading is ready, it's good that user eyes focus on the indicator. Darkening (and blurring, Qt5 graphical effects make that easy) the rest of the UI is a good way to achieve this. But sometimes just the opposite is desired, directing user focus to real content and keeping indicators relatively obscure. Example of this is our Picture Wall demo, users attention is on loaded images instead of the ones still loading. With our indicators this can be achieved by decreasing opacity. (Developer note: When making your own ShaderEffect which rewrites the default fragmentShader, remember to multiply gl_FragColor with qt_Opacity to keep QML opacity property behaving correctly!). Here's how Picture Wall demo fades indicators into background:

Circular zooming animation doesn't progress linearly, but instead follows a custom bezier curve. This change in speed makes animation feel more lively and natural as it would be affected by slight gravity, gaining speed when moving down and slowing down while reaching the top. Designs are often filled with small details like this, final touches.

These indicators are not highly original and will not win design awards. Graphics, effects and small details could be greatly refined. But we anyway tried to consider use-cases and apply them into the design. If you are eager to experiment yourself, grab the sources.

Next part will explain how to reach optimal performance to support these design considerations.

0 0

QUItIndicators: Introduction

Thu, 18 Apr 2013 14:26:00 +0000

Few months ago I wrote a normal mapping series with part I and part II. That was a good experience, so series it is again! This time about implementing dynamic QML components, with an example case being busy&progress indicators. We'll call these specific ones QUItIndicators.

Let's start with obligatory video which demonstrates these components, BusyIndicator and ProgressIndicator, with few examples:

Traditionally indicators like these would be implemented as an animated GIF or a sprite. Cons of that approach are zero customization and memory consumption: 2s animation of 256x256px 32-bit color indicator at 60fps would mean 2*60*256*256*4 = 31.5Mb memory consumption. That's quite a bit for just one indicator, so usually frames are animated slower than 60fps which makes animation less smooth.

Alternative way to implement animated indicator would be using imperative drawing API (QPainter, Cairo, Skia etc.). Drawing freely to a canvas gives a lot of possibilities, but can easily lead to non-optimal performance. Many of these APIs have OpenGL backends which sounds good in theory, but the reality is that they can't take full gains out of modern GPUs. Like wise Tro^H^H^HDigians have said, combining QPainter with OpenGL backend doesn't make a perfect harmony.

So as you probably guessed, our indicators use Qt5+QML+GLSL instead. The pros of this approach compared to sprites or imperative drawing are rendering performance, low memory consumption and customization possibilities. There is also at least one con: Indicator needs to be designed so that required animations can be achieved with vertex & fragment shaders.

Next blog post goes through design thoughts behind these indicators. In the meantime, you can get the sources from here and try yourself!

0 0

Qt5 and normal mapping - reloaded

Sun, 14 Oct 2012 10:54:00 +0000

(This is part II of the normal mapping journey, check the part I first for details.)

So you have all now played with Qt5 NMapper tool, right? Goody, that means we have gained experience of normal mapping and created some perfectly tuned normal mapped textures. Now it's time to use these in a separate application.

Let's assume that you are working on a 2D QML application, but would want 3D-looking effect into some part(s) of the UI. To visualize, here's an example NMapCarousel demo application:

(Qt5 NMap Carousel, running on PC and on Raspberry Pi)

Here normal mapping is used to make the carousel icons more dynamic by applying lighting. To increase the 3D impression, there are also extra shadows reflected behind the icons.

To implement something similar, here's how to proceed:

If not already, setup Qt5 to your PC/Mac/RPi or equivalent platform.
Create normal maps of your graphic assets using Gimp, Blender, Photoshop etc. tool of your choice. Name the normal mapped image with extra "n" in the end, so images are something like "thing.png" and "thingn.png".
Test your graphics with NMapper by copying these images into "images" folder and adding "thing" into imageFiles array property. Play with the light intensity, diffuse, switching x&y coordinates etc. If you are not happy with the results, jump back to step 2 to edit the images and iterate.
Make your own application. Copy NMapEffect.qml and NMapLightSource.qml from NMapper, use your freshly made images, the lighting settings you tested earlier and implement rest of the UI.
Profit! (Sorry that this took a bit more steps than normally... but on the positive side there is no unknown ???-step in the middle!)

Source codes of this demo are available from here. I'm waiting to see cool normal mapping uses!

PS: To learn shaders from the master, check out Andrew's thndl.com!

4 1

Qt5 and normal mapping

Fri, 12 Oct 2012 12:04:00 +0000

This one has been on my "blog at some point" back burner for some time now...

'Normal mapping' is a graphics rendering technique used for faking the lighting conditions. In 3D software it is often used for bringing small bumps and dents of textures visible to achieve more realistic graphical appearance without using huge amount of polygons. Normal mapping is kinda advanced version of preceding 'Bump mapping' technique. Where bump mapping uses just one channel for 'bumps', normal mapping uses 3-channel (RGB) bitmaps and can therefore contain more detailed normal vector information.

Normal mapping technique can also be used in 2D applications to get 3D'ish looking UI elements, which means it can be used also in normal non-Qt3D QML applications. Combining image textures with specifically made normal map textures using a suitable shader is all you need. And normal maps can be automatically created with Gimp, Blender, Photoshop etc. drawing tools, although for best results some tweaking may be required.

But enough about theoretical mumbling, here comes visuals:

(Qt5 NMapper tool, running on PC and on Raspberry Pi)

To experiment with normal mapping I implemented a simple Qt5 NMapper application. As seen from video, it can be used to play with different graphical assets, change lighting conditions, switch normal map x&y-coordinates etc. It also includes the essential 'cave mode' for wiggly fire light.. ;-)

Download NMapper application from here and try it on PC/Mac/RPi or equivalent platform with Qt5.

After this brief intro I'll make a follow-up post within few days about example usage. Have a hacking weekend everyone!

4 1

Qt5 & Raspberry Pi

Fri, 21 Sep 2012 22:24:00 +0000

I received a Raspberry Pi this week (thanks Nokia & QtonPi!) and naturally baked Qt5 into it as the first thing. Started by just installing premade RPi Qt5 package, but as qmlscene is not yet included, went for building Qt5 following loosely these instructions. About 2 hours later, I had system setup with latest Raspbian image running Qt5 QML apps.

Last month when Qt5 first beta was coming together I prepared this "Qt5 Cinematic Experience" technology demo and got some good feedback. Samuel Rødal (btw check out his awesome "Qt 5 based 3D Wayland compositor" video!) kindly tested that it works also in RPi. Yes, it worked and was pretty fast also, but not even close to perfect... Now armed with RPi I wanted to spend some quality time with it, experimenting what the GPU (Broadcom VideoCore IV) likes and hates. So here comes "Qt5 Cinematic Experience - Raspberry Pi Edition":

The changes made for this RPi version are:

Original version was quite scalable, but it was optimized for ~N9 screen resolutions. I wanted to run RPi in full HD 1080p (1920x1080) so adjusted things to fit better for the larger screen, making everything bigger and better. Though more pixels means more work for CPU&GPU so..
Added FPS item in the top-left corner which shows how frequently QML animation loop gets called. Seeing this all the time while developing gives good feedback on how different changes affect the performance and also adds some demonstration sugar.
Reduced smoke particles amount & size as that was a clear bottleneck.
Another slowdown was DropShadow effect for big movie title texts, switched it now to plain Text.Outline style.
On the other hand, increased shooting star sprite and its particles sizes as these changes didn't notably decrease the performance.
On the RPi side used 128/128 CPU/GPU memory split and to get even more juices out, overclocked it to "medium" 700MHz -> 900MHz (see instructions)
Went for a more colorful theme by default, raspberries are bright!

These RPi tuned sources as well as original ones are are available from here if you wanna grab and hack! 4 0

Qt5 Cinematic Experience

Thu, 16 Aug 2012 10:34:00 +0000

During the past ~20 months I've made several blog posts about Qt5, QML Scene Graph, shaders and whatnot. As Qt5 beta is getting reeeeally close, I thought this would be a good time for a fresh Qt5 technology demo. This one is called 'Cinematic Experience' and looks a bit like this:

(best viewed in HD)
Cinematic Experience collects many of the new Qt5 QtQuick 2.0 features into the same UX demo application. It uses particles, sprites, path animation, custom shaders etc. features which Qt5 introduces for QML UIs. As usual, source codes are available from here.

Performance note: The GPU in N9 (SGX530, released Jul 2005) is showing its age. Especially fragment shaders need to be very conservative as the GPU just isn't powerful enough for the N9 screen resolution. To get the application perform in N9, some optimizations were required like disabling the normal-mapping lighting and reducing the amount of fog particles. As seen in the video, after these tweakings N9 can run the demo okeyish. Definitely far from velvet, but I would say it's more like butter ;P

PS. In case you own RPi, Beagleboard, Pandaboard, Snowball or any other embedded hardware running Qt5, please grab the demo and give it a go. I'm waiting for feedback and videos!5 0

Qt5 LedScreen component

Sat, 09 Jun 2012 16:33:00 +0000

Howdy! Do you remember the time before HD, amoled etc. super sharp screens? When pixels were so big that you could easily count them and any colors were luxury? This is your ticket back to these good ol' times: LedScreen Qt5 & QtQuick 2.0 component! Here is a video presenting it with example applications:

This component allows you to use any QML content as the source for the ledscreen, define led size and color or use colors from the source item. So it doesn't contain kitchen sink yet, but there's only so much you can fit into 60 lines of QML + GLSL with API documentation.. ;-)

Feel free to grab sources from here & modify & use as you want!

PS: Hoping to be able to develop & demo Qt5 soon on Raspberry Pi!7 0

Smoke The Bugs!

Tue, 20 Mar 2012 20:16:00 +0000

Smoke the Bugs is now available to download from Nokia Store for Harmattan N9 and for Anna/Belle. No bugs (except software bugs!) were harmed while developing the game, but to know whether this virtual bug smoking is suitable for you, check this video of game play on N9:

As explained here earlier, this was partly an expedition on making a game with pure QML + JavaScript + shader effects. Plan was to make it totally without C++ (excluding the launcher which Qt SDK generates automatically) and to see what the outcome would be.

So summing up some random development notes here:

Harmattan version of the game utilizes Qt-components for portrait main window and for disabling swipe while playing. Symbian version does not use Qt-components as pure QML was enough.

It's good to use Loader for separating rest of the UI from initial "splash screen" for faster startup. Another option on Harmattan would be to show static splash screen image with invoker.

In this game, loaders are also used for help and high score views. As these are not often used, it is better to save memory and only load them when needed. Loading is fast enough not to cause notable delay.

ShaderEffectItem is available on Harmattan, Belle and Anna+Qt 4.7.4, so it's possible to target quite a many devices. Exception is Nokia 500 which is lacking GPU for OpenGL.

With Symbian, setting QGLWidget for viewport is required to be able to use ShaderEffectItem. On Harmattan this is not needed as the default graphics system is already set to use OpenGL.

When application is minimized, unload ShaderEffectItems or set their 'visible' property to false. Not doing this causes minimized application to use resources unnecessarily. Application state can be tracked with Qt.application.active

When writing shaders, be careful to keep them performing well. Symbian devices and especially newer Belle ones can handle heavy fragment shaders better than N9. As an example, moving night effect math from fragment shader to vertex shader improved performance notably on N9.

Avoid too many ShaderEffectItems to save resources. As an example, instead of each bug containing its own burning effect, there are three global effect items in a queue, positioned and animated when needed. If three simultaneously burning bugs are not enough, it's easy to add more effect items into queue.

QML performance notes give good general guidelines what to avoid. Qt5 version of this document is even better and provides also information on how Qt5 scenegraph and V8 engine changes reflect to optimizing QML performance.

P.S. I joined Nokia ~month ago which may increase my bias towards Qt... But it's not like I wouldn't have made my opinion pretty clear already ;-)4 1

Games for the Next Billion

Sat, 31 Dec 2011 12:16:00 +0000

Catchy title right? Don't worry, content partly matches to that description... ;)

It seems that I quite often include videos in my blog posts. There is no reason to stray away from that habit now, so here's a video showing a beta version of "Smoke the Bugs!" game on N950 & N8:

By looking at the graphics, effects, dynamic lights etc. what you saw was a pretty average OpenGL (ES 2.0) game, right? Well yes and no... Yes, GLSL shaders have been used for the effects. But no, there is zero lines of OpenGL and in fact also zero lines of C/C++ in the game. It's all QML + GLSL + JavaScript.

To work on current Harmattan & Symbian devices, game uses Qt 4.7 with the shaders plugin. This is an okay-ish platform, as you see from the video: N8@680MHz runs at smooth ~60fps. But I have also smelled, tasted and floated in the sweet velvet of Qt5 and can tell you as a fact that it will be much better. With Qt5 & QtQuick 2.0, applications will get a healthy boost of performance, smoothness and possibility for even better effects.

Here is a short list of improvements QtQuick-based games will gain from Qt5:
- Performance: QML Scene Graph will render everything faster than Qt4 QGraphicsView-based renderer, especially when the amount and complexity of (animated) items rises.
- Performance2: New V8 JavaScript engine performs much better than the JavaScriptCore engine in Qt4. Also thanks to this integration work, there is deeper co-operation between QML and JavaScript.
- Smoothness: Qt5 moves rendering into a separate thread which makes UI feel much smoother.
- Effects: QtQuick 2.0 supports shader effects to make QML UI's much more dynamic. Using shaders with Qt4 is possible with the shader plugin as shown above, but Qt5 native support will be more complete.
- Particles: QtQuick 1.0 contains particles plugin but it's very basic when compared to QtQuick 2.0 particles. No game can survive without particles!
- QML features: There are additions in QML which will suit games very well like SpriteImage for sprite animations and PathAnimation & PathInterpolator to animate along a custom path instead of linear path.
- QtCreator: Had to mention this one still as the work done in QtCreator Qt5 integration, QML debugger & analyzer etc. will improve the developer (that's me) productivity.

Now look at the video again to see what the old 2011 QML looked like, add all the above improvements to it and use your imagination... For me it feels like Qt5 & QtQuick 2.0 can offer a great platform not just for applications but also for games. Billion or two, I don't really care... ;) Happy New Year 2012 Everyone!6 1

5inarow @ N9

Fri, 28 Oct 2011 21:04:00 +0000

Hey! Qt Developer Days '11 are over and I want to thank all organizers & attendees, what a great event again!!

For fresh owners of N9 (congratulations!), I'll say that 5inarow game is now available through Nokia Store. Here's how to get beaten by medium level:

Symbian version may follow later, but for now game is only available on N9/N950. It's free and contains no ads so if you feel like it, go grab it from here.

PS. If this tickles your "How to implement a Qt game like that?" or "I could do much better than that!" -nerves, source codes and Qt Quick Game Programming tutorial are still available from here. These are for the older N900 version, without e.g. sounds and computer AI. But an idea of updating the document for Qt5 & shader effects is floating in my mind, we'll see, we'll see...6 1

Qt5 + Distance Field Effects

Sun, 21 Aug 2011 13:40:00 +0000

Yoann Lopes blogged recently about Text Rendering in the QML Scene Graph using distance field alpha testing. This technique brings smoothly scalable fonts with fast OpenGL rendering to Qt5.

Distance field is of course not limited for just fonts (although they are the most usual use-case), same technique can be used also with suitable images. Here is a video of an example application running on PC and N950 which demonstrates the effect:

As you can see, the original image becomes quite pixelated when zooming in, which is expected as image is only 256x160 pixels (smiley 64x64 pixels). But enabling smoothing with distance field shader makes it very scalable with nice anti-aliasing, outline and transparency. As the pixmap required for this is so small, GPU / fragment shader has less to process leading to better performance. Like with fonts, adding effects such as outline, smoothing, glow and shadow can be implemented very effectively.

This application is under 300 lines of QML with a GLSL shader, including slider and toggle button components. So if you have Qt5 built up and want to give it a try, source codes are available from here. Creative usage ideas and astonishing shaders are welcomed!7 0

Qt Contributors' Summit

Mon, 13 Jun 2011 22:53:00 +0000

I will be mostly interested in discussions about Qt5 graphics stack, qml-box2d, QtQuick 2.0 and of course QML Scene Graph. So whenever something related to these is going on, please grab me in!4 1

QML Metaballs

Fri, 06 May 2011 16:19:00 +0000

Kimi, the man with excellent genes, blogged few days ago in here about QML extension plugin that provides shader effects for QGraphicsView based Qt Quick 1.x. What makes this magnificent, is the fact that API matches to what QML Scene Graph (at least currently) has, making it a perfect solution to start experimenting with the future. Also, as it is a separate plugin sitting on top of standard Qt 4.7.x, it turns "Qt everywhere" to "shaders everywhere" right now while waiting for the full Scene Graph glory.

All you need is 1) Qt 4.7 installed in suitable environment (Linux, Windows, Symbian etc.) 2) the qml1-shadersplugin and 3) imagination for writing QML & GLSL.

What I came up with using the plugin is something they call metaballs:

Source codes are available in here, go wild! And kudos to Nokia/Qt team for providing this plugin!7 1

Superior technology

Mon, 21 Feb 2011 00:23:00 +0000

I decided not to blog anything right after Nokia & Microsoft deal was published. And I'm glad about that, because I have now reached the state where I'm actually excited again! Volker Hilsheimer made a very good summary about the situation from Qt perspective.

Instead of going deep into politics and sales speeches, I decided to approach this from a technical perspective. Keeping things simple and concrete, here's one example UI implemented in few hours with Qt Quick & QML Scene Graph:

Please spend a bit time looking at what is really happening in there: wave, colorize, fading, water, text highlight... This is ~300 lines of QML + GLSL, performing smoothly on good ol' N900 hardware. Same can not be done using WP7 Silverlight & XAML, period.

Qt is still the best platform for "mobile phones" and we have also here good ingredients for the "future disruption" like Nokia management has outlined. But technology is nothing without a community (a.k.a. "ecosystem"), so question is that are we going to continue the work and do it? While you think about that, I'll continue hacking with my superior technology! =)15 1

QML Scene Graph demo

Sun, 16 Jan 2011 18:00:00 +0000

Here is a small demo of QML animations combined with OpenGL shader effects, running on QML Scene Graph:

At first, everything is gray and plain. But once you enable QUIt mode, the whole world feels a lot more colorful and dynamic. Some call this feeling velvet, I call it.. exciting 2011!8 1

MeeGo Conference & SteelRat

Sun, 14 Nov 2010 23:41:00 +0000

I'm personally not attending to MeeGo Conference this year. Past two Maemo Summits have been great, so I'm sure this time things will be even Harder, Better, Faster, Stronger!

But in a way part of me is attending, as one thing I have been working with recently is a UX prototype called "SteelRat". It will be shown in Nomovok booth, running on top of MeeGo in different ARM development boards. This is what SteelRat looked like in Freescale i.MX51 during Qt Developer Days:

But anyway, wishing good times for all you attending!1 0

Qt Quick Game Programming

Sun, 24 Oct 2010 17:15:00 +0000

Are you interested about Qt Quick? Want to get jiggy with it and develop mad skillz? Wanna become first Qt Quick OVI Store millionaire? Good news, we have a (partial) solution!

We've been working with Qt Quick / QML for quite some time now and decided to write ~30 pages short tutorial which goes through step-by-step the implementation of 5-in-a-row game. My recommendation would be to read the tutorial while browsing game sources and reaching towards Qt Quick API documentation whenever interested in more details.

Download the "Qt Quick Game Programming" tutorial from here!14 0

5-in-a-row

Sun, 24 Oct 2010 17:01:00 +0000

We released today a game called 5-in-a-row. It's implemented with Qt Quick / QML and designed for 2 players playing next to each other:

Want it? Package for N900 as well as source codes are available from here!7 0