Démo de développement pour NES - HEOHdemo

L'histoire des festivals d'art informatique, également connue sous le nom de demopati, existe depuis un quart de siècle dans notre pays. Des gens de partout dans le pays se rassemblent pour montrer leurs exercices pour extraire l'impossible des ordinateurs anciens ou modernes et des quantités ultra-petites de code. Au cours de la première période de cinq ans, le CAFe (du coup, Computer Art Festival ), qui s'est tenu à Kazan de 1999 à 2003, est devenu l'une des principales démopathies du pays. Plus tard, il a longtemps disparu des radars, donnant la paume aux plus célèbres Constructions Chaos et DiHalt , et cette année son retour a été assez triomphant - sinon par l'ampleur de l'événement, puis par le nombre d'œuvres diverses, qui ont duré jusqu'à six heures du matin. Parmi eux se trouvait la mienne, dont la création sera discutée dans cet article.


Sur la demoscene, je suis plus sympathique qu'un participant actif. Mes intérêts principaux sont dans le développement de jeux rétro et de logiciels sonores. Plus tôt, je n'ai fait qu'une seule démo conditionnelle complète pour un téléphone rouge , qui est depuis devenu un mème de scène, et environ une douzaine de petites intros pour différentes plates-formes. Les organisateurs de la CAFe , qui avaient commencé à agiter personnellement les auteurs à l'avance, d'abord à distance, par le biais d'amis communs, puis lors de réunions personnelles, m'ont finalement motivé à créer mon premier véritable travail à part entière dans la catégorie démo complète. En fait, sur une autre plate-forme pas la plus populaire - la console de jeu NES / Famicom , connue par la plupart sous le nom de Dandy.

Planification

Au départ, j'allais faire une démo conçue depuis longtemps pour une autre plate-forme 8 bits plus populaire. Mais pour sa mise en œuvre, il a fallu effectuer une quantité importante de travaux de recherche, c'est-à-dire qu'il n'y avait aucune compréhension ni du calendrier, ni de la faisabilité fondamentale de l'idée, ni de la qualité du résultat possible. Par conséquent, des actions spécifiques ont été prises très lentement. Les délais ont commencé à s'épuiser de manière significative, et il est devenu clair que si je veux tenir la promesse de participation, il est urgent de choisir un autre projet, plus prévisible en cours d'exécution. Après avoir réfléchi à la deuxième idée, pour la catégorie Wild , qui nécessitait également de l'expérimentation, j'ai décidé de revenir aux blancs de démonstration de longue date pour NES , réalisés il y a trois ans, puis pour le Multimatograph . En conséquence, elles-mêmes n'étaient pas vraiment utilisées, mais la direction du travail a finalement été déterminée.

Le plan de travail spécifique pour NES a finalement été approuvé début octobre, jusqu'à ce que CAFe soit dans environ trois semaines. Le dossier du projet a été créé le 5 octobre, mais certains mouvements ont eu lieu avant cela.

La première question à résoudre était de savoir combien d'effets (scènes) étaient nécessaires pour que la durée de la démo soit suffisante pour revendiquer une grande forme, plutôt qu'une simple intro. Il fallait également comprendre quelle était cette durée suffisante.
Pour cela, entre autres, les meilleurs travaux actuels pour la plate-forme sélectionnée sur Pouet ont été examinés et les deux meilleurs ont été analysés - High Hopes et NESPECCY . Le dernier, qui est une invitation à la même démopati, a été publié en décembre 2018, et jusqu'à ce moment-là, je n'avais pas attiré mon attention. Au début, cela a même quelque peu touché la motivation, car j'ai initialement supposé un niveau plus facile pour mon travail futur.

Selon les résultats de l'analyse, il s'est avéré que dans High Hopes il y a environ six effets et une durée de 2:45, et dans NESPECCY environ 11 effets et une durée de 3:45. C'est une moyenne d'environ 25 secondes par effet. J'ai suggéré qu'en moyenne, 10 à 15 effets suffiraient, en supposant que seulement 3 à 5 d'entre eux seraient relativement compliqués techniquement, et le reste peut être simple mais assez satisfaisant. Afin de ne pas retarder l'affichage de scènes simples, il se passera en moyenne environ 15 secondes par effet, avec la durée totale de la démo en environ deux ou trois minutes.

Cela a été suivi d'un calcul du temps qui peut être consacré à la création de chaque effet. Il s'est avéré un jour et demi à deux jours, sans compter les nombreuses autres œuvres nécessaires, telles que la musique, le graphisme, une sorte d'idée, et juste préparer une base technique qui combine les effets. Un tel calendrier ne semblait pas très réaliste, mais j'ai décidé de faire autant d'effets que possible, en essayant de tenir dans deux jours pour chacun.

Ainsi, la tâche prioritaire a été déterminée - être capable de faire dans le temps au moins quelque chose qui convient à la participation à la compétition, ainsi que le mode de développement dans le style «pas de temps pour expliquer». Cela a également exclu le journal de développement, et maintenant vous devez récupérer les événements de la mémoire, en essayant de ne pas trop mentir.

La tâche de faire le travail, revendiquant la première place, n'a pas été posée. L'essentiel n'est pas la victoire, mais la participation et tout ça, et en général la victoire principale est au-dessus de soi. Je n'ai pas fait de prévisions spéciales sur la base des résultats du concours pour l'impopularité de la catégorie sélectionnée, en m'attendant à ce que dans le pire (meilleur) cas de participation au concours de plusieurs travaux assez forts, le mien deviendra des compo fillers, qui sont également nécessaires et importants, et s'il n'y a pas de travaux, alors je le referai un gagnant parmi lui, comme cela s'est déjà produit dans d'autres disciplines. Bien sûr, je voulais gagner un combat décent, mais j'ai moi-même évalué mon travail moins que ce que le public avait finalement estimé.

