	INDEXS DE COULEUR VDI ou XBIOS


	La couleur 3 du VDI n'est pas la couleur 3 du XBIOS... C'est
dommage, mais c'est ainsi depuis les dbuts du ST! Les programmeurs s'y
sont fait et ont fini par accepter la chose avec philosophie.
	Mais, maintenant que dbarquent les cartes graphiques, y-a-t-il de
nouvelles diffrences? La rponse est NON! Par bonheur, l'ordre hardware
des registres sur une carte est l'ordre XBIOS, et l'ordre VDI d'une carte
est l'ordre VDI normal...
	Tout ceci se rsume donc  une conversion XBIOS/VDI.

L'ordre XBIOS
-------------
	Il correspond aux valeurs physiquement crites en RAM cran et 
l'ordre physique des registres de couleur.

L'ordre VDI
-----------
	Il correspond  un ordre virtuel choisi pour diffrentes raisons
mais dans lequel on a la chance de toujours avoir du noir et du blanc aux
registres 1 et 0 quelque soit le nombre de couleurs de la rsolution
courante.

En bref...
----------

	Il faut donc comprendre que si avec la VDI j'affiche un pixel de
couleur 8, je n'aurai pas forcment crit 8 en RAM cran, et que si je
modifie le registre VDI-8 de couleur je n'aurai pas modifi le registre
XBIOS-8 de couleur.

	On pourrait se dire: il suffit de faire du 100% VDI ou du 100%
XBIOS. Certes, mais les choses marchent rarement comme on le voudrait...

L'utilit par l'exemple
-----------------------

	Dans certains cas, une programmation XBIOS vous est impose:
	- les palettes des images Degas ou NEO ne sont pas VDI!
	- NVDI, lors d'un changement de rsolution et du nombre de
	couleurs, ne donne plus accs  la fonction vs_color

	Dans d'autres cas, c'est le format VDI qui s'impose:
	- Les images IMG contiennent une palette au format VDI.
	- certains drivers de cartes graphiques ne prennent pas la peine
	d'muler les appels XBIOS (la Matrix 256 par exemple...).

	Ces quelques exemples montrent qu'on est parfois contraint de
passer d'un monde  l'autre, et donc de connaitre les tables de
conversion.

Tables de conversion
--------------------

	en 16 couleurs
	- - - - - - - -

	XBIOS	VDI
	0	0
	1	2
	2	3
	3	6
	4	4
	5	7
	6	5
	7	8
	8	9
	9	10
	10	11
	11	14
	12	12
	13	15
	14	13
	15	1


	en 256 couleurs
	- - - - - - - -
	XBIOS	VDI
	0	0
	1	2
	2	3
	3	6
	4	4
	5	7
	6	5
	7	8
	8	9
	9	10
	10	11
	11	14
	12	12
	13	15
	14	13
	15	255
	(de 16  254, pas de changement)
	16	16
	...	...
	254	254
	255	1

	Un exemple: si en RAM cran, mon pixel a l'index numro 5, je peux
en fixer la couleur soit par les fonctions XBIOS en prenant 5 comme index,
soit par les fonctions VDI en prenant 7 comme index.
	Rciproquement: si j'ai fix, avec un appel VDI, la couleur 6 sur
du rouge, je peux alors afficher du rouge avec un appel VDI et l'index 6
ou en crivant directement en RAM cran la valeur 3.


Validit des tables
-------------------

	En 16 couleurs:
		- cran Atari (ST/TT/Falcon)
		- Nova

	En 256 couleurs:
		- cran Atari (TT/Falcon)
		- NOVA
		- Cyrel
		- Matrix
		- Crazy Dots 1 & 2
		- cran HADES

	J'ai limit ma liste aux machines et aux cartes dont j'tais
certain, par contre, je n'ai jamais vu une carte n'acceptant pas ces
tables: elles semblent donc tre universelles sur nos machines  base de
TOS.
	Dieter Fiebelkorn (Gemview) quant  lui, utilise une mthode
universelle au lancement de ses programmes lorsqu'il se trouve en 16 ou
256 couleurs:
	il crit en (0,0) un pixel avec v_pmarker (appel VDI 7) puis le
relit avec v_get_pixel (appel VDI 105). Cette deuxime fonction renvoit
dans intout[0] l'index hardware XBIOS et dans intout[1] l'index VDI!
	Ainsi, en parcourant toute la palette, il obtient sa table de
conversion.

	Cette mthode semble imparable, mais reste  la merci d'un driver
de carte incomplet pour lequel v_get_pixel serait bugg! Je fais moi mme
la triste exprience de ce genre de drivers puisque sur ma carte NOVA
l'appel VDI 103 v_contourfill ne fonctionne pas! Sous D2M par exemple,
impossible de remplir une surface...


Conclusion
----------

	Colorez bien, faites attention aux programmes dtournant les
fonctions couleurs comme NVDI ou les drivers de carte: sont-ils bien
complets? Doit-on plutot utiliser XBIOS ou VDI? Faites vos tests et
choisissez la meilleure solution,

	Guillaume Tello
	gtello@wanadoo.fr