[Ancien] Blabla général Making

Oui tu vis dans une ville d'ET...

Ce sont des doubles-frames?

J'ai trouvé ça :

Citation :

Un jeu est un programme composé principalement d'une boucle infinie. Cette boucle s'arrête quand l'utilisateur ferme le jeu. Chaque tour de boucle compose une Frame qui est affichée à l'écran. Pour qu'un jeu soit fluide il faut essayer d'avoir 60 Frames par secondes.

Est-ce une constante que dans tous les jeux on doit avoir 60 frames par secondes ? Il semblerait bien.

Ce qui voudrait dire que 0.0 = 1 frame.

Il me semble que c'était la nouveauté du passage XP->VX, l'affichage 60f/s

J'ai l'impression d'être le scientifique qui a découvert que les neutrinos étaient allés plus vite que la lumière, et que ses ignares de confrères ne croyaient pas

Ce que je dis entre pourtant en accord avec ce que tu as dit :

Manderr a écrit:

J'ai posé deux event, l'un qui changait d'apparence au bout de 1s, l'autre au bout de 60x 0.0s, et les deux changaient d'apparence en même temps.

Et les demi-pixels, ça n'existe pas..

Kilam hors sujet.

En fait la norme est apparu avec les ecrans 60 hz a l'epoque les jeux sur les consoles europeenne (jusqu'a la ps2) tourne a 50 frames car les ecrans etaient en 50 hz

La plupart des jeux tournent en 30 frames par seconde. Depuis longtemps. Même aujourd'hui ça reste un standard. Ce standard est (en gros) le même pour n'importe quoi de vidéo (films) vu que c'est ce qui se rapproche le plus de ce que l'oeil peut percevoir.

En gros à part quelques jeux ils tournent tous à 30 frame par seconde. Le gars qui parle de 60 ne parle pas en général mais parle plutôt des FPS sur PC qui nécessites plus d'images par seconde pour ne pas donner envie de vomir car la caméra bouge beaucoup.

Bref, je voudrais savoir si un calcul de moins d'une frame est logique, ce qui ne me semble pas le cas. Si un moteur tourne à 30 frame par seconde, comme 2k3 (il me semble vu que tous les events se base là dessus) une boucle de calcul devrait durer une frame donc il y a maximum 30 boucles par seconde.



Manderr : si tu essaye avec 10 fois plus de temps, ça marche aussi ?

Alex RoiEsper a écrit:

Ce que je dis entre pourtant en accord avec ce que tu as dit :

Manderr a écrit:

J'ai posé deux event, l'un qui changait d'apparence au bout de 1s, l'autre au bout de 60x 0.0s, et les deux changaient d'apparence en même temps.

On est ok alors?
Parce que là j'ai juste l'impression d'être le fou qui raconte de la grosse merde alors que j'ai toujours raison, même quand j'ai tord!

Sinon, tu as essayé avec 10x plus de temps comme le dit Relm?

J'ai laissé tourner le jeu pendant 5bonnes minutes, et il n'y avait aucun décalage.

Peut-être que les calculs de RM se font vite (inférieur ou égal à 1/2 frame), donc Enterbrain a peut-être mis à disposition le 1/2 frame par l'intermédiaire du wait 0,0s pour des programmeurs que ça peut intéresser.

Je viens de vérifier aussi. En effet, tu as raison pour le temps.
Par contre RM 2k3 affiche bien 30 images par seconde donc ça veut dire que malgré que sa sortie vidéo affiche cela il est sur une base de 60 images par seconde ? Ca peut avoir du sens car comparativement à des jeux prévus pour une sortie TV, les jeux PC peuvent avoir un standard de 60 frames par seconde assez souvent depuis l'an 2000.

Si un jour un gars arrive à hacker cela peut être que 2k3 aura la fluidité de VX (bof pas si cool. )

En tout cas, vu que 2k3 affiche seulement 30 images par seconde ça ne sert à rien de lui faire faire 2 fois le même calcul entre un 0,0. Je dirai que ça peut plutôt nuire aux performances.
Si on veut un calcul qui boucle de manière optimal il faudrait le stopper par deux 0,0.

Bon, heureusement 2k3 ne baisse rarement en terme de performances...

C'est le gros merdier, je viens de terminer mes calculs concernant la vitesse de déplacement et d'animation des event selon leur vitesse, et j'ai obtenu des valeurs décimales (1/4 de frames quoi ).
Voyez par vous-même:

Vitesse du mouvement	Coordonnées	Animation
Très lente	5,25s	10,5s
Lente	2,8333333s	7,8333333s
Modérée	1,25s	6,5s
Normale	0,5833333s	5,1666667s
Rapide	0,25s	4,5s
Très rapide	0,0833333s	3,8333333s

Bande de branlos, je veins de passer mes deux dernières heures à récupérer ces données et je vous les offre bien présentées etoo!

T'aurais pu faire un truc utile.

peut tu remplacer les decimaux par des fractions s'il te plait ?

Relm a écrit:

T'aurais pu faire un truc utile.

Au contraire, ce sont des valeurs que j'avais toujours voulu connaître, ne serait-ce que pour coupler "prog. event" avec "prog. pictures"...
Gary: Surtout que l'unité n'était pas la seconde mais le dixième de seconde

Vitesse du mouvement	Coordonnées	Animation
Très lente	31,5	31,5
Lente	16,5	23,5
Modérée	7,5	19,5
Normale	3,5	15,5
Rapide	1,5	13,5
Très rapide	0,5	11,5

*Valeurs exprimées en frames (1frame = 1/30seconde)
C'est sans doute plus pratique avec ces unités

C'est le temps que met un évènement a changé de coordonnées, et a terminer son animation de déplacement ?

L'affichage graphique de RM est limité à 30 FPS, c'est ça ? Tandis que les calculs se font à 60 FPS ? C'est pour ça qu'on peut parler de "demi-frames", parce que l'affichage ne se fait qu'une "frame de calcul" sur deux ? Si c'est ça, je ne comprends pas trop comment il est possible qu'un event "très rapide" prenne 0,5 frame à s'afficher : ça veut dire qu'il existe des quart de frame, c-à-d que RM calcule tous les 0,25 frames à 30 FPS ? Autant je comprenais que les calculs se fassent à 60 fps au lieu de 30, mais 120, j'ai plus de mal à comprendre. Est-ce qu'on peut vraiment récupérer une valeur de 1/4 de frame, ou bien c'est purement théorique ton truc ?

Pour les coordonnées, oui.
Pour les animations, c'est le temps que met l'event pour faire la boucle :"pose normale - pose pied droit - pose normale - pose pied gauche"
Pour le reste, c'est ma faute, je me suis planté dans mes unités, mais c'est corrigé
Mais ça veut bien dire qu'un event en vitesse très rapide avance de 1 case toutes les 1/60s

EDIT : Je viens de retester toutes les valeurs, et elles sont correctes (celles du dernier tableau )

voila un test de moi quand j'ai une journée a perdre.

J'ai envie de dire : WTF?

j'aurais du poster cela ailleurs désolé

Nan nan, c'est bien du making mais j'ai du mal à cerner le principe
Ton PJ se transforme et truc rouge et fait peur aux gentilles chattounette?

une fois rassasié oui tu leurs fait peur (tu es quand même un loup garou).

en faite c'est la base d'un mini jeu que je compte faire, ou le jour tu mène une enquête et la nuit tu doit te nourrir. Sachant que tout les pnj sont consommable tu devra faire gaffe a qui tu mange si tu veux finir l’enquête ^^

En fait dans un programme normal, une frame se décompose en gros en 2 partie : calcul puis affichage. Calculer sans afficher, je vois pas l'intérêt, ça voudrait dire un calcul intermédiaire. Peut être pour avoir la possibilité de mieux gérer certaines valeurs (vu qu'on a pas accès aux valeurs décimales sous RM non ? ).

C'est comme calculer des positions en demi pixel, pour simuler une fonction mathématiques c'est très intéressant, pour un jeu vidéo beaucoup moins (voir même complétement inutile ).

Bref pour moi, des "demi frame" pour les calculs ou des coordonnées en demi pixel, c'est possible mais je vois pas d'utilité à faire ça (pourquoi faire 2 calculs lorsque un seul suffirait ).

Testa: Ah ouais, bon concept