Re: GUERRE ST-AMIGA, FIGHT !!!

[dlfrsilver]

Et maintenant, j'attends de voir la même chose sur un Amiga AGA...

Moi aussi  .

sur un ecran fixe avec un amiga aga+fast ram ça doit etre possible . mega typhon qui tourne sur a500 est dns le genre la réference et lui a un scrolling

Hannn..... Fais gaffe, y en a qui vont te jeter des pierres à dire des trucs comme ça   !

[stapha92]

stapha92 a écrit:Les 300 Ko/s, c'était pour me moquer : déjà tu mettais 2,5 megabits/s et ensuite ce nombre est moins ridicule que le tien. Déjà on est passé de HD qui faisaient 2,5 Mo/s à une interface qui n'atteint que la moitié... On progresse...
La fameuse interface dont je parle est un adaptateur qui n'existait pas à l'époque du ST (ou alors elle aurait couté 10x fois le prix du ST...) et, pour fonctionner, elle necessite une modification du ST (un Hack, pour reprendre les termes de l'auteur...). Non il ne fait aucun test car ça ne sert à rien : Il explique qu'avec un UltraSatan (plus performant que tout ce qui existait à l'époque) on ne peut atteindre que du 320x158 en 25 i/s (on oublie les 30K couleurs perceptibles...)...

je donné les débits SCSI, dont je parle SCSI, ne mélange donc pas tout et sois un peu plus attentif dans tes lectures.   donc comme tu confirmes, l'auteur ne donne aucun débit en SCSI, cela n'empêche de sa faisabilité.

C'est toi qui devrait être attentif à tes écritures : Je te rappelle qu'au départ, tu nous as expliqué que tes fameuses vidéos prouvaient que le ST aurait pu faire mieux que le mig à l'époque. Or, il faut 2,5 Mo/s et on en est loin, même avec un ultrasan... Il faut une interface spéciale (qui aurait coûté une fortune à l'époque...) et il faut trafiquer le ST et meme l'adressage du 68000. C'est dire le niveau des modifs...
On va faire plus simple : montre nous une de ces vidéos sur un vrai ST dans les conditions de l'époque...
Encore plus simple : bien que ça ne montrerait pas que le ST aurait pu concurrencer le mig en vidéo, montre nous une des ces vidéo sur un vrai ST.

 
Y avait quoi d'autre ? Ben renseigne toi : la plupart des applis fonctionnent, ce sont les jeux qui coincent (et encore, pas toujours...).
Pas de chance pour le STE (parce qu'on a du oublier le ST dans ce débat..), parce que si, sur le mig, les player qui font des changements de palette à chaque ligne tournent très bien quel que soit le modèle de mig. En plus de faire plus de changement qu'un 68000, de faire des changement couleur par couleur, le copper permet de rendre ce genre de trick indépendant du processeur... D'ailleurs l'OS lui même les utilise... En même temps avec un TOS incompatible avec les processeur 32 bits, ça n'aurait servi à rien ! lol !!!

les applis ? tu parles de celles qui en bougeant la souris trop vite provoquaient un guru ou celle qui débordait sur la ram d'un autre appli ? ou tu parles peut-être de celle qui tournait sur WB 1.3 mais pas sur la 2.0 ?  tu parles de cette magnifique copper n'a pas évolué sur le A1200, le rendant dès le départ obsolète ?  à quoi bon être compatible si c'est pour brider la machine...

Donc tu éludes une bonne partie de mes arguments et tu inventes pour répondre aux autres... 
Encore une invention : Ça se saurait si l'OS ne supportait pas un déplacement de souris rapide. D'ailleurs, pour ta gouverne , sache que les ressources consommées par la gestion de la souris sont les mêmes quand elle ne bouge pas ou quand elle est déplacée rapidement. Et, bien entendu, il en faut beaucoup moins sur le mig que sur le ST. Alors que sur le mig, le pointeur possède sa propre palette contrairement au ST ou il utilise celle du bureau ou de l'appli en dessous. Pas très pratique, surtout quand on sait qu'en moyenne résolution, ladite palette n'a que 4 couleurs sur le ST. Tres convivial... 
Le problème 1.3 -> 2.0 concerne surtout les jeux. Tu ne fais pas la différence ? Remarque c'est normal : quand on voit un scrolling sur ST, on pense avoir à faire à un défilement dans une application tellement ça saccade... 
Et encore, Prend MindWalker : considéré comme le premier jeu sur le mig, il tourne sur tous les OS, tous les processeurs et toutes les machines. 

La compatibilité était infiniment meilleure sur le mig sur sur le ST. Avec votre TOS non compatible 32 bits, c'est normal... Et en plus il n'était pas rétro-compatible. Sur le mig, tu peux mettre mettre un os 3.1 sur une machine équipée du 1.2 par exemple. Tu peux mettre un TOS 2.0 sur un STF ? ben non, tu ne peux même pas mettre un TOS 1.6 (tu sais celui qui a besoin de STE_FIX.PRG pour corriger des bug...).

La ram qui empiétait ? Tu sors ça d'ou ? C'est plutôt le TOS qui a des problèmes de RAM : la gestion de la mémoire est beaucoup plus basique et c'est en accord avec l'architecture bidon du ST qui ne peut pas être accéléré de façon efficace sans utiliser de hack. Même Atari a du s'y résoudre : pour pouvoir profiter d'un pauvre 68000 à 16 Mhz (et obtenir en moyenne 50% d'accélération...), il a fallu mettre 16 Ko de cache. Sinon tout les bénéfices de la fréquence doublée étaient gâches par les accès mémoires du ST, qui est le seul ordinateur à ma connaissance dont la mémoire est ralenti par l'affichage même quand il n'y a pas d'affichage ! Même les 8 bits étaient mieux conçus à ce niveau là ! Inutile de dire qu'au delà d'un 68000 à 16 Mhz, cette "superbe architecture" n'aurait pas permit d'obtenir le moindre gain. Sur le mig, grace à sa conception ET à son os, un 68030 à 50 mhz pouvait s'exprimer... 
Atari a corrigé le tir sur le TT en y ajoutant de la fast-ram (et surtout un TOS capable de la gérer, enfin j'imagine) afin de pouvoir profiter de son 68030 à 32 Mhz. C'est marrant : la seule machine vraiment pro de la gamme a repris l'un des concept de notre "console avec clavier"... 
Evidemment, pour en tirer parti de catte fast-ram, il faut que, lors d'allocations de ram, le programme le demande explicitement à l'OS. Sinon ce dernier est obligé d'allouer de la ST-RAM au cas ou elle devrait contenir des données graphiques. Donc, les programmes prévus pour ST ne pouvait pas profiter de la puissance d'un TT. Même quand, par miracle, ils parvenaient à être compatible avec cette machine... 

Mais le  plus drôle est là, bien expliqué par l'auteur des fameuses vidéos :

Hey ! - it can overwrite some user data, because we asked less. Right - TOS programmers knew about it, and therefore we have disk buffers. So, in reality, data goes first in buffer (from disk), and then will copy only proper number of bytes to end destination, to avoid damage of user data. And it means of course slower load

QUand le TOS charge des données, il peut empiéter sur la RAM du programme qui lui demande un chargement. LOL ! C'est ça votre TOS bien pensé ? Et y en a des dizaines comme ça. J'aurai surement l'occasion d'y revenir.
 

Non on lui doit pas le monde, mais c'est le premier micro que l'on peut qualifier de multimedia (image, son et animation)

comme déjà expliqué ici, la définition du mot multimedia ne comporte pas de critère qualitatif.  pourquoi une image atari ST ne peut-elle pas être "multimedia" ?? parce qu'il n'a que 512 couleurs ?  Une Atari ST peut jouer une vidéo / photo, avec du son, cela en fait donc un ordi multimedia.  il peut également piloter des synthés, laserdisc etc.. ce qui le fait rentrer dans le monde pro sans difficulté.  Du reste, soyons clair, l'amiga n'a rien de plus à offrir: il est lui aussi incapable de jouer une video 50 FPS en qualité vidéo.  

Oui oui c'est ça : le St est multimédia... Avec un son 8 bits, une image qui ne peut remplir l'écran (sans trick hyper couteux en ressources et inutilisables dans une application) et des animations saccadés. Un ordinateur est multimedia si il possède des applications pour faire du multimédia. Y a quoi sur le ST ? 
C'est vrai, le mig ne peut pas jouer une vidéo en 50 i/s en qualité vidéo. Mais il en est beaucoup plus proche que le ST. Les vidéos qui ont déjà été postées ici atteignent la qualité VHS, qui nous suffisaient bien à l'époque. Et elles tournent sur des vrais mig non "hackés". Pas sur un émulateur... 
Evidemment, pour les pros il y avait ce qu'il fallait : carte graphique 24 bits avec compression motion-jpeg en temps réel et direct-to-disk. 
Ah il peut piloter des synthés ou des laserdisc ? Genial ! Ben le mig aussi. En même temps, faire du midi ou piloter un laserdisc était à la portée des 8 bits, rien d'extraordinaire... 
Tu as beau dire "soyons clair" : la plupart des lecteurs savent que l'Amiga a bien plus à offrir que le ST en matière de vidéo ou de multimédia. Et les pros de l'époque l'avaient bien compris. Pour tout ce qui était vidéo ou multimédia le ST était inexistant chez les pros. Alors pour ce qui est de l'entrée dans le monde pro sans difficulté (ce que tu as prétendu à la base), ben tu repasseras... 

Ah mais je ne cherches pas à te convaincre, je veux juste corriger quelques une des inepties que j'ai vues ici. Les lecteurs se feront leur opinion. Je leur dirai simplement qu'il y a des jeux qui utilisent le dual-playfield et ajoutent un troisième layer à base de sprites mutiplexés horizontalement par le copper. Et ils font scroller tout ça sans aucun problème. Pourtant ça prend autant de ressource qu'un Ecran SHAM ou sliced EHB (6 bitplans et autant d'instructions pour le copper)...

et bien montres-nous cela ... j'attends toujours ton jeu en scrolling horizontal en sliced EHB ou SHAM...et concernant les jeux dual + sprite, cela se limite  à 99% des cas à un score qui s'affiche en sprite sans plus.  c'est bien joli de faire du parallax, mais cela ne se prêt à ...ben Shadow of the beast, un jeu très joli, développé sur un effet mais con comme la lune.  tous les tricks amiga sont inutilisables dans des jeux classiques.  

Tu attends quoi ? Je t'ai dit qu'il y avait des jeux avec un scrolling en HAM ? Tu n'arretes pas de dévier parce que tu ne peux pas continuer avec tes arguments. Au départ tu expliquais que le HAM ne pouvait servir qu'à des images statiques. Je t'ai montré un voxel en HAM et tu as rétorqué que les pixels etaient énormes. Superbe argument quand on sait qu'ils ont la meme taille sur les voxels en 16 couleurs des démos ST. Dans la discussion je t'ai dit qu'un scrolling en HAM était possible. Pas qu'il y avait des jeux en HAM avec un scrolling : dans un jeu c'est une autre paire de manches...
Marrant comme les posts des pro-st sont remplis de "c'est possible" et que nous n'avons pas le droit de faire une seule fois ce genre d'affirmation... 
Prend Pioneer Plague : c'est un jeu avec scrolling multi-directionnel en mode HAM (tiens ! on est passé de "c'est possible à "ça a été fait"...). Le problème est qu'il utilise des bobs en mode HAM au lieu de sprites. Et utiliser des bobs sur un écran HAM est hyper couteux en ressource (je pensais meme que ce n'était pas possible de le faire avec un 68000). Du coup le fond n'exploite absolument pas la palette du mode HAM. Mais les faits sont là : un scolling horizontal en HAM... 
Les jeux Dual + sprite se limitent à ça ? LOL ! Les tricks amiga inutilisables dans un jeu ? Encore une affirmation erronée : va voir la page http://www.codetapper.com/amiga/sprite-tricks/ . Tu verras des jeux qui utilisent le dual-playfield (donc 6 plans, comme le HAM ou l'EHB) + un multiplexage de sprite horizontal par le copper (ça consomme autant que de redéfinir la palette) + un changement de palette par le copper également. Il y en a quelques un mais tu peux en trouver des centaines de jeux sur le mig qui exploitent ce genre de trick... 
Pire : des jeux comme Brian the lion ou M. Nutz utilisent des effets JAMAIS vu dans une démo. C'est dire à quel point tu te trompes... 
Par contre, regarde Enchanted Land : l'écran d'intro se la joue SOTB mais quand tu lances le jeu, il n'y a même pas de vrai scrolling horizontal alors que le jeu repasse sur un seul plan ! Et Lethal Xcess : c'est le shoot de reférence sur ST et ça tourne à un pauvre 16 I/s... Il y a aussi Leavin' Teramis ou No Buddies Land, qui utilisent le syncscroll : super les saccades (alors que No Buddies Land ne fait qu'un scrolling vertical)... 
Marrante la façon dont tu affirmes que le ST "aurait" pu utiliser ses tricks dans des jeux et pas le mig alors que c'est exactement le contraire... 

Puisque tu joues du "j'attend toujours", je te rappelle que tu avais affirmé pouvoir reproduire les rotations the BTL sur un ST avec 1 Mo pour prouver que c'était possible en précalc (alors que dans le cas de BTL, c'est le jeu qui tient en 1Mo). J'attends toujours...

A noter : j'ai proposé une méthode pour faire un scrolling vertical au pixel sur ce forum et j'avais posé une question. Aucun STiste ne m'a répondu : Quand c'est pour affirmer des betises il y a du monde. Quand ça devient sérieux, il n'y a plus personne... 
Puisque tu n'étais pas là à ce moment là, je peux la reposter si ça t'interesse (ou d'autres, qui n'étaient pas là). Elle ne trafique pas le shifter (donc pas de problème avec les premiers ST) et consomme peu de ressources processeur. Son seul défaut est de consommer de la mémoire. Et elle n'a rien de compliqué.

