Logicielsmoto.com

Bonjour à tous,

J'ai écrit un outil de développement pour TO8 (mode bitmap 16) que je souhaite partager avec vous.
Il permet de gérer :
- la génération d'une image fd
- le boot en assembleur
- les animations de sprites en double buffering
- la génération de sprites compilés a partir de planches d'images
- la routine d'effacement de sprite
- la routine de positionnement de sprite par pas de 2 pixels
- l'organisation optimisée de sprites en page mémoire
- le chargement des données de sprites en page mémoire
- la conversion d'une image en données prête à l'affichage
- la génération de la palette de couleur

Il fonctionne en java et prend en entrée un fichier de config.
L'outil permet de faire un build a partir de votre code source assembleur en y intégrant des images compilées et des données d'animation.
Le résultat est une image de disquette fd et sd
Utilisé dans un IDE comme Eclipse, il permet de builder et de tester sous emulateur en un clic.

Vous trouverez en pièce jointe l'outil et une démo.
La démo montre un jeu de plateforme, mais il est possible d'implémenter n'importe quel style de jeu, l'outil à pour vocation d'être principalement un moteur d'animation.



Voici en exemple, le fichier de config de la demo livrée avec l'outil :


On y retrouve :
- Le fichier ASS qui contient le code de boot (BOOT.ASS)
- le fichier ASS qui contient le programme principal (MAIN.ASS)
- La balise qui permet de positionner la déclaration des données d'animation
- L'image de disquette générée
- l'image de fond a charger au démarrage du programme
- Les pages mémoires qui sont réservées à la génération des sprites compilés. A noter que les pages impaires (5, 7, ...) doivent être libres car utilisées dans le cadre du double buffering.
- les planches d'images: elles contiennent des images de tailles identiques organisées horizontalement. les colonnes "pagegroup" et "subgroup" ne sont pas utilisées pour le moment. Il faut indiquer le nombre d'images (pour la découpe). On peut demander un flip horizontal de l'image, ce qui évite de devoir faire des planches en double pour la symétrie. le tag ASM est celui qui sera intégré dans le code source, le tag est celui référencé dans le script d'animation.
Remarques: Pour chaque image les codes couleurs de palette sont affichées à l'écran, il faut choisir une de ces palettes et intégrer le code manuellemet dans le fichier MAIN.ASS
Les images doivent être au format PNG indexé 8bit, avec en position 0 la couleur transparente, puis les 16 couleurs utiles de 1 à 16.
- les scripts d'animation permettent de définir les images d'une animation, la durée de chaque image, si la durée de chaque image est proportionelle a la vitesse du sprite, l'enchainement des animations (branchement, retour, ...).
Dans votre code assembleur en fonction des mouvements de manette et de l'intelligene du jeu, un sprite pourra être amené a changer d'animation. il suffira d'appeller

Le moteur d'animation se chargera en permanence d'afficher la bonne image du sprite au bon moment.

Exemple : si vous souhaitez remplacer toutes les images de la démo par une seule, effectuez les changements suivants dans le fichier de config. Il n'y a aucune ligne de code assembleur a modifier, le personnage se déplace selon le même moteur physique, il n'y a qu'une image chargée en mémoire et sur la disquette.
Cela permet une grande latitude dans la conception en ajustant les animations en fonction des ressources mémoire, sans avoir a refaire tout le code. Evidement dans cet exemple c'est un peu extrême ;-)




L'outil est fonctionnel, mais il manque encore pas mal de choses. Les évolutions a venir sont :
- Une organisation des pages mémoires en "tableaux" ou "niveaux" de jeu, pour pouvoir changer le set de sprites et de fond d'ecran facilement
- Un moteur d'animation pour plusieurs sprites et non un seul !
- Une optimisation du générateur de sprite compilés actuel
- Le choix entre plusieurs méthodes pour la génération de sprite compilés, en particulier une version sans la gestion de l'effacement intégrée
- l'intégration des données de palette en automatique
- Correction du comptage des cycles et taille du code compilé en log

