Le mouvement en pixel art : marche, caméra et portes sur iPhone

Pokémon Version Rouge, Pokémon Version Cristal et Pokémon Version Émeraude, un jeu par génération parmi les trois de la Game Boy et de la Game Boy Advance, parcourent tous une cellule de 16 pixels en 16 images à environ 59,73 hertz, soit 3,73 cellules par seconde, et rien dans ce pas n’est confié à une horloge : Émeraude déplace le joueur d’exactement un pixel par image, affiche un dessin d’enjambée et un dessin debout par pas, et fait défiler la caméra sur la même image, du même nombre de pixels.¹²³ Rouge et Cristal arrivent aux mêmes seize images en avançant de deux pixels une image sur deux.⁴ La porte d’Émeraude s’ouvre en quatre dessins tenus cinq images chacun, le joueur est conduit d’un pas forcé à l’intérieur, la porte se referme, puis l’écran s’assombrit en neuf niveaux étagés : au moins 79 images, 1,32 seconde, avant que la carte suivante puisse commencer à se charger.¹⁵ Le monde de Kiradex fait marcher ses personnages selon le temps écoulé et lisse sa caméra, et un modèle de ce code (un modèle, pas une capture faite sur un téléphone) indique que le sprite fait un saut de deux pixels une fois par tuile à 60 hertz, que la caméra prend environ un pixel de retard de plus à chaque tuile d’une marche à 60 hertz (9 pixels à la cinquième, et 13 en course) et s’immobilise 4 à 9 pixels trop court, et que les dessins de marche suivent leur propre horloge, un cycle pour 3,00 tuiles là où celui d’Émeraude en couvre deux.⁶ Apple accorde aux jeux une priorité spéciale à 30 et 60 hertz et RealityKit effectue généralement son rendu à 60 ; le cahier des charges prévoit donc un tick fixe à 60 hertz avec des pas en pixels entiers, des dessins de marche choisis selon la distance parcourue (ma proposition, pas la méthode des consoles portables), une caméra fixe, le cérémonial de la porte d’Émeraude dans nos propres graphismes, trois événements haptiques facultatifs, et 60 hertz plutôt que 120.⁷⁸ Voici le canon mesuré à partir des décompilations, le côté iPhone d’après les pages d’Apple, et le cahier des charges avec les vérifications qu’il doit passer.

En bref

• Un pas est un contrat, pas une vitesse. Chaque table de pas d’Émeraude totalise 16 pixels : la marche, c’est 1 pixel par image pendant 16 images (268 millisecondes par cellule), la course et le surf 2 pendant 8, la vitesse maximale du Vélo Course (Mach Bike) 4 pendant 4, et seul le 2-3-3-2-3-3 du Vélo Cross (Acro Bike) est irrégulier. Rouge et Cristal parcourent les mêmes 16 images par sauts de 2 pixels, à 30 mises à jour par seconde.¹²⁴
• Les jambes et le pas sont synchronisés. Émeraude compte les dessins et le pas en images, séparément, et fait concorder les deux décomptes : la marche est enjambée, debout, enjambée, debout, à 8 images par dessin sur deux cellules de 16 images ; les allures plus rapides divisent la durée d’affichage par deux au lieu d’ajouter des dessins, si bien qu’il y a un appui au sol tous les 16 pixels, à toutes les vitesses. Se tourner à l’arrêt prend 8 images (134 millisecondes), se tourner en marchant ne prend rien, et marcher contre un mur joue un heurt de 32 images.¹⁹¹⁰²
• La caméra, c’est le joueur. La caméra d’Émeraude copie la position du joueur et défile du même nombre de pixels sur la même image, sans retard ni avance, et ne s’arrête jamais au bord d’une carte, car l’extérieur est dessiné à partir de tuiles de bordure. Game Freak a écrit une caméra qui devance le vélo et l’a livrée désactivée.²³¹¹¹²
• Une porte est un cérémonial. Quatre dessins de cinq images (335 millisecondes), un pas forcé de 16 images, la porte qui se referme en 20, et un fondu dont le dernier mélange tombe sur sa 17e image et qui se termine sur sa 22e : au moins 79 images, 1,32 seconde, sans aucune commande, avant que la carte puisse se charger. Cela confirme l’article de cette série consacré aux structures, environ 84 millisecondes par dessin, et corrige les notes de recherche sur lesquelles il s’appuyait, qui indiquaient « 4 ticks each (16 frames, about 0.27 s at 59.7 Hz). » (4 ticks chacun, soit 16 images, environ 0,27 s à 59,7 Hz). Cristal fait un fondu au blanc en 8 images ; Rouge un fondu au noir en 32.^1513144
• Sur iPhone, une cadence régulière à 60. preferredFrameRateRange (iOS 15.0) est une indication ; les iPhone ProMotion fonctionnent de 10 à 120 hertz en douze paliers ; dépasser 60 exige CADisableMinimumFrameDurationOnPhone ; les jeux bénéficient d’une « special priority to 30Hz and 60Hz » (priorité spéciale à 30 et 60 Hz) ; RealityKit « typically limits the refresh rate » (limite généralement la fréquence de rafraîchissement) à 60. Une marche en pixels entiers ne gagne rien à 120 : chaque pixel est simplement tenu pendant deux rafraîchissements.^1571686
• Kiradex aujourd’hui, modélisé et non mesuré. Le code fait marcher à 4 tuiles par seconde selon le temps écoulé, si bien qu’un modèle à 60 hertz constants met 15 images par tuile et avance de 2 pixels sur l’une d’elles ; il lisse puis arrondit la caméra, qui prend de plus en plus de retard au fil d’une marche (5 pixels après la première tuile, 9 après la cinquième, 13 en course) et s’immobilise à 4 pixels du joueur à 60 hertz et à 9 à 120 ; son cycle de marche de six dessins à 8 par seconde couvre 3,00 tuiles par cycle en marchant et 4,50 en courant. Aucun téléphone n’a été mesuré.¹⁷⁶
• Ce que cela apporte à Kiradex : un cahier des charges, pas une version livrée. Un tick fixe à 60 hertz avec des pas de 1 pixel et une règle explicite pour le retard accumulé, des dessins de marche choisis selon la distance, une caméra fixe sur des pixels entiers, la séquence complète de la porte avec un fondu par paliers, un pas refusé rendu visible, trois événements haptiques facultatifs, aucune demande de 120 hertz, et pour chaque point une vérification qu’un journal de mouvement, une capture ou un script peut confirmer.

1. La marche d’Émeraude : seize pixels en seize images

Les deux premiers articles de cette série ont mesuré l’apparence d’un monde en pixels et de ses habitants ; le troisième a mesuré ses bâtiments. Celui-ci mesure le temps : combien de pixels par image, combien d’images par pas, quel dessin s’affiche sur quelle image, combien de temps durent une rotation, une porte et un fondu, et ce que fait la caméra pendant tout ce temps. Les jeux sont lus comme dans les articles précédents, à partir des décompilations par pret des jeux Game Boy et Game Boy Advance publiés, aux commits utilisés précédemment : pokered d2704a6, pokecrystal 5beda23, pokeemerald 731ad5b.¹⁸ Cinq petits scripts ont fait le décompte ; chacun est nommé dans les notes avec sa sortie enregistrée.

Un chiffre d’abord, car tout le reste se compte en images. La Game Boy Advance dessine une image en 280 896 cycles d’une horloge à 2^24 hertz, soit 59,7275 images par seconde et 16,743 millisecondes par image ; GBATEK l’arrondit à « ca. 59.737 Hz ».¹⁹ L’horloge à 4 194 304 hertz de la Game Boy d’origine, divisée par 70 224 points par image, donne les mêmes 59,7275 ; Pan Docs indique « @ 59.7 fps ».¹⁹ Les millisecondes de cet article sont calculées sur la base de 59,7275.¹⁹

Chaque vitesse est une table dont la somme fait seize

Émeraude ne déplace pas un personnage selon la vitesse multipliée par le temps. Chaque vitesse sur la carte du monde est une table de déplacements en pixels par image, et le code source dit ce que toutes ces tables ont en commun : « Over the course of the step animation, these sum to 16 pixels (one full metatile). » (Sur toute l’animation du pas, leur somme fait 16 pixels, soit une metatile entière.)² sStep1Funcs compte seize déplacements d’un pixel, sStep2Funcs huit de deux, sStep4Funcs quatre de quatre, sStep8Funcs deux de huit, et sStep3Funcs fait exception : Step2, Step3, Step3, Step2, Step3, Step3.² Compté par script dans le code du déplacement, cela donne :

Source de chaque ligne : measure_gen3_motion.py sur src/event_object_movement.c.¹

C’est le chiffre de la marche qu’il faut retenir : un pixel à chaque image, seize images par cellule, 3,73 cellules par seconde, 268 millisecondes par cellule, utilisé par PlayerWalkNormal et par chaque PNJ qui marche.¹ Courir avec le bouton B, c’est PlayerRun, et surfer, c’est PlayerWalkFast, que le code annote « same speed as running » (même vitesse que la course) ; les glissades sur la glace appellent la même fonction. Les trois avancent de deux pixels par image, huit images par cellule, 7,47 cellules par seconde.¹¹⁰ Il existe aussi une marche lente, UpdateWalkSlowAnim, qui avance d’un pixel sur les valeurs paires du minuteur, 31 à 32 images par cellule, pour les scènes scriptées.¹

Le Vélo Cross est la seule vitesse aux pixels irréguliers : 2, 3, 3, 2, 3, 3 sur six images, 2,67 pixels par image en moyenne, 9,95 cellules par seconde.¹ On l’atteint par PlayerRideWaterCurrent depuis AcroBikeTransition_Moving, la même fonction que celle des courants marins.¹²⁰ À mon sens, cette irrégularité est le prix d’une vitesse qui ne divise pas seize : trois pixels par image dépasseraient la cellule, si bien que la table alterne des deux et des trois pour tomber exactement sur seize. Toutes les autres vitesses sont des diviseurs entiers de la cellule.

Le Vélo Course accélère par pas plutôt que par image. sMachBikeSpeedCallbacks vaut PlayerWalkNormal, PlayerWalkFast, PlayerWalkFaster, et bikeFrameCounter augmente de un à chaque pas jusqu’à un plafond de 2, si bien que le premier pas depuis l’arrêt prend 16 images, le deuxième 8, et chaque pas suivant 4 : quatre pixels par image, 14,93 cellules par seconde.¹²⁰ Le vélo ne se trouve jamais entre deux vitesses. Chaque pas est l’une des tables, exécutée jusqu’au bout, et la vitesse ne change qu’à une frontière de cellule.

Chaque allure mesurée dans Rouge, Cristal et Émeraude correspond à un nombre entier d’images par cellule de 16 pixels ; les chiffres de Kiradex sont un modèle de son code, pas une capture.¹⁴⁶²¹

Un appui tous les seize pixels

L’animation de marche est enjambée, debout, enjambée, debout. sAnim_GoSouth vaut ANIMCMD_FRAME(3, 8), (0, 8), (4, 8), (0, 8) : le dessin 3 pendant huit images, le dessin debout 0 pendant huit, le dessin 4 pendant huit, de nouveau le dessin debout pendant huit, 32 images en tout, soit deux cellules de marche.⁹¹ La durée est exacte : sprite.c charge la durée de l’image moins un dans le compteur de délai et décompte jusqu’à zéro, si bien qu’une image de durée 8 reste à l’écran pendant huit images.⁹¹ Chaque pas affiche donc un dessin d’enjambée et un dessin debout, et SetStepAnimHandleAlternation démarre chaque nouveau pas sur l’autre moitié du cycle (animPos = {1, 3, 0, 2}), de sorte que la jambe gauche et la jambe droite alternent pas après pas, même quand le joueur s’arrête puis repart.² Le premier article de cette série décrivait le même cycle du point de vue des graphismes : « step, stand, step, stand at eight ticks each, which is the bob everyone remembers. » (pas, debout, pas, debout, à huit ticks chacun, le petit balancement dont tout le monde se souvient.)²²

