Je veux créer une menue de départ pour un clone Pong où la balle dans l'arrière-plan rebondit les bords. Cependant, la boucle de jeu mette à jour rapidement afin que les coordonnées de la balle sont déjà sorties du JFRAME avant de pouvoir le voir et se déplace rapidement. J'ai trouvé cela à travers des systèmes.
Je suppose que cela a quelque chose à voir avec des fils, mais je ne suis pas sûr.
La classe principale appelle cette classe sous forme de fil, mais la partie importante est dans la classe arrière-plan de la classe inférieure
3 Réponses :
C'est parce que votre maths suce; -)
oui, équivalent à c'est-à-dire, votre code attend correctement de rendre le rendu Première image, mais n'enregistre pas qu'elle a rendu cette image, et pense donc toujours qu'elle est tardive et n'attend plus plus. à la place, vous pouvez essayer quelque chose comme: BTW, il suffit de rester dans une boucle sans fin pour passer du temps n'est pas très efficace. Il serait préférable d'utiliser quelque chose comme Thread.Sleep () pour attendre - mais le calcul du temps qu'il devrait attendre à la main est un peu velu. Heureusement, l'API Java est livré avec de belles classes d'aide à utiliser: (maintenant - lasttime) / ns est la quantité de cadres qui aurait dû être rendu depuis le début du moteur. Par conséquent, votre code simplifie:
Je m'excuse. Je ne comprends pas. Delta = Framessincestart ()? Je ne sais pas ce que vous voulez réaliser avec cela. Aussi où devrais-je attendre? Je veux rendre le plus grand nombre possible de cadres que possible de faire courir ou non?
Je voulais vous montrer où vous avez mal tourné en résumant les détails inutiles. Le problème clé est que votre calcul est faux. Lorsque vous décidez de mettre à jour, vous vérifiez si la mise à jour première aurait dû se passer d'ici, plutôt que de vérifier que les mises à jour moins ont eu lieu que le taux de trame dicté. Et non, vous ne voulez pas rendre () plus souvent que la mise à jour (), car cela revient à repeindre la même image à l'écran encore et encore, ce qui fait de la différence visible, mais des déchets inutilement du processeur et du temps GPU.
Vous n'utilisez pas thread.sleep (). Au lieu de cela, vous attendez jusqu'à ce que System.NanOtime () a changé. Cela signifie que le processeur est en cours d'exécution tout le temps (pas bon).
aussi cette boucle: p> n'a pas de sens parce qu'il pourrait être remplacé par un si . P> Ensuite, vous ne mettez jamais la mise à jour de la variable em> . Donc cette ligne: p> entraînera une fonction quadratique car elle entraînera quelque chose comme celui-ci (chaque exécution de boucle): p> @Override
public void run()
{
while(running)
{
update();
render()
System.out.println("X-Koordinate " + Var.ballX + " " + "Y-Koordinate " + Var.ballY);
Thread.sleep(1000L/60L);
}
}
essayer Une autre chose que vous pouvez essayer est de réduire la vitesse de la balle. P> thread.sleep (long millis) code> private synchronized void update() {
Var.ballX += 0.01;
Var.ballY += 0.01;
}
Les variables BallX et Bally sont des entiers. Même s'ils n'étaient pas des entiers, je ne pense pas qu'il y ait quelque chose comme 1/100 d'un pixel est là?
Tous les 100 appels, il déplacera 1 pixel.