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ê!

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

[UPDATE 14/01 09:40]

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:

“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…

(A linha vermelha indica o que o carro estava fazendo, a linha verde indica o que o GoogleStreetMaps indicava fazer)

Como não quero passar aperto em Sampa semana que vem, e sei que Sorocaba e Itu estão na lista das cidades que o GoogleMaps erra, resolvi escrever um pequeno patch para o Maemo-Mapper, que adiciona a seguinte feature: “Calibrar o Mapa”.

Funciona mais ou menos assim: Ao identificar um erro de deslocamento, o usuário vai no menu Mapas e depois em “Calibrar Mapa”. Logo após clica-se em algum lugar da tela onde ele crê que realmente está.

O ideal mesmo seria parar o carro em uma esquina, identificar a rua onde está e a rua que irá cruzar, e clicar bem em cima.

O algoritmo faz duas coisas muito simples: Calcula a diferença da Latitude e Longitude do clique e da posição real indicada pelo cursor. Em mãos desta diferença, ela será sempre adiciona à Latitude e Longitude na leitura do GPS.

Desta forma conseguiremos andar sempre em cima da rota. O resultado final será algo como:

(Há! bem melhor agora!)

Bom, se o patch mostrar-se útil para mais alguém posso envia-lo à equipe do maemo-mapper… Para mim com certeza o será.

O patch pode ser encontrado aqui, e o pacote para instalar aqui.

É isso, bom fim de semana a todos!

[]‘s

Danilo Cesar

[UPDATE: 15/02/2008] Quase um mês depois…

O mapeamento de Sorocaba é melhor do que eu pensava. Usei o calibrador apenas em um momento, quando entrei na cidade. Excelente trabalho do nosso co-piloto!

Depois, com o calibrador desligado, percebi que o erro era imperceptível em vários pontos, inclusive na chegada do kartódromo de Itu! Por falar em Kartódromo, o Schinchariol é uma exelente opção para os paulistas amantes da velocidade.

Bom, o equipamento é o seguinte: GPS Holux com interface bluetooth, N800 com Maemo-Mapper com trajeto e mapas adquiridos antecipadamente através do Google-Maps.

A saída de Curitiba e boa parte do trajeto até chegar em Londrina foi excepcional! Se havia algum erro de GPS, este foi imperceptível. Eu ficava admirado em ver o ponto azul em uma curva exatamente quando o carro fazia a mesma. Tudo muito sincronizado.

Como nem tudo são flores, chegando em Londrina houve uma grande decepção, pois havia um erro de quase duas quadras ( uns duzentos metros ) em relação ao ponto mostrado no mapa e o ponto onde eu realmente estava.

De duas uma:

1. O GPS está me passando uma informação errada.
2. O Google Maps não mapeou direito às coordenadas de Londrina.

Pessoalmente, a primeira eu acho difícil de ser verdade, uma vez que ele estava funcionando muito bem em Curitiba em meus testes utilizando de 9 a 10 satélites ( onde estou agora, em Londrina, o GPS utiliza 8 ).

A segunda opção eu acho bem viável. Londrina não é uma cidade tão grande, e o mapeamento pode ter sido feito “às coxas”.

A questão é a segunte: Será que em minha passagem por Sorocaba e Itú terei o mesmo problema? Mesmo SP sendo o “coração do Brasil” (sem trolls aqui, por favor), ambas também são cidades de interior.

Por isto eu faço um apelo: Se você é morador de Londrina-PR, Itú-SP ou Sorocaba-SP, e possui GPS: Pegue suas coordenadas e coloque-as no GoogleMaps e verifique se a referência no mapa é realmente onde você está. Depois poste aqui os resultados.

Bom, vou aproveitar minha família agora =)

Abraços a todos e bom fim de semana!

[Update] Hoje com mais tempo vim tentar descobrir o problema, e é mais ou menos o que o Rafael falou. A verdade é que o mapeamento por satélite do GoogleMaps é uma beleza, mas o mapeamento de rua não!

Descrevendo o problema: A rua marcada em vermelho deveria estar no traçado verde. O Google Satelite posiciona-se corretamente, mas o mapa é posicionado com um erro de cerca de 167 metros.

Bom, talvez o Google não seja tão bom assim =)

[Update2] O Google compra as informações sobre mapas da MapLink. Logo o problema está lá!