Code

Après que les délais ont été fixés, il est devenu clair que pour avoir le temps de soulever un tel projet, il fallait se rattacher à un perfectionnisme inapproprié et ne pas essayer de faire le code de démonstration le plus technologique ou le plus compact. Plus c'est simple et rapide, mieux c'est, tout en conservant un effet extérieur suffisant.

Il a été décidé de choisir une configuration assez puissante et même redondante - un mappeur MMC3 avec 256 kilo-octets de code ROM et 256 kilo-octets de graphiques graphiques, et essayez de ne pas craindre que son plein potentiel reste inexploité. Cette configuration n'est pas la plus avancée de l'existant et encore plus possible, elle a été largement utilisée dans les jeux commerciaux, à commencer par Super Mario Bros. 3 (1988), mais auparavant, les auteurs de la démo pour NES se limitaient à des mappeurs plus simples et à moins de mémoire. En conséquence, 80% du volume du code ROM a été utilisé et un peu moins des deux tiers du volume des graphiques ROM. La quantité excessive de mémoire nous a permis de ne pas perdre de temps supplémentaire à résoudre le problème de compression des données, bien qu'il ne puisse pas s'en passer.

La méthode de développement était également évidente - principalement en C, avec des insertions d'assembleur au besoin, principalement la copie dans la mémoire vidéo, les gestionnaires d'interruption et un lecteur de musique. J'utilise depuis longtemps et avec succès cette approche sur des plateformes rétro. Cela économise beaucoup de temps de développement, car le prototypage de code peut être fait localement: implémentez-le d'abord en C et obtenez immédiatement un résultat qui fonctionne sur NES , puis, s'il ne fonctionne pas assez rapidement, réécrivez-le en pièces dans l'assembleur selon un modèle déjà préparé, jusqu'à La vitesse requise a été atteinte.



L'un des principaux problèmes attendus, qui, cependant, n'a pas causé beaucoup de problèmes dans la pratique, était la quantité de RAM principale - à NES, ce n'est que de 2 kilo-octets, et dans mon travail, j'ai décidé de ne pas l'étendre, bien que le mappeur ait essentiellement permis ce mouvement. La mémoire des systèmes basés sur le processeur 6502, compte tenu de sa capacité totale de huit bits, est souvent considérée comme des pages de 256 octets, et la répartition de la RAM s'est révélée comme suit:

