Day: January 4, 2008

>Two years ago the QtCentre site was launched. The goal was to provide the leading forum on the internet, encouraging the exchange of experience and to provide a meeting point to the Qt community. The response to this has been beyond our wildest expectations – all thanks to all our visitors and contributors.

As a part of QtCentre’s ambition to be the meeting point of the QtCommunity a Qt programming contest was held last year. The result was fenomenal with a great list of high quality entries and a matching list of prices. The participants came from all of the earth, reflecting the wealth of the community available at QtCentre.

A forum is good for exchanging experience and providing answers. For the more in-depth information QtCentre provides a wiki filled with articles. These articles touch the peculiarities of Qt, provide helpful tips and tricks as well as providing useful general knowledge about Qt.

The QtCentre team would like to thank all visitors and contributors. Thanks to you, the centre has succeeded beyond our wildest expectations. We hope to see you all in 2008 and make that an even greater year!

QtCentre is the leading independent Qt forum. In addition, it hosts a wiki filled with in-depth Qt articles. The goal is to provide the Qt community with answers and information.

The QtCentre is based on the vibrant community surrounding Qt. The centre is one of the few sites actively used by both the open source community and the propritary users of Qt.

>

Getting Qtopia up and running on the BADGER board was really just a matter of compilation. However, Qtopia’s built-in framebuffer driver automatically assumed that 16 bits per pixel was a 5/6/5 format. This resulted in some rather funny looking colours as it works with a 4/4/4 setup – but at least the framebuffer works as expected.

Even if BADGER works with 4/4/4 right now, it can easily be reconfigured and synthesized for pretty much any other conceivable pixel formats. However, the standard reference design uses 4/4/4 right now, so I’ll work with that.

Spending a few more hours, an unaccelerated driver operating directly on the screen was created. The driver simply provides a screen class initializing the hardware, a dummy surface and a paint device simply returning a paint engine inheriting the QRasterPaintEngine. By implementing the drawBufferSpan and drawColorSpans we get something on the screen.

And, hey, the drawColorSpans is a simple draw-horizontal-line-function so we can accelerate it right away. The drawBufferSpan is also accelerated – we simply plot the data to a buffer in the video memory and then use the blitting capabilites of BADGE to have it handle the alpha blending – neat :-)