Coucou les petits chats.

J'ai un problème a résoudre et comme je suis déja oqp a faire du graphisme je vais laisser vos méninges travailler :p

Exposer du problème :
Actuellement en train de réaliser un petit jeu de course, j'aimerais mettre un timer qui me permettra de connaitre le temps nécessaire pour faire un tour de circuit. L'ennui est qu'en fonction de l'ordinateur ou du fait d’être, ou non , en plein écran le framerate ( cycles / seconde ) est différent. En d'autre terme, si pour parcourir la totalité du circuit j'ai besoin de par exemple 10 000 cycles, le temps total sera différent. Je ne peux donc pas utiliser le chronomètre classique.

J'aimerais savoir si vous aviez une idée pour qu'en fonction du pc de chacun, le temps pour faire un tour de circuit soit dépendant de la vitesse et non pas du framerate.

A savoir :
Le circuit comporte 1500 segments de : -> 400 “d ”
A chaque cycle le joueur avance de sa vitesse qui est de : -> Vitesse“d”
le framerate peu varier entre 24 et 30 cycle/ seconde.

Pourquoi ne pas compter le nombre de cycles, et normaliser à partir de là ?

A 30 FPS, 30 cycles font 1s. Mais à x FPS, 30 cycles font 30/x secondes (en réel), alors qu'on voudrait que ce soit 30 secondes aussi.

Au final, le temps de parcours en cycles se traduit en secondes en divisant le nombre de cycles par 30. Comme ça chacun a son temps dépendant uniquement du nombre de cycles qu'il a mis, ce qui ne dépend pas de la vitesse de son PC. Et quelqu'un qui tourne a 30 FPS est en “temps réel”.

Edit : avec un tel calcul, quelqu'un qui tourne à 24 FPS (qui semble être ton minimum), aura des “secondes” qui durent 30/24 = 1.25s. C'est pas énormissime comme différence et ça peut presque passer inaperçu.

Et pour afficher un timer en permanence, il suffit encore une fois d'afficher le nombre de cycles divisé par 30 (et peut-être converti en MM : SS : DD pour être plus lisible )

En effet c'est une piste a laquelle j'avais pensé.
Mais le temps du circuit ( jeu de course oblige ) est affiché en temps réel. Ce qui implique de connaitre le nombre de cycle /sec dés le début du circuit. ( voir mieux en temps réel ). Mais je trouvait le calcul trés lourd.

réinitialiser le chronomètre
mettre [ Frame] à [0]
répéter indéfiniment
ajouter à [TrackTime] ( (30) / (Framerate))
ajouter à [Frame] (1)
mettre  [Framerate]  à ((Frame) / (chronomètre))
end

Je peux éventuellement faire un calcul sur une seconde et le garder en mémoire pour ensuite faire mon compte.

Lol tu as fais un edit avant mon post

Tu n'as pas besoin de connaître le framerate : il suffit de décréter qu'un cycle fait 1/30 de secondes (par exemple, si tu considères qu'à 30 FPS on est en temps réel).
Alors le temps écoulé pour le jeu est :

mettre [timer v] à ((#cycles) / (30))

Edit (Cresson) : du coup, joueur A tourne a 30 FPS, et fait le circuit en 3000 cycles. Il a donc un temps de 100s. Joueur B tourne à 24 FPS et fait le circuit en 3000 cycles aussi : ça lui a pris 125 secondes de sa vie a faire, mais pour le jeu son temps est aussi de 100s.
Et c'est tant mieux : le FPS va sûrement bouger au cours du temps en fonction de la quantité de choses à afficher. Avoir un temps par cycle fixé permet de ne pas tenir compte de se genre de problème

SBissay wrote:

Tu n'as pas besoin de connaître le framerate : il suffit de décréter qu'un cycle fait 1/30 de secondes (par exemple, si tu considères qu'à 30 FPS on est en temps réel).
Alors le temps écoulé pour le jeu est :

mettre [timer v] à ((#cycles) / (30))

Edit (Cresson) : du coup, joueur A tourne a 30 FPS, et fait le circuit en 3000 cycles. Il a donc un temps de 100s. Joueur B tourne à 24 FPS et fait le circuit en 3000 cycles aussi : ça lui a pris 125 secondes de sa vie a faire, mais pour le jeu son temps est aussi de 100s.
Et c'est tant mieux : le FPS va sûrement bouger au cours du temps en fonction de la quantité de choses à afficher. Avoir un temps par cycle fixé permet de ne pas tenir compte de se genre de problème

Oui c'est top comme idée en effet , cela me permet de faire un calcul de moins.
Par contre

mettre [timer v] à ((#cycles) / (30))

Est un peu rapide par cycle car 1 cycle c'est 1/30 ??

Comme je fait déja mon calcul de FrameRate en temps réel je peux malgré tout m'en servir ?

Non, ça dit : 1 cycle c'est 1/30 secondes. Donc tous les 30 cycles, tu gagnes 1 seconde.

Pour ton FrameRate, tu peux l'afficher, mais s'en servir pour le calcul est un risque : comme je le disais, il va sensiblement évoluer selon l'affichage, et donc tu auras au mieux une moyenne du FrameRate, jamais un FrameRate instantané. Cela va induire des erreurs, certes minimes sur un petit nombre de cycles, mais qui vont s'accumuler…

Encore un édit (Piaf) : je viens de me rendre compte que ma nomenclature n'était peut-être pas claire : “#cycles” signifie “nombre de cycles”, celui que tu comptes depuis le début du tour.

Merci a Cresson et Piaf pour leurs précieux conseils. J'ai vu mon erreur et j'ai mis tout ces bons calculs en place !!

Je te laisse la primeur du résultat :
https://scratch.mit.edu/projects/227346999/

Merci encore !

Eh ben nickel !

C est bien fait quand meme

point towards ((3d::#999)+(100% pen::#125)+(games::#148)+(tests::#589)::custom)::hat pen
create::list