... La liste est longue, a vous de donner votre avis !
Si vous voulez participer au projet, n'hésitez pas.

Complément:
J'ai bien avancé sur une application indépendante qui permet de travailler sur un ensemble d'images, d'établir automatiquement une palette commune avec un nombre fixe et réduit de couleurs (en passant par le référentiel CIE Lab).
On peut ensuite enregistrer toutes les images réindexées en une fois. A suivre donc ... je pense que c'est interressant dans le cas d'adaptation de jeux existants.

Mode opératoire :
1. Installer OpenJDK 12 ou supérieur si ce n'est pas déjà fait (ex: https://jdk.java.net/14/)
Ajouter le chemin complet du répertoire bin du jdk dans le PATH
2. Ajouter c6809.exe dans le répertoire racine de l'outil (dans le même répertoire que config.properties)
3. Pour lancer le build, utiliser la ligne de commande suivante dans le répertoire racine de l'outil
java.exe -classpath ".\bin" fr.bento8.to8.build.BuildDisk config.properties
Si vous n'avez pas d'erreur, vous trouverez l'image de disquette dans le répertoire output

Pour lancer la démo, appuyer sur B !

Je n'ai jamais pris la peine de remercier tous les contributeurs des différents forum, alors je prend le temps de le faire :
Un grand merci à vous tous pour tous les conseils et le code que vous publiez sans relache depuis tant d'années !
Sans vous j'en serai resté au basic ... il y a 30 ans.

PS : Le moteur d'animation et la gestion du personnage de la demo ont été insiprés du code asm de Sonic.
http://info.sonicretro.org/Disassemblies
http://info.sonicretro.org/Sonic_Physics_Guide

PS : si vous voulez discuter en particulier du générateur de sprites compilés, un fil est déjà ouvert ici http://www.logicielsmoto.com/phpBB/viewtopic.php?f=3&t=619

(Update 18/09/2021) Dernière version du projet :
https://github.com/wide-dot/thomson-to8-game-engine

Archive obsolète :

Mouais mais ça reste du PC'developpement

Moi je trouve ca très intéressant. Les évolutions à venir (multi-sprites) sont très prometteuses. Il faudrait voir comment faire en sorte que, par exemple, le moteur soit intégrable avec du Pascal-Base pour faciliter le travail de Neotenien.

Avoir un jeu de plateau totalement fini avec ce moteur serait aussi un grand plus.

_________________
Good morning, that's a nice Tnetennba

Bien sûr que c'est intéressant, je ne dis pas le contraire. Mais avec tous ces outils on perd un peu le côté "artisanal" d'antan. C'est ce que je voulais dire

Oui, mais si c'est pour faire les jeux aussi poussifs qu'avant, ca vaut le coup de passer sur du "plus moderne" au niveau développement.

D'ailleurs, c'est un autre sujet, mais j'ai en tête une conversion (bytecode) java "simple" -> binaire 6809 qui me plairait bien d'experimenter. C'est l'étape suivante par rapport aux optims de pascal-base.

sam (développer pour Thomson depuis Eclipse ? )

_________________
Good morning, that's a nice Tnetennba

Je me souviens très bien dans les années 90 (sur TO8) avoir recopié via du calque une carte du monde sur papier millimétré ...
ensuite il fallait rentrer les pixels un à un avec les touches de direction et la barre d'espace dans le logiciel de dessin.

Puis attendre 8 heures que mon programme en basic trace une sphère à partir de la carte du monde sur une dizaine d'images.
elles étaient ensuite animées ... pour faire tourner la Terre à l'écran ;-)

Tu as raison, c'est mon meilleur souvenir de programmation !
Plus l'effort est grand, plus la satisfaction est grande.

Le problème c'est que j'aimerai bien réaliser un jeu jusqu'au bout, et je n'y suis jamais arrivé.
Je pense que je sous-estime le temps de réalisation à chaque fois, d'ou l'idée de s'outiller un peu pour partir du bon pied.

