	Les secrets de M_Player et d'Aniplay
	************************************


Guillaume :



	Alors Didier, pourquoi le choix d'un player AVI/MOV et non pas un
travail comme Lexicor qui a invent un format d'animation pour Atari avec
compresseur et player?



Didier :



	Bonne question ! Avant tout les fichiers QuickTime sont trs
frquents sur les CD, les fichiers AVI le sont moins. Et c'est la vue de
ces fichiers sur PC, et le rsultat passable du premier player AVI puis
MOV sur Atari (le programme en C de Dieter Fiebelkorn qui a eu le mrite
d'tre le premier) qui m'a donn envie de mettre au travail. Mon but tait
de faire un player sous GEM rapide (en assembleur 68K et DSP) afin de
montrer que l'on peut obtenir un rsultat similaire sur un Atari (en
l'occurrence un FALCON !). Et il faut bien donner  manger  son oiseau a
vocation multimdia !

	J'ai rien contre les formats d'animations sur Atari mais j'avoue
ne m'y tre jamais intress (il faut dire que je passe 99% de mon temps
micro  faire de la programmation !). Avant j'avais manipul des formats
d'images comme le (X)IMG et le GEM (a a donn PICDESK) et le son
AVR/WAV/AIF/DVSM (a a donn SONDIGIT). Je suis donc parti de presque
rien, si ce n'est que je connais la vido puisque mon pre tait dpanneur
TV.

	Et toi Guillaume, pourquoi tre parti d'un player de fichiers
Quick-Time et ensuite avoir volu vers un maximum de fichiers
d'animations sur Atari et autres ?



Guillaume :



	Je crois que c'est uniquement pour l'attrait de ce qui est cach.
Trouver un nouveau format d'animation m'occupe l'esprit jusqu' ce que je
le dcode compltement. D'ailleurs, sur certains CD, j'ai t bien surpris
de la qualit de fichiers SEQ raliss il y a dix ans dj. Pour certains
formats, je n'avais aucune information, mme pas un player qui tourne sur
le TT... C'est un casse tte prenant!



Didier :



Et pourquoi ton player n'est il pas sous GEM (mis a part les dialogues) ?



Guillaume :



	Mon Player n'est pas sous GEM... C'est un choix qui s'est impos 
moi ds le dbut: il m'a sembl indispensable de rserver un maximum de
puissance au service de la qualit du rendu. Pas d'accs aux vnements,
pas de gestion de la souris, mise en premier plan de mon application sous
multitche, passage en True color lorsque cela est possible.

	Je remarque d'ailleurs que ton player dispose d'une option 'sans
interface GEM', quelle en est la raison ?



Didier :



	Au dbut mon player fonctionnait uniquement sous GEM, mais je suis
(comme toi) un fou de vitesse, j'ai donc ajoute le choix sans GEM (avec un
changement de rsolution possible en 320 * 240 True Color sur FALCON si
l'animation dpasse pas la taille de l'cran).

	En fait c'est pas tellement au niveau des accs GEM que l'on perd
du temps (un evnt_multi), c'est surtout le fait de devoir utiliser une
rsolution vido plus leve (par exemple du 640 x 400 True Color), car le
Videl ralentit considrablement la machine par ses accs  la RAM. C'est
vrai que j'ai voulu donner  un Atariste la mme 'Vision' que sur MAC ou
PC en dmontrant que cela tait possible.
	Si l'on enlve l'affichage direct il est mme possible d'afficher
une animation en arrire-plan (il vaux mieux disposer d'un HADES ou d'un
FALCON avec une AFTERBURNER !). Avec l'option sans interface GEM sur
FALCON et TT, le clavier est gr directement (tampon clavier), et les
seuls appels systmes une fois l'animation lance sont donc les fonctions
du DOS pour lire un fichier. Sur les autres machines je lis le clavier
avec une fonction du BIOS (c'est plus rapide que la fonction evnt_muli du
GEM).

	Cela dit, voir un film AVI/QuickTime sous GEM avec MAGIC (par
exemple) est impressionnant ! Au final c'est  l'utilisateur de choisir en
fonction de ses besoins (pour ma part j'utilise beaucoup l'affichage sans
GEM en "plein ecran").



