Re: GUERRE ST-AMIGA, FIGHT !!!

[dlfrsilver]

slt tt le monde^^

je voie encore que le st vs amiga existe encore^^

le st c'est pourrie, les composant sont cheap parce que c'est fais en Israêl

l'amiga ça cartonne parce que c'est pas fais pour les pauvres^^

y a pas un forum atari tout pourrie aussi ? je sait pas sa fais tellement lontemps que de vous lire sa m'as rappellé des souvenirs

dlfrsilver : super génial de travail, merci :)

Non les puces n'était pas fabriqué en Israel mais dans les pays asiat. Cependant il est clair que pour tirer les prix vers le bas au maximum, les composants de l'atari ST étaient clairement pas de 1ère qualité. C'est juste une évidence, à l'époque de sa vente, la RAM, les TTL coutaient très cher, donc forcément pour casser le cout de l'ordinateur, ils ont fait déjà un hardware à la va vite, et ils ont utilisés des composants à pas cher.

De rien pour Ambermoon :)

[rocky007]

oui sur l'amiga, mais sur le ST, non, car comme je l'expliquais, le jeu ralenti sérieusement à certains moment même sur un A1200 doté d'un 68030. Et ça hors des moments ou on évolue dans les environnements 3D. Les zones de couleurs sont gérées par le copper, donc ça ne bouffe rien sur l'amiga.

Mais voilà, comment un ST avec un simple 68000 pourrait mieux faire qu'une machine full 32 bits avec un 68030 tournant à 50 mhz sur la partie combats avec les animations et zooms sans compter les sprites de 128x128 et 256x256 ?

je n'aurais pas eu le culot que comparer à la version A1200    bien évidement, je parlais de la version A500

[rocky007]

justement, ambermoon ayant 3 zones différentes horizontales bien distinctes, il était facile d'avoir sa propre palette par chacune de ces zones et un dégradé dans la zone d'action.

Pour les séparations haut/bas oui c'est possible et plein de jeux le faisaient sur ST (cf screenshots au dessus)

Pour les séparation gauche/droite, non, c'est juste trop compliqué sur ST, ca demande une synchro sur chaque ligne, ca bouffe un temps fou de changer la palette 2 fois par ligne et il faut intégrer le code du jeu entre les changements de palette au cycle près, tout ca en s'assurant qu'il soit constant, ce qui est une utopie pour un jeu, sauf peut être un avec à scrolling vertical dans lequel 50% de la frame serait dédié à faire des centaines de movem. Dans ce cas on pourrait placer ces instructions dedans mais même là ca serait de la folie.

Ce genre de magouille rend l'utilisation de branchements conditionnels dans le code intégré entre les changements de palettes très pénibles à gérer, et tout ce qui est tests avec des "if". Un jeu est truffé de "if" pour la partie gameplay et d'instructions à temps non constant pour les calculs 3D (muls, divs etc).
On peut compenser le temps non constant des "if" et des branchement en remplissant le code de NOPs pour "égaliser" le temps de chaque branchement, mais ca fait évidemment perdre du temps machine.

Bref, c'était une belle astuce de demomaker, ca marchait sur papier et dans les demos, mais c'était en pratique inutilisable pour un jeu commercial.

L'écran de Delta Force ci-dessous utilisait cette méthode, en changeant la palette une fois au debut de la ligne, et une fois au milieu (l'effet met du temps à demarrer, on voit mieux vers 3:00).
Le reste du temps machine était probablement utilisé à faire des copies des zones du texte avec toutes les tailles de zoom de 15 couleurs déjà précalculées. Donc du bon movem.l à temps constant, sans "if", ni calculs 3D, ni code de gameplay, probablement juste de l'indexation avec une table (lookup table). C'est à l'opposé de ce qu'on voit dans un jeu niveau code.

Beaucoup de jeux étaient fait en C au passage, soit à 100% soit avec quelques routines en assembleur pour les choses critiques. Le mix C / Assembleur aurait rendu la tache d'intégrer du code à temps constant entre les synchros de palette encore plus impossible :)

Pour la petite histoire, Glenn Corpes m'avait raconté qu'il avait codé Populous en C puis plus tard Powermonger en Assembleur mais qu'il avait trouvé que le passage a l'Assembleur n'avait finalement pas valu le coup pour ce jeu.

en fait, pour être encore plus précis, Atari fournissaient des devkit en C, c'était la base de travail pour de nombreux développeurs, même si en général les studios développent leurs propres librairies en interne.  Fallait vraiment être motivé pour créer un jeu entier en assembleur, c'est vraiment se torturer pour rien.   Comme tu le dis , l'idéal étant les routines critiques en assembleur ( sprite, scroll etc. ), et la structure du jeu en C.

[dlfrsilver]

oui sur l'amiga, mais sur le ST, non, car comme je l'expliquais, le jeu ralenti sérieusement à certains moment même sur un A1200 doté d'un 68030. Et ça hors des moments ou on évolue dans les environnements 3D. Les zones de couleurs sont gérées par le copper, donc ça ne bouffe rien sur l'amiga.

Mais voilà, comment un ST avec un simple 68000 pourrait mieux faire qu'une machine full 32 bits avec un 68030 tournant à 50 mhz sur la partie combats avec les animations et zooms sans compter les sprites de 128x128 et 256x256 ?

je n'aurais pas eu le culot que comparer à la version A1200    bien évidement, je parlais de la version A500

La version A500 et A1200 partagent exactement le même code. Il y a un petit programme au démarrage qui détermine si on est sur un A500 avec 1mo de chip, ou bien si le CPU est un 68000 ou 68020 par exemple. Si c'est un A500 avec 68000, le lanceur executera le programme faisant usage à fond du blitter (AM2_BLIT). Si l'amiga est un 500 surgonflé, il lancera le programme (AM2_CPU), ce qui permet d'avoir de la 3D au sol et au plafond. La version A500 n'a de textures qu'aux murs, mais pas au sol et plafond (comme wolfenstein 3D en fait :) ) dans sa version blitter. La full 3D est réservée aux possesseur d'amiga 500 et 1200 dotés de cartes acceleratrices avec 68020 et 68030.

La ou je veux en venir, c'est que pour faire tourner la version CPU d'Ambermoon, il faut au minimum un 68020, l'idéal étant un 68040 voir 68060 (la c'est plein pot, et y a plus aucun ralentissement !), mais pas un 68000 !