Voici une petite vidéo avec les images de bubble bobble paramétrées pour l'outil.
On y voit un bug du générateur de sprite ;-) va falloir que je corrige ça.



Pourquoi pas bosser sur un jeu, ça permet aussi de se restreindre aux fonctionnalités importantes à implémenter.
Par contre je ne connais absolument rien au Pascal Base.
Je préfère rester focalisé sur l'assembleur (que je ne pratique que depuis un an) et sur lequel il me reste beaucoup à apprendre encore.
Donc à voir si qq chose peut être réalisé, tout dépend de l'architecture, l'outil de build pourrait intégrer plusieurs bouts de binaires peu importe leur provenance. il faut trouver comment orchestrer tout ça (si Neotenien est interessé). ça risque d'être quand même compliqué si la compilation pascal est réalisée hors d'un environnement pc ... bref bcp d'interrogations.

D'ailleurs j'ai une question :
J'ai remarqué que lorsque j'utilise le bootloader pour démarrer en 6200, j'avais un comportement différent entre le lancement par B ou par C.
Peut-être un montage différent des pages en mémoire au moment ou on récupère la main ?

Excellent ! Tiens moi informé ;-)

Quand on boot par C, il bascule en "compatibilité TO7/70" et la commutation mémoire doit se faire via le PIA (comme sur TO9 et TO7/70). Il faut alors modifier le registre système pour restaurer la commutation de bank rapide comme sur TO8. D'ailleurs dans le BootLoader fait par Préhisto pour la démo "In the Shadow of the thomson", il y a ceci:
Je pense que tu peux t'en inspirer.

_________________
Good morning, that's a nice Tnetennba

Merci !

D'ailleurs le seul endroit ou j'avais trouvé le source d'un bootloader c'était dans l'archive de TO-ale.
Donc double remerciement.

Cette fonctionnalité de boot elle est documentée officiellement quelque part ?
Ou c'est quelque chose qui a été découvert (il y a longtemps j'imagine). Sait-on qui l'a découvert ?

En fait Il y a 2 sortes de bootLoader. Un qui n'est détecté que par le Basic1 (et que je pense avoir trouvé dans la litterature de l'époque), et un autre qui est aussi détecté par le Basic2 et que je pense avoir trouvé dans les différents forums qui ont existés (et disparus pour certains).

Un bonne source d'info est le site de Gislain Fournier: http://collection.thomson.free.fr/site/edito/page.php

Avec en particulier un paragraphe sur la copie rapide de zones mémoires: http://collection.thomson.free.fr/code/ ... XI=0&XJ=12

_________________
Good morning, that's a nice Tnetennba

Un petit mot pour vous dire que la V2 est en préparation depuis septembre.
Il me reste beaucoup de code à produire mais la phase de conception est terminée (bcp de diagrammes ;-)).
Encore deux mois de code au moins !

Au programme :
- Chargement des ressources d'un niveau de jeu (sprites et leur code associé)
- Utilisation du nouveau générateur de sprite compilé (voir fil Sprites en BM16)
- La sauvegarde des données de fond de sprite se fait par une routine d'allocation/désallocation mémoire
- Gestion des priorités d'affichage de sprite (8 plans distincts dont un overlay)
- Moteur d'animation
- Gestions d'un pool dynamique de 64 objets/sprites (il y en aura peut être moins, ce sera fonction de la place mémoire une fois tout le moteur codé)
- Automatisme permettant de ne pas rafraichir (effacement+dessin) un sprite si celui-ci n'en a pas besoin (immobile, pas de changement d'image, pas de changement de priorité, ...)
=> ce dernier point est assez complexe, surtout avec le double buffering, car on doit vérifier qu'un sprite non rafraichi n'est pas en collision avec un autre qui passe en dessous.
mais je pense avoir un algo et une organisation des données qui devrait ne pas trop être pénalisant.