Guillaume :


	Pour ce qui est du True Color, avec une carte graphique le problme du
ralentissement Videl ne se pose pas: sur un TT ou un Hads c'est donc le
mailleur choix.
	J'aimerai galement reprendre un peu ce que tu disais : j'ai eu le
mme sentiment que toi en voyant de la vido sur un PC. Par contre, est-ce
qu'on ne risque pas de tuer un peu notre crativit en se focalisant sur
ce que peut faire un PC? Un peu comme si tout Atariste avait  se
justifier du choix de sa machine,  prouver qu'elle peut faire autant ? Ne
peut-on pas se contenter de faire simplement "autrement" plutt qu'aussi
bien ?




Didier:



	Je pense qu'il faut continuer  proposer quelque chose d'autre,
mais galement regarder ce qui se fait ailleurs pour viter de s'isoler
(c'est le cas d'Aniplayer).

	Pour Sondigit par exemple j'utilise des formats d'chantillons
ATARI (AVR/DVSM), mais galement PC (WAV), et MAC (AIF).

	Pour Aniplayer c'est un but que je m'tais fix au dpart, il est
possible galement que j'ajoute le MPEG par la suite, comme je l'ai fait
avec le FLI.


Guillaume:



	Remarque, depuis que j'ai intgr le MOV-Maker et le AVI-Maker,
c'est un peu un retournement de situation puisqu'on fait jouer  un PC
sous Windows des animations cres par un Atari.



Didier:



	Quelle est ta mthode d'affichage en 256 couleurs ? (j'ai pas vu