Les allures plus rapides conservent les dessins et raccourcissent leur durée. GoFast tient chaque dessin quatre images (un cycle de 16 images), GoFaster deux (8 images), GoFastest une (4 images).¹ La course a ses propres dessins, aux durées inégales : sAnim_RunSouth vaut (12, 5), (9, 3), (13, 5), (9, 3), un cycle de 16 images.¹⁹

Mettez les deux tables côte à côte et la conception apparaît. Le cycle de 32 images de la marche couvre deux cellules de 16 images ; le cycle de 16 images de la course couvre deux cellules de 8 ; le cycle GoFaster de 8 images du Vélo Course couvre deux cellules de 4.¹⁹ À toutes les vitesses, un appui tombe tous les 16 pixels.¹ Ce sont deux horloges, pas un seul compteur. Le dessin avance quand animDelayCounter, chargé dans sprite.c à partir de la durée de chaque image, arrive à son terme ; le pas avance quand NpcTakeStep indexe la table de la vitesse avec le sTimer du sprite, une entrée par image ; et SetStepAnimHandleAlternation choisit l’animation de l’allure au début de chaque pas.⁹² Ce qui les maintient ensemble, c’est que les deux se comptent dans les mêmes images et que les durées ont été choisies pour concorder, allure par allure. À mon sens, c’est là ce qu’il faut reprendre : la cadence des dessins ne peut pas se décaler par rapport au mouvement, parce que les dessins de chaque pas durent exactement autant d’images que le pas lui-même. Rien dans ces tables ni dans mon modèle ne mesure où se trouve un pied posé par rapport au sol, je n’affirme donc rien de plus.

Se tourner, se heurter, et quand la commande est lue

Un pas commencé se termine ; la croix directionnelle est lue quand il s’achève, si bien qu’une direction maintenue enchaîne les pas sans interruption et qu’un changement de direction en marchant ne coûte rien.¹⁰ À l’arrêt, c’est différent. CheckMovementInputNotOnBike ne renvoie TURN_DIRECTION que lorsque la nouvelle direction diffère de l’orientation et que le joueur n’est pas déjà en mouvement, et PlayerTurnInPlace joue la marche sur place rapide, à laquelle InitMoveInPlace donne une durée de 8 images : 134 millisecondes pour pivoter sur place.¹⁰¹ C’est ce mécanisme qui permet au joueur de faire face à un panneau ou à une personne sans faire un pas vers eux. Marcher contre un mur joue à la place la marche sur place lente, 32 images, 536 millisecondes, avec un bruit de choc : un pas refusé est montré, pas avalé.¹¹⁰ Les marches sur place normale et plus rapide durent 16 images (268 millisecondes) et 4 (67).¹

À mon sens, ces quatre chiffres représentent l’essentiel de ce que « réactif » veut dire dans un jeu sur grille. Le monde ne se déplace jamais d’une fraction de cellule, l’intention du joueur s’exprime donc en pas entiers, et la seule latence est le reste du pas en cours : au plus 268 millisecondes en marchant, 134 en courant.¹ La rotation depuis l’arrêt n’est pas une latence, mais une action distincte avec son propre résultat visible.

2. La caméra, les portes, les fondus et les secousses d’Émeraude

La caméra n’a ni retard ni avance

La caméra d’Émeraude est un sprite invisible qui suit le joueur. CameraObject_UpdateMove copie le x et le y du sprite suivi et stocke la différence par rapport à l’image précédente dans sCamera_MoveX et sCamera_MoveY ; CameraUpdateCallback transmet cette différence à CameraUpdate, qui fait défiler la carte d’exactement autant de pixels.²¹² La boucle de la carte du monde exécute RunTasks(); AnimateSprites(); CameraUpdate(); UpdateCameraPanning(); dans cet ordre à chaque image, et comme AnimateSprites exécute les callbacks des sprites dans l’ordre des emplacements et que l’objet caméra est créé après le joueur (InitPlayerAvatar, puis InitCameraUpdateCallback(gPlayerAvatar.spriteId)), la caméra lit la position que le joueur a atteinte sur cette même image.³ J’ai suivi cet ordre dans le code sans l’exécuter ; c’est donc une lecture, pas une mesure, mais le résultat qu’elle implique est simple. Le déplacement du joueur et le défilement tombent sur la même image, du même nombre de pixels. À l’écran, le joueur ne bouge jamais, tandis que le monde glisse sous ses pieds.

Itay Keren appelle cela, dans sa conférence de la GDC 2015 sur les caméras de jeux à défilement horizontal, le position-locking (verrouillage sur la position) : la caméra reste sur le joueur, « keeping the car in focus at all times and the camera motion completely predictable. » (en gardant la voiture au point en permanence et le mouvement de caméra entièrement prévisible.)²³ Émeraude ajoute une chose que sa définition laisse ouverte : ce qui se passe au bord de la carte. Elle ne s’arrête jamais. Les cellules situées hors de la disposition d’une carte sont lues via GetBorderBlockAt, qui renvoie les metatiles de bordure 2 par 2 de la disposition, répétées et marquées MAPGRID_IMPASSABLE, si bien que la vue garde le joueur à la même position à l’écran et remplit l’extérieur d’arbres ou d’eau de bordure.¹¹ L’edge-snapping (aimantation au bord) de Keren, l’autre option, « simply snaps the camera to the edge of the level, allowing the character to move away from its anchor point. » (aimante simplement la caméra au bord du niveau, laissant le personnage s’éloigner de son point d’ancrage.)²³ Émeraude s’en est passée en dessinant.

La caméra que Game Freak a écrite puis désactivée

field_camera.c contient une anticipation complète pour le vélo. CameraPanningCB_PanAhead décale le panoramique vertical de 2 pixels par mise à jour, depuis sa valeur de repos de 32 vers 72 ou vers moins 8 selon le sens de déplacement, soit 40 pixels dans un sens comme dans l’autre : une caméra qui devance le joueur vers l’endroit où il va.¹² Elle ne s’exécute que si gUnusedBikeCameraAheadPanback est vrai, la variable n’est jamais mise qu’à FALSE (dans bike.c), et la branche porte le commentaire « this code is never reached. » (ce code n’est jamais atteint.)¹²²⁰ Dans le vocabulaire de Keren, c’est un dual-forward-focus ou un target-focus, la caméra qui suit sa règle : « When you walk left, you want to see more to the left. » (Quand on marche vers la gauche, on veut voir davantage à gauche.)²³ Quelle que soit la raison pour laquelle elle est restée désactivée, le jeu livré a gardé la caméra verrouillée même aux 4 pixels par image du Vélo Course.¹

Une porte s’ouvre en vingt images, pas en seize

La table des portes dans field_door.c se lit comme si chaque dessin prenait quatre images : sDoorOpenAnimFrames vaut {4, -1}, {4, 0}, {4, 0x100}, {4, 0x200}, la porte fermée plus trois dessins ouverts.²⁴ Mais AnimateDoorFrame dessine quand son compteur vaut 0 et avance quand le compteur égale la durée de l’entrée, si bien que chaque dessin reste affiché pendant cinq mises à jour : 84 millisecondes par dessin, 335 pour les quatre.²⁴¹ L’article de cette série sur les structures donnait le même chiffre, cinq mises à jour et environ 84 millisecondes.¹³ Les notes de recherche à partir desquelles cet article a été écrit se trompaient, « 4 ticks each (16 frames, about 0.27 s at 59.7 Hz), » (4 ticks chacun, soit 16 images, environ 0,27 s à 59,7 Hz), tout comme un commentaire dans le code des portes de l’application elle-même, qui dit qu’elle s’ouvre « at about Emerald’s four ticks a frame » (à peu près aux quatre ticks par image d’Émeraude), puis tient le premier dessin 70 millisecondes ; les deux sont corrigés ici et dans le cahier des charges.¹⁴¹⁷

L’entrée elle-même, Task_DoDoorWarp, comporte cinq états dont aucun ne peut être sauté : figer les autres objets, jouer le son de la porte et ouvrir la porte au-dessus du joueur ; forcer un pas MOVEMENT_ACTION_WALK_NORMAL_UP dans l’embrasure ; quand le joueur est immobile, refermer la porte et masquer le joueur ; quand la tâche de la porte se termine, faire un fondu sur la musique et l’écran ; charger la carte.²⁵ La sortie déroule le cérémonial à l’envers : Task_ExitDoor montre la porte déjà ouverte, attend le fondu d’ouverture, force un pas WALK_NORMAL_DOWN, referme la porte, et seulement ensuite rend les commandes.²⁵

En additionnant les décomptes ci-dessus et la trace du fondu ci-dessous, la porte s’ouvre en 20 images, le pas en prend 16 et la porte se referme en 20 ; le fondu qui suit effectue son dernier mélange sur sa 17e image, si bien que l’écran est entièrement sombre après au moins 73 images, 1,22 seconde. La carte ne peut commencer à se charger qu’une fois le fondu devenu inactif, sur sa 22e image, et que Task_WarpAndLoadMap l’a constaté et poursuivi : au moins 79 images, 1,32 seconde.⁵²⁵ Les changements d’état entre les phases de la porte et l’attente de l’arrêt de la musique ne peuvent qu’ajouter des images, ce sont donc deux bornes inférieures.⁵

L’entrée d’Émeraude est une borne inférieure tirée de ses décomptes d’images ; la ligne de Kiradex est lue dans le code des portes de l’application, pas chronométrée sur un téléphone.¹⁵¹⁷²¹

Un fondu, c’est neuf niveaux

Un fondu de téléportation dans Émeraude n’est pas une rampe lisse. BeginNormalPaletteFade fixe un pas de 2 sur un coefficient de mélange qui va de 0 à 16, UpdateNormalPaletteFade mélange les palettes d’arrière-plan lors d’un appel et les palettes de sprites lors du suivant, puis fait avancer le coefficient, et IsSoftwarePaletteFadeFinishing ajoute cinq appels à la fin.²⁶ L’image sur laquelle tombe chaque appel dépend de qui l’appelle. La tâche de la porte lance le fondu depuis RunTasks, et BeginNormalPaletteFade exécute lui-même une mise à jour, copie immédiatement le résultat dans la mémoire des palettes et efface l’indicateur qui, sinon, ferait attendre la mise à jour suivante jusqu’au retour vertical ; plus tard dans la même image, OverworldBasic appelle de nouveau UpdatePaletteFade.²⁵²⁶³ La première image reçoit donc deux mises à jour, toutes deux au niveau 0, et chaque image suivante une seule. Un portage Python de palette.c suivant ce calendrier, en comptant l’image de la tâche comme 0, donne neuf niveaux, 0, 2, 4 et ainsi de suite jusqu’à 16 : les palettes d’arrière-plan atteignent le niveau 2 à l’image 1 et le niveau 16 à l’image 15, les palettes de sprites une image plus tard à chaque fois, le dernier mélange à l’image 16 (285 millisecondes en comptant l’image 0), et le fondu devient inactif à l’image 21 (368 millisecondes).⁵ Un mélange calculé sur une image atteint l’écran au retour vertical qui termine cette image. Le portage suppose qu’aucun fondu n’était en cours et que la mise à jour normale de la carte du monde s’applique ; avec la pluie, la neige, le brouillard, l’ombre ou la sécheresse actifs, le fondu de fermeture se déroule de la même façon à partir des couleurs teintées par la météo (FadeScreen copie d’abord le tampon teinté, puis appelle le même BeginNormalPaletteFade), mais le fondu d’ouverture est géré par le code météo, et ce chemin n’a pas été simulé.⁵

Neuf niveaux espacés de deux seizièmes, arrière-plan et sprites à une image d’écart : la rampe que le cahier des charges adapte à un seul voile.⁵²¹