D'ou ce que je disais au sujet de l'atari ST, si pour faire tourner la version utilisant les routines softwares il faut un 68020 au minimum, explique moi comment un ST de base (je parle même pas d'un STE ) peut faire tourner ce jeu, avec son 68000 ?

Est-ce que tu comprends pourquoi aussi la version ST ne pouvait être qu'une reprise d'amberstar, et non l'utilisation du code de la version (étendue) amiga ?

[rocky007]

mais on est bien d'accord qu'ambermoon tourne (mal) sur une A500 de base en 68000...il pourrait donc tourner ( tout aussi mal ) sur un ST...

[dlfrsilver]

la version de base pour A500 fait un usage lourd du blitter. Le jeu n'a pas de version CPU (ou les routines sont software) pour le 68000.

Le jeu serait injouable sur ST. Pour être honnête, sans copper et sans blitter, je pense que Jurie aurait laissé tomber la version A500 de base.

[rocky007]

regardes à nouveau les 2 exemples que je t'ai donné : wolfenstein qui tourne en plein écran ou le doom qui lui tourne avec les plafonds, reliefs et sol... preuve que cela aurait pour tourner sans problème aussi bien que la version A500..

[dlfrsilver]

regardes à nouveau les 2 exemples que je t'ai donné : wolfenstein qui tourne en plein écran ou le doom qui lui tourne avec les plafonds, reliefs et sol... preuve que cela aurait pour tourner sans problème aussi bien que la version A500..

Mmhhh.... je suis pas vraiment sur qu'un A500 puisse faire tourner wolfenstein 3D en plein écran.... il me semble que le jeu exploite une particularité du STE.

Le doom n'est qu'une démo technique par contre, Ambermoon est un jeu, avec une IA, et tout un tas de paramètres  à gérer. C'est pour ça aussi que la fênetre n'est pas en plein écran. Le CPU a beaucoup à gérer uniquement en terme de logique de jeu.

Tu sais comment moi qu'on ne peut pas comparer une démo et un jeu, coder une démo pour faire des effets particuliers c'est jouable, mais un jeu est une histoire de compromis. Les folies faites dans les démos mangent sur ST/E quasiment 100% de CPU. Un jeu c'est bien plus que ça, tu as le programme principal, les interruptions, l'IA, des sprites, un scrolling à gérer, et donc il y a un choix à faire.

tout les pros du jeu vidéo avec qui j'ai pu en discuter face à face me l'ont dit, ce que les démomakers sur ST faisaient, ils ne pouvaient pas s'en servir dans les jeux qu'ils codaient, c'était trop couteux en temps machine.

[rocky007]

wolfenstein tourne sur un ST normal également, avec une fenêtre légèrement plus réduite mais qui reste toujours 2x supérieur à ambermoon.

je ne pense vraiment pas que le CPU doit gérer tant de chose que cela dans la phase 3D.  cela m'a l'air très très léger, puisque c'est le CPU qui gère la 3D de toute façon. 

concernant le rapport demo / jeu, ce n'est pas tout à fait vrai, de nombreuses techniques sont exploitables dans les jeux, la preuve en est avec les moteurs 3D, les routines de sprites, etc..  même si le jeu ne peut bénéficier de toutes les effets d'une démo, les optimisations qu'un codeur demo a l'habitude de faire servent dans les jeux.  Une autre limitation est surtout la mémoire, dans les démos on se prive pas d'utiliser parfois 1mb de mémoire juste pour un effet, dans un jeu cela est impossible.

cependant, il y a qd même pas mal de jeux qui ont utilisé des techniques pointue issue des démos ( les jeux Thalion par exemple )

[dlfrsilver]

wolfenstein tourne sur un ST normal également, avec une fenêtre légèrement plus réduite mais qui reste toujours 2x supérieur à ambermoon.

je ne pense vraiment pas que le CPU doit gérer tant de chose que cela dans la phase 3D.  cela m'a l'air très très léger, puisque c'est le CPU qui gère la 3D de toute façon. 

concernant le rapport demo / jeu, ce n'est pas tout à fait vrai, de nombreuses techniques sont exploitables dans les jeux, la preuve en est avec les moteurs 3D, les routines de sprites, etc..  même si le jeu ne peut bénéficier de toutes les effets d'une démo, les optimisations qu'un codeur demo a l'habitude de faire servent dans les jeux.  Une autre limitation est surtout la mémoire, dans les démos on se prive pas d'utiliser parfois 1mb de mémoire juste pour un effet, dans un jeu cela est impossible.

cependant, il y a qd même pas mal de jeux qui ont utilisé des techniques pointue issue des démos ( les jeux Thalion par exemple )

J'ai vu Wolfenstein par le biais de ta vidéo. C'est très bon pour un atari STE, franchement y a rien à redire.
Mais pour avoir joué pendant de nombreuses heures sur Ambermoon, Wolfenstein 3D sur STE est clairement en dessous techniquement malgré sa fenêtre plein écran.

Pourquoi ? Parce qu'Ambermoon est entièrement animé (du sol au plafond sur A1200), et bénéficie de texture animées. C'est pas juste de la 3D face pleine, tout est rempli d'animation. La routine de Michael Bittner est une routine Planar to Chunky qui tourne à l'aide du copper, le CPU est donc déchargé de ça.

Donc contrairement à ce que tu dis ce n'est pas le CPU qui gère la 3D. Bittner s'est cassé le crâne pour pondre cette routine hardware spéciale "chunky", et cette dernière ne pourrait pas tourner sur un CPU à 7 ou 8 mhz. L'amiga (et le ST s'il était concerné) ne le supporteraient pas en terme de puissance de calcul requis.

La 3D d'Ambermoon est au pixel en 1x1, c'est dire à quel point c'est fabuleux de voir ça sur une machine qui n'a pas la puissance CPU pour fournir ce genre d'effet.

Sur Amiga tout les effets spéciaux, la 3D, les sprites, les graphismes tout est géré par les puces customs de l'amiga. Le CPU s'occupe de gérer l'AI, la préparation des données graphiques pour le copper et le blitter, la logique du jeu (pour le programme en mode hardware).

ensuite comme le disait Erik Simon lui-même, les gens s'en foutent des astuces tordues utilisées sur Atari ST, c'est d'ailleurs pour ça qu'ils ont arrêté. Ca leur prenait trop de temps à mettre en place dans leurs programmes, et comme les gens n'étaient pas intéressé, ils y ont mis un stop.

Enfin, malgré toutes les astuces techniques utilisées dans leurs jeux, nombre de jeux de thalion sont très faibles, et au final peu intéressant, et en plus ces dites techniques flinguent littéralement malgré l'hyper optimisation du code les cycles CPU disponibles......

Un jeu comme Enchanted Lands bouffe 100% de CPU à cause des techniques utilisées, le même jeu sur amiga utilise 20% du CPU en terme de charge.

Enchanted Lands était un bel effort sur Atari ST, mais le jeu est juste ridicule, il est très bon par rapport à ce que peu fournir un ST ou un STE, mais n'ayant aucun intêret sur Amiga, c'est un jeu de plateforme tout à fait moyen, limite banal.

Wings of Death c'est pareil : le jeu est joli, mais pffff merde quoi c'est un jeu carrément poussif sur Amiga, en plus ils se sont plantés aussi bien dans la palette (programmé n'importe comment), et la musique de l'introduction du jeu est buggée (oui oui, ça n'a pas de rapport avec le rendu sonore, Hippel a utilisé les mêmes samples entre les deux versions, sauf que sur amiga son driver son fait pas le boulot correctement....). Bref un shoot très moyen quand on connait des jeux de légende comme hybris ou Battle Squadron, bien plus poussés techniquement et graphiquement.

je passe la liste, Prehistoric Tale, c'est du petit jeu style DP, Tangram est un bon jeu (ptet bien celui ayant le plus d'intérêt), Dragon flight est très bon, mais avec des bugs qui tuent le jeu.... Bref.....

Lionheart et Ambermoon sont au final les joyaux de la couronne, au delà de l'aspect technique, quel plaisir de jouer à ces jeux là. Quel dommage qu'ils n'aient pas compris avant que le ST/STE étaient clairement trop limités pour ce qu'ils voulaient accomplir en terme de créativité......

[rocky007]

J'ai vu Wolfenstein par le biais de ta vidéo. C'est très bon pour un atari STE, franchement y a rien à redire.
Mais pour avoir joué pendant de nombreuses heures sur Ambermoon, Wolfenstein 3D sur STE est clairement en dessous techniquement malgré sa fenêtre plein écran.

tu te trompes, afficher un écran entier est très gourmand, le réduire de moitié l'aurait soir fluidifié, soit permis un plus grand nombre de couleurs

Pourquoi ? Parce qu'Ambermoon est entièrement animé (du sol au plafond sur A1200), et bénéficie de texture animées. C'est pas juste de la 3D face pleine, tout est rempli d'animation. La routine de Michael Bittner est une routine Planar to Chunky qui tourne à l'aide du copper, le CPU est donc déchargé de ça.

Donc contrairement à ce que tu dis ce n'est pas le CPU qui gère la 3D. Bittner s'est cassé le crâne pour pondre cette routine hardware spéciale "chunky", et cette dernière ne pourrait pas tourner sur un CPU à 7 ou 8 mhz. L'amiga (et le ST s'il était concerné) ne le supporteraient pas en terme de puissance de calcul requis.

La 3D d'Ambermoon est au pixel en 1x1, c'est dire à quel point c'est fabuleux de voir ça sur une machine qui n'a pas la puissance CPU pour fournir ce genre d'effet.

c'est impossible , tout simplement.  tu ne peux avoir une tel résolution avec du copper chunky, la 3D est bel est bien gérée par le CPU, pas par le copper.  de plus, la 3D est en temps réel, comment veux-tu construire une copper list sans cpu ? 

Enfin, malgré toutes les astuces techniques utilisées dans leurs jeux, nombre de jeux de thalion sont très faibles, et au final peu intéressant, et en plus ces dites techniques flinguent littéralement malgré l'hyper optimisation du code les cycles CPU disponibles......ue le ST/STE étaient clairement trop limités pour ce qu'ils voulaient accomplir en terme de créativité......

