Otimizações pro Horus Eye

Projetos
#1

Tive umas idéias de coisas que podem melhorar a performance do Horus Eye.

  1. Ao invés de criar uma textura para a imagem inteira, criar uma textura cada frame.
    Vantagens:
  • Mais improvável de superar o tamanho máximo de uma textura.
  • Ao mover a textura para a memória de video (glBindTexture), uma quantia menor de dados tem que ser transferida assim como uma quantia menor de memória de video é utilizada.
  • Evita fazer as contas para localizar a posição do frame desejado.
  • Simplifica o funcionamento do DrawTo da classe Image.

Desvantagens:

  • Aumenta o número de texturas.
  • Impossibilita que o frame_size seja alterado.
  • Requer que o frame_size seja especificado quando carrega a imagem.

Sobre as desvantagens, eu não sei se a primeira é ruim. A segunda é algo que ja deveria ser desde o começo e a terceira é uma das coisas planejadas quando for implementado o “Image Descriptor” (ou outro nome, não lembro bem, perguntem ao Wilson).

  1. Ouch, já esqueci…

Mas bem, isso é algo que eu suspeito que seja benéfico (em particular pelo que li de como o glBindTexture funciona), mas talvez não esteja correto.

#2

Aproveitando o tópico:

Sugestão do Will (Gnann), de muitos tempos atrás: usar instruções SIMD (tipo SSE sabem?)
Elas podem melhorar pra caramba a eficiência de algumas funções, principalmente cálculos, cálculos vetoriais, coisas que mexem com muitos dados e tal.

Porém não faço idéia de como implementar tal coisa… E como as instruções variam de CPU para CPU (por exemplo, nem todas tem SSE), pode dar algumas complicações na hora de implementar direito… Se bem que maioria das CPUs atuais (e de um tempo atrás tb) tem pelo menos alguns tipos de SIMD.

Então sei lá… :stuck_out_tongue:
Acho que valerá a pena dar uma olhada nisso alguma hora.

#3

De fato, esse tipo de otimização traz ganhos consideráveis de performance. Porém, normalmente se “apela” para elas quando já não é mais factível otimizar os algoritmos - o que ainda não é nosso caso. Mas, mesmo assim, não vou repreender ninguém que tiver coragem o suficiente para tentar trabalhar com isso.

Só gostaria de fazer um adendo ao que o Fernando disse: certamente, instruções desse tipo variam de processador para processador, porém praticamente todos os CPUs que estão por aí (mesmo nos computadores mais idosos - como o servidor do fórum - heheheh) dão suporte a, pelo menos, SSE2.

Vinícius

#4

O que eu sei é que PCs socketA não têm SSE2
…ou seja, todos os single-core da Athlon antes do Athlon64, e os da mesma época mais ou menos da Intel. Ainda assim acho que é safe usar até SSE2, esses PCs hoje em dia são beeeeem velhos…
SSE3 é um pouco mais complicado já, melhor só usar se for mesmo necessário ‘-’.

#5

Acho a política do Dolphin sobre suporte a SSE2 muito válida:
Qualquer pc que seja rápido o suficiente para rodar o programa tem suporte a SSE2.

#6

Link legal: http://www.gamedev.net/page/resources/_ … w-cc-r1987

Outro link legal: http://www.ibiblio.org/gferg/ldp/GCC-In … HOWTO.html
Na verdade esse aí é o que ensina comofas/ pra funcionar no GCC.
(No link anterior está um jeito estranho que não sei qual o compilador que aceita.)

Outra otimização que o Wil e o Henrique lembraram agora: parar de calcular fucking raiz quadrada pra colisão (não faz diferença).