Re: GUERRE ST-AMIGA, FIGHT !!!

[drfloyd]

tiens, alors meme le C64 en prend pour son grade, la rolls des micro 8bit etait une merde aussi....

[Seb]

Tu crois que ton esprit partialiste est mieux que ce que tu appelles mon étroitesse d'esprit ? A toujours tout voir via le prisme du ST, sans regarder plus au large ?

Je te rappelle que j'ai eu les 2 machines et que j'adore les 2. Mes posts précédents expliquaient même pourquoi l'Amiga était une machine globalement plus puissante que le ST. Je ne suis pas "partialiste" et je n'ai pas de prisme ST.

Je ne me souviens pas avoir écrit une seule des choses que tu as mises entre guillements au passage, sur Vroom ou autre chose, tu te trompes de personne.

Mais une fois de plus, tu ne vois que ce que tu veux voir.

[dlfrsilver]

tiens, alors meme le C64 en prend pour son grade, la rolls des micro 8bit etait une merde aussi....

Alors ton argument de rolls des micros 8 bits, désolé, mais personne ne peut l'acheter. Le seul truc qui sauve cette machine, c'est le SID. La palette de couleurs est juste immonde, le processeur ridicule.

L'amstrad CPC était clairement la Rolls des 8 bits : qualité de conception, de fabrication, un plastique de bonne qualité, qui ne s'éffrite pas (pas comme celui du c64 et du ST par exemple), performances globalement équilibrées, une belle palette de couleurs, et une puce dédiée à la vidéo, et aucun problème d'alimentation, avec une carte mère n'ayant que très peu de condensateurs.

Le c64 n'est pas une machine équilibrée. Tout à été misé sur le SID, et sur les sprites hardware, et les extensions qui coutaient bien trop cher pour ce qu'elles offraient.

Le C64 est d'un point matériel une machine très fragile oui, tu te souviens pas qu'au moment de sa sortie, il avait une garantie de 90 jours seulement justement à cause de ça ?

La machine pouvait te claquer dans les doigts sans mot dire. J'ai découvert cette information en lisant un journal de l'époque sur Abandonware Magazine.

J'avais trouvé ça très "tramielesque". Ou comment je me blinde les fouilles de pognon en refilant aux client du matos merdique.

Bien sur, si on s'en tient au son, le SID a un bon rendu, c'est un indéniable. Mais voilà, pour un ordinateur qui coutait une blinde, ça la foutait mal :)

Comme pour l'Amiga 1000, le c64 avait un prix inapproprié. Par rapport à sa qualité de finition et aux pièces qui le composait s'entend, car l'amiga avait lui un hardware de qualité supérieure et une bien meilleure finition.

[dlfrsilver]

Tu crois que ton esprit partialiste est mieux que ce que tu appelles mon étroitesse d'esprit ? A toujours tout voir via le prisme du ST, sans regarder plus au large ?

Je te rappelle que j'ai eu les 2 machines et que j'adore les 2. Mes posts précédents expliquaient même pourquoi l'Amiga était une machine globalement plus puissante que le ST. Je ne suis pas "partialiste" et je n'ai pas de prisme ST.

Je ne me souviens pas avoir écrit une seule des choses que tu as mises entre guillements au passage, sur Vroom ou autre chose, tu te trompes de personne.

Mais une fois de plus, tu ne vois que ce que tu veux voir.

Dans ce cas pourquoi tu as ramené la chose au ST, alors que je parlais du GFA basic, sorti sur les 2 machines ?

La version Amiga est pareille à la version ST et propose presque les même choses.

[Seb]

tiens, alors meme le C64 en prend pour son grade, la rolls des micro 8bit etait une merde aussi....

A un moment je pense que ca ne sert à rien de continuer à perdre son temps avec un troll.

Discuter avec dlfrsilver c'est un peu comme discuter avec les creationistes. Je vais arrêter de perdre mon temps en laissant cette image qui représente bien les discussions avec dlfrsilver ici et sur d'autres sites (heureusement que Stapha92 compense le niveau)

Dans ce cas pourquoi tu as ramené la chose au ST, alors que je parlais du GFA basic, sorti sur les 2 machines ? 

La version Amiga est pareille à la version ST et propose presque les même choses.

Parce que comme je le disais dans mon post le GFA basic a été développé sur ST puis porté ailleurs plus tard, donc c'était un bon exemple d'exclu ST en 1986 mais je m'arrête là c'est sans intéret cette discussion.

[babsimov]

Ca depend ce que tu veux faire....

ce GFA32 je ne suis pas trop certain de sa fiabilité, ni de sa documentation... j'ai l'impression que le support est abandonné.

En "pur" basic aujourd'hui le basic BLITZMAX est quand meme bien plus convivial par exemple

Je posais la question par curiosité, la programmation ça remonte bien trop loin pour moi.

[ryosaeba]

c'est en effet ce qui rend ce débat difficile, car l'avantage du ST se modifie en fonction du temps :

de 85 à 87 : c'est clairement le ST qui a le dessus : machine 2x moins cher, jeux presque identiques sur Amiga, plus pratique et fiable à utiliser au quotidien que WB 1.0

ensuite l'Amiga est devenu abordable et +- abouti dans sa version A500.  Atari a senti le vent tourner et a essayé de rattraper le coup avec le malheureux STe... et là, de 88 à 92, Atari n'a fait que perdre de la vitesse et n'a rien sorti de bon jusqu'au Falcon.

Donc je résumerais par :
 
85-88  : ATARI WINNER
89-92  : AMIGA WINNER

On peut dire ça, j'ajouterai une nuance :

85-88 : ATARI WINNER FINGER IN THE NOZE
89-92 : ATARI WINNER POUR LA BUREAUTIQUE/PRO/PROG/ULILITAIRES et AMIGA WINNER POUR LE JEU

Et comme pour moi la grande epoque 16/32bit c'etait 86-89... tous les titres revolutionnaires sont sortis sur cette période, et franchement y a eu essoufflement des 1990 dans la qualité des programmes... ATARI l'emporte donc HAUT LA MAIN dans cette guerre.

Je sais, je devais faire une pause, mais lire des truc comme ça, c'est du n'importe quoi !

Je l'ai déjà dit, le ex-ingénieurs Atari l'emportent haut là main (hardware et OS) !

Parce que les ingénieurs de l'Atari de l'époque ST n'avaient clairement RIEN à voir avec eux au niveau technique si j'en juge mes lectures sur ce forum.

Quant au jeux 16/32 bits qui s’essoufflent à partir de 1990... c'est sur qu'à partir de cette époque, le ST, il suit plus...

Et rappelons nous de ce qui sort à partir de 1990 comme jeux soit disant "essouflés" :

- Wing Commander (PC/Amiga), c'est LE JEU qui a fait basculer le marché du jeu sur PC. Même moi, à l'époque, j'ai faillit passer sur PC à cause de CE jeu.

- Dune (PC/Amiga). La version PC étant clairement une réussite à tous les niveaux.

- Dune II (PC/Amiga). Celui là c'est la base des jeux de stratégies temps réel qui sont de nos jours encore d'actualité.

- Wolfenstein3D (PC), là aussi la base des FPS... 
Sur ST vous en avez eu des FPS à l'époque ? Sur Amiga il y en a eut alors que c'était réputé impossible (c'est l'auteur de Wolfenstein 3D qui prétendait ça, encore un programmeur PC qui faisait tout au processeur... donc forcément l'Amiga il pouvait pas appréhender).

- The Settlers (PC/AMIGA)

- Civilization (PC/AMIGA/ST)... tiens je me demandais pourquoi l'affichage était si lent sur Amiga par rapport à la version PC... j'avais toujours pensé que c'était à cause de la version MAC... et non, ça devait encore être à cause d'un mauvais portage ST vers Amiga.

Et, il y en a surement d'autres dont je ne me souviens pas.

Quant au domaine des logiciels pro, en dehors de la bureautique (ou le ST avait la quantité et plus de chose en français), l'Amiga avait largement de quoi faire. Pour la programmation, tous les langages soit disant exclusif du ST ont été adapté sur Amiga (GFA et STos...). Ah et parlons de ce dernier... La version de STos sur Amiga s'appelait AMOS, qui, bien entendu, était meilleur que le STos... et que dit son auteur :

http://obligement.free.fr/articles/itwlionet.php

"Première question piège, quelle machine as-tu préféré, Atari ou Amiga ? Et bien entendu, pourquoi ?

L'Amiga bien entendu. Les modes graphiques de l'Atari en 640x480 maximum étaient vraiment trop limités, et je n'aimais pas le GEM."

Tiens un STiste qui n'aimait pas le GEM... et qui en plus préfère l'Amiga en ayant eut les deux... 

Et il persiste et signe pour le GEM :

"Au départ, le STOS était destiné à offrir un nouveau système pour remplacer le GEM sur Atari."

Tiens, ça me fait penser que ça fait au moins deux programmeurs chevronnés qui préfèrent l'Amiga (celui d'AMOS, et celui de DirectX)...

Et puisqu'on parle d'utilitaires, vous connaissez Aminet, la plus grosse bibliothèque d'utilitaires domaines publiques en tous genres et toute plateforme confondues de l'époque... Un des nombreux avantage de l'Amiga. Et cette bibliothèque n'a pas attendue internet pour être connue, il y avait les célèbres CD aminet, et avant les collections de disquettes DP.

Bref, ce que je constate sur ce forum, c'est que lorsque les Amigaistes font une pause, les PRO Atari ici se livrent au révisionnisme et distillent LEURS vérités en prétendant que c'était la réalité de l'époque. 