le rsultat car sur mon FALCON ton player passe en True Color). Moi je
laisse le choix  l'utilisateur de tramer ou pas les animations de plus de
256 couleurs (avec l'option qualit, le problme du tramage c'est qu'il
ralentit fortement l'animation, moins avec le DSP).



Guillaume:



	En 256 couleurs, je fais systmatiquement du niveau de gris ds
que l'animation comporte plus de 256 couleurs (32768, ou TC). Ceci vite
en effet le tramage et permet de gagner du temps. J'ai une table de
conversion 15 bits vers index de gris et ceci me permet d'crire
directement en mmoire cran sans me soucier de la position du pixel : en
effet, beaucoup de mthodes de tramage dpendent de x et y (par cycle de
4 ou 8).

	Il faut dire galement que peu nombreux sont ceux qui utilisent ce
mode avec M_Player : les TT sans carte (2 utilisateurs), les cartes
n'ayant pas de mode 32768c (4 ou 5 utilisateurs). Pour tous les autres
(bonne carte ou Falcon), on travaille directement en Near TC. Ainsi, je
n'ai pas t pouss  me pencher sur la question. D'autant plus que
dernirement je viens d'ajouter le support du mode 65536 couleurs sur
carte graphique ce qui rduit encore les utilisateurs de 256 couleurs.

	On voit d'ailleurs dans nos choix respectifs que nous sommes trs
influencs par la machine sur laquelle on dveloppe.

	Pour le clavier, je me suis contente de fonctions sur les touches
SHIFT/ALT ou Control, ce qui permet d'viter l'appel au BIOS tant donne
qu'une adresse existe pour ces touches particulires.

	Saurais tu me donner une ide du ralentissement cause par le tramage ?



Didier:



	Moi en 256 couleurs sans tramage je propose galement l'affichage
en 256 couleurs en niveaux de gris (bascule avec la touche 'C') pour les
animations en True Color, sinon l'affichage se fait en couleurs avec 6
niveaux par couleurs ce qui donne en RVB 6^3 soit 216 couleurs utilises,
dans ce cas cela laisse ventuellement libre les 16 premires couleurs
pour le GEM. En 16 couleurs le tramage utilise les 8 premires couleurs du
VDI (palette systme par dfaut). Le problme avec le tramage en 256 couleurs,
mme si l'on utilise une mthode rapide, est qu'il faut utiliser un sous-programme
pour limiter la taille du code gnr (ce qui ralentit normment l'affichage)
qui tient compte de la position X,Y des points et de la couleur sur 15 ou 24
bits soit 32K ou 16M), l'optimisation n'est donc plus possible (criture
rapide dans la ram video). L'option est bien sr utile et agrable pour
des animations de petites dimensions ou sur une machine rapide (HADES ?).



Guillaume :



	Question affichage, j'ai souvent entendu dire que ANIPLAY donnait
une image plus fine que M_Player, c'est quoi ton truc ?



Didier :



	Pour la qualit des animations d'Aniplayer cela vient je pense du
fait que je n'utilise pas toujours une table prcalcule pour les
animations en Cinepak (16 millions de couleurs) pour un affichage en 16 ou
15 bits (True Color FALCON ou carte NOVA sur TT par exemple). Avec ce
format c'est possible d'viter le prcalcul des couleurs afin d'amliorer
la qualit en travaillant effectivement sur du 16 millions de couleurs
(surtout avec le DSP). J'ai malgr tout ajout une option qualit pour
travailler avec une tableau de couleurs prcalcul car tout le monde n'a
pas de DSP et a permet de gagner jusqu' 10% en vitesse sur du Cinepak
(les autres formats n'en parlons pas, avec du YUV (Intel Raw) ou de l'IV32
(Intel Indeo) on est oblig d'utiliser un tableau prcalcul pour gagner
de temps (au moins 50%).


	Pour l'affichage en 256 couleurs, il faut reconnatre que sur
FALCON et TT BASSE nous ne sommes pas gts avec les 8 plans de couleurs
(les animations AVI/MOV en 256 couleurs sont par octets et non en plans
comme sur ATARI...). Utilises-tu une mthode particulire pour les TTistes
n'ayant pas de carte graphique ? Es-ce la mthode dcrite dans tes
articles ? Avec ces formats c'est une perte de temps inutile...



Guillaume :



	En effet, les 8 plans ralentissent normment le travail... J'ai
utilis au dpart la routine dcrite dans mon article. Ensuite, j'ai
travaill  une routine trs longue contenant 256 sous-programmes allumant
exactement les bits ncessaires pour chaque valeur d'octet rencontre. Elle
tournait dj  160% de ce que j'obtenais avant. Ensuite, Douglas Little
m'a fourni un code magnifique dont la vitesse est surprenante. Il s'tait
inspir de routines Amiga. J'ai ensuite adapt son travail pour le 16
couleurs (MP_STE) ainsi que pour les conversions inverses (par exemple du
FLM en 8 plans vers la carte NOVA en octets). D'ailleurs, toi qui l'a
galement expriment, que penses-tu du dsassemblage ? ;-))



Didier:



	Effectivement cette routine est plus rapide car elle traite de
faon simultane les plans alors qu'une routine traditionnelle travaille
avec des dcalages successifs plan par plan et bit par bit... Malgr tout,
il est prfrable de travailler en (Near) True Color, c'est plus rapide et
en plus la qualit est meilleure.


Guillaume :


	Ta remarque sur la qualit du Near True Color montre la ncessit
d'un changement de rsolution sur Falcon (car le bureau est souvent en 16
ou 256 couleurs) et donc l'impossibilit d'utiliser le GEM.


Didier:


	Pour parler d'autre chose, au sujet du son, quelle est ta mthode
pour restituer les frquences d'chantillonnage (souvent multiple des
44KHz), vers les frquences de nos machines ? Moi au dpart j'effectuait
une interpellation linaire avec le 680xx (le DSP tant dj utilis pour
dcompresser les images) activable par option, mais cette routine bien que
rapide prenait trop de temps au dtriment du reste (le dcompression des
images). J'ai donc fait un test autour des frquences ST(E)/TT et FALCON
et si elle est dans une plage de 7/8eme ou 9/8eme je retire ou j'ajoute un
chantillon.


Guillaume:


	J'utilise cette mthode depuis le dbut, car pour mes premiers