Les téléportations font un fondu au noir, avec une seule famille d’exceptions, et cette exception a un sens. WarpFadeOutScreen interroge GetMapPairFadeToType sur la paire de types de cartes, WarpFadeInScreen interroge GetMapPairFadeFromType, et chacune appelle FadeScreen avec du blanc quand la réponse est vraie, du noir sinon.²⁵ Toutes deux cherchent la paire dans sTransitionTypes, dont les 16 lignes couvrent chaque type de carte à l’entrée et à la sortie de MAP_TYPE_UNDERGROUND ; la première renvoie l’indicateur d’entrée d’une ligne et la seconde son indicateur de sortie, vrais uniquement sur les lignes qui entrent dans une grotte et uniquement sur celles qui en sortent.²⁷ En entrant dans une grotte, l’écran fait donc un fondu au blanc puis réapparaît depuis le noir, et en en sortant, un fondu au noir puis réapparaît depuis le blanc. Chaque ligne nomme aussi sa propre routine de transition de grotte, que je n’ai pas suivie.²⁷ Un fondu blanc plus lent, FadeInFromWhite avec un délai de 8, devient inactif après 86 ou 87 images, 1,44 à 1,46 seconde ; il est lancé depuis le callback de chargement de la carte, dont je n’ai pas suivi la première image, et le portage donne les deux cas.⁵²⁵

La secousse est un panoramique scripté

La secousse d’écran dans Émeraude est une commande de script, pas un effet physique. ShakeCamera lit un panoramique vertical, un panoramique horizontal, un nombre de secousses et le nombre d’images entre secousses dans quatre variables de script, et inverse le panoramique à chaque secousse.²⁸ Les scripts du jeu en contiennent 24 appels répartis dans 9 fichiers, et un script les a tous comptés :²⁹

Source : measure_gen3_shake.py sur data/**/*.inc.²⁹

Dix des 24 sont la même secousse : un pixel dans chaque sens, huit inversions, cinq images d’écart, 670 millisecondes.²⁹ La plus ample fait 3 pixels à l’horizontale ; la plus longue dure 100 images, 1,67 seconde.²⁹ La secousse de l’ascenseur, que l’article sur les structures a traitée (une secousse toutes les trois images, un nombre de fois qui augmente avec les étages parcourus), est une routine distincte et ne figure pas dans ce décompte.¹³ À mon sens, la leçon est la retenue : une secousse dans Émeraude, c’est un pixel ou deux, réservée à un événement que le script a jugé important, jamais à un pas ou à une porte.

3. Rouge et Cristal : le même pas à 30 mises à jour par seconde

Rouge avance de deux pixels une image sur deux

Pokémon Version Rouge n’a pas de tables de pas. Sa boucle de carte du monde, OverworldLoop, appelle DelayFrame puis tombe dans OverworldLoopLessDelay, qui l’appelle à nouveau, si bien que le monde se met à jour une image sur deux.³⁰ Un pas fixe wWalkCounter à 8, et à chaque passage AdvancePlayerSprite le décrémente et fait défiler les registres d’arrière-plan hSCX et hSCY du vecteur de pas décalé d’un bit vers la gauche : 2 pixels.³⁰ Huit passages de 2 pixels font 16 pixels en 16 images, les mêmes 268 millisecondes et 3,73 cellules par seconde qu’Émeraude, par sauts de 2 pixels à 30 mises à jour par seconde.⁴³⁰ Le vélo ajoute une seconde avancée par passage : DoBikeSpeedup appelle de nouveau AdvancePlayerSprite (sauf sur la Piste Cyclable (Cycling Road) tant que haut, gauche ou droite est maintenu), si bien qu’un pas prend 8 images.⁴³⁰

Les dessins de marche de Rouge changent tous les quatre passages, soit huit images, selon un cycle de quatre images, debout, pas, debout et pas en miroir, si bien qu’il affiche lui aussi un dessin d’enjambée par pas.³¹²² UpdatePlayerSprite incrémente le compteur interne à l’animation à chaque passage et fait avancer le dessin quand il atteint 4.³¹²²

Rouge se tourne en un passage de boucle, deux images : une nouvelle direction depuis l’arrêt écrit l’orientation et revient dans la boucle sans faire de pas.³⁰ Son demi-tour comporte dans le code une orientation intermédiaire que, selon le commentaire du code lui-même, personne ne voit : « It is unlikely for it to ever be visible because DelayFrame is called at the start of OverworldLoop. » (Il est peu probable qu’elle soit jamais visible, car DelayFrame est appelé au début d’OverworldLoop.)³⁰ Je l’ai lu dans le code et ne l’ai pas exécuté dans un émulateur.

La téléportation, c’est un son et un fondu, sans porte dessinée. PlayMapChangeSound joue SFX_GO_INSIDE quand la tuile est une porte (tuile $0b) et SFX_GO_OUTSIDE sinon, puis GBFadeOutToBlack écrit quatre palettes, en maintenant chacune pendant huit images : 32 images, 536 millisecondes.⁴³² Je n’ai pas suivi le fondu de réapparition de Rouge.

Cristal se met lui aussi à jour une image sur deux

Cristal conserve la cadence de Rouge avec un autre mécanisme. MaxOverworldDelay vaut db 2, et le gestionnaire VBlank décompte wOverworldDelay, si bien que les objets de la carte se mettent à jour une image sur deux.³³ StepVectors donne à la marche huit mises à jour de 2 pixels et au vélo quatre de 4 : 16 images et 8 images par cellule, comme Rouge et Émeraude.⁴ Le pas lent compte seize mises à jour de 1 pixel, 32 images, 1,87 cellule par seconde.⁴³³

Les portes de Cristal font un fondu au blanc, et rapide. MapSetupScript_Door commence par FadeOutToWhite et MapSetupScript_Warp se termine par FadeInFromWhite ; chacun compte quatre étapes de palette espacées de deux images, 8 images, 134 millisecondes dans chaque sens.⁴³⁴ Sa rotation est une fonction de pas en quatre parties, StepFunction_Turn, dont les parties s’enchaînent les unes dans les autres. À la première mise à jour, .init1 fixe une OBJECT_STEP_DURATION de 2 et tombe dans .step1, qui la décompte jusqu’à 1 ; à la deuxième, .step1 la décompte jusqu’à 0 et traverse .init2, qui écrit la nouvelle orientation et remet 2, pour tomber dans .step2, qui la décompte jusqu’à 1 ; à la troisième, .step2 atteint 0 et rend l’objet à STEP_TYPE_FROM_MOVEMENT.³³ Rejouée instruction par instruction, la routine prend trois mises à jour, six images à raison de deux images par mise à jour, la nouvelle orientation étant écrite à la deuxième. C’est la routine seule, lue dans le code ; je n’ai pas suivi le temps entre l’appui sur le bouton et le début de la routine.³³

Trois générations, trois fondus

Sources : les décomptes des sections 1 à 3 ;¹⁴⁵²⁵ le pas forcé de Rouge en sortant d’une porte, PlayerStepOutFromDoor, provient de l’article sur les structures.¹³

Les lignes sur lesquelles les trois s’accordent sont celles qui méritent d’être conservées : un fondu entre les cartes, un pas forcé qui fait franchir le seuil au joueur, et aucune commande pendant le cérémonial. Les durées de fondu diffèrent d’un facteur quatre ; à mon sens, la durée est donc un choix de conception plutôt qu’un canon. Le fondu à neuf niveaux d’Émeraude est celui qui a été conçu autour de portes dessinées, et Kiradex dessine ses portes,¹³ c’est donc lui que retient le cahier des charges.

Rouge, Cristal et Émeraude, un jeu par génération parmi les trois de la Game Boy et de la Game Boy Advance, deux machines différentes, ont adopté le même contrat : un pas fait 16 pixels, prend 16 images à environ 59,73 hertz et ne peut pas être interrompu une fois commencé.¹⁴ Rouge y parvient par sauts de 2 pixels parce que sa boucle attend deux images par passage ; Cristal par le même délai de deux images avec des vecteurs de 2 pixels ; Émeraude à la fréquence d’images complète avec des déplacements de 1 pixel. La course, le surf et le vélo suivent le même contrat à 8 ou 4 images.¹⁴ Quand on dit que ces jeux donnent l’impression d’être « sur des rails », je pense que c’est là le rail : le pas, le dessin et la caméra se comptent tous dans les mêmes images, avec des durées choisies pour concorder, si bien qu’ils ne peuvent pas se désynchroniser.

4. Les références modernes : la caméra de Celeste, le vocabulaire de Keren et les portages sur téléphone

Quand une caméra doit lisser, et quand elle ne le doit pas

La caméra verrouillée d’Émeraude est une réponse parmi d’autres dans un vocabulaire qu’Itay Keren a exposé dans « Scroll Back: The Theory and Practice of Cameras in Side-Scrollers », version remaniée de sa conférence à l’Independent Games Summit de la GDC 2015, publiée sur Game Developer le 11 mai 2015.²³ Les termes que j’emploie dans cet article sont les siens. Le position-locking fixe la caméra sur le joueur. L’edge-snapping l’arrête au bord du niveau. Une camera-window ne déplace la caméra que lorsque le joueur pousse le bord de la fenêtre. Le lerp-smoothing fait glisser la caméra vers sa cible, et il le qualifie de « a standard tool in reducing jarring camera speeds, particularly jumps. » (outil standard pour atténuer les vitesses de caméra brusques, en particulier lors des sauts.) Le target-focus et le dual-forward-focus font devancer le joueur dans le sens du déplacement. Il nomme aussi le platform-snapping, le region-focus et les cue attractors, dont un personnage qui marche sur une grille n’a que faire.²³

Il donne la raison pour laquelle le mouvement de caméra compte : « conflicting sensory signals (Visual vs. Vestibular) may lead to discomfort and nausea, and though it’s worse in 3D (especially VR), it is still very much in effect in 2D games. » (des signaux sensoriels contradictoires, visuels contre vestibulaires, peuvent provoquer inconfort et nausée ; c’est pire en 3D, surtout en VR, mais le phénomène reste bien réel dans les jeux en 2D.) Et il donne le cas où le schéma le plus simple est le bon : le position-locking pour « a crafting adventure game like Terraria, with a small character relative to the screen with pretty small jumps, it works very well. » (un jeu d’aventure et d’artisanat comme Terraria, avec un personnage petit par rapport à l’écran et des sauts assez modestes, fonctionne très bien.)²³ Une ville vue de dessus avec un collectionneur de 30 pixels, la taille adoptée par l’article de cette série sur les personnages à la build 34, correspond exactement à ce cas, sauts en moins.³⁵

Celeste est la référence moderne pour l’autre choix. Ses développeurs ont publié la classe Player « as a learning resource and for general interest, » (comme ressource d’apprentissage et par intérêt général), la licence MIT ne couvrant que ce code, et la caméra y tient en quelques lignes : level.Camera.Position = from + (target - from) * (1f - (float)Math.Pow(0.01f / multiplier, Engine.DeltaTime)), sous le commentaire « Camera (lerp by distance using delta-time) » (caméra : interpolation selon la distance, avec delta-time).³⁶³⁷ Avec un multiplicateur de 1 et une cible immobile, cela comble 99 pour cent de l’écart chaque seconde, quelle que soit la fréquence d’images ; or la cible de Celeste n’est pas immobile, puisqu’elle est recalculée à chaque image à partir de la position et de l’état du joueur, si bien que ce chiffre décrit le lissage, pas l’endroit où la caméra finit par se placer.³⁶ La cible est le joueur centré dans la vue du jeu (X - Celeste.GameWidth / 2), limitée aux bornes de la salle, avec des décalages pour quelques états : 48 pixels d’avance dans la direction du dash StRedDash, 64 vers le haut pour le lancement du sommet.³⁶ Le premier article de cette série notait que Celeste effectue le rendu de son monde en 320 par 180 et le multiplie par six.²²

À mon sens, les deux ne se contredisent pas. Celeste lisse parce que les sauts d’un jeu de plateforme tireraient la vue vers le haut et vers le bas à chaque bond ; la définition même du lerp-smoothing selon Keren porte sur les sauts. Un personnage sur une grille se déplace à vitesse constante en ligne droite ; un verrouillage ne produit donc aucune secousse à lisser, et une caméra lissée ne fait qu’ajouter une traîne derrière un mouvement déjà régulier. La section 7 montre ce que mesure cette traîne dans le modèle de Kiradex.

Ce que les autres jeux nous apprennent sur la vitesse