Pourtant, sans la petite nuance, j'aurais été prêt à accepter le résumé de Rocky007. 

Même si je n'adhère pas au +-abouti pour le 500 (face au ST non évolutif), ainsi qu'à la référence au WB 1.0 alors qu'on a vu que le TOS aussi il faudra attendre, je cite, "à partir du 1.04 ça commence enfin à devenir un plaisir d'utiliser un ST". Hors le 1.04 c'est 87. Donc égalité, puisque 87 c'est le 1.2 et on peut dire la même chose pour l'Amiga. 
Voici la source, c'est ST Magazine de l'époque, j'espère qu'on va pas me dire que c'était un magazine anti-ST :)




J'avais espéré que ma pause serait quand même plus longue. Je pensais pouvoir lire le sujet de manière détachée. Je vais essayer de le faire, à l'avenir, car, parfois on y apprend des choses intéressantes sur les deux machines.

Cela provient de quel numéro de st mag ?

[stapha92]

Babsimov,

Tu avais raison : je voulais dire qu'un OS monotache est "moins" risqué. J'ai édité mon post.

Pour ta question sur la difficulté à tirer parti du mig : non, ce n'est pas du tout aussi difficile que le XL. C'est même assez facile en fait.

Tu me posais des questions sur mon ressenti sur les 2 machines. 

J'ai eu un ST puis un mig. Et j'ai REELLEMENT utilisé les 2. Connais-tu quelqu'un qui l'ai fait et qui ait préféré le ST ? Je veux dire, en dehors de ce forum ? Personne ? C'est bien ce que je pensais... 

Et quand tu as codé en tatant du TOS et de l'AmigaOS, tu ne regrettais pas le premier. Vraiment pas. Car c'est le jour et la nuit. 
Je parle de coder : 
        - Sérieusement. Pas de jouer avec le GFA. Non pas que ce soit criticable, mais ce dernier cache au codeurs les appels aux fonctions du TOS. Tout juste peut-il se rendre compte que le GFA sur mig était plus rapide... 
        - Des applis pour l'OS. Un codeur de démo ou de jeux en n'avait rien à faire que le TOS soit si mal foutu : il ne l'utilisait (presque) pas. 
        
Je te le dis : ceux qui expliquent le contraire mentent. 

Donc j'ai eu les 2. Et tu sais quoi ? J'ai eu plus de bombes que de Guru meditation. Largement plus... Cela veut-il dire que le TOS/GEM est moins fiable ? Pas forcément : j'ai beau être un fan-boy Amiga, je n'oublie pas que j'ai eu le ST AVANT le mig. Donc j'ai bénéficié d'un AmigaOS plus ancien que le TOS. 

Parlons du livre cité par Rocky, l'auteur parle de bugs et donne deux exemples : 
        - Une division par 0 
        - Un manque de mémoire. Il s'agissait du Guru le plus courant : un programme demande une zone mémoire. L'OS lui renvoit la valeur NULL car il n'y a plus assez de mémoire dans la machine (donc la demande de mémoire est refusée) et le programme, au lieu de vérifier qu'il n'a pas reçu la valeur NULL va essayer d'exploiter l'adresse reçue. 
Dans les 2 cas, ça n'a rien à voir avec le multitache et ça peut tout aussi bien se produire avec n'importe quel OS... 

L'auteur parle de la programmation événementielle qui était une nouveauté (sur les machine personnels). Je me souviens avoir expliqué avoir découvert ça sur le mig quand je disais que coder dessus était bien plus interessant que coder sur ST. Et ça m'a été utile : aujourd'hui toutes les applis font de l'événementiel... 

Idem quand tu expliques à Rocky que c'était plus ergonomique de ne pas être obligé de saisir sa souris pour cliquer sur OK quand tu insérais la disquette demandée. Il t'a répondu qu'il suffisait de quelques lignes de code en C pour faire pareil. 
Sauf que quand tu appelles la fonction du GEM qui affiche une boite de dialogue pour confirmer ou annuler, ton programme n'a plus la main tant que l'utilisateur n'a pas fait l'un des 2 choix ! Donc ça : 

et comme déjà dit, rien n'empêchant le codeur de faire d'ajouter ses 10 lignes de C dans son logiciel pour faire la detection automatique.  
plein de jeux Atari detectait tout seul le changement de disquettes.

C'est faux. Le seul moyen pour le codeur est de gérer lui même la boite de dialogue entièrement : c'est un plus long que 10 lignes de code en C... 
L'autre solution serait l'ouverture d'une fenêtre modale. C'est à dire une fenêtre autonome qui ne bloque pas l'appelant. Mais ce n'est possible qu'avec du multitache. Donc interdit au ST... 
Et oui, le multitache sert aussi à faire des applis MDI. Ce qui apporte un plus en terme d'ergonomie.

Un jeu par contre, ne passe pas par le GEM pour demander une confirmation à l'utilisateur : c'est pour ça que des jeux pouvait le faire. Mais sortir cet exemple dans une discussion sur les limites du TOS/GEM. Hmmm.... 

Sur l'Autorun dont tu parlais : il n'y a pas que le programme lancé automatiquement. il y a aussi l'icone. Quand tu met un CD dans un micro d'aujourd'hui, c'est un icone peronnalisé qui apparait. Et c'est comme ça depuis 1995 sous windows. Ou 1985 sous AmigaOS...

Revenons sur le débat TOS/AmigaOS :

Il y a de grandes discussion ici sur le TOS et l'AmigaOS. 
Mais elles s'arretent sur l'aspect visible de ces OS. Et comme pour un iceberg, ça ne représente qu'une toute petite portion de l'OS. Et ce n'est pas la plus importante. 
Le plus important, ce sont les API de l'OS. Ce sont elles qui permettent à toutes les applications de tourner dessus.
Les API sont des ensembles de fonction qui permettent d'effectuer un certains nombre d'actions. Elle permettent, entre autres : 
        - D'éviter d'avoir à réinventer la roue à chaque écriture de logiciel. Pour cela elles doivent être le plus complete possible. Et le TOS est loin derrière le mig à ce niveau. 
        - D'utiliser le hardware sans être obligé de le manipuler directement. 
        - D'avoir des applications qui disposent du même look & feel. 

Un logiciel quel qu'il soit (on écarte les démos et les jeux de cette explication) passe une bonne partie de son temps à appeler ces fonctions de l'OS. 

Comment appeler une fonction de l'OS dans le mig ? 

Les fonctions sont regroupées dans des bibliothèques. Avant de pouvoir utiliser une fonction, il faut "ouvrir" la bibliothèques qui la contient. Bien sur, un programme ne le fait qu'une seule fois. Le plus souvent pendant son initialisation. 

Ouvrir une bibliothèque permet, entre autres, de savoir ou elle se trouve. C'est bien sur une obligation pour pouvoir l'utiliser ! 
Comment fait-on ? C'est simple : on utilise la fonction OpenLibrary de la bibliothèque EXEC. Mais comment ouvrir EXEC alors ?!!! 
Pas besoin : EXEC est la seule bibliotheque qui soit toujours ouverte. Et son adresse est fixe. C'est la seule qui soit dans ce cas dans tout l'AmigaOS. Ce qui apporte de la souplesse et permet de conserver une compatibilité totale si des bibliothèque sont modifiée. 

Exemple, on trouve en ROM une bibliothèque A et juste après une bibliotheque B. On améliore l'OS et on ajoute des fonction à la bibliothèque A. Du coup la bibliothèque B ne sera plus au même endroit. Avec le système de l'AmigaOS, ça ne posera pas de problème. Y compris pour EXEC : comme c'est la première des bibliothèques en ROM, elle se trouvera toujours au même endroit. 

Evidemment, rien n'empeche le codeur "maladroit" d'appeler une fonction de l'OS directement sans utiliser le système d'ouverture. Après tout, il sait bien ou se trouvent les fonctions dont il a besoin. Pourquoi s'embeter à respecter les recommandation de Commodore ? 
C'est ce que faisait souvent les jeux du début (Juste par flemme...). Et c'est pourquoi ils rencontreront des problèmes de compatibilité avec les versions ultérieures de l'AmigaOS. 

Alors : comment fonctionne OpenLibrary ? 

On lui donne le nom et la version de la bibliothèque que l'on souhaite utiliser et elle renvoit un pointeur qui contient l'adresse de base de la bibliothèque. Si elle ne la trouve pas dans la ROM, elle recherche dans le répertoire LIBS et si elle la trouve, la charge en mémoire. Elle vérifie que le numéro de version de la bibliothèque trouvée est supérieur ou égal au numéro de version que l'on a envoyé en paramètre. Si elle ne trouve pas la bibliothèque ou si celle qu'elle a trouvé n'a pas le bon numéro de version, elle renvoit null. 
On donne le nom de la bibliothèque en clair. On peut donc avoir un nombre énorme de bibliothèque différente. 
On peut même indiquer un chemin complet pour le nom de la bibliothèque et l'AmigaOS ira directement voir à cet endroit pour la charger (au lieu d'aller dans LIBS). 