je te l'accorde, les jeux Thalion ne sont pas les meilleures, clairement.

[oliver27]

Tout les ST que j'ai récupéré j'ai du passer leur tôle à la toile éméri et au "frameto" pour retirer la rouille. A l'inverse, tout mes amiga, que ce soit 500 ou 1200 ont quelques pigment de rouille, mais rien de bien méchant.

AH ! enfin quelqu'un qui a rencontré le même problème que moi pour la corruption Disquette et Disque dur !!!

Mon 500 qui est en révision 5 (donc de loin pas de dernière génération) est parfait autant au niveau de la carte-mère que de la protection métallique, très légèrement jauni au niveau du boîtier mais rien du tout par rapport au 1040STF que j'ai pu trouver il y a quelques mois.

En comparaison des deux carte-mères, c'est le jour et la nuit, l'Amiga fait très pro, l'Atari c'est le champ de bataille, des câbles, des condos, des bidules dans tous les sens, en plus le câble floppy soudé à la carte-mère... En plus un bordel à démonter les protections métalliques et celles du style carton avec couche alu.

De même pour mon 1200, de légères traces de rouille sur le shielding métallique, le boîtier non jauni, quelques touches de clavier le sont.

[Seb]

mais on est bien d'accord qu'ambermoon tourne (mal) sur une A500 de base en 68000...il pourrait donc tourner ( tout aussi mal ) sur un ST...

En fait non, ca aurait tourné beaucoup plus mal sur un ST. Tout aussi impressionnant qu'il soit, Wolfenstein a "juste" des murs texturés verticaux, c'est le cas idéal pour du mapping et les precalculs divers, c'est bien pour ca que le 1er Wolfenstein sur PC était comme ca.

Ambermoon a bien plus de choses comme le sol et le plafond (beaucoup plus compliqués et couteux que des murs verticaux car sol et plafond sont en vraie rotation, les murs eux sont juste "stretchés" pour donner une illusion de rotation).
Le boulot de Ray sur Wolfenstein reste excellent quand on regarde le hardware sur lequel ca tourne.

concernant le rapport demo / jeu, ce n'est pas tout à fait vrai, de nombreuses techniques sont exploitables dans les jeux, la preuve en est avec les moteurs 3D, les routines de sprites, etc..

Oui et non, les ruses de demos viennent souvent avec beaucoup de contraintes qui limitent fortement la liberté des jeux. L'utilisation de hardscroll dans Enchanted Land les a obligés a ne pas avoir de double buffering, probablement pour des raisons de mémoire. Ca veut dire du tearing, des sprites qui peuvent clignoter et le besoin de connaitre la position de chaque sprite à l'écran pour les afficher au bon moment et éviter le clignotement. Sur le papier c'est sympa mais c'est vraiment une contrainte dont un game designer et un programmeur se passeraient.

La stabilité du hardscroll semble aussi avoir été un problème sur le Shifter de certains ST dans certains pays.


Les techniques de sprites issues des demos genre code généré sont très gourmandes en mémoire. Ca marche bien dans une demo quand c'est UN même sprite répété 30 fois à l'écran. Ca devient inutilisable quand on a besoin de 10 sprites différents.

Steve Bak (Goldrunner, StarRay, Return To Genesis) est un exemple de gars qui utilisait des ruses typiques de demos. Ses jeux étaient sympa mais on voyait très bien qu'il y avait de grosses contraintes pour le gameplay et l'environnement. Au final il s'est sans doute interdit plein de choses avec ces contraintes, au profit de la fluidité et de l'exploit technique.

[dlfrsilver]

J'ai vu Wolfenstein par le biais de ta vidéo. C'est très bon pour un atari STE, franchement y a rien à redire.
Mais pour avoir joué pendant de nombreuses heures sur Ambermoon, Wolfenstein 3D sur STE est clairement en dessous techniquement malgré sa fenêtre plein écran.

tu te trompes, afficher un écran entier est très gourmand, le réduire de moitié l'aurait soir fluidifié, soit permis un plus grand nombre de couleurs

Pourquoi ? Parce qu'Ambermoon est entièrement animé (du sol au plafond sur A1200), et bénéficie de texture animées. C'est pas juste de la 3D face pleine, tout est rempli d'animation. La routine de Michael Bittner est une routine Planar to Chunky qui tourne à l'aide du copper, le CPU est donc déchargé de ça.

Donc contrairement à ce que tu dis ce n'est pas le CPU qui gère la 3D. Bittner s'est cassé le crâne pour pondre cette routine hardware spéciale "chunky", et cette dernière ne pourrait pas tourner sur un CPU à 7 ou 8 mhz. L'amiga (et le ST s'il était concerné) ne le supporteraient pas en terme de puissance de calcul requis.

La 3D d'Ambermoon est au pixel en 1x1, c'est dire à quel point c'est fabuleux de voir ça sur une machine qui n'a pas la puissance CPU pour fournir ce genre d'effet.

c'est impossible , tout simplement.  tu ne peux avoir une tel résolution avec du copper chunky, la 3D est bel est bien gérée par le CPU, pas par le copper.  de plus, la 3D est en temps réel, comment veux-tu construire une copper list sans cpu ? 

Enfin, malgré toutes les astuces techniques utilisées dans leurs jeux, nombre de jeux de thalion sont très faibles, et au final peu intéressant, et en plus ces dites techniques flinguent littéralement malgré l'hyper optimisation du code les cycles CPU disponibles......ue le ST/STE étaient clairement trop limités pour ce qu'ils voulaient accomplir en terme de créativité......

je te l'accorde, les jeux Thalion ne sont pas les meilleures, clairement.

L'information au sujet de la routine chunky est tirée du magazine allemand ou j'ai récupéré l'info au sujet d'ambermoon. Elle repose sur le copper :) Le CPU charge les données dans le copper mais c'est peanuts en terme de cycles.

regarde ici à propos de la 3D du jeu au pixel près

"Le développement est passé du fil de fer aux polygones solides et à présent à du texture mapping. Le Texture mapping utilises les mêmes calculs simples que la plupart des jeux avec polygones utilisent mais au lieu de prendre un simple polygone en une couleur, on prend une image bitmap et on la tord dans l'espace de façon à ce qu'elle rentre dans le polygone. De nombreux programmes de dessins tel que DPaint font ce genre de chose depuis des années mais le vrai problème est de faire ça en temps réel avec des douzaines de polygones en bitplan. C'est une tâche immense parce que vous devez gérer tout les pixels de l'objet, au lieu d'utiliser une routine de polygone en une couleur. C'est plus facile à faire sur un PC que sur l'Amiga, grâce aux cartes VGA [le mode octet-par-pixel, autrement connu sous le nom de chunky], sans parler des CPUs plus rapides."

Ici Erik Simon explique clairement que c'est une routine chunky qu'ils ont mis au point, et que celle gère la 3D sur l'amiga au pixel, donc conforme à ce que je te disais plus haut. C'est une routine "chunky" qui repose sur le copper.

[Seb]

De la lecture intéressante:

http://www.codetapper.com/amiga/sprite-tricks/

[rocky007]

"Le développement est passé du fil de fer aux polygones solides et à présent à du texture mapping. Le Texture mapping utilises les mêmes calculs simples que la plupart des jeux avec polygones utilisent mais au lieu de prendre un simple polygone en une couleur, on prend une image bitmap et on la tord dans l'espace de façon à ce qu'elle rentre dans le polygone. De nombreux programmes de dessins tel que DPaint font ce genre de chose depuis des années mais le vrai problème est de faire ça en temps réel avec des douzaines de polygones en bitplan. C'est une tâche immense parce que vous devez gérer tout les pixels de l'objet, au lieu d'utiliser une routine de polygone en une couleur. C'est plus facile à faire sur un PC que sur l'Amiga, grâce aux cartes VGA [le mode octet-par-pixel, autrement connu sous le nom de chunky], sans parler des CPUs plus rapides."

