question graphique sur TO9 et compagnie

[nouvelhermes]

J'avais déjà posé des questions graphiques et je remercie ceux qui ont pris le temps de me répondre.

Je sais que sur TO9 (et suivants) il existe plusieurs modes graphiques dont le 300x200 16 couleurs avec clash, et le 160x200 16 couleurs sans clash./

Mais est-il possible de combiner ces deux modes, par exemple les vingt premieres lignes en 160x200 sans clash (pour avoir de belles illustrations), et les cinq dernières en 320x200 avec clash (pour avoir du texte lisible) ?

Je me posais la question surtout concernant les jeux d'aventures textuels avec illustrations, courant à l'époque du TO9.

[Fool-DupleX]

Oui, moyennant un peu de gymnastique. Cet effet est présenté dans la Mégadémo d'HCL :



Ou 4 modes apparaissent simultanément : 320x200 avec clash, 620x200 en 2 couleurs, 320x200 en 4 couleurs et 160x200 en 16 couleurs.

Mais ça suppose de synchroniser le changement de mode, donc il faut un bout de logiciel qui est appelé à intervalle parfaitement régulier, par exemple avec l'interruption IRQ et un 6846 correctement programmé.

[__sam__]

Oui, mais attention avec l'IRQ timer: les latences en ROM sont variables (la pire étant celle du TO9 je crois), et l'IRQ n'intervient qu'au début de l'instruction suivante, donc si elle apparait dans une instruction longue (adresse complexe LDX [$AAAA,Y], ou plusieurs accès mémoire comme les PSHU/S PULU/S), il peut y avoir un retard d'une dizaine de µs + la latence en ROM pour retrouver la source de l'IRQ, ce qui peut être un problème.

En outre on a vu sur le forum il y a quelques années, que le TIMER d'origine est parfois émulé dans un gate array, et que l'émulation est incorrecte: l'interruption ne se produit pas à la valeur -1 du compteur, mais à la valeur 0. Au final l'usage du timer est à la fois imprécis et super couteux en temps CPU (une ligne = 64µs; la latence en ROM en mange déjà la moitié au moins avant d'atteindre le code de l'utilisateur).

Les démos rechignent à utiliser le timer pour ces raisons. Elles préfèrent désactiver les interruptions et compter les cycles dans tous les chemins d'execution. C'est laborieux à coder, mais c'est le plus fidèle. Bref: le changement de mode à la volée à base d'interruptions raster pilotées par le timer n'est pas exploitable en pratique à mon sens.

[Fool-DupleX]

Je suis d'accord. D'ailleurs, si on consulte le code source de la Mégademo HCL, le code ne fait pas appel aux interruptions, bien au contraire, il les masque. Il compte scrupuleusement les cycles.

Je trouve malgré tout l'idée bonne de vouloir mixer deux modes écran. Pour un jeu d'aventure, ça a effectivement du sens. Mais sacré gymnastique en perspective.