Pour le programmeur, ça apporte un certain confort. Il ne se préoccupe pas de savoir si la bibliothèque qu'il utilise est en ROM ou si elle doit être chargée. Il n'a pas à vérifier si la bibliothèque qu'il utilise possède bien les fonctions dont il a besoin puisque la gestion des version le fait pour lui. Il n'a pas à vérifier si la bibliothèque est déjà chargée. S'il ouvre une bibliothèque qui l'est déjà, l'OS lui retournera le pointeur dont il a besoin et cela ne génèrera aucun problème. Ainsi, si une bibliothèque qui se trouve sur disque est déjà chargée en RAM par une autre application, c'est elle qui sera utilisée. L'OS ne la chargera pas deux fois. A l'inverse l'OS ne libérera la bibliothèque que lorsque toutes les applis qui l'utilisent l'auront fermé. 
C'est pour s'assurer qu'il n'y aura pas de problème lors de l'utilisation conjointe d'une bibliotheque par plusieurs application que Commodore imposait que le code d'une bibliothèque soit réentrant. Parce que n'importe quel codeur pouvait coder sa propre bibliothèque. Aminet en est rempli. 

Je ne connais aucun système analogue sur le TOS. Ni même quelque chose d'approchant. 

Ensuite, il faut pouvoir appeler les fonctions de la bibliothèque. On pourrait le faire de plusieurs façon mais les règles de Commodore imposait l'utilisation d'un adressage indirect avec déplacement. Elles imposaient également l'utilisation du registre A6 comme base. 
Concrètement cela signifie que A6 contient l'adresse qui a été retournée par OpenLibrary() et que l'on accède la façon suivante : 

JSR Offset(A6) 

Offset représente la position de la fonction par rapport au début de la bibliotheque. Par exemple, si une fonction se trouve à 1000 octets du début ça donnera : 

JSR 1000(A6) 

Efficace mais pas très parlant. Donc sur le mig, on ne fait pas comme ça : on utilise des constantes fournies par Commodore. Elle associe un nom de fonction à la valeur de l'offset qui lui correspond. Donc en assembleur un appel de fonction prend la forme suivante (exemple avec une fonction qui converti un caractère en majuscule) : 

Move.l #Code,(D0)        ; On met le code du caractère à convertir dans D0 
JSR ToUpper(A6)           ; On appelle la fonction. D0 contient le caractère converti. 

(Le "ToUpper" est la constante dont je parlais) 

Et c'est terminé. Le code ci-dessus prend 12+18 = 30 cycles. 

Le système est simple, efficace, rapide et très lisible. On jetant juste un oeil sur ce code, on sait exactement ce qu'il fait. 


Comment ça se passe dans le ST ? 

Le système est totalement différent. Il s'appuie sur l'instruction TRAP. Cette instruction prend en parametre un numéro de vecteur. Le 68000 utilise ce numéro pour savoir ou aller chercher l'adresse à laquelle il doit se rendre avant de traiter l'exception. 
Pour appeler une fonction, on met les paramètres sur la pile, on met le numéro de la fonction sur la pile, on fait le trap en utilisant un numéro de vecteur qui correspondra à la librairie que l'on souhaite utiliser et on réaligne la pile. Ca donne ceci : 

Move.l  #X,—(sp)         ; On empile un paramètre  
move.w  #3 ,—(sp)      ; On met le numéro de la fonction sur la pile 
TRAP #13                   ; On déclenche l'exception 
Move.l  (sp)+,D0         ; On recupère le retour dans D0 
addq.l  #2,sp              ; On réaligne la pile 

88 cycles. Mais ce n'est pas tout. Ce système oblige le TOS à faire des choses en plus : dépiler le numéro de fonction, utiliser ce numéro pour récupérer l'adresse de la fonction dans une table (après y avoir appliqué un décalage de 2 bits), appeler la fonction et dépiler le paramètre. Et le RTE que le TOS devra faire est plus couteux que le RTS que fera l'AmigaOS. Ouf ! 
On sera aux alentour de 130-140 cycles de plus que l'AmigaOS ! Et j'ai pris pour exemple une fonction avec un seul paramètre : plus ces derniers sont nombreux, plus l'écart est grand ! 

Donc au final : 
        - Le TOS perdra plein de temps à chaque appel de fonction. 
        - Les fonctions du TOS seront plus longues en taille. (Et pourtant le TOS utilise une ROM plus petite que l'AmigaOS) 
        - Les appels du coté de l'application seront plus long également. 
        - Le code sera beaucoup moins lisible. Car je n'ai jamais vu un système de constante analogue à ce qu'il y a avec le mig. Et 5 lignes sont moins lisibles que 2. 
        - le risque d'erreur sera plus grand. Non seulement il y a plus de code, mais il y a obligation de réaligner la pile. Si c'est mal fait, ça peut ne pas planter du tout, planter tout de suite ou planter bien plus tard. Si, dans l'exemple ci-dessus, le codeur choisi de ne plus récupérer la valeur de retour, il devra supprimer la 4eme ligne et surtout ne pas oublier de remplacer le #2 par #6. 

Je m'arrete là mais je pourrai passer des heures à faire des comparaisons qui seraient totalement défavorable au TOS/GEM...

[babsimov]

Dune PC a de très beaux graphismes et une belle bande son. Mais je lui préfère nettement celle de la version amiga, bien plus atmosphérique à mon gout. Celle-ci avait d'ailleurs eu 20/20 dans le magazine joystick.
Et ça se comprend :)

Mon principal reproche à la version Amiga de Dune, c'est qu'il n'y a que 3 musiques en tout et pour tout, là ou le PC en avait 9. 
Pour que tu comprennes mon point de vue à ce sujet, je vais vite fait résumer l'anecdote. La première fois que j'ai découvert Dune c'était sur PC. Un pote de l'époque (PCiste) venait de "l'avoir" et comme il savait que j'avais lu les livres DUNE et vu le film, voulait que je l'aide à un peu avancer. Moi, pas spécialement intéressé par voir un jeu PC, je lui dis ok, mais pas trop longtemps (le début quoi). Il lance le jeu et là, le choc... j'avais lu que les musiques sur PC était les meilleurs sur Adlib que même les ingénieurs d'Adlib ne pensait pas que c'était possible. Et bien, oui, c'était la première fois que j'était étonné des musiques sur PC. Et, il y en avait un paquet, toutes plus belles les unes que les autres. 
Bref, je suis resté et on a quasiment fini le jeu dans l'après midi (en tout cas, bien avancé). Il y avait un mode de lecture des musiques comme un CD. Je lui ais fait enregister les musiques sur cassette. J'ai ensuite lu un article qui expliquait qu'un CD allait sortir avec les musiques du jeu. Je suis passé chaque week end, pendant plusieurs semaine, au Virgin Megastore à Paris pour le trouver... et cerise sur le gateau, le jour ou je l'ai trouvé, l'équipe du jeu était là et j'ai eu la chance de parler avec eux, notamment de la suite du jeu... Et, même si je n'ai pas compris à l'époque, ils m'avaient décrit dans les grandes lignes, Dune II de Westwood. 
Je me souviens plus si la version Amiga était sortit quand j'ai eu le CD ou pas. En tout cas, comme je trouvais les versions PC des musiques déjà très bien, je me disais que sur Amiga ce serait encore meilleur...
Alors certes, les musiques Amiga ont plus de "coffre", mais il n'y en a que 3 et en plus celle que je préférais n'y étais pas (ornithoptère).

Version Adlib :


Version CD :



Je me suis souvent demandé pourquoi la version Amiga de Dune n'avait pas toutes les musiques de la version PC. Et la réponse qui parait le plus plausible, c'est que pour les jeux, l'Amiga était considéré comme une machine sans disque dur en standard. Le 1200 aurait eu un disque dur en standard, peut être aurait on vu toutes les musiques sur Amiga. 

Petit comparatif :

Intro PC :



Amiga :



Dune intro version CD (sign of the worm)



Ecolove Amiga (il ne semble pas y avoir de version d'écolove sur PC)



Ecolove CD



Freemen PC :



Freemen Amiga :



Freemen CD



Quelques comparaison entre la version Adlib et CD, des musiques qui n'existent pas sur Amiga :

Spice Opera PC



Spice Opera CD



Franchement, la version PC est quand même pas mal !

Wake Up PC :



Wake Up CD :



Water PC



Water CD :



Franchement la bande son adlib, pour l'époque, je la trouve bluffante, elle méritait amplement ses éloges et je regrette qu'on ait pas eu toutes les musiques sur Amiga.

La bande son Adlib complète :
https://www.youtube.com/watch?v=usTwtyjepPo&list=PLB324754A61AB3F1B&index=3

La bande son CD complète :
https://www.youtube.com/watch?v=_wMIMMmWS74&list=PL9DB7EF0D0FEBB95A


Là, je vais poser une question au préservateur de jeux qui est en toi dlfrsilver. J'ai vu que tu avais traduit Eyes of The Beholder I et II sur Amiga, ainsi que Ambermoon.

Existe t il une version AGA de Dune (je pense que c'est une version ECS, même sur AGA). Si cela n'existe pas, est il possible de transformer la version ECS en version AGA avec les graphismes issus du PC... et cerise sur le gateau, pour les compositeurs de mod sur Amiga, d'y intégrer des versions Amiga des musiques manquantes par rapport au PC... Une sorte de Dune version Gold sur Amiga ?
Peut être même demander les sources aux auteurs pour faire ça ?

Que dis tu de cette idée... on peut même demander de l'aide au programmeurs Amiga ici (et tiens un portage sur ST...), après tout, je suis sur que ça pourrais être intéressé des programmeurs ST ça ? 

Rocky007 ?
Stapha92 ?
Seb ?

[dlfrsilver]

Il n'existe pas de version A1200 de Dune à ma connaissance :)

Pour faire une version AGA, celà passe par 2 choses :
1) Désosser le programme de la version Amiga, surement codé en C et ASM. Et passer l'affichage de 5 à 8 bitplans (256 couleurs).
(C'est ce qui a été fait pour les 2 EOB).

2) Créer des outils pour ouvrir les fichiers archives qui composent le jeu et remplacer les graphismes.

A partir de la, une version AGA est possible. Mais ça nécessite un programmeur de talent.

CFOU pour EOB I et II a carrément du comprendre le système de compression utilisé pour chaque type de fichier et développer un compresseur supportant chaque format.

A voir si Philippe Ulrich aurait le code source de dune Amiga pour ce faire :)