Ici Erik Simon explique clairement que c'est une routine chunky qu'ils ont mis au point, et que celle gère la 3D sur l'amiga au pixel, donc conforme à ce que je te disais plus haut. C'est une routine "chunky" qui repose sur le copper.

oui c'est une routine chunky to planar , pas une copper chunky.  un telle résolution est impossible avec le copper.  tout se fait au CPU, désolé de te décevoir.

cela n'a du reste aucun intérêt , car comme déjà dit, si le CPU doit générer la copper en temps réel, il n'y a aucun intérêt.  afficher directement le pixels ou demander à la copper de le faire revient au même.  par contre, dans un démo, précalculer une immense copper ( par exemple un rotozoom ) , a de l'intérêt, puisque pendant que le copper affiche l'animation ( ou un partie ), le CPU est libre pour un autre effet ou pour calculer la suite du copper.

[dlfrsilver]

tu as lu comme moi le commentaire de Erik. Pour info, quand on lance le jeu en mode étendu (en mode CPU quoi), la oui, ce n'est pas la routine chunky cablée sur le copper qui est utilisée, mais bien le CPU, comme sur un PC ou un ST. Mais la version A500 de base elle utilise une routine qui tourne avec le copper. Cette routine est très complexe et lourde, et si un amiga 500 devait le faire en soft, ça n'aurait pas pu marcher, le CPU n'est pas assez puissant.

Mais par contre, ce que tu dis au sujet de la coopération CPU copper est juste. C'est justement parce que c'est le copper qui est en charge que le CPU a encore du mou pour traiter le reste. le copper déleste vraiment d'un énorme poids le CPU.

La seule chose que fait le CPU de l'amiga c'est charger ou utiliser les registres hardware du copper. ça ne coute rien en terme de cycles CPU, faut juste que ça soit bien intercallé avec les autres parties du programme géré par le CPU.

La routine chunky utilisée est en temps réel, je ne l'ai pas copié collé mais c'est dans l'article en allemand, bien spécifié autant par Erik que par Jurie.

Le copper n'est pas précalculé, ce n'est pas une routine, mais une puce custom de l'amiga dont le rôle est multiple, mais le principal c'est de faire des changements de palettes à gogo sur n'importe quelle zone de l'écran de l'amiga. Le copper gère physiquement le positionnement du cannon à electron, permet de décrypter des données, permet de faire tout un tas de choses avec les sprites hard, comme les recharger, les bouger à l'écran sans que le 68000 ne prenne un seul cycle.

Et pour info, cet exemple fonctionne aussi avec Shadow of the Beast.

La ou un Atari ST sur ce jeu utilise 90% de temps CPU (si c'est pas plus), un amiga 500 n'utilise que 20-30% de temps CPU. C'est te dire si les puces customs sont puissantes.

Pour qu'un Atari ST puisse répliquer exactement Shadow of the Beast avec autant de couleurs  et une animation en 50 images par secondes,
il faudrait un Atari ST avec un 68000 cadencé à 20mhz et 4 méga octets de RAM.

On fait ça sur un Amiga 500 avec 1 lecteur de disquette et 512ko de RAM.

donc si les programmeurs de Beast ont réussi en 89 a faire une telle prouesse technique, imagine les gars de thalion en 93 avec leur connaissance de la machine, les progrès technologique en programmation, et la puissance des composants internes de l'amiga ? Ils ont explosé ce que fait Beast dans tout les sens du terme.

Pour avoir désossé le programme d'Ambermoon, la version A500 est littéralement truffée de copper list, et quoi de plus normal, puisqu'il y a 64 environnements 3D (en dehors des villes) à parcourir.

Les puces propriétaires de l'amiga sont utilisées à leur maximum, et la différence majeure entre la programmation sur Atari ST et Amiga, et qui consistue le fossé entre les deux machines, c'est l'usage du CPU.

Sur un ST tout repose sur le CPU, à 100%. Un amiga ne fonctionne pas comme ça. Le programmeur doit faire accomplir un maximum de tâches (les plus lourdes entre autres), par les puces, et pas par le 68000 pour lui donner de l'air et lui permettre de faire d'autres choses, et de gérer d'autres effets. Ca un Atari ST ne peut pas le faire.

C'est pour cette raison que les jeux 16 bits de 3ème et 4ème génération sont impossible à transposer sur Atari ST ou même Atari STE. La machine se retrouve coincée avec un nombre de couleurs impossible à gérer, ou alors une quantité d'effets, ou une vitesse de scrolling impossible à répliquer. Quel programmeur a envie de massacrer un programme juste parce qu'il aurait fallu le convertir sur ST ?

[ryosaeba]

J'ai trouvé cela comme site. C'est peut-être connu .... mais je trouve cela très bien :

http://www.exotica.org.uk/wiki/Lost_In_Translation/Shadow_Of_The_Beast

[rocky007]

tu as lu comme moi le commentaire de Erik. Pour info, quand on lance le jeu en mode étendu (en mode CPU quoi), la oui, ce n'est pas la routine chunky cablée sur le copper qui est utilisée, mais bien le CPU, comme sur un PC ou un ST. Mais la version A500 de base elle utilise une routine qui tourne avec le copper. Cette routine est très complexe et lourde, et si un amiga 500 devait le faire en soft, ça n'aurait pas pu marcher, le CPU n'est pas assez puissant.

Mais par contre, ce que tu dis au sujet de la coopération CPU copper est juste. C'est justement parce que c'est le copper qui est en charge que le CPU a encore du mou pour traiter le reste. le copper déleste vraiment d'un énorme poids le CPU.

La seule chose que fait le CPU de l'amiga c'est charger ou utiliser les registres hardware du copper. ça ne coute rien en terme de cycles CPU, faut juste que ça soit bien intercallé avec les autres parties du programme géré par le CPU.

l'article que tu as cité ne parle en aucun cas du copper. 

Si selon toi, la seule chose que fait le CPU est de charger les "registres" du copper, dis moi qui fait alors les tous les calculs ( les raycast, les zooms, les rotations, etc.. )  ??  le CPU doit se charger de tout cela et certainement pas la copper !   la seule utilité de la copper, c'est quand elle ne change pas, ou peu, mais certainement pas quand une image dynamique complète doit être affichée par celle-ci, il perd alors tout intérêt.  de plus, la vitesse de changement de palette ne permet pas un changement à chaque pixel, il est donc impossible d'obtenir un résolution d'un pixel uniquement par la copper.  ici l'animation est en temps réel et dépend de l'utilisateur, donc c'est le CPU qui fait TOUT le boulot.

 Le copper gère physiquement le positionnement du cannon à electron, permet de décrypter des données, permet de faire tout un tas de choses avec les sprites hard, comme les recharger, les bouger à l'écran sans que le 68000 ne prenne un seul cycle.

la copper ne gère pas du tout cela.  elle reçoit seulement des infos de vsync et hsync, qui lui permet de démarrer du code à des moments précis. 

donc si les programmeurs de Beast ont réussi en 89 a faire une telle prouesse technique, imagine les gars de thalion en 93 avec leur connaissance de la machine, les progrès technologique en programmation, et la puissance des composants internes de l'amiga ? Ils ont explosé ce que fait Beast dans tout les sens du terme.

tu parles de 2 routines totalement différentes : SOTB exploite ce dont l'amiga est prévu pour : des "rasters" en hard, des scroll en hard et des sprites, de préférence en scroll horizontal si on veut préserver les jolis effets parallax et rasters.. dès que le scroll devient multidirectionnel, la fête est terminée et ça devient tout à fait banal...  Ambermoon, dans sa phase 3D, n'exploite rien d'autre que le CPU.   seules les couleurs elles sont gérées par le copper, tout le reste c'est le CPU.

C'est pour cette raison que les jeux 16 bits de 3ème et 4ème génération sont impossible à transposer sur Atari ST ou même Atari STE. La machine se retrouve coincée avec un nombre de couleurs impossible à gérer, ou alors une quantité d'effets, ou une vitesse de scrolling impossible à répliquer. Quel programmeur a envie de massacrer un programme juste parce qu'il aurait fallu le convertir sur ST ?

ambermoon n'exploitant pas les spécificité de l'amiga, il aurait pu être converti sur Atari, ainsi que tous les jeux qui n'exploitent pas les scrolling/sprite, comme les jeux 3D.  Regardes encore les deux exemples sur ST, au CPU pur, ça tourne sans problème...du reste, montres moi le même Wolfenstein sur amiga...cela ne pourrait exister à ce niveau, car le 68000 de l'amiga est légèrement moins rapide.

[ryosaeba]

il y a également Substation sur Ste : http://www.atarimania.com/game-atari-st-substation_11440.html
ou 

https://www.youtube.com/watch?v=b6WEzPgsAus


Il y a une discussion sur ce forum concernant Doom sur St: http://www.atari-forum.com/viewtopic.php?f=4&t=16682&sid=e7a058ea2f2033a6ccc1e3146c4c9ceb&start=25

[ryosaeba]

http://www.exxoshost.co.uk/atari/last/crash/index.htm

[dlfrsilver]

tu as lu comme moi le commentaire de Erik. Pour info, quand on lance le jeu en mode étendu (en mode CPU quoi), la oui, ce n'est pas la routine chunky cablée sur le copper qui est utilisée, mais bien le CPU, comme sur un PC ou un ST. Mais la version A500 de base elle utilise une routine qui tourne avec le copper. Cette routine est très complexe et lourde, et si un amiga 500 devait le faire en soft, ça n'aurait pas pu marcher, le CPU n'est pas assez puissant.

Mais par contre, ce que tu dis au sujet de la coopération CPU copper est juste. C'est justement parce que c'est le copper qui est en charge que le CPU a encore du mou pour traiter le reste. le copper déleste vraiment d'un énorme poids le CPU.

La seule chose que fait le CPU de l'amiga c'est charger ou utiliser les registres hardware du copper. ça ne coute rien en terme de cycles CPU, faut juste que ça soit bien intercallé avec les autres parties du programme géré par le CPU.

l'article que tu as cité ne parle en aucun cas du copper. 

Si selon toi, la seule chose que fait le CPU est de charger les "registres" du copper, dis moi qui fait alors les tous les calculs ( les raycast, les zooms, les rotations, etc.. )  ??  le CPU doit se charger de tout cela et certainement pas la copper !   la seule utilité de la copper, c'est quand elle ne change pas, ou peu, mais certainement pas quand une image dynamique complète doit être affichée par celle-ci, il perd alors tout intérêt.  de plus, la vitesse de changement de palette ne permet pas un changement à chaque pixel, il est donc impossible d'obtenir un résolution d'un pixel uniquement par la copper.  ici l'animation est en temps réel et dépend de l'utilisateur, donc c'est le CPU qui fait TOUT le boulot.

 Le copper gère physiquement le positionnement du cannon à electron, permet de décrypter des données, permet de faire tout un tas de choses avec les sprites hard, comme les recharger, les bouger à l'écran sans que le 68000 ne prenne un seul cycle.

la copper ne gère pas du tout cela.  elle reçoit seulement des infos de vsync et hsync, qui lui permet de démarrer du code à des moments précis. 

donc si les programmeurs de Beast ont réussi en 89 a faire une telle prouesse technique, imagine les gars de thalion en 93 avec leur connaissance de la machine, les progrès technologique en programmation, et la puissance des composants internes de l'amiga ? Ils ont explosé ce que fait Beast dans tout les sens du terme.

tu parles de 2 routines totalement différentes : SOTB exploite ce dont l'amiga est prévu pour : des "rasters" en hard, des scroll en hard et des sprites, de préférence en scroll horizontal si on veut préserver les jolis effets parallax et rasters.. dès que le scroll devient multidirectionnel, la fête est terminée et ça devient tout à fait banal...  Ambermoon, dans sa phase 3D, n'exploite rien d'autre que le CPU.   seules les couleurs elles sont gérées par le copper, tout le reste c'est le CPU.

C'est pour cette raison que les jeux 16 bits de 3ème et 4ème génération sont impossible à transposer sur Atari ST ou même Atari STE. La machine se retrouve coincée avec un nombre de couleurs impossible à gérer, ou alors une quantité d'effets, ou une vitesse de scrolling impossible à répliquer. Quel programmeur a envie de massacrer un programme juste parce qu'il aurait fallu le convertir sur ST ?

ambermoon n'exploitant pas les spécificité de l'amiga, il aurait pu être converti sur Atari, ainsi que tous les jeux qui n'exploitent pas les scrolling/sprite, comme les jeux 3D.  Regardes encore les deux exemples sur ST, au CPU pur, ça tourne sans problème...du reste, montres moi le même Wolfenstein sur amiga...cela ne pourrait exister à ce niveau, car le 68000 de l'amiga est légèrement moins rapide.

Je suis désolé, mais le copper en est hélas capable. Le jeu Brian the Lion utilise des effets de type Snes Mode 7, qui sont entièrement gérés au copper. Donc je ne suis absolument pas étonné de voir Ambermoon utiliser une routine 3D temps réel chunky qui tourne avec le copper. Et je te confirme que le copper fait le travail.

Tu connais seulement l'architecture de l'amiga, ses composants et comment ces derniers fonctionnent ?

Je suis vraiment désolé de te le confirmer, mais oui le copper permet de changer la position à la volée du cannon à electron sur l'amiga, c'est ce qui permet justement les effets graphiques tel qu'afficher 128 couleurs à l'écran. Le copper permet par exemple d'afficher 4 palettes de 16 couleurs différentes sur un même écran dans un jeu.
J'en connais au moins un dans ce cas, c'est Pang. J'ai eu l'occasion de discuter avec le programmeur, Pang utilise 64 couleurs à l'écran, et c'est pas le mode halfbright. Le copper découpe en fait l'écran en 4 bandes distinctes, chacune utilisant 16 couleurs indépendantes. Cet effet là, sans le copper c'est impossible à réaliser.

regarde la confirmation de ce que je te disais au sujet du copper (source wikipédia amiga) :

"les capacités graphiques sont très difficile à expliquer brièvement en raison du coprocesseur Copper, qui permet en cours de balayage de changer les caractéristiques de l'affichage (On parle bien du contrôle et du changement de position du canon à electron, puisque c'est lui qui affiche les pixels à l'écran) :

(résolution, palette de couleurs, nombre de couleurs, synchronisation du balayage, réaffectaction et/ou modification des sprites, etc)."

quand tu vois qu'il est capable de mettre 2 résolutions différentes sur un même écran, de mettre jusqu'à 5 ou 6 palettes différentes voir plus à l'écran, de changer en temps réel des couleurs dans n'importe laquelle des dites palettes, de réaffecter ou de modifier les sprites à la volée, je ne suis pas du tout étonné de voir que le copper gère la dite routine sur la version A500. le 68000 de la machine n'est pas assez puissant pour gérer seul cet effet.

Ensuite quand tu dis :

"tu parles de 2 routines totalement différentes : SOTB exploite ce dont l'amiga est prévu pour : des "rasters" en hard, des scroll en hard et des sprites, de préférence en scroll horizontal si on veut préserver les jolis effets parallax et rasters.. dès que le scroll devient multidirectionnel, la fête est terminée et ça devient tout à fait banal...  Ambermoon, dans sa phase 3D, n'exploite rien d'autre que le CPU.   seules les couleurs elles sont gérées par le copper, tout le reste c'est le CPU."

Je suis navré, mais la majeure partie des effets spéciaux de palettes et de sprites sur Beast sont fait par le copper et les sprites hardware, seul le scrolling est géré par le blitter.

C'est le copper qui est responsable de l'affichage des 128 couleurs à l'écran, et du rechargement permanent des registres des sprites hardware. L'affichage à l'écran pour tout afficher et tout modifier au 50ème de secondes utilise 9 copperlist différentes, qui changent à la volée la position des sprites hardware, leur couleurs, ainsi que les palettes de couleurs présentes sur les différentes zones de l'écran.

ensuite :

"ambermoon n'exploitant pas les spécificité de l'amiga, il aurait pu être converti sur Atari, ainsi que tous les jeux qui n'exploitent pas les scrolling/sprite, comme les jeux 3D.  Regardes encore les deux exemples sur ST, au CPU pur, ça tourne sans problème...du reste, montres moi le même Wolfenstein sur amiga...cela ne pourrait exister à ce niveau, car le 68000 de l'amiga est légèrement moins rapide."

Ambermoon exploite l'amiga à fond (C'est pas moi qui le dit, mais les concepteurs, Erik Simon et Jurie Horneman).
Télécharge un émulateur amiga, et passe une journée entière sinon plus à y jouer, et tu verras par toi même que le jeu fait appel à fond aux puces de l'amiga (sauf la version CPU qui fait tout en software sur 68020/030/040/060).

Le jeu fait un usage massif de sprites, et d'une taille énorme. Wolfenstein 3D est pas mal sur STE, mais je préfère 100 fois mieux la 3D complexe temps réel d'Ambermoon, ses textures plaquées et les animations de ces dernières.

Quand à dire que le 68000 de l'amiga ne pourrait pas avoir Wolfenstein 3D au CPU, je te réponds qu'avec la routine d'Ambermoon, et sans passer par le CPU, mais le copper, le jeu serait parfaitement faisable.

Néanmoins, si le programmeur d'Ambermoon a strictement dédié la version CPU de son jeu aux processeur supérieurs au 68020 et au delà c'est pas pour rien. Le jeu pour tourner en version soft nécessite bien plus qu'un 68000 de base comme celui qui équipe l'atari ST.

[rocky007]

Je suis désolé, mais le copper en est hélas capable. Le jeu Brian the Lion utilise des effets de type Snes Mode 7, qui sont entièrement gérés au copper. Donc je ne suis absolument pas étonné de voir Ambermoon utiliser une routine 3D temps réel chunky qui tourne avec le copper. Et je te confirme que le copper fait le travail.

ok si tu veux le croire, je n'insiste pas sinon ce post va tourner indéfiniment sur ce point

Tu connais seulement l'architecture de l'amiga, ses composants et comment ces derniers fonctionnent ?

suffisamment pour t'expliquer que tu te trompes lourdement

Je suis vraiment désolé de te le confirmer, mais oui le copper permet de changer la position à la volée du cannon à electron sur l'amiga, c'est ce qui permet justement les effets graphiques tel qu'afficher 128 couleurs

 changer la postions du canon à électron ne change en rien le nombre de couleur.  tu ne peux physiquement pas modifier le balayage d'un écran, cela est impossible.  L'écran va de gauche à droite, de haut en bas... les seuls écrans que tu peux piloter le canon sont les écrans vectoriels comme ceux qui équipent la Vectrex. 

Le copper permet par exemple d'afficher 4 palettes de 16 couleurs différentes sur un même écran dans un jeu.
J'en connais au moins un dans ce cas, c'est Pang. J'ai eu l'occasion de discuter avec le programmeur, Pang utilise 64 couleurs à l'écran, et c'est pas le mode halfbright. Le copper découpe en fait l'écran en 4 bandes distinctes, chacune utilisant 16 couleurs indépendantes. Cet effet là, sans le copper c'est impossible à réaliser.

c'est ultra simple a réaliser , et ce sans copper. cet effect existe depuis la nuit des temps, sur n'importe quel ordinateur qui fournit un vsync.  Si tu connais le début du balayage écran, tu peux modifier la palette en temps réel et la position très précisément, cela peut se fait au CPU ou via la copper.



tu déformes ce qui est écrit, tout comme tu déformes l'interview d'eric concernant ambermoon.  Où lis-tu que le copper modifier la position du canon ?
la copper ne possède que 3 instructions élémentaires, il ne peut donc pas faire des manipulations complexes, et certainement pas calculer des raycast et compagnie.

En gros, la copper te permet d'attendre un point précis de l'écran, et de modifier des registres ( couleurs, sprite, résolution, etc..).  Tu n'as aucune opération mathématique.

Je suis navré, mais la majeure partie des effets spéciaux de palettes et de sprites sur Beast sont fait par le copper et les sprites hardware, seul le scrolling est géré par le blitter.

désolé encore de te contredire, mais les scrolling dans SOTB ne sont pas géré par le blitter.  et je t'ai confirmé que la palette , scrolling et sprite sont bien géré par le copper, d'où la limitation du jeu...( jeu à scrolling horizontal ).. dès qu'il s'agit d'un scroll multidirectionnel, tous les beaux effets tombent, car pas exploitables.

Quand à dire que le 68000 de l'amiga ne pourrait pas avoir Wolfenstein 3D au CPU, je te réponds qu'avec la routine d'Ambermoon, et sans passer par le CPU, mais le copper, le jeu serait parfaitement faisable.

Néanmoins, si le programmeur d'Ambermoon a strictement dédié la version CPU de son jeu aux processeur supérieurs au 68020 et au delà c'est pas pour rien. Le jeu pour tourner en version soft nécessite bien plus qu'un 68000 de base comme celui qui équipe l'atari ST.

cela sera le cas, si tes dires était correct : une routine 3D indépendante du CPU, ce qui n'est pas le cas.  Le jeux était à 100% par le CPU (excepté les couleurs ), il est donc portable sur n'importe quel machine au CPU équivalent.

Enfin je te propose qu'on en termine sur ce débat, je comprends que Ambermoon est ton bébé, car tu y as travaillé de nombreuses heures et trifouiller ses entrailles, mais malheureusement tu es loin de la vérité sur le côté technique.

[Nextome]

Sans parler technique, je me fie à se que je vois à l'écran... Alors entre un Atari ST et un Amiga, j'ai toujours trouvé les jeux Amiga + beaux, + colorés, + fluides avec des musiques et un son magnifique...
Donc forcément, sans trop se poser de questions existentielles, on voit bien que l'Amiga gère mieux et en a + dans le ventre. Après savoir si le ST pouvait faire mieux, je veux bien y croire, mais je n'ai jamais vu...

[ryosaeba]

Sans parler technique, je me fie à se que je vois à l'écran... Alors entre un Atari ST et un Amiga, j'ai toujours trouvé les jeux Amiga + beaux, + colorés, + fluides avec des musiques et un son magnifique...
Donc forcément, sans trop se poser de questions existentielles, on voit bien que l'Amiga gère mieux et en a + dans le ventre. Après savoir si le ST pouvait faire mieux, je veux bien y croire, mais je n'ai jamais vu...

Pourquoi se limiter au jeux. Un ordinateur n'est pas une console. Pour moi, la véritable question est de savoir qui du St ou de l'Amiga était l'ordinateur le plus polyvalent. Lequel était le plus pratique, le plus simple d'utilisation, celui qui si on devait faire une moyenne de tous les domaines (jeux, utilitaires,.....) aurait la meilleure moyenne.

Le véritable vainqueur est celui qui répondra à cette question.

[dlfrsilver]

Je suis désolé, mais le copper en est hélas capable. Le jeu Brian the Lion utilise des effets de type Snes Mode 7, qui sont entièrement gérés au copper. Donc je ne suis absolument pas étonné de voir Ambermoon utiliser une routine 3D temps réel chunky qui tourne avec le copper. Et je te confirme que le copper fait le travail.

ok si tu veux le croire, je n'insiste pas sinon ce post va tourner indéfiniment sur ce point

Tu connais seulement l'architecture de l'amiga, ses composants et comment ces derniers fonctionnent ?

suffisamment pour t'expliquer que tu te trompes lourdement

Je suis vraiment désolé de te le confirmer, mais oui le copper permet de changer la position à la volée du cannon à electron sur l'amiga, c'est ce qui permet justement les effets graphiques tel qu'afficher 128 couleurs

 changer la postions du canon à électron ne change en rien le nombre de couleur.  tu ne peux physiquement pas modifier le balayage d'un écran, cela est impossible.  L'écran va de gauche à droite, de haut en bas... les seuls écrans que tu peux piloter le canon sont les écrans vectoriels comme ceux qui équipent la Vectrex. 

Le copper permet par exemple d'afficher 4 palettes de 16 couleurs différentes sur un même écran dans un jeu.
J'en connais au moins un dans ce cas, c'est Pang. J'ai eu l'occasion de discuter avec le programmeur, Pang utilise 64 couleurs à l'écran, et c'est pas le mode halfbright. Le copper découpe en fait l'écran en 4 bandes distinctes, chacune utilisant 16 couleurs indépendantes. Cet effet là, sans le copper c'est impossible à réaliser.

c'est ultra simple a réaliser , et ce sans copper. cet effect existe depuis la nuit des temps, sur n'importe quel ordinateur qui fournit un vsync.  Si tu connais le début du balayage écran, tu peux modifier la palette en temps réel et la position très précisément, cela peut se fait au CPU ou via la copper.



tu déformes ce qui est écrit, tout comme tu déformes l'interview d'eric concernant ambermoon.  Où lis-tu que le copper modifier la position du canon ?
la copper ne possède que 3 instructions élémentaires, il ne peut donc pas faire des manipulations complexes, et certainement pas calculer des raycast et compagnie.

En gros, la copper te permet d'attendre un point précis de l'écran, et de modifier des registres ( couleurs, sprite, résolution, etc..).  Tu n'as aucune opération mathématique.

Je suis navré, mais la majeure partie des effets spéciaux de palettes et de sprites sur Beast sont fait par le copper et les sprites hardware, seul le scrolling est géré par le blitter.

désolé encore de te contredire, mais les scrolling dans SOTB ne sont pas géré par le blitter.  et je t'ai confirmé que la palette , scrolling et sprite sont bien géré par le copper, d'où la limitation du jeu...( jeu à scrolling horizontal ).. dès qu'il s'agit d'un scroll multidirectionnel, tous les beaux effets tombent, car pas exploitables.

Quand à dire que le 68000 de l'amiga ne pourrait pas avoir Wolfenstein 3D au CPU, je te réponds qu'avec la routine d'Ambermoon, et sans passer par le CPU, mais le copper, le jeu serait parfaitement faisable.

Néanmoins, si le programmeur d'Ambermoon a strictement dédié la version CPU de son jeu aux processeur supérieurs au 68020 et au delà c'est pas pour rien. Le jeu pour tourner en version soft nécessite bien plus qu'un 68000 de base comme celui qui équipe l'atari ST.

cela sera le cas, si tes dires était correct : une routine 3D indépendante du CPU, ce qui n'est pas le cas.  Le jeux était à 100% par le CPU (excepté les couleurs ), il est donc portable sur n'importe quel machine au CPU équivalent.

Enfin je te propose qu'on en termine sur ce débat, je comprends que Ambermoon est ton bébé, car tu y as travaillé de nombreuses heures et trifouiller ses entrailles, mais malheureusement tu es loin de la vérité sur le côté technique.

"ok si tu veux le croire, je n'insiste pas sinon ce post va tourner indéfiniment sur ce point"

=> ce n'est pas une question de croire ou ne pas croire. Concernant Brian the lion, Martin edmonson, le programmeur de Beast au passage, a expliqué de façon détaillée dans un magazine anglais que la routine 3D du jeu repose sur le copper. Tu n'oserais pas mettre en doute la parole même du programmeur du jeu quand même ?

Rassure-moi ?

"suffisamment pour t'expliquer que tu te trompes lourdement"

=> quand tu me parles de "la copper" déjà j'ai toutes raisons de penser que tu ne connais le sujet ni la puce.
C'est "le copper", nom masculin (google le HRM de l'amiga)

"Changer la postions du canon à électron ne change en rien le nombre de couleur.  tu ne peux physiquement pas modifier le balayage d'un écran, cela est impossible.  L'écran va de gauche à droite, de haut en bas... les seuls écrans que tu peux piloter le canon sont les écrans vectoriels comme ceux qui équipent la Vectrex."

=> Tu vois ta première m'indique que tu ne connais pas le fonctionnement de l'amiga, et encore du copper, ou de ce qu'il est capable de faire.

Le copper peut Changer la postions du canon à électron (y compris en plein milieu d'une ligne !) ET changer à la volée le nombre de couleurs.

Ce qui m'amène a invalider ta phrase suivante : "tu ne peux physiquement pas modifier le balayage d'un écran, cela est impossible" T'es juste pas sérieux, nombre de jeux exploitant bien l'amiga utilisent cette technique, et c'est le copper qui en a la charge sur l'amiga.

Tu veux avoir la liste de ce que le copper peut faire sur un amiga ? la voilà ! avec les caractéristiques officielles et non officielles :

• les capacités graphiques sont très difficile à expliquer brièvement en raison du coprocesseur Copper, qui permet en cours de balayage (tu sais l'histoire du positionnement du canon à electron ?) de changer les caractéristiques de l'affichage (résolution, palette de couleurs, nombre de couleurs, synchronisation du balayage, réaffectaction et/ou modification des sprites, etc).
  
• grâce au Copper, on peut avoir un écran séparé en deux dans le plan horizontal, avec des résolutions et des palettes différentes sur chaque partie de l'écran.
  
  
  
  • bien que ce ne soit pas une caractéristique officielle, le Copper peut être utilisé pour changer les registres de sprite (entre autres) au milieu d'une ligne de balayage. Ce qui permet d'afficher plus de sprites par ligne. Une astuce qui a été employée par certains jeux comme Battle Squadron.
    
  • il est possible de simuler une largeur de sprite variable en plaçant des sprites de 16 pixels de larges côte à côte. Et ceci jusqu'au maximum de 128 pixels de large pour des sprites de 3 couleurs, et de 64 pixels de large pour des sprites de 15 couleurs. Cependant, plus large est ce pseudo-sprite, moins il est possible d'afficher de sprites sur une ligne de balayage.
    
  
  
  

Ce que tu m'as répondu contrevient clairement avec les aptitudes officielles de la puce.

"C'est ultra simple a réaliser , et ce sans copper. cet effect existe depuis la nuit des temps, sur n'importe quel ordinateur qui fournit un vsync.  Si tu connais le début du balayage écran, tu peux modifier la palette en temps réel et la position très précisément, cela peut se fait au CPU ou via la copper."

=> Oui simple à réaliser. Mais Pang est un jeu et pas une démo. La version atari ST n'utilise pas cette astuce, car bien trop gourmande en cycle CPU, et comme le jeu ne tourne déjà qu'en 25 images secondes...... (Ah et je précise que la conversion ST a été effectuée par un spécialiste de l'Atari ST).

Via le copper ça mange aucun cycle, sur ST au CPU, tu flingues gratuitement des cycles pour rien.

"une routine 3D indépendante du CPU, ce qui n'est pas le cas.  Le jeux était à 100% par le CPU (excepté les couleurs ), il est donc portable sur n'importe quel machine au CPU équivalent."

=> le jeu n'est pas 100% CPU sur la version A500. Je t'ai expliqué au début que le programmeur a crée un lanceur, pour 2 programmes différents. Le premier pour A500/68000 qui utilisent à fond les puces customs (copper+blitter), et le deuxième pour Amiga avec processeur 68020 à 68060 qui fait tout dans le jeu au CPU en software.

Le jeu n'est donc pas portable sur Atari ST puisque la machine n'a pas de puces dédiées. Comme le code pour A500 est entièrement architecturé autour des puces customs, le jeu n'est pas portable en l'état.

"Enfin je te propose qu'on en termine sur ce débat, je comprends que Ambermoon est ton bébé, car tu y as travaillé de nombreuses heures et trifouiller ses entrailles, mais malheureusement tu es loin de la vérité sur le côté technique."

=> Ce n'est pas mon bébé, mais j'ai mis les mains dans ses tripes, et c'est pour ça que je peux te dire que le jeu n'est en aucune façon transposable sur Atari ST. J'ai ressourcé les 2 programmes, et le code pour A500 est bourré d'accès aux puces customs, alors que la version A1200 y a pas grand chose, tout les calculs sont faits au CPU.

La version A500 => version avec support hardware (AM2_BLIT pour 68000)
La version A1200 => version intégralement en software (AM2_CPU pour 680X0)

La version A1200 même étant en software trop gourmande en ressource CPU, le petit 68000 du ST n'y suffirait pas.

Par contre si le falcon avait du succès et n'était pas mort né, et s'était vendu, ils auraient pu porter tranquillement le jeu dessus.

[Nextome]

Sans parler technique, je me fie à se que je vois à l'écran... Alors entre un Atari ST et un Amiga, j'ai toujours trouvé les jeux Amiga + beaux, + colorés, + fluides avec des musiques et un son magnifique...
Donc forcément, sans trop se poser de questions existentielles, on voit bien que l'Amiga gère mieux et en a + dans le ventre. Après savoir si le ST pouvait faire mieux, je veux bien y croire, mais je n'ai jamais vu...

Pourquoi se limiter au jeux. Un ordinateur n'est pas une console. Pour moi, la véritable question est de savoir qui du St ou de l'Amiga était l'ordinateur le plus polyvalent. Lequel était le plus pratique, le plus simple d'utilisation, celui qui si on devait faire une moyenne de tous les domaines (jeux, utilitaires,.....) aurait la meilleure moyenne.

Le véritable vainqueur est celui qui répondra à cette question.

Pratiquant le photomontage, et le dessin, j'étais mieux servi avec l'Amiga (j'avais le 1200). Apparemment le ST était doué dans le son grâce à sa prise midi mais il me semble qu'il n'était pas compliqué de faire de même avec un Amiga... Après, la grande majorité utilisait ces micro-ordinateurs pour le jeux vidéo... La raison pour laquelle l'Amiga a été souvent comparé aux consoles japonaises de l'époque.

[Doctoritchy]

je contredit pas le reste je ne sais pas trop MAIS

"changer la position du canon as électron de l’écran" ....  sérieusement  y as un peu d'abus  , le canon as électron , au nombre de 3  positionner en triangle  loger dans le tube cathodique , scellé  il ne BOUGE PAS  as mois d’écran très spéciaux et coûteux ,(je ne pense même pas que cela existe en vrais ) les canon as électron son FIXE le jet d’électron est dirigé et balayer as la fréquence de balayage horizontale et verticale via des bobine de déflexion qui défléchisse le jet d’électron vers la grille de l’écran et qui viens après frapper la couche phosphorescente de l’écran et puis qui nous apparaît !!!!  , l'ordi peu par contre géré les fréquence de balayage qui dévie les électrons , mais cette fréquence est fixe ( 50khz verticale et 15khz horizontal pour nos chère micro , mais qui change avec la résolution ) , donc l'ordi pour donc géré la fréquence horizontale oui , mais en temps réel ça j'ai un léger doute , mais en aucun cas c'est le canon as électron qui bouge , c'est les déflecteur magnétique qui font le boulot

[rocky007]

=> ce n'est pas une question de croire ou ne pas croire. Concernant Brian the lion, Martin edmonson, le programmeur de Beast au passage, a expliqué de façon détaillée dans un magazine anglais que la routine 3D du jeu repose sur le copper. Tu n'oserais pas mettre en doute la parole même du programmeur du jeu quand même ?

montres-nous donc l'article qui explique clairement, "j'utiliser le copper pour faire de la '3D' temps réel 1pxl"...

=> quand tu me parles de "la copper" déjà j'ai toutes raisons de penser que tu ne connais le sujet ni la puce. 

là c'est vraiment l’hôpital qui se fout de la charité   apprends donc les bases de ton cher amiga

• les capacités graphiques sont très difficile à expliquer brièvement en raison du coprocesseur Copper, qui permet en cours de balayage (tu sais l'histoire du positionnement du canon à electron ?) de changer les caractéristiques de l'affichage (résolution, palette de couleurs, nombre de couleurs, synchronisation du balayage, réaffectaction et/ou modification des sprites, etc).
  
• grâce au Copper, on peut avoir un écran séparé en deux dans le plan horizontal, avec des résolutions et des palettes différentes sur chaque partie de l'écran.
  
  
  
  • bien que ce ne soit pas une caractéristique officielle, le Copper peut être utilisé pour changer les registres de sprite (entre autres) au milieu d'une ligne de balayage. Ce qui permet d'afficher plus de sprites par ligne. Une astuce qui a été employée par certains jeux comme Battle Squadron.
    
  • il est possible de simuler une largeur de sprite variable en plaçant des sprites de 16 pixels de larges côte à côte. Et ceci jusqu'au maximum de 128 pixels de large pour des sprites de 3 couleurs, et de 64 pixels de large pour des sprites de 15 couleurs. Cependant, plus large est ce pseudo-sprite, moins il est possible d'afficher de sprites sur une ligne de balayage.
    
  
  
  

encore une fois, OU VOIS-TU QUE L'AMIGA CHANGE LA POSITION DU CANON ??? OUUUUUUUUU ?  Ouvre un manuel technique d'une télévision !  Seul un écran vectoriel peut effectuer une modification X-Y de l'affichage pas un écran traditionnel ! 

=> Oui simple à réaliser. Mais Pang est un jeu et pas une démo. La version atari ST n'utilise pas cette astuce, car bien trop gourmande en cycle CPU, et comme le jeu ne tourne déjà qu'en 25 images secondes...... (Ah et je précise que la conversion ST a été effectuée par un spécialiste de l'Atari ST).

n'importe quoi, mettre 2 -3 palettes sur un jeu ne prend rien en cycles.  encore une fois, apprends donc les bases !  Regardes simple Beast sur ST ou Bio Challenge, Nebulus, Enchanted land, Turrican 2,etc.. c'est blindé de couleurs et pourtant le CPU tourne au max !  ( et autrement plus que Pang !!! )

=> le jeu n'est pas 100% CPU sur la version A500. Je t'ai expliqué au début que le programmeur a crée un lanceur, pour 2 programmes différents. Le premier pour A500/68000 qui utilisent à fond les puces customs (copper+blitter), et le deuxième pour Amiga avec processeur 68020 à 68060 qui fait tout dans le jeu au CPU en software. 

je n'ai jamais parlé pas de la version 1200, alors arrête de tout mélanger.  Je compare la version A500 VS ATARI ST.
la routine 3D est CPU, pas en copper !!   c'est fou que tu ne prends même pas la peine de réfléchir une seconde.
Je t'ai déjà expliqué que la copper ne fait AUCUNE opération mathématique, conditions, branchement, etc..  comment veux-tu que la copper seule fasse des raycast, rotation, etc.. ???

bref, j'arrête là, j'ai été patient et poli, mais je te trouve de plus en plus agressif et méprisant.
Si tu ne peux comprendre qu'un Wolfenstein plein écran est au moins aussi bien que ta petite fenêtre d'ambermoon, je peux pas d'aider, tu manques simplement de logique.

Si pour toi, l'amiga peut piloter le canon d'une TV grâce à sa copper qui se programme comme un 68000, je pense qu'on va s'arrêter là   on se demande encore pourquoi l'amiga a un 68000 (  puisqu'il ne fait jamais rien, ils auraient pu économiser en mettant un Z80 )   on va bientôt lire ici que même un traitement de texte fonctionne juste avec la copper et le blitter.

[Doctoritchy]

calmmmeeennoonnn nous :)

alors l'histoire du amiga qui contrôle le canon as électron NON c'est physiquement impossible , et un ecran vectoriel ?  non meme pas le canon est toujours fixe  c'est le controle de la déflexion  des bobine magnetique qui dirige le faiceaux  , la seule "projection" vectoriel ou la source de lumiere bouge de façon mécanique c'est avec deux mirroir X et Y bouger par des galvanometre spéciaux controlé en position  mais ça c'est le domaine de la gravure laser et la projection laser , et quelque rare application video :) 

donc il faudras révisé un peu l'electronique  avant d'affirmé un truc aussi  , heu gros !!!  de plus le systeme de balayage est en frequence fixe  c'est l'allumage et l'extinction du flot d'electron qui définit ou et comment le pixel va se positioner  et en se synchronisant sur la frequence de balayage qui elle ne varie pas , enfin elle varie mais seulement au changement de résolution d'affichage :)

on peu tricher en superposant plusieur couleur tres vite sur le meme pixel et as des degré de puissance different pour crée de nouvelles couleur  c'est comme ça que on peu avoir des million de couleur avec les crt "actuelle" (enfin les dernier construis ) l'amiga et l'atari peu emuler cette possibilité avec du code bien fait mais demande as chaque fois du temps cpu en plus (peu importe quel cpu le fait il doit le faire 2 4 ou 8 fois as chaque rafraichissement image , ici 15khz donc 15000 fois par seconde * le nombre de couche couleur !! 

bref , ceci est le coter hardware inébranlable d'un ecran crt peu importe sa marque ou model

[Invité]

Tapez sur les idées, pas les gens.

Merci.