Com a ajuda do Ademar escolhemos um bom caso de uso. Um “bouncing game”.

O Jogo

As flags

As flags que comentarei neste post são:

• QGraphicsScene::ItemIndexMethod
• QGraphicsView::OptimizationFlags
• QGraphicsView::ViewportUpdateMode

Os resultados

* Os testes foram executados em um Nokia 5800, RM-356 rodando firmware V51.0.006 com Qt 4.6.3.
** O eixo Y dos testes é o FPS. Quanto maior, melhor.

Testes com 10 elementos

Primeiro de tudo, tentei as 4 formas de update da Viewport usando 10 elementos na tela. O MinimalViewportUpdate e o SmartViewportUpdate renderam a maior taxa de FPS (34 e 33.5). A documentação da biblioteca mostra que NoIndex é a melhor opção para cenas dinâmicas. Bem, a diferença é bem pequena, mas é verdade.

Neste caso, para os próximos testes, usarei sempre NoIndex.

E quanto às flags?

Dado os melhores resultado dos últimos testes (SmartViewportUpdate and BoundingRectViewportUpdate) foi feito outro teste com as duas flags de optimização QGraphicsView::DontSavePainterState e QGraphicsView::DontAdjustForAntialiasing. A conclusão foi que estas flags de optimização rendem uma pequena melhora no desempenho, mas somente se você puder controlar precisamente a maneira como seus elementos são desenhados. Caso contrário você pode enfrentar problemas de renderização.

20 elementos

30 elementos

40 elementos

Lições aprendidas

É importante selecionar corretamente a maneira como serão feitos dos updates da Viewport. Isso pode fazer a diferença.

Se existem muitos elementos dinâmicos, e se eles estão espalhados por toda a tela, é mais barato pintar toda a tela (ou pelo menos o bounding rect) do que tentar determinar a área afetada pelo movimento e só pintar estes espaços.

Para ser honesto eu estava esperando um resultado melhor do FullViewportUpdate, mas acredito que obteríamos melhores resultados (do que o BoundingRect) se fosse utilizado um background não estático.

Mas… E se..?

Q:O que aconteceria se fosse utilizado somente um único graphicsItem para pintar todas a bolinhas? O que aconteceria se uma bolinha não fosse um ítem, mas apenas um objeto com um método de renderização?

R: Fiquei um pouco surpreso com o resultado, mas o desempenho do Qt (especialmente os states do QPainter) melhorou muito desde a versão 4.6 e o resultado deste teste obteve resultados piores do que usando vários QGraphicsItems. Esta abordagem obtém melhor rendimento que a abordagem padrão apenas se o número de elementos é maior que 60.

Depois de escrever os testes, o que acontece com o código?

Usando os conhecimentos adquirido pelos testes e com a ajuda de uma das designers do INdT – Nara – estou liberando uma versão de um jogo baseado na engine dos testes. Não está totalmente concluído, faltam alguns elementos, mas já está jogável. =)

Symbian package here!

Por enquanto segue apenas o demo, e em breve a versão completa na Ovi Store mais perto de você!

O fato de sermos usuários Linux não nos afasta mais deste objetivo. O colega Lizardo, não muito feliz com a dependência do Janelas, adaptou com sucesso o famigerado GNUPOC para funcionar com o Qt 4.6.X, dando-nos assim um ambiente agradável de desenvolvimento Qt/Symbian no Linux.

Graças a ele temos qmake, QGraphicsView e QCoisas funcionando da mesma forma como funcionavam no desktop.

E as APIs específicas como GPS, sensores e rede?

A idéia do Qt everywhere inclui abstrair a API não tão bonita do symbian e maemo (e outros) para uma única API Qt.

Seguindo este princípio lançaram, dia 15/02, um pacote beta do Qt-Mobility Project, com classes Qt para sensores, GPS, contatos e etc.

A instalação é simples mas, para quem seguiu os passos do Lizardo, basta utilizar este script e passar o diretório onde o download do pacote foi feito:

qt-mobility-install.sh <directory>