Stardew Valley exprime la vitesse du joueur comme une statistique sans unité : « 2 when walking, » (2 en marchant), « 5 when running, » (5 en courant), « 6.6 when riding a Horse (7 if the horse was fed a carrot that day), » (6,6 à cheval, 7 si le cheval a mangé une carotte ce jour-là), jamais en dessous de 1.³⁸ Le wiki ne dit pas à combien de pixels par tick correspond une unité ; aucun chiffre en tuiles par seconde n’est donc donné ici pour Stardew.

J’ai aussi cherché une source primaire sur les caméras de Sea of Stars, Eastward et CrossCode, sans en trouver : des entretiens sur les déplacements et l’éclairage, rien sur la caméra, et l’option « Pixel Perfect » de Sea of Stars décrite seulement par des guides et des forums. Aucune conférence ni aucun article de Maddy Thorson sur la caméra n’est apparu non plus, ce qui explique que Celeste soit cité à partir de son code.³⁹

Sur téléphone : toucher pour marcher, avec une porte de sortie

La version mobile de Stardew Valley propose neuf schémas de commande, et celui par défaut est « Tap-to-move & Auto-Attack » (toucher pour se déplacer et attaque automatique) : « Tap anywhere on screen and the farmer will walk to where you tapped. » (Touchez n’importe où sur l’écran et le fermier marchera jusqu’à l’endroit touché.)⁴⁰ Garder le doigt appuyé « will cause the character to follow the touch, » (fait suivre le contact au personnage), et le wiki prévient que le mode suivi « is very literal, moving directly towards the finger without routing around blocking objects. » (est très littéral et se dirige droit vers le doigt sans contourner les obstacles.) Le schéma à joystick invisible occupe « the left half of the screen » (la moitié gauche de l’écran), centré là où vous touchez. Et le wiki est honnête sur la limite du schéma par défaut : certaines tâches qui exigent un positionnement précis « can not be completed using the default controls; temporarily switching to a control style with a movement joystick is necessary in such cases. » (ne peuvent pas être accomplies avec les commandes par défaut ; il faut alors passer temporairement à un schéma doté d’un joystick de déplacement.)⁴⁰ Ces schémas sont arrivés avec une mise à jour dont TouchArcade a rendu compte le 1er novembre 2018, avec une option permettant de revenir à « the default tap-to-move and auto-attack controls. » (les commandes par défaut, toucher pour se déplacer et attaque automatique.)⁴¹

Le Pixel Remaster du premier FINAL FANTASY de Square Enix sur iOS a ajouté un réglage par défaut marche ou course dans sa version 1.2.0, datée du 11 mars 2025 dans l’historique de l’app sur l’App Store (la série est publiée sous forme d’apps distinctes, et je n’ai consulté que celle-ci) : « In tap based movement mode the character controlled will always run as the default speed when moving. » (En mode de déplacement au toucher, le personnage contrôlé courra toujours par défaut lors de ses déplacements.)⁴² La prise en charge des manettes était arrivée sur les versions mobiles avec une mise à jour couverte par TouchArcade le 30 janvier 2024.⁴³ Je n’ai trouvé nulle part de documentation du schéma exact de déplacement tactile au-delà de ces notes, ni de description du déplacement de Terraria sur mobile sur la page du wiki que j’ai consultée.³⁹

Les Human Interface Guidelines d’Apple disent la même chose du point de vue de la plateforme. Pour les jeux tactiles : « consider letting players tap objects to select them instead of adding a virtual selection button » (envisagez de laisser les joueurs toucher les objets pour les sélectionner plutôt que d’ajouter un bouton de sélection virtuel) ; « For movement control, opt to show a virtual thumbstick wherever the player lands their thumb instead of a static thumbstick position » (pour le déplacement, affichez un stick virtuel là où le joueur pose le pouce plutôt qu’à une position fixe) ; « Make sure frequently used controls are a minimum size of 44x44 pt » (les commandes fréquentes doivent mesurer au moins 44 × 44 pt) ; « Always include visible and tactile press states » (prévoyez toujours des états d’appui visibles et tactiles) ; et pour la marche et le sprint, « consider combining the actions into a single control. » (envisagez de réunir les deux actions dans une seule commande.) Le journal des modifications de la page date ces pratiques pour les commandes tactiles du 9 juin 2025.⁴⁴ À la WWDC25, la session d’Apple sur les commandes tactiles posait clairement la prémisse : « the vast majority of players won’t have a controller available. » (la grande majorité des joueurs n’auront pas de manette à disposition.)⁴⁵

Aucune de ces sources ne dit que toucher pour marcher est la règle pour les jeux sur téléphone, et je ne le prétends pas. Ce que j’en retiens, comme recommandation pour Kiradex et non comme constat, c’est le schéma que Kiradex suit déjà à moitié : toucher pour marcher par défaut, comme le propose la version mobile de Stardew ; un stick qui apparaît là où se pose le pouce, comme le conseillent les HIG, pour la précision ; et pas de croix directionnelle fixe à l’écran.⁴⁰⁴⁴

5. Le savoir-faire, en règles chiffrées

Voici les règles par rapport auxquelles est rédigé le cahier des charges de la section 7, chacune rattachée à une mesure ci-dessus. « Tick » désigne un pas de simulation de 1/60 de seconde ; c’est ainsi qu’une image à 59,73 hertz devient quelque chose qu’un iPhone peut tenir ; à 16 ticks par cellule, la marche fait 3,75 cellules par seconde au lieu de 3,73.¹¹⁹

Sources du tableau : les décomptes de la marche, de l’animation et des portes d’Émeraude ;¹ ses minuteurs distincts pour le dessin et le pas ;⁹² sa caméra ;¹²³ son fondu et ses secousses ;⁵²⁹ Rouge et Cristal ;⁴³³ Keren et Celeste ;²³³⁶ les recommandations d’Apple sur la cadence d’images, RealityKit et l’haptique ;⁷⁸⁴⁶ les références sur les commandes.⁴⁰⁴²⁴⁴

Deux de ces règles méritent chacune une phrase. La règle du cycle de marche est la plus facile à mal appliquer dans un moteur moderne, parce qu’un système d’animation compte ses propres secondes tandis qu’une marche compte la distance parcourue dans le monde. Les consoles portables maintenaient les deux ensemble en les comptant dans les mêmes images, avec des longueurs choisies pour concorder ; sur un téléphone, où la durée d’image varie, je propose de lire le dessin à partir de la distance parcourue, ce qui donne le même résultat sans seconde horloge à garder synchronisée. Quant à la règle de la fréquence d’images, ce n’est pas un manque d’ambition. Un monde qui avance d’un pixel entier par tick n’a rien à montrer entre deux ticks ; un écran plus rapide ne peut donc que répéter la même image, et la section 6 montre que c’est exactement ce qu’il fait.

6. La manière d’Apple : cadence d’images, horloge de RealityKit et haptique

Le premier article de cette série présentait le moteur sur lequel tourne le monde de Kiradex : une scène RealityKit utilisée comme moteur de rendu 2D, une caméra orthographique, le sol sous la forme d’un unique maillage de quads texturés, les personnages sous forme de quads, et la position de chaque sprite arrondie à des unités entières du monde à chaque image.²² Cette section couvre la partie de la documentation d’Apple qui détermine comment ce monde se déplace dans le temps. Chaque page ci-dessous a été lue telle qu’Apple la publiait le 4 octobre 2026, et la disponibilité indiquée est celle que mentionne chaque page.

La cadence d’images sur ProMotion

CADisplayLink.preferredFrameRateRange (iOS 15.0, iPadOS 15.0, Mac Catalyst 15.0, visionOS 1.0) est une demande, pas un réglage.¹⁵ Le conseil de la page est « Choose a frame rate range that your app can consistently maintain, » (choisissez une plage de fréquences d’images que votre app peut tenir de façon constante), et elle décrit ce que le système fait de la demande : « The system typically provides a consistent frame rate by choosing one that’s a factor of the display’s maximum refresh rate. » (Le système fournit généralement une fréquence régulière en choisissant un diviseur de la fréquence de rafraîchissement maximale de l’écran.) Par défaut, la plage est égale au maximum de l’écran.¹⁵ La plage elle-même est un CAFrameRateRange (iOS 15.0) composé d’un minimum, d’un maximum et d’une fréquence préférée.⁴⁷

L’article d’Apple sur ProMotion donne les chiffres. Les écrans ProMotion basculent entre 24 et 120 hertz sur l’iPad Pro et entre 10 et 120 sur les iPhone compatibles, et les fréquences de l’iPhone forment douze paliers : 120, 80, 60, 48, 40, 30, 24, 20, 16, 15, 12 et 10 hertz ; celles de l’iPad Pro en sont cinq.⁷ La liste des appareils mentionne désormais l’iPhone Air et « iPhone 17 and later » (iPhone 17 et modèles ultérieurs) à côté de « iPhone 13 Pro and later. » (iPhone 13 Pro et modèles ultérieurs).⁷ Sur iPhone, rien au-delà de 60 ne se produit à moins que l’Info.plist de l’app ne règle CADisableMinimumFrameDurationOnPhone (iOS 15.0) sur true : « If you don’t enable this support, Core Animation won’t access higher frame rates (above 60Hz). » (Sans cette prise en charge, Core Animation n’accède pas aux fréquences supérieures à 60 Hz.)⁷¹⁶ Deux phrases de l’article comptent davantage pour un jeu que le reste. La première : « In iOS 15 and later, the system provides games with special priority to 30Hz and 60Hz refresh rates to ensure optimal performance, » (à partir d’iOS 15, le système accorde aux jeux une priorité spéciale pour les fréquences de 30 et 60 Hz afin de garantir des performances optimales), obtenue avec CAFrameRateRange(minimum: 30, maximum: 60, preferred: 60).⁷ La seconde : « Prepare your app to operate at any refresh rate, not just those it requests. » (Préparez votre app à fonctionner à n’importe quelle fréquence de rafraîchissement, pas seulement à celles qu’elle demande.)⁷ Et pour tout ce qui s’anime : « Always use targetTimestamp to drive any animation, physics, or other time-related content provided in your CADisplayLink callback » (utilisez toujours targetTimestamp pour piloter l’animation, la physique ou tout autre contenu lié au temps dans votre callback CADisplayLink) (targetTimestamp date d’iOS 10.0).⁷⁴⁸

La session de la WWDC21 « Optimize for variable refresh rate displays » couvre à la fois ProMotion sur iPad Pro et les écrans Adaptive-Sync sur Mac.⁴⁹ Pour les écrans Adaptive-Sync du Mac, elle modifie la recommandation antérieure d’Apple : sur un écran à fréquence fixe, « we’ve previously recommended that you slow down your rendering to hit the next factor of the display’s fastest refresh rate » (nous recommandions jusqu’ici de ralentir le rendu pour atteindre le diviseur suivant de la fréquence maximale de l’écran) ; sur Adaptive-Sync, « You should instead attempt to present frames at the highest rate your app can do so evenly. » (Essayez plutôt de présenter les images à la fréquence la plus élevée que votre app peut tenir de manière régulière.)⁴⁹ Le mot que j’en retiens pour un téléphone est evenly, régulièrement.

L’horloge de RealityKit

Le monde de Kiradex ne possède pas de display link. Il avance sur l’événement par image de RealityKit, SceneEvents.Update (iOS 13.0), « An event invoked once per frame interval, » (un événement déclenché une fois par intervalle d’image), dont le deltaTime est « The elapsed time since the last update. » (le temps écoulé depuis la dernière mise à jour.)⁵⁰⁵¹ RealityView (iOS 18.0) documente précisément cette voie pour le travail par image, « you can use a System or directly subscribe to the engine’s SceneEvents.Update, » (vous pouvez utiliser un System ou vous abonner directement à SceneEvents.Update du moteur), et ne propose aucun réglage de fréquence d’images qui lui soit propre.⁵² L’article d’Apple sur les performances de RealityKit indique la fréquence à attendre : « RealityKit typically limits the refresh rate, » (RealityKit limite généralement la fréquence de rafraîchissement), qu’il définit comme la fréquence à laquelle le framework effectue le rendu des mises à jour pour l’écran, « to 60 frames per second (fps). » (à 60 images par seconde.)⁸ Je n’ai pas mesuré si RealityView effectue réellement son rendu à 60 ou à 120 sur un iPhone 18 Pro Max ou un iPhone Duo, et la section 7 fait de cette mesure la première vérification du cahier des charges.