• Une page pour les variables «rapides»;
• Une page pour la pile et la palette matérielles (une partie importante de la pile n'est pas utilisée);
• Une page pour le tampon de liste de sprites (les fonctionnalités de l'architecture du contrôleur vidéo l'exigent);
• Une page pour une liste des mises à jour de la mémoire vidéo;
• Une page pour une liste de paramètres pour les effets raster.

Les deux derniers sont déclarés dans le programme sous la forme de tableaux de caractères non signés ordinaires de 256 octets et, à certains endroits, sont également réutilisés à d'autres fins. Les trois pages restantes sont données sous la pile du programme cc65 , c'est-à-dire sous les variables globales et locales du programme C.

Il est à noter que l'allocation dynamique de mémoire (malloc / free) sur de telles plateformes n'est pratiquement pas utilisée, une solution statique était nécessaire. Au début, j'ai adhéré à la méthode d'utilisation d'autant de variables locales que possible, ce qui m'a permis de réutiliser automatiquement la mémoire de la pile logicielle pour elles. Mais les variables locales fonctionnent beaucoup plus lentement, et en conséquence, le volume disponible pour les variables globales a commencé à manquer, et il était simplement inconfortable d'écrire du code de cette manière, en utilisant à plusieurs reprises des variables du même nom. J'ai ensuite appliqué une solution inutilisée auparavant: une annonce dans la configuration de l'éditeur de liens de plusieurs segments de RAM situés physiquement aux mêmes adresses. Des groupes de variables utilisées dans le même effet ont été placés à l'aide de directives de compilation dans ces segments, permettant la réutilisation de la même mémoire.

Un autre problème - la distribution du code du programme C par les banques de mémoire de code ( NES utilise l'adressage de page pour la mémoire étendue) - a été résolu par moi dans d'autres projets et n'a pas causé de problèmes. Le code de placement dans les pages est limité à 16 kilo-octets (la taille de la fenêtre de mémoire commutable) dans une section fonctionnellement complétée et est appelé par la méthode de superposition: la page souhaitée est connectée, le code est traité, l'exécution revient à la page principale et l'accès à la mémoire entre les pages est impossible. Les fonctions sont allouées aux banques manuellement, via les directives du compilateur. Le code requis dans toutes les parties du programme, comme un lecteur de musique, une sortie de sprite et des gestionnaires d'interruption, se trouve dans la fenêtre de mémoire non commutable supérieure, également de 16 kilo-octets.

En travaillant sur le dernier effet, le couloir avec Mario, je suis tombé sur un message d'erreur de compilation divertissant: débordement d'étiquette locale . Si je comprends bien, le compilateur a une limite interne sur le nombre d'étiquettes locales générées (apparemment 65536) à l'intérieur d'un module objet, mais j'ai utilisé un module commun pour simplifier la gestion de la mémoire partagée. L'une des solutions possibles était de diviser le code en plusieurs modules, et j'avais déjà prévu de l'appliquer, cependant, après avoir déplacé un tableau de constantes de la source vers C dans la partie assembleur ( incbin avec une étiquette externe), le problème a été résolu par lui-même, la limite a cessé d'être dépassée, et même après l'ajout quelques centaines de lignes de code supplémentaires, un message d'erreur ne s'est plus produit.

Développement

Dans le choix des effets, il était prévu de nous limiter à une utilisation simple, mais toujours fluide, à pleine vitesse d'affichage (60 images par seconde). Les effets de démonstration traditionnels tels que le plasma et les rotateurs de zoom n'ont pas été initialement pris en compte, car ils ne cadrent pas bien avec l'architecture du décodeur, qui a des restrictions importantes sur l'accès à la mémoire vidéo - cela aurait l'air moche par rapport aux plates-formes où de tels effets sont implémentés à plusieurs reprises dans toute sa splendeur.

Au début, je voulais faire la majeure partie des effets selon un plan vieux de trois ans, basé sur des manipulations ligne par ligne avec le raster affiché - en changeant le déplacement vertical et horizontal de chaque ligne, ainsi que les banques du graphique affiché, pendant que le rayon traverse le raster. Une telle approche pourrait fonctionner sur la base d'un bloc de code commun, ce qui permettrait de gagner du temps de développement, mais les effets se révéleraient assez uniformes, et également assez traditionnels, que l'on trouve dans de nombreux autres travaux. De plus, il y avait des difficultés à déboguer ce bloc général de code, et en conséquence, la démo ne comprenait qu'un seul effet de ce type, une cartouche rotative.

Jouant avec quelques effets basés sur de vieilles idées, dont l'un est finalement devenu l'effet Kirby, et le second n'est pas entré dans la démo, j'ai commencé à écrire un document texte où j'ai noté toutes les idées qui me venaient à la tête, à la fois pour les effets individuels et pour le concept général. Cette liste comprenait plus de 40 effets, tandis que dans le travail final, moins de 15 ont été mis en œuvre. En même temps, la plupart des effets sont des animations d'un type ou d'un autre, bien que chacune de ses variantes soit assez unique et utilise diverses astuces pour assurer une consommation de mémoire acceptable et le bon fonctionnement requis. . Il est également arrivé involontairement que le type d'effets prédominant soit la rotation de quelque chose. En principe, c'est une bonne coïncidence, car une sorte d'unité conceptuelle est apparue.

Une intro avec un éléphant a été conçue et réalisée, comme une blague sur le sujet de mon travail précédent, puis un effet avec des rayures colorées et des interférences. Sans beaucoup de réflexion, le titre de travail, HEOHdemo , a été choisi comme une continuation de la blague de l'introduction (HE IS NOT HE). Quand il est venu à la réalisation de la scène avec la présentation du nom, il a été approuvé comme final, car il n'y avait plus d'idées réussies à ce moment-là et il n'y avait pas de temps pour les proposer.

Une décision spontanée avec la démo du nom a incité le concept final de tout le travail, qui a finalement pris forme dix jours avant la date limite. Cela impliquait l'utilisation de jeux vidéo et de matériel de culture pop reconnaissables, tels que des personnages, des logos, des scènes de jeux, mais modifiés de manière à rendre les originaux un peu différents (comme «pas eux»). Il a également été décidé de diffuser l'humour des scènes initiales et finales à l'ensemble de la démo, compensant ainsi le niveau technique pas très élevé, ce qui est tout à fait dans l'esprit de l'époque citée (milieu des années 90), et fait appel à un public plus large - après tout, les anciennes consoles de jeu ont leur propre, pas entrecoupé de la demoscene et pas très éclairé en technologie, mais un public très vaste. À peu près à la même époque, il a été décidé d'utiliser la démo inhérente des années 90 divisée en scènes indépendantes distinctes, car elles sont plus faciles à faire dans le temps disponible, ce qui a ensuite grandement aidé avec la partie musicale et la synchronisation des effets avec elle.

Les idées de scènes avec Vid, un logo rotatif et en partie avec Mario dans le couloir sont également apparues naturellement pendant le travail. Ils ont été fabriqués à leur tour, comme une sorte de procrastination - jusqu'à ce que les principaux effets prévus soient collés.

Assemblage

Au départ, il était clair que le temps le plus long dans le chronométrage prendrait part à l'introduction, au titre, aux salutations et au générique final. Le travail sur eux a été effectué en premier lieu, donc à un moment donné, il s'est avéré que la démo avait déjà un début et une fin complets (les mêmes que dans la version finale), mais il n'y a presque pas de terrain d'entente pour lequel un seul était plus ou moins prêt effet. Les délais tiraient à leur fin. Le travail sur le projet s'est transformé en un marathon de plusieurs heures, occupant tout le temps possible, et pas trop libre. Les effets restants dans les plans ont été classés par complexité, toutes les idées ont été simplifiées autant que possible. Des envahisseurs spatiaux ont été créés, des problèmes avec une cartouche rotative ont été vaincus et une tour facile à mettre en œuvre avec un craquement a été achevée (expérimentée avec l'apparence). Les effets étant prêts, la séquence de leur affichage a été déterminée.

Chaque bagatelle a pris trois fois plus de temps qu'il n'y paraissait au début, et quelques jours avant la date limite, alors qu'il n'y avait toujours pas la moitié des effets ou de la musique, il y avait un fort sentiment que cela ne marcherait pas. Le plan B a été envisagé, pour achever et exposer les travaux déjà sur une autre démopati, ou à l'extérieur. Mais ensuite, une décision plus efficace a été prise: rassembler et achever de toute urgence tout ce qui existe déjà, au moins dans un semblant de produit prêt à sortir, même complètement stupide, pour écrire de la musique pour cela, et s'il reste encore du temps après cela, essayez d'ajouter plus d'effets. Parmi ces scènes ajoutées au dernier moment se trouvaient Pakman et le couloir, tous deux dans la version la plus simplifiée par rapport aux idées originales.

Cette méthode d'assemblage a conduit à une incohérence notable des effets au milieu de la démo et à un changement complet de musique entre de nombreuses scènes. Cependant, cela a permis de gagner beaucoup de temps et, en fait, le travail était complètement prêt à être publié un jour avant la date limite. Ce temps supplémentaire a été consacré à la finalisation de diverses bagatelles dans toutes les parties et en musique. En particulier, c'est à cette époque que les envahisseurs et le crapaud ont acquis leur apparence alternative.

Débogage

Faute de capacités de débogage sur du matériel réel, ainsi que sur le matériel lui-même, la démo a été déboguée exclusivement dans des émulateurs. Le travail principal était dans l'émulateur FCEUX . Ce n'est pas très précis, mais il a un bon débogueur et il démarre très rapidement, ce qui est important avec la méthode de développement consistant à "ajouter quelques lignes, exécuter, vérifier". Les effets critiques ont également été débogués dans Mesen , punes et Nestopia, beaucoup plus précis mais moins pratiques.

Étant donné que le format de démonstration lui-même implique le désir d'obtenir de la plate-forme ce que personne ne faisait auparavant, il teste la précision des émulateurs pour la force, y compris en montrant leur désaccord sur divers cas extrêmes. Après avoir débogué l'effet dans un émulateur, vous pouvez y insérer des artefacts dans d'autres émulateurs. Pour cette raison, et également en raison des caractéristiques de l'architecture NES , de nombreux effets liés à des temporisations précises ont dû être débogués plusieurs fois. Par conséquent, j'ai configuré la démo pour un travail propre dans l'émulateur FCEUX populaire, avec lequel elle a été envoyée au concours, et pour un travail normal dans tous les autres émulateurs.

Parmi les erreurs intéressantes trouvées lors du débogage, il y avait un problème dans la scène avec un logo rotatif, se manifestant exclusivement dans l'émulateur Mesen .Initialement, dans cet effet, le rendu a été désactivé immédiatement sous l'inscription inspirée par le transfert d'un grand bloc de données vers la mémoire vidéo et ne s'est réactivé qu'au début de l'image suivante. Cela a bien fonctionné dans tous les émulateurs, mais à Mesen , d' une manière incompréhensible, l'affichage de sprites de pièces volantes a complètement cessé de fonctionner normalement. L'activation du rendu après le transfert a résolu ce problème.

La démo prend directement en charge uniquement la version NTSC de la console, car la prise en charge PALcela augmenterait considérablement la quantité de travail et le temps consacré au débogage - certains effets nécessitent des paramètres très différents, et pour préserver la durée de la démo et la vitesse de la musique, vous devrez créer deux ensembles de données musicales et effectuer deux fois l'ajustement manuel des effets. Par conséquent, au démarrage, une détermination du système est effectuée et si une version PAL est détectée, un avertissement est émis concernant un éventuel mauvais fonctionnement. La démo elle-même démarre, mais fonctionne avec de puissants artefacts visuels dans certains effets et est 17% plus lente.

Après la sortie, certains téléspectateurs ont exécuté des démos sur diverses consoles réelles - l'American NES , Famicom AV et même Pegasus (un analogue de notre Dendy Classic 2en Pologne, en République tchèque et dans certains autres pays). Il s'est avéré que sur toutes les consoles, la démo fonctionne généralement normalement, mais avec des problèmes visuels dans certaines scènes, et plus intéressant encore, ces problèmes sont différents pour tout le monde. Certains d'entre eux sont probablement liés à la mise en œuvre insuffisamment précise du mappeur MMC3 dans les cartouches Flash populaires , car le moins de problèmes sont survenus sur une cartouche conventionnelle avec un vrai MMC3 . La configuration la moins problématique suivante était Pegasus, bien que la démo là-bas n'aurait pas dû fonctionner normalement en principe - elle ne montre qu'un petit artefact sur la scène avec Mario. À ma grande surprise, l'effet le plus difficile à déboguer et à synchroniser - la cartouche rotative - fonctionne de manière stable sur n'importe quelle configuration de fer de test.

Les problèmes rencontrés sur le matériel ne sont pas critiques, et finalement la version finale sera publiée, où ils seront corrigés. Mais pour cela, il reste à voir lequel des problèmes se rapporte spécifiquement au code de démonstration, et laquelle des fonctionnalités des configurations de test. Après cela, les informations obtenues peuvent être utilisées pour améliorer la qualité des émulateurs et des cartouches Flash .

La musique

Le travail sur la musique a commencé par la sélection d'un thème du programme "New Reality" et tente de le croiser avec "Glory". Ce processus a pris un temps indécent. Ensuite, AON a inspiré l'idée de faire des tambours dans la première partie de la démo sous la forme de signaux saccadés simples de deux hauteurs différentes, et un fragment de musique avec de tels tambours pour un effet appelé démo a été grossièrement esquissé. L'idée a également surgi que le même fragment, mais dans un arrangement différent, pourrait être utilisé dans la partie avec des salutations, comme un semblant d'un thème musical général. Pour la plupart, le travail sur la musique s'est arrêté là, et le reste a été écrit deux jours avant la date limite. Dans le même temps, un ajustement conjoint des effets et du matériel musical a été effectué.

Malgré les modestes capacités du système audio NES , , , -. , , , , , . , .

Reaper MIDI-, , FamiTracker . MIDI-, Reaper, FamiTracker .



FamiTracker NES , , , — , . , . , «» FamiTracker ' NSF - . , , NES .

. . FamiTracker Zxx , .

Le code est emprunté à un ancien projet. La partie apparaissant de la ligne est affichée avec des sprites avec différentes palettes, puis imprimée en arrière-plan. L'inscription «basée sur des effets réels» laisse entendre que d'autres effets ne sont pas comme ça, c'est une blague sur le sujet d'un débat constant sur l'acceptabilité et le rôle de l'animation dans la démo.

Intro avec éléphant et ligne rampante

L'idée de l'effet a évolué d'un court encart commençant immédiatement par une ligne en cours d'exécution à une scène à part entière. Le premier personnage est donc apparu dans la démo.

Techniquement, la scène est très simple, la principale difficulté est la conversion des graphiques dessinés dans Graphics Gale en un sprite multicouche pour y fournir un nombre inhabituellement élevé de couleurs (10). Seulement quatre couches, chacune avec sa propre palette. Les couches sont converties individuellement en NES Screen Tool et empilées manuellement dans un sprite commun dans l'éditeur de métasprite.

Interférence

, , , . , , .

8 32 , PC. . MMC3, ( ), , . , .

Le premier effet à part entière qui a été écrit pour la démo. En fait, il se compose de deux parties - une minuterie s'affiche tout d'abord, montrant la synchronisation de démonstration actuelle proche de la réalité, puis l'effet passe à une animation de bandes croissantes.

Bien que la minuterie soit visuellement très simple et que vous ne puissiez pas le remarquer d'un coup d'œil, elle fait également quelque chose d'inhabituel dans le cadre de la plate-forme. Les nombres sont de 12 x 16 pixels, mais la couche d'arrière-plan est constituée de carreaux 8 x 8, et les images-objets ne peuvent pas couvrir plus d'un quart de la largeur de l'écran - tandis que le minuteur prend les deux tiers. Pour avoir la possibilité d'afficher une police qui ne rentre pas dans la grille, une astuce a été appliquée - un graphique de toutes les paires de chiffres de 00 à 99 a été préparé, puis converti en un ensemble de tuiles en supprimant les doublons - afin qu'il tienne dans une centaine et demi de tuiles. L'effet de chute de la minuterie est réalisé par un simple défilement vertical. Étant donné que les graphiques des barres de couleur sont un remplissage de couleur unie, leur mouvement n'apparaît pas visuellement.



, , MMC3, , .

, 32 . 238 , 7 . , , , 53. , PC, , .

Le titre

Au début, deux autres effets plus complexes avec les mêmes lettres prétendaient à cette scène; en conséquence, la troisième option plus facile à mettre en œuvre a été choisie.

La police est rectangulaire pour faciliter l'animation. Chaque lettre a essentiellement une hauteur de cinq pixels conventionnels et une largeur de quatre. Il existe cinq combinaisons différentes de pixels sur chaque ligne de la lettre. Blender a préparé une animation de rotation douce du bord au plan des cinq combinaisons. Les images sont combinées en un seul fichier, la couleur est réduite à trois couleurs, après quoi l'image a été importée dans l' outil d'écran NES - cela a donné un ensemble de 82 tuiles et une carte de tuiles pour l'animation elle-même. En fait, il existe deux ensembles de ce type, pour faire pivoter les lettres dans des directions différentes.



La lettre rotative est affichée sur la carte des tuiles; elle est composée de cinq bandes animées requises. Comme une seule animation de lettre est visible à la fois, la couleur du visage peut être modifiée, ce qui crée l'illusion du multicolore. Les lettres arrivant à l'écran sur le bord sont affichées par des sprites, leurs coordonnées et vitesses sont sélectionnées très précisément manuellement pour créer la fluidité nécessaire et les changements de vitesse des objets. Une fois que le sprite atteint l'emplacement souhaité sur l'écran, il est remplacé par une animation sur le calque d'arrière-plan.



Les bandes horizontales volant à des vitesses différentes sont réalisées via le gestionnaire d'interruption MMC3 , cette fois il définit le décalage horizontal horizontal des pixels de la couche d'arrière-plan pour chaque ligne de tuiles.

Envahisseurs spatiaux

L'idée de cette scène très simple avec la rotation de grands pixels rassemblés dans une certaine image est venue plus près du début du travail, et en même temps plusieurs options pour la rotation de l'animation ont été dessinées manuellement dans Gale . La scène elle-même a été réalisée beaucoup plus tard, lorsque le concept de la démo a finalement été établi, et l'idée a semblé montrer des personnages cultes.



Les tuiles sont sorties en enregistrant dans la mémoire vidéo dans la couche d'arrière-plan. Les étoiles sont affichées par des sprites.

Le caractère prolongé de la scène s'explique par sa synchronisation avec la musique, selon l'image par battement. Il n'y avait pas d'élaboration spéciale du temps pour montrer les effets, et sans y penser, il semblait que cela n'avait pas l'air très ennuyeux.

Logo rotatif

En raison du manque d'effets et du temps pour les développer, j'ai décidé de réutiliser une petite intro écrite il y a quelques années, dans laquelle les lettres volaient le long du même chemin autour d'un logo statique. Récemment, je me suis de nouveau intéressé au préfixe N64 , que j'ai négligé à la fin des années 90, et dans le processus de travail sur d'autres effets, une idée spontanée est venue avec l'animation de la rotation du célèbre logo, qui semblait très simple à mettre en œuvre - ces deux pensées se sont rencontrées, mais la mise en œuvre a pris beaucoup plus de temps que prévu.

La principale complexité technique de la scène est la réduction de la quantité de mémoire requise pour une animation aussi fluide et large. Si vous stockez ses images sans compression, une image occuperait un ensemble de 4 kilo-octets (puisque deux images ne tiendraient pas dans 256 tuiles), et cela prendrait 256 kilo-octets de ROM graphique, c'est-à-dire tout le volume utilisé dans le volume de démonstration. Pour résoudre ce problème, trois astuces ont été appliquées à la fois: animation de rotation à seulement 90 degrés (64 images), après quoi deux couleurs de visage sont échangées; conversion graphique avec perte pour placer des groupes de quatre images dans des ensembles de 256 tuiles; ainsi que la mise à jour de la mémoire vidéo dans la partie visible du raster. Ainsi, l'animation a pris quatre fois moins d'espace.

Le modèle de lettre et l'animation de rotation sont réalisés dans Blender . Au cours de son miroir votre idée est venue qui correspond au concept de démonstration, et il était drôle - la scène dit: « et et et et et et. » Les images d'animation sont regroupées, la profondeur de couleur est réduite à 4 et ces images sont converties par la fonction d'importation avec perte dans l' outil d'écran NES . Cette fonction est peut-être mon arme secrète principale - si la limite de tuiles est dépassée pendant la compression, elle recherche les tuiles visuelles les plus similaires et les combine jusqu'à ce que le nombre requis de tuiles reste. Bien sûr, cela donne des artefacts de conversion visuelle et nécessite un raffinement manuel ultérieur, mais vous permet de presser des images plus complexes avec moins de travail dans la limite.



Pour l'animation du logo, les ensembles de tuiles sont commutés et la fenêtre de 14 par 14 tuiles dans la carte de tuiles d'arrière-plan est mise à jour, pour laquelle l'interruption MMC3, qui est déclenchée avant une ligne de texte, est utilisée. La ligne nécessite également de basculer l'ensemble graphique vers la police, après quoi il y a un retard dans le code pendant le temps que les lignes de l'inscription sont affichées, puis l'affichage s'éteint (la couleur d'arrière-plan est constamment affichée) et les données sont transférées dans la mémoire vidéo.