*Observação: Não esqueça de setar as variáveis de ambiente $EPOCROOT e $PATH, de forma que o qmake utilizado seja o da instalação para S60

Óbviamente eu não queria pagar uma grana altíssima numa bateria profissional ou no kit completo do rockband. A Solução? ProbreBand!!!

Na verdade é apenas o início da implementação do Ardrumo, que usa um Arduino e alguns piezos para gerar um sinal  que é enviado para o sequenciador MIDI do mac (Futuramente do Linux? talvez…). Segue abaixo o vídeo.

* Minha irmã sempre disse que eu não tinha ritmo =)

Fiquei meio preocupado com o tempo de resposta e sensibilidade. Mas o tempo de resposta é muito bom (no vídeo parece que tá atrasado, mas só parece), e a sensibilidade fica perfeita quando você prende os piezos em alguma superfície.

Enfim, voltar a brincar com embarcados tem sido divertido, ainda mais aprendendo eletrônica. Breve comento sobre outros brinquedos que estou fazendo (com motor de passo, e um servo que está pra chegar).

Agradecimentos a Jesus (não esse Jesus), que me incentivou a comprar o Arduino, e ao Alex, Thulio, Jeez e Larry que estão me dando dicas de eletrônica. E claro, ao cara do Ardrumo que me fez economizar uma grana. =)

[update: 29/03/2009] A idéia é montar uma estrutura maior de borracha para os sensores, e uma estrutura em PVC para a bateria. Se um dia eu conseguir ponho aqui. A idéia é algo parecido com isso:

Neste meu estudo produzi uma espécie de Data Provider, que é um serviço que fica rodando sobre o DBus e é responsável por receber atualizações de rss de um determinado blog. Os clientes não acessam diretamente o rss mas sim este provider, via canal DBus, e são notificados quando ocorre alguma atualização.

O conceito é simples, o código também. Não estou usando nada como QDBusAdaptors ou classes afins. Na verdade, o exemplo é válido pela didática pois exemplifica uma forma de enviar objetos “estranhos” via DBus.

O código pode ser obtido com:
git clone http://labs.danilocesar.com/git/qdbus-test.git

Ao menos uma das previsões de 2008 saiu =)

[UPDATE 14/01 09:40]

O comando history do bash (também o CTRL+R) guarda apenas o histórico da última sessão aberta, o que é um problema para quem usa mais de um terminal (eu uso o conjunto Xterm + screen).

Para corrigir isto, adicione em seu .bashrc

#Firulas de historico com o bash
export PROMPT_COMMAND="history -a"
export HISTFILESIZE=2000
shopt -s histappend

Trabalhe com quantos terminais quiser, e guarde o histórico de todos!

[UPDATE 07/08/2008]: Tinha um erro na última linha. Obrigado André Matos e Sérgio Silva

WTF???

Outro teste:

OK, já passou da hora usar OpenDNS!

Vou-me embora para Pasárgada
Lá sou amigo do Reis

Novidades:

1 – Estou formado em Ciência da Computação pela UFPR.

2 – Estou deixando Curitiba. Após 22 anos na saudosa Curitiba estou deixando-a, e indo para Recife-PE.

Só tenho o que agradecer a esta magnífica cidade, à minha família que fica por aqui, e aos meus colegas da Mandriva, com os quais pude aprender bastante.

E esperar que este novo desafio seja tão bom e gratificante quanto o antigo.

Quando eu estava tentando sincronizar o teclado com o N800 pude perceber que o SU 8W é um teclado pré-configurado, e com um pouco de paciência encontrei o arquivo de configuração do mesmo: /usr/share/X11/xkb/symbols/nokia_vndr/su-8w

Após 5 minutos estudando a sintaxe, em 10 minutos é possível perceber que falta alguma coisa: Não há, pelo menos, as configurações para português, espanhol e italiano. Agora eu entendo porque a configuração de layout português não funciona.

Já que não existe uma configuração para o idioma definido, utiliza-se o us_intl, certo? Mas a primeira linha da definição do us-intl tem um comentário preocupante: “I can’t belive! It’s not intl”. Parece que a tafera não será assim tão simples.