Pourquoi 120 hertz n’apporte rien à une marche en pixels entiers

Voici le calcul, tiré du même script de modélisation que celui utilisé à la section 7 pour le code actuel de l’app, appliqué cette fois à la proposition : un monde qui avance sur un tick fixe à 60 hertz, un pixel par tick, l’écran affichant ce que le dernier tick a produit. Sur un écran à 60 hertz, chaque pixel du monde est affiché pendant exactement un rafraîchissement.⁶ Sur un écran à 120 hertz, en une seconde, 59 des 61 positions sont tenues pendant exactement deux rafraîchissements et deux pendant un seul.⁶ Sur un écran à 80 hertz, les durées alternent entre un et deux rafraîchissements, 42 positions tenues une fois et 19 deux fois.⁶ À mon sens, le cas à 120 hertz est le cas à 60 hertz dessiné deux fois, et le cas à 80 hertz est une cadence irrégulière : un pixel qui reste tantôt 12,5 millisecondes, tantôt 25.

Pour un monde en grille sur iPhone, la question n’est donc pas 120 hertz mais une cadence régulière à 60 : un tick de simulation fixe à 60 hertz, des déplacements entiers par tick, des animations comptées en ticks, et un moteur de rendu qui affiche le dernier tick. C’est aussi ce qui rend le mouvement indépendant de la fréquence que choisit RealityKit. La session de la WWDC21 fait une remarque voisine sur les écarts de temps. Lorsqu’une image lente fait sauter un callback au display link, l’écart dont il faut avancer est « not 8ms, but rather 16ms » (non pas 8 ms, mais 16 ms) ; la session ajoute qu’une app qui « uses time delta to advance the state of your custom drawing » (utilise l’écart de temps pour faire avancer l’état de son dessin personnalisé) va « slow down your custom drawing by one frame » (ralentir son dessin personnalisé d’une image) chaque fois qu’un callback est sauté, ce que je comprends comme une app qui avance des 8 millisecondes attendues plutôt que du temps réellement écoulé, et elle dit qu’on « can instead keep track of a previous targetTimestamp so that you can advance the state correctly. » (peut plutôt garder une trace du targetTimestamp précédent afin de faire avancer l’état correctement.)⁴⁹

Haptique

Core Haptics (iOS 13.0, iPadOS 13.0, Mac Catalyst 13.0, visionOS 1.0) construit un CHHapticPattern, « An object representing a haptic waveform, » (un objet représentant une forme d’onde haptique), à partir de dictionnaires, de tableaux d’objets CHHapticEvent ou d’un fichier AHAP.⁵³ Les événements sont de deux types haptiques, hapticTransient et hapticContinuous ; les transitoires sont des « brief impulses that occur at a specific point in time. » (impulsions brèves qui se produisent à un instant précis.)⁵⁴ Chacun accepte les paramètres hapticIntensity, hapticSharpness, attackTime, decayTime, releaseTime et sustained.⁵⁵ Un CHHapticEngine les joue, et capabilitiesForHardware() indique si l’appareil en est capable.⁵⁶

La voie la plus simple est UIImpactFeedbackGenerator (iOS 10.0), « A concrete feedback generator subclass that creates haptics to simulate physical impacts, » (une sous-classe concrète de générateur de retour qui crée des retours haptiques simulant des chocs physiques), dont les styles décrivent « The mass of the objects in the collision » (la masse des objets lors de la collision) (light, medium, heavy, soft, rigid) ; impactOccurred(intensity:) date d’iOS 13.0, et la page range init(style:view:) sous « Initializing the feedback generator » et init(style:) sous Deprecated.⁵⁷⁵⁸⁵⁹ prepare() ne réduit la latence que s’il a le temps d’agir : « Calling prepare() and then immediately triggering feedback (without any time in between) does not improve latency, » (appeler prepare() puis déclencher immédiatement le retour, sans délai entre les deux, n’améliore pas la latence), et le moteur repasse au repos après que « A short period of time passes (typically seconds). » (une courte période s’est écoulée, généralement quelques secondes.)⁶⁰ En SwiftUI, sensoryFeedback(_:trigger:) (iOS 17.0) « Plays the specified feedback when the provided trigger value changes, » (joue le retour indiqué lorsque la valeur de déclenchement fournie change), y compris .impact(weight:intensity:).⁶¹

La page des HIG sur la lecture des retours haptiques en constitue la moitié conceptuelle. « Avoid overusing haptics, » (évitez d’abuser des retours haptiques)⁴⁶ avec la raison : « Often, the best haptic experience is one that people may not be conscious of, but miss when it’s turned off. » (Souvent, la meilleure expérience haptique est celle dont on n’a pas conscience, mais qui manque quand on la désactive.) « Make haptics optional. » (Rendez les retours haptiques facultatifs.) Faites correspondre « the intensity and sharpness of a haptic with the intensity and sharpness of the animation it accompanies. » (l’intensité et la netteté d’un retour haptique à celles de l’animation qu’il accompagne.)⁴⁶ La netteté peut traduire une expérience « that’s soft, rounded, or organic, or one that’s crisp, precise, or mechanical. » (douce, arrondie ou organique, ou au contraire vive, précise ou mécanique.)⁴⁶ Et des retours haptiques personnalisés peuvent rendre « a collision or a hit » (une collision ou un coup) très différents « from subtle experiences like the approach of footsteps or a looming danger. » (d’expériences subtiles comme des pas qui approchent ou un danger imminent.)⁴⁶ Une marche à 3,75 pas par seconde pendant des minutes est exactement le cas que vise la première règle.¹

Commandes

Les API de commandes tactiles, dans les termes de la section 4. Touch Controller (iOS 26.0, iPadOS 26.0, Mac Catalyst 26.0, visionOS 26.0) est résumé sur sa page par « Integrate onscreen touch controls into your Metal-based games » (intégrez des commandes tactiles à l’écran dans vos jeux basés sur Metal) : boutons, croix directionnelles, sticks, manettes de gaz et pavés tactiles, exposés via un GCController.⁶² Son TCDirectionPad (iOS 26.0, iPadOS 26.0, Mac Catalyst 26.0) peut être configuré « to behave as either a composite direction pad » (pour se comporter comme une croix directionnelle composite) ou « as four separate buttons. » (comme quatre boutons distincts.)⁶²⁶³ Le plus ancien GCVirtualController (iOS 15.0) est « A software emulation of a real controller that you configure specifically for your game. » (une émulation logicielle d’une vraie manette, que vous configurez spécifiquement pour votre jeu.)⁶⁴ Une adresse que j’ai essayée, developer.apple.com/documentation/touchcontrols, a renvoyé une erreur 404 ; la page du framework est touchcontroller.³⁹

Ce que cela coûte

Rien dans cette section n’a été chronométré sur un téléphone. La durée d’image du monde sur l’appareil, le coût d’un accumulateur à 60 hertz et le coût d’un moteur haptique maintenu en marche tant que le monde est à l’écran ne sont pas mesurés ; les vérifications du cahier des charges, à la section 7, sont rédigées pour mesurer les deux premiers.

7. Le cahier des charges : ce que Kiradex construit et les vérifications à passer

Où en est la marche aujourd’hui

J’ai lu le code de la marche, de la caméra et des transitions du monde dans le dépôt de Kiradex le 4 octobre 2026, sans le modifier, et j’en ai écrit un modèle image par image. Tout ce qui figure dans cette sous-section est soit lu dans ce code, soit calculé par le modèle, et il est précisé lequel des deux. Le modèle effectue chacune des opérations Float du code sur 32 bits, dans l’ordre du code, avec l’arrondi de Swift, à exactement 1/60 ou 1/120 de seconde par image, et laisse de côté les bords de la carte, la charnière de l’iPhone Duo et le décalage des pieds, dont aucun ne modifie une marche en ligne droite au milieu de la carte. C’est un modèle du code. Ce n’est pas une capture, et aucun téléphone n’a été mesuré.¹⁷⁶

Ce que fait le code, d’après sa lecture :

• La commande, c’est toucher pour marcher, et rien d’autre. La scène convertit un toucher en point du monde, puis touche un collectionneur ou le kiosque, ou appelle walk(to:). Pas de glisser, pas de croix directionnelle, et aucun appel haptique nulle part dans la cible de l’app : une recherche de UIImpactFeedbackGenerator, sensoryFeedback et CHHaptic ne trouve rien.¹⁷
• Le chemin est une recherche du plus court chemin dans huit directions, ordonnée selon le coût parcouru jusque-là, sans estimation de la distance restante, ce qui en fait une recherche de Dijkstra plutôt qu’un A* ; les diagonales coûtent √2 et ne coupent jamais l’angle d’un mur. Un pas en diagonale est orienté de côté et divise sa progression par √2 après application du facteur de course de 1,6, si bien que, dans le modèle, un pas en diagonale prend 22 images en marchant et 14 en courant à 60 hertz, contre 15 et 10 pour un pas en ligne droite.¹⁷⁶
• La vitesse, c’est du temps. tilesPerSecond vaut 4, soit 64 pixels par seconde, et la marche devient une course à 1,6 fois cette vitesse quand le chemin compte 6 pas ou plus ; une marche dans l’app fait donc de 1 à 5 tuiles, et tout ce qui est plus long se fait en courant. Chaque image ajoute dt × speed / length à la progression d’un pas, et quand la progression atteint 1, le personnage saute à la tuile suivante et la progression revient à 0, l’excédent étant jeté.¹⁷
• Le dessin de marche est choisi selon le temps. La colonne est cycle[Int(walker.clock * framesPerSecond) % count], avec framesPerSecond à 8 et les cycles de marche et de course de six dessins de la forge. L’article de cette série sur les personnages indiquait la même cadence, « the walk at eight frames a second » (la marche à huit images par seconde), ce qui décrit fidèlement le code.¹⁷³⁵
• La caméra lisse, puis arrondit. À chaque image, elle se déplace de (target - current) * min(1, dt * 6) vers le joueur puis arrondit les deux axes à des unités entières ; elle est bornée à la carte quand la carte est plus grande que la vue. La phrase du premier article selon laquelle chaque sprite et la caméra « are rounded to whole world units each frame, after easing » (sont arrondis à des unités entières du monde à chaque image, après lissage) est elle aussi exacte.¹⁷²²
• Portes et téléportations. La porte affiche immédiatement le dessin entrouvert de la planche et le dessin ouvert au bout de 70 millisecondes, puis retire la porte 1,4 seconde plus tard ; le pas sur la téléportation attend 220 millisecondes puis change de lieu. L’article sur les structures décrivait cela comme une lacune connue.¹⁷¹³
• Les transitions sont des push de navigation avec leur animation par défaut ; un changement d’étage remplace la scène par identité, sans fondu ; quitter appelle dismiss(). Le seul voile de l’app est la superposition noire de la visionneuse de cartes, animée avec .easeOut(duration: 0.25).¹⁷
• Aucune demande de fréquence d’images. Pas de CADisplayLink, de preferredFrameRateRange ni de CADisableMinimumFrameDurationOnPhone dans l’app ou son fichier de projet ; le monde avance sur SceneEvents.Update avec le deltaTime de l’événement.¹⁷

Ce que ce code produit à l’écran selon le modèle, à durée d’image constante :