Les pièces sont affichées par des sprites et volent le long d'un chemin calculé plus ou moins honnêtement (en utilisant un point fixe). L'ancien code a été modifié pour que la rotation se déroule, si possible sans intersection avec le logo plus grand, ainsi que pour que les pièces apparaissent et disparaissent progressivement aux bons moments. Ils vont au-delà des graphiques du logo en utilisant le drapeau de priorité de chaque image-objet.

Cartouche rotative

L'implémentation de l'effet est très simple en mots, mais elle a nécessité un long débogage. Le gestionnaire d'interruption lance un effet raster sur la ligne souhaitée (pour laisser du temps au thread principal). Ensuite, le code avec des minutages sélectionnés très précisément est exécuté pour définir le décalage vertical pixel par pixel de la carte de tuiles affichée pour chaque ligne de l'écran. Cela nécessite un schéma d'écriture très délicat dans les registres PPU , et certains d'entre eux doivent exactement tomber à un certain endroit sur la ligne. Dans la version NTSC du décodeur, la vitesse d'horloge du processeur et le taux de répétition des pixels ne sont pas multiples, et le temps d'exécution du code peut varier légèrement en fonction de plusieurs facteurs, de sorte que les synchronisations de chaque ligne s'éloignent progressivement et nécessitent une correction.

