Le PSG 8912, circuit intégré complexe, génère des sons sur la base de 14 paramètres qu’il faut lui fournir. Ce sont surtout les 6 premiers paramètres (en fait 3 paramètres sur 2 octets chacun) qui nous intéressent aujourd’hui. Ils définissent la période des sons qui seront respectivement générés par les canaux 1, 2 et 3. Lorsqu’on veut programmer des sons en langage machine, il faut envoyer ces 14 paramètres aux 14 registres du PSG 8912 à l’aide de la routine #FA86 (Atmos), après avoir renseigné X et Y pour qu’ils pointent sur l’adresse où se trouve le bloc des 14 paramètres. Heureusement ces 14 registres sont latchés (verrouillés) et gardent leur valeur tant qu’on ne la remplace pas par une autre. La plupart du temps il y a donc peu de changements et il est possible de modifier un seul registre à l’aide de la routine #F590 (Atmos), après avoir renseigné A avec le n° de registre (de 0 à 13) et X avec la valeur à y placer (A, X et Y sont les registres du microprocesseur 6502).
VOUS PRÉFÉREZ LE BASIC ?
Il n’empêche que le PSG 8912, ce n’est pas de la tarte, avec ses 14 paramètres dont certains sont complexes ! Mais les commandes PLAY, MUSIC et SOUND simplifient la vie de ceux qui sont effrayés par le langage machine. Le bel effort, qui a été fait pour programmer les commandes PLAY, MUSIC et SOUND, est handicapé par la pauvreté des manuels. A ce propos, je vous renvoie à l’excellent article “PLAY, MUSIC, SOUND”, paru dans le CEO-mag d’avril 2000, n°119-120, pages 35 à 39. Toujours est-il que ces 3 commandes Basic permettent de mettre en œuvre assez facilement les paramètres du PSG 8912.
MUSIC
Dans le cas de MUSIC, par exemple, il suffit d’indiquer le canal à activer (1 à 3), l’octave (0 à 7), la note (1 à 12) et le volume (1 à 15 pour le volume sonore ou 0 pour passer la main au contrôle par une enveloppe). Quoi de plus simple ? Soit dit en passant, la syntaxe de ce dernier paramètre est regrettable. Pourquoi ne pas avoir repris les valeurs qu’accepte directement le PSG 8912, à savoir 0 à 15 pour le volume et 16 (#10) pour le passage de contrôle à une enveloppe ?
SOUND
Mais MUSIC a les inconvénients (les limites) de son avantage (la simplicité) : Cette commande ne sait produire aucun son en dehors des notes standards. Pour ce genre de sons, il existe la commande SOUND, pour laquelle il faut indiquer le canal (1 à 6 avec 1 à 3 pour le canal et 4 à 6 pour ajouter du bruit blanc aux canaux 1 à 3), la période (de 0 à 65535) et le volume (idem MUSIC). Pas top la syntaxe du 3e paramètre (période). En français la hauteur d’une note est définie par sa fréquence. On ne parle jamais de la période d’une note. L’utilisation de la période était probablement plus simple d’un point de vue programmation, mais elle est contre culturelle et pas du tout intuitive (plus une note est haute plus sa période diminue). Toute valeur entre #0000 et #FFFF (0 et 65535) est acceptée et la valeur que l’on indique est directement envoyée au PSG 8912. Mais celui-ci ne prend pas en compte les 4 bits supérieurs de l’octet de poids fort. Les valeurs réellement injectées dans le PSG sont ra menées à l’espace #0000 à #0FFF (0 à 4095 en décimal). L’intervalle de 0 à 65535 est donc illusoire (mais les capacités du PSG 8912 et celles de l’oreille humaine sont quand même largement couvertes).
PERIODE
La période (en secondes) est l’inverse de la fréquence (en Hertz). En pratique, pour avoir des valeurs manipulables, on exprime la période en µs. Pour ce faire, il faut diviser 1 000 000 par la fréquence (il y a un million de µs dans une seconde). Par exemple pour le LA de l’octave 3 (le diapason qui sert de référence en musique), la fréquence officielle est 440 Hz. La période correspondante est de 1 000 000 / 440 = 2 272,73 µs, une valeur qui n’est jamais mentionnée, ni utilisée.
LE TRUC INVISIBLE
Le truc qui n’est pas explicité dans les divers documents disponibles (et il y en a un paquet !) est que dans le cas du PSG 8912, la période n’est pas exprimée en µs, mais en unités de 16 µs (ça sent le système binaire là-dessous). Il faut donc appliquer un facteur de conversion de 62 480 (car 1 000 000 / 62 480 = 16,00512164). Dans le cas du LA de l’octave 3 (440 Hz) la période exprimée en unité de 16 µs est de 62480 / 440 = 142 (soit #008E en hexadécimal). Les amateurs de langage machine pourront vérifier que #008E est bien la valeur indiquée dans la Rom par les tables de conversion en #FC5E (octet de poids fort) et #FC6B (octet de poids faible). Et c’est bien la valeur 142 qu’il faut indiquer à la commande SOUND pour obtenir un LA de l’octave 3.
POUR EN REVENIR AU PSG 8912
C’est bien sûr #008E qu’il faut aussi indiquer au PSG pour obtenir ce même LA de l’octave 3. Par exemple, pour obtenir ce son sur le canal 1, il faudra placer #8E dans le premier registre et #00 dans le second. D’une manière générale, pour produire un son de fréquence F, il faudra placer dans les registres du PSG une valeur de période P = 62480 / F. Ce n’est pas si compliqué, encore fallait-il le dire clairement. En complément pour ceux qui seraient intéressé, une table de conversion “Note-Frequence-periode.pdf” accompagne cet article.
Le dernier acte (connu à ce jour) de la programmation multi-ordinateurs en basic par Dan Cresp, et un coup de chapeau à Dom
Informations générales
Après presque quatre ans sans programmer sur l’ORIC, quand Dan reprend la création de soft avec «Averno», il est tellement satisfait du résultat qu’il s’engage dans un autre projet encore plus complexe.
AVERNO a été le premier jeu que réalisé en BASIC par Dan où le protagoniste passe en arrière-plan sans défauts d’affichage. Pour ce faire, Dan a placé la totalité de la zone de jeu dans une matrice texte et déplace le fantôme en reconstituant l’arrière-plan à partir des données de cette matrice. Le résultat est bon mais le coût de cette routine, ainsi que la maintenance de la matrice sont élevés. Le processus prend environ 10 secondes. Sur le plan graphique, l’utilisation de 3×2 caractères lui permettait de réaliser des graphismes presque identiques à l’original … monochromes.
Par la suite, Dom sur oric-concours.forumactif.org a amélioré l’apparence du jeu en utilisant une propriété des attributs de couleur de l’écran permettant d’afficher les couleurs complémentaires des couleurs principales. Il a également amélioré la composition du niveau en enregistrant les écrans. Et pour simplifier l’ensemble, il a transféré le logiciel sur une disquette. L’on doit admettre que la version s’est améliorée et que son apparence est meilleure. Bravo !!!
Avec Solomon’s Key, Dan va un cran plus loin dans la conception de l’écran.
Un écran titre alléchant !
Sprites Cette fois, Dan a voulu expérimenter une utilisation améliorée des «sprites», sans avoir à monter l’usine à gaz de la matrice écran, et insérer directement des valeurs 16 bits dans la mémoire vidéo à l’aide de l’instruction DOKE, qui affecte l’adresse de mémoire indiquée et la suivante.
Dan n’avait pas réussi à mettre en oeuvre ce processus auparavant même si au final, il est assez simple. Brièvement, chaque image-objet a une taille de 2×2 caractères. Avant de placer une image-objet à l’écran, Dan enregistre la valeur de 2×2 caractères où elle sera insérée dans deux variables numériques. Ceci est fait avec un DEEK, qui est un PEEK 16 bits (à l’image du DOKE qui est un POKE 16 bits). La position de l’image-objet est une adresse mémoire et non deux coordonnées. Avec deux DOKE, il copie rapidement le sprite sur l’écran. Avant de le déplacer, Dan remplace l’arrière-plan à la position correspondante à partir de la valeur stockée dans la variable numérique, modifie la position de l’image-objet, enregistre l’arrière-plan dans la variable, puis le place dans la nouvelle position à l’aide des deux clés. Le résultat est là, efficace.
L’écran Sur ZX-Spectrum, le jeu original a une largeur d’écran de 32 caractères. Deux pour les marges et 15 blocs de 2×2 caractères. Pour que cette version ait le même aspect, Dan aurais dû utiliser des blocs 3×2, mais avec l’ORIC, il est limité à 38 colonnes, loin de son besoin de 47. De fait, Dan a été contraint à réduire la taille des sprites à 2×2. De plus, les caractères de l’Oric font 6 pixels au lieu des 8 habituels. L’aspect final est de fait moins fouillé, mais avec des graphiques rapides mis en oeuvre avec les 2 DOKE.
Comme la largeur de l’écran comporte plus de caractères, Dan a placé une colonne de blocs des deux côtés de l’écran et une colonne inférieure. Cela l’a également aidé à contrôler le déplacement des éléments mobiles du jeu.
Dans le code, sur les lignes 440 à 455, trois lignes calculent quel bloc de fond doit être placé dans une zone de l’écran quand un bloc bleu est supprimé, et lorsque l’on prend la clé ou une pièce de monnaie, ou encore quand un ennemi frappe.
Graphiques Le jeu de caractères ORIC ne comporte que 128 caractères. Dan souhaitait conserver les lettres, les chiffres et certains caractères spéciaux, Il a donc redéfini le minimum de blocs graphiques possibles. L’utilisation de deux caractères en largeur de bloc au lieu de trois a contribué à cet objectif. L’impact principal de ces options a été la suppression du mouvement de jambes de notre personnage ; mais cela a également permis de simplifier quelque peu le code et à améliorer les performances. Dan peut toujours tout montrer avec deux simples DOKE.
Et comme toujours avec les programmes développés par Dan sur ORIC, les graphiques ont dû être redessinés par rapport à la version initiale car au lieu de la matrice habituelle de 8×8 pixels, nous passons à une matrice 8×6 soit 12 pixels horizontaux au lieu des 16 habituels.
Les couleurs … encore un problème ! En raison de la façon dont l’Oric gère les attributs, Dan a choisi de créer Solomon’s Key en monochrome, avec un peu de couleur dans la présentation et dans les marqueurs. Pour mettre en évidence les briques que nous pouvons détruire, Dan a appliqué la technique consistant à utiliser les couleurs complémentaires des deux couleurs principales en ajoutant 128 au code ASCII du personnage (les caractères inversés). permettant d’afficher 4 couleurs sur l’écran de jeu.
L’encodage des niveaux A ce stade, nous arrivons à la création de l’écran. Chaque écran est constitué d’une matrice de 12 lignes et de 15 colonnes. Dans chaque colonne se trouve un tableau de caractères 2×2, tel que des blocs de pierre, des portes, des clés ou des pièces de monnaie. Dan a choisi de coder les niveaux en utilisant un format similaire à «Averno» simplifié. La présentation du niveau prend environ 6 secondes et le codage est effectué comme suit:
Une lettre entre “A” et “Z” a une valeur comprise entre 1 et 26 et correspond aux blocs de pierre à afficher. Alternativement, ils apparaissent en jaune ou en bleu.
Un caractère “*” signifie qu’il modifie le type de bloc de pierre indiqué, bleu ou jaune.
Une lettre entre “a” et “z” a une valeur comprise entre 1 et 26 et correspond à des blocs vides de 2×2.
Un caractère “.” Désigne un bout de la ligne en sautant au suivant.
Un caractère numérique correspond à un objet:
2 portes,
3 clés,
4 devises,
6 têtes et
7 canaux.
1, et 5 correspondent aux blocs de pierre jaune et bleue.
Un écran de jeu de Solomon’s Key, avec l’aperçu de son encodage graphique
Le contrôle du personnage Une des premières difficultés à résoudre avant de commencer à développer le jeu était de savoir comment gérer les différents mouvements et actions que le joueur pouvait faire. La programmation du jeu en Basic prend en compte l’impossibilité d’appuyer sur plusieurs touches simultanément.
Appuyez sur “Z” et “X” pour déplacer le magicien à gauche ou à droite.
En appuyant sur “P” nous sautons. S’il y a un bloc au-dessus, nous le cassons. Sinon, nous pouvons augmenter la hauteur d’un bloc. Si pendant que nous sautons, nous appuyons sur une flèche, nous irons dans cette direction.
En appuyant sur “L” nous insérons ou supprimons un bloc bleu. Si nous sommes juste au-dessus d’un bloc, nous le placerons devant et si nous ne le plaçons pas au niveau du sol.
Les Ennemis Contrairement au jeu “Averno”, dans ce “Solomon’s Key”, il y a des ennemis et ils bougent ! Dan a mis en place une routine très basique qui permet de déplacer jusqu’à cinq ennemis avec deux vitesses différentes (des déplacements de un ou deux caractères), leur déplacement est horizontal ou vertical, et simule l’effet de rebond ou non lorsque vous touchez un mur, en détruisant les blocs bleus touchées. Le tout en sept lignes de code !
Le type de mouvement de l’ennemi et sa position initiale sont définis dans les DATA de la ligne 9600. Chaque ennemi requiert trois caractères :
le premier indique le type
les deux autres la position initiale horizontale et verticale. Pour les positions, Dan utilise des lettres afin d’indiquer des valeurs supérieures à un chiffre avec un seul caractère.
La routine de mouvement contrôle le nombre d’ennemis dans ce niveau. Moins il y a d’ennemis, plus ils se déplacent fréquemment et rapidement.
Les sprites des ennemis se déplacent également sur le fond sans le supprimer. Comme pour le sprite du protagoniste, la technique de sauvegarde du personnage qui était à l’écran avant d’utiliser l’ennemi sur l’écran a été utilisée. Lorsqu’il se déplace, il reconstitue l’arrière-plan, sa nouvelle position est recalculée, puis le graphique de l’ennemi est placé.
Résultat final En ce qui concerne la vitesse, l’ORIC BASIC pourrait être placé dans le milieu de gamme des ordinateurs 8 bits. C’est l’un des plus rapides en impression à l’écran, mais pour le reste, ce serait au niveau du MSX ou du ZX-Spectrum. Des ordinateurs tels que l’Amstrad CPC impriment très lentement à l’écran mais plus rapidement, en parallèle avec des ordinateurs tels que BBC Micro / Electron ou Lynx Camputers. La gamme basse reste pour le ZX-81 et surtout, le Texas Instruments TI / 99-4A qui mange séparément.
Après toutes ces briques, je dois admettre que, malgré les limites imposées par ORIC BASIC, de par son apparence et ses performances, je suis très satisfait. Cela ressemble à un jeu commercial, mais c’est du BASIC pur et dur. Je pense que ce n’est pas habituel de regarder des programmes en BASIC comme celui-ci. Je pense que j’ai placé la barre très haut, mais avec l’expérimentation de ces techniques, je suis sûr que je ferai autre chose bientôt. En fait, au fond de moi, j’ai déjà l’idée d’adapter un classique qui n’existe pas dans ORIC.
Eh bien, rien de plus, je ne peux qu’espérer que cela vous plaise …
Je vous invite à l’essayer.
Quelques éléments concernant le programme
La routine principale du programme est divisée en 10 blocs:
Déclaration des variables et matrices et début du jeu.
Boucle principale de développement.
Mouvement des ennemis.
Mouvement du protagoniste.
Routines des actions du protagoniste.
Passer le niveau ou perdre une vie.
Routine pour montrer le niveau de jeu.
Présentation et début du jeu.
Charger UDG.
DATA avec les UDG du jeu et les valeurs de la matrice.
L’ensemble du programme occupe 170 lignes dont vous trouverez ci-dessous les principales :
5 – Nous définissons les variables du jeu.
10 – Nous définissons les matrices du jeu.
20 – Passez au sous-programme qui redéfinit les caractères et définit les variables globales.
40 – Afficher le niveau à l’écran.
100 – REPEAT indiquant le début de la boucle principale.
105 – Vérifiez si nous sautons.
110 – Si nous n’avons pas de terre sous nos pieds, le personnage tombe.
115 – Prenez la touche appuyée.
120 – Touche de saut.
125 – Bloquer la touche marche / arrêt.
130 – Touche de déplacement à droite.
135 – Touche de déplacement gauche.
140 – Vérifiez si le personnage frappe à la porte, à la clé ou à la pièce de monnaie.
150 – Aller au sous-programme de mouvement ennemi.
155 – Retournez à REPEAT si la variable U = 0.
160 – Lorsque vous quittez la boucle, regardez la valeur de U. U = -1 niveau et U = 2 perd une vie.
200 – Déplace le fantôme vers la droite.
225 – Déplace le fantôme vers la gauche.
300 – Contrôle la chute du personnage.
320 – Détecte quel objet tu as sous le personnage.
350 – Routine de saut.
400 – Mettre / enlever le bloc.
440 – Routine de remplacement en arrière-plan lors de la pose, de la suppression d’un bloc ou de la saisie d’un objet.
500 – Routine pour passer un niveau.
550 – Programme de perte de vie et fin du jeu.
600 – Montre les marqueurs de points, de niveau et de vies.
2000 – Routine qui montre le niveau. Les données sont encodées dans la matrice M $.
2050 – Définissez le type, la vitesse et la direction des ennemis et placez-les à l’écran.
2500 – Écran de présentation.
3000 – Sélection des couleurs, effacement de l’écran, masquage du curseur et masquage des «CAPS» supérieurs.
3005 – Lecture de données UDG.
3010 – Définir des variables avec des bandes de caractères.
9000 – DATA avec graphes, positions, blocs de graphes et codage de niveau UDG.
9200 – Blocs graphiques utilisés par l’instruction DOKE.
9300 – Position initiale du caractère en fonction de l’écran.
9500 – Données de niveau.
9600 – Données avec les types et la position des ennemis.
Le Jeu !
Solomon’s Key est un jeu publié par Tecmo en 1986 et concédé sous licence pour différents systèmes à partir de 1987. US Gold a commandé les versions 8 bits du jeu.
Le jeu est de type plates-formes avec une pincée de jeu de stratégie. Nous y contrôlons un petit sorcier qui doit saisir une clé et sortir pour monter de niveau. Le magicien a la capacité de créer et de détruire des blocs bleus qui lui permettront d’atteindre la clé. Chaque niveau est plein d’ennemis qui te tueront au moindre contact. Le petit sorcier part avec 5 vies.
La version développée par Dan utilise les mêmes mécanismes que le jeu original avec les 17 écrans de la version ZX-Spectrum, qui sont répétés indéfiniment. Le mouvement des ennemis est adapté aux limitations du BASIC.
Contrôles :
Déplacez l’assistant à gauche ou à droite avec “Z” et “X”.
Appuyez sur “L” pour créer ou détruire un bloc bleu. Selon votre position, il sera créé devant vous à votre hauteur ou à une hauteur inférieure.
Appuyez sur “P” pour sauter, avec en plus la possibilité de contrôler la direction en appuyant sur “Z” ou “X”. Si vous avez un bloc en haut, vous le détruisez d’un coup de tête.
Comparons …
Comparaison des versions Oric-Atmos et ZX-Spectrum
Comme indiqué dans le sous-titre, il s’agit d’une version améliorée de Radar Oric (voir le CEO-mag n°358, pages 4 & 5 et RadarOric.dsk dans le fichier 358.zip). Outre de nouvelles commandes, cette version comporte 48 nouvelles grilles réparties en 3 niveaux de difficulté (1 Fastoche, 2 Faisable et 3 Fortiche). Autre petit plus : Le jeu est maintenant bilingue Anglais et Français.
Rappel du synopsis
Votre QG est attaqué par une flotte ennemie et pour vous défendre, vous disposez d’un tout nouveau radar couplé à un ordinateur dernier cri : l’Oric. Votre tâche est de localiser exactement la position de tous les bateaux ennemis, puis de déclencher un feu apocalyptique qui les anéantira.
Vitesse de déplacement du curseur
A l’usage, il est apparu que Radar Oric pouvait être amélioré.
Tout d’abord, le déplacement du curseur trainait beaucoup trop lentement dans les 100 cases de la grille. J’ai donc un peu revu l’algorithme du jeu afin de perdre le moins de temps possible. Cela a entraîné une redéfinition des labels à attribuer aux cases. Ces labels, sont maintenant passés de 1 à 9 :
1 – Case vide
2 – De l’eau (et sans sous-marin par-dessous !)
3 – Élément de bateau présent mais indéterminé ou hypothèse de présence d’un élément
4 – Sous-marin
5 – Extrémité “gauche” d’un navire
6 – Extrémité “droite” d’un navire
7 – Extrémité du “haut” d’un navire
8 – Extrémité du “bas” d’un navire
9 – Élément du corps d’un navire
La nouveauté importante est l’ajout du label 3 qui permet de placer des hypothèses, ce qui n’est pas du luxe pour les grilles de “Fortiches”.
Autre innovation pour accélérer les déplacements : les mystérieuses commandes H et V. En fait, elles n’ont rien de mystérieux. C’est plutôt que je n’arrivais pas à décrire ces commandes de manière concise dans mon écran d’instructions ! Les commandes H ou V éditent la ligne Horizontale ou la colonne Verticale où se trouve le curseur. Cette édition consiste à marquer toutes les cases de la ligne ou de la colonne avec le label 2 (de l’eau), sauf si une hypothèse ou un élément de bateau est déjà présent. Cerise sur le bateau, le compteur des coups joués n’est pas incrémenté : non seulement vous gagnez du temps dans le déplacement du curseur, mais vous améliorez vos performances, qui je le rappelle sont la combinaison d’un score maximum ET d’un nombre minimal de déplacements. En outre, vous réduirez vos déplacements car le curseur reste à la position initiale, ce qui vous permet d’atteindre des cases distantes sans perdre de temps pour vous y rendre et pour revenir !
Nouvelles commandes
Le jeu comporte maintenant 7 commandes au lieu de 4.
Outre le commandes H et V décrites ci-dessus et les commandes déjà présentes dans la première version (flèches de déplacement, numéros de label pour les cases, R pour reprendre au début la grille en cours et S pour sauver la partie en cours afin d’aller faire dodo), la nouvelle version offre la commande L qui permet de charger (Load) la partie précédemment sauvegardée. Dans la première version de Radar Oric, on ne pouvait choisir cette option que lors du lancement du jeu. Recharger la partie sauvegardée sort donc maintenant de son rôle initial (reprise de la partie le lendemain).
En effet, au cours de la résolution d’une grille complexe, lorsque plusieurs possibilités s’offrent à vous, il est intéressant d’effectuer une sorte de point de restauration avec la commande S. Si la voie dans laquelle vous vous étiez engagée se révèle erronée, il vous suffit de restaurer l’état précédent avec la commande L et de tester une autre hypothèse. La commande R au contraire régénère la grille à son point de départ. Cette commande sert en principe à repartir sur un bon pied lorsque la situation est devenue trop embrouillée. Le score affiché est alors celui qui était présent lors du chargement initial de cette grille et non celui qui était acquis au moment “du point de restauration”. J’espère que vous apprécierez la meilleure jouabilité de Radar Oric 2 et que ce petit jeu de réflexion vous apportera quelques moments agréables…
Comme nous l’avons vu dans l’article précédent, peu importe
que le logiciel à traiter soit protégé ou non, l’essentiel est qu’il soit
possible de le faire tourner sur un émulateur et de pouvoir réaliser un dump de
la mémoire.
Disons que si le logiciel n’est pas protégé (ou s’il a été
déverrouillé), il est plus facile de savoir s’il est écrit en Basic ou en
langage machine, s’il tourne en mode TEXT ou HIRES, s’il utilise les zones
normales de stockage des caractères et les procédures normales d’affichage.
Il y a trois grandes catégories de logiciels :
1. Ceux dont les caractères sont redéfinis
uniquement lors du lancement.
2. Ceux dont les redéfinitions évoluent au fil de l’exécution.
3. Ceux dont les caractères ne sont pas redéfinis (oups !).
1) Logiciels dont les caractères sont redéfinis uniquement lors du lancement
Dans cette catégorie, j’ai pris comme exemple “Rush
Hour” de Fabrice F. En effet ce logiciel est particulièrement astucieux.
Pour contourner les difficultés d’un cahier des charges très
lourd, Fabrice a recopié les caractères utiles du jeu 0 dit “normal”
dans le jeu 1 dit “semi-graphique” (dont les caractères d’origine
sont évidemment écrasés). Pour l’affichage de texte standard, il faudra
désormais utiliser le mode “semi-graphique” !
Les 96 caractères du jeu 0 étant
“disponibles” ont été redéfinis pour afficher les sprites de divers
véhicules. Notez que ce programme n’est pas protégé et que son listing est bien
documenté.
Procédure dans Euphoric :
Lancez Euphoric, chargez “Rush Hour” (RUSHHOUR.TAP) et lancez-le.
Avancez dans le jeu, dans mon exemple, jusqu’au “Level 11” (choix “Harder”).
Pressez la touche F9 pour générer un dump mémoire. Renommez par exemple en DumpRH.BIN
Pressez F12 pour générer une recopie d’écran au format .BMP. Renommez par exemple en RushHourLevel11.BMP
Laissez Euphoric en attente.
Procédure dans votre éditeur hexadécimal :
1. Ouvrez le modèle d’en-tête SAVJ0TXT.TAP
(voir article précédent). CTRL+A puis CTRL+C pour copier les 23 octets du
fichier.
2. Ouvrez un nouveau document. CTRL+V pour y
coller l’en-tête. Modifiez cet en-tête uniquement pour le renommer (par exemple
RHJ0TXT).
3. Ouvrez le fichier DumpRH.BIN de “Rush
Hour”. Allez à l’offset #B500 et sélectionnez les #0300 octets du jeu 0,
puis tapez CTRL+C pour copier cette zone.
4. Allez à la fin de l’en-tête dans le
nouveau document. CTRL+V, pour y coller le jeu 0.
5. Sauvegardez votre jeu sous le nom
RHJ0TXT.TAP (Rush Hour, Jeu 0, mode TEXT).
6. Faites la même chose pour le jeu 1
(SAVJ1TXT.TAP, RHJ1TXT, #B900, #0200 octets, RHJ1TXT.TAP).
7. Toujours dans votre éditeur hexadécimal,
réglez l’affichage pour 40 octets par ligne, afin qu’une ligne dans l’éditeur
corresponde à une ligne de l’écran Oric et allez en #BB80 (début de l’écran
TEXT).
8. Reprenez la fenêtre d’Euphoric qui était restée en attente et placez là immédiatement à gauche de la zone d’affichage des codes Ascii de votre éditeur (voir la figure ci-dessous). Vous avez maintenant la correspondance entre les véhicules de “Rush Hour” à gauche et les codes Ascii utilisés pour l’assemblage des sprites !
2) Logiciels dont la redéfinition des caractères évolue au fil de l’exécution
Cette
catégorie est semblable à la précédente, sauf que les caractères sont redéfinis
pour chaque phase du jeu !
L’exemple
le plus frappant est “The Hellion” avec 101 écrans où se meuvent les
sprites d’objets très différents en quantité invraisemblable. En fait, les 101
tableaux de “The Hellion” représentent un cas extrême de
redéfinitions à répétition.
Ce
logiciel fonctionne en mode TEXT et les 2 jeux de caractères sont partiellement
redéfinis.
Vous trouverez le programme (HELLION.WAV, HELLION.TAP
& HELLION.DSK au choix), ainsi que les fichiers utilisés ou produits dans
cet exemple dans le zip qui accompagne cet article.
Procédure dans Euphoric
Il
faut traiter “The Hellion” comme s’il s’agissait d’une série de 101
programmes indépendants, mais réunis à la queue-leu-leu. La procédure suivante
devra donc être répétée pour chaque tableau :
1. Pressez
la touche F9 (sauvegarde d’un dump de la mémoire) au début de chaque tableau.
2. Puis, le plus vite possible, pressez la touche F12 pour avoir une recopie de l’écran correspondant à ce dump (le plus rapidement possible car les sprites se déplacent très vite).
3. Et enfin pressez F11 pour geler la série de tableaux, le temps de renommer le fichier “DUMP” en “DumpH-xx.bin” ainsi que la recopie d’écran en “Hellion-xx.bmp”, xx étant le n° du tableau.
Procédure dans votre éditeur hexadécimal :
Chacun des fichiers
“DumpHxx.bin” sera traité dans votre éditeur Hexadécimal pour en
extraire les deux jeux de caractères et afficher la zone d’écran TEXT. Prenons
par exemple le fichier DumpH04.bin :
Ouvrez le
modèle d’en-tête SAVJ0TXT.TAP. CTRL+A puis CTRL+C pour copier les 23 octets du
fichier.
Ouvrez un
nouveau document. CTRL+V pour y coller l’en-tête. Modifiez cet en-tête pour le
renommer (par exemple “H04J0TXT”).
Ouvrez le
fichier “DumpH04.bin”. Allez à l’offset #B500 et sélectionnez les
#0300 octets du jeu 0, puis tapez CTRL+C pour copier cette zone.
Allez à la
fin de l’en-tête dans le nouveau document. CTRL+V, pour y coller le jeu 0.
Sauvegardez
votre jeu 0 par exemple sous le nom H04J0TXT.TAP (Hellion, tableau “Wave
4”, Jeu 0, mode TEXT).
Faites la
même chose pour le jeu 1 avec le modèle SAVJ1TXT.TAP et sauvegarder le jeu 1
par exemple sous le nom H04J1TXT.TAP (Hellion, tableau “Wave 4”, Jeu
1, mode TEXT).
Toujours
dans votre éditeur hexadécimal, réglez l’affichage pour 40 octets par ligne,
afin qu’une ligne dans l’éditeur corresponde à une ligne de l’écran Oric et
allez en #BB80 (début de l’écran TEXT).
Reprenez la
fenêtre d’Euphoric qui était restée en attente et placez là immédiatement à
gauche de la zone d’affichage des codes Ascii de votre éditeur (voir la figure ci-dessous).
Vous avez maintenant la correspondance entre les “feux tricolores” de
“The Hellion” à gauche et les codes Ascii utilisés pour l’assemblage
de ces sprites à droite !
Si on compare le jeu 0 obtenu
à partir de ce tableau “Wave
4” avec le jeu 0 natif de l’Oric, on constate que deux caractères
seulement sont redéfinis : { (Ascii 123)
et } (Ascii 125) (et cette
redéfinition varie d’ailleurs d’un tableau à l’autre).
Pour le reste, les sprites
affichés sont formés avec des caractères du jeu 1 (un attribut #09 est placé au
début de chaque ligne d’écran).
Dans le tableau “Wave
4” (voir la figure ci-dessus), les objets volants (des feux tricolores)
sont redéfinis avec les caractères 1 2 3 4 ou 5 6 7 8 ou 9 : ; < disposés verticalement.
C’est plus compliqué pour
l’oiseau du bas de l’écran, car celui-ci vole et plusieurs sprites se succèdent
pour réaliser cette animation. J’ai détecté des images redéfinies avec = > ? sur une 1e ligne et @ A B en dessous, ou C D E et F G H ou I J K et L M N ou O P Q et R S T ou U V W et X Y Z. L’animation est donc
réalisée avec 5 images. Avec 6 caractères redéfinis par image, cela fait 30
caractères redéfinis rien que pour l’oiseau !
Dans tous les cas (feux
tricolores ou oiseau) un attribut de couleur est placé juste à gauche de
chacune des lignes des sprites, ce qui permet d’obtenir des sprites
multicolores.
Pour ne pas alourdir cet
article, je ne montre que ce tableau “Wave 4”. Mais dans le tableau
suivant “Wave 5”, chaque sprite est défini par les mêmes 4 caractères
1 2 3 4 ou 5 6 7 8 ou 9 : ; < disposés sur deux lignes. Or
ces caractères ont été redéfinis entre temps puisque les dessins affichés sont
différents. L’oiseau qui ressemble comme deux gouttes au précédent est affiché
à partir des même 5 jeux de redéfinitions que précédemment !
Je ne suis pas allé plus loin dans mon analyse des 101
tableaux de “The Hellion”. Mais si certains sprites vous intéressent,
vous devriez pouvoir les récupérer sans difficulté en suivant mes indications.
3) Logiciels dont les caractères ne sont pas redéfinis
Avant
de vouloir récupérer des caractères redéfinis, il serait sage de s’assurer
qu’il y en a. La présence de sprites sur l’écran ne signifie pas que des
caractères ont été redéfinis. C’est, la plupart du temps, le cas pour les
programmes qui tournent en mode Hires et qui sont, quasiment à coup sûr, écrits
en langage machine. En effet, le Basic n’est pas assez rapide pour faire
évoluer des sprites sur l’écran (ni même des caractères via la commande CHAR).
Pour
cette catégorie de logiciels, il s’agira plutôt de récupérer des sprites. Mon
prochain article :
“Récupérez les sprites de tous les logiciels en HIRES” montrera comment s’y prendre sans avoir à désosser le langage machine.
Après une longue pause de programmation sur Oric, L’année 2019 démarre en fanfare avec ce nouveau jeu proposé par DanCresp, une pleine réussite qui a été traduite en Français quelque peu modifiée par Dom.
Informations générales
Dan a été presque quatre ans sans rien programmer pour l’ORIC. Comme le temps passe vite ! Il est de retour, avec quelques nouvelles découvertes sur son système préféré.
Cette fois, c’est une adaptation assez fidèle d’un jeu acheté pour MSX qu’il a apprécié, beaucoup aimé et qui a laissé chez Dan de bons souvenirs.
Il existe des versions pour plusieurs systèmes, vous pouvez maintenant ajouter l’ORIC. Sur l’Oric, le jeu a un mécanisme identique à celui d’origine, mais avec quelques améliorations et quelques petites choses que Dan a laissées de côté. Il lui a fallu près d’une semaine pour réaliser une version jouable !
Ecran titre de la version 2019 sur Oric
Dan est très satisfait de cette version car le jeu a les mêmes niveaux que la version originale, la même résolution des niveaux et les performances du jeu sont identiques aux versions originales, voire un peu plus élevées … sauf pour la génération de l’écran.
Les petites détails de la version ORIC Comme toujours pour la programmation dans l’ORIC, les graphismes ont dû être repensés car au lieu de la matrice habituelle de 8×8 pixels, nous passons à une matrice de 8×6. Comme les graphiques sont formés avec deux blocs de 1×2 caractères ou 2×2 caractères de 8×8 pixels, nous avons des blocs de 8×16 pixels ou 16×16 pixels.
La solution choisie par Dan consiste à utiliser des blocs de 1 x 3 ou 2 x 3 caractères, de sorte que les blocs aient une largeur de 18 pixels et non de 16 pixels. Comme il ne pouvait pas utiliser de couleurs pour délimiter les blocs, l’auteur a laissé une bande de pixels vide au début. et à la fin de certains graphiques pour les rendre moins déroutants. Contrairement à la version d’origine, la porte et les clés ont toutes deux un masque pour mieux s’intégrer à l’arrière-plan.
Lorsque sont placés les graphiques à l’écran, ils prennent presque toute la largeur de l’écran. Dan a donc supprimé certains marqueurs, le reste étant placé en haut, car l’ORIC comporte plus de lignes.
Un autre problème a été le problème de la couleur, en raison de la façon dont il gère les attributs, Dan a dû produire un jeu en monochrome, en donnant toutefois un peu de couleur dans la présentation et dans les marqueurs. Dommage, mais très ORIC !
L’écran du 1er niveau, en monochrome Le truc du mag, le fantôme ne peut monter que 2 marches à la fois … pensez y !
A ce stade, nous arrivons à la création de l’écran. Chaque écran est constitué d’une matrice de 20 lignes et de 10 colonnes. Dans chacune des colonnes, il y a un graphique ou une partie de celui-ci, comme avec les portes et les clés. En codant de manière brute, une matrice de 13 (écrans) x 20 (lignes) x 10 (colonnes) aurait pu être créée. Au total, 260 lignes de code, avec la quantité de mémoire correspondante, de 600 octets par niveau. Au lieu de cela, l’auteur a choisi de coder les niveaux, chaque niveau étant compris entre 50 et 100 octets. La présentation du niveau prend environ 6 secondes et le codage est effectué comme suit, l’écran étant bleu:
Une lettre entre “A” et “Z” a une valeur comprise entre 1 et 26 et correspond aux blocs de briques de l’arrière-plan à afficher.
Une lettre entre “a” et “z” a une valeur comprise entre 1 et 26 et correspond aux blocs de pierre à afficher.
Un nombre compris entre 1 et 8 correspond à un bloc prédéfini stocké dans la matrice B $, en mettant ce qui entre dans la ligne correspondante.
L’encodage des niveaux sur Oric
Avec ce nouveau logiciel, Dan a découvert de nouvelles difficultés. Ainsi, c’est la première fois qu’en BASIC, il fait bouger le protagoniste sur le fond sans le supprimer. Pour ce faire, un deuxième processus doit être effectué, ce qui prend environ 10 secondes. Au cours d’une boucle double, Dan lit la mémoire d’écran et conserve les caractères à l’écran dans la matrice “S”. Pendant le processus de lecture de la mémoire vidéo, l’auteur crée un effet d’aveuglement qui change la couleur de la ligne en jaune final. Ce n’est pas du plus bel effet, mais c’est nécessaire pour déplacer le personnage rapidement.
Le jeu original utilise des blocs cachés à plusieurs niveaux. Dan a découvert ce détail en regardant une vidéo alors que son adaptation du jeu était presque terminée et a choisi de les ignorer. Cela l’a obligé à faire quelques changements mineurs dans ces niveaux, car dans cette version, les blocs sont visibles. Cependant, ils n’affectent pas la résolution des niveaux.
Pour contrôler le curseur, le clavier est lu à l’aide d’un «PEEK 520» ($208 pour les intimes), ce qui évite les problèmes de lettres majuscules / minuscules et vous garantit de toujours lire la dernière touche enfoncée, en accédant à la mémoire tampon du clavier.
Et pour le son, une fois encore, Dan a utilisé les effets prédéfinis de l’ORIC, démontrant ainsi sa faiblesse dans ce domaine …
Pour terminer, ayant respecté les niveaux d’origine, Dan trouve que la difficulté n’est pas linéaire et que les niveaux les plus simples se situent au début et à la fin de la partie. Mais comme le jeu original était comme ça, l’auteur l’ai laissé ainsi.
Dan vous invite à l’essayer et espère que ce jeu vous plaira …
Quelques informations à propos du programme
Le programme est divisé en 10 blocs:
Déclaration de la matrice et début du jeu.
Boucle principale de développement.
Passer le niveau ou perdre une vie.
Mouvement fantôme.
Présentation et début du jeu.
Routine pour afficher le niveau.
Écran de victoire finale.
Préparez et montrez l’aire de jeu.
Charger UDG.
DATA avec les UDG du jeu et les valeurs de la matrice.
L’ensemble du programme occupe 137 lignes.
10 – Nous définissons les matrices du jeu.
20 – Passez au sous-programme qui redéfinit les caractères et définit les variables globales.
30 – Afficher l’écran de présentation.
40 – Afficher le niveau.
100 – Début de la boucle principale.
105 – Prenez la touche appuyée. Si vous appuyez sur “Echap”, quittez la boucle et perdez une vie.
110 – Mouvement fantôme selon la touche enfoncée.
122 – Actualiser le repère temporel.
125 – Voyez ce qu’il y a sous le fantôme, agissez en conséquence.
135 – Mise à jour du temps, laissant la boucle si elle se termine.
140 – Retournez à REPEAT si la variable U = 0.
150 – Lorsque vous quittez la boucle, regardez la valeur de U. U = 1 pour passer le niveau ou U = 2 pour perdre une vie.
155 – La routine de la mort
200 – Déplace le fantôme vers la droite.
250 – Déplace le fantôme vers la gauche.
300 – Contrôle la chute du fantôme, surveillant s’il passe au-dessus d’une clé ou d’une porte.
400 – Montre le fantôme. Avec D = 1, regardez à droite et D = -1, à gauche.
420 – Routine de collecte de clés. Il met U = 1 si tous ont été collectés.
450 – Actualiser le marqueur de temps.
460 – Actualiser le marqueur de point.
500 – Lancer un bloc de briques. Calculez la position du fantôme pour dire quel bloc devrait tomber.
2000 – Écran de présentation.
2100 – Routine qui montre le niveau. Les données sont encodées dans la matrice M $.
2130 – Double boucle qui enregistre les caractères de chaque position sur l’écran dans la matrice D.
2200 – Écran de fin de jeu à la fin du niveau 13.
3000 – Sélection des couleurs, effacement de l’écran, masquage du curseur et masquage des «CAPS» supérieurs.
3005 – Lecture de données UDG.
3010 – Assemblez des matrices avec des bandes de caractères et des positions du fantôme.
9000 – DATA avec graphes, positions, blocs de graphes et codage de niveau UDG.
Le jeu
Averno est un jeu publié pour plusieurs systèmes en 1989. C’est un jeu de réflexion dans lequel nous contrôlons un fantôme qui doit collecter toutes les clés du niveau pour ouvrir la porte. Vous devez ouvrir les 13 portes pour échapper aux dégâts. Nous devons éviter de manquer de temps ou de rester coincés.
Le fantôme a la capacité de déposer des blocs de briques pour accéder à certaines parties du niveau ou de s’y placer, car il ne peut pas escalader les murs de plus de deux blocs de briques. Vous pouvez seulement déposer des blocs qui n’ont rien en dessous.
Cette version suit exactement la même mécanique et les 13 écrans sont identiques au jeu original, sauf que les blocs invisibles ont été supprimés, ce qui n’affecte pas la résolution des niveaux.
Contrôles :
Déplacez le fantôme vers la droite ou la gauche avec “Z” et “X”.
Appuyez sur “Entrée” pour déposer un bloc de briques, selon que vous êtes dessus ou partiellement dessus.
Appuyez sur “Echap” si vous êtes verrouillé. Vous allez perdre l’une de vos 5 vies.
Actuellement, Assinie et moi travaillons dessus. Des tests ont été fait pour faire tourner glOric. Il y a beaucoup de choses de faites, mais elles sont surtout en béta.
Que permet Orix ?
Orix est un ensemble de binaires/kernel qui permet de gérer un shell et des routines d’accès au hardware de la carte twilighte. L’objectif est de faire tourner tout ce qu’on veut sur l’oric quelques soit l’OS initial, ou le support (tap/dsk etc).
Une première démo est sortie il y a en 2017. Cette démo était plus un proof of concept car beaucoup de choses étaient faites par bidouilles.
Certaines ROM en plus du shell sont disponibles avec leur programme associé :
un basic 1.1 modifié pour charger des .tap à partir de la sdcard. Une version existe pour charger sur le port USB avec une clé USB. Il suffirait de charger cette ROM en ROM ou en RAM (car la twilighte board pourrait charger n’importe quelle ROM dans ses 64 banques.
le forth modifié pour accéder à la SDCARD, ce n’est ni plus ni moins que teleforth
Monitor est un moniteur qui est en réalité teleass en version light car il n’y a pas l’assembleur embarqué pour l’instant
Quelques commandes linux/unix sont présentes :
ls : affiche la liste des fichiers
man : affiche la doc d’une commande
./ : lancement d’une commande du répertoire courant
cp : copie un fichier
mv : déplace un fichier
env : permet de voir quelques variables d’environnement
sh : qui permet de lancer des script shell minimalistes
meminfo : affiche la quantité de mémoire disponible et la quantité de mémoire restante
lsmem : affiche l’occupation de la mémoire par les process
ps : affiche la liste des process
exec : permet de lancer des commandes
touch : créé un fichier
Plusieurs binaires sont disponibles en plus des commandes type linux/unix qui sont propre à Orix
bank : affiche les banques disponibles et leur signature
help : affiche les commandes en bash et en ROM (avec un paramètre -b pour afficher les commandes de la banque passée en paramètre)
viewhrs : permet de voir des images en hires
bootfd : démarre le bootsector d’une disquette : ne fonctionne que sur telestrat.
twil : permet de piloter la carte twilighte (swap du jeu de banking, passage en SRAM ou en ROM sur les 4 dernières banques de 16KB chacune, affichage du firmware de la carte)
vidplay : affiche des vidéos en streamant à partir de la sdcard
gunzip : binaire pour décompresser
kernupd : pour mettre à jour la rom en direct sur atmos.
Où en est on sur Orix ?
Beaucoup de choses sont faites, mais il y a beaucoup de bugs. Tout le monde peut participer, le code est disponible sur github. Le hardware n’est pas ouvert, mais le code oui. Il est possible de faire des ROMs simplement, de rajouter des binaires, travailler sur les process, la mémoire, les drivers.
Premiers pas sur Orix
A partir du moment, où vous avez le prompt (sur réel ou Oricutron), commençons par lister les ROM dispos :
# bank
Ok mais je n’ai que 7 banques d’affichées ! On me disait que j’avais 32 banques !
Le choix a été fait de n’afficher que 7 banques tout le temps, mais de jouer sur les banques 4,3,2,1 pour afficher les banques supplémentaires. Ceci afin de garder le fonctionnement iso entre le Telestrat et atmos.
Basculons de jeu de banques pour la banque 4,3,2,1 : cela ne fonctionne pas avec Oricutron, mais sur réel oui : les banques 4,3,2,1 affichent des signatures différentes :
# twil -s1
# bank
Si dessous la vidéo montre le fonctionnement de la carte est du switch de banque. C’est comme si sur telestrat, nous changions physiquement la cartouche port droit, sauf que c’est ici sans arrêt de machine, car c’est le hard et le soft qui gèrent tout cela.
En effet, pour garder une compatibilité avec le telestrat, il a été décidé de n’afficher que 7 banques. Aussi, le kernel qui est issu de telemon, ne gère que 7 banques. Pour ne pas à avoir tout à modifier, la twilighte card fonctionne dans le mode “7 banques” tout le temps à l’affichage. A l’avenir, il sera possible de présenter 31 banques. mais cela nécessitera une modif du kernel et du firmware de la carte. Aussi, le paramètre “twil -s” accepte une valeur entre 0 à 8. La valeur 4 est un peu spéciale : elle affiche en banque 4,3,2,1 une banque en plus, puis le kernel, puis le basic1.1 puis le shell.
Démarrer un fichier .tap
La rom basic11 ne sait gérer que du tap dans un seul fichier. Le multitap ne fonctionne pas. C’est une limite sofware. En revanche, il est possible de charger plusieurs .tap dans le programme basic : un “10 cload “toto.tap”” sera chargé. C’est le cas pour zip&zap par exemple. Prenez des fichiers .tap, et mettez les à la racine de la sdcard. Puis taper :
# basic11
La rom basic 11 a démarré
il suffit de faire le cload du fichier déposé à la racine de la sdcard, le programma va démarrer tant qu’il n’est pas en multitap.
Comment utiliser Orix actuellement ?
Actuellement, il n’y a l’émulation que du contrôleur sdcard sur Oricutron. Ce qui veut dire que la partie swap de banques et accès à la RAM supplémentaire n’est pas possible sur Oricutron. Néanmoins, il est déjà possible de l’utiliser. Sur Oricutron, il y a déjà les roms de dispos. Il suffit de démarrer Oricutron en mode telestrat, en mettant en banque 7, le kernel, en banque 6, la rom basic11 modifée et le shell en banque 5
Avec RadarOric, Fifteen Puzzle est un des premiers jeux de l’année 2020. Rax et Iss nous ont concocté un magnifique jeu de réflexion. J’avoue n’avoir jamais été fan de ce type de jeu car ces puzzles type Rubik’s Puzzle et consorts ne m’ont jamais trop réussi. Cette sortie est donc l’occasion de découvrir le genre et surtout les méthodes qui me permettent enfin de finir ces casse-têtes.
Petit historique pour commencer …
Ces jeux de réflexion ou l’on pousse des pièces pour les remettre dans l’ordre est également appelé “taquin” (NDLR : Rax et Iss le sont ils ?). Ce solitaire se présente sous la forme d’un damier et a été créé vers 1870 aux États-Unis. Comme toujours dans les domaines du jeu, le concept est associé à une théorie mathématique qui a été publiée par l’American Journal of mathematics pure and applied en 1879 (franchement, je préfère être publié dans le CEO-MAG). En 1891, alors que le jeu passionne, son invention est revendiquée par Sam Loyd. En fait, le premier jeu de taquin connu date de 1880 et il est de Noyes Chapman. Sam Loyd l’a popularisé. Sans internet, le jeu a tout de même mis quelques mois à se répandre dans les chaumières. La version la plus classique est composée de 15 carreaux numérotés de 1 à 15 qui glissent dans un cadre prévu pour 16 (sur une matrice de 4×4). Il faut donc que le joueur remette dans l’ordre les 15 carreaux à partir d’une configuration initiale quelconque.
Le principe a été étendu à toutes sortes d’autres jeux. La plupart sont à base de blocs rectangulaires plutôt que carrés, mais le but est toujours de disposer les blocs d’une façon déterminée par un nombre minimal de mouvements. Le Rubik’s Cube est aujourd’hui considéré comme l’un des «descendants» du taquin.
Le Concept
Le jeu qu’il proposait était le 14-15. Il s’agissait de remettre les pions mobiles dans l’ordre séquentiel correct. Loyd promettait un prix à celui qui y arriverait. Il était, en fait, infaisable … car les pavés 14 et 15 étaient inversés.
L’insoluble taquin de Loyd
Pour répondre au petit casse-tête de Sam Loyd, nous allons étudier comment les configurations du taquin changent par les mouvements autorisés. Il sera plus facile de travailler avec des nombres disposés à la queue-leu-leu plutôt que rangés dans un tableau. Voici comment nous rangeons les nombres : à une position du taquin, on associe la liste des numéros que l’on rencontre en parcourant les cases le long du chemin indiqué ci-dessous. On ne tient pas compte de la case vide. Le chemin vert ressemble à une file d’attente aux guichets d’une gare, entre des barrières qui zigzaguent, n’est-ce pas ?
On obtient ainsi un rangement des nombres de 1 à 15. Par exemple, le rangement associé à la configuration de départ du taquin est “4 – 3 – 2 – 1 – 5 – 6 – 7 – 8 – 12 – 11 – 10 – 9 – 13 – 14 – 15”. Le rangement des nombres de 1 à 15 ne détermine pas complètement la configuration du taquin, car il ne donne pas d’information sur la position de la case vide. Mais comme on peut promener la case vide le long du chemin par les mouvements autorisés du taquin, peu importe : si l’on peut arriver à l’une des configurations donnant un certain rangement, on pourra aussi arriver à toutes les configurations donnant le même rangement.
Le critère le plus important pour qualifier le taquin est le dérangement. Le « dérangement » est le nombre de paires inversées pour obtenir une séquence croissante de 1 à 15. Dans le cas simple ci-dessus du Taquin de Loyd, seule la paire 14-15 est inversée (le brigand). Le dérangement est donc de 1, donc impair. La plupart du temps, calculer le dérangement est fastidieux mais il permet de vérifier que le jeu est soluble. En effet, si le dérangement est impair, les pièces ne peuvent pas être repositionnées dans l’ordre désiré. D’un rangement R donné des nombres de 1 à 15 (ou de 1 à un entier quelconque) par rapport au rangement par ordre croissant. On dira qu’une paire de nombres présente une inversion dans le rangement R si le plus grand des deux nombres vient avant le plus petit dans R. Par exemple, dans le rangement suivant des nombres de 1 à 9
On a prouvé par ordinateur que le jeu de taquin n’exige jamais plus de 80 mouvements.
Fifteen Puzzle
Le jeu proposé par ISS et Rax est magnifique. Moderne, en Hires et agrémenté au choix de bruitages et de musique, il met en oeuvre plusieurs designs ; des classiques dés numérotés de 1 à 15 à de beaux puzzles qui tirent parti des capacités graphiques de l’Oric (NDLR : Ils auraient quand meme se mettre à la page de l’égalité homme-femme).
L’écran titre annonce la couleur et sert de mode d’emploiOh mon bateau oh oh oh !Quel est donc ce virtuose du dessin sur Oric : Rax ou Iss ?Il n’y a pas à dire, ils nous régalent avec ce soft
Pour finir en toute tranquillité ce puzzle, sans altérer l’oeuvre des auteurs.
Ici, point de peek, de poke, de call … il y a une méthode infaillible que j’ai réussi à mettre en oeuvre sans mettre en oeuvre de compétences oriciennes. Partons du principe que la case vide est placée en bas à droite du puzzle.
remettre le jeu dans l’ordre ligne par ligne en commençant par la ligne du haut. répéter la manip pour la seconde ligne.
quand il ne reste plus que les deux lignes du bas mélangées, les réordonner colonne par colonne en commençant par celle de gauche.
lorsque les 2 colonnes de gauche sont ordonnées, il ne nous reste plus qu’à conclure en mettant en ordre les 3 derniers carrés à leurs places respectives.
Etes vous prêts à relever le défi ?
Bien sur, les experts de ce type de jeu boucleront l’énigme rapidement est en un nombre minimal de coups mais cette méthode est simple à mémoriser et aboutit dans tous les cas (si la solution est possible)
Les puzzles basés sur des images sont bien plus difficiles à résoudre…
Ceci est une nouvelle version de l’un des jeux préférés de Dan Cresp pour le ZX-81, adapté d’abord sur MSX et SHARP MZ-700,
Fungaloids, sur Sharp MZ-700
Dan a décidé de créer une version “Cellophane Edition” pour ORIC, pour laquelle il a travaillé davantage sur la partie graphique et adapté le jeu à 36 colonnes au lieu de la version originale ou de 40 sur le MZ-700.
D’un côté, Dan aurait aimé avoir un jeu différent au niveau des couleurs, mais les limitations de l’ORIC ne l’ont pas permis. Il a donc décidé de le présenter tel quel, ce qui lui donne un aspect très rétro. Ce résultat est magnifique.
Les performances de l’ORIC sont très bonnes pour certaines choses, tel que le traitement des polices de caractères, mais en retrait pour d’autres aspects, ce qui fait que le jeu n’est pas aligné avec la fluidité que souhaitée. Comme tous les ennemis sont représentés par un seul personnage, Dan a décidé de passer directement sur l’écran vidéo par des POKE, au lieu d’utiliser le PLOT. Cela a simplifié le code et amélioré les performances.
La boucle principale se répète jusqu’à ce que nous perdions la seule vie que nous ayons. A chaque passage, nous ne déplaçons qu’un des ennemis, sélectionné aléatoirement avec un nombre compris entre 0 et 2 :
0 : Nous levons ou baissons la barrière d’énergie au hasard.
1 : Au hasard, nous élevons ou abaissons l’un des navires ennemis.
2 : Pour les fongoïdes, nous calculons un grand nombre aléatoire. S’il est inférieur à 6, nous faisons croître le Fungaloid correspondant et sinon nous ne faisons rien. Cela les fait progresser plus lentement, mais au fur et à mesure que le jeu avance, le nombre que nous calculons diminue et, par conséquent, augmente sa vitesse et sa difficulté.
Pour détecter les collisions, j’utilise certaines variables qui indiquent la position absolue dans la mémoire de l’écran sur laquelle se trouve l’aile gauche de notre navire, ou notre tir. En accédant à la mémoire vidéo avec un PEEK, nous pouvons voir que nous jouons. Cela nous évite de nombreux calculs et cela reste assez précis.
Dans le jeu original, il faut survoler un Fungaloid et lui tirer dessus. Ici, pour gagner de la vitesse, j’ai choisi de lui faire tirer dessus en détruisant un fragment de Fungaloid. Donc, je prends le même code qui me dit que Fungaloid est parvenu à poser sa balle sur le sol correspondant.
La vérité, c’est que Dan aurait aimé apporter quelques modifications, mais il a choisi de conserver l’esprit du jeu original. Bien que complètement programmé en BASIC, le jeu a atteint une vitesse très convenable et vous permet de jouer parfaitement. Bien sûr, comme pour les autres logiciels crées par Dan Cresp, le son reste le point faible.
Je vous invite à l’essayer
Quelques informations à propos du programme
Dan a divisé le programme en 11 blocs:
Déclaration de la matrice et début du jeu.
Contrôle de notre vaisseau.
Déplace les ennemis.
Contrôle du tir.
Contrôle du projectile ennemi.
Fin du jeu.
Niveau de passage.
présentation
Afficher l’écran de jeu et initialiser les variables.
Plusieurs routines.
bloc de données.
L’ensemble du programme occupe 82 lignes.
Ci dessous, le principe des différentes parties du programme:
10 – Nous définissons les matrices du jeu.
100 – Nous lisons le clavier: si aucune touche n’est enfoncée, elle passe à 170, mais le navire est supprimé de l’écran.
160 –Nous vérifions la position du navire. S’il y a autre chose que des espaces, passez à 600.
200 – Code déterminant quel ennemi nous devons nous déplacer: 0- Barrière énergétique, 1- Navires ennemis et 2- Fungaloids.
210 – Routine de mouvement de barrière d’énergie.
240 – Programme de déplacement d’un des trois navires.
270 – Programme de déplacement de l’un des six Fungaloids.
300 – Contrôle de notre tir.
400 – Commande de déclenchement fongoïde.
450 – Nous regardons les 3 personnages qui sont dans la position de notre vaisseau. S’ils ne correspondent pas au navire, cela signifie que nous sommes entrés en collision avec quelque chose et que nous sautons à la fin de la partie, sinon le système revient au début de la boucle.
600 – Fin de partie.
700 – Niveau de réussite.
800 – Divers programmes: charger des munitions (820), charger du carburant (850), montrer le score (880).
900 – Routine pour imprimer notre vaisseau dans la position correspondante.
2000 – Écran de présentation.
2500 – Nous dessinons l’aire de jeu.
2800 – Initialise les variables du jeu.
3000 – Nous chargeons les graphiques et initialisons certaines variables.
9000 – Données des positions verticales initiales des 6 fongoïdes.
Le jeu
Le jeu original a été publié en 1982 et fut programmé pour le ZX-81 étendu à 16K.
Le but du jeu est de détruire les Fungaloids avant qu’ils n’atteignent le haut de l’écran. Ces plantes poussent et produisent des spores qui nous détruisent si elles nous parviennent. Nous devons éviter d’entrer en collision avec eux ou avec les différents ennemis de la région.
Notre seul navire a une capacité limitée de carburant et de munitions et nous devons périodiquement faire le plein dans les zones correspondantes.
En détruisant tous les segments des Fungaloids, nous recevons 100 points, nous passons le niveau et la difficulté augmente.
Près de la base de certains Fungaloids, il y a des constructions. Si nous en détruisons un, nous perdons 20 points.
Le jeu se termine si nous perdons notre seule vie ou si nous perdons tous les points.
Contrôles : Q-A-O-P pour déplacer le navire et ESPACE pour tirer.
D’autres versions …
Fungaloids sur ZX-81, la version originale Fungaloids sur le MZ-700Et pour finir, sur le MSX
Je ne peux pas résister au plaisir de vous montrer les écrans que j’ai pu récupérer à partir du fichier TALISMAN_DEMO.WAV de Simon G. A ma connaissance il n’existe pas de fichier .TAP ou .DSK pour cette démo et je l’ai choisie pour illustrer la simplicité de la procédure de récupération des nombreux écrans Hires qu’elle contient. Cet article montre des recopies d’écran, mais vous trouverez tous ces écrans au format .tap dans le zip joint à cet article.
Prévu à l’origine pour être un cadeau de Noël, ce programme a connu un peu de retard à force de le peaufiner. Mais bon, il est maintenant disponible et vous le trouverez dans le zip accompagnant cet article, ainsi que sur mon site, à l’adresse http://andre.cheramy.net/telechargement/Programmes/choix.htm
C’est une sorte de bataille navale, mais dans le jeu
classique (en vigueur dans les cours de récréation et qui se joue sur une
grille papier), deux protagonistes
s’échangent des missiles pour couler les bateaux de l’adversaire et (cf. “touché”,
“en vue” et “dans l’eau”). Dans les équivalents numériques
le jeu est souvent réduit à un seul joueur contre l’ordinateur.
Dans Radar Oric, il n’y a aucun risque de recevoir des missiles sur vos bateaux, car vous n’avez pas de bateaux. C’est votre QG qui est attaqué par une flotte ennemie et pour vous défendre, vous disposez d’un tout nouveau radar couplé à un ordinateur dernier cri, l’ Oric. Votre tâche est de localiser exactement la position de tous les bateaux ennemis, puis de déclencher un feu apocalyptique qui les anéantira vite fait bien fait avant qu’ils aient eu de temps de dire ouf ! Oui, je sais les bateaux ne peuvent pas dire ouf, mais bon…
Le jeu proprement dit
Votre rade est représentée par une grille de 10×10 cases où les 10 bateaux de la flotte ennemie se sont faufilés, profitant d’un épais brouillard. Heureusement, il y a quelques trous dans ce brouillard, dans lesquels vous pouvez apercevoir des bouts de navires ou… de l’eau ! Mais c’est tout (voir la figure ci-dessous).
Pas facile de savoir où sont les bateaux ennemis !
Heureusement encore, votre super Radar Oric est capable de scanner cette grille
et de vous indiquer combien d’éléments de bateaux se trouvent dans chaque ligne
et dans chaque colonne (voir les chiffres rouges à gauche et sous la grille).
Heureusement encore, votre super Radar Oric est
capable de scanner cette grille, ligne par ligne et colonne par colonne, et de
vous indiquer combien d’éléments de bateaux s’y trouvent (voir les chiffres
rouges à gauche et sous la grille).
Un peu de réflexion vous permettra de déduire la
localisation exacte des 10 bateaux ennemis. Dernier petit service offert par
votre Radar Oric : il vous indiquera si vous vous êtes planté dans votre
raisonnement ou si les bateaux sont bien là où vous pensez.
Si c’est correct, il ne vous restera plus qu’à les anéantir
et l’ennemi n’aura même pas le temps de comprendre ce qui lui arrive. Le
résultat est garanti en un rien de temps !
Hélas, l’ennemi a la peau dure et il ne va pas tarder à vous
envoyer une nouvelle flotte. Sacrebleu, il va encore falloir se creuser les
méninges !
Mais tout est bien qui finit bien, il arrivera
inexorablement un moment où l’ennemi sera à court de bateaux et où aurez
définitivement gagné.
Chaque flotte ennemie est composée des 10 bateaux suivants
Un porte-avions (4 cases)
Deux croiseurs (3 cases)
Trois destroyers (2 cases)
Quatre Sous-marins (1 case)
Cet effectif vous est rappelé au-dessus de la grille et vous sera utile pour vous aider à trouver où peuvent se tenir les bateaux.
Les commandes disponibles
Les quatre flèches pour déplacer le curseur dans
la grille.
Les chiffres de 1 à 8 pour marquer la case au
curseur selon ce que vous pensez qu’elle contient.
La touche “R” pour recommencer la
grille au début, si vous êtes trop embrouillé.
La touche “S” pour sauvegarder la
partie en cours afin de la reprendre plus tard.
Correspondance entre les touches 1 à 8 et le marquage des cases
Case indéterminée
De l’eau
Corps de bateau
Sous-marins
Extrémité gauche d’un bateau
Extrémité droite d’un bateau
Extrémité basse d’un bateau
Extrémité haute d’un bateau
A tout moment, vous pourrez consulter le pense-bête, situé à
droite de la grille (chiffres bleus suivis d’une icône).
Enfin, le n° de la flotte qui vous attaque est visible juste au-dessus de ces chiffres (par exemple le
4 sur la figure ci-dessus indique que vous vous défendez contre la 4e
flotte ennemie).
Toutes les grilles du jeu ont bien sûr une solution et une seule.