• Un saut de deux pixels une fois par tuile à 60 hertz. À 60 hertz, une marche prend 15 images par tuile, 4,00 tuiles par seconde, et les 16 pixels de chaque tuile se répartissent en 14 images de 1 pixel et une image de 2 : un saut de 2 pixels par tuile, cinq sur une marche de cinq tuiles. Émeraude avance d’exactement 1 pixel à chaque image.⁶¹
• Des 0 et des 1 irréguliers à 120 hertz. À 120 hertz, la marche prend 30 images par tuile et les 16 pixels de chaque tuile se répartissent en 16 images de 1 pixel et 14 sans déplacement, entrelacées de façon irrégulière.⁶
• La course est plus lente que sa constante. À 60 hertz, la course prend 10 images par tuile, 6,00 tuiles par seconde, alors que 4 fois 1,6 donnerait 6,4, parce que l’excédent de chaque tuile est jeté ; les 16 pixels de chaque tuile se répartissent en 4 images de 1 pixel et 6 de 2. À 120 hertz, elle prend 19 images par tuile, 6,32 tuiles par seconde ; la vitesse de course dépend donc de la fréquence d’images.⁶
• Une caméra qui traîne et n’arrive jamais. En marchant à 60 hertz, la caméra prend environ un pixel de retard de plus à chaque tuile, de 5 pixels à la fin de la première tuile à 9 à la fin de la cinquième, la plus longue marche que fasse l’app, et la position du joueur à l’écran change sur 8 des 73 images de la marche après la première. En course, c’est-à-dire sur tout chemin de 6 tuiles ou plus, elle traîne de 13 à partir de la deuxième tuile. À 120 hertz, elle atteint 9 dès la première tuile, en marchant comme en courant, puis s’y maintient. Quand le joueur s’arrête, la caméra s’immobilise à 4 pixels de lui à 60 hertz et à 9 à 120, et y reste : dès que l’écart multiplié par min(1, dt × 6) est inférieur à un demi-pixel, l’arrondi renvoie la même position à chaque image. Le côté où elle s’immobilise dépend de la direction de la dernière marche. Dans Émeraude, la traîne et le décalage au repos sont tous deux nuls.⁶
• Les dessins suivent leur propre horloge. Le cycle de six dessins à 8 par seconde dure 0,75 seconde. Mesuré à partir des positions du modèle entre les débuts de cycles successifs à 60 hertz, il couvre 3,00 tuiles en marchant et 4,50 en courant (4,80 à la vitesse nominale de course de 6,4 tuiles par seconde, que l’excédent jeté ne lui permet jamais d’atteindre) ; le cycle de deux appuis d’Émeraude couvre 2,00 tuiles. À mon sens, un cycle qui couvre moitié plus de terrain que ses appuis se voit comme des pieds qui glissent, mais le modèle ne mesure pas où un pied se pose au sol. Le dessin se trouve aussi sur le fil du rasoir toutes les 15 images, à 60 comme à 120 hertz, quand l’horloge multipliée par 8 tombe exactement sur un nombre entier, la frontière entre deux dessins : conserver l’horloge sur 32 bits, comme le fait l’app, plutôt que sur 64, change le dessin affiché sur 9 des 11 images de ce type en 12 tuiles de marche à 60 hertz, et sur 14 des 23 à 120.⁶
• Un second toucher en plein pas fait reculer le personnage. Ce point est lu dans le code, ni modélisé ni capturé : walk(to:) remet la progression à 0 alors que la tuile du personnage est encore l’origine du pas, si bien que l’image suivante dessine le personnage jusqu’à 15 pixels en arrière de l’endroit où il se trouvait ; les déplacements d’autres collectionneurs venant du serveur font de même.¹⁷

Pixels par image affichée : le canon est régulier, le code d’aujourd’hui (un modèle, pas une capture) ne l’est pas, et un tick fixe reste régulier à 120 aussi.⁶²¹

La caméra lissée et arrondie, selon le modèle : elle traîne pendant la marche ou la course et s’arrête trop court à la fin de la marche.⁶²¹

Rien de tout cela ne préjuge de la sensation en main, puisqu’aucun téléphone n’a été mesuré. Les durées d’image réelles fluctuent, ce qui modifiera la répartition exacte des 1 et des 2. La traîne et le décalage au repos dépendent eux aussi de la durée d’image, parce que le pas de lissage min(1, dt × 6) en dépend, d’où les 4 pixels au repos à 60 hertz et les 9 à 120 dans le modèle. À mon sens, une fluctuation dans la plage qu’un téléphone présente normalement en modifiera l’ampleur sans les supprimer ; la condition est que les images restent plus courtes que 1/6 de seconde, environ 167 millisecondes, car à cette durée le facteur de lissage atteint 1 et la caméra rejoint le joueur en une image, si bien qu’un à-coup assez long comble l’écart sur cette image.¹⁷⁶ Le décalage entre les dessins et la marche ne dépend pas de la fréquence d’images : une horloge de dessin à 8 par seconde face à une marche de 4 tuiles par seconde donne 3,00 tuiles par cycle à 60 hertz et à peu près autant à 120. Celui de la course en dépend, 4,50 tuiles par cycle à 60 hertz et 4,75 à 120, parce que l’excédent qu’elle jette à chaque tuile en dépend.⁶

Le cahier des charges

Chaque point comprend une modification de Kiradex/World/, sa justification, et une vérification qu’une ligne de journal, un script ou une capture peut confirmer. Aucun élément graphique, aucun nom ni aucun son tiré des jeux n’est proposé : les chiffres relèvent de la mécanique, tandis que les graphismes, les sons et les mots appartiennent à Kiradex.

1. Marcher au tick, pas à l’horloge.

Modification. Ajouter un accumulateur à 60 hertz à la mise à jour du rig. Chaque callback ajoute son dt ; si l’accumulateur contient alors plus de 8 ticks de temps (133 millisecondes), l’excédent est jeté et inscrit dans le journal de mouvement sous la forme d’une ligne dropped avec ses millisecondes ; ensuite, chaque tick entier présent dans l’accumulateur s’exécute, chacun soustrayant un tick. L’accumulateur compte le temps en unités entières (nanosecondes, ou le 1/60 000 000 de seconde du modèle), jamais en secondes à virgule flottante : avec un accumulateur Double ou Float, le 600e tick d’un test de dix secondes tombe, à certaines fréquences, à une erreur d’arrondi de sa limite, et le décompte donne 599. C’est la règle du retard accumulé : jusqu’à 8 ticks de retard sont rattrapés au callback suivant, et tout ce qui dépasse est traité comme une suspension, si bien que le monde reprend là où il s’était arrêté au lieu de courir pour rattraper son retard. Le chiffre de huit est choisi pour couvrir toutes les fréquences de la liste d’Apple pour les iPhone ProMotion, jusqu’à 10 hertz, qui exige 6 ticks par callback.⁷ Dans le modèle, dix secondes de callbacks à chacune des douze fréquences exécutent exactement 600 ticks sans rien jeter, alors qu’un plafond de 4 ticks par callback en exécuterait 480 à 12 hertz et 400 à 10.⁶ Après un à-coup d’une seconde à 60 hertz, la règle exécute 8 ticks au callback suivant puis 1 à chacun des suivants, et inscrit 866,7 millisecondes jetées ; le même à-coup avec le retard conservé sous un plafond de 4 exécute 4 ticks sur 19 callbacks d’affilée, l’avance rapide que la règle existe pour empêcher.⁶ Chaque personnage conserve un nombre de ticks de pas au lieu d’une progression fractionnaire, et son décalage dessiné est ce nombre multiplié par ses pixels par tick : des entiers exacts, si bien que les personnages n’ont plus besoin d’arrondi. La marche, c’est 1 pixel par tick, 16 ticks par tuile ; la course, 2 pixels par tick, 8 ticks, en conservant la règle actuelle selon laquelle un chemin de 6 pas ou plus se fait en courant. Les pas en diagonale, que la recherche de chemin autorise, conservent le √2 que le code prévoit déjà et son ordre, c’est-à-dire l’allure de course appliquée avant la division par √2 : une diagonale en marchant prend 23 ticks (16√2 vaut environ 22,6, arrondi à l’entier supérieur) et une diagonale en courant 12 (8√2 vaut environ 11,3, arrondi à l’entier supérieur), chacune déplaçant 16 pixels sur chaque axe sur les ticks où floor(16 × t / 23) ou floor(16 × t / 12) change.¹⁷ En marchant, cela fait 1 pixel sur 16 des 23 ticks et aucun sur les 7 autres ; en courant, 1 pixel sur 8 des 12 ticks et 2 sur 4, la seule allure irrégulière du cahier des charges, comme le Vélo Cross est la seule allure irrégulière d’Émeraude.¹ Il n’y a aucun excédent à jeter.

Pourquoi. Les règles de marche et de course de la section 5 ; et, dans le modèle, le saut de 2 pixels par tuile à 60 hertz et les 0 et 1 irréguliers à 120.⁶¹

Vérifications. Un argument de lancement -motionLog consigne le tick et les x, y du joueur à chaque tick, ainsi que chaque ligne dropped. Sur la démo d’orientation existante, qui fait une tuile dans chaque direction, un script vérifie que chaque tick de marche avance d’exactement 1 pixel, que chaque tuile prend 16 ticks et qu’aucun tick n’avance de 2. Une démo de diagonales, un pas en diagonale en marchant et un en courant dans chaque direction, vérifie 23 ticks et 12, 16 pixels sur chaque axe par pas, des déplacements par axe de 0 ou 1 pixel en marchant et de 1 ou 2 en courant, et une diagonale en courant plus rapide qu’une diagonale en marchant. Des tests unitaires fournissent à l’accumulateur des séquences de dt fictives en unités entières exactes : dix secondes à chacune des douze fréquences de l’iPhone, de 120 à 10 hertz, exécutent 600 ticks sans rien jeter, et un trou d’une seconde à 60 hertz exécute 8 ticks au callback suivant, puis 1 par callback, avec 866,7 millisecondes consignées comme jetées. Le même journal de mouvement sur un iPhone 18 Pro Max et sur l’écran intérieur d’un iPhone Duo donne le même nombre de ticks par tuile : la fréquence de l’écran ne doit pas modifier la marche.

2. Choisir le dessin de marche selon la distance.

Modification. Ce point est ma proposition, pas une copie : Émeraude cadence ses dessins en images, en accord avec ses pas, et ne les lit pas à partir de la distance.⁹² Pendant la marche, choisir la colonne d’après la progression de la marche comptée en pas, c’est-à-dire les pas terminés depuis le début de la marche plus les ticks du pas en cours divisés par sa longueur : walkCycle[floor(steps × walkCycle.count / 2) % walkCycle.count], deux appuis pour deux pas, et de même pour la course. Sur un pas en ligne droite, cela revient à la distance parcourue sur 32 pixels, floor(distancePx × 6 / 32) mod 6. Sur une diagonale, on compte le pas plutôt que sa longueur en √2, si bien qu’un appui tombe toujours au début de chaque pas, avec une enjambée plus longue ; c’est mon choix pour des dessins conçus pour des enjambées en ligne droite. Afficher le dessin debout à la fin de la marche, comme le fait Émeraude. Laisser les horloges d’attente, de clignement et d’émotes telles quelles. Un cycle cadencé au tick pourrait lui aussi concorder avec les pas, comme celui d’Émeraude, mais six dessins sur 32 ticks exigeraient des durées inégales de 5 et 6 ticks ; compter la progression ne nécessite pas de seconde table et vaut pour toute allure que l’app ajoutera.

Pourquoi. Un appui tous les 16 pixels à toutes les vitesses, et une cadence qui ne peut pas se décaler par rapport au mouvement ; le cycle actuel couvre 3,00 tuiles en marchant et 4,50 en courant dans le modèle.¹⁶ Cela tranche aussi les « eight frames a second » (huit images par seconde) de l’article sur les personnages : à 1 pixel par tick, six dessins sur 32 pixels changent tous les 5,33 pixels, soit 11,25 dessins par seconde, pas 8.³⁵

Vérification. À partir du journal de mouvement et de la colonne affichée : les deux dessins de contact (walk_a et walk_d dans le cycle de la forge) apparaissent à 0 et à 16 pixels, à un près, sur chaque tranche de 32, à 60 comme à 120 hertz ; sur la démo de diagonales, ils apparaissent au premier tick de chaque pas.

3. Finir le pas ; garder le toucher ; ajouter un stick flottant.