La partie principale des graphiques de cette scène a été dessinée il y a plusieurs années pour une tentative précédente de faire une démo pour NES , mais maintenant elle a été complétée par d'autres faces de cartouche et un logo de démo. L'image originale est empilée en hauteur sur un seul écran. Pour simplifier le code d'effet, les mêmes lignes sont dupliquées plusieurs fois à l'arrière de la cartouche.



L'animation de rotation est entièrement calculée à l'avance à l'aide d'un programme PC et prend une quantité importante de code ROM - trois banques de 16 kilo-octets chacune, dans lesquelles pour chacune des 256 images de l'animation, une table est stockée dans 176 numéros des lignes raster affichées. Il était possible de faire un effet en temps réel, j'ai déjà fait une démo similaire pour une autre plateforme, mais dans ce cas il y avait assez de mémoire libre et il n'y avait pas de temps supplémentaire.

Pacman

Initialement, une scène plus complexe était prévue, mais en raison du manque total de temps, elle est entrée dans la démo dans la version la plus minimaliste, sous la forme d'une décomposition des scènes lors du changement de musique.

Le principal problème était de trouver un moyen de créer rapidement des animations. Tout d'abord, l'idée est venue d'utiliser à nouveau Blender ou d'autres programmes graphiques. Mais après les premières tentatives et quelques calculs, il est devenu clair que seulement huit images de l'animation d'ouverture de la bouche d'une position complètement fermée à une position complètement ouverte seraient suffisantes, et elles seraient beaucoup plus faciles et plus rapides à dessiner manuellement dans Gale .

