Fool-DupleX a écrit:
Ce qui me fait penser à tout autre chose, est-ce que le mode 160x200x16 est le seul mode géré par le framework, ou bien toutes ces magnifiques fonctionnalités sont aussi disponibles pour les autres modes ? Et sur quelles machines ? Je pense justement à mon cher MO5 qui n'a que le mode 320x200x16 avec contrainte.
Pour le moment le moteur ne gère que le mode 160x200x16.
Mais il est tout à fait possible d'étendre ses fonctionnalités pour exploiter d'autres modes graphique.
Pour ça il faut :
- créer une variante du générateur de sprites compilés (environ 1 à 2 mois)
- créer des variantes de certaines routines asm (ce qui touche au positionnement écran) => qq jours, c'est la partie rapide a faire.
La où il y a plus d'impacts c'est que le plan d'adressage doit être différent (je n'ai jamais regardé d'autres machines que le TO8.
Or sur TO8 j'utilise à peu près tout ce que j'ai sous la main en même temps:
$0000-$3FFF page RAM/ROM (exécution du code des objets/sprites compilés)
$4000-$5FFF demi-page 0 (données de sauvegarde du fond écran avant ecriture des sprites, une demi page pour la page 2 une autre pour la page 3)
$6100-$9FFF page 1 (programme principal)
$A000-$DFFF page RAM (page 2 et page 3 pour permettre l'écriture des données vidéo en double buffering)
Bien sur on pourrait conserver un certain nombre de routines du moteur de jeu, mais il faudrait revoir l'organisation des données en mémoire ainsi que la partie de chargement des données, cette partie touche au générateur écrit en java qui organise les données en mémoire, construit les index des données et produit l'image disque. C'est un code assez conséquent et très spaghetti.
Pour le moment ce n'est pas géré et ce n'est pas prévu dans un avenir proche.
Mais si d'aventure je venais à réécrire (ou fx ?) le générateur Java (que j'appelle builder) pour avoir quelque chose de plus propre, ça pourrait être pris en compte.
Du coup merci pour la question !