Modification. Un toucher en plein pas planifie à partir de la tuile vers laquelle on marche, pas depuis l’origine, et le pas en cours se termine d’abord ; le compteur de pas n’est jamais remis à zéro. Les déplacements serveur des autres collectionneurs suivent la même règle. À l’arrêt, un toucher dont le premier pas change l’orientation fait pivoter pendant 8 ticks avant le déplacement. Un toucher sur une cellule bloquée voisine du joueur, ou sur la tuile située devant lui, le fait se tourner vers elle et joue un heurt de 32 ticks avec le retour haptique de refus du point 6. Garder un doigt appuyé le fait suivre, comme dans le schéma par défaut de Stardew, mais en passant par la recherche de chemin existante chaque fois que le doigt franchit une tuile, puisque le suivi de Stardew ne contourne pas les obstacles et que le nôtre le peut. Un stick flottant, à quatre directions, désactivé par défaut, apparaît là où se pose le pouce, construit sur un geste de glisser SwiftUI au-dessus du monde ; tout élément dessiné mesure au moins 44 sur 44 points. Le stick de Touch Controller (iOS 26) ne remplace le glisser que si une build de test montre qu’il se dessine par-dessus la RealityView : Apple présente le framework comme destiné aux « Metal-based games » (jeux basés sur Metal), sa session de la WWDC25 dit qu’il « integrates directly with Metal, » (s’intègre directement à Metal), et le monde de Kiradex est dessiné par RealityView sans passe de rendu propre.⁴⁵⁶²

Pourquoi. Les règles du pas, de la rotation, du pas refusé et des commandes de la section 5.^14044624517

Vérifications. Un test d’interface touche une tuile 6 cases à l’est, puis 120 millisecondes plus tard une tuile 6 cases au nord ; le journal de mouvement ne montre aucun tick où le x du joueur diminue, et la tuile du premier pas est atteinte avant le changement de direction. Un test d’interface touche le mur à côté de la maison ; le journal montre un changement d’orientation et un heurt de 32 ticks, sans changement de position. Avec le stick activé, un glisser maintenu vers la droite pendant 60 ticks à partir du premier tick de mouvement termine trois tuiles au tick 48, en commence une quatrième alors que le stick est encore maintenu, et la termine au tick 64 après le relâchement : le journal montre le joueur 4 tuiles à l’est, sur une tuile entière, le pas en cours au moment du relâchement étant terminé, sans arrêt entre les tuiles.

4. Verrouiller la caméra.

Modification. Remplacer le lissage par une caméra placée au même tick que le déplacement du joueur, uniquement à partir de pixels entiers du monde : camera = clamp(player + foldOffset, low, high). Chaque terme reste entier, car aujourd’hui seul l’arrondi final rend la caméra entière : les bornes et le décalage de charnière sont fractionnaires. La position du joueur est entière grâce au point 1. Le décalage de charnière, que follow calcule en points multipliés par displayScale / pixelScale, est arrondi une fois à des pixels entiers du monde, au moment où la charnière change. Les bornes sont arrondies vers l’intérieur, la basse vers le haut et la haute vers le bas, car la demi-taille de la vue en pixels du monde n’est pas forcément entière : fit divise les pixels d’écran de la vue par un nombre entier de pixels d’écran par texel, si bien qu’une vue d’exemple de 393 sur 852 points en 3x obtient 7, une vue de 168,43 pixels du monde de large et une demi-largeur de 84,21, et les bornes de la caméra deviennent 85 et la largeur de la carte moins 85, de sorte qu’aucune image ne montre ce qui se trouve au-delà du bord de la carte.¹⁷⁶ Quand la carte est plus petite que la vue, les bornes s’inversent, comme le permet la borne actuelle, et le même arrondi vers l’intérieur garde toute la carte dans la vue. Conserver la limitation à la carte ; la règle de la section 5 autorise à borner ou à dessiner l’extérieur, et la caméra de Kiradex ne dépasse le bord de la carte vers les bois que lorsque le Duo est à moitié ouvert, d’une marge de tuiles entières.¹⁷ Traiter le décalage de charnière comme fixe jusqu’à ce que la charnière change ; quand il passe de a à b, le faire progresser par a + round((b − a) × i / 8) pour i de 0 à 8, un niveau tous les 2 ticks, la cadence du fondu, si bien que chaque position intermédiaire est un pixel entier ; un passage de 0 à moins 37, par exemple, passe par 0, −5, −9, −14, −19, −23, −28, −32 et −37.⁶ Conserver la parallaxe des bois, calculée à partir de la caméra verrouillée et arrondie comme aujourd’hui. Pas d’anticipation vers la destination touchée : Game Freak en a construit une et l’a laissée désactivée, et la destination d’un toucher pour marcher est déjà à l’écran.¹²

Pourquoi. La règle de caméra de la section 5, et la traîne du modèle, qui augmente au fil d’une marche jusqu’à 9 pixels à la cinquième tuile et atteint 13 en course, ses changements de la position du joueur à l’écran, et ses décalages au repos de 4 et 9 pixels.⁶

Vérifications. D’après le journal de mouvement, la caméra moins le joueur est constante à chaque tick d’une marche sur la place dégagée (zéro, ou le décalage de charnière) et reste la même après l’arrêt du joueur, et chaque valeur de caméra est un nombre entier. Un test unitaire appelle fit avec la vue de 393 sur 852 points en 3x, fait marcher le joueur jusqu’aux deux bords d’une carte et vérifie des positions de caméra entières qui s’arrêtent à 85 et à la largeur de la carte moins 85 ; le même test change ensuite la charnière et vérifie que la caméra atteint le nouveau décalage en passant par 9 positions en pixels entiers, espacées de 2 ticks, et qu’aucun tick intermédiaire ne sort des bornes. Pour une capture, les dessins de marche ne conviennent pas comme repère, car la forme des pieds change d’un dessin à l’autre ; une build de débogage dessine un repère d’un texel, dans une couleur utilisée nulle part ailleurs, à la position de l’entité du joueur, et un script le retrouve dans chaque image d’une marche de 6 tuiles sur la place dégagée : le même pixel d’écran sur chaque image. Près du bord de la carte, c’est le repère qui bouge et non la caméra, uniquement par pixels entiers.

5. La porte, le pas et le fondu, dans les graphismes de Kiradex.

Modification. Entrer par une porte, c’est-à-dire par une téléportation dotée d’une planche de porte. Aujourd’hui, la porte s’ouvre une fois que le personnage est arrivé sur la cellule de la porte : le onStep du pas trouve la téléportation sur cette tuile et y appelle openDoor.¹⁷ Émeraude ne laisse jamais le joueur se tenir dans une porte fermée : TryDoorWarp ne se déclenche que lorsque le joueur, sur la cellule du dessous, pousse vers le nord contre une porte, et Task_DoDoorWarp ouvre la porte une cellule plus haut puis force le pas jusqu’à elle.⁶⁵²⁵ Le cahier des charges recule le déclencheur d’une cellule pour faire de même :

1. Quand le pas suivant du chemin mène sur une téléportation de porte, la marche s’arrête sur la cellule précédente, et l’entrée commence là, au tick 0. Geler les commandes et jouer le son de la porte, un son de Kiradex.
2. Ouvrir la porte en quatre créneaux de 5 ticks, les quatre dessins d’Émeraude à cinq images chacun (83 millisecondes par créneau à 60 ticks par seconde, là où les cinq images d’Émeraude font 84 ; 20 ticks en tout), à la place de l’actuel dessin entrouvert immédiat et du dessin ouvert à 70 millisecondes : fermée, entrouverte, ouverte, ouverte. La planche de porte de Kiradex compte trois dessins, fermée, entrouverte et ouverte (le door_sheet() de la forge en dessine trois, et l’app la charge avec SpriteSheet.bundled(name, columns: 3, rows: 1)), là où la porte d’Émeraude compte la porte fermée plus trois, si bien que le dessin ouvert se prolonge sur le quatrième créneau. Un quatrième dessin issu de la forge, entre entrouverte et ouverte, remplirait ce créneau à la place ; c’est un graphisme facultatif, pas une exigence. Corriger le commentaire qui parle de « four ticks » (quatre ticks).²⁴¹⁷
3. Faire faire au joueur un pas forcé de cette cellule jusqu’à la cellule de la porte, 16 ticks. Les portes de la ville se trouvent dans la rangée inférieure d’un bâtiment, avec des cellules du bâtiment de part et d’autre et au-dessus, et le chemin ne coupe jamais l’angle d’un mur ; ce pas se fait donc toujours vers le haut depuis la cellule du dessous, comme celui d’Émeraude.¹⁷
4. Masquer le personnage et refermer la porte, les créneaux à l’envers (ouverte, ouverte, entrouverte, fermée), 20 ticks.
5. Faire apparaître sur le monde un voile noir en 9 niveaux d’opacité étagés (0, 2/16 et ainsi de suite jusqu’à 16/16), le niveau i au tick 2i du fondu, si bien que le dernier niveau tombe au tick 16 et se maintient jusqu’au tick 17 : 18 ticks. C’est une adaptation, choisie, et non le minutage d’Émeraude. Les palettes de sprites d’Émeraude atteignent chaque niveau sur les mêmes images paires que ce voile, ses palettes d’arrière-plan une image plus tôt, et après le dernier mélange à l’image 16, il exécute cinq mises à jour de finition avant de devenir inactif à l’image 21 ; un voile unique n’a pas de seconde couche en retard ni rien à finir.⁵ Ne jamais animer l’opacité de la vue qui contient la RealityView elle-même ; la visionneuse de cartes a appris cette leçon au premier article.²²
6. Pousser la destination avec les animations désactivées, et faire disparaître le voile selon les mêmes 9 niveaux.
7. Arriver sur le paillasson intérieur, orienté vers le haut. La sortie inverse le tout : arrivée sur la cellule de la porte avec la porte ouverte, un pas forcé vers le bas de 16 ticks, la porte se referme, puis les commandes.

Les étages, qui aujourd’hui remplacent la scène sans fondu, reçoivent le même voile, sans porte ni pas forcé. Quitter une pièce, qui aujourd’hui appelle dismiss(), reçoit le voile et le pas forcé vers l’extérieur.

Pourquoi. Les règles de la porte, du fondu et du cérémonial de la section 5 ; aujourd’hui, le lieu change 220 millisecondes après le pas, la porte affiche deux dessins à 70 millisecondes d’intervalle, et l’écran glisse sur le côté.¹⁵¹⁷

Vérifications. Le journal de mouvement compte les ticks à partir de celui où la marche s’arrête sous la porte. Il montre le joueur encore sur cette cellule, et les créneaux de la porte aux ticks 0, 5, 10 et 15 (fermée, entrouverte, ouverte, ouverte) ; le pas forcé aux ticks 20 à 35, 1 pixel par tick, atteignant la cellule de la porte au tick 35 et jamais avant ; les créneaux de fermeture aux ticks 36, 41, 46 et 51 ; le premier niveau du voile au tick 56 ; et le push pas avant le tick 74. Une marche qui se termine sur une cellule de porte sans cette séquence échoue à la vérification. Le journal de mouvement consigne aussi l’opacité du voile à chaque tick : 9 valeurs distinctes, chacune tenue 2 ticks, aux ticks 56 à 73 à l’aller, et les mêmes 9 au retour. Un enregistrement d’écran le confirme sur une partie de l’image qui reste immobile : l’image entière ne convient pas, car l’eau du sol, sur une carte qui en comporte, change de dessin 4 fois par seconde et d’autres collectionneurs peuvent se déplacer ; un script échantillonne donc un pan de mur de bâtiment choisi à l’avance, sans tuile animée ni personnage qui passe dessus dans l’enregistrement, et compte 9 niveaux distincts à l’aller et 9 au retour, chacun tenu 2 images, à une près à 60 hertz.¹⁷ Dans un enregistrement d’écran d’une téléportation, le monde ne se déplace jamais horizontalement : aucun glissement de navigation.

6. Haptique : trois événements, et un interrupteur.

Modification. Un seul CHHapticEngine détenu par le monde, démarré quand il apparaît et arrêté quand il disparaît, avec un interrupteur Retours haptiques dans les réglages, activé par défaut et respectant le réglage haptique du système. Les motifs, conservés sous forme de fichiers AHAP dans le bundle :

Les valeurs d’intensité et de netteté sont mes points de départ, pas des mesures, et sont destinées à être ajustées sur un appareil. UIImpactFeedbackGenerator(style: .soft, view:), avec prepare() appelé au début d’une marche, sert de solution de repli là où capabilitiesForHardware() indique que Core Haptics n’est pas disponible.