Quand à porter Dune sur Atari ST, est-ce que le jeu en vaut la chandelle, le jeu est en 32 ou 64 couleurs sur Amiga (me souvient plus).

Dune Amiga ne possède pas toute les musiques c'est vrai, mais il a les principales, impeccablement répliquées via le tracker Starttrecker d'Exolon of Fairlight :).

Je possède également le CD des musiques, que j'ai aussi offert à mon beau-frère qui adore Dune comme moi :)

[Invité]

bon courage pour les musiques de dune.  ya que stephane picq qui peut faire du stephane picq ! (pour les curieux ; rippez les mods de la version amiga et regardez comment les instrus sont balladés d'une piste a l'autre... j'ai jamais rien vu de similaire.. completement dingue la facon dont il a fait ces. mods).

[dlfrsilver]

il a utilisé Startrekker, qui est un excellent tracker.

Par ailleurs, comme l'amiga joue des samples, la ou le ST ne fait que du pilotage midi, j'explique :

. Un ST peut faire jouer un morceau via le midi à un synthétyseur.

L'amiga peut non seulement le faire jouer, mais mieux, il peut enregistrer sur disque dur chaque sample correspondant à chaque touche du clavier et ou synthétyseur. Ce qui veut dire que l'amiga peut répliquer le morceau entier tel qu'on pourrait l'écouter avec le synthé, la ou le ST ne ferait que blip blip bloupe bloupe.

Problème sur l'amiga, la RAM que tout ça prend (sample+partoche en 4 voix). Chaque morceau eniter fait décompressé 190ko.

Dune Amiga était bien sur installable sur Disque dur, donc pas de souci à ce niveau :)

Je connais un mec sur Amiga qui sait très bien convertir les musique midi en format MOD :)

[babsimov]

Babsimov,

Tu avais raison : je voulais dire qu'un OS monotache est "moins" risqué. J'ai édité mon post.

Pour ta question sur la difficulté à tirer parti du mig : non, ce n'est pas du tout aussi difficile que le XL. C'est même assez facile en fait.

Tu me posais des questions sur mon ressenti sur les 2 machines. 

J'ai eu un ST puis un mig. Et j'ai REELLEMENT utilisé les 2. Connais-tu quelqu'un qui l'ai fait et qui ait préféré le ST ? Je veux dire, en dehors de ce forum ? Personne ? C'est bien ce que je pensais... 

Je n'ai pas connu beaucoup de personnes dans ce cas, mais c'est vrai que ceux que j'ai connu qui venaient du ST vers l'Amiga, ne sont pas retournés sur ST. 

Et quand tu as codé en tatant du TOS et de l'AmigaOS, tu ne regrettais pas le premier. Vraiment pas. Car c'est le jour et la nuit. 
Je parle de coder : 
        - Sérieusement. Pas de jouer avec le GFA. Non pas que ce soit criticable, mais ce dernier cache au codeurs les appels aux fonctions du TOS. Tout juste peut-il se rendre compte que le GFA sur mig était plus rapide... 
        - Des applis pour l'OS. Un codeur de démo ou de jeux en n'avait rien à faire que le TOS soit si mal foutu : il ne l'utilisait (presque) pas. 
        
Je te le dis : ceux qui expliquent le contraire mentent. 

Donc j'ai eu les 2. Et tu sais quoi ? J'ai eu plus de bombes que de Guru meditation. Largement plus... Cela veut-il dire que le TOS/GEM est moins fiable ? Pas forcément : j'ai beau être un fan-boy Amiga, je n'oublie pas que j'ai eu le ST AVANT le mig. Donc j'ai bénéficié d'un AmigaOS plus ancien que le TOS.

Tu accrédites donc le fait que les premières version du TOS/GEM étaient tout aussi "peu fiables" que les premières versions de l'AmigaOS ? 
A propos, en quelle année as tu eut ton Amiga et quel modèle ? Je suis aussi curieux de connaitre ta configuration, disque dur ? Ram ? Carte accélératrice ?

Parlons du livre cité par Rocky, l'auteur parle de bugs et donne deux exemples : 
        - Une division par 0 
        - Un manque de mémoire. Il s'agissait du Guru le plus courant : un programme demande une zone mémoire. L'OS lui renvoit la valeur NULL car il n'y a plus assez de mémoire dans la machine (donc la demande de mémoire est refusée) et le programme, au lieu de vérifier qu'il n'a pas reçu la valeur NULL va essayer d'exploiter l'adresse reçue. 
Dans les 2 cas, ça n'a rien à voir avec le multitache et ça peut tout aussi bien se produire avec n'importe quel OS...

Ce qui est bien avec tes réponses, c'est que tu as les arguments techniques qui font souvent défauts au non programmeurs comme moi, quand on en arrive à parler de ce genre de bugs.

L'auteur parle de la programmation événementielle qui était une nouveauté (sur les machine personnels). Je me souviens avoir expliqué avoir découvert ça sur le mig quand je disais que coder dessus était bien plus interessant que coder sur ST. Et ça m'a été utile : aujourd'hui toutes les applis font de l'événementiel...

La programmation événementielle, je ne connais que de nom. J'ai fait une petite recherche :
https://fr.wikipedia.org/wiki/Programmation_%C3%A9v%C3%A9nementielle

Ce que je retiens de ce que tu dis, c'est que, comme je le soutiens depuis le début, l'Amiga a permis à beaucoup "d'entrevoir" ce que serait l'avenir l'informatique.

Ta remarque sur la programmation m'amène à te poser une autre question. Je ne sais pas si tu as suivi le débat sur les propos de l'auteur de DirectX qui disait s'être inspiré de l'Amiga pour concevoir DirectX ?
J'étais venu donner cette information ici, ce qui a relancé le débat sur l'AmigaOS. 
Que peut tu dire du parallèle entre DirectX et l'AmigaOS (surtout époque Windows 95, je pense que de nos jours DirectX est bien différent).
Tu trouveras les propos de l'auteur de DirectX ici (vers le milieu de la page) :
http://blog.a-eon.biz/blog/?p=7873

Idem quand tu expliques à Rocky que c'était plus ergonomique de ne pas être obligé de saisir sa souris pour cliquer sur OK quand tu insérais la disquette demandée. Il t'a répondu qu'il suffisait de quelques lignes de code en C pour faire pareil. 
Sauf que quand tu appelles la fonction du GEM qui affiche une boite de dialogue pour confirmer ou annuler, ton programme n'a plus la main tant que l'utilisateur n'a pas fait l'un des 2 choix ! Donc ça : 

et comme déjà dit, rien n'empêchant le codeur de faire d'ajouter ses 10 lignes de C dans son logiciel pour faire la detection automatique.  
plein de jeux Atari detectait tout seul le changement de disquettes.

C'est faux. Le seul moyen pour le codeur est de gérer lui même la boite de dialogue entièrement : c'est un plus long que 10 lignes de code en C... 
L'autre solution serait l'ouverture d'une fenêtre modale. C'est à dire une fenêtre autonome qui ne bloque pas l'appelant. Mais ce n'est possible qu'avec du multitache. Donc interdit au ST... 
Et oui, le multitache sert aussi à faire des applis MDI. Ce qui apporte un plus en terme d'ergonomie.

Je suis content que tu confirmes mes propos pour ce point d'ergonomie de l'Amiga. 
Comme je ne connais pas la programmation ou le fonctionnement interne du TOS ou AmigaOS, j'ignorais qu'en absence de multitâche ce n'est pas possible sur ST... 
Mais Rocky007 nous a habitué à dire que tout était possible sur ST :) 

Un jeu par contre, ne passe pas par le GEM pour demander une confirmation à l'utilisateur : c'est pour ça que des jeux pouvait le faire. Mais sortir cet exemple dans une discussion sur les limites du TOS/GEM. Hmmm....

Oui, j'avais plus ou moins fait remarquer ça qu'un jeu ça n'avait pas trop de rapport avec TOS/GEM.

Sur l'Autorun dont tu parlais : il n'y a pas que le programme lancé automatiquement. il y a aussi l'icone. Quand tu met un CD dans un micro d'aujourd'hui, c'est un icone peronnalisé qui apparait. Et c'est comme ça depuis 1995 sous windows. Ou 1985 sous AmigaOS...

C'est tout à fait exact pour l'icone aussi (et en plus animée (deux états), pas juste un fond de couleur en plus quand elle est sélectionnée)

Revenons sur le débat TOS/AmigaOS :