Ensuite, un programme a été écrit pour le PC, prenant une séquence d'images d'un cycle d'animation complet et trouvant des images qui ont changé entre les tuiles. Les adresses de ces tuiles dans la carte des tuiles dans la mémoire vidéo sont enregistrées sous forme de listes de longueur variable, l'effet dans la démo met simplement à jour les sections modifiées de ces listes. Les graphiques de tous les cadres tiennent dans un seul jeu de tuiles et ne changent pas pendant l'effet.

Kirby

Cet effet a été débogué sur mon ancienne photo Catrix . Il y avait un plan pour changer l'image du visage d'un chat en une image alternative avec un chat du Cheshire à travers une sorte d'effet visuel. Lorsque l'idée est venue d'ajouter des personnages du jeu à la démo, après une courte élection - il était urgent de dessiner deux nouvelles images en plein écran - il a été décidé de prendre Kirby et d'en faire une version «Cheshire». L'effet de la modification des images dans le processus a été simplifié en un court scintillement.

Les blocs d'images en mouvement sont affichés sous forme de sprites et imprimés sur la carte de tuiles lorsqu'ils arrivent au bon endroit. De même, une suppression de bloc se produit.

La tour

J'ai toujours aimé l'effet dans le dernier niveau du jeu Battletoads , et j'ai longtemps voulu le répéter. Dans la démo, il est venu à un endroit de la scène avec des salutations.