Pourquoi. La règle haptique ; les recommandations d’Apple citées à la section 6.^46565760

Vérification. Un argument -hapticLog consigne chaque événement. Une entrée par une porte scriptée consigne exactement 2 événements de porte, aux ticks 5 et 10 du décompte du point 5, et aucun par pas ; avec l’interrupteur désactivé, aucun du tout.

7. Fréquence d’images : 60, régulièrement.

Modification. Aucune dans l’Info.plist : ne pas ajouter CADisableMinimumFrameDurationOnPhone, car le monde ne gagne rien à 120. Conserver la RealityView ; le tick du point 1 rend le mouvement indépendant de la fréquence à laquelle elle effectue son rendu. Si un display link est un jour ajouté, régler CAFrameRateRange(minimum: 30, maximum: 60, preferred: 60) pour bénéficier de la priorité accordée par Apple aux jeux.⁷⁶

Vérifications. Consigner un histogramme de SceneEvents.Update.deltaTime sur une marche de 60 secondes sur un iPhone 18 Pro Max et sur un iPhone Duo, écrans extérieur et intérieur. Le cahier des charges suppose que le mode est de 16,7 millisecondes ; s’il est de 8,3, l’accumulateur du point 1 maintient quand même la marche à 16 ticks par tuile, et le journal le prouve. Les lignes dropped du journal de mouvement : aucune lors d’une marche normale, à l’une comme à l’autre fréquence.

8. Une secousse, pour un seul moment.

Modification. Une secousse de caméra en texels entiers, 1 texel, 8 inversions, 5 ticks d’écart, réservée à un événement qui la mérite, par exemple la révélation d’une carte rare sur la place, accompagnée du retour haptique de la carte levée. Pas pour les portes, les pas ou les arrivées.

Pourquoi. La plus courante des 24 secousses d’Émeraude, et leur retenue.²⁹

Vérification. Le journal de mouvement montre le décalage de la caméra alternant entre plus et moins 1 texel aux ticks 0, 5 et ainsi de suite jusqu’à 35, puis revenant à 0 au tick 40.

Ce qui ne figure pas dans ce cahier des charges

• Lissage ou anticipation de la caméra sur la grille. Il n’y a pas de sauts à lisser, et Game Freak a livré son anticipation désactivée.¹²²³
• 120 hertz pour le monde. L’objectif est une cadence régulière à 60 ; 120 montre chaque pixel deux fois.⁶
• Un retour haptique à chaque pas par défaut.⁴⁶
• Une croix directionnelle fixe à l’écran. Ma recommandation est toucher pour marcher, plus un stick flottant facultatif.⁴⁴
• Les sons ou jingles de porte ou de téléportation des jeux. Les sons relèvent de l’expression, et Kiradex a besoin des siens.
• Vélos, surf, glace et courants. Les personnages de l’app marchent et courent, rien de plus, et les vitesses ci-dessus sont consignées pour le jour où cela changera.¹⁷

La question ouverte : le minutage sur un appareil

Chaque chiffre du modèle dans cette section suppose un intervalle constant de 1/60 ou 1/120 de seconde entre les images. Savoir si RealityView effectue son rendu à 60 ou à 120 sur un iPhone 18 Pro Max ou un iPhone Duo, et dans quelle mesure son deltaTime fluctue, n’a pas été mesuré ; l’histogramme du point 7 est la première chose à lancer, et le point 1 est rédigé pour que la réponse ne change rien à la marche, quelle que soit la fréquence de la liste des iPhone d’Apple.⁶⁸⁷

Points clés

Si vous dessinez les graphismes

• Dessinez la marche pour une distance. La marche d’Émeraude, c’est deux enjambées et deux positions debout sur 32 pixels, tenues pendant des images qui correspondent à ses pas, et les allures plus rapides réutilisent les dessins avec des durées plus courtes au lieu d’ajouter des images, si bien qu’un appui tombe tous les 16 pixels à toutes les vitesses.¹⁹²
• Un cycle de six dessins convient, à condition que le moteur le joue sur une distance fixe ; joué à une fréquence fixe face à une marche cadencée séparément, sa cadence se décale par rapport au mouvement, 3,00 tuiles par cycle en marchant et 4,50 en courant dans le modèle de notre code.⁶
• La porte d’Émeraude, c’est la porte fermée plus trois dessins, chacun à l’écran pendant 84 millisecondes. Une planche de trois, fermée, entrouverte et ouverte, comme celle de Kiradex, remplit les quatre créneaux en tenant le dessin ouvert sur deux d’entre eux, ou bien la forge en dessine un quatrième ; dans les deux cas, dessinez l’état ouvert comme quelque chose qui vaut la peine d’être vu.¹²⁴¹⁷

Si vous construisez le moteur

• Faites avancer le monde sur un tick fixe avec des déplacements en pixels entiers qui divisent la tuile, lisez les commandes à la tuile, et laissez le moteur de rendu afficher le dernier tick. Dites ce qu’il advient d’un retard accumulé : le nôtre rattrape jusqu’à 8 ticks et jette le reste, en le consignant. Les tables de pas d’Émeraude sont le modèle : chacune totalise 16.²¹⁶
• Verrouillez la caméra sur le joueur au même tick, avec des bornes et des décalages en pixels entiers, pour que rien n’ait besoin d’être arrondi ensuite. Lisser puis arrondir fait traîner la caméra derrière un joueur qui marche et, dans le modèle de notre code, l’arrête 4 à 9 pixels trop court jusqu’à la marche suivante.³⁶
• Sur iPhone, ne demandez pas 120 hertz pour du mouvement en pixels. Apple donne la priorité à 30 et 60 pour les jeux, RealityKit effectue généralement son rendu à 60, et une marche en pixels entiers à 120 ne fait que tenir chaque pixel pendant deux rafraîchissements.⁷⁸⁶
• Faites vos fondus par paliers, pas en rampe lisse. Le fondu de porte d’Émeraude compte neuf niveaux espacés de deux seizièmes, son dernier mélange à la 17e image et le fondu terminé à la 22e ; notre voile de 18 ticks est une adaptation de cette rampe, pas une copie.⁵
• N’animez jamais l’opacité de la vue SwiftUI qui contient une RealityView ; posez un voile par-dessus.²²

Si vous concevez la boucle de jeu

• Dans Émeraude, une entrée par une porte est un cérémonial d’au moins 1,32 seconde sans commande, et c’est le pas forcé par-dessus le seuil qui la fait lire comme une entrée à pied.⁵²⁵
• Pivoter sur place pendant 8 images permet au joueur de faire face à quelque chose sans bouger ; un heurt de 32 images lui signale qu’un pas a été refusé.¹
• Sur téléphone, ma recommandation : toucher pour marcher par défaut, comme le propose la version mobile de Stardew, un stick flottant comme solution de repli pour la précision, comme le conseillent les HIG, et pas de croix directionnelle fixe.⁴⁰⁴⁴
• Les retours haptiques confirment des événements, pas des pas, et s’accompagnent d’un interrupteur.⁴⁶

Questions fréquentes

À quelle vitesse le joueur marche-t-il dans Pokémon ?

Dans Rouge, Cristal et Émeraude, un pas de marche parcourt une cellule de 16 pixels en 16 images à 59,7275 images par seconde : 268 millisecondes par cellule, 3,73 cellules par seconde. Émeraude avance de 1 pixel à chaque image ; Rouge et Cristal avancent de 2 pixels une image sur deux. La course et le surf dans Émeraude, ainsi que les vélos dans Rouge et Cristal, prennent 8 images par cellule, 7,47 cellules par seconde.¹⁴¹⁹

Combien d’images compte un cycle de marche dans Pokémon Émeraude ?

Quatre entrées sur 32 images : un dessin d’enjambée pendant 8 images, le dessin debout pendant 8, l’autre enjambée pendant 8, debout pendant 8. Cela représente deux cellules de marche, si bien que chaque pas montre une enjambée et une position debout, et que les jambes alternent pas après pas. La course est un cycle de 16 images sur deux cellules de 8 images.¹⁹²

La caméra de Pokémon Émeraude est-elle en retard sur le joueur ?

Non. La caméra d’Émeraude copie la position du joueur et fait défiler la carte du même nombre de pixels sur la même image, si bien que le joueur reste fixe à l’écran pendant que le monde se déplace. Elle ne s’arrête pas non plus au bord d’une carte : l’extérieur est dessiné à partir des tuiles de bordure de la disposition. Une caméra d’anticipation pour le vélo existe dans le code, mais n’est jamais activée.²³¹¹¹²

Combien de temps dure la transition de porte et de fondu dans Pokémon Émeraude ?

La porte s’ouvre en quatre dessins de cinq images (335 millisecondes), le joueur fait un pas forcé de 16 images vers l’intérieur, la porte se referme en 20 images, et l’écran s’assombrit en neuf niveaux, le dernier mélange sur la 17e image du fondu et le fondu terminé sur sa 22e : au moins 79 images, 1,32 seconde, avant que la carte suivante puisse commencer à se charger. En entrant dans une grotte, l’écran fait un fondu au blanc au lieu du noir, et en en sortant, il réapparaît depuis le blanc.¹⁵²⁵²⁷

Un jeu en pixel art doit-il tourner à 120 Hz sur un iPhone ProMotion ?

Pas pour un mouvement en pixels entiers. Un monde qui avance d’un pixel par tick à 60 hertz ne fait que montrer chaque pixel pendant deux rafraîchissements à 120 hertz, et avec des durées inégales à 80. L’article d’Apple sur ProMotion indique que les jeux bénéficient d’une « special priority to 30Hz and 60Hz, » (priorité spéciale à 30 et 60 Hz), qu’une app iPhone doit définir CADisableMinimumFrameDurationOnPhone pour dépasser 60, et RealityKit effectue généralement son rendu à 60. Simulez sur un tick fixe à 60 hertz et laissez l’écran faire ce qu’il fait.⁶⁷¹⁶⁸

Pourquoi les pieds de mon sprite glissent-ils quand il marche ?

Généralement parce que les dessins de marche suivent une horloge et le mouvement une autre, avec des longueurs qui ne concordent pas. Le code actuel de Kiradex joue un cycle de six dessins à 8 dessins par seconde tout en marchant à 4 tuiles par seconde, si bien qu’un cycle couvre 3 tuiles au lieu de 2, comme le montre un modèle du code. Les consoles portables comptent les deux en images et font durer les dessins de chaque pas autant que le pas ; choisir le dessin selon la distance parcourue, ce que je propose pour Kiradex, obtient la même concordance sans seconde horloge. Dans les deux cas, la cadence ne peut pas se décaler par rapport au mouvement ; qu’un pied reste bien posé dépend aussi des dessins eux-mêmes.⁶¹⁹

Un jeu en pixels sur mobile doit-il utiliser une croix directionnelle virtuelle ?

Pas par défaut, selon ma lecture des sources. Le schéma par défaut de Stardew Valley sur mobile est le toucher pour se déplacer, avec un joystick invisible parmi ses autres schémas pour les tâches de précision ; les HIG d’Apple recommandent de toucher directement les objets et un stick qui apparaît « wherever the player lands their thumb instead of a static thumbstick position. » (là où le joueur pose le pouce, plutôt qu’à une position fixe.)⁴⁰⁴⁴

Sur ce site, à lire aussi : Des mondes en pixel art sur iPhone, le premier guide de cette série, avec la marche pas-debout d’Émeraude, la recette RealityKit sur laquelle tourne ce monde et la leçon d’opacité de la visionneuse de cartes ; Des personnages en pixel art : personnages et éditeur sur iPhone, le deuxième, avec la marche en six dessins dont cet article fait passer le minutage d’une horloge à une distance ; Des structures en pixel art : maisons, halls et intérieurs sur iPhone, le troisième, avec les portes, les téléportations et les étages dont la section 2 mesure le minutage ; L’iPhone Duo pour les développeurs et Préparer votre app pour l’iPhone Duo traitent des deux écrans et de la charnière que la caméra du cahier des charges évite ; Le modèle mental spatial de RealityKit explique le modèle d’entités et de systèmes qui sous-tend SceneEvents.Update.

Sources