[Ancien] Blabla général Making

Testa: Ah ouais, bon concept

Manderr, c'est ridicule. Tout comme les demi pixels.

J'ai fais ce test : dans un event, on attend 0.0sc puis on incrémente une variable. Dans un autre, on attend une seconde, puis on affiche la valeur de ladite variable.
Le résultat est 30.
Par conséquent 30 * 0.0sc = 1sc, donc RM lance les jeux en 30FPS, Relm a raison sur ce point.

Ensuite j'ai refait la même chose mais avec 0.1sc, vu que j'étais sûr que ça marchait bien (pas de faux calculs). Et le résultat est 3.
Donc 0.1sc = 3*0.0sc, et pas 6

Avant de dire que c'est ridicule, saisi un peu le truc... Parce c'est toi qui l'est en essayant de te montrer pro et connaisseur alors que tu n'avais absolument pas lu ce que j'avais écrit. Tu m'as fait le même coup en critiquant ma vidéo sur les collisions et en affirmant qu'il n'y avait que 8 directions et en me proposant une manip pourrie et foireuse, alors que je te soupçonne de ne même pas l'avoir regardée...

Ensuite, je sais pas d'où t'est venue l'idée de faire un test aussi bidon, mais j'en ai refais un, où j'incrémentais dans un event une première variable toutes les 6x 0.0s, et dans un autre event un seconde variable toutes les 0.1s, et lorsque j'appuyais sur F9, les deux étaient égales...
CQFD

Et si tu fais le test avec 3x0,0s, ça donne quoi ?

La première variable est à peu près égale au double de la seconde.

Donc le test d'AristA est faux ? Où est son erreur ?

Oui
Et ensuite, j'en sais rien, tout ce que je sais c'est que c'est foireux

Mon test démontre que dans un dixième de seconde il y a trois 0.0sc, il n'est pas faux du tout :L

Tente si tu veux.

Dans la théorie ton test est correct, dans la pratique, non
Puis de toute façon, on ne va pas s'étaler plus, ce n'est pas une histoire de croyance ou de religion, ce sont des faits, je les ai démontrés, voilà...

Et sinon, je viens de rentrer 100 images successive d'une fonction sans me rendre compte qu'elle était affine et que je pouvais donc me passer de les rentrer manuellement...

Citation :

Dans la théorie ton test est correct, dans la pratique, non.

Son test est autant théorique/pratique que le tien. Tant qu'il n'y a pas d'explication dans la différence de vos résultats, pour moi aucun de vos résultats n'est fiable. C'est dommage, l'idée était intéressante (à défaut de servir à quelque chose ).
Ca n'est pas très scientifique de ta part, manderr, de dire :
Si X est vrai (ta méthode), donc Y est faux (celle d'AristA), juste parce que les résultats te conviennent mieux avec ta méthode de calcul.
Il y a forcément une erreur, soit dans vos méthodes de calcul, soit dans le logiciel. Tu ne voudrais pas savoir situer cette erreur ?

Et parce que je l'ai déjà démontré avant et que tous mes tests allaient dans ce sens.

Et ensuite, ma première hypothèse sur le probable problème du test d'AA, à savoir que les event ne se lançaient pas en même temps s'est révélée vraie lorsque j'ai ajoutée "Attendre touche pressée" au début des deux events (sans oublier de mettre l'incrémentation de la variable dans une boucle). Et le résultat était 60 (61 pour être plus précis)

Manderr, tu dois quand même te rendre compte que la théorie du "RM calcule 2 fois avant d'afficher " n'a pas de sens. A quoi cela servirait de faire le double de calcul alors qu'il serait possible de n'en faire qu'un seul ?

Le gros problème vient du fait que RM indique des temps en secondes, ce qui est loin d'être logique en programmation (l'unité est la frame non pas la seconde ), et qui perd son sens si on prend en compte la granularité du temps due à l'OS (windows ou autre ) phénomène qui implique que le temps entre 2 frames n'est pas constant

Je suis de cet avis aussi mais dans ce cas comment expliquer le temps de wait 0,0 ?
Parce qu'il en faut 60 pour faire une seconde.

Peut être que RM ne calcule simplement rien dans cette durée et a réellement besoin de deux wait 0,0 minimum.

Peut être que RM est en 60fps mais que l'affichage est actualisé seulement une frame sur 2 si il n'y a pas de wait 0.0 ou de mouvement à vitesse maximale.

Peut-être que RM2K3 a été développé avec dans l'idée d'avoir un taux de FPS de 60, que ça a été bridé ensuite pour des raisons de performances (d'affichage), mais que le calcul à 60 FPS a été laissé au cas où ?
Il me semble que Manderr a raison, et que ta question c'est à Enterbrain qu'il faudrait la poser. :p

Ou a Cherry, peut-être qu'il s'y connait là dessus.

L'hypothèse de Zim me paraît la plus plausible. Oui, peut-être que Cherry le sait, mais c'est pas sûr, il faudrait le lui demander

La théorie de la programmation en 60 fps et l'affichage en 30, je l'ai faite la page précédente, vous dormiez.

Manderr, j'ai fais un test différent. J'ai scindé chaque partie en un événement distinct (dont l'appui d'une touche). Lorsque la boucle des 0.0sc est telle quelle dans l'événement en processus parallèle, je trouve 30FPS. Lorsque je mets lesdites commandes dans une boucle/ou étiquettes, je trouve 60FPS.

Ok rm 2k3 le log wtf bourré de bug

C'est ce qui fait son charme

Ça voudrait dire que RMXP ou RMVX sont moins buggués que RM2k3 ?

Ma vision du monde s'écroule.

On ne peut pas non plus aller dans cet extrème AA

Joke s'y connait là-dessus il me semble, il faudrait lui demanderr.

Citation :

demanderr

tu roule les R comme un espagouin killam ^^

Quel insolite calembour!

Citation :

La théorie de la programmation en 60 fps et l'affichage en 30, je l'ai faite la page précédente, vous dormiez.

Ma théorie complète la tienne, Relm. Ca explique pourquoi il y a 60 FPS en prog et 30 en affichage.

AristA : donc le 0,0s aurait une valeur différente selon les cas ? Ou bien est-ce que les évènements parallèles prennent une demi-frame à se relancer, à ajouter au 0,0s ? C'est ça ? (Pas sûr de piger )