tests je ne voulais pas me creuser la tte: avec un fichier original 
11025 Hz, en passant de 8  9 chantillons (en rptant le 8me) a donne
le mme son mais  11025*9/8=12403 Hz, ce qui est trs proche du 12517 Hz
du son DMA.
	De mme, passer de 8  7 (en enlevant le 8me), permet de rejouer
le son  11025*7/8=9647 Hz qui correspond  la frquence que j'ai choisie
pour rejouer un son sur le Yamaha avec un STF. J'utilise encore une
mthode similaire pour les 19200Hz de la carte P-Sound sur Hades.

	Je pense qu'un spcialiste du son nous dirait qu'une rptition
d'un octet sur 9 entrane un bruit parasite (cassure de la courbe)  la
frquence 12517/9=1391 Hz  mi-chemin entre un Mi et un Fa. Mais, avant de
critiquer la restitution sur Atari, je crois qu'il faut couter ce que a
donne sur un PC : certains fichiers Quick-Time  11025 Hz sont ignobles !
Alors, ce n'est pas notre choix commun d'une routine rapide qui est en
cause, mais bien le fichier de dpart.


Didier :



	C'est vrai que l'on ne trouve pas beaucoup d'chantillons 16 bits
et que les chantillons 8 bits de certains fichiers ont soit pas assez
d'amplitude, soit de la saturation, soit des parasites...

	Pour le son YAMAHA du STF je calcule des valeurs de programmation
pour le timer A du MFP (utilise en interruptions)  partir de la frquence
d'chantillonnage mais l'erreur avec la frquence thorique est plus
leve avec une frquence leve. Je l'utilise sur HADES aussi en direct
to disk (la STARTRACK doit fonctionner galement si elle utilise les
fonctions DMA du XBIOS FALCON).


Guillaume:


	Un truc me chiffonne : ton player est plus ancien que le mien,
mais il me semble que son ouverture  d'autres configurations que la
tienne est trs rcente (cartes graphiques, TT...). Quelles en furent les
raisons  une poque o tout un chacun s'extasie facilement devant un soft
compatible toutes machines ? (ce qui est,  mon sens, une mauvaise raison
de s'extasier)



Didier:

	L'ide de l'ouverture de mon player sur les machines autres que
le FALCON m'est venue depuis que j'ai diffus mon player (en dcembre 1996)
pour contenter un maximum de personnes en visant un maximum d'ataristes.
C'est galement  cette poque que j'ai dcid d'tre actif en achetant un
modem et en mettant mes programmes en freeware. Et depuis, tout mon temps
micro passe sur le dveloppement de mon player...


	Pour le fonctionnement sous GEM du player en True Color, je pense
que certaines personnes sont intresses. Il y a des utilisateurs de FALCON
qui travaillent en True Color 640 * 480 pour se connecter sur Internet, avec
un FALCON acclr c'est possible. Alors sur TT et HADES a ce justifie
encore plus par la puissance disponible. Pense-tu Guillaume, un jour
passer ton player sous GEM pour les HADESiens ?


Guillaume :



	Je suis (presque) d'accord avec toi sur le True Color (TT+carte,
Hades ou Falcon boost). D'ailleurs, j'ai cd  la tentation et, dans
les cas o le bureau est dj en 32768 couleurs mini, l'affichage se fait
dans une fentre. Par contre, dans un autre mode du bureau, je me demande
quel plaisir peut avoir une personne  visualiser une anim avec un fond
dgueulasse parceque la palette a t change... Dans ce cas, un passage
en fond noir me semble le summum du confort visuel.

	Alors, c'est vrai qu'on peut tramer en 216 couleurs et conserver
les couleurs GEM intactes... mais si l'anim a exactement 256 couleurs ?
Doit on encore tramer ? Quelle perte de temps et de qualit!

	Mais mme en High Color, je reste sceptique quant  l'utilit de
la chose : imaginez votre tlvision avec un cran quatre fois trop grand
dont le film que vous regardez n'occupe qu'un quart : aurez vous le mme
confort, la mme attention alors que sur les 3/4 restants se promnent des
couleurs, des objets, parfois vifs et blancs?... Pour la vido, un bon
fond noir genre salle de cinma me semble le plus appropri.