Il y a de grandes discussion ici sur le TOS et l'AmigaOS. 
Mais elles s'arretent sur l'aspect visible de ces OS. Et comme pour un iceberg, ça ne représente qu'une toute petite portion de l'OS. Et ce n'est pas la plus importante. 
Le plus important, ce sont les API de l'OS. Ce sont elles qui permettent à toutes les applications de tourner dessus.
Les API sont des ensembles de fonction qui permettent d'effectuer un certains nombre d'actions. Elle permettent, entre autres : 
        - D'éviter d'avoir à réinventer la roue à chaque écriture de logiciel. Pour cela elles doivent être le plus complete possible. Et le TOS est loin derrière le mig à ce niveau. 
        - D'utiliser le hardware sans être obligé de le manipuler directement. 
        - D'avoir des applications qui disposent du même look & feel. 

Un logiciel quel qu'il soit (on écarte les démos et les jeux de cette explication) passe une bonne partie de son temps à appeler ces fonctions de l'OS. 

Comment appeler une fonction de l'OS dans le mig ? 

Les fonctions sont regroupées dans des bibliothèques. Avant de pouvoir utiliser une fonction, il faut "ouvrir" la bibliothèques qui la contient. Bien sur, un programme ne le fait qu'une seule fois. Le plus souvent pendant son initialisation. 

Ouvrir une bibliothèque permet, entre autres, de savoir ou elle se trouve. C'est bien sur une obligation pour pouvoir l'utiliser ! 
Comment fait-on ? C'est simple : on utilise la fonction OpenLibrary de la bibliothèque EXEC. Mais comment ouvrir EXEC alors ?!!! 
Pas besoin : EXEC est la seule bibliotheque qui soit toujours ouverte. Et son adresse est fixe. C'est la seule qui soit dans ce cas dans tout l'AmigaOS. Ce qui apporte de la souplesse et permet de conserver une compatibilité totale si des bibliothèque sont modifiée. 

Exemple, on trouve en ROM une bibliothèque A et juste après une bibliotheque B. On améliore l'OS et on ajoute des fonction à la bibliothèque A. Du coup la bibliothèque B ne sera plus au même endroit. Avec le système de l'AmigaOS, ça ne posera pas de problème. Y compris pour EXEC : comme c'est la première des bibliothèques en ROM, elle se trouvera toujours au même endroit. 

Evidemment, rien n'empeche le codeur "maladroit" d'appeler une fonction de l'OS directement sans utiliser le système d'ouverture. Après tout, il sait bien ou se trouvent les fonctions dont il a besoin. Pourquoi s'embeter à respecter les recommandation de Commodore ? 
C'est ce que faisait souvent les jeux du début (Juste par flemme...). Et c'est pourquoi ils rencontreront des problèmes de compatibilité avec les versions ultérieures de l'AmigaOS. 

Alors : comment fonctionne OpenLibrary ? 

On lui donne le nom et la version de la bibliothèque que l'on souhaite utiliser et elle renvoit un pointeur qui contient l'adresse de base de la bibliothèque. Si elle ne la trouve pas dans la ROM, elle recherche dans le répertoire LIBS et si elle la trouve, la charge en mémoire. Elle vérifie que le numéro de version de la bibliothèque trouvée est supérieur ou égal au numéro de version que l'on a envoyé en paramètre. Si elle ne trouve pas la bibliothèque ou si celle qu'elle a trouvé n'a pas le bon numéro de version, elle renvoit null. 
On donne le nom de la bibliothèque en clair. On peut donc avoir un nombre énorme de bibliothèque différente. 
On peut même indiquer un chemin complet pour le nom de la bibliothèque et l'AmigaOS ira directement voir à cet endroit pour la charger (au lieu d'aller dans LIBS). 

Pour le programmeur, ça apporte un certain confort. Il ne se préoccupe pas de savoir si la bibliothèque qu'il utilise est en ROM ou si elle doit être chargée. Il n'a pas à vérifier si la bibliothèque qu'il utilise possède bien les fonctions dont il a besoin puisque la gestion des version le fait pour lui. Il n'a pas à vérifier si la bibliothèque est déjà chargée. S'il ouvre une bibliothèque qui l'est déjà, l'OS lui retournera le pointeur dont il a besoin et cela ne génèrera aucun problème. Ainsi, si une bibliothèque qui se trouve sur disque est déjà chargée en RAM par une autre application, c'est elle qui sera utilisée. L'OS ne la chargera pas deux fois. A l'inverse l'OS ne libérera la bibliothèque que lorsque toutes les applis qui l'utilisent l'auront fermé. 
C'est pour s'assurer qu'il n'y aura pas de problème lors de l'utilisation conjointe d'une bibliotheque par plusieurs application que Commodore imposait que le code d'une bibliothèque soit réentrant. Parce que n'importe quel codeur pouvait coder sa propre bibliothèque. Aminet en est rempli. 

Je ne connais aucun système analogue sur le TOS. Ni même quelque chose d'approchant. 

Ensuite, il faut pouvoir appeler les fonctions de la bibliothèque. On pourrait le faire de plusieurs façon mais les règles de Commodore imposait l'utilisation d'un adressage indirect avec déplacement. Elles imposaient également l'utilisation du registre A6 comme base. 
Concrètement cela signifie que A6 contient l'adresse qui a été retournée par OpenLibrary() et que l'on accède la façon suivante : 

JSR Offset(A6) 

Offset représente la position de la fonction par rapport au début de la bibliotheque. Par exemple, si une fonction se trouve à 1000 octets du début ça donnera : 

JSR 1000(A6) 

Efficace mais pas très parlant. Donc sur le mig, on ne fait pas comme ça : on utilise des constantes fournies par Commodore. Elle associe un nom de fonction à la valeur de l'offset qui lui correspond. Donc en assembleur un appel de fonction prend la forme suivante (exemple avec une fonction qui converti un caractère en majuscule) : 

Move.l #Code,(D0)        ; On met le code du caractère à convertir dans D0 
JSR ToUpper(A6)           ; On appelle la fonction. D0 contient le caractère converti. 

(Le "ToUpper" est la constante dont je parlais) 

Et c'est terminé. Le code ci-dessus prend 12+18 = 30 cycles. 

Le système est simple, efficace, rapide et très lisible. On jetant juste un oeil sur ce code, on sait exactement ce qu'il fait. 


Comment ça se passe dans le ST ? 

Le système est totalement différent. Il s'appuie sur l'instruction TRAP. Cette instruction prend en parametre un numéro de vecteur. Le 68000 utilise ce numéro pour savoir ou aller chercher l'adresse à laquelle il doit se rendre avant de traiter l'exception. 
Pour appeler une fonction, on met les paramètres sur la pile, on met le numéro de la fonction sur la pile, on fait le trap en utilisant un numéro de vecteur qui correspondra à la librairie que l'on souhaite utiliser et on réaligne la pile. Ca donne ceci : 

Move.l  #X,—(sp)         ; On empile un paramètre  
move.w  #3 ,—(sp)      ; On met le numéro de la fonction sur la pile 
TRAP #13                   ; On déclenche l'exception 
Move.l  (sp)+,D0         ; On recupère le retour dans D0 
addq.l  #2,sp              ; On réaligne la pile 

88 cycles. Mais ce n'est pas tout. Ce système oblige le TOS à faire des choses en plus : dépiler le numéro de fonction, utiliser ce numéro pour récupérer l'adresse de la fonction dans une table (après y avoir appliqué un décalage de 2 bits), appeler la fonction et dépiler le paramètre. Et le RTE que le TOS devra faire est plus couteux que le RTS que fera l'AmigaOS. Ouf ! 
On sera aux alentour de 130-140 cycles de plus que l'AmigaOS ! Et j'ai pris pour exemple une fonction avec un seul paramètre : plus ces derniers sont nombreux, plus l'écart est grand ! 

Donc au final : 
        - Le TOS perdra plein de temps à chaque appel de fonction. 
        - Les fonctions du TOS seront plus longues en taille. (Et pourtant le TOS utilise une ROM plus petite que l'AmigaOS) 
        - Les appels du coté de l'application seront plus long également. 
        - Le code sera beaucoup moins lisible. Car je n'ai jamais vu un système de constante analogue à ce qu'il y a avec le mig. Et 5 lignes sont moins lisibles que 2. 
        - le risque d'erreur sera plus grand. Non seulement il y a plus de code, mais il y a obligation de réaligner la pile. Si c'est mal fait, ça peut ne pas planter du tout, planter tout de suite ou planter bien plus tard. Si, dans l'exemple ci-dessus, le codeur choisi de ne plus récupérer la valeur de retour, il devra supprimer la 4eme ligne et surtout ne pas oublier de remplacer le #2 par #6. 

Je m'arrete là mais je pourrai passer des heures à faire des comparaisons qui seraient totalement défavorable au TOS/GEM...

Comme toujours, dès que tu approfondis dans la technique, on comprends la différence entre les deux machines et OS. Il va quand même falloir que je fasse une seconde lecture, mais déjà à la première j'ai compris l'essentiel.

[Invité]

en parlant de ca dlfrsilver tu arriverais a gratouiller dans "extase" et sortir les mods de tous les levels ? il sont plus ou moins altérés par ce qui se passe en jeu du coup c'est un peu chaud a ripper (ca doit muter des pistes et lancer des one-shot a gogo.. j'arrive a chopper les sons mais pas les. mods)

[babsimov]

Il n'existe pas de version A1200 de Dune à ma connaissance :)

Pour faire une version AGA, celà passe par 2 choses :
1) Désosser le programme de la version Amiga, surement codé en C et ASM. Et passer l'affichage de 5 à 8 bitplans (256 couleurs).
(C'est ce qui a été fait pour les 2 EOB).

2) Créer des outils pour ouvrir les fichiers archives qui composent le jeu et remplacer les graphismes.