Oui c'est ça : SOTB est nul. C'est ce que disent les ST-fanboy (ceux d'aujourd'hui, parce qu'à l'époque ils pleuraient quand ils le voyaient) sans meme l'avoir essayé. 
Et tu peux dire ce que tu veux : c'est un jeu qui est devenu culte. Contrairement à Carrier command ou autre diaporamas (parce que 5 ou 10 i/s, c'est une séance de diapos, pas une animation...) que vous n'arretez pas de nous ressortir ici... 
Et le plus drole : SOTB sur ST était une vrai bouse. Il a pourtant été en tete des ventes pendant lontemps... LOL ! 
 

Ah bon ? Comment gérer les sprites et le scrolling ? Et ou as-tu vu que ça ne se fait qu'avec le copper ? Les sprites sont autonomes, y compris pour le multiplexage vertical. Quand au scrolling, c'est 2 registres à modifier. Cela peut être fait avec le 68000 mais comme on fait ça en dehors de l'affichage pour éviter les "tearing", ça peut être fait avec le copper sans soucis puisque pendant ce temps là, il n'y a pas de palette à modifier...
La différence ? Y en a plusieurs :
 - Sur ST, tu dois synchroniser tes instructions 68000 avec l'affichage. En gros tu demandes au 68000 de faire des move sans arret du début à la fin de la zone affichée. ça représente 65% de la frame avec 200 lignes. Sur le mig, le 68000 peut utiliser toute la frame (voire 2 frames avec une vidéo à 25 i/s).Il peut même préparer plusieurs copperlist à l'avance...
 - Sur St, la synchro avec le début de l'affichage prend pas mal de cycles. Sur le mig, vu que c'est le copper, c'est gratuit...
 - Sur ST, tu es obligé d'utiliser des movem et de modifier toute la palette d'un coup pour atteindre 48 couleurs lignes. Le copper fait des move simple sur n'importe quel registre. C'est beaucoup plus efficace.
 - Sur ST, dans un logiciel de dessin (ou dans un viewer), le 68000 est occupé 65 % du temps même si aucun pixel change. Sur le mig, le 68000 se repose....
 - Sur ST, tu ne disposes plus des interruptions 68000 pendant l'affichage. Sur le mig si...
 - Sur ST, ça ne peux marcher qu'avec le proc d'origine. Sur le mig c'est compatible avec tous les 680x0. Peut importe que la copperlist soit remplie plus vite...
Je pourrai continuer a t'expliquer les avantages mais ce n'est pas la peine je pense.

ah super, on passe donc de temps  à réel à des coppers prédéfinie..wow magnifique ça, donc dans un jeu en temps réels, tu vas donc utiliser une copper par frame ??  bonne idée ça...  tu vas utiliser le 68000 pour préparer la copper qui va suivre... ah oui juste, vu comme ça, ça change du tout au tout ...
qd à ton exemple du logiciel de dessin, magnifique, l'amiga se repose et pas l'atari qui doit bouloter pour afficher ses couleurs...et après ?  tu as peur de consommer trop d'electricité ?  bref, on reviens à la même chose : si tu as un copper dynamique à chaque frame, cela ne change rien.

Toujours la même tactique qui consiste a faire dévier la discussion. Franchement c'est du troll...

Encore une fois tu montres que tu ne comprends rien au mig ou au ST... 
Meme si le 68000 devait refaire une copperlist à chaque frame, ça serait beaucoup plus efficace. Va te renseigner sur le temps que met le 68000 à déclencher une interruption avant même de faire quoi que ce soit (moins performant qu'un 6502 sur ce point...). Multiplie ça par le nombre de ligne et tu auras une vague idée de ce dont je parle. Assez pour comprendre que même refaire une copperlist à chaque frame est beaucoup moins couteux que d'utiliser des interruptions. 
Et pourquoi refaire la copperlist à chaque frame ? Tu crois qu'elle s'efface ? Il suffit de modifier ce qui doit l'être, c'est tout. 
Il y a même des cas ou tu fais une copperlist qui ne traite qu'une seule ligne (ou plusieurs) et le copper se chargera de la répeter sur la partie de l'ecran nécessaire. Comment ? Grace au possibilité de masquage des valeurs du copper (va te renseigner si tu ne comprends pas, y a rien de compliqué) et surtout grace... Aux branchements ! Quoi ???!!! Mais tu as dit que le copper ne pouvait pas faire de branchement ! 
Ben tu as tort, encore une fois. 
C'est sur, pour nous réciter les docs techniques tu es fort, mais pour appréhender ce que ça signifie, tu as plus de mal... 
Je vais t'aider : tu es au courant que le copper peut faire des move dans n'importe quel registre du chipset. Tu ne t'es jamais demandé ce qui ce passerait s'il faisait un move dans le registre qui contient l'adresse de la prochaine instruction à exécuter (son PC) ? Ben ça fait un branchement ! Et grace à l'utilisation de SKIP, ce branchement peut être conditionné... 
Dernier point : la copperlist peut être modifiée avec le blitter. Très utile si on a une grosse copperlist pour faire des changement de couleurs partout par exemple.

Quand au logiciel de dessin, les ressources consommées ne sont pas qu'un problème de courant : si le ST doit "bouloter", ben il reste moins de ressources. Deplace une grande brosse ou trace une ligne avec cette même brosse sous deluxe paint sur un ST et sur un Mig et admire la différence de vitesse : le ST rame completement à coté du mig. Maintenant refait l'opération sur un logiciel ST qui utilise un changement de palette à chaque ligne (ça sera bien pire...) et revient prétendre que ça ne change rien de bouffer les 2/3 du cpu pour afficher 3x16 couleurs/ligne...

Non ce n'est pas sans fondement. Tu prétendais que le ST aurait pu faire aussi bien que le mig en matière de titrage et de vidéo et SCALA est un programme hyper utilisé dans ce domaine. Cela impliquerait que le ST est capable de reproduire les effets disponibles dans SCALA. Il en est incapable meme en bidouillant, alors que le SCALA le fait sur le mig en étant OS friendly

oui et je confirme : le ST AURAIT pu faire, cela n'a pas existé, mais cela AURAIT PU.  Je ne vois pas c qu'il aurait été impossible à faire sur un ST que faisait SCALA.

Ah... Encore le "Aurait pu" du ST fanboy... Marrant parce que, vous nous citez le midi en pensant que le mig "n'aurait pas pu" alors qu'il l'a fait (Pro24, logiciel le plus utilisé pour le midi sur ST existait sur le mig mais était moins bien que Bar & Pipes). Et quand on vous cite les domaines phares du mig, vous nous dites que le ST "AURAIT" pu... 
Tu ne vois pas quel effet aurait été impossible à faire ? Je vais te donner quelques exemples : 
        - N'importe quel effet en haute résolution 16 couleurs. 
        - N'importe quel effet en oversan. 
        - N'importe quel effet en entrelacé. 
        - N'importe quel effet qui utilise le blitter (dommage : la plupart le font...) 
        - N'importe quel effet qui a besoin d'un scrolling (comme un simple générique)
Je pourrais continuer mais ça ne sert à rien. Prétendre qu'on aurait pu avoir un Scala sur ST suffit à te ridiculer tout seul... 

100 fois plus puissant...woooaaaaw...  tu dois avoir une super calculette pour trouver un tel chiffre... oui c'est bien ce qu'on dit depuis le début : le multitâche ne sert qu'à lancer un module s'il reste un peu de RAM.  Amiga inventé le substitut de radio pendant qu'on bosse sur un ordi.   Au prix de l'amiga, on pouvait acheter 2 ST, un pour jouer de la musique et un pour bosser.  les accessoires ST remplissent parfaitement leurs rôles ( ce sont des accessoires ), et sont super pratiques.  tu devrais vraiment essayer.  tu devrais aussi revoir ton source d'un spooler, tu as oublié  comment cela fonctionne.  ce qui est ridicule c'est l'obsession des amigaistes à comparé leur usine à gaz à un ordi fonctionnel au quotidien.  exactement comme un macintosh : un outil simple, fiable et perfomant pour le travail de tout les jour.  si on voulait une console de jeu, l'amiga était clairement le bon choix. 

Oui bien sur, le multitache ne sert qu'à ça... 
2 St au prix du mig ? Ah bon : j'ai payé mon A500 3790 Fr quand le ST était à 2990 Fr. La multiplication par 2 est différente dans l'espace-temps des ST-Fanboy ? Pas impossible, après tout il y a plein de choses étranges dans votre monde... 
Euh... Les accessoires, j'ai utilisé. Et c'est de la merde comparé aux commodities du mig. Déjà c'est du coopératif, ça ne se compare même pas. Et ils doivent être lancés au boot ! 
Si je suis en train de coder quelque chose et que j'ai besoin d'une calculatrice sur ST, je fais comment si je n'ai pas chargé l'accessoire calculatrice ? Ben je fais pas... 
Je suis donc obligé de charger une ribambelle d'accessoires pour être certain d'avoir tout ce qu'il me faut ? Ah ben zut : je suis limité à 6 accessoires max... 
Sur le mig je lance n'importe quelle calculatrice (pas besoin que ce soit une commoditie) et je fais mon calcul. 
J'ai oublié le fonctionnement d'un spooler ? Ben voyons, c'est sur que tu es bien placé pour me donner des leçons... Mais répond à ma question au lieu de dévier : quel est l'interet d'un spooler d'impression dans un env monotache ? Ou montre nous ce que je t'ai demandé : imprime une image depuis un logiciel de dessin et montre nous comment tu fais pour ne pas être bloqué. 
Oui c'est sur : super fiable le St et pas fiable le mig. C'est pour ça que le record de l'ordinateur resté allumé le plus longtemps est détenu par un Amiga (utilisé par une chaine hongroise, il est resté allumé 16 ans ! Et il a été éteint volontairement)

ah bon ?  un genlock externe ne se lock pas sur la synchro..tiens tiens...alors comment il fait pour mixer les 2 signaux vidéos ?  y'a un random qui choisit la fréq au hasard ?

Je t'ai expliqué comment marche un Genlock  mais tu ne comprends pas : il PREND LE CONTROLE DE L'HORLOGE VIDEO de l'ordinateur pour la synchroniser avec celle d'un autre signal vidéo (il ne se locke pas : il locke l'horloge de l'ordinateur). C'est pour ça qu'il faut que l'ordinateur en question soit prévu pour dès le départ (En fait pas forcément mais, sinon, ça coutera bien plus cher et la qualité sera moins bonne puisqu'il faudra passer par un frame-buffer). Donc je te le redemande : comment fonctionneront tes tricks ST qui jouent avec l'horloge vidéo (au point de générer des bruits dans le moniteur) avec un Genlock ? Ou alors montre nous un genlock faire un titrage en plein écran... 

.Tu n'es pas spécialiste mais ça ne t'empeche pas d'affirmer pleins de choses. Et de faire pleins d'erreurs..

éclaires donc ma lanterne, montres moi de la 3D hyper rapide grâce au blitter...
et idem pour c2p sur un A500 de base, montres-nous donc une routine plus rapide que sur un ST, grâce au blitter...très impatient également

Tu oublies qu'au départ tu disais que le blitter ne pouvait pas faire de C2P. Maintenant tu fais comme si tu avais simplement dit qu'il ne permettait pas de faire une C2P plus rapidement que le ST. Tu n’arrêtes pas de dévier. Reconnait que tu t'étais trompé, ça ne va pas te tuer : tout le monde l'a vu maintenant...

C'est pas grave, je te réponds quand même.

Mais peux-tu déjà me donner la routine de C2P la plus rapide sur ST ? Non ? Ah... 

Je ne vais pas faire comme toi et affirmer dans le vide. Je vais faire tout le boulot pour toi : peut-être que ça pourra te convaincre que je sais de quoi je parle. Je ne me contente pas de répéter des affirmations glanées ça et là sur le net
Et si ça peut apprendre quelque chose à quelqu'un ici qui s’intéresse au coding sur ST ou sur le Mig, ben tant mieux. 

Dans tous les cas, sur mig comme sur st, le plus rapide est de faire la C2P à la volée. C'est possible si le traitement de pixels se fait horizontalement. Sinon, il faudra passer par un buffer chunky. On peut aussi dérouler les codes que je vais présenter pour tout l'écran et utiliser les offset comme buffer c2p. 

