screen

The challenge is as follows:

fxsf — Wed, 16 Oct 2013 02:02:38 GMT

There is a generic system (most likely an embedded one) that has a buffer of images (frames of a video), attached to a screen (resolution of [640 x 480] on both screen and buffer):

The buffer is a 2D set of pixels, and the first pixel is the top-left most of the image. Each pixel has 16 Bits and it is stored as follows:

[Red | Green | Blue]

00000 000000 00000

Red has 5 Bits, Green has 6 Bits, and Blue has 5 Bits. This is how a single pixel stores the 3 colors (right part is least significant). The objective is to overlay another image on the buffer (like the subtitles of a movie, or a mouse cursor on top of a background image). This image is a [32 x 32] pixels, and it will be put on a given coordinate (X,Y) of the buffer. A slight drawback is that this smaller image has its pixels stored with 32 Bits as follows, so you will have to have this fact taken into account later:

[Red | Green | Blue | Alpha]

00000000 00000000 00000000 00000000

Every channel has 8 Bits this time. This is how a single pixel stores the 3 colors (right part is the least significant). The Alpha is the opacity of the pixel. Will Alpha be used in this problem? Yes. How? If Alpha is 100%, the pixel of the smaller image will be completely opaque; if it is 0%, the color will be fully transparent (values in between will fade the color accordingly). The solution would be:

This is a challenge to be accomplished with any programming language and any type of implementation (that is, how you structure it, which data types you choose, totaly up to you as long as you do the task in an efficient way).

Function signature:

overlayImageBuffer ([IN/OUT] buffer, [IN] img2Mix, [IN] xCoord, [IN] yCoord)

Solution: overlayImageInBuffer.cpp

I coded my interpretation of the solution in C++. I used 2D buffer arrays of type char (because C does not provide native data types of neither 16 nor 32 Bits). There is a point that, because the [32 x 32] image has pixels of 32 Bits and not just 16 Bits, I had to choose how to fit those 8 Bit [R|G|B] values into [R|G|B] of 5 and 6 Bits. I chose to use the least significant digits, hence making it an implementation choice.

Anyhow, above is the complete code.

#estudo_android

jose-la-salete — Wed, 18 Apr 2012 23:45:24 GMT

Após conversarmos com o nosso orientador, chegamos à conclusão que o nosso projecto carece de alguma fundamentação e consolidação na escolha do leque de dispositivos móveis mais indicados para os quais estamos a trabalhar.

Cedo decidimos que iríamos trabalhar para dispositivos Android que possuam versões entre 2.2 e 2.3.7. Tal escolha é justificada pelo simples facto de que (segundo estatísticas presentes no website Android Developers) este intervalo representa 86,8% dos utilizadores de Android, por isso logo à partida, estaremos a trabalhar para um leque de mercado extremamente abrangente, havendo assim mais possibilidades de adesão à aplicação.

Figura 1. Tabela que mostra a distribuição dos utilizadores Android.

No entanto não é suficiente apenas nos centrarmos na versão do sistema operativo do dispositivo. Outra característica fundamental e que pode comprometer o desempenho da aplicação é a resolução do dispositivo para a qual estamos a desenvolver a WIP. Uma vez que um dos elementos possui um dispositivo Android recente (Samsung Galaxy S2), pareceu-nos sensato desenvolver para este dispositivo, mas tomar esta decisão sem um pouco mais de fundamentos poderá trazer algumas consequências. Assim, decidimos investigar um pouco mais sobre esta questão.

Figura 2. Tabela que mostra as diferentes categorias dos dispositivos Android relativamente aos seus ecrãs.

O Samsung Galaxy S2 tem um ecrã de alta densidade (240 HDPI), com uma resolução de 480x800 DP’s. Tal como é possível reter, este dispositivo é colocado no grupo dos HDPI, e dos quatro grupos existentes (LDPI, MDPI, HGDPI e XHDPI), os HDPI são os que detêm a maior percentagem de utilizadores, com cerca de 65%.

Figura 3. Gráfico representativo do número de utilizadores Android de acordo com os ecrãs dos seus dispositivos.

Podemos concluir então que esta é uma escolha feliz, pois desta forma estamos a trabalhar para o grupo de dispositivos que tem o maior número de utilizadores Android, potenciando assim o impacto da nossa aplicação e alargando o seu raio de incidência.

Referências: http://developer.android.com/resources/dashboard/platform-versions.html

Onde está o Wally?

henriquemacedo — Wed, 19 Oct 2011 13:08:57 GMT

Estrutura da aplicação

renato-costa — Fri, 07 May 2010 23:07:02 GMT

Boa noite.

Conseguimos ter a estrutura de todos os ecrãs principais devidamente adaptada ao ecrã do simulador, como mostramos nos screens mais abaixo. Esse objectivo foi atingido e o grupo está agora a implementar a funcionalidade propriamente dita da aplicação, nomeadamente os conteúdos audiovisuais (após selecção de um determinado mood), através de streaming a partir do servidor, e também a melhorar a navegação através do focus do simulador.

Este post é em nome de todos os elementos do grupo

João Elvas | Martim Santos | Renato Costa | Ricardo Carvalho | Tiago Figueiredo