6502man a écrit :Je voudrais bien trouver un mode bitmap sans contraintes de proximités dans l'idéal ca serait du 320X200 en 8/16 couleurs mais d'après la DOC du TO8 on est restreint à 4 couleurs prédéterminées en comptant le noir et le blanc il reste que 2 couleurs !!!!
Non les 4 couleurs sont libres parmi les 4096. En fait, c'est un mode assez riche.
Après il faut savoir l'usage du mode GFX. Si c'est pour afficher une image statique les contraintes 8x1 ne sont pas si gênantes que cela (voir mes nombreuses images sur:
http://www.logicielsmoto.com/phpBB/viewtopic.php?t=383). Si c'est une image avec des sprites qui bougent, la contrainte 8x1 peut éventuellement gêner, mais cela dépend de l'ampleur des mouvements. Si les sprites se déplacent de blocs 8x8 en blocs 8x8 il n'y aura pas trop de soucis, si c'est un déplacement au pixel près horizontalement, alors oui ca coincera.
Ce qui guidera la contrainte du mode gfx est certainement la génération de machine visée. Si c'est du TO7/MO5 alors pas le choix il faut faire avec les contraintes 8x1. Si on veut faire des déplacement de sprites au pixel près, il faut dans ce cas restreindre le playfield à 2 couleurs comme dans Sortilège.
Si on colle les sprites à des multiples de 8 horizontalement, alors aucun soucis (pulsar, coliseum, etc)
.
Si tu veux taper dans les machines de dernière génération, il y a le mode BM16 (160x200) en 16 couls parmi 4096 sans contraintes de proximité. Le grain est moins fin, le dither pas terrible (mais tout le monde n'aiment pas le dither (jester?)), mais l'utilisation de deux bank mémoire pour les groupes de pixels rend la programmation de routines de sprites absolument affreuse.
Pour l'affichage des fichiers MAP sur les machines dont le basic ne possède pas l'instruction, il existe un routine de préhisto ici:
http://ct.ghislain.fr/code/articles/pre ... XI=0&XJ=13
Pour se faire une idée de ce que donne une image "sans contraintes", le plus rapide est de prendre un outil de dessin type PSP, de réduire l'image à 320x200 (ou 160x200) et réduire le nombre de couleurs à 4 (pour 320x200) ou 16 (pour 160x200). Ca donne un avant-goût. Cela dit, les couleurs ne seront pas fidèles sur un thomson parce que la palette est très largement non linéaire. En gros sur thomson il est impossible d'avoir un gris très sombre. Il est tout de suite trop clair. Pour que ca marche parfaitement, il faut tenir compte du gamma thomson avant et après la réduction de couleurs (schematiquement: couleur^(1/3) avant la réduction de couleurs, puis couleurs^3 à la sortie). Perso j'ai tenu compte de tout cela dans mes scripts de conversion d'images utilisés pour la collection des
TruCxx
Si on a des contraintes de proximité, alors il faut passer par des algos non connus par les outils standard. Perso je me suis fait des scripts perl qui implémente un algo en perpétuel évolution permettant de donner des résultats pas mauvais (voir
Elvisives).
Si tu veux que je te fasse des tests, passe moi un petit MP (mes scripts ne sont hélas pas exploitable par un tiers, tellement c'est le bazar dans les trucs en évo permanente). Mais un jour je vais coder l'algo en C et le mettre dans mon
visualiseur pour XnView).
Allez pour se faire plaisir, voici quelques images affichables sur un MO5/TO7 "de base".
[edit] retiré le msg pour Daniel.
System.cfg