La partie technique est très simple, il s'agit d'un défilement vertical normal d'un calque d'arrière-plan. L'effet de rotation est obtenu par l'animation des graphiques des tuiles, tandis que la carte des tuiles reste inchangée. Pour l'animation, le mode MMC3 est utilisé avec quatre fenêtres CHR commutables. La première fenêtre contient des tuiles de la partie statique, tandis que les trois autres commutent à des vitesses différentes. L'une des fenêtres modifie également en douceur la direction de l'animation. Étant donné que 64 tuiles sont placées dans chaque fenêtre, et l'élément animé ne nécessite que 28, les graphiques des tuiles sont dupliqués dans chaque fenêtre pour recevoir l'animation dans la direction opposée.



Le principal problème pour réaliser l'effet était la préparation de l'animation. Il a été exécuté par un programme sur un PC qui prend une texture 16x16 et une table de vitesse pour chaque colonne de pixels en entrée, et génère un bloc de 16 images d'animation sous la forme d'un ensemble de 256 tuiles (dont certaines sont vides). Les ensembles sont convertis au format souhaité dans l' outil d'écran NES et distribués aux banques de graphiques ROM avec les décalages souhaités via les options de la directive assembleur incbin .

Une autre tâche importante concernant les salutations était de ne pas oublier de les transmettre à tous ceux qui le souhaiteraient. Depuis ce nombre tend vers l'infini, et une scène trop longue serait ennuyeuse. J'ai décidé de ne me limiter qu'à ceux avec qui je croisais depuis un an. Noms recueillis dans un fichier texte au fur et à mesure qu'ils me venaient à l'esprit. Bien sûr, après avoir terminé le travail, il s'est avéré que j'avais encore oublié de mentionner beaucoup de gens.

Couloir

Il y avait un désir de faire une sorte de scène avec une perspective, comme un tunnel classique. Les tunnels classiques ou un véritable rakester Wolfenstein 3D ont disparu en raison de la complexité. De plus, NES a déjà plusieurs vrais rakasters, y compris des textures, mais ils ne semblent pas tous très impressionnants en raison de la vitesse extrêmement basse.

Je suis très intéressé par les graphiques pseudo-tridimensionnels dans les premiers jeux, et parmi les anciens développements il y avait déjà un couloir de sprites avec une animation fluide des virages, inspiré du jeu Zig Zag pour le ZX Spectrum . Il a été décidé de l'utiliser. Comme le couloir abstrait lui-même n'est pas très intéressant, une intrigue interne de la scène avec Mario et l'humour des toilettes a été inventée, qui le complète logiquement, ainsi que la démo dans son ensemble. La scène a été réalisée la toute dernière, et malgré l'utilisation de blancs, le travail a duré plus de 11 heures d'affilée, sans compter les travaux préparatoires lors de la planification.

Toutes les images animées sont tracées manuellement dans Gale. C'est le seul effet dans la démo, allant à une vitesse inférieure à 60 images par seconde, bien qu'il puisse fonctionner à cette vitesse sans aucun problème. Pour des raisons de lisibilité visuelle et de synchronisation avec la musique lors du lancement dans le couloir, le taux de rafraîchissement de l'écran était limité à 30 images par seconde, comme alternative à l'ajout de phases intermédiaires de mouvement, pour la préparation desquelles il n'y avait plus de temps.

Les cadres graphiques ont pris deux ensembles de tuiles. Aux moments nécessaires de l'animation, le calque d'arrière-plan est mis à jour, l'ensemble de graphiques souhaité est connecté et deux couleurs sont définies dans deux palettes (pour la moitié supérieure et inférieure de l'écran), car lorsque vous tournez à 90 degrés, les couleurs des murs changent de place.

Les cartes de tuiles d'animation sont d'abord copiées dans la RAM par un code dans une banque fixe à partir de l'une des deux banques inférieures enfichables de la ROM. Pendant l'affichage du raster juste en dessous de la fenêtre affichée de l'effet, le rendu est désactivé et les données sont transférées de la RAM vers la mémoire vidéo. La désactivation du rendu sert également de limite inférieure de l'écrêtage visuel du sprite Mario.

Légendes

Cette scène a été l'une des premières, après les barres de couleur, basée sur le code d'un des anciens projets. Il avait déjà pris en charge deux polices, des palettes différentes et des ralentissements à la fin. Pour la démo, de nouvelles polices ont été dessinées, qui sont utilisées partout, et un effet a été ajouté sur les bords de l'écran.

Au début, je voulais que les bords s'assombrissent en douceur, mais pendant les expériences préliminaires, j'ai essayé des options avec un décalage de ligne horizontal, j'ai aimé le résultat et j'ai décidé de ne pas passer de temps supplémentaire. Un léger ombrage est ajouté à l'aide de la fonction controversée du contrôleur vidéo NES , la réduction du gain des composants de couleur. La controverse réside dans le fait que dans différentes versions régionales et clones de la console, cette fonction fonctionne différemment, mais dans cette application, il ne devrait pas y avoir de problèmes particuliers (sans compter le soi-disant PPU RVB , où les bords seront remplis de blanc).

Afficher

À peu près au moment où la scène de sous-titrage a été réalisée, l'idée de cette scène a surgi spontanément. L'idée initiale était de l'insérer à un moment aléatoire, mais à la fin il a réussi à s'insérer dans la fin. Malgré la courte durée, la scène se compose de trois éléments: la simulation de la mise à l'échelle du sprite, l'augmentation du nombre de nuances de gris en alternant deux images et la lecture programmée d'un échantillon DPCM .

Pour simuler la mise à l'échelle, le fait que tous les grands sprites sur NES sont composés de petits, dans ce cas 8x16, est utilisé. Si vous les déplacez les uns par rapport aux autres, vous pouvez obtenir l'effet de mise à l'échelle ou de distorsion, qui semble assez décent avec de petites valeurs de changements. Pour cet effet, vous devez multiplier le décalage de chaque image-objet par rapport au centre par une échelle, mais comme le processeur NES ne peut pas faire face à un grand nombre de multiplications entières paires, l'astuce est appliquée - au début du cadre, la grille de coordonnées le long des axes X et Y est prise en compte et la sortie de l'image-objet utilise ces valeurs pré-calculées . Ainsi, le nombre de multiplications nécessaires est considérablement réduit - avec une pulvérisation composite de 8x8 éléments (64 sprites), seules 16 (8 + 8) multiplications sont nécessaires au lieu de 128 (8 * 8 * 2).

NES ne peut afficher que 4 nuances de gris, y compris le blanc et le noir. L'effet imite 7 dégradés: si vous affichez un pixel blanc et blanc à travers le cadre, il sera blanc, si gris et gris il sera gris, et si vous alternez blanc et gris, alors visuellement cela ressemblera à une gradation intermédiaire entre blanc et gris. La principale difficulté est encore une fois la préparation des graphiques, à savoir deux demi-images de l'image, qui a été effectuée par un certain nombre de manipulations manuelles dans Gale et GIMP . Pour réduire le scintillement, les lignes des demi-images alternent.



La lecture programmatique de DPCM était nécessaire car il n'y avait pas de place pour un échantillon dans de meilleurs formats, le support matériel ne pouvait pas lire les échantillons de la moitié inférieure de la mémoire, mais il n'y avait pas d'espace pour un échantillon d'une telle longueur dans la mémoire supérieure non commutable. Le fragment de son lui-même ne provient pas de l'économiseur d'écran d'origine, mais d'un jingle de son assez similaire du jeu bien connu avec une finition cruelle, qui sonne au moment de la finition proprement dite.

Carte mémoire

En cours de développement, l'utilitaire NES Space Checker a été constamment utilisé, ce qui permet de visualiser le remplissage des banques de mémoire. Il est assez intéressant de voir un bon exemple de quoi et où se trouve à l'intérieur du programme.



PRG00 ... PRG02 - données musicales
PRG03 - exemple pour une scène avec une vue
PRG04 ... PRG06 - données d'animation de rotation de cartouche
PRG07 - animation de tuiles profondément dans le couloir
PRG08 - animation de rotation des carreaux dans le couloir
PRG09 - code de scène de tour
PRG0A - code de scène avec logo rotatif
PRG0B - code de scène avec un nom et un couloir
PRG0C - code de scène avec cartouche rotative, Kirby, View, envahisseurs, Pakman
PRG0D - code de scène avec intros, bruit, barres de couleur, légendes
PRG0E - la banque principale du code, contient uniquement les appels de toutes les scènes
PRG0F - banque de code fixe, lecteur de musique, sortie sprite, gestionnaires d'interruption

CHR00 - bébé éléphant et tuiles pour rayures colorées
CHR01 - police et bruit
CHR02 - Afficher le sprite et les tuiles de lettres tournantes dans le nom
CHR03 - Tuiles Kirby normales
CHR04 - Tuiles Cheshire Kirby
CHR05 - graphiques pour une scène avec une cartouche rotative
CHR06 ... CHR0D - animation du logo rotatif
CHR0E - une police pour les salutations et l'animation des tuiles envahissantes
CHR0F - Tuiles Pakman
CHR10 ... CHR13 - animation de texture de tour
CHR14 - Carreaux de couloir
CHR15 - Sprite Mario
CHR16 ... CHR1F - non utilisé

Au lieu d'une conclusion

Je terminerai par un mème combo: dans toute situation incompréhensible, écrivez des scènes de démonstration, messieurs!