Para propósito de teste, não criei um novo mapa de teclado para pt_BR e sim editei o us_intl. O resultado ficou aceitável, e finalmente é possível ter um teclado funcional em português. O resultado você pode entrar aqui.(Não esqueça de fazer backup antes de sobrescrever)

Nos próximos dias ponho aqui a solução definitiva.

Resltado final:

Projeto da matéria de Processamento de Imagens, o objetivo era fazer um tracker de pessoas em um determinado vídeo.

Na especificação havia:

• O vídeo será uma sequência de imagens PPM nomeada da forma <nome>_<seq>.ppm. Ou seja, se a sequência se chamar tracker, o primeiro arquivo será o tracker_00.ppm.
• O vídeo será testado em dois casos: No primeiro haverá uma pessoa, no segundo duas.
• As pessoas devem ser marcadas com cores diferentes, e a mesma cor para cada uma das pessoas.
• Em nenhum momento as pessoas se cruzam.

Assim fica fácil! =)

Segue algumas screen shots:

Como de costume, o código está no SVN em:

http://danilocesar.com/svn/pitracker/

E as imagens podem ser encontradas no site da matéria.

Procurando um pouco vi que habilitá-los é fácil.

Primeiro edite o arquivo ~/.pythonrc

#Enable syntax completion
try:
    import readline
except ImportError:
    print "Module readline not available."
else:
    import rlcompleter
    readline.parse_and_bind("tab: complete")

Após isto, em seu ~/.bashrc adicione:

export PYTHONSTARTUP=~/.pythonrc


Agora inicie o python e faça o teste.

Acho que vale a pena ler os comentários antes de ler o texto:

Yes, the fact that the writer thinks that MEPIS is based on Mandriva shows how little knowledge he has, and how poorly researched his paper is..

O que não se faz por uns trocados?

“Não basta colocar um filho no mundo, é preciso alimenta-lo, educa-lo e fazer o possível para vê-lo crescido!”

Pois bem, depois de certo tempo resolvi voltar a mexer no abandonado código do pychord e adicionar algumas funcionalidades que eu precisava.

Após duas tentativas frustradas (0.4.5 e 0.5) percebi que era necessário re-escrever a biblioteca gráfica. Assim foi feito. Adicionei o conceito de janela, conteiner de widgets, melhorei a herança entre classes, etc. A interface não mudou muita coisa, pygame é meio chato para isso.

Ainda estou usando o padrão .chr criado para a primeira versão, mas pretendo adicionar o formato XML opensong em breve.

A parte legal, e a novidade mais visível, é que criei uma heurística para decidir quais linhas são acordes e quais não são. Esta heurística pretendo ir melhorando a medida que for encontrando casos em que ela não funcione.

Para resumir: ao nível de usuário, as modificações foram:

1. Heurística para reconhecer/diferenciar acordes de letra de músicas
2. Mudança de tom
3. Listas clicáveis e móveis
4. Suporte ao Maemo OS2008
5. Controle da luminosidade durante a apesentação das cifras ( o display não apaga durante a mostragem mais )

A parte nerd

A idéia era que o código da interface pudesse ser reutilizada em outros projetos, logo trabalhei para ter uma GUI mais conscistente do que a anterior. Utilizando melhor o conceito de herança foi possível simplificar a utilização da lib, deixando as coisas com menos cara de gambiarra.

Através do conceito de slots ficou bem simples implementar mais de uma action para um mesmo evento.

Screenshots

Tela de busca, não mudou muito de como era anteriormente.

Visualização da cifra

Mudaça de tom.

Como sempre, o arquivo de instalação pode ser pego aqui. Ainda não criei um repositório pois o aplicativo está em fase de testes. Mas pretendo fazer isto em breve.

[UPDATE 03/03/2008] Por problemas de codificação dentro do módulo sqlite3, os textos devem estar em formato UTF-8…

Com estas informações tenho duas perguntas:

Será a Nokia capaz de manter a qualidade da biblioteca QT?

Será que veremos uma licença LGPL para a libQT? Se isto acontecer, será o fim da libGTK?