On peut aussi remplacer les offset constants par un registre (on utilise un autre mode d'adressage du 68000). Ce qui permet de faire des calculs au fur et à mesure. Utile uniquement si les valeurs à utiliser ne sont pas les même pour toutes les lignes. Le surcout serait le meme pour les 2 méthodes. On ne va donc pas s'attarder dessus. 

Pour les 2 méthodes, on va traiter 4 pixels en 2x2 afin d'avoir une résolution effective de 160x100 sur un écran en 320x200. Il faudra, pour que le SMC soit efficace, répéter le code pour tous les pixels d'une ligne .Dans le cas du ST, il faudra ajouter 320 au registre qui pointe sur l'écran et pas sur le mig (movep n'offre pas d'incrémentation auto)). Mais je te ferai grace de cette différence qui n'est que de 400 cycles pour toute la trame dans les calculs de vitesse. 


D'abord, méthode la plus rapide pour un effet de type C2P sur ST : 

On va stocker la texture sur 4 octets, en dédoublant les pixels et en les ventilant sur chacun des octets. En considérant que A, B, C et D représente le bitplan dans lequel le bit doit aller, un texel ressemblera à ceci : 

AA000000 BB000000 CC000000 DD000000 

Ensuite on va copier cette texture 4 fois en décalant de 2 bits à chaque fois, ça donnera : 

Texture 1 : AA000000 BB000000 CC000000 DD000000 
Texture 2 : 00AA0000 00BB0000 00CC0000 00DD0000 
Texture 3 : 0000AA00 0000BB00 0000CC00 0000DD00 
Texture 4 : 000000AA 000000BB 000000CC 000000DD 

(pour des pixels non dédoublés, il faudrait faire un décalage d'un seul bit et stocker la texture 8 fois) 

En faisant pointer A0 à A3 sur les 4 textures, A4 sur la mémoire écran et en considérant que l'offset permet de choisir le texel à récupérer, on obtient le code suivant : 


Move.l Offset(A0),D0 ; D0 = AA000000 BB000000 CC000000 DD000000 
Or.l   Offset(A1),D0 ; D0 = AAAA0000 BBBB0000 CCCC0000 DDDD0000 
Or.l   Offset(A2),D0 ; D0 = AAAAAA00 BBBBBB00 CCCCCC00 DDDDDD00 
Or.l    Offset(A3),D0 ; D0 = AAAAAAAA BBBBBBBB CCCCCCCC DDDDDDDD 
Movep.l D0,(A4) ; Ecran = AAAAAAAA xxxxxxxx BBBBBBBB xxxxxxxx CCCCCCCC xxxxxxxx DDDDDDDD xxxxxxxx 
Move.l Offset(A0),D0 ; D0 = AA000000 BB000000 CC000000 DD000000 
Or.l   Offset(A1),D0 ; D0 = AAAA0000 BBBB0000 CCCC0000 DDDD0000 
Or.l   Offset(A2),D0 ; D0 = AAAAAA00 BBBBBB00 CCCCCC00 DDDDDD00 
Or.l    Offset(A3),D0 ; D0 = AAAAAAAA BBBBBBBB CCCCCCCC DDDDDDDD 
Movep.l D0,1(A4) ; Ecran = AAAAAAAA AAAAAAAA BBBBBBBB BBBBBBBB CCCCCCCC CCCCCCCC DDDDDDDD DDDDDDDD


Le movep permet de faire la permutation 8 bits et l'affichage entrelacé évite la permutation 16 bits. 

Total 176 cycles pour nos 8 pixels en 2x1. Pour dédoubler les lignes et obtenir du 2x2, on va faire pleins de movem déroulés qui vont couter 34 cycles (en fait un peu plus, mais bon...) de plus pour traiter nos 8 pixels. 

Donc total : 210 cycles pour le ST. 


Version Amiga : 

On va également stocker notre texture 4 fois, mais chaque texel prendra 2 octets et les 4 textures donneront : 

Texture 1 : AB000000 CD000000 
Texture 2 : 00AB0000 00CD0000 
Texture 3 : 0000AB00 0000CD00 
Texture 4 : 000000AB 000000CD 

Et on utilisera le code suivant (A4 pointe sur un buffer chip) : 

Move.w    Offset(A0),D0 ; DO = AB000000 CD000000 (on n'utilise que le mot de poids faible) 
Or.w        Offset(A1),D0 ; DO = ABAB0000 CDCD0000 
Or.w        Offset(A2),D0 ; DO = ABABAB00 CDCDCD00 
Or.w        Offset(A3),D0 ; DO = ABABABAB CDCDCDCD 
Move.w    D0,(A4)+       ; buffer chip = ABABABAB CDCDCDCD 
Move.w    Offset(A0),D0 ; DO = AB000000 CD000000 
Or.w        Offset(A1),D0 ; DO = ABAB0000 CDCD0000 
Or.w        Offset(A2),D0 ; DO = ABABAB00 CDCDCD00 
Or.w        Offset(A3),D0 ; DO = ABABABAB CDCDCDCD 
Move.w    D0,(A4)+       ; buffer chip = ABABABAB CDCDCDCD ABABABAB CDCDCDCD 

Le code prend 112 cycles, mais on n'a pas terminé. 

On va faire appel au blitter pour, à partir de la séquence suivante : 

ABABABAB CDCDCDCD ABABABAB CDCDCDCD 

générer les 2 séquences suivantes, qui vont correspondre au bitplans 1 et 3 

ABABABAB ABABABAB 
CDCDCDCD CDCDCDCD 

On va faire 2 passes en faisant pointer la source A sur le buffer chip et la source B sur le buffer chip + 2 octets. On attribuera un modulo de 2 aux 2 sources et on mettra la constante 11111111 00000000 dans la source C (donc pas de DMA sur cette source, son utilisation est gratuite) 

Pour la première passe, on réalisera l'opération suivante (D est la destination) : 

D = (A AND C) OR (B >> 8 AND (NOT C)) 

Il faudra donc décaler la source B de 8 bits et appliquer le minterm %11101000. 

Pour la deuxième passe, on fera l'opération : 

D = (A << 8 AND C) OR (B AND (NOT C)) 

Et on aura nos plans 1 et 3. 

2 remarques : 
        - Je pense que tu commences à comprendre à quel point le blitter du mig est puissant (il peut faire des choses bien plus complexes que ça). 
        - Tu te dis peut-être : Des bits A et B dans le plan 1 ? Mais il ne devrait y avoir que des bits A ! Et les bits B devraient être dans le plan 2 ! 
          C'est vrai, mais grace à l'architecture du mig, on ne va pas avoir besoin de le faire. Voyons voir comment. 

Là on peut s'arreter et utiliser le scrolling hardware : on fait pointer les bitplans 2 et 4 sur les même plans que les 1 et 3 en effectuant un décalage de 1 pixel sur les plans pairs. Nos 4 plans seront donc ainsi : 

ABABABABABABABAB 
BABABABABABABAB (plan 1 décalé d'un bit vers la gauche) 
CDCDCDCDCDCDCDCD 
DCDCDCDCDCDCDCD (plan 3 décalé aussi) 

Magique ! (quand je vous disais que, niveau coding, on s'amuse plus avec un mig...) 

Mais 1 pixel sur 2 sera erroné : on voit bien que sur la 1ere colonne, il y a bien ABCD, mais sur la 2eme c'est BACD, sachant que les bits B et D concernent le 1er pixel et les A et C le second. Donc soit : 
        - On les efface (avec un 5eme plan et les couleurs 16 a 31 de la palette mises à 0) mais l'image est plus sombre. Donc ce n'est pas equitable dans cette comparaison. 
        - Soit on rédéfini habilement les couleurs 16 a 31 pour avoir des couleurs intermédiaires sur ces pixels (on récupéra les bits de poids fort de chacun des pixels adjacents). 
          l'image pourra être meilleure qu'avec du 2x2 normal (sorte d'interpolation gratuite) mais certaines combinaisons de couleurs seront inutilisables (parce qu'on utilise pas réellement les poids forts) donc on se retrouve avec 11-12 couleurs exploitables (à tester, je ne l'ai jamais fait). Ce n'est toujours pas équitable avec le code du ST ci-dessus. 

Donc, pour avoir le même résultat que sur ST, on va refaire 1 passe (Si on s'est arrangé pour que les bitplans 1 et 3 soient contigus, sinon il en faut 2) et générer les plans 2 et 4 qui auront l'aspect suivant : 

BABABABA BABABABA 
DCDCDCDC DCDCDCDC 

On va utiliser un 5eme plan, mais sans utiliser de DMA ni de mémoire : on va utiliser la constante 01010101 01010101. 
Nos 5 plans seront donc : 

ABABABAB ABABABAB 
BABABABA BABABABA 
CDCDCDCD CDCDCDCD 
DCDCDCDC DCDCDCDC 
01010101 01010101 

Cette fois toutes les colonnes contiennent les bits des même pixels. Mais pas dans le meme ordre. 
Ce n'est pas grave : On aura copié les couleurs 0 a 15 de la palette dans les slots 16 a 31 en les réorganisant pour que les combinaisons ABCD dans la premiere moitié correspondent aux combinaisons BACD dans la deuxième (par exemple la couleur 00001 devra etre identique à 10010, ou encore 01010 à 10101) 

On aura créé 2 copperlists (on ne le fait qu'une seule fois ! ;-) ) pour effectuer les 3 passes du blitter (le copper sait attendre la fin d'un travail du blitter) dans les 2 buffers différents et on appelle celle qui correspond au buffer écran que l'on est en train de traiter (on fait tout ça en double-buffer bien sur). Ou on le fait au 68000 : le blitter peut générer une interruption quand il termine une passe. 

Et c'est terminé. 

Les passes du blitter prennent 24 cycles pour les 8 texels. Mais la parallélisation fera que, en pratique, ça n'en prendra meme pas la moitié (et si on les lance pendant que le 68000 fait des gros calculs, ça sera beaucoup moins.). Allez disons que ça prend la moitié : pour le ST j'ai pris des nombres avantageux, pour le mig je fais l'inverse, je suis quand même fair-play... ça fait donc un total de 124 cycles. Et si on a de la fast-ram, on peut s'arranger pour que le travail du blitter soit gratuit. 

Quand au doublage de ligne, il est gratuit : le chipset peut le faire tout seul en lisant les données de chaque ligne 2 fois. 

Donc au total on a : 
        - 210 cycles pour le ST 
        - 124 cycles (112 avec de la fast-ram) pour le mig 

si on tient compte de la différence d'horloge (on prend les resultats du mig et on les multiplie par 8/7,1) ça donne : 
        - 210 cycles pour le ST 
        - 140 cycles (126 avec de la fast-ram) pour le mig 

Et la version mig a un autre avantage : les textures prennent 2 fois moins de place. C'est pas du luxe : 16 octets par texel sur le ST, 8 octets sur le mig. Une texture de 64x64  prendrait 64 Ko sur le St et 32 Ko sur le mig. 

En fait, grace au blitter et au chipset, le 68000 du mig traitera 8 Ko par écran. Ce qui correspond à une définition de 160x100x16. C'est le minimum. Le 68000 du ST traitera les 32 Ko de l'écran entièrement. C'est pour ça que le mig sera plus rapide. 

Si je n'ai pas été clair dans l'explication (aussi bien pour le ST que le mig), n'hésites pas (toi ou d'autres) à demander.

[stapha92]

Alors pour la comparaison Ambermoon/Wolfeinstein : Wolfeinstein est en plein écran mais en 2x2. ça revient quasiment au même. Et Wolfeinstein utilise beaucoup moins de textures, ne gère pas tout ce que gère Ambermoon mais a besoin de 2 Mo pour tourner (ce qui le rend incompatible avec la grande majorité des ST de l'époque...). Il faudrait combien pour faire tourner Ambermoon de la meme façon ? 8 Megas ? A l'inverse Ambermoon est beaucoup plus vieux : il ne profite donc pas des techniques de coding récentes. Il tournait sur les A500 de l'époque avec 1 Mo : il ne peut pas s'appuyer sur des textures présentes n fois ou du code déroulé. Par contre, la présence de fast-ram (qui n'était pas une exception sur le mig) doit lui permettre de tourner plus vite. C'est peut-être pour ça que nos 2 combattants n'obtiennent pas le même résultat.
Je dirai que la comparaison est totalement biaisée. 

Pour l'histoire du copper qui ne peut pas faire de 1x1. Rocky a parfaitement raison : Il peut faire 57 changement de couleur/ligne. Il en faudrait presque 3 fois plus pour faire du 1x1 dans la fenêtre d'Ambermoon. 
Par contre, Ambermoon doit abondamment utiliser le blitter (rien que le nom de l'exe lancé : AM2_BLIT le montre clairement), c'est pourquoi je pense que de la fast-ram doit lui permettre de tourner beaucoup plus vite. 
Donc le STE n'aurait pas pu avoir un Ambermoon identique : son blitter n'a que 2 sources (pas rentable pour une C2P) et ne parallélise pas son travail : il bloque totalement son CPU ! Dans la doc officielle, Atari recommandait de faire des blits ligne par ligne pour que les interruptions puissent être executées (avec un retard qui peut atteindre une ligne et un surcout en ressources processeur...). C'est du foutage de gueule ! 

Wolfeinstein n'exploite pas de particularité du STE. Il doit juste utiliser le blitter pour dédoubler les lignes plus rapidement qu'avec des movem. Il doit surement utiliser des texture pré-shiftées qui facilitent la conversion du buffer chunky et des grandes tables de conversion. D'ou la quantité de RAM nécessaire. Il s'appuie surtout sur une version Macintosh beaucoup plus adaptée au 68000 que la version PC.

[stapha92]

Vroom, malgré la présence de sprite, tourne plus vite sur St que sur Amiga, et c'est la même chose pour tous les jeux n'utilisant pas de scrolling comme par exemple les jeux 3D.

Vroom n'est pas plus rapide sur le ST. Pourtant les routines d'affichages sont les même et n'exploitent absolument pas le chipset du mig. la seule différence se situe au niveau du son : c'est bien plus gourmand  de reproduire un sample sur ST. Et comme en plus Vroom reproduit l'effet doppler, il faut pouvoir faire varier la tonalité. Ce que même un STE ne sait pas faire de façon hardware (et c'est pour ça que même un STE ne peut pas reproduire un mod avec la même qualité que le mig...). Le premier a avoir expliqué que Vroom tournait moins vite sur ST à cause du son sur ce forum c'est ST-iste. Lui n'était pas un fanboy et il a quitté ce forum... 

Tous les jeux sans scrolling tournent plus vite ? Encore une affirmation assénée comme une vérité absolue. Mais c'est totalement faux. 
Un exemple ? Ok : 
- Lotus turbo esprit : plus fluide sur le mig. Et il n'y a pas que la fluidité : les objets sur les cotés et les voitures ne sont pas positionnés au pixel près. Ils se déplacent par a-coups. C'est déjà moche sur les objets mais sur les voitures c'est vraiment ignoble ! Facile à comparer :
https://www.youtube.com/watch?v=fJjEZPMcBhA&t=2m14s
https://www.youtube.com/watch?v=JLlWlsb9GpQ&t=3m08s
Déjà que le pré-scaling nuit à l'animation (quel dommage qu'il n'utilise pas les extension RAM : il aurait pu être parfait...) mais les déplacements erratiques des voitures nuisent même au gameplay (pas facile de froler une voiture quand elle se déplace par bloc de 16 pixels...) 

D'autre exemples  : 
        - Space Harrier : plus fluide sur le mig alors qu'il est en plein écran avec overscan. Sur ST il n'occupe meme pas la totalité des 320x200 disponibles. Et il souffre du même problème de positionnement horizontal des sprites. 
        - Super Hang-on : meme problème encore sur le ST. Mais là en plus, on a droit a des motos ridiculement petites ! Et ce n'est pas plus fluide pour autant... 
        - Driving force : ce jeux utilise des gros pixels qui lui permettent d'avoir une animation sans défaut. Du moins sur le mig... 
        - Encounter : pas plus fluide sur le ST. Pourtant il y a de la 3D... 
        - T Bird : Les graphismes sont beaucoup moins bons sur le ST. Et pourtant l'animation est nulle dessus, avec un scaling completement raté... 
        
Shockwave ou Vindex n'existent pas sur ST (et n'ont pas de scrolling...) mais font des scalings largement meilleurs que tous ce que j'ai vu sur ST... 

Parlons de 3D surface pleine, puisque l'on arrete pas de nous dire que le mig est à la ramasse par rapport au ST : 
Effacer un ecran est pratiquement gratuit sur le mig si on utilise le blitter (surtout que, dans ce mode, ce dernier n'utilise que la moitié des cycles dont il dispose ). 
Effacer un ecran sur ST prend 70 000 cycles : à 12 images/secondes, le ST aura consommé l'avantage qu'il possédait sur le mig. Si c'est plus fluide, c'est pire... 
Et ça ne s'arrete pas là. Parce que le mig peut : 
        - Tracer des lignes au blitter. Honnetement, pas très efficace avec des petits polygones car le gain est perdu par la mise à jour des registres du blitter. 
        - Faire les remplissages au blitter. Là, ça commence à être intéressant, et même très intéressant pour les gros polygones)) 
        - Faire des copies dans les bitplans : le 68000 traite un polygone dans un buffer sur un seul plan et le blitter le réparti dans les différents bitplans disponibles en positionnant ou en effaçant les bits en fonction de la couleur à utiliser et en s'occupant des masquages. Là c'est hyper efficace. Surtout que, dans ce cas, la source sert de masque. 
        - Utiliser des modulos : sur le mig on peut s'arranger pour que chaque ligne soit séparée de la suivante par 256 octets, ça simplifie les calculs d'adresse mémoire pour les coordonnées. 
La vérité c'est que la majorité des jeux en 3D surface pleine datent de l'époque ou les jeux ST étaient portés vers le mig directement sans profiter du Hardware. Quand on est passé à l'époque ou le mig était correctement exploité, ces jeux ne faisaient plus recette. Après les années 90, il y en avait beaucoup moins mais il étaient bien plus fluides (Vroom, No second prize, Trex Warrior). Mais, bien qu'il n'utilisaient pas le hardware du mig, ils tournaient aussi bien que sur ST.

[stapha92]

Et bien entendu cela apporte un plus gros confort dans les applications pro.

Le ST plus rapide pour les applis pro ? LOL ! 
Tu veux qu'on parles de la rapidité de l'OS ? De la façon dont les fonctions sont appelées directement avec le mig contre un passage par vecteur d'exception sur ST ? Du passage de paramètre par registre pour le mig et par la pile pour le ST ? Du résultat sur la pile que l'appelant doit synchroniser dans le cas du ST ? Va te renseigner sur le nombre de cycles perdus betement à cause de ce système pourri avant de croire que le ST est plus rapide... 
Ou mieux, fait une comparaison et montre nous ça qu'on rigole. Mais pas besoin : rien qu'un déplacement de fenêtre est bien moins rapide sur le ST. Ou essai votre sacro saint GFA Basic, c'est facile de comparer (il existe sur le mig, même s'il a été cité ici comme argument en faveur du ST, c'est dire le fanboyisme ambiant...). Il tourne plus vite sur le mig avec le multitache activé ! MDR ! 
Un programme comme pagestream ou pro24 (je fais expres de prendre 2 logiciels issus du monde ST mais qui existent sur le mig) passent par l'OS pour tous les affichages, forcément, qui se faisaient beaucoup plus rapidement sur le mig puisque l'OS exploite le blitter... 
Et puis, les pros avec une machine qui ne peut pas être accéléré efficacement... on reparle des accès mémoire bridés du ST qui font qu'une carte accélératrice (je devrais dire un bricolage parce que carte sur un ST...) avec un 68000 à 16 Mhz n'apporte que 10 à 15 % d'accéleration effective ? On reparle d'Atari qui, sur le MegaSTE , a du mettre 16 Ko de cache pour atteindre 50% d'accélération (toujours avec un 68000 à 16 Mhz) ? On parle des cartes à base de 68030 ? Ah ben non on en parle pas : ça n'existe pas parce que ça n'apporterait presque rien (même avec un TOS compatible 32 bits... lol !) à cause de la super architecture du ST... 

Au fait, à cause de la façon dont sont entrelacés les accès mémoire entre le chipset et le cpu, un amiga tirerait pleinement profit d'un 68000 à 16 Mhz même sans fast-ram ni cache. 
Sur le mig il alternent avec une précision d'un cycle, sur le ST c'est 2. Pourtant sur le ST, il n'y a pas grand chose à gérer... 
Je pourrais détailler mais pour expliquer brièvement : sur Amiga le cpu peut accéder à la RAM tous les 2 cycles et sur le ST tous les 4 cycles. Avec un 68000 à 8 Mhz, ça ne pose pas de problème car les instructions 68000 prennent 4 cycles minimim (ou presque pas de problème : une instruction qui prend 6 cycles sur le mig en prendra 8 sur le ST...). Par contre, à 16 Mhz, le 68000 tourne 2 fois plus vite que la RAM, il pourra donc y accéder tous les 2 cycles. Impossible sur un ST (d'ou l'utilisation de mémoire cache sur le MegaSTE) et aucun problème sur le mig... 
Ah oui : très pro tout ça...

[stapha92]

Ryosaeba, 
Tu nous le refais régulièrement le coup de la moyenne avec toutes les utilisations d'un ordinateur. 
Cette moyenne, il faudrait la pondérer avec l'utilisation. Combien de fois un utilisateur de St ou Mig a eu besoin de faire de la PAO ? Combien de fois a-t-il eu envie de jouer ? 
Avec cette pondération, le mig est loin devant rien qu'avec les jeux qui représentaient la grande majorité de l'utilisation de ces 2 bécanes. 
Mais même sans, faisons les comptes : 
        - Pour jouer le mig, loin devant. 
        - Pour dessiner, le mig loin devant. 
        - Pour faire de la musique sans avoir à acheter un expander qui valait 2 fois le prix de la machine, le mig loin devant. 
        - Pour coder, le mig loin devant  : on a le sacro-saint GFA nous aussi. Et notre version du STOS (AMOS) est infiniment meilleure et elle a beaucoup évoluée (extensions multiples, compilateur, version pro). Mais on a le blitz, qui écrase tout ça. Ou le E, qui était gratuit et permettait de faire de l'objet. On peut faire de la vrai programmation événementielle, apprendre à travailler avec les messages inter-applications, etc... On disposait même des meilleurs editeurs (comme CygnusEd par exemple). Je passe sur la présence d'un vrai shell, qui permettait de faire des fichiers scripts facilement. Ou de Arexx (créé par IBM pour les pros...), qui permettait de décupler la puissance de pleins d'applications, en les faisant communiquer entre elles pour travailler ensembles. 
Si on prend les domaines de prédilection de chaque machine, là aussi la situation est claire : 
        - Pour le titrage, la 3D, le multimedia : le ST n'existait pas. Il n'avait aucune application (voire pas de solution technique) d'un niveau approchant ce qu'il y avait sur le mig. 
        - Pour le midi : ben on avait Pro24, Bar & Pipes Pro (premier a etre totalement orienté objet : Microsoft a meme racheté la boite qui l'a créé pour utiliser sa techno dans DirectX...) et pleins d'autres applis. 
        - Pour la PAO : On avait, entre autres, PageStream qui est considéré comme la killer-app dans ce domaine. 

Alors c'est vrai, on n'avait pas Cubase ni le Rédacteur. Mais par rapport à ce que le ST n'avait pas, c'est le jour et la nuit... 

Un ordinateur, ce n'était pas que les logiciels. C'est aussi les possibilités d'expansion. Sur le mig on avait l'autoconfig : tu as acheté une carte ? Ben tu la mets dans ton mig, elle est reconnue et les ressources sont attribuées automatiquement. Rien à faire. Aujourd'hui on appelle ça le plug & play. Vous n'aviez rien de tel sur le ST. Remarque, ça n'était pas utile vu que tout ce que le ST avait, c'est un port cartouche tout juste bon à recevoir des dongles... Marrant : la console à disquette n'a pas de port cartouche mais est hyper évolutive et l'ordinateur "sérieux" (pour ne pas dire austère) avait un port cartouche et presqu'aucune possibilité d'évolution.

[Invité]

Meme si le 68000 devait refaire une copperlist à chaque frame, ça serait beaucoup plus efficace. Va te renseigner sur le temps que met le 68000 à déclencher une interruption avant même de faire quoi que ce soit (moins performant qu'un 6502 sur ce point...). Multiplie ça par le nombre de ligne et tu auras une vague idée de ce dont je parle. Assez pour comprendre que même refaire une copperlist à chaque frame est beaucoup moins couteux que d'utiliser des interruptions. 

Tout à fait, c'est d'ailleurs surement ça qui justifie la présence du copper, qui plus est, est largement plus efficace et flexible que des interruptions, même rapide comme celles des 65xx .

[stapha92]

st je sais pas , mais le ste me semble tres similaire au a500 , j'ai tester quelque jeu j'ai pas vraiment vu de difference , scroll et co , le son un peu mieux sur amiga , mais le ste se rattrappe avec une toute petit modif sur le filtre audio !

l'image est tout aussi belle l'un que l'autre :)

le st ok il est en dessous du 500 , mais le ste est au meme niveaux que le a500 !

Tu ne vois pas la différence entre un STE et un A500 ? 
Ben trouve nous quelque chose du niveau de SOTB 1, 2 & 3, LionHeart, M. Nutz, RickyWoods, Jim Power, Agony, Brian the Lion, Kid Chaos, Ruff 'n' Tumble, Soccer kid, Universe, Unreal, Apidya, Leander, Project X, The Settlers, Alien Breed, skidmarks, Flashback, Beneath A Steel Sky, Curse of Enchantia, Flight of the Amazon Queen, Chuck rock 1 & 2, micro machines, R-Type 2, Elfmania, shadow fighter, Desert strike, Jungle strike, Pacmania, James pond 2 & 3, Simon The Sorcerer, etc... (je pourrais continuer longtemps comme ça...) 
Tu ne pourrais pas parce que le STE n'apporte pas grand chose au ST : 
        - Il n'affiche pas plus de couleurs, c'est toujours 16 en basse résolution et 4 en moyenne. Loin derrière le mig. 
        - Il n'a toujours qu'un seul playfield, le mig 2 et peut même en avoir 3 grace aux sprites et au copper. 
        - Toujours pas de mode overscan. 
        - Toujours pas de sprites. 
En fait, ce qui change dans l'affichage, c'est : 
        - la palette : elle passe de 512 à 4096 couleurs. Mais le nombre de pixels et/ou de couleurs affiché est strictement identique à un ST de Base. 
        - Des registres permettant (enfin !) de faire scroller l'écran (avec la bonne idée d'avoir un bug sur l'offset horizontal : bien joué Atari !) 
        - Un blitter moins bon que celui du mig (en étant sorti des années après !). 

Je passe sur le fait que les registres Amiga sont pris en compte à n'importe quel moment alors que la plupart de ceux du ST(E) ne sont pris en compte qu'au début de l'affichage. 
ça l'empeche par exemple de faire des scrolls différentiels à la ligne ou d'avoir 2 zones à l'écran qui scrollent indépendamment, comme Super Cars 2. 

Meme si on prend un jeu qui n'a besoin ni de blitter, ni de sprite, qui est sorti sur STE d'abord et qui a la réputation d'être plus beau sur le STE que sur mig (mets ta souris au dessus de l'image pour avoir la version mig): 

milan.kovac.cc/atari/wet/obsession/compare.html 

Meme dans ce cas, on peut pas dire que "l'image est tout aussi belle l'un que l'autre " ! Et pourtant il utilise des tricks spécifiques STE : c'est pas codé n'importe comment... 


Si tu veux avoir un ordre d'idée juste pour le graphisme : 
        - En 320x200, un STE affiche 12 couleurs de plus qu'un amstrad cpc 
        - En 320x200, un amiga affiche 48 couleurs de plus qu'un STE, et lui peut faire du 352x288 avec le même nombre de couleurs... (on ne parle pas du mode HAM evidemment) 
        - En 640x200, un STE affiche 2 couleurs de plus qu'un cpc. 
        - En 640x200, un amiga affiche 12 couleurs de plus qu'un STE (et là encore, ça monte à 704x288). 
       
Si tu ne vois pas la différence entre un STE et un mig, tu ne dois pas voir celle entre un cpc et un ST : l'écart est moins grand dans ce cas...

ben coter perf j'ai pas encore trouver de jeu mieux sur l'amiga que le ste , actuellement le ste est bien plus performant que le a500 sous ks 1.3 et 512ko , vitesse de chargement , jeu , démo , son ect !

HA HA HA HA !!!!

[stapha92]

Je ne trouve vraiment pas beau le WB, et désolé mais un OS qui ne peut même pas afficher un directory et nécessite un 3 changement de disquette pour fomatter, n'est pas un OS digne de ce nom. Même les plus fervent d'Amiga reconaissent que les WB < 2.0 sont de le merde.

Pas possible d'afficher un directory ? Laisse moi rire, on avait un shell d'origine (et pas un erzast...) qui nous permettait de tout faire. Et le TOS alors ? Tu oublies de dire qu'il ne permettait pas de le renommer ce fameux directory. Et tu ne parles pas de la limite de 40 directorys. 40 max en tout et pour tout et sur toutes les partitions d'un HD ! LOL ! Rien qu'en restant dans le domaine du directory (LE truc que vous nous sortez tout le temps) on voit combien le TOS est ridicule ! J'aurai pu parler aussi de la fiabilité du filesystem, ou des attributs beaucoup moins nombreux que sur le mig... 
Tu as tout à fait le droit de trouver le WB moins beau, c'est un critère subjectif. Il faut cependant noter que : 
 - Le WB est infiniment plus personnalisable que le GEM. Quand on voit les 2 options du GEM qui se battent en duel , ça donne envie de rire ! Les préférences du WB, c'est carrément autre chose. 
 - Il affiche des icones personnalisés. 
 - Ces même icones permettent de paramétrer un tas de choses liées aux exécutable associés, comme la taille de la pile, les params en ligne de commande, etc... 
 - Il affiche des noms de fichier clairs. Un fichier nommé "Vacances aux canaries 1994 - 01.jpeg" est quand même plus parlant que "VCCN9401.JPG". Surtout quand ce fichier était associé à un icone qui représentait une miniature de la photo en question. 
 - Il permet d'avoir une ligne de commande. Il y a des choses que tu peux faire en une ligne mais qui demandent des centaines de clics. 
 - Il permet d'ouvrir plus de 4 fenêtres... 
 - Il affiche les icones des disquettes (standards ou personnalisés) avec leur nom (en clair) quand on insère une disquette dans le lecteur. Et pas l'icone d'un lecteur B meme si on n'en a pas...
 - Il affiche 16 couleurs en haute resolution.
 - Il propose 2 systeme de disk en RAM (le ST un seul, avec un accessoire) : Un normal et un qui resiste au reboot (ah pas le ST). C'est ce qui m'avait décidé à acheter une extension mémoire en lieu et place d'un 2eme lecteur (avec une startup sequence qui va bien, le système pointait sur le RAD: chaque fois qu'il avait besoin de la disquette du WB et rebootait dessus). C'est sur : il fallait savoir ecrire la startup-sequence... Ou recopier une de celles publiées par une revue amiga. 
 - Il n'était pas obligatoire : si tu préférais DOpus, comme Ryosaeba. Ben tu pouvais démarrer avec. Pas besoin du WB. 
 - Il utilisait un système de datatype : tu faisais glisser une image compressé en jpeg sur l'icone MultiViewer et ce dernier l'affichait. Alors meme que le programme ne gerait pas le JPEG... 
Tout ça pour dire que, avec un peu de personnalisation, même toi tu aurais pu trouver le WB acceptable. 

Je me souviens de l'un de mes premiers contact avec le WB : j'ai utilisé la commande SAY pour le faire parler un peu. Quand j'ai réalisé que la synthèse vocale etait meilleure que le manoir de mortevielle (je venais du ST) je n'y croyais pas ! Mais bon : ça ne me servait à rien... 

l'amiga possède lui aussi une longue liste de jeux infâmes, ce n'est pas propre à l'atari

Oui, c'est vrai (La plupart dont d'ailleurs des direct port du ST...) mais il en possède moins puisqu'il faut enlever ceux qui sont infames sur ST et bon voire excellents sur le mig (Pacmania, SOTB, etc... ). Mais, surtout, il possède des tonnes de jeux excellents. Beaucoup plus que le ST. Y en plusieurs qui sont devenus cultes (SOTB, Lemmings, Worms, The Settlers, ...). Et il y a des perles parmis ceux qui ne sont pas connus (Fury of the furies, Benefactor...) 

il te faut surtout 4mb de mémoire minimum, et les bonnes images WHDLoad patchées.

Pas du tout : WHDLoad fonctionne avec 1 Mo. Avec 1,5 on est à l'aise pour les jeux ECS. C'est avec les jeux AGA qu'il en faut plus, parce que ceux-ci en prennent déjà 2. Mais les jeux AGA sur un A600... 

on ne parle pas de la clock du processeur mais la gestion timing du midi ! le midi faisant partie intégrante de l'hardware et du software ( ROM ), sa gestion est plus précise que utiliser le port série de l'amiga en midi.

Ah bon ? Le midi est un port série, rien de plus. En quoi la gestion d'un port série est plus précise que la gestion d'un port série ? Et depuis quand le software en rom est un avantage ? La ROM de ton ST est plus rapide que la RAM ? C'est nouveau ça... 
D'autre part, il existait des interfaces midi sur ST aussi (et produites par Steinberg, C-Lab : donc du très sérieux...) qui offraient plus de prises et de canaux que ce qu'il y a d'origine sur un ST. Et elles se connectaient sur... le port série !
Bizarre, non?

le multitâche, ça veut bien dire faire plusieurs tâches en même temps. Si le processeur prend plus de temps pour jouer un sample car n'a pas une puce dédiée à cela, cela reste cependant du multitâche. tu as beau retourner dans tout les sens, c'est comme ça. et concrètement, le multitâche ne sert pas pour jouer à deux jeux en même temps ( du reste l'amiga était tellement mal foutu que cela planterait direct), mais pour des applications bureautiques, je ne vois donc pas l'intérêt d'avoir des rasters partout , sprites ou module qui jouent pendant que tu fais du traitement de texte. les copros sont inutiles.

C'est vrai : le processeur prend plus de temps à cause de la façon dont il doit gérer les samples tout seul. Il irait de toute façon moins vite que le mig, à cause des appels via vecteur d'exception mais la différence ne serait pas énorme. Et en quoi l'Amiga est tellement mal foutu qu'il planterait direct si on faisait tourner 2 jeux (ce qui serait débile : comment jouer à 2 jeux en meme temps) ? C'est bien beau de nous mettre un "du reste", comme si tu disais une évidence mais c'est encore faux. 
Pour des applications bureautiques, le blitter est très utile. Toutes les applications qui affichent quelque chose (donc l'immense majorité...) sont dans ce cas. Et pourtant, c'est un copro, non ? 
Et c'est pas ce type de copro qui, bien des années plus tard, était présent sur toutes les cartes graphiques de PC ? 

Désolé dlfrsilver, mais, sur le principe global de cet échange, c'est Rocky qui a 2 fois raison : 
 - Le ST pourrait être multitache. le fait que le 68000 n'ai rien pour l'aider rendrait ce multitache moins performant que le mig mais il aurait été possible d'avoir un résultat tout à fait correct. 
 - Ce n'est pas le harware du mig qui le rend multitache. L'OS en tire profit c'est tout. Par exemple : une appli affiche quelque chose -> l'os fait travailler le blitter et en attendant attribue les ressources cpu à d'autres taches. Avec un OS monotache, le cpu attendrait betement que le blitter ai fini. Autre exemple : Il tire profit du copper pour afficher plusieurs écrans dans des réolutions différentes. Mais l'absence de ces fonctionnalités n'empeche pas d'avoir un OS multitache. 

En fait tous les processeurs peuvent faire du multitache mais, pour que celui-ci soit exploitable (cad eviter que les changements de tache soient trop gourmands en ressources processeur) il faut que la pile soit relocalisable. C'est bien entendu le cas du 68000. Donc oui : il existe bien des OS multitaches pour le ST. Et même multitaches préemptif. Mais il y a un problème : la compatibilité avec les logiciels et avec les machines : il faut un HD et de la RAM... Je n'ai jamais vu un STF avec plus d'1 Mo, et c'était insuffisant... 
Et parmi ceux qui sont cités, il y en a qui ont besoin d'un proc avec MMU. Il ne peuvent donc tourner qu'avec un falcon ou un TT. 

j'ai simplement dit qu'une source de tout les plantages de l'amiga est le manque de MMU.

Moi j'ai pas connu tous ces plantages. J'ai pas eu plus de Guru que bombes. C'est sur que si on utilisait des DP en version beta, ça devait arriver plus souvent... 
Et non : la source des plantages d'un mig ou d'un ST est la présence d'un bug. Fin. 
Dans un multitache coopératif, comme le ST (partiellement...), c'est à l'application de rendre la main. Donc quand elle plante, elle bloque tout le système, contrairement au préemptif. Quand ça arrive sur le ST, ce n'est pas de la faute de l'OS mais bien de l'appli. Si un accessoire est bien écrit et ne plante jamais, il ne bloquera jamais le système. Fin.

[stapha92]

au niveau hardware oui l'Amiga est meilleur mais en tant que machine polyvalente le St est devant.

Oui c'est ça. ça fait 1000 fois que tu le répètes mais tu n'a jamais argumenté ni répondu à mes arguments qui affirment le contraire.

Alors je recommence.

Le ST plus polyvalent ? Alors qu'il : 
 - possède moins de jeux de qualité. 
 - dispose de moins d'applications. 
 - couvre un domaine plus restreint. 
 - utilise un os plus fermé, plus bridé, moins personnalisable et moins performant. 
 - est beaucoup moins extensible et évolutif. De par son architecture comme par son os. 
Faut vraiment être un ST-Fanboy pour trouver le ST plus polyvalent. Le mig est mort car il a été supplanté par le PC. Quand c'est arrivé, il y a bien longtemps que le ST n'existait plus... 

ben voyons.... si on parle de demos alors là...... On en a déjà parlé tous les effets graphiques de l'amiga ont été portés sur St.

Non, on en a pas parlé. TU l'as affirmé, je t'ai donné des exemples prouvant le contraire et tu n'as plus répondu. Et tu reviens des années après pour nous asséner la même phrase erronée... 
Trouve moi sur ST : 
 - Un rotozoom en 320x200, pixels de 1x1, en 16 couleurs et 50 I/S (Intro de Brian the Lion) 
 - Un scrolling sur 2 playfieds multi-directionnel avec 1 effet d'eau sur le 1er et 1 avec parallaxe ligne par ligne sur le deuxième (Lionheart) 
Je pourrai continuer (note que le deuxième effet est réalisé PENDANT un jeu : ça devrait être facile pour le ST de le faire en démo...) mais on va faire plus simple : 
Prend un amiga et : 
 - Lance Deluxe paint en mode 320x200 32 couleurs 
 - Dessine 1 pixel avec la couleur 1 n'importe ou sur l'ecran. 
 - Sur la même ligne, colle 1 deuxième pixel avec la couleur 2, puis 1 pixel avec la couleur 3, etc. jusqu'à avoir 32 pixels collés avec 32 couleurs différentes. 
Regarde ton écran : tu as un effet impossible à reproduire avec un ST (et encore j'aurais pu utiliser un mode 64 couleurs ou HAM)... 
Ou encore : fais un dégradé avec 16 nuances de la même couleur... Impossible aussi... 
Tu veux rester dans les démos ? Trouve moi un voxel ou un rotozoom en 4096 couleurs (ou plutot en 512 couleurs) et on en reparle...

[stapha92]

le MMU est utile dès que 2 programmes, quel que soit la taille, fonctionnent en même temps.

C'est Faux. Elle sert à controler les accès mémoire, c'est tout. Qu'il y ait 1 programme ou 100. Tu penses que les accès mémoires sont moins risqués sur un ST parce qu'il est monotache ? Voyons, voyons, faisons un petit calcul : 
Sur un 68000, quand on accède à de la mémoire on utilise une adresse sur 24 bits, ce qui représente 16 Mo. Mais seules 1/32eme des adresses existent sur un 520 ST (1/16eme sur un 1040) : si on fait un accès en dehors de ces valeurs ça plante illico. Et, dans les valeurs qui existent, y en a un grand nombre qui feront tout planter si on y accède. Tu penses toujours que le ST ne peut pas faire d'accès mémoire illégal à cause d'un programme buggé ? 
Avec ton argument, on croirait que le ST n'a pas besoin de MMU et que le mig ne peut sans passer. Avec des programmes bien écrit, le ST comme le Mig n'ont pas besoin de MMU. D'ailleurs, un programme peut planter à cause d'un accès mémoire buggé qui se fait dans une zone allouée (essai un lea 20(PC),A0 puis un move.l #0,(A0) par exemple). Et là, la MMU ne réagira pas. Ou a l'inverse, si un programme stocke une valeur dans une zone mémoire inutilisée mais non réservée, il plantera seulement s'il y a une MMU ! 
Evidemment, les accès mémoire illicites sont dur à debugger quand ils ne provoquent pas de plantage... 
Justement, lors de l'écriture d'un programme, pour s'assurer que ce dernier ne fait pas d'accès mémoire illégal, la MMU est super pratique quand on utilise un débugger qui s'en sert. Pas de problème sur mig, les débuggers qui le faisaient étaient légion. Il suffisait de mettre une carte 68030 (ou 68020+MMU). Ce qui ne posait aucun problème aux développeurs d'application pro (pour les jeux, on se fout de vérifier que tous les accès mémoire sont valides, certains jeux mal écrits ne prenait meme pas la peine de la réserver...). Sur ST, tu faisais comment pour avoir une MMU ? Ben tu faisais pas... Y avait pas... 
Et après, le ST serait soi-disant mieux pour coder (certains l'ont répété ici à maintes reprises)... Le mig possède plus de langages classiques que le ST. Et en langage orienté objet l'écart est encore plus grand. 
La capacité d'indiquer au processeur, via sa MMU, quelles sont les zones mémoire auxquelles il a le droit d'accéder afin qu'une exception soit déclenchée s'il fait un accès non autorisé, c'est ça la protection mémoire. Rien de plus. 
Et si ça n'a pas été mis dans le mig, c'est pour une raison très simple : un processeur avec MMU coutait une fortune à cette époque. C'était réservé aux stations de travail sous Unix qui coutaient le prix d'une voiture... Ce n'est pas une erreur de Commodore, c'est un choix économique qui s'imposait. Commodore a fait pleins d'erreur. mais pas celle là. 

En somme on a 2 cas : 
 - une machine sur laquelle on a developpé d'autres OS. Comme quoi pleins d'utilisateurs ST considéraient eux aussi le TOS comme une merde... 
 - un os que l'on a adapté à d'autres machines (sous x86 ou PowerPC). Ce qui montre sa qualité. 
  

l'Atari est bien conçu : il est plus stable que l'amiga

Bien sur, tu t'appuies sur quoi pour étayer ça ?
Ah... sur rien... comme d'hab... 
Alors, pour la petite histoire : le mig est tellement instable qu'il possède le record de l'ordinateur qui est resté allumé le plus longtemps (16 ans !!!). Utilisé par une chaine hongroise, il a été arreté volontairement.

[stapha92]

pour reprendre Touko : "rien de ce que faisait le ST était infaisable sur amiga, le contraire par contre ...

Non mais tu es sérieux ? C'est un argument ça ? Parce qu'on ne fait pas de syncscroll sur le mig, tu en conclus ça ? LOL ! 
Le syncscroll permet de faire un Scroll Hardware. Quel interet puisque l'Amiga peut le faire d'origine ? Pour bousiller un écran ? En plus ton syncscroll ne permet pas de faire un scrolling horizontal au pixel près (les démos sont obligées de multiplier les écrans pour donner l'impression d'en faire un) alors que le mig n'a aucun problème pour ça. 
Touko n'a jamais dit que le mig pouvait utiliser toutes les méthodes du ST, il dit que le mig peut faire tout ce que le ST fait. Dans le cas que tu cites, le mig fait mieux que le ST.

[stapha92]

pas d'effet de zoom ni de rouleaux sur st :O j'ai du rever alors je doit avoir un ju qui fais cela sur mon ste :)

Tu as regardé l'effet de rouleaux ? ce ne sont pas des lignes décalées : il s'agit d'appliquer un stretching horizontal différent sur chaque ligne. 
Je veux bien que tu nous montre ça. Pour etre honnete, je n'y crois pas une seconde. Quand on sait, en plus, que BTL fait ça sur un layer et applique des rotations en temps réel  sur un autre layer qu'il fait scroller indépendamment, le tout en 50 i/s. Le STE est vraiment loin du compte...

[stapha92]

"encore un remarque complétement débile : pourquoi un autre ordi ne pourrait-il pas faire 213 étapes d'animations ? il faut aussi une copper super 3D multitâche préemptif pour faire ça ? n'importe quel ordinateur peut le faire, même un ZX spectrum, si sa RAM est suffisante. du reste, pour ta petite culture général, Prince of Persa sur ST fait plus de 400 étapes d'animations

Parce que sur le ST, il faut préshiter tous les sprites 16 fois, ça prend beaucoup de place. Sinon on le fait en temps réel : ça prend du temps (surtout pour des sprites qui font plus de 16 pixels de large). C'est possible sur un jeu avec un décor fixe et peu d'ennemis, genre POP mais impossible sinon. 
Y a aussi le problème du masque : il faut le stocker également, 25% de place en plus, ou le calculer en faisant un OR entre tous les plans : ça prend du temps également. 
Grace à l'utilisation d'un sprite pour le perso principal, le mig n'a besoin ni de préshifter, ni de stocker ou calculer un masque, ni d'appliquer une opération logique... 
(Et pour le reste, le blitter peut faire tout ça tout seul) 

pas de chance, une disquette ST peut se formater de 9 à 11 secteurs, de 1 à 85 pistes. On peut donc arriver à la même capacité d'une disquette amiga.

La meme capacité qu'une disquette amiga au format standard. Sur le mig aussi , on peut augmenter le nombre de secteur et/ou de pistes. Et allègrement dépasser le Mega... 
Mais bon, je vois pas pourquoi vous vous étripez là-dessus : le mig n'est pas meilleur que le ST parce qu'il peut mettre 100 ou 200 Kilos de plus sur une D7. C'est sans interet. 
Vous allez loin dans le fight : bientot vous allez comparer le nombre de lumens emis par la led ! LOL !

comment fais-tu une routine de rotation/zoom avec seulement 3 instructions ?  ( MOVE, WAIT, SKIP ) ?? 
C'est bien entendu impossible, c'est le CPU ou blitter qui se charge de cela, contrairement à la SNES qui se charge de cela en hardware.

La méthode utilise le blitter de façon astucieuse. Elle permet effectivement une rotation plus précise que la SNES. Mais elle a un défaut : au fur et a mesure qu'on se rapproche de 90° (ou de 270%), l'image est légèrement allongée verticalement. Pour la corriger, les auteurs ont choisi de se servir du copper pour supprimer les lignes en trop (il auraient pu utiliser le blitter pour ça aussi mais ça n'aurait pas permit de rester en 1 vbl en plein écran). Donc ça utilise les 2. Pour la rotation, tu as raison : le copper ne fait pas grand chose. C'est le blitter qui fait tout le boulot. 
Pour ce qui est du zoom simple ou de l'effet tunnel, c'est le copper qui le faire. J'explique : 
Le zoom d'une image se décompose en 2 parties : le traitement vertical des lignes et le traitement horizontal des pixels : 
        - Pour la partie vertical, le copper supprime ou dédouble des lignes en jouant avec les registres qui contiennent les adresses des bitplans à afficher à la fin de chaque ligne. S'il met une valeur qui correspond à l'adresse actuelle - la taille d'une ligne, la ligne actuelle est dédoublée. Si la valeur correspond à l'adresse actuelle + la taille d'une ligne, la ligne suivante est supprimée. 
        - Pour la partie horizontal : il joue avec le registre de décalage horizontal. Kezaco ? En fait, sur le mig , en jouant avec l'adresse des bitplans à afficher, on peut faire un scolling horizontal de 16 pixels. Pour pouvoir le faire au pixel près, il existe un registre qui va indiquer à Denise de combien de pixel on veut décaler l'ecran (de 0 a 15 pixels). Le copper modifie la valeur de ce registre plusieurs fois pendant l'affichage d'une ligne, ce qui provoquera la répétition du dernier pixel (zoom grossissant) ou le saut du pixel à venir (zoom rétrécissant). Cette astuce est appelée 102-trick car le registre d'offset se trouve à l'adresse $DFF102. En fait il existe 2 registres : un pour chaque playfield mais cette adresse correspond au 1er, c'est celui qu'on utilise le plus souvent. 
L'effet de tunnel n'est donc pas précalculé mais utilise exclusivement cette méthode. Simplement le niveau de zoom effectué n'est pas régulier mais différent à chaque ligne. Il n'utilise donc pas une petite copperlist qui se répete mais une copperlist qui fait tout l'écran. Il suffit ensuite de changer l'adresse de départ du playfield pour avoir la rotation. 
Donc il reste bien du temps cpu, surtout si on a de la fast-ram. Et, dans ce cas, vu le cpu de la Snes, il doit rester plus de ressource sur le mig. Sans fast-ram, je ne pense pas : le blitter doit être en nasty mode et ne doit pas laisser grand chose au cpu. 

ce tube n'est probablement pas mappée en temps réel. ça a l'air clairement précalculé sur sa moitié et mirroré. Le peu d'élément dans cette phase semble confirmer ma théorie, puisque l'effet doit bouffer de la mémoire. mais bon, je peux me tromper, car c'est techniquement faisable en temps réel. 

J'ai déjà répondu en expliquant que c'est bien du temps réel et j'ai expliqué comment ça marche (et comment veux tu mirrorer alors que ça tourne ?....)
Mais j'ajoute que, sans le 102-trick, ça n'est pas faisable en temps réel. Aucune démo ST ne propose quelque chose d'analogue (encore un effet non reproduit Ryosaeba)... 

même dans les meilleures megademo Amiga , cela n'existe pas.

C'est vrai (y en a bien un rotozoom 1x1 dans WOC mais pas aussi bien fait) ! mais lance Brian the Lion et regarde l'ecran de sélection de la langue ou l'écran d'accueil : en 320x200, 16 couleurs, pixels de 1x1 et en 1 vbl. Zoom + rotation puis stretching horizontal (vertical aussi mais ça n'a rien d'extraordinaire) de l'écran entier 

Je te parlais de la résolution de la rotation, PAS LA PRECISION. 512x448 contre 80x256 ! Je veux bien croire qu'on soft l'amiga pouvait faire un précision pour élevée que l'hardware de la SNES. Il suffisait de la coder la rotation en soft sur la SNES. Perso, je vois pas l'intérêt d'avoir 1024 degré de précision sur une image de 320x200. C'est aussi très ridicule de pavaner qu'on fait mieux sur la SNES sur une seul détail, quand tout le reste est à la ramasse. ( résolution, couleur, taille de la zone de travail, charge processeur, etc..)

Euh... 512x448, c'est le max en entrelacé. Les jeux c'est plutot 256x224 contre 320x256 pour le mig... 
Non, il est impossible de faire une rotation à la vbl avec le cpu. Sur le mig comme sur la Snes. D'ailleurs, niveau cpu, c'est la snes qui est à la ramasse. 
A tel point que pleins de cartouches contiennent un cpu pour pallier 
Je ne vois pas ce que tu veux dire par zone de travail. En tout cas la RAM vidéo fait 64 Ko sur la SNES. Moins qu'un mig ou qu'un ST. Ce sont ses tiles qui lui donnent l'avantage, comme toutes les consoles.

Pour ce qui est du mode 7 à la mario kart, c'est clair que tu as entièrement raison : je ne l'ai jamais vu dans un jeu. Pas sur un A500 en tout cas.

[ryosaeba]

pour reprendre Touko : "rien de ce que faisait le ST était infaisable sur amiga, le contraire par contre ...

Non mais tu es sérieux ? C'est un argument ça ? Parce qu'on ne fait pas de syncscroll sur le mig, tu en conclus ça ? LOL ! 
Le syncscroll permet de faire un Scroll Hardware. Quel interet puisque l'Amiga peut le faire d'origine ? Pour bousiller un écran ? En plus ton syncscroll ne permet pas de faire un scrolling horizontal au pixel près (les démos sont obligées de multiplier les écrans pour donner l'impression d'en faire un) alors que le mig n'a aucun problème pour ça. 
Touko n'a jamais dit que le mig pouvait utiliser toutes les méthodes du ST, il dit que le mig peut faire tout ce que le ST fait. Dans le cas que tu cites, le mig fait mieux que le ST.

  C'est du troll bien évidemment. J'aime bien tes interventions, elles sont toujours très intéressantes.

L'Amiga ou le St, je les adore tous les 2. Si tu parcours ce topic tantôt je suis pour le St, tantôt pour l'Amiga. 

Pour les effets demos Amiga, quels sont les effets qui n'ont pas été reproduites sur le st voir le ste) ?

[Doctoritchy]

ho on as un nouveaux drlfsilver :)

callmmeeee toi , meme le concepteur originel ne se prendrais pas autant la tete :o


sinon le a500 je le trouve en effet tres similaire , j'ai tester quelque jeu bha le scrolling est idem  je vois pas ou tu vois que ça rame ! , le ste peu afficher bien plus que 16 couleur j'ai un jeu (robin hood ) qui m'affiche 4096 couleur , et ça sacade pas ça scintille pas  et le son est tres propre , identique au a500

coter son je sais ce que est un bon son , car le son c'est mon job ! amiga atari ça vaut pas du broadcasting c'est sur , mais qualititativement ( apres mod sur le ste ) le son est parfaitement identique ! , bien que certain atari soit utilisé en studio son pour généré des effet 8bit , et par le passer  du sampling ! chose que amiga ne fesait pas pour les pro ( enfin si mais sur A3000 A4000  genloc video titrage video , montage , mais y avais des carte additionelle car d'origine c'est impossible ! )

de plus le mode ham , heuuuu c'est pourris  , on fait de la vraie video sur ste et de la video ham degeux sur amiga ...  et sur le ste ça rame pas

enfin  , je suis comme ryosaeba j'ai les deux machine je les aime bcp toute les deux , alors commencer as déclancher une seconde guerre mondiale pour prouver par un calcul pseudo scientifque par la racine carrée de napoléon , hermmmm ....

[dlfrsilver]

"encore un remarque complétement débile : pourquoi un autre ordi ne pourrait-il pas faire 213 étapes d'animations ? il faut aussi une copper super 3D multitâche préemptif pour faire ça ? n'importe quel ordinateur peut le faire, même un ZX spectrum, si sa RAM est suffisante. du reste, pour ta petite culture général, Prince of Persa sur ST fait plus de 400 étapes d'animations

Parce que sur le ST, il faut préshiter tous les sprites 16 fois, ça prend beaucoup de place. Sinon on le fait en temps réel : ça prend du temps (surtout pour des sprites qui font plus de 16 pixels de large). C'est possible sur un jeu avec un décor fixe et peu d'ennemis, genre POP mais impossible sinon. 
Y a aussi le problème du masque : il faut le stocker également, 25% de place en plus, ou le calculer en faisant un OR entre tous les plans : ça prend du temps également. 
Grace à l'utilisation d'un sprite pour le perso principal, le mig n'a besoin ni de préshifter, ni de stocker ou calculer un masque, ni d'appliquer une opération logique... 
(Et pour le reste, le blitter peut faire tout ça tout seul) 

pas de chance, une disquette ST peut se formater de 9 à 11 secteurs, de 1 à 85 pistes. On peut donc arriver à la même capacité d'une disquette amiga.

La meme capacité qu'une disquette amiga au format standard. Sur le mig aussi , on peut augmenter le nombre de secteur et/ou de pistes. Et allègrement dépasser le Mega... 
Mais bon, je vois pas pourquoi vous vous étripez là-dessus : le mig n'est pas meilleur que le ST parce qu'il peut mettre 100 ou 200 Kilos de plus sur une D7. C'est sans interet. 
Vous allez loin dans le fight : bientot vous allez comparer le nombre de lumens emis par la led ! LOL !

comment fais-tu une routine de rotation/zoom avec seulement 3 instructions ?  ( MOVE, WAIT, SKIP ) ?? 
C'est bien entendu impossible, c'est le CPU ou blitter qui se charge de cela, contrairement à la SNES qui se charge de cela en hardware.

La méthode utilise le blitter de façon astucieuse. Elle permet effectivement une rotation plus précise que la SNES. Mais elle a un défaut : au fur et a mesure qu'on se rapproche de 90° (ou de 270%), l'image est légèrement allongée verticalement. Pour la corriger, les auteurs ont choisi de se servir du copper pour supprimer les lignes en trop (il auraient pu utiliser le blitter pour ça aussi mais ça n'aurait pas permit de rester en 1 vbl en plein écran). Donc ça utilise les 2. Pour la rotation, tu as raison : le copper ne fait pas grand chose. C'est le blitter qui fait tout le boulot. 
Pour ce qui est du zoom simple ou de l'effet tunnel, c'est le copper qui le faire. J'explique : 
Le zoom d'une image se décompose en 2 parties : le traitement vertical des lignes et le traitement horizontal des pixels : 
        - Pour la partie vertical, le copper supprime ou dédouble des lignes en jouant avec les registres qui contiennent les adresses des bitplans à afficher à la fin de chaque ligne. S'il met une valeur qui correspond à l'adresse actuelle - la taille d'une ligne, la ligne actuelle est dédoublée. Si la valeur correspond à l'adresse actuelle + la taille d'une ligne, la ligne suivante est supprimée. 
        - Pour la partie horizontal : il joue avec le registre de décalage horizontal. Kezaco ? En fait, sur le mig , en jouant avec l'adresse des bitplans à afficher, on peut faire un scolling horizontal de 16 pixels. Pour pouvoir le faire au pixel près, il existe un registre qui va indiquer à Denise de combien de pixel on veut décaler l'ecran (de 0 a 15 pixels). Le copper modifie la valeur de ce registre plusieurs fois pendant l'affichage d'une ligne, ce qui provoquera la répétition du dernier pixel (zoom grossissant) ou le saut du pixel à venir (zoom rétrécissant). Cette astuce est appelée 102-trick car le registre d'offset se trouve à l'adresse $DFF102. En fait il existe 2 registres : un pour chaque playfield mais cette adresse correspond au 1er, c'est celui qu'on utilise le plus souvent. 
L'effet de tunnel n'est donc pas précalculé mais utilise exclusivement cette méthode. Simplement le niveau de zoom effectué n'est pas régulier mais différent à chaque ligne. Il n'utilise donc pas une petite copperlist qui se répete mais une copperlist qui fait tout l'écran. Il suffit ensuite de changer l'adresse de départ du playfield pour avoir la rotation. 
Donc il reste bien du temps cpu, surtout si on a de la fast-ram. Et, dans ce cas, vu le cpu de la Snes, il doit rester plus de ressource sur le mig. Sans fast-ram, je ne pense pas : le blitter doit être en nasty mode et ne doit pas laisser grand chose au cpu. 

ce tube n'est probablement pas mappée en temps réel. ça a l'air clairement précalculé sur sa moitié et mirroré. Le peu d'élément dans cette phase semble confirmer ma théorie, puisque l'effet doit bouffer de la mémoire. mais bon, je peux me tromper, car c'est techniquement faisable en temps réel. 

J'ai déjà répondu en expliquant que c'est bien du temps réel et j'ai expliqué comment ça marche (et comment veux tu mirrorer alors que ça tourne ?....)
Mais j'ajoute que, sans le 102-trick, ça n'est pas faisable en temps réel. Aucune démo ST ne propose quelque chose d'analogue (encore un effet non reproduit Ryosaeba)... 

même dans les meilleures megademo Amiga , cela n'existe pas.

C'est vrai (y en a bien un rotozoom 1x1 dans WOC mais pas aussi bien fait) ! mais lance Brian the Lion et regarde l'ecran de sélection de la langue ou l'écran d'accueil : en 320x200, 16 couleurs, pixels de 1x1 et en 1 vbl. Zoom + rotation puis stretching horizontal (vertical aussi mais ça n'a rien d'extraordinaire) de l'écran entier 

Je te parlais de la résolution de la rotation, PAS LA PRECISION. 512x448 contre 80x256 ! Je veux bien croire qu'on soft l'amiga pouvait faire un précision pour élevée que l'hardware de la SNES. Il suffisait de la coder la rotation en soft sur la SNES. Perso, je vois pas l'intérêt d'avoir 1024 degré de précision sur une image de 320x200. C'est aussi très ridicule de pavaner qu'on fait mieux sur la SNES sur une seul détail, quand tout le reste est à la ramasse. ( résolution, couleur, taille de la zone de travail, charge processeur, etc..)

Euh... 512x448, c'est le max en entrelacé. Les jeux c'est plutot 256x224 contre 320x256 pour le mig... 
Non, il est impossible de faire une rotation à la vbl avec le cpu. Sur le mig comme sur la Snes. D'ailleurs, niveau cpu, c'est la snes qui est à la ramasse. 
A tel point que pleins de cartouches contiennent un cpu pour pallier 
Je ne vois pas ce que tu veux dire par zone de travail. En tout cas la RAM vidéo fait 64 Ko sur la SNES. Moins qu'un mig ou qu'un ST. Ce sont ses tiles qui lui donnent l'avantage, comme toutes les consoles.

Pour ce qui est du mode 7 à la mario kart, c'est clair que tu as entièrement raison : je ne l'ai jamais vu dans un jeu. Pas sur un A500 en tout cas.

Salut Stapha92, franchement quand je lis toutes les infos que tu donnes, je suis limite content de m'être trompé 2 fois face à Rocky. Quand je vois la déculottée technique horizontale et verticale que tu lui mets et qu'il mérite bien clairement, ça vaut son pesant son cacahouète. Globalement il m'a accusé de dire n'importe quoi, mais c'est peanuts par rapport aux bétises qu'il nous chante sur ce topic.

J'ai pas l'aplomb suffisant sur les questions de programmation, ou encore sur certains point techniques concernant le ST et même l'amiga. Mais je ne suis pas un fanboy. Savoir si c'est commodore ou Atari qui a les plus grosses roubignolles je m'en tape, que Jay miner ait bossé avant pour Atari, je m'en contre tape.

Je vois simplement que le GEM du ST fonctionnellement parlant est ridicule à côté du Workbench de l'amiga, Sur le ST en dehors de jeux ne faisant pas pas à une grosse technique et qui sont intéressants, je me sens totalement à l'étroit, alors que sur l'amiga je sens qu'il y a de l'espace, et qu'on peut faire plus de choses, et je parle même pas de programmation. Juste de base l'utilisation.

Je déplore simplement le fait que même en 2015, au delà de l'adoration qu'on peut avoir pour une machine, les ataristes nous serinent toujours les mêmes vieilles rengaines complètement bidon. L'amiga comme tout machine a ses défauts et ses limites, ce que je ne m'explique pas c'est comment ils arrivent à des "L'atari ST ou STE aurait pu le faire", "Oh lalala, le ST avec son processeur 68K à 8Mhz, 12% de puissance en plus, mazeltov, mon cul sur la commode", "Vroom est plus rapide sur le ST 't'rends pas compte".

Toutes ces conneries je ne les comprends pas. J'ai eu l'occasion de parler vite fait avec Pierre Adane il y a de ça un moment lorsque j'ai fait préserver Snow Bros sur Amiga, je lui avais posé la question au sujet de l'amiga et du ST. Il m'avait répondu simplement en une phrase "L'amiga en a toujours eu plus dans le sac que le ST".

J'ai discuté aussi de face avec le programmeur de Flashback. Qui m'a expliqué que le jeu n'était pas convertible sur atari, même le ST. Causes : trop de sprites, palette de couleurs insuffisante (le jeu faisant un usage forcené de 32 couleurs différentes avec 16 pour les décors et 16 pour les sprites. Sur le ST les tests effectués en 8 couleurs pour les décors et 8 pour les sprites ont démontrés que les 16 couleurs du ST était simplement insuffisante pour avoir une bonne expérience visuelle du jeu. Le perso principal de Flashback utilise 800 frames différentes à lui seul sur les 1200 totales utilisées par tout les sprites du jeu (j'ai les planches IFF originales). Compte tenu de ce que tu as expliqué, comme quoi il faut préshifter 16 fois les sprites, laisse tomber quoi. Et les fanboy du ST de me sortir l'excuse fatale : "Mais euhhh le ST il était en fin de vie, c'est pour ça qu'ils ont pas voulu le sortir (genre le ST ou STE auraient pu le gérer)."

Honteux, même pas capable de se dire en toute honnêteté "Ben ouais, c'était trop pour le ST/E, dommage".

Est-ce nous sur Amiga on vient faire les cacos en disant "ouin ouin, ils ont pas sorti cadillac et dinosaurs (le jeu CPS1) sur amiga parce qu'ils étaient en fin de vie". Non, le jeu n'est pas sorti et c'est tant mieux, l'amiga 500 aurait vraiment morflé, pire qu'avec Street Fighter 2.

tiens Stapha92, t'as envie de percuter le nez de certains ataristes en anglais, ils me défoncent parce que je ne connais rien à la programmation et que je connais pas l'Amiga :

Lis ça, ça vaut son pesant d'or (je te le traduis en français) :

"En guise d'expérimentation DLFRsilver. Essaie les deux choses suivantes sur les deux machines en mode "user".

Sur le ST: move.w #0,$ff8240
Sur l'Amiga: move.w #0,$dff180

Un va gerber (crasher quoi) et l'autre pas. Quel comportement est le meilleur ?"

Je sais que ça va te faire rire, moi aussi ça m'a fait marrer. En quoi le fait que le registre de palette de couleur 00 du ST ne soit utilisable qu'en mode supervisor sur le 68000 est mieux que son comparse sur amiga, qui lui fonctionne en mode "user" ???

Commentaire par la suite d'un certain Frank B. qui me répond :

"T'as pas vraiment pigé le truc. Laisse-moi essayer de te l'expliquer à nouveau.
$dff180 est un registre d'un puce sur l'Amiga. Son équivalent sur le ST est $ff8240.

Le ST possède une forme de protection mémoire ou les programmes en mode utilisateur (pense à eux en tant que non root) ne peut pas les corrompre.

La table des vecteurs et les adresses des puces sont protégées à partir de l'accès du mode user sur le ST. Les programmes en mode user ne peuvent pas "trapper" un gestionnaire de trap ou un gestionnaire d'exception CPU.

Les programmes en mode user ne peuvent pas fouttre la merde partout dans les registres IO. Ils doivent être soit en mode superviseur ou bien il faut accéder à eux via l'OS.

L'Amiga n'a pas un tel mécanisme de protection. N'importe quel process peut fouttre la merde partout dans la machine. Le ST est bien meilleur à cet égard."

qu'est-ce que tu en penses ?

[Seb]

Je déplore simplement le fait que même en 2015, au delà de l'adoration qu'on peut avoir pour une machine, les ataristes nous serinent toujours les mêmes vieilles rengaines complètement bidon

Le problème c'est qu'au bout d'un moment, après x années d'attitude méprisante ou 30 messages condescendants, il se crée un réflexe d'autodéfense avec les posts (très) exagérés qui vont avec.

Certes, on est sur un thread "VS", mais les posts genre "AHAHAH TA MACHINE C'EST DE LA MERDE GROS NAZE" (je paraphrase mais l'idée est là), c'est moyen, surtout qu'on a tous un attachement "émotionnel" à ces machines.

Pour ce qui est des rengaines bidons et erreurs, il y en a des 2 cotés sur ce thread, et parfois des belles, donc il n'y a vraiment pas de quoi se pavaner :)

Ayant eu les 2 machines et ayant fait des demos il y a longtemps, un A500 est globalement clairement plus puissant qu'un ST, même si le ST a les quelques avantages qu'on connait (MIDI, un poil plus de puissance de calcul au 68000 par frame etc). Pourtant je préferais mon ST, même si j'adorais mon Amiga. Je dois être maso

Désolé si ca sonne moralisateur mais un peu de respect mutuel ne ferait de mal à personne car au final tout le monde décroche de ce thread parfois plus rempli de posts méprisants (ou de mauvaise foi) que de faits.

[Urbinou]

Globalement d'accord, on a un peu perdu le côté bon enfant rempli de mauvaise foi et de vannes foireuses qui caractérise les topics fight. Mais les posts techniques de Stapha92 sont un régal à lire, moi qui n'ai jamais tâté de la prog amiga, j'ai appris plein de trucs

[Invité]

ce tube n'est probablement pas mappée en temps réel. ça a l'air clairement précalculé sur sa moitié et mirroré. Le peu d'élément dans cette phase semble confirmer ma théorie, puisque l'effet doit bouffer de la mémoire. mais bon, je peux me tromper, car c'est techniquement faisable en temps réel. 

Bien sur que c'est du temps réel,et n'importe quelle machine avec une interruption hsync peut faire ça @50/60 fps, sauf le st 
ce n'est pas un mapping de texture, juste un repositionnement des lignes du plan,comme l'effet d'axelay sur snes . .
Le roto zoom en plus lui c'est une autre histoire .

En tout cas la RAM vidéo fait 64 Ko sur la SNES. Moins qu'un mig ou qu'un ST. Ce sont ses tiles qui lui donnent l'avantage, comme toutes les consoles.

Là c'est un peu réducteur, si tu parles pour l'économie de mémoire ROM/VRAM tu as raison, si c'est pour justifier que les jeux snes sont plus détaillés que sur amiga non .
La snes code ses couleurs sur 15 bits, avec 8 palettes de 16 couleurs et avec jusqu'à 4 plans indépendants de scrolling,128 sprites qui sont plus flexibles sur la majorité des points .
Cependant l'effets du roto/zoom de BtL sur amiga est infaisable sur snes, tout comme sur Md ou PCE .

[ryosaeba]

ce tube n'est probablement pas mappée en temps réel. ça a l'air clairement précalculé sur sa moitié et mirroré. Le peu d'élément dans cette phase semble confirmer ma théorie, puisque l'effet doit bouffer de la mémoire. mais bon, je peux me tromper, car c'est techniquement faisable en temps réel. 

Bien sur que c'est du temps réel,et n'importe quelle machine avec une interruption hsync peut faire ça @50/60 fps, sauf le st 
ce n'est pas un mapping de texture, juste un repositionnement des lignes du plan,comme l'effet d'axelay sur snes . .
Le roto zoom en plus lui c'est une autre histoire .

En tout cas la RAM vidéo fait 64 Ko sur la SNES. Moins qu'un mig ou qu'un ST. Ce sont ses tiles qui lui donnent l'avantage, comme toutes les consoles.

Là c'est un peu réducteur, si tu parles pour l'économie de mémoire ROM/VRAM tu as raison, si c'est pour justifier que les jeux snes sont plus détaillés que sur amiga non .
La snes code ses couleurs sur 15 bits, avec 8 palettes de 16 couleurs et avec jusqu'à 4 plans indépendants de scrolling,128 sprites qui sont plus flexibles sur la majorité des points .
Cependant l'effets du roto/zoom de BtL sur amiga est infaisable sur snes, tout comme sur Md ou PCE .

Ne lisant pas tous les posts, je suppose que vous parlez de l'arrière-plan de Brian the lion ?

[Invité]

Oui ..

[Invité]

Vroom n'est pas plus rapide sur le ST. Pourtant les routines d'affichages sont les même et n'exploitent absolument pas le chipset du mig. la seule différence se situe au niveau du son : c'est bien plus gourmand  de reproduire un sample sur ST. Et comme en plus Vroom reproduit l'effet doppler, il faut pouvoir faire varier la tonalité. Ce que même un STE ne sait pas faire de façon hardware (et c'est pour ça que même un STE ne peut pas reproduire un mod avec la même qualité que le mig...).

si j'ai bien compris le STE ne sait pas faire de bend en hard ?

[ryosaeba]

Oui ..

sans te commander, tu pourrais mettre un lien de cet effet ? Grand merci.

[dlfrsilver]

Oui, et comme je le disais moi-même, l'amiga et ne serait-ce qu'au vu des infos données par Stapha92, je pensais que l'amiga en avait plus dans le sac que le ST ou STe, mais à ce point c'est du délire.

J'en viens même à me dire qu'au final l'Amiga n'aura peut-être pas été poussé à fond, et ça c'est moche.....

[stapha92]

    C'est du troll bien évidemment. J'aime bien tes interventions, elles sont toujours très intéressantes.

L'Amiga ou le St, je les adore tous les 2. Si tu parcours ce topic tantôt je suis pour le St, tantôt pour l'Amiga. 

Pour les effets demos Amiga, quels sont les effets qui n'ont pas été reproduites sur le st voir le ste) ?

Moi aussi j'aime bien les 2 machines, tu le sais. J'avais posté dans ton tread "Pourquoi j'aime le ST".

J'ai déjà eu l'occasion de le dire sur ce thread. Tout comme j'ai eu l'occasion de dire ce que je pense du STE...

Des effets ? Zoom ou rotation en 1x1 16 couleurs, triple ou quadruple playfield avec scrolling, voxels ou rotozoom en 4096 couleurs par exemple.

Par contre, ce qui est certain, c'est le niveau des démos est plus élevé sur le ST. Surement parce que sur le mig, ça c'est dispersé entre l'OCS et l'AGA, entre les 68000, 68020-30, 68060.

Il y a un regain d'interet depuis quelques temps envers les demos A500 depuis quelques temps. A l'inverse il y a de plus en plus de démos qui ne fonctionnent que sur un STE avec 2 Mo voire plus. Je trouve ça dommage...

[Invité]

Oui ..

sans te commander, tu pourrais mettre un lien de cet effet ? Grand merci.

Pas de soucis 

https://youtu.be/m-IDcTW8JQ4?t=9m20s

Par contre, ce qui est certain, c'est le niveau des démos est plus élevé sur le ST

Je plussois, je préfère la mise en scène des demos amiga mais le niveau du coding sur ST est vraiment plus impressionnant avec tout en soft .

[dlfrsilver]

    C'est du troll bien évidemment. J'aime bien tes interventions, elles sont toujours très intéressantes.

L'Amiga ou le St, je les adore tous les 2. Si tu parcours ce topic tantôt je suis pour le St, tantôt pour l'Amiga. 

Pour les effets demos Amiga, quels sont les effets qui n'ont pas été reproduites sur le st voir le ste) ?

Moi aussi j'aime bien les 2 machines, tu le sais. J'avais posté dans ton tread "Pourquoi j'aime le ST".

J'ai déjà eu l'occasion de le dire sur ce thread. Tout comme j'ai eu l'occasion de dire ce que je pense du STE...

Des effets ? Zoom ou rotation en 1x1 16 couleurs, triple ou quadruple playfield avec scrolling, voxels ou rotozoom en 4096 couleurs par exemple.

Par contre, ce qui est certain, c'est le niveau des démos est plus élevé sur le ST. Surement parce que sur le mig, ça c'est dispersé entre l'OCS et l'AGA, entre les 68000, 68020-30, 68060.

Il y a un regain d'interet depuis quelques temps envers les demos A500 depuis quelques temps. A l'inverse il y a de plus en plus de démos qui ne fonctionnent que sur un STE avec 2 Mo voire plus. Je trouve ça dommage...

Merci dans tout les cas pour toutes les explications que tu as donné. C'est juste fabuleux, et ça mérite des applaudissements.

Je ne sais pas si tu es programmeur de métier, mais franchement, hallucinant :)

[stapha92]

callmmeeee toi , meme le concepteur originel ne se prendrais pas autant la tete :o

sinon le a500 je le trouve en effet tres similaire , j'ai tester quelque jeu bha le scrolling est idem  je vois pas ou tu vois que ça rame !

Et quand ai-je dit qu'un scrolling sur STE ramait ? Tu prends un ton moqueur pour me faire dire des choses que je n'ai jamais dites : les lecteurs jugeront...

Par contre montre moi un jeu avec :
 - Plus de 100 couleurs (avec un écran non fixe).
 - Un scrolling sur plusieurs layers
 - Un parallaxe à la ligne
Aucun jeu STE n'intègre un seul de ces éléments. Sur le mig on trouve des jeux qui intègrent les 3...

C'est clair : très similaire...

le ste peu afficher bien plus que 16 couleur 

Bien sur qu'il peut, grace aux interruptions horizontales. Il ne fait que redefinir des couleurs dans la palette. Le mig le fait aussi, en mieux. Mais, de base un STE affiche 16 couleurs.

j'ai un jeu (robin hood ) qui m'affiche 4096 couleur , et ça sacade pas ça scintille pas  et le son est tres propre , identique au a500

Montre nous ça...

coter son je sais ce que est un bon son , car le son c'est mon job ! amiga atari ça vaut pas du broadcasting c'est sur , mais qualititativement ( apres mod sur le ste ) le son est parfaitement identique ! , bien que certain atari soit utilisé en studio son pour généré des effet 8bit , et par le passer  du sampling ! chose que amiga ne fesait pas pour les pro ( enfin si mais sur A3000 A4000  genloc video titrage video , montage , mais y avais des carte additionelle car d'origine c'est impossible ! )

Je ne répondrai même pas sur les studios. Du troll...

Par contre tu t'y connais en son. Donc tu dois savoir que :
  - Un STE n'ayant que 2 canaux, pour en produire 4, il lui faut en mixer 2 par canal de façon software. Du coup, la résolution du sample n'est plus que de 7 bits.
  - Pour jouer un mod, il faut pouvoir faire varier la fréquence de restitution. Mais le STE en est incapable. Il faut donc modifier les échantillons avec le 68000. Meme en appliquant un filtrage bi-linéaire, la qualité serait moins bonne. Et vu que le 68000 doit, en temps réel, se contenter de simplement supprimer ou copier des valeurs. La qualité est encore moindre.

(J'imagine que je n'ai pas besoin de détailler puisque tu t'y connais en son)

Donc le STE a un son aussi bon que le mig uniquement s'il n'y a pas variation de tonalité et qu'il n'y a que 2 canaux.
Ah j'oublias ! Si on se contente de 2 canaux, le mig peut reproduire des échantillons de 14 bits. Encore raté pour le STE...

de plus le mode ham , heuuuu c'est pourris  , on fait de la vraie video sur ste et de la video ham degeux sur amiga ...  et sur le ste ça rame pas 

Montre nous ça...

enfin  , je suis comme ryosaeba j'ai les deux machine je les aime bcp toute les deux , alors commencer as déclancher une seconde guerre mondiale pour prouver par un calcul pseudo scientifque par la racine carrée de napoléon , hermmmm ....

J'ai eu les 2 pour les utiliser à l'époque. Pas pour les collectionner aujourd'hui. je sais de quoi je parle.
Ou tu as vu un calcul pseudo scientifique ? Je donne des faits, c'est tout. S'ils ne te plaisent pas, je n'y peux rien. Si tu veux m'attaquer, fais le au moins de façon élégante...

J'aime le ST moi aussi. ça m'ait arrivé de le défendre sur ce thread parce que je trouvais que les pro-st le faisaient mal. J'ai posté sur des threads en faveur du ST sur ce site.
Le ST a des défauts. Mais il a été conçu dans l'urgence. On peut les comprendre.

Par contre le STE est le plus gros mensonge d'Atari : il avait été annoncé comme l'amiga-killer. Moi qui ai toujours été pro-Atari, j'attendais sa sortie avec impatience : on nous promettait des caracteristiques qui explosaient le mig et un OS à l'avenant. Quelle déception ! Une évolution minime faite uniquement pour pouvoir afficher des choses qui paraissaient au niveau du mig dans les pubs (4096 couleurs ! blitter ! samples à 50 Khz !)...

Le ST a apporté l'architecture 16 bits dans les foyer. Il a permis à beaucoup, dont moi, de découvrir le 68000. Il représente un gap dans l'informatique personnelle. Il aura toujours mon respect pour ça.

Le STE a apporté quoi ? Une machine moins bonne que la concurrence... Pour moi c'est une arnaque...

[ryosaeba]

    C'est du troll bien évidemment. J'aime bien tes interventions, elles sont toujours très intéressantes.

L'Amiga ou le St, je les adore tous les 2. Si tu parcours ce topic tantôt je suis pour le St, tantôt pour l'Amiga. 

Pour les effets demos Amiga, quels sont les effets qui n'ont pas été reproduites sur le st voir le ste) ?

Moi aussi j'aime bien les 2 machines, tu le sais. J'avais posté dans ton tread "Pourquoi j'aime le ST".

J'ai déjà eu l'occasion de le dire sur ce thread. Tout comme j'ai eu l'occasion de dire ce que je pense du STE...

Des effets ? Zoom ou rotation en 1x1 16 couleurs, triple ou quadruple playfield avec scrolling, voxels ou rotozoom en 4096 couleurs par exemple.

Par contre, ce qui est certain, c'est le niveau des démos est plus élevé sur le ST. Surement parce que sur le mig, ça c'est dispersé entre l'OCS et l'AGA, entre les 68000, 68020-30, 68060.

Il y a un regain d'interet depuis quelques temps envers les demos A500 depuis quelques temps. A l'inverse il y a de plus en plus de démos qui ne fonctionnent que sur un STE avec 2 Mo voire plus. Je trouve ça dommage...

Oui; C'est vrai que j'ai acheté mon amiga et revendu mon St à l'époque, j'ai eu un peu de mal. Le St m'a manqué. J'ai longtemps préféré l'Atari. Depuis quelques années, j'ai (re)découvert l'Amiga et la claque qui va avec.

[ryosaeba]

Oui ..

sans te commander, tu pourrais mettre un lien de cet effet ? Grand merci.

Pas de soucis 

https://youtu.be/m-IDcTW8JQ4?t=9m20s

Par contre, ce qui est certain, c'est le niveau des démos est plus élevé sur le ST

Je plussois, je préfère la mise en scène des demos amiga mais le niveau du coding sur ST est vraiment plus impressionnant avec tout en soft .

Je me demande si je n'ai pas vu cela en démo....bon d'accord ce n'est pas un jeu. Je vais fouiller un peu dans les demos récentes et voir sur un autre forum si on n'en n'a déjà pas parlé.