Suivez-nous sur X
|
|
|
0,
A,
B,
C,
D,
E,
F,
G,
H,
I,
J,
K,
L,
M,
N,
O,
P,
Q,
R,
S,
T,
U,
V,
W,
X,
Y,
Z,
ALL
|
|
0,
A,
B,
C,
D,
E,
F,
G,
H,
I,
J,
K,
L,
M,
N,
O,
P,
Q,
R,
S,
T,
U,
V,
W,
X,
Y,
Z
|
|
0,
A,
B,
C,
D,
E,
F,
G,
H,
I,
J,
K,
L,
M,
N,
O,
P,
Q,
R,
S,
T,
U,
V,
W,
X,
Y,
Z
|
|
A propos d'Obligement
|
|
David Brunet
|
|
|
|
Le courrier des lecteurs d'Amiga News Tech - juin 1991
(Rubrique animée par Frédéric Mazué et extraite d'Amiga News Tech - juin 1991)
|
|
Depuis que la rubrique "Requester" (Courriers des lecteurs) existe, nous avons répondu à pas mal de questions dans beaucoup de domaines...
Mais l'ANT étant devenu "le premier magazine dédié aux programmeurs sur Amiga", nous vous saurions gré de ne
plus nous parler des C64, PET et autres PC... Même si ce sont bien des machines Commodore, l'ANT ne se voue
qu'à l'Amiga. D'avance, merci.
Calcul 3D
Bonjour à tous, et en particulier à Pascal Amiable. Lecteur d'ANT intéressé par la 3D,
j'ai jeté un oeil sur le programme de 3D du "Coin des démomakers" du mois d'avril 1991. Je me permets de
faire plusieurs remarques concernant la programmation. Ces remarques sont un peu techniques, mais bon, c'est
ANTech, non ?
Commençons par les moins importantes. Concernant le détourage de droites, les arguments donnés en faveur de
la technique dichotomique et contre le calcul utilisant une division sont faux : le calcul par le coefficient
directeur ne fait perdre aucune précision s'il est fait intelligemment. Il est sûr que faire le calcul
(y2-y1)/(x2-x1) donne un résultat fractionnaire difficile à gérer, mais si on fait (x_max-x1)*(y2-y1)
puis l'on divise ce résultat par (x2-x1), on obtient une valeur parfaitement correcte de y_inter.
Le seul argument en faveur de la dichotomie est qu'elle permet parfois de trouver l'intersection plus
rapidement, mais par contre, dans d'autres cas, elle peut se révéler beaucoup plus longue.
L'auteur de l'article nous dit qu'il n'a pas l'intention de faire la 3D la plus rapide, mais plutôt
d'initier les débutants, alors qu'il utilise des techniques d'optimisation dignes d'un programmeur ST.
Exemple : l'effacement Blitter + 68000 qui, pour un débutant, n'est pas forcément facile à appréhender.
Mais surtout, il commet une erreur impardonnable : le code auto-modifié ! Non seulement cette pratique
est indigne du 68000 mais aussi, comme vous le dîtes si bien dans votre dernière page, elle a le
gros inconvénient de ne pas fonctionner sur micros avec mémoire cache. De plus, en utilisant correctement
le 68000, il aurait été aisé de faire quelque chose de plus rapide, par exemple en utilisant un
pointeur sur une variable contenant les sinus et cosinus courants, et en faisant des "movem.w (a0)+,d4/d5".
C'est plus rapide et sans danger !
Quelques mots sur le journal pour finir : le contenu du premier numéro était un peu décevant et
donnait une sensation de "vide", mais les choses vont en s'améliorant. Par contre, j'attends
toujours les entrevues, notamment celle de Fred Fish. En tout cas, bonne continuation
[Thomas Landspurg].
Réponse
Heeeyyy, vous avez vu qui nous écrit là ? Thomas Landspurg, Mister 3D himself ! Ceux qui ne
connaîtraient pas ses démos, dont celle qui l'a rendu célèbre, la VectorBall Demo, sont
priés de se ruer chez le petit copain les copier illico !
Cela dit, les critiques de Thomas sont parfaitement fondées. En ce qui concerne la 3D, je
pense qu'on peut lui faire confiance quant aux arguments pour ou contre la recherche dichotomique
ainsi que pour les questions d'optimisations diverses... Mais Jérôme Étienne, l'auteur de l'article
en question, a pour but d'initier à la 3D en assembleur, non à l'assembleur lui-même. Accélérer
l'effacement de l'écran en utilisant conjointement le Blitter et le processeur peut passer
inaperçu, du moment que le lecteur aura compris le principe de la 3D elle-même. Ce n'est pas
là le point le plus important de l'article. Quant à l'utilisation du code auto-modifié, il est
vrai que cela jure un tantinet avec la rubrique CATS dans laquelle on déconseille fortement cette
pratique. Jérôme Étienne en a d'ailleurs été puni, se retrouvant sans Amiga pour plusieurs semaines !
Pour terminer, merci à Thomas pour les critiques sur le journal en lui-même. Elles résument parfaitement
le sentiment général, qui, il faut bien le dire, est également le nôtre. Nous pensons toutefois
avoir largement remédié à cet état de fait depuis quelques numéros. Quoiqu'il en soit, n'oubliez
jamais que l'ANT est et reste avant tout votre journal. Nous sommes prêts à accueillir toutes les
idées, toutes les suggestions et propositions d'articles que vous jugerez bon de nous faire parvenir.
Il est évident que si vous ne faites pas vivre l'ANT par votre courrier, si vous ne nous donnez pas
de fil directeur, il ne pourra sans doute jamais répondre à toutes vos attentes. Le sondage du
premier numéro, destiné à vous mobiliser un peu, nous a déjà permis de nous faire une idée de ce
que vous vous attendiez à trouver dans l'ANT et de ce dont vous vous fichez éperdument... dont
les entrevues, même de Fred Fish !
Lecteur HD, port parallèle et assembleur
Chers ANTiens, je vous félicite en tant qu'amigaïste et que membre de l'association Corsaire
Productions pour dire qu'enfin, un vrai journal technique a fait son apparition en France. En
tant que technicien de l'association, j'ai essayé différents matériels sur mon Amiga et ma
question sera peut-on installer un lecteur 3"1/2 HD (haute densité) et si oui, comment ?
Mes essais ont été infructueux : 880 ko, mais pas un de plus !
Une autre question tournera autour de l'utilisation du port parallèle de l'Amiga en assembleur.
J'aimerais connaître les différentes adresses permettant de le paramétrer sans gêner le
multitâche. Dans le même ordre d'idée, j'ai de gros problèmes de transmission avec le port série,
qui ne fonctionne correctement qu'en BASIC. Les liaisons entre deux Amiga
par l'un ou l'autre restent difficiles à réaliser. Vous désirez des questions, en voici quelques-unes
qui vous feront passer quelques heures de recherches, fructueuses j'espère. Merci d'avance, et
continuez comme ça encore longtemps. Et longue vie à l'Amiga !
[Bruno Lebresne].
Réponse
Connecter un lecteur haute densité sur l'Amiga est évidemment possible, mais c'est moins
facile que l'on ne pourrait le penser à priori... A l'inverse du PC, qui a au moins ça
de bien, l'Amiga ne sait pas reconnaître le type des lecteurs connectés. Il
ne différencie déjà pas le 5"1/4 du 3"1/2, alors lui demander de faire la différence entre
un double densité et un haute densité, hein, franchement... Le problème ne se situe pas
au niveau de la connectique, comme tu as déjà pu en faire l'expérience, mais bel et bien
au niveau du logiciel. En effet, le trackdisk.device ne sait rien gérer d'autre que la
double densité.
Pour régler le problème, il faut donc y aller du compilateur C et de l'assembleur, et écrire
un gestionnaire (handler) particulier pour le lecteur haute densité capable de gérer un nombre
accru de secteurs par piste et d'octets par secteur. Ce qui n'est pas une tâche aisée, j'en
conviens. Pour ce qui concerne le port parallèle, deux possibilités s'offrent à toi si tu
tiens réellement à rester "amiga friendly" (ce dont nous ne pouvons que te féliciter) utilise
soit le parallel.device, soit la misc.resource (voir à ce sujet
l'article de Max dans ce même numéro).
Cette seconde solution est cependant plus difficile à mettre en oeuvre, car il faut alors attaquer
directement le matériel.
Il en va de même pour le port série. Le serial.device et la misc.resource (encore elle) sont
là pour te permettre de l'utiliser à ta guise. Si la transmission ne fonctionne pas correctement,
vérifie surtout que le port est paramétré de la même manière sur les deux terminaux (les préférences
sont là pour ça) et que tu utilises un protocole de communication correct (en fonction de la parité,
du nombre de bits de données, du "handshaking" et que sais-je encore ?). Et merci pour ton
enthousiasme qui nous va droit au coeur !
Ajouter des menus dans le Workbench
Bonjour à toute l'équipe de l'ANT. Je ne m'attarderai pas sur le journal que je trouve très
bien comme il est, et passerai directement à une question qui me turlupine depuis quelque
temps. Je programme en assembleur, et je recherche le moyen d'ajouter des menus personnels
à ceux du Workbench. Je sais que plusieurs programmes du domaine public réalisent déjà cela,
mais ceux que j'ai pu voir jusqu'ici ne me conviennent pas. Pourriez-vous me donner un fil
conducteur ?
[Philippe Lamy-Jonc].
Réponse
Le principe est simple : il faut rechercher dans la liste des écrans et des fenêtres -
liste maintenue par Intuition - celle du Workbench. Elle est facilement reconnaissable :
le drapeau BACKDROP est positionné et son titre est "Workbench" (tout bêtement). Il
faut alors extraire de cette structure les adresses du Menu et du MsgPort utilisés par
le Workbench (tous deux se trouvent en mémoire). Ensuite, ClearMenuStrip(), ajout d'une
ou plusieurs structures Menu derrière le menu "Special", puis SetMenuStrip() suffisent à
ajouter autant de menus que tu le désires.
Pour les gérer, il faut remplacer le champ wd_UserPort de la fenêtre du Workbench par un
MsgPort à toi et filtrer tous les messages qui y arrivent : tant qu'il ne s'agit pas d'un
message du type MENUPICK, il faut le détourner avec PutMsg() sur le MsgPort original du
Workbench (sinon, il ne reçoit plus rien !). S'il s'agit bien d'un MENUPICK, il faut évidemment
vérifier que c'est bien l'un des nouveaux menus qui a été sélectionné, sinon PutMsg()
à nouveau. Bref, voici une routine qui réalise tout cela (on suppose que toute la partie
initialisation - ouverture des bibliothèques, création d'un MsgPort avec CreatePort()
ou une routine équivalente, etc. - est déjà réalisée).
Voilà. Il n'y a bien sûr que le squelette du programme, mais cela devrait te permettre d'avancer
quand même un peu... Tu peux même, si cela t'amuse, envoyer de faux messages au Workbench,
ou bien en filtrer certains, les modifier... Tout (ou presque) est permis !
|