Didier :



	C'est qu'en 256 couleurs, il y a de quoi se poser la question. La
rduction de couleurs et la meilleure solution pour la vitesse avec les
animations en 32K ou 16M de couleurs avec 216 couleurs. Les animations en
256 couleurs n'utilisent pas forcment toute la palette. Quand  l'affichage
sous GEM en 16 couleurs, le tramage utilise la palette systme d'origine,
le problme de changement de palette ne se pose donc pas, a moins que
l'utilisateur a effectu un changement avec une image de fond... Pour
les resolutions vidos infrieures  16 couleurs je trame en monochrome.



Guillaume :



	Revenons de l'autre cot de la puissance, y-a-t-il une chance de
voir tourner un jour ANIPLAY sur une machine 68000 (STE ou Mega STE avec
carte) ?



Didier :



	Il est possible que mon player fonctionne un jour correctement sur
ST(E) sans les 3 bombes possibles, tout dpend si j'ai suffisamment de
demandes pour me convaincre. Mais je pense qu'il faudra m'orienter vers un
programme spar pour viter que la taille du player n'augmente de trop
(a revient pour viter l'accs sur les adresses impaires de faire 4 accs
sur un octet  la place d'un seul sur un long, moi j'appelle a de la
dsoptimisation). Reste  savoir si a vaut vraiment le coup...



	A ce sujet a-tu obtenu beaucoup d'enregistrements des STistes ?



Guillaume :



	Tu vas rire: seulement 9 en 11 mois... Pourtant c'est pas faute
d'y avoir mis le paquet ct options pour rendre les anims fluides sur un
ST. Je suis mme en train d'adapter le IV32 (le dinausaure d'Intel) au
68000...



Didier :



	Quelle est ta mthode d'affichage des animations sur cette machine ?



Guillaume :



	J'affiche en niveaux de gris, si l'anim n'a que 16 couleurs, alors
elle passe en couleurs. Pour celles ayant 256 couleurs, on a la
possibilit d'appliquer un algorithme de rduction de palette qui donne
d'excellents rsultats en couleur. Pour ce qui est de la taille, tout ce
qui est au dessus de 320 est reduit de moiti (donc on peut visualiser une
animation 640x480).

	J'ai galement ajout le support de l'affichage ST Haute
monochrome: les animations sont trames par un filtre de Bayer trs rapide
(matrice 8x8) que je dcale d'une ligne une fois sur deux afin de briser
la rgularit de la trame. Le rsultat me semble bon au vu de ce qui est
demand au pauvre 68000 en temps rel.

	Quelque soit l'affichage (ST Haute ou ST Basse) on a la
possibilit de convertir une anim en FLM sonore: on obtient ainsi une
copie d'un ex-MOV, ex-FLI ou ex-AVI passant a 15 images/s avec son et
synchro sur un simple STE.

	Sinon, sans le FLM, j'ai une version modifie de la routine de
Douglas Little pour faire du 4 plans entrelacs de manire rapide.



	Ton ANIPLAY inclut, il me semble, une solution d'avenir se basant
sur la prolifration de machines TOS de plus en plus puissantes: c'est le
son et l'image en D2D. Comment, en 1995, cette ide s'est elle impose 
toi ? Pourquoi, face  la ralit de ce qu'tait le parc Atari il y a peu,
n'as tu pas comme moi opt pour une solution raisonnable du traitement
spar du son ?



Didier :



	Je pense ne pas perdre trop de temps  lire le son en D2D en plus
des images, c'est vrai avec mon CD-ROM 10X. La perte de temps est compens
soit par l'utilisation du DSP sur FALCON soit par l'optimisation 
l'extrme de certains formats de compression (c'est le cas je pense du
Cinepak). Cette optimisation se fait au dtriment de la taille du
programme (qui atteint les 200K avec maintenant l'IV32). J'ai opte pour
cette solution car  l'poque j'avais un CD-ROM 2X, ma Speed Resolution
Card  40 MHz, mais que 4 Mo. La seule solution pour passer des gros
fichiers (j'en ai pass un d'une dure de 15 minutes) c'est de travailler
totalement en D2D. L'avantage aussi de cette solution c'est que
l'animation dmarre tout de suite.

	 Par la suite, il est nanmoins possible que je charge via option
totalement le fichier en mmoire (si possible) pour les FALCON de 14 Mo ne
disposant pas de carte acclratice (et/ou pour les possesseurs de CD-ROM
2X). Au niveau performances sur FALCON avec du Cinepak et le DSP mon
player est un peu plus rapide que toi, sur TT a doit tre l'inverse.
C'est tout  fait normal car on optimise son programme avant tout pour sa
machine. L'inconvnient du full D2D c'est qu'il m'a pos jusqu' cet t
pas mal de problmes avec l'option sauter images (synchro chez toi),
maintenant a fonctionne  peu prs correctement avec tous les fichiers.



	Au niveau optimisation, je sais que ton programme est totalement
en assembleur (comme le mien), mais utilise tu beaucoup les instructions
du 68030, et dans ce cas, cela apporte t-il beaucoup d'amliorations
notable en vitesse ?



Guillaume :



	Comme tu le disais, la facilit ce sont les accs de mots ou mots
longs  des adresses impaires, c'est surtout cette possibilit '68030
only' qui donne du punch au player (cela vite de quadrupler l'instruction
!! ). Egalement, la possibilit de faire des accs indirects selon un
indice D0, ou D0*2, ou D0*4 sans modifier D0 est trs pratique pour les
conversions de couleurs. Pour finir, les instructions de division et
multiplication sur 32/64 bits vitent toutes les routines obligatoires
avec un 68000. Mais ces deux dernires ne constituent qu'un confort de
programmeur, car ces instructions n'interviennent que dans la prparation
de l'animation et n'influent pas sur le rendu.

	Je reste nanmoins persuad qu'un bon codeur 68000 peut gnrer un
programme trs performant tournant sur 68030 sans utiliser les nouvelles
instructions. D'ailleurs, il me semble que les instructions utilisant la
double indirection ne sont pas plus rapides que l'quivalent 68000 en
plusieurs instructions.



Didier :



	Je le pense galement, d'ailleurs j'utilise seulement le code
68030 dans les parties critiques. Il faut dire que pour l'instant
j'utilise encore mon Assembleur (prhistorique) PROFIMAT, qui ne gnre
que du code 68000, les parties critiques sont donc des codes taps  la
main (DC.L xxxxxxxx). Pour le DSP j'utilise DEVPAC DSP bien qu'il peut
gnrer quelques code errons  l'assemblage (enfin je fais avec !).


Guillaume :

	J'utilise ASSEMBLE. Si il n'existait pas, il faudrait l'inventer
de toute urgence!
	J'aimerai conclure en me flicitant de l'ambiance bon-enfant qui
peut rgner entre des programmeurs  priori "ennemis". En effet, nous
travaillons sur le mme domaine et nos deux crations sont en concurrence
directe (trs directe, puisque nous sommes les seuls  proposer le MOV,
AVI et FLI en un seul programme avec une ouverture multimachines). J'ai
connu des Ataristes qui se tiraient dans les pattes. Je crois qu'on est
trop peu nombreux pour pouvoir se le permettre sans porter prjudice 
notre "petit monde" dj bien fragile.
	Je te dis tschaow, et  bientt sur le Net pour d'autres changes
essentiels d'ides et de codes sources !

Didier :

	Je suis totalement d'accord avec toi, je suis d'ailleurs ouvert
pour accepter les critiques constructives, et sur le Net j'ai trouv
chez toi une personne avec qui je peux discuter. Il ne faut pas oublier
que l'avenir de nos machines repose en partie sur mous. Ce serait bien
dommage qu'une des dernires machines, o le programmeur et l'utilisateur
ont encore la maitrise du systme et leur mot  dire sans succomber 
la Wintelmania, soit raye de la plante comme le ft ATARI...

											   gtello@wanadoo.fr
	Guillaume Tello (gtello@wanadoo.fr)
	Didier Mquignon (didier.mequignon@wanadoo.fr)											   didier.mequignon@wanadoo.fr
