Re: GUERRE ST-AMIGA, FIGHT ! (Mauvaise foi assurée)

[Jacques Atari]

Mon dieu quelle horreur perdre de la RAM pour charger un TOS

je me demande parfois si tes posts sont destiné uniquement à obtenir des suppos de dflfrsilver

Il y a pris goût...

[Copper]

T'es jaloux voilà tout

[babsimov]

Mais, il y aussi l'AGA. Tu n'as pas connu ce chipset, mais en gros son problème était que le blitter et le copper sont restés les mêmes que l'OCS de 1985 et tournaient à 3.5 mhz comme à l'origine.

 mais quelle farce Amiga..donc tu veux dire qu'après 8 ans de recherche, ils ont sorti un truc encore pire que le A500 ?  mais comment est-ce possible ?

Tout d'abord ce n'est pas pire que le A500, vu que l'AGA est plus performant que l'OCS/ECS, ensuite comme je le disais, au contraire ça démontre que dès l'OCS le blitter a le potentiel pour gérer 256 couleurs. D'ailleurs récemment sur un forum anglais (j'ai oublié lequel) j'avais trouvé la liste des registres de l'OCS et il y a avait justement deux registres dans l'OCS/ECS réservé pour le futur pour 7 et 8ème plan planar. 

Par contre, oui l'AGA aurait du sortir bien plus tôt et proposer plus. Mais l'argent avait été mis dans le AAA qui lui était largement plus performant que l'AGA. Mais, avec le recul, je pense que c'était une erreur d'avoir voulu trop faire d'un seul coup avec le AAA. Un truc intermédiaire comme la AA+ en 1990 aurait été amplement suffisant tout en restant peu cher à produire dans lignée de l'OCS.

Mais Atari non plus n'a pas brillé par ses performances. En 1989 le STE était à peine au niveau de l'Amiga de 1985. Et en 1993, s'il n'y avait pas le DSP dans le Falcon la machine était bridée par un bus 16 bit pour un processeur 32 bit, ça c'est une belle décision stupide des ingénieurs, que ceux de Commodore ne feront pas. Pourquoi mettre un 68030 avec un mode burst qui ne pourra de tout façon pas être utilisé sur un bus 16 bt.
De plus il me semble avoir lu que le mode true color chunky était particulièrement lent sur le Falcon, au point que les démomaker préféraient faire du C2P.

je viens de regarder à nouveau la vidéo de Sim City 2000, c'est juste déplorable...vous faites les malin avec vos " ah ben nous on a des jeux qui sont encore sorti "..mais ils sont juste injouables, une vraie farce.

Mais Sim City 2000 c'est le cas extrême. La plupart des jeux tournaient en 320x256 à l'époque et là les performances de l'AGA suffisaient. Comme je l'ai dit, en 1994 l'AGA devait être remplacé par le AA+ qui justement augmentait les performance de façon à pouvoir utiliser sans ralentissement la haute résolution en 256 couleurs. Il y avait même un mode chunky 16 bit (voir 24 bit selon certaines infos).

et c'est vraiment le comble que vous ayez à émuler version MAC pour que cela soit jouable..effarant... je comprends mieux pourquoi vous aviez absolument voulu un émulateur Atari ST, c'était pour jouer à des jeux rapides et décents.

Mais cela n'aurait pas été plus facile d'acheter un Atari ou un Mac ?

Et le fait qu'il soit plus jouable en émulation MAC montre aussi qu'il y avait des problème d'optimisation dans le code de la version Amiga, vu que l'émulation MAC l'affichage dans la même résolution tournait mieux sur la même configuration. 

A partir de 95, l'émulation MAC permettra aussi d'avoir des titres qui ne seront pas porté (à condition d'avoir un 040 minimum bien souvent). Et c'est aussi à cette époque que le marché des cartes RTG va vraiment décoller, puisqu'il était quasi certain que le AA+ et Hombre ne sortiraient plus.

Ainsi le blitter peut gérer 256 couleur en 15 khz sans trop de problème, mais par contre dès qu'on passe en 31 khz là ça devient lent, voir assez lent. La palette de l'AGA passe de 4096 à 24 bit et il y un mode HAM8 ajouté (262144 couleurs simultanées dans toutes les résolutions, de mémoire).

oui en effet j'ai vu, je pensais pas que c'était lamentable à ce point. je pense que  Sim City 2000 aurait pu être rapide même dans cette reso s'il avait utilisé ses propres routines au lieu d'Intuition.

Mais justement Sim City 2000 ne me parait pas du tout utiliser les routines intuition....

Regarde la différence de l'interface entre Sim City 2000 et Colonization (qui lui utilise parfaitement les routines intuition et qui tourne sans problème en haute résolution, vu que je l'ai joué sur mon 1960)





Tu vas me dire oui mais colonization là c'est pas de la haute résolution. Par défaut non, mais on peut changer la résolution pour profiter de la haute résolution, normal c'est un jeu qui respecte totalement le système. 

Mais aucune des ses machines ne fut commercialisé, car entre temps la direction de Commodore a changé et le nouveau responsable des ingénieurs (celui à l''origine du PCjunior IBM, un échec retentissant) a annulé tous les projets de son prédécesseurs pour qu'on pense que c'était des mauvais projets.

ce n'est pas plus mal pour l'humanité.  j'imagine encore le CO2 qui cela aurait produit pour rien du tout

Je dirais que c'est plutôt le Falcon qui a été produit pour rien du tout, vu qu'Atari a abandonné ce marché pour aller vers les consoles.... combien de CO2 dans notre atmosphère à cause du Falcon... surement trop 

Voilà j'espère que tu ne m'en voudras pas de t'avoir fait ce récapitulatif de la situation à l'époque.

non pas du tout, très bon résumé pour conclure le fail de Commodore... on gardera tous en mémoire le C64, le seul et vrai succès de Commodore,

Sauf que même si ça te plait pas, l'Amiga est entré dans l'histoire comme iconique de ces années là....

Comme le montre récemment la série Strangers Things saison 4

https://www.amigaimpact.org/forums/topic/stranger-things-et-a1000/

Episode 1 et 6, c'est sympa de le voir. Bon comme dans toutes les séries ce qu'on voit à l'écran n'est pas conforme à la réalité, mais ce qui compte c'est qu'en 1986 c'est bien l'Amiga qu'il sont allé chercher pour représenter le top informatique du moment.

Peut être, mais à mon avis faut pas trop rêver. Maxis a simplement tout fait au processeur je pense et n'aurait probablement pas utilisé le DSP, car il aurait fallu vraiment tout réécrire pour une plateforme à base de 680x0 pour laquelle ils pouvaient se contenter de reprendre tel quel le code du MAC. 
Le Falcon ne représentait surement pas un marché suffisamment rentable pour que MAXIS ait payé pour réécrire le jeu spécifiquement pour un DSP. D'ailleurs Maxis n'a même pas considéré la gamme ST pour ce jeu dirait on.

c'est clair qu'exploiter le Falcon nécessitait des programmeurs qui ne contentait pas de compiler les sources C PC sur la machine  (comme font les codeurs Amiga ). 

Les programmeurs américains faisaient souvent ça nuance. Et aussi ceux issus du ST à l'époque des portages.

c'est fou quand on y pense, de 1985 et à 1992 le jeux Amiga étaient compilé à partir des sources Atari, et de 1992 à 199x, ils ont été compilé à partir des sources PC.  Heureusement vous avez eu SOTB quand même 

Jusqu'en 1989 l'Amiga a été en effet sous exploité à cause du ST, normal on prend le plus petit dénominateur commun, les jeux étaient nivelé par le bas (le ST). Mais à partir de 1989 ce sera fini, et oui heureusement que SOTB est passé par là.
Les éditeurs européens exploitaient beaucoup mieux l'Amiga que les américains. Et les américains délaisseront le ST assez tôt.

Et après 1991 l'Amiga aura de nombreuses exclusivité dont certain seront porté sur PC, à commencer par The Settlers 

Tiens avant 91



et après 1991 :

 
Plus de jeux après que le ST soit mourru 

Mais bien entendu sur toute sa carrière l'Amiga a eu beaucoup de jeux qui était infaisable à l'identique sur ST, mais ça te plait pas non plus parce que, que ça te plaise ou non, l'Amiga est plus puissant que le ST.

[stapha92]

@Stapha92 : intéressant, je ne savais pas qu'en poussant le blitter à fond sur amiga, c'est comme si le CPU lockait à 5,2Mhz, alors que sur ST, on se retrouve de 8mhz à 0mhz, donc machine "vérouillée".....

Et encore : 5,2 Mhz c'est le pire des cas. Si tu t'arranges pour faire des instructions longues, la différence est moindre. Dans le meilleur des cas, tu fais des divisions et le cpu ne perd que quelques % (et le blitter ne ralentit presque pas)

Le blitter peut aussi travailler en mode "nasty". Dans ce cas, il ne rend pas la main au 68000. A utiliser quand on ne veut pas paralléliser. Ce qui arrive plus souvent qu'avec le ST puisqu'il y a le copper. Là ou simple dégradé de fond gène l'utilisation du blitter sur ST, ça ne gène en rien sur le mig.

Le mode normal est surtout là permettre une gestion propre du multitâche par le système.

[Zarnal]

Mon dieu quelle horreur perdre de la RAM pour charger un TOS

C'est pareil pour le Relokick.

Ce qui peut être ennuyeux si le jeu demande vraiment 1Mo ( ou plus ou moins 768k, en faisait abstraction du système ).

Et même un kickstart  1.3 sur une DK, ce n'est pas une solution miracle. C'est loin de tout arranger systématiquement.

[Copper]

Tout d'abord ce n'est pas pire que le A500, vu que l'AGA est plus performant que l'OCS/ECS, ensuite comme je le disais, on contraire ça démontre que dès l'OCS le blitter a le potentiel pour gérer 256 couleurs. D'ailleurs récemment sur un forum anglais (j'ai oublié lequel) j'avais trouvé la liste des registres de l'OCS et il y a avait justement deux registres dans l'OCS/ECS réservé pour le futur pour 7 et 8ème plan planar. 

Disons qu'il y'avait de la place après BPL6PTL et après BPL6DAT dans la plage des registres ca se voit très bien quand on regarde ici et là.

En revanche pour la palette il y avait juste assez de place pour mettre 32 registres de plus après COLOR31 (pour permettre un vrai mode 64 couleurs) mais l'ECS a pris certains emplacements... Au final il n'y pas eu de nouveaux registres de couleurs et la palette de 256 couleurs de l'AGA est malheureusement paginée (mais le pire est la gestion du 24 bits car on est quasiment obligé de le faire composante par composante)

Quand au potentiel du Blitter ce n'est pas exact il aurait quand même fallut l'accélérer car mine de rien entre 16 et 256 couleurs il y'a 2 fois plus de données à transférer...

[stapha92]

le mig attribue ses canaux DMA de façon dynamique : le cpu recevra un accès quand ce sera nécessaire. Il devra juste attendre 3 cycles à chaque fois.

si tu changes la priorité du blitter, en effet le CPU récupère la main tous les 4 cycles..mais alors le blitter "n'est plus à fond"

Pas tout à fait : le CPU récupère la main à la demande (toujours ces canaux DMA dynamiques) : s'il fait la pire des divisions, le blitter restera à fond pendant 161 cycles par exemple...
Idem s'il y a de la fast : le blitter ne ralentira que lorsque le cpu voudra lire ou écrire en chip. Ce qu'on évite de faire bien sur. Dans le pire des cas, le blitter perd 1 cycle sur 7 car le 68000 a au minimum 4 cycles entre tous ses accès à la RAM.

Donc tu as tort sur le chiffre mais raison sur le principe, le blitter n'est effectivement plus à fond.

Mais ça aurait pu être pire :
Le blitter du ST a son alternative : le shared mode. Dans le mode c'est 64 cycles chacun son tour. Donc 2 x moins rapide pour tout le monde. Ce qui est stupide...
Même avec une répartition statique, il y avait moyen de faire mieux : en alternant les tours plus rapidement, le blitter n'irait pas moins vite mais le 68000 bien plus vite. Et, accessoirement, ça permettait d'atteindre un grain assez fin pour pouvoir gérer les interruptions (parce qu'avec 0 à 64 cycles ça n'est pas assez précis dans pleins de cas).
Meme si ça ne pourrait jamais être aussi performant qu'une répartition à la volée, il y avait moyen d'avoir quelque chose de mieux juste en passant de 64 cycles à 8 par exemple.

[Copper]

C'est pareil pour le Relokick.

Ce qui peut être ennuyeux si le jeu demande vraiment 1Mo ( ou plus ou moins 768k, en faisait abstraction du système ).

Et même un kickstart  1.3 sur une DK, ce n'est pas une solution miracle. C'est loin de tout arranger systématiquement.

Oui mais c'est toujours moins horrible que de charger le TOS

[Zarnal]

C'est pareil pour le Relokick.

Ce qui peut être ennuyeux si le jeu demande vraiment 1Mo ( ou plus ou moins 768k, en faisait abstraction du système ).

Et même un kickstart  1.3 sur une DK, ce n'est pas une solution miracle. C'est loin de tout arranger systématiquement.

Oui mais c'est toujours moins horrible que de charger le TOS

Il faudra que j'essaye. Mais ce n'est pas une priorité.

[stapha92]

En 1989 le STE était à peine au niveau de l'Amiga de 1985

Je peux t'assurer que non : le STE est très loin du mig (même du A1000). Il n'y a toujours pas match.

Je suis passé du ST au mig mais quand Atari a annoncé "l'amiga killer", j'y ai cru et l'idée de retourner chez Atari ne me déplaisait pas (J'ai adoré mes Atari 8 bits). Quand j'ai vu que c'était une évolution mineure au niveau hardware et inexistante au niveau software, j'ai été très déçu. Et quand j'ai vu les pubs qui jouaient sur l'ambiguïté pour faire croire que le STE valait un mig, mon respect pour Atari a disparu.

[Copper]

C'était une façon de parler... Tout le monde sait bien que le STE n'était pas au niveau de l'Amiga 500

[Zarnal]

Ils aiment tous les suppos dans leur...   ...post.

[babsimov]

En 1989 le STE était à peine au niveau de l'Amiga de 1985

Je peux t'assurer que non : le STE est très loin du mig (même du A1000). Il n'y a toujours pas match.

Je suis passé du ST au mig mais quand Atari a annoncé "l'amiga killer", j'y ai cru et l'idée de retourner chez Atari ne me déplaisait pas (J'ai adoré mes Atari 8 bits). Quand j'ai vu que c'était une évolution mineure au niveau hardware et inexistante au niveau software, j'ai été très déçu. Et quand j'ai vu les pubs qui jouaient sur l'ambiguïté pour faire croire que le STE valait un mig, mon respect pour Atari a disparu.

C'est aussi ce que j'avais pensé à l'époque en voyant les spécifications du STE, ils ont essayé d'avoir un Amiga sur le papier.

J'aimerais par contre bien savoir à quelle fréquence tourne le blitter du STE. Parce que si c'est 8 mhz pour pas faire mieux que celui de l'Amiga qui tourne à 3.5 mhz s'est encore plus décevant pour le Atari de Jack Tramiel.

PS : Stapha92, pourrait consulter ta boite mail privé ? Merci.

[Jacques Atari]

Finalement, ceux qui parlent le plus du ST(e), c'est les Amigaleux...

[rocky007]

Par contre, oui l'AGA aurait du sortir bien plus tôt et proposer plus. Mais l'argent avait été mis dans le AAA qui lui était largement plus performant que l'AGA. Mais, avec le recul, je pense que c'était une erreur d'avoir voulu trop faire d'un seul coup avec le AAA. Un truc intermédiaire comme la AA+ en 1990 aurait été amplement suffisant tout en restant peu cher à produire dans lignée de l'OCS.

avec des "si" c'est facile de refaire l'histoire... il faut juste constater le désastre de l'amiga 1200

Mais justement Sim City 2000 ne me parait pas du tout utiliser les routines intuition....

je peux me tromper, mais pour moi il utilise bien Intuition, ça m'étonnerait qu'il se soit amusé à recoder toute une interface, surtout qu'elle n'existe pas sur PC si j'ai bien vu.  Et il utilise aussi la GUI native du MAC.
elle a peut être été par contre customisée graphiquement, je ne sais pas à quel point c'était faisable facilement sur Amiga

Sauf que même si ça te plait pas, l'Amiga est entré dans l'histoire comme iconique de ces années là....

Comme le montre récemment la série Strangers Things saison 4

ben ça devrait pas t'interloquer ? un Amiga dans un série qui s'appelle Stranges Things ?

et vu la pauvreté scénaristique de cette saison #4, je pense que le scénario a été écrit par dlfrsilver

[rocky007]

Mais ça aurait pu être pire :
Le blitter du ST a son alternative : le shared mode. Dans le mode c'est 64 cycles chacun son tour. Donc 2 x moins rapide pour tout le monde. Ce qui est stupide...

sauf que tu n'es absolument pas obligé de respecter les 64 cycles, le CPU peut rendre la main bien avant.

[Jacques Atari]

Y'a eu un Amiga dans les Goonies 2.0? J'étais pas au courant, je ne regarde pas la télé remarquez... C'est bien, ça va mettre un coup de boost au prix de l'Amiga sur eBay, lui qui était salement à la traîne derrière le ST. Comme souvent...

[rocky007]

Episode 1 et 6, c'est sympa de le voir. Bon comme dans toutes les séries ce qu'on voit à l'écran n'est pas conforme à la réalité, mais ce qui compte c'est qu'en 1986 c'est bien l'Amiga qu'il sont allé chercher pour représenter le top informatique du moment.

ouais et comme par hasard par utilisé par une fille dans une famille de barakis  "on pas pas le pognon pour une console, mais on trouvé un amiga monochrome dans une poubelle"... on est très loin de l'image "top" / "pro" de l'amiga qu'on veut nous vendre ici

[Jacques Atari]

Ah? Ils ont tenté de jouer les pros ici, tu es sûr? Moi je n'ai vu que d'anciens joueurs bourrins devenus des kékés ou des has been...

[rocky007]

il parait qu'à la Nasa....blabla

[Jacques Atari]

Ouais, et tout le Japon était équipé Amiga. Et les USA aussi. Et Pluton aussi...

[Firebird]

Firebird,

Pour le fond en tunnel qui scrolle, je pense qu'ils étaient limités par la quantité de RAM.

Techniquement, la méthode utilisée est compatible avec un scrolling horizontal. Le problème est que l'effet de zoom est obtenu, en partie, en modifiant le nombre de pixel à scroller (de 0 à 15) à des positions précises pour faire disparaitre certains pixels.
Cela est fait par le copper car lui seul peut obtenir la précision nécessaire.

Si tu ajoute un scroll horizontal, la première valeur à mettre n'est plus 1 mais le nombre de pixels du scroll initial + 1.
Ce qui signifie que tu dois avoir 16 copperlists pour que ton scroll soit compatible avec l'effet. Et elle ne sont pas petites puisque les pixels à supprimer sont différents à chaque ligne : on ne peut pas utiliser de boucle...
Tu peux aussi jouer sur la texture mais c'est pire : il te faut 16 fois la même image pré-shiftée.
Edit : en fait, cette solution aurait été moins gourmande en RAM. 


Pour les palmiers par contre, il s'agit d'un sprite multiplexé qui n'est pas très haut. Donc pas RAM supplémentaire pour un scroll. La seul contrainte technique serait que ce sprite soit utilisé à d'autres hauteurs. Ce qui limiterait le scroll vertical. Mais ce n'est pas le cas : les seuls autres sprites sur l'écran sont ceux du HUD et du personnage et ce sont les même qui sont réutilisés.

D'ailleurs, sur la version AGA, il ont remplacé les sprites multiplexés par un 2eme playfield en 16 couleurs. Il auraient pu l'animer verticalement sans surcout et ils avaient 1 Mo de RAM en plus. Je pense donc que c'était voulu.

Okay. Merci Stapha92.
Donc scroller le tunnel rotatif était théoriquement possible.

Fallait juste à s'emm**der un peu plus. J'imagine que les devs ont dû juger le résultat satisfaisant et se sont probablement dit qu'il ne fallait pas abuser des bonnes choses. ;-)

En tout cas c'est assez surprenant quand ont pense que Brian dans sa version OCS tourne sur un chipset qui date de fin 84...

[dlfrsilver]

Y'a eu un Amiga dans les Goonies 2.0? J'étais pas au courant, je ne regarde pas la télé remarquez... C'est bien, ça va mettre un coup de boost au prix de l'Amiga sur eBay, lui qui était salement à la traîne derrière le ST. Comme souvent...

Arrête tes histoires, j'ai acheté 5 atari STF et STE pour 50 balles. ça vaut pinuts, à l'inverse, les prix de l'amiga sont plus haut alors qu'il est plus courant..... moche.

[dlfrsilver]

Par contre, oui l'AGA aurait du sortir bien plus tôt et proposer plus. Mais l'argent avait été mis dans le AAA qui lui était largement plus performant que l'AGA. Mais, avec le recul, je pense que c'était une erreur d'avoir voulu trop faire d'un seul coup avec le AAA. Un truc intermédiaire comme la AA+ en 1990 aurait été amplement suffisant tout en restant peu cher à produire dans lignée de l'OCS.

avec des "si" c'est facile de refaire l'histoire... il faut juste constater le désastre de l'amiga 1200

Mais justement Sim City 2000 ne me parait pas du tout utiliser les routines intuition....

je peux me tromper, mais pour moi il utilise bien Intuition, ça m'étonnerait qu'il se soit amusé à recoder toute une interface, surtout qu'elle n'existe pas sur PC si j'ai bien vu.  Et il utilise aussi la GUI native du MAC.
elle a peut être été par contre customisée graphiquement, je ne sais pas à quel point c'était faisable facilement sur Amiga

Sauf que même si ça te plait pas, l'Amiga est entré dans l'histoire comme iconique de ces années là....

Comme le montre récemment la série Strangers Things saison 4

ben ça devrait pas t'interloquer ? un Amiga dans un série qui s'appelle Stranges Things ?

et vu la pauvreté scénaristique de cette saison #4, je pense que le scénario a été écrit par dlfrsilver

Ah je bosse à Hollywood maintenant ? Arrête ton léchage de Fiak, ça marchera pas avec moi 

[Firebird]

@Stapha92 : intéressant, je ne savais pas qu'en poussant le blitter à fond sur amiga, c'est comme si le CPU lockait à 5,2Mhz, alors que sur ST, on se retrouve de 8mhz à 0mhz, donc machine "vérouillée".....

Et encore : 5,2 Mhz c'est le pire des cas. Si tu t'arranges pour faire des instructions longues, la différence est moindre. Dans le meilleur des cas, tu fais des divisions et le cpu ne perd que quelques % (et le blitter ne ralentit presque pas)

Le blitter peut aussi travailler en mode "nasty". Dans ce cas, il ne rend pas la main au 68000. A utiliser quand on ne veut pas paralléliser. Ce qui arrive plus souvent qu'avec le ST puisqu'il y a le copper. Là ou simple dégradé de fond gène l'utilisation du blitter sur ST, ça ne gène en rien sur le mig.

Le mode normal est surtout là permettre une gestion propre du multitâche par le système.

C'est peut-être ce qui explique que bien qu'il soit clocké à un peu plus du double de la fréquence (8MHz) de celui de l'Amiga, le Blitter du STe a des perfs équivalentes. Du moins si on se réfère aux tests d'anim de BOBs effectués sur A500 et STe.









En revanche, dans un Amiga OCS/ECS un peu de Fast améliore les perfs.
Blitter et 68K doivent pouvoir travailler chacun dans leur coin en même temps.

Le simple fait d'ajouter de la Fast dans mon A600 (68000@7Mhz sans autre accélération), m'a fait gagné quelques fps à Dread, et a quasiment fait disparaitre les petits ralentissements qui pouvaient apparaitre dans Gradius (Tinyius) et Bubble Bobble (TinyBooble). Ce qui prouve, au passage, que C= aurait dû mettre un minimum de Fast dans les A500/+/A600. 256Ko de Fast aurait sans doute été possible sans faire exploser le prix de la machine.

[stapha92]

Mais ça aurait pu être pire :
Le blitter du ST a son alternative : le shared mode. Dans le mode c'est 64 cycles chacun son tour. Donc 2 x moins rapide pour tout le monde. Ce qui est stupide...

sauf que tu n'es absolument pas obligé de respecter les 64 cycles, le CPU peut rendre la main bien avant.

Absolument pas : le cpu ne peut avoir aucun accès pendant les 64 cycles. Tu peux faire des trucs sur les registre du blitter pendant les 64 cycles du cpu mais pas le contraire.

[rocky007]

c'est exactement ce que j'ai écris : tu n'es pas obligé d'attendre les 64 cycles du CPU

[stapha92]

@Stapha92 : intéressant, je ne savais pas qu'en poussant le blitter à fond sur amiga, c'est comme si le CPU lockait à 5,2Mhz, alors que sur ST, on se retrouve de 8mhz à 0mhz, donc machine "vérouillée".....

Et encore : 5,2 Mhz c'est le pire des cas. Si tu t'arranges pour faire des instructions longues, la différence est moindre. Dans le meilleur des cas, tu fais des divisions et le cpu ne perd que quelques % (et le blitter ne ralentit presque pas)

Le blitter peut aussi travailler en mode "nasty". Dans ce cas, il ne rend pas la main au 68000. A utiliser quand on ne veut pas paralléliser. Ce qui arrive plus souvent qu'avec le ST puisqu'il y a le copper. Là ou simple dégradé de fond gène l'utilisation du blitter sur ST, ça ne gène en rien sur le mig.

Le mode normal est surtout là permettre une gestion propre du multitâche par le système.

C'est peut-être ce qui explique que bien qu'il soit clocké à un peu plus du double de la fréquence (8MHz) de celui de l'Amiga, le Blitter du STe a des perfs équivalentes. Du moins si on se réfère aux tests d'anim de BOBs effectués sur A500 et STe.









En revanche, dans un Amiga OCS/ECS un peu de Fast améliore les perfs.
Blitter et 68K doivent pouvoir travailler chacun dans leur coin en même temps.

Le simple fait d'ajouter de la Fast dans mon A600 (68000@7Mhz sans autre accélération), m'a fait gagné quelques fps à Dread, et a quasiment fait disparaitre les petits ralentissements qui pouvaient apparaitre dans Gradius (Tinyius) et Bubble Bobble (TinyBooble). Ce qui prouve, au passage, que C= aurait dû mettre un minimum de Fast dans les A500/+/A600. 256Ko de Fast aurait sans doute été possible sans faire exploser le prix de la machine.

Le blitter du ste n'est pas plus de 2 fois plus rapide. Il est 13% plus rapide, comme le cpu.
Et attention aux tests de ce genre : Ce n'est pas un hasard si les bobs n'ont pas de trous...

Dans la vrai vie, et pas dans une démo, pour afficher un bob en cookie -cut, le mig a besoin d'une seule passe avec les 4 canaux activés (la source, le masque, la destination et l'ecriture). Le STE n'a que 3 canaux, il est donc obligé de faire 2 passes (on applique le masque, puis on applique la source) avec les 3 canaux à chaque fois. Donc pour faire le même travail, il doit faire 50% d'accès mémoire en plus et demander 2 fois plus de boulot au cpu. 50% en plus pour 13% de cycles : Il est perdant sans compter le reste. Et ceci s'ajoute aux problèmes donc j'ai parlé : dans lotus STE, pour conserver les interruptions il blitte par morceaux qui font entre une et 8 lignes. Donc on multiplie les blits pour chaque objet et chaque blit fait perdre 24 cycles de plus (voir la vidéo qui détaille lotus STE que j'ai posté).
Demande au gars qui a codé le test d'ajouter un dégradé de fond et tu verras...

Au final, dans ce jeu, le blitter du ST est plus lent que le cpu. Alors imagine par rapport au blitter du mig qui, lui, explose le 68000...
Donc on a un jeu sans scrolling ou tout se fait au cpu et au blitter qui est beaucoup plus fluide sur le mig alors qu'il affiche plus de choses et que les 2 composant cités tournent 10% moins vite. Cherchez l'erreur...

Oui une extension de fast, permet d'accélérer Dread de façon visible. Surtout si elle est assez grande pour stocker le code et les textures. Et là ton A600 va au moins aussi vite qu'un megaSTE à 16 Mhz.

Le choix de Commodore était normal vu le prix de la RAM, comme celui de la non gestion d'une MMU vu le prix des processeurs qui en avaient.
Ils auraient pu ajouter un controleur dans l'A500 : ça aurait permit que toutes les extensions soient en fast et pas en slow. Mais, pour être honnête, il n'y avait pas beaucoup de jeux qui exploitaient ça (et ceux que tu cites auraient pu être fluide sans fast...), c'était plutôt pour les applications que c'était intéressant. Et dans ce cas, on n'utilisait pas le même type d'extension de toute façon (et là c'était de la fast).

Qui aurait pu prédire Dread à l'époque ? Vraiment personne.

[stapha92]

c'est exactement ce que j'ai écris : tu n'es pas obligé d'attendre les 64 cycles du CPU

Désolé j'avais mal compris. Au temps pour moi.

[Copper]

C'est dingue à chaque fois que j'apprend quelque chose sur le ST ou le STE c'est toujours pire que ce que je pensais

Sur Amiga pour faire du cookie cut en une seule passe il faut quand même dupliquer le masque pour chaque bitplane et surtout utiliser le mode interleave (faire se suivre les lignes de chaque bitplane)

[epc35]

Oui, l'Amiga, un hardware très ambitieux vu sa date de conception, mais qui aura laissé la plupart des developpeurs sur le coté de la route.