Velocidade do jogo

Mobile
#1

To desenvolvendo um jogo mobile e testando em 3 celulares, e com o mesmo código “Thread.sleep(1)” o jogo fica normal em um celular, em outro fica rápido e no terceiro fica muuuutio rápido. Acredito que isso aconteça por causa da velocidade do processador do celular. Como fazer para que os três fiquem com velocidade semelhante?

#2

Acho que JME não tem algo como FPSAnimator (mas não tenho certeza disso, antes de alguem vir com pedras) que regula automaticamente para você, caso não tenha, vale a pena implementar algo parecido.

Você define um tempo máximo de espera entre a exibição de um quadro e outro (baseado no modelo mais lento), começando a contar a partir do início do desenho do quadro, algo como:

Date inicio = new Date();

.
.
.
desenha frame
.
.
.

Date fim = new Date();
while (fim - inicio < TEMPO_ESTABELECIDO) {
Thread.Sleep(x);
}

#3

Outra possibilidade é lembrar que:
deslocamento = velocidade * tempo.

A velocidade é dada em pixels/ms
O tempo é em ms, e representa o tempo entre duas chamadas ao update do seu jogo.

Do jeito que vc está fazendo, você está assumindo que o tempo entre updates é sempre constante. E isso é muito perigoso. Você pode ter variações de tempo dentro de um mesmo jogo, caso rode uma lógica um pouco diferente da anterior num dos loops.

#4

Concordo, até por isso o tempo de latência (sleep) deve ser calculado baseado no tempo que levou para desenhar o quadro.
Por isso começar a medir o início antes de desenhar.

#5

Sim, no caso que eu falei, não haveria esse sleep. Você poderia usar 100% do processamento. Uma opção mais comum em jogos full screen, ou jogos que monopolizam o dispositivo.

#6 
        // loop inicio

            time = System.currentTimeMillis();

            game.update();

            render();

            time = System.currentTimeMillis() - time;

            if (time &lt; DELAY) 
                Thread.sleep(delay - time);

        // loop fim
#7

Definitivamente essa nao é uma boa estrategia para jgoo de celular.

#8

Mas pode ser boa em palmtops e outros tipos de handhelds.

#9

Como seria isso, o frame rate variaria de acordo com as capacidades do hardware que estivesse processando o jogo?

Creio que com um tempo constante entre os updates é como obtemos um frame rate independente de plataforma.

Vou conferir os jogos no seu blog pra tentar entender como vc fez… mas por acaso vc usa threads?

#10

Não é só assim. Você pode também calcular os deslocamentos dos personagens com base no tempo. Aí, num computador que tenha framerate alto, o deslocamento seria pequeno. E num de frame rate baixo, o deslocamento seria enorme.

É só ver a fórmula que eu passei lá em cima.

#11

Não é só assim. Você pode também calcular os deslocamentos dos personagens com base no tempo. Aí, num computador que tenha framerate alto, o deslocamento seria pequeno. E num de frame rate baixo, o deslocamento seria enorme.

É só ver a fórmula que eu passei lá em cima.[/quote]

O que eu disse, neste caso o frame rate varia mas vc compensa a diferenca no deslocamento dos elementos. Basta duas plataformas a 100% de sua capacidade produzirem frame rates diferentes uma da outra e vc tem um problemao para tratar colisao.

Nao vejo porque palmtops e outros handhelds estao livres desse tipo de problema.

#12

Lógico, seu jogo terá uma taxa de frame rate mínimo.

Acima disso, não existe problemas para colisão. Afinal, o deslocamento entre dois passos do jogo será menor que o inicialmente previsto, o que dificilmente é um problema.

O fato é que também é ridículo limitar um jogador com um dispositivo potente a uma taxa de FPS baixa. Se ele tem hardware para exibir o jogo de uma forma bonita e agradável, porque você vai nivelar por baixo e exibir um gráfico feio e saltado?

Eu não sei como você trata colisão. Mas há técnicas que consideram o deslocamento feito e, mesmo em caso de um FPS muito baixo, detectam a colisão. Agora, geralmente o bom e velho bounding-box cobre a maior parte dos casos, pois costuma a ser suficientemente tolerante.

#13