A partir de la, une version AGA est possible. Mais ça nécessite un programmeur de talent.

CFOU pour EOB I et II a carrément du comprendre le système de compression utilisé pour chaque type de fichier et développer un compresseur supportant chaque format.

A voir si Philippe Ulrich aurait le code source de dune Amiga pour ce faire :)

Quand à porter Dune sur Atari ST, est-ce que le jeu en vaut la chandelle, le jeu est en 32 ou 64 couleurs sur Amiga (me souvient plus).

Dune Amiga ne possède pas toute les musiques c'est vrai, mais il a les principales, impeccablement répliquées via le tracker Starttrecker d'Exolon of Fairlight :).

Des programmeurs de talents, nous en avons croisés dans ce sujet (demomaker, expert OS, programmeur de jeu). Peut être que certains pourraient être intéressés ?

A moins que quelqu'un ait un contact avec Philippe Ulrich pour le code source ?

Pour une version AGA, serait il possible avec le copper d'avoir encore plus de couleurs que sur la version PC (notamment pour les dégradé dans le désert ?)

Les musiques, il y a eu une version MT32 (qui est midi je crois), peut être est ce possible de les convertir. Sinon il y a encore des musiciens de talent sur Amiga (Gibbs d'Amiga Impact me vient à l'esprit). Ses remix sont de grande qualité, peut être pourrait il faire une version Startrecker des musiques PC ?

Autrement, il reste à demander à Stephane Picq s'il ne serait pas intéressé par ce défit, pour le fun ? Tiens pour les 30 ans de l'Amiga, une sorte d'hommage à l'Amiga ?

Au sujet des musiques, pour ma part, ce que tu appel les musiques principale pour la version Amiga, ce n'était pas mes préférés la version PC... et la cassette en question je l'ai écouté suffisamment en attendant la version Amiga et le CD pour être très déçu de ne pas avoir des version Amiga de toutes les musiques qui m'avait enchantées dans la version PC. 

Dune Amiga était bien sur installable sur Disque dur, donc pas de souci à ce niveau :)

Le problème n'était pas qu'il soit installable sur disque dur (je le sais, c'est ce que j'avais fait), mais qu'il DEVAIT être jouable sans, à partir des disquettes. Donc, pour éviter trop de changement de disquettes, je penses qu'il a fallu réduire le nombre de musiques au minimum. 
Une version Amiga pensée UNIQUEMENT pour être jouée depuis un disque dur aurait, à mon avis, eu le même nombre de musiques que sur PC.

Je connais un mec sur Amiga qui sait très bien convertir les musique midi en format MOD :)

Donc, tout est possible, allez après Ambermoon, une version AGA de DUNE ?
Et même, pourquoi pas, après, une version CD32 basée sur la version PC CD du jeux ?

Est ce même envisageable de remplacer les mod Amiga du jeu, par des versions basés sur des samples issus de la version CD de la bande son (celle du CD EXXOS je veux dire, pas la version PC CD)?

Je possède également le CD des musiques, que j'ai aussi offert à mon beau-frère qui adore Dune comme moi :)

Il faut dire que ce jeu était à la hauteur des livres, culte.

[babsimov]

La demande de Kaot, me fait penser que le mod de la musique en jeu de Transarctica m'intéresserait.

A l'époque j'avais essayé de ripper ça, mais pas réussi.

Celle-ci :



Elle dure plus longtemps que ça dans mon souvenir.

As tu la possiblité de me la ripper en mod ?

PS : je réalise que je te demande surement trop. Met ça sur le compte de la passion, mais c'est vrai que le mod Transarctica (la musique en jeu) je ne l'ais pas encore trouvé. On arrive à trouver l'intro, mais celle là, elle me plait pas. Ca me rappel pas trop le jeu, j'ai bien plus entendu la musique en jeu que l'intro dans mes parties.

[dlfrsilver]

tout sur le format de fichiers de dune pour PC ici :

http://bigs.fr/dune_old/

la plupart des fichiers de la version amiga se décompressent bien avec UNHSQ.exe ; cependant, les fichiers graphiques ne semblent pas encodés de la même manière.

[dlfrsilver]

en parlant de ca dlfrsilver tu arriverais a gratouiller dans "extase" et sortir les mods de tous les levels ? il sont plus ou moins altérés par ce qui se passe en jeu du coup c'est un peu chaud a ripper (ca doit muter des pistes et lancer des one-shot a gogo.. j'arrive a chopper les sons mais pas les. mods)

C'est normal que tu n'arrives pas à chopper la musique, ce n'est pas un fichier mod, mais de la musique interactive.

regarde ici :

http://www.exotica.org.uk/wiki/Extase

Le morceau y est, mais il faut deliplayer pour le lire.

Transarctica c'est pareil, c'est un module custom crée par Michel Pernot (le frère de Jean-Pierre ! Nan c'est une blague, je rigole)

Comme ce n'est pas un fichier mod, impossible de le gauler, Les jeux silmarils sont des "bytes_interpreters", et c'est ardu de récupérer les fichiers en question.

[rocky007]

C'est faux. Le seul moyen pour le codeur est de gérer lui même la boite de dialogue entièrement : c'est un plus long que 10 lignes de code en C...

effectivement si on utilise une boîte d'alerte GEM, on ne sait pas en sortir, par contre rien n'empêche d'ouvrir une fenêtre et y afficher un message de changement de disque.  quand je parlais de 10 lignes, c'était par exemple dans le cas d'un jeu ou d'un installateur sur disque dur. 


concernant le multitâche sur 800 XL, en effet, mea culpa, l'OS n'est pas en version définitive, mais toujours en développement.

( http://atari8.co.uk/gui/ )



beaucoup de choses à lire intéressantes ( et de stapha92   ).. et oui je ne connais strictement rien en hardware/coding XL, donc désolé si je ne fais que glaner sur internet des infos où je peux, vu que la bibliothèque du coin n'a probablement pas de livre sur le 800 XL.  Pour le displaylist par exemple, pour ce que j'en pu en lire, cela me semblait pourtant très similaire au copper : un copro indépendant du 6502 qui exécutait un script synchro sur l'affichage vidéo.  alors oui, c'est surement pas aussi puissant, mais le concept me semble qd même très similaire non ?

[barbarian_bros]

Pour les musiques de Dune, même la version MT-32 (pourtant très bonne), a un moins bon rendu que la version AdLib (et soundblaster, la SB étant à la base un clone d'AdLib).
C'est valable aussi pour KGB/Conspiracy, l'autre jeu d'aventure de Cryo qui utilise le même moteur et une interface quasi-similaire (d'ailleurs dans le générique du jeu une version CD de la musique est annoncée, comme pour Dune, mais il me semble qu'elle n'est jamais sortie).

En fait Stéphane Picq a composé les musiques AdLib ' de Dune et de KGB en utilisant le moteur sonore 'HERAN System', créé par Remi Herbulot (programmeur de chez Cryo) en collaboration avec les ingénieurs de chez AdLib.
Le Heran System  repousse les capacités de synthèse FM plus loin que ce que les responsables de chez AdLib croyait possible sur leur puce sonore.

[stapha92]

85-88 : ATARI WINNER FINGER IN THE NOZE

Hmmm... ah bon ? Et pourquoi donc ? Voyons voyons... 

Bureautique : Avec son écran monochromme, le ST a l'avantage. 
Midi : Les logiciels Midi sont adaptés sur le mig. Mais avec retard et pas tous... ST devant 

Pour ces 2 domaines, Atari gagnant si on achète un périphérique couteux avec son ST (imprimante ou expandeur midi) et qu'on est pret à se contenter d'un moniteur noir et blanc (ou a acheter 2 moniteurs et un switch). 

Continuons : 

Jeux : les meilleurs jeux sont déjà sur Amiga (alors qu'il ne l'exploitent pas encore...) et, techniquement, le ST ne peux pas suivre. 

Dessin : On a photon paint, digi paint, deluxe paint, etc... Des logiciels qui n'existent pas sur ST ou qui y existent sous forme d'erzast. De toute façon, le ST est trop largué pour pouvoir offrir quelque chose d'approchant... 

Musique : Les trackers à base de samples naissent sur le mig. Le ST ne peut pas suivre. Ses trackers sont incapables de reproduire tous les effets d'un mod créé sur le mig à cause du hardware bien trop largué par celui du mig... 

Animation :  Aegis Animator, Lights!Camera!Action!, DeLuxe Video, Disney Animation Studio, etc... : le ST est bien trop limité sur ce point... 

Modelisation 3D :  Sculpt 3D, TurboSilver, Videoscape 3D, Caligari, Imagine, Real 3D, Etc... : Les meilleurs logiciels sont sur Amiga. Les capacités graphiques du ST sont trop dépassées par celles du mig... 

Programmation : La programmation sur mig est plus moderne (événementielle, gestion de messages, Arexx, scripts...), plus agréable (API du TOS incomparable avec celle de l'AmigaOS), plus diversifiée (présence de coprocesseurs, et d'un chipset plus souple et performant). Il dispose de CygnusEd (éditeur dédié au coding et inégalé sur ST), de compilateur C gratuits (domaine public) et de AMOS (La version Amiga explose littéralementde STOS et a d'ailleurs beaucoup évolué et reçu une flopée d'extensions) et même du GFA (avec 2 mois de retard mais plus de possibilités grace à l'OS) 

CAO :  X-CAD, IntelliCAD, IntroCAD, MaxonCAD, ElektroCAD. Rien à envier au ST. Encore une fois, la haute résolution en 16 couleur est un plus. 

Dans ces domaines, le ST est déjà largué pendant cette période. Et il s'agit de choses qui se font sans être obligé d'investir dans un périphérique... 

89-92 : ATARI WINNER POUR LA BUREAUTIQUE/PRO/PROG/ULILITAIRES et AMIGA WINNER POUR LE JEU

Bureautique : Les logiciels de bureautique débarquent en nombre sur le Mig. Les écrans VGA baissent. Le mig a accès à des résolutions biens supérieures à celles du ST. 
                          Le premier traitement de texte a pouvoir intégrer des images 24 bits dans un document sort sur mig (WordWorth) 

Midi : Pro24 est disponible. Cubase ne l'est pas mais Bar & Pipes débarque. Son système de module est tellement révolutionnaire (et utilise abondamment le multitache) que Microsoft a racheté l'éditeur du logiciel pour reprendre sa technologie dans DirectSound... 

Pour le reste, l'avantage que le mig possédait déjà s'est creusé. 

Et pourquoi s'arreter en 92 ? Le ST avait peut-être disparu, mais ce n'était pas le cas du mig. 
Rien qu'au niveau des jeux : plus de 1 000 jeux sortiront sur le mig à partir de 1993... 

Et comme pour moi la grande epoque 16/32bit c'etait 86-89... tous les titres revolutionnaires sont sortis sur cette période, et franchement y a eu essoufflement des 1990 dans la qualité des programmes... ATARI l'emporte donc HAUT LA MAIN dans cette guerre.

Donc Vroom (1991) et Lotus 2 (1991) sont de moins bonne qualité que Buggy boy ? 
Même sur ST, ce que tu dis est complètement faux : les meilleurs jeux du ST sont sortis pendant cette période que tu prétend déclinante... 

Et sur Amiga, c'est encore pire : 1990 c'est le début de l'age d'or pour les jeux

[babsimov]

tout sur le format de fichiers de dune pour PC ici :

http://bigs.fr/dune_old/

la plupart des fichiers de la version amiga se décompressent bien avec UNHSQ.exe ; cependant, les fichiers graphiques ne semblent pas encodés de la même manière.

Est ce à dire que tu as déjà commencé le portage de DUNE en AGA :)

Ca ce serait cool. 

J'espère que cette idée lancée un peu comme ça, pourra se concrétiser.

[babsimov]

Stapha92, je me suis souvenu d'une de tes réponses récentes qui m'avait amené une nouvelle série de questions. Ca fait quelques pages déjà. Je pense que ces questions ont été diluées dans le flot de toutes celles que je t'ai déjà posé. Cela concernait ta version de ce qu'aurait du être l'AGA.

Je vais donc me permettre de remettre ta réponse d'origine, ainsi que les questions que celle ci avait entrainé de ma part, en espérant que tu trouveras un peu de temps pour y répondre. 
J'espère que tu ne m'en voudras pas pour cette démarche un peu "cavalière".

Tu avais écrit :

Il y a eu beaucoup de spéculations sur ce qu'aurait du être le A1200 : chunky pixel, DSP, j'en passe et des meilleurs. 

Je ne suis pas d'accord avec tout ça : ce qu'il fallait, dans l'idéal, c'est une fréquence doublée pour le chipset et un passage en 32 bits pour tous les copro. Le blitter aurait été 4 fois plus performant ()alors qu'en 256 couleurs on n'a besoin de ne déplacer "que" le double de données). Idem pour le copper (sa résolution aurait de 2 pixels au lieu de 8). Idem pour Paula (ça aurait permit 8 canaux en 16 bits ou 16 en 8 bits). Il aurait également fallu que l'entrée de gamme pour le processeur soit au moins un 68020 à 28 Mhz. 

Un A1200 avec tout ça (Meme pour un prix plus élevé : le A1200 était vendu moins cher que le A500 à sa sortie...) aurait eu beaucoup plus de chance.

Et je t'avais répondu ceci, avec plusieurs questions à l'intérieur :

Babsimov
Moi aussi, comme tu as du le lire parfois ici, j'ai beaucoup réfléchit à ce qu'aurait du être le 1200. Bien entendu ce que tu dit n'est pas faux, mais tu es sur que le simple fait d'avoir doublé la fréquence du chipset aurait permis de compenser l'abscence de Chunky (notamment pour les jeux de type Wolfenstein qui se démocratisait à l'époque ?) ou les jeux 3D texturé en général ? 
Un Paula à fréquence double aurait pu jouer 8 canaux 16 bits (alors que dans l'électronique interne il n'y avait que 4 canaux ? Ca n'aurait pas demandé un peu de puissance processeur ?
J'ai souvenir que jouer 8 canaux avec Octamed était réputé pour consommer un peu plus de processeur (j'ignore combien) que 4 canaux (ce qui ne consommait rien). Mais 8 canaux avec Paula la qualité du son était moindre si je me souviens bien. C'est pour ça que je me pose la question avec un Paula à fréquence doublé (mais à l'électronique inchangée), on aurait vraiment pu avoir 8 voies 16 bits ?

En tout cas, pour le 68020 à 28 mhz, c'était ce que j'avais avec ma carte accélératrice (avec 4MO de fast) et jusqu'en 95/96 c'était largement suffisant pour un usage courant. Je peux t'assurer que le jour ou j'ai mis cette carte dans le 1200, dès le boot j'ai vu la différence. J'ai tout suite su que j'avais bien fait de prendre une carte accélératrice.

La configuration idéale que tu propose pour le 1200 me convient, j'y ajouterai juste un mode chunky et un DSP (même optionnel).

[babsimov]

dlfrsilver

Transarctica c'est pareil, c'est un module custom crée par Michel Pernot (le frère de Jean-Pierre !  Nan c'est une blague, je rigole)

Comme ce n'est pas un fichier mod, impossible de le gauler, Les jeux silmarils sont des "bytes_interpreters", et c'est ardu de récupérer les fichiers en question.

Si c'est trop compliqué, c'est pas grave, t'embête pas. 
Cependant, si, un jour ça "t'amuse" d'essayer et que tu as du temps, je suis intéressé par le mod.

[dlfrsilver]

tout sur le format de fichiers de dune pour PC ici :

http://bigs.fr/dune_old/

la plupart des fichiers de la version amiga se décompressent bien avec UNHSQ.exe ; cependant, les fichiers graphiques ne semblent pas encodés de la même manière.

Est ce à dire que tu as déjà commencé le portage de DUNE en AGA :)

Ca ce serait cool. 

J'espère que cette idée lancée un peu comme ça, pourra se concrétiser.

Il manque un programmeur..... un vrai avec de large épaules.....

Je n'ai rien commencé du tout, les graphismes PC ne sont pas encodés comme ceux de l'amiga déjà.

Pas un projet simple

[babsimov]

tout sur le format de fichiers de dune pour PC ici :

http://bigs.fr/dune_old/

la plupart des fichiers de la version amiga se décompressent bien avec UNHSQ.exe ; cependant, les fichiers graphiques ne semblent pas encodés de la même manière.

Est ce à dire que tu as déjà commencé le portage de DUNE en AGA :)

Ca ce serait cool. 

J'espère que cette idée lancée un peu comme ça, pourra se concrétiser.

Il manque un programmeur..... un vrai avec de large épaules.....

Je n'ai rien commencé du tout, les graphismes PC ne sont pas encodés comme ceux de l'amiga déjà.

Pas un projet simple

Y aurais pas un programmeur Amiga avec de larges épaules ici ? :)

Tant qu'à faire, ne pas oublier d'ajouter des versions Amiga des musiques PC qui ne sont pas sur Amiga. Et tant qu'à faire, à implémenter la lecture en mode CD, comme sur PC :)

En faite faire ce qui aurait du être fait à l'époque en somme :)

Quoi je suis exigeant ? c'est que Dune ce fut un véritable choc pour moi à l'époque, un jeu CULTE.

Il semble qu'il y ait une tentative en cours pour une réécriture du jeu en open source :
http://sourceforge.net/projects/dunerevival/?source=typ_redirect

[stapha92]

- Sundog
- Mortevieille Manoir
- L'Arche du Capitaine Blood
- Dungeon Master
- Larry, Space Quest, etc....
- Super Sprint
- Carrier Command
- Kick Off
- Starglider 2
- Buggy Boy
- GFA Basic 2
- et tous le sutilitaires pour la PAO, texte, calcul

tout ca souvent en priorité sur ST.

en 1990 le PC arrivait en force
en 1990 la Megadrive écrasait l'Amiga, les consoles avaient repris le dessus

L'Amiga n'avait alors que qq restes.... pour ceux qui etaient resté au CPC6128 auparavant....

Et ben le Doc, c'est ça ta liste de jeux géniaux ? Tu es sur que tu es du coté du ST ? Parce que là tu es en train de le descendre sacrément ! 

Mortevieille Manoir : ouais, impressionnant au début. Barbant une fois l'effet de surprise passé. Surtout que ce cheveux sur la langue à la longue...
L'arche du capitaine blood : C'est quoi ce truc ? Je l'avais essayé sur les conseils des magazines. Ils parlaient de la sequence d'atterissage soi disant bluffante et des "discussions" avec les aliens. Bof...
Et Super sprint qui ne vaut pas un super off-road sur ST.
Ou ces jeux d'aventures au graphisme 8 bits.
Ou ces jeux 3D qui se mettent à ramer dès qu'il y a plus de 3 pixels à afficher.
Buggy boy est pas mal. Sans plus. Je préfère 100 fois un vroom ou un Lotus sur le ST..

Dungeon Master et Kick off : Ouf ! 2 bons jeux dans ta liste !

Et Kick-off sur le mig possède un gazon qui n'est pas uni, les vrais marquages avec le rond central et les arrondis de la surface de réparation, des filets dans les buts, les panneaux publicitaires... En fait, le mig affiche un vrai terrain là ou le ST se contente de tracer des lignes droites... En plus le son est meilleur sur le mig, comme dungeon master...

Tiens une liste de la même période et de la même taille que la tienne sur Amiga : 
- pacmania 
- marble madness 
- Zany Golf 
- Hybris 
- Silkworm 
- Shadow of the beast 
- Battle Squadron 
- It came from the desert 
- Ballistix 
- Menace 

Certains sont inexistants sur ST, d'autres existent mais dans des versions à oublier face aux versions mig...

Le PC arrive en force en 90 ? Pourquoi ? Parce que ça coutait une fortune ? Parce que ça se faisait exploser par le mig sur tous les plans ? Ou parce qu'ils tournaient sous DOS/Windows ?
Ton calendrier avance de 5 ans...

Quand à la mégadrive : elle écrasait les ST ports du début, mais le mig était passé à autre chose...

[stapha92]

dlfrsilver, 

Le GFA Basic est un bon langage. Son éditeur n'est pas terrible, c'est vrai, mais ce n'est pas le plus important. 
Il y avait sur le mig un Pascal qui n'était pas cher et qui générait des exe presque aussi rapides que du C. 
Le GFA en est loin mais il faut se souvenir de l'époque : beaucoup d'utilisateur du ST ou du Mig viennent du 8 bits et sont assez réfractaire à l'idée d'apprendre un nouveau langage (même si le Pascal est facile). Alors que la grande majorité avait appris le BASIC sur leur 8 bits. 
Donc quand arrive un Basic qui permet de programmer de façon beaucoup plus structuré et, surtout, s'avère être très rapide, c'est une révélation. 
Et, sur Amiga, le GFA se vendra plus que ce Pascal dont j'ai oublié le nom (révélateur...). 

La qualité d'un langage doit se mesurer par rapport aux autres langages de même type. Sinon, on met tout à la poubelle et le C ecrase tout le monde. 
Si tu ne compares le GFA qu'aux autres basic, force sera de constater qu'il arrive parmi les meilleurs. 
Tu pourras me rétorquer que AMOS ou le Blitz (qui lui arrive au niveau du C) sont meilleurs. Mais ils sont sortis bien après. Et pas sur ST. 

Pourquoi a-t-il disparu ? Et est-ce une preuve de mauvaise qualité ? 
Non : ce qui disparait n'est pas forcément mauvais, ni même moins bien. Sinon on aurait tous des Amiga... ;-) 

Pourquoi alors ? Je vois 2 raisons : 
Un langage interprété quand il execute un programme doit analyser chaque instruction et la convertir. Le GFA a été précurseur dans la mesure ou il effectue cette analyse en amont et non pas pendant l'exécution. C'est pour ça qu'il est si rapide. 
Mais forcément, cette solution innovante sera reprise par la concurrence et il finira par perdre son avantage : Par exemple l'omikron sur ST était aussi un super Basic. Il est sorti après et on se doute que ses auteurs ont du s'inspirer du système du GFA. 

La deuxième est que les BASIC ont disparus ! On en trouve toujours bien sur mais ils sont utilisés de façon anecdotique. Il reste bien VB.net mais est-ce vraiment un Basic ? Et cette évolution du Visual Basic est un produit Microsoft : facile pour eux de garder en vie un de leur produit. ça n'a rien à voir avec la qualité. D'ailleurs, ils sont quand même à l'origine de l'Amiga Basic, qui était fourni avec le mig, qui est la seule application connue de l'AmigaOS à ne pas être compatible avec certains processeurs (Les codeurs de microsoft utilisaient l'octet de poids fort des adresses pour stocker autre chose : une aberration). Et pourtant son éditeur produit aujourd'hui les langages les plus utilisés... 

Les bons produits disparaissent parfois. Et parfois les mauvais perdurent...

Si tu veux rire un coup : Le test du GFA dans Amiga News. L'auteur est exaspéré par l'éditeur, c'est le moins que l'on puisse dire ! Mais au final, il trouve le langage performant.

Test de GFA Basic 3.0

Moi je reprocherai une chose au GFA : il était tellement performant qu'il a dissuadé pleins de codeurs de passer au C ou à l'assembleur ! C'est dommage : sur 8 bits, au bout d'un moment, tu trouvais le Basic trop limité et tu passais à l'assembleur. Le GFA, par ses qualités, a empeché cela. Alors que l'assembleur 68000 est plus sympa que les assembleurs des 8 bits...

[dlfrsilver]

ah lalala :) Si même le Docteur fait du "révisionisme", on est pas "rendu" (quoi ça dépend sous quel angle on prend la chose) !

[ryosaeba]

Sacrilège. Manoir de mortevielle est un chef d'œuvre. j'y ai passé des nuits comme sur maupiti Island.

[stapha92]

et oui je ne connais strictement rien en hardware/coding XL, donc désolé si je ne fais que glaner sur internet des infos où je peux, vu que la bibliothèque du coin n'a probablement pas de livre sur le 800 XL.  Pour le displaylist par exemple, pour ce que j'en pu en lire, cela me semblait pourtant très similaire au copper : un copro indépendant du 6502 qui exécutait un script synchro sur l'affichage vidéo.  alors oui, c'est surement pas aussi puissant, mais le concept me semble qd même très similaire non ?

Je ne te reproche pas de glaner des infos sur le net. Pas du tout. Mais je dis que si, dans ce cas, tu choisissais de te faire ta propre opinion en étudiant le copper et les displaylist, je suis sur que tu en concluerais que ce n'est pas si similaire que certains l'expliquent.

J'imagine bien que ça peut être barbant. Voici donc un raccourci.

Dans l'atari 2600, le TIA s'occupait de l'affichage. Mais il ne savait pas gérer de playfield, juste quelques sprites élementaires. 
Donc le codeur devait modifier certains éléments (changer la couleur de fond, réutiliser des sprites) pendant l'affichage pour donner l'illusion d'avoir un playfield. 
D'ou l'expression "racing the beam" (faire la course avec le faisceau). Fallait de sacrés codeurs sur cette console... 

Dans le 800Xl, le TIA a évolué pour donner le CTIA puis le GTIA. Mais il ne pouvait toujours pas gérer de playfield ! Donc, plutot que d'obliger le 6502 à l'alimenter, ils ont ajouté un autre circuit qui s'en occupe : Antic. Ce circuit interprète les données du frame-buffer pour alimenter GTIA. Et la façon d'interpreter ces données peut varier en fonction du mode graphique. 
Plutot que de stocker la façon d'interpreter ces données dans des registres, on a créé le système de playlist : au début de chaque ligne, une série de commande défini les règles à utiliser pour cette interprétation. Donc la lecture de la displaylist fait partie intégrante de la lecture des données graphiques. 
Du coup, la majeure partie de ce que gère Antic est indiquée dans la playlist (Resolution, mode graphique ou texte, position du frame-buffer dans la RAM, scrolling). ça apporte une grande souplesse dans l'affichage du XL (la meilleure des 8 bits). Et il y a une commande qui peut faire faire à Antic UNE chose qui ne concerne pas l'affichage : déclencher une interuption (les fameuses DLI - Diplay List Interrupt). On peut donc s'arranger pour que le 6502 puisse faire des actions (raster par exemple) au début de certaines lignes de façon très précise. Or, le 6502 est très doué pour faire des interruptions. A noter que le niveau de granularité des commandes d'une DisplayList dépend de l'affichage. Au mieux, il sera d'une ligne. Mais il peut descendre à 8 lignes en mode texte, ou 16 lignes avec un mode texte à la résolution dédoublée.

Le copper par contre, ne fait pas partie de Denise (le pendant d'Antic sur le mig). Il peut se synchroniser sur l'affichage mais pas forcément. Il peut travailler sans synchro ou se synchroniser sur le blitter (cas utilisé fréquement). Surtout, il a la capacité d'écrire dans n'importe quel registre du chipset du mig. On peut par exemple l'utiliser pour jouer un sample à 96 Khz sans intervention du cpu, ou pour lancer une tache du blitter, réafficher un sprite. Tout ça grace à son instruction MOV. 
Le niveau de granularité du copper est toujours le même puisqu'il est indépendant du circuit d'affichage (8 pixels en basse résolution. Donc 16 pixel en haute.
Enfin, le copper est un vrai microprocesseur, avec un programme indépendant un accès mémoire qui lui est propre et des instructions que l'on peut enchainer comme on veut. Y a rien de tout ça dans les displaylist. Le copper est hyper simpliste comme microprocesseur, on peut pas faire plus simple. Donc les displaylist ne peuvent pas être un copper simplifié.

Le copper a été créé parce que le 68000 n'est pas performant dans sa gestion des interruptions. L'un des plus gros attrait des displaylist vient justement du fait que le 6502 est efficace dans sa gestion des interruptions. 

On peut trouver que ça se ressemble quand même mais on pourrait tout aussi bien remarquer que la color-ram du C64 peut être reproduit à l'identique sur le mig grace au copper avec la même granularité (1 couleur redéfinie tous les 8 pixels). Pourtant, ça n'a rien à voir...