Discussion :

[mazertys17]

Bonjour.

Je travaille sur un jeu mobile et j'ai un problème au niveau du calcul de la vitesse.
En fonction de l'état du smartphone, la vitesse des éléments n'est pas la même or elle devrait l'être.
Je fais appel à votre expertise car je ne sais pas comment résoudre le problème et d'où peut il venir exactement.

Pour la calculer, je procède ainsi, depuis le thread d'affichage GLES (afin qu'a chaque image donnée, la vitesse soit établie en fonction du temps passé avant l'image suivante ) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
 
    long time = 0 ;
    void draw_() {
        float elapsedTime = (System.nanoTime() - time) / 1000000000f;
        time = System.nanoTime();
        ...
        x += speedX*timeElapsed ;
        y += speedY*timeElapsed ;

En fait le problème est visible surtout quand la vitesse de mon objet est modifiée par un flux dont la vitesse est calculée pareillement depuis un autre objet.
Le flux est censé forcer l'objet (un petit robot en apesanteur) a prendre sa vitesse, un peu comme un objet flottant qui serait jeté dans une rivière.
Plus le flux est intense plus la vitesse de l'objet s'adaptera rapidement jusqu'à devenir la même que celle du flux.
Le problème est qu'en calculant la vitesse de l'objet séparément de la vitesse du flux, le décalage était trop grand et l'objet était toujours un peu plus lent au final que le flux.
Pour résoudre le problème j'ai triché en faisant ainsi :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
 
 
        Flux f = Flux.getFlux(x,y, SIZE/2 );
        if ( f != null ){
 
            speedX += (f.getSpeedX() - speedX)*(f.intensity*f.timeElapsed);
            speedY +=  (f.getSpeedY() - speedY)*(f.intensity*f.timeElapsed);
 
            x += speedX*f.timeElapsed ;
            y += speedY*f.timeElapsed ;
 
        }else{
                x += speedX*timeElapsed ;
                y += speedY*timeElapsed ;
        }

En fait si le robot traverse un flux, sa vitesse est calculée en fonction du flux et selon le temps calculé par le flux, sinon il est calculé en fonction du temps du robot.
Ca marche...mais c'est pas net...quand le robot sort du flux on sent une différence mais ce que je ne comprends pas est pourquoi il y a autant de différence alors que la vitesse est calculée de la mène manière.

Si vous voulez mieux comprendre mon problème, vous pouvez télécharger (gratuitement) le jeu déjà disponible sur le google play :

https://play.google.com/store/apps/d...ostinasteroids

Merci si vous pouvez m'aider

[Paul TOTH]

pourquoi f.timeElapsed et non timeElapsed ? le temps doit être le même pour tout le monde..

[mazertys17]

Paul TOTH Merci pour ta réponse.

Oui en fait c'était un bricolage de dernière minute.
Dans l'idéal je pensait que chaque élément allait lui même calculer son propre temps pour être le plus adapté visuellement.
J'espérais que le calcul serait suffisamment précis.

Si j'utilise le même temps pour tout le monde (chose que j'ai essayé de faire aussi), le problème est le même : la vitesse est instable.
Si par exemple il y a beaucoup d'éléments a calculer, alors elle sera plus lente et inversement.

Pourtant le but est de faire en sorte que justement quand beaucoup de temps s'écoule entre les images, ce temps étant utilisé comme facteur de vitesse, la vitesse devrait être stable.

Hélas, il n'en est rien.

[Paul TOTH]

c'est pourtant bien l'idée, au moment du rendu du décompte le temps passé depuis le dernier rendu et tu appliques ce delta temps à la vitesse de chaque élément pour calculer sa nouvelle position.

ceci dit, je ferais plutôt comme ceci

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
//     speedX += (f.getSpeedX() - speedX)*(f.intensity*f.timeElapsed);
//     speedY +=  (f.getSpeedY() - speedY)*(f.intensity*f.timeElapsed);
 
   x += (SpeedX + f.intensity*f.GetSpeedX()) * timeElapsed;
   y += (SpeedY + f.intensity*f.GetSpeedY()) * timeElapsed;

je ne sais pas bien à quoi correspond Intensity, mais ça ne devrait pas affecter SpeedX/Y à priori

[mazertys17]

Ok, en fait l'intensité c'est la force du flux. Plus elle est grande et plus l'objet qui le traverse va changer rapidement pour atteindre celle du flux.

Cependant cela ne change rien au fait que la vitesse est instable au final...
En fonction des performances du téléphone ou du nombre d'objets à calculer, elle varie sensiblement.

Or mon but est d'arriver à une vitesse qui reste stable au maximum quelque soit la situation.
Si par exemple le thread calcule une image en 0.01 seconde ou s'il la calcule en 0.5 seconde, au final l'objet devrait se déplacer à la même vitesse et parcourir la même distance en X secondes.

[Paul TOTH]

Ok, en fait l'intensité c'est la force du flux. Plus elle est grande et plus l'objet qui le traverse va changer rapidement pour atteindre celle du flux.

Cependant cela ne change rien au fait que la vitesse est instable au final...
En fonction des performances du téléphone ou du nombre d'objets à calculer, elle varie sensiblement.

Or mon but est d'arriver à une vitesse qui reste stable au maximum quelque soit la situation.
Si par exemple le thread calcule une image en 0.01 seconde ou s'il la calcule en 0.5 seconde, au final l'objet devrait se déplacer à la même vitesse et parcourir la même distance en X secondes.

c'est la vitesse ou le framerate qui est instable ?

j'ai testé l'appli sur un S8 le déplacement ne m'a pas choqué enfin si, je trouve que l'inertie n'est pas réaliste, mais le mouvement n'est pas saccadé.