Ar-S a écrit :Ton perso, s'il avance pixel par pixel tu n'as pas besoin des floats. Il ne va pas se déplacer de 2,3 pixels
Si tu as structuré tes coords de déplacements et les dimensions de tes sprites/décors, ce ne sera pas difficile de gérer la position et les mouvements du sprite en question
Tuuuut tut tut. Attention, le JV c'est compliqué et on peut avoir de très mauvaises intuitions quand on ne s'y connaît pas : Instinctivement, c'est vrai qu'on se dit que si on utilise des chiffres ronds, on aura jamais de problème... Et ça a l'air vrai vu de loin, mais c'est du JV donc c'est compliqué et ça se passe pas comme ça, pour deux raisons principales :
Δt vs Frame pacing
Une des premières question qu'on doit se poser : comment le jeu mesure-t-il le temps qui passe? Doit on dire "mon jeu tourne à 60 fps, donc le personnage se déplace de 3 pixels par frame" -
aka le frame pacing- ou "Mon jeu tourne a 1 seconde par seconde (
) donc mon personnage se déplace de 180 pixels par seconde" -
aka le Δt. Comme ça, ça a l'air identique, mais voici les trois plus grandes différences:
- Si mon jeu rame : En Δt, le jeu va garder son rythme, mais on va "sauter" des étapes. En Frame pacing, le rythme du jeu va ralentir. En fonction du type de jeu, l'un est préférable à l'autre : sur un Danmaku, utilisez exclusivement le frame pacing. Sur un rythme game, seul le Δt compte. Et entre les deux... Bah c'est une question d'importance de vos feedback visuels. Par exemple, sur un jeu de baston, où chaque frame convoie pas mal d'information, on a tendance à préférer le frame pacing (street fighter 5), mais des jeux moins exigents et plus portés sur le spectable font le choix du Δt (Mortal Kombat X).
- Sur des hardware "spéciaux" : vous connaissez les écrans à 144hz? Des écrans pour joueurs, très très agréables à utiliser puisque tout est plus fluide dessus... Ouiiii, mais pour un développeur de jeu ça devient vite un cauchemar : quand on fait du frame pacing, on a tendance à utiliser 60 fps comme vitesse de base; sauf aue 60 hz n'est pas un multiple de 144hz. Et donc, les jeux en frame pacing sur ce genre d'écran, en particulier si le vsync est activé, ont un rendu très désagréable.
- Virgule flottante de partout : en frame pacing, pour peu qu'on ait choisi des nombres entier à la base, alors on aura jamais que des nombres entier; parfait! Mais en Δt... Et bien on travail en milliseconde, 180 pixels par seconde, c'est donc 0.18 pixels par milliseconde et... Bah ouais, on va avoir besoin de float partout, il faut donc y penser dès le début; car la conversion serait longue et douloureuse.
Pixel art vs Gros carrés art
Cherchons une définition de pixel... Disons... C'est
l'unité indivisible de l'image numérique. Bon, bah de nos jours, bonne partie des jeux en "pixel art" ne respectent pas cette définition du pixel : ils font en fait du gros carré art : après tout, si ton jeu est 640*360, il est en fait probablement affiché sur un écran en 1080p (neuf fois plus de pixels), voir même 1440p (seize fois plus) ou 4k (TRENTE-SIX FOIS PLUS!) :
Par exemple, sur ce sémillant Zero, j'ai compté 44 gros carrés de haut; pourtant vous vous rendez bien compte que chaque gros carré est composé de plusieurs pixels sur votre écran.
Et bien voilà le principe du "gros carrés art" : on reprend l'esthétique du pixel art, mais pas ses limitations.
Pour exploiter ces sous-pixels, l'exemple le plus évident, c'est les rotation : voilà le même sprite sur lequel j'ai appliqué une rotation :
Lequel est le meilleur? Là dessus, y'a débat, l'un est clairement plus lisible, l'autre clairement plus respectueux... C'est au choix. Sauf que, comme vous pouvez vous en douter : pour exploiter au mieux les sous pixels, il va falloir utiliser des floats et donc le prévoir dès le début.
Bref, désolé c'était plus long que je ne le pensais, mais c'était pour montrer que dans le jeu vidéo, tout est toujours beaucoup plus compliqué qu'il n'y parait.