Dans cette version évidement le but est de pouvoir instancier n sprites d'un même type sans dupliquer son code.
J'ai décidé de me caler au plus près du moteur de Sonic2 (megadrive).
Certaines routines sont des traductions du 68000 en 6809.
Evidement tout ce qui touche au VDP est remplacé par du code spécifique ...

Au final ce qui restera a développer pour faire un jeu, c'est le code des objets/sprites.
(On ne parle pas encore des tiles en fond, ce sera en V3)

Un avant gout de ce qui devrait être réalisable en pj :
Le code d'intro de Sonic2 traduit en 6809 et compatible avec le futur moteur de jeu v2 ... (premier jet, hein ça fonctionne pas encore ;-)


A suivre ...

Voici les diagrammes de conception pour ceux que ça intéresse (il y a plusieurs onglets).
Format: drawio (logiciel gratuit en ligne ou en appli desktop)

Wow! ça sera en genre de gameMaker pour Thomson ?

_________________

Ce ne sera certainement pas aussi poussé, mais c'est dans l'esprit.

Une petite vidéo qui illustre l'avancement ...
MD à gauche / TO8 à droite




Le moteur de jeu gère maintenant l'affichage des sprites compilés avec effacement.
C'est à dire que les données de fond de chaque sprite sont enregistrées dans un buffer avec un système d'allocation/désallocation de blocs mémoire (en page 0).

Le refresh (effacement/affichage) des sprites n'est déclenché que si le sprite se déplace ou change d'image.
S'il est rafraichi, il provoque aussi le rafraichissement des sprites en collision se trouvant au dessus de lui.
On économise ainsi pas mal de cycles par rapport à un rafraichissement systématique lors de chaque frame.

Dans cette intro, lorsque Sonic ou Tails monte, j'ai conservé la temporisation d'origine (un déplacement tt les 4 frames).
Avec le double buffering on a donc deux frames pour la gestion de l'effacement/affichage du sprite (env 15000-18000 cycles y compris le moteur de jeu)
Suivi de deux frames ou l'on ne fait rien ;-) de quoi laisser de la place pour gérer le masquage par l'emblème qui manque encore dans cette intro.

De même quand le bras de Sonic ou Tails bouge par dessus le personnage, celui-ci n'est pas réactualisé.

A la toute fin la petite étoile passe derrière les personnages, là on a des frame drop ...
derrière sonic cela provoque un refresh des 4 sprites, puis quand elle passe sous Tails, Sonic et son bras ne sont plus rafraichis.

Les priorités :
FRONT
large star p2
Sonic hand p3, Tails hand p3
Sonic p4, Tails p4
small star p5
BACK

en pj le fichier .sd si vous voulez le faire tourner sur un vrai TO8 ou sur émulateur.
Sur mon TO8 ça m'a fait "quelque chose" de voir ces gros sprites s'animer aussi vite ...

La suite :
Je dois implémenter un autre générateur de sprite compilé sans la gestion de l'effacement du fond.
Cela permettra de gérer les sprites de type overlay qui ne se déplacent pas et ne changent pas d'image.
Un peu de boulot en perspective.
Après je termine l'intro en ajoutant l'emblème, le fond ...
et je passe a la réalisation d'un premier niveau de jeu avec gestion d'une tilemap + collision associée et ajout d'un personnage jouable.
Pas de scrolling évidement, mais le fond changera quand le perso sort de l'écran

bcp de travail à l'horizon, mais des premiers résultats encourageants !!!
ça m'aide bcp d'avoir le code source commenté de Sonic, je ne pensais pas pouvoir adapter le code des objets (ici l'écran d'intro) aussi facilement.
Pour les graphismes j'ai été "obligé" de réaliser un petit programme java pour reconstruire des png à partir de la rom d'origine (des fichiers décompilés plus précisément).
En effet les planches de sprites que l'on trouve ne portent pas les informations de mapping, en particulier en ce qui concerne le centrage des images.

Je publierai tt à l'heure le projet complet "en l'état".