Re: GUERRE ST-AMIGA, FIGHT !!!

[Invité]

Bah avec la taille des sprites fallait un peu s'y attendre,cependant il semble qd même assez contenu et discret .

[Zarnal]

Question : c'est quoi un overflow ?

Merci.

[babsimov]

Ca ne te dirais pas d'essayer de refaire le niveau 1 du jeu (en rippant les graphismes) avec les optimisations que tu proposes, pour voir ce que ça donnerais en terme de rapidité ?

Honnêtement, faire tout ce travail pour obtenir le défilement fluide d'un décor moche... Bof...
A la limite, si je me monte un environnement de dev (ce que je pourrais faire pour aider l'un des intervenants de ce topic qui voulait faire un jeu) et si quelqu'un s'occupe du rip, je veux bien coder un truc vite fait...

Reste plus qu'à trouver quelqu'un pour ripper les images alors. Ca tombe bien, j'ai un nom qui m'est venu à l'esprit. 

Il me semble que Dlfrsilver s'occupe de préserver les anciens jeux et d'en ripper les données. Peut être a-t-il déjà rippé ce jeu d'ailleurs ?

@Dlfrsilver, aurais tu travaillé sur le préservation de Sword Of Sodan sur Amiga ? Sinon aurais tu le temps et la possibilité de ripper les graphismes du niveau 1 pour que Stapha92 puisse essayer d'obtenir un jeu plus fluide que l'original ?

Ce serait cool de voir ce que le résultat pourrait donner, je pense que je ne suis pas le seul que ça pourrait intéresser, en particulier les programmeurs, puisque, je suppose, que tu serait prêt à détailler ton code pour eux et que tu trouveras les explications pour que la majorité comprenne les optimisations que tu auras trouvé ?

[Invité]

Question : c'est quoi un overflow ?

Merci.

C'est qd tu as un débordement .
Ici comme il s'agit de sprites, c'est quand tu as des sprites qui sont plus affichés, car la puce video est arrivé aux limites de ce qu'elle peut afficher comme sprites sur une même ligne,donc le reste des sprites est vide .

[Templeton]

Stapha92:

Templeton: Tu ne pourras jamais faire tourner Sword Amiga en 1VBL comme Fighting, c'est impossible.

Je suis certain du contraire :

Non c'est carrément impossible même avec l'utilisation du scroll Hardware, le "cookie-cut" et 2 "je vous salut marie"! Je vais t'expliquer pourquoi.

Stapha92:
Tu as tout a fait raison. mais même avec 5 sprites, il y aurait beaucoup moins à restaurer que le blit d'un écran en entier.

Par exemple, on peut éviter la majeure partie des restauration. En effet, lorsque l'on fait du cookie cut, l'une des 3 source correspond à la destination mais rien n'empeche d'utiliser la copie écran qui sert à la restauration à la place. Du coup, le cookie-cut et la restauration se feront en même temps et cette dernière sera gratuite : seules les parties qui ne seront pas recouvertes devront être restaurées.
Bien sur, cela implique de traiter les sprites par colonnes de 16 pixels :

Dans les cas ou les sprites ne se chevauchent pas ou pratiquement pas, un tel algo ne servira pratiquement à rien, voir ci dessous:

Stapha92: On peut donc le stocker entièrement et copier avec le blitter la partie visible. Pour appliquer le décor, le blitter travaillera avec une seule source et une destination...

C'est ce que fait déjà le programmeur.
Je viens de dumper la mémoire pendant le jeu pour les 3 premier niveaux. Le décor est stocké intégralement dans un buffer de 80ko (640*200 en 5 biplans) et ce, systématiquement !
Il est déjà assemblé, il n'y a donc pas de système de tiles (c'est un gros dessin) et certains niveaux ne font que 2 écrans de large comme le buffer. Il y a une petite subtilité dans certains levels où le codeur copie de larges bandes verticales pour créer une boucle afin de rallonger la map.

Stapha92: Donc non seulement ce jeu pourrait tourner en 1 vbl sur un A500 mais, en plus...

Techniquement c'est impossible (voir plus bas) et le codeur l'avait bien compris. Ce n'était pas un manche car il avait déjà codé des jeux sur Amiga en 50 FPS!
Le programmeur maîtrise sa machine car Sword of Sodan utilise le copper pour augmenter le nombre de couleur dans la partie supérieur du Hud et ajouter par dessous un autre raster.
Il utilise également les sprites Hardware pour afficher la majeur partie du HUD, et, fait même du multiplexage avec le copper pour afficher sur les soldats, les sprites des 4 seringues en 15 couleurs (donc 8 sprites Hard concaténés), chapeau bas ! Enfin, il utilise massivement le Blitter !
A l'époque, on aurait aimé que tous les codeurs Amiga en fasse autant...

Si le programmeur n'a pas choisi d'utiliser le scroll hard, c'est peut être en partie parce qu'il n'avait plus assez de mémoire pour ça.
Dans le mode vidéo que le codeur a choisi, le scroll hard lui aurait coûté 76 ko supplémentaire (2octets*5biplans*19mots*200lignes = 38000 octets*2Buffers = 76000 octets).
Ce n'est pas négligeable avec seulement 512 ko, des sprites énormes en 5 biplans, un décor dessiné sur 2 écrans de large (pas de tiles et toujours en 5 biplans), des gros samples pcm (plein de phrase et de bruitage pendant ce jeu), un double buffer et le code.

Stapha92: Le blitter doit faire du cookie-cut pour dessiner les sprites. ça impose 3 sources et une destination. Dans ce mode il peut traiter 35 Ko par frame. Vu ce qu'il lui reste après le traitement du décor, cela fait 15 Ko à peu près.

Dans un jeu commercial Amiga, il faut essayer d"être le plus précis possible dans l'estimation du calcul des transferts pour des sprites soft. Il ne faut pas raisonner avec une estimation via un débit max par frame, mais via un débit par "sprite utile" en fonction du nombre de biplans et de la résolution.
Dans ma démonstration, on va utiliser le scroll hard, et partir sur des sprites optimisés via un découpage afin de transférer le moins d'octet possible (le calcul d'assemblage ne devrait pas être trop pénalisant avec le puissant 68000).

En tenant compte de la résolution, du nombres de plans et du coup du nombre de cycles DMA disponible, on peut connaître le nombre de sprite par vbl.

Cas BOB A:
Dans une résolution de 304*200 en 5 Biplans, et dans le cas ou tu dois sauver le décor sous le sprite dans un buffer (s'il reste de la place dans la mémoire avec les 512ko...), afficher le sprite et le restaurer, tu pourras afficher presque 13 sprites 5Biplans de 32*32 par scanline (le blitter est sympa mais ce n'est pas une brute non plus...).

Cas BOB B:
Dans ce jeu on a vu que le codeur a réussi à loger tout le décor dans la mémoire pour certain level, donc dans ces niveaux, pas de gymnastique cérébrale pour sauver le décor, tu affiches le sprite et tu restaures le décors en piochant les coordonnées dans son buffer.
On obtient donc une performance de 17 sprites de 32*32 par scanline (on est trèèèès loin d'une Mega Drive mais c'est du 32 couleurs).

Ce calcul de sprite "BOB" en 5 biplans ne prend pas en compte les cycles DMA pris par les sprites hardware et l'audio. Si tout est activé tu peux enlever presque 2 BOB dans les deux cas!
En rajoutant la gestion du multiplexage, les 2 rasters, les IA, les collisions, le découpage et le reste de la logique du jeu, on se retrouve dans le cas A avec 11 sprites 5Biplans de 32*32 par scanline, et dans le cas B, 15 sprites 5Biplans de 32*32 par scanline.

Maintenant, regarde l'écran ci-dessous, sachant que je ne prends pas en compte;

• Les grosses gerbes de sang lors des impacts ;
  
• Les potions qui peuvent rester au sol ;
  
• Le gros bouclier magique ;
  
• L'absence de scroll différentiel dans ce niveau (qui peut prendre plus d' 1/4 écran dans certains levels) ;
  

Ça nous fait un volume "32*32" (à la louche car il y a du 16*X, etc..) d'environ 2 sprites pour une petite partie du HUD + 9,5 sprites pour la dame + 7,5 pour le soldat, soit 19 sprites !
Alors qu'il nous manque encore 3 soldats à afficher (SIC!) plus tous les autres sprites cités au-dessus (et pas de parallaxe) , dans le cas A on sort laaaargement de la VBL (19 BOB>11 BOB) et dans le cas B on est privé des 50 fps également(19 BOB>15 BOB)...

Bien-sur, on peut optimiser le découpage avec des sprites de 48*X, 64*X, X*X ( j'ai voulu que l'exemple soit plus facile à appréhender) pour gratter et peut être obtenir la VBL dans le cas B ... mais dès qu'il y aura une gerbe de sang et/ou une potion (voir pire le gros bouclier magique) on passera direct en 2VBL et il reste encore 3 personnages à afficher et pas de parallaxe...

Dans ce jeu on travaille avec des sprites en 32 couleurs sur un décor en 32 couleurs, l'Amiga ne peut pas travailler dans un mode optimal avec ce cas de figure car le Blitter perd en performance (trop de cycles DMA volés). C'est peu courant sur Amiga d'avoir des jeux d'action avec des sprites en 32 couleurs.

En prenant tous les autres sprites non comptabilisés dans le screenshoot, cette démonstration montre qu'en consacrant plus de temps sur les sprites (bonjour le temps de dev en plus...)+ un scroll hard, le développeur aurait pu faire tourner son jeu en 3 VBL (voir 2VBL dans le cas d'un level court sans scroll diff et 3-4 perso ) au lieu des 4/5VBL qui nous donne le IIGS gagnant avec ses 3/2 VBL...
Dans mon exemple avec sprites optimisés mais sans le scroll hard, on aurait un frame rate proche des 4VBL, voir 3 VBL dans certains cas (Et 2 si pas grand chose à l'écran). On se rapproche donc des performances de Sword en 1989 mais en un peu mieux.

Cnnclusion : Sword of Sodan ne pourra jamais tourner en 1 VBL, c'est mathématique !

[Templeton]

Stafa92: En comparaison, SOTB utilise jusqu'à 6 bitplans, a des sprites bien plus gros (mais moins colorés) ou plus nombreux et ne souffre pas de cette lenteur.

Tu surestimes l'Amiga parce que tu prends comme modèle Shadow of the Beast pour afficher un sprite software. SOTB utilise un système de transfert peu conventionnel très rapide, mais ultra contraignant et totalement incompatible avec Sword of Sodan (voir plus bas pourquoi). De plus, les sprites softwares ''imposants'' dans SOTB sont un peu plus petits, moins nombreux et toujours en 3 biplans (7 couleurs).

Dans SOTB le héro (+ le HUD) utilise 6 sprites hardware avec multiplexage (zeppelin, planète, etc...), et il en reste 2 pour afficher seulement 1 monstre.
Ces deux sprites hard sont utilisés pour afficher un type de "pieu" très grand de 16 pixels de large en 15 couleurs max (concaténé) ou, un monstre de 32 pixels de large qui fait souvent tache avec ses 3 couleurs.
Ces monstres sont très faciles à repérer car ce sont les seuls qui sont affichés sur le décor du premier plan et sur les sprites soft.

Tous les autres monstres (les plus répandus) sont des "sprites softwares" en 3 biplans donc en 7 couleurs max ! Dans SOTB les monstres sont majoritairement en 3 ou 7 couleurs max!


Pour afficher ses sprites softs le plus rapidement possible, le codeur a utilisé une astuce géniale qui est totalement incompatible avec Sword of Sodan (et Beast 2 et 3).

Petit rappel pour les néophytes, pour poser un sprite software au CPU ou avec le Blitter (BOB) sur le décor il faut réaliser 4 opérations:
1 Sauvegarder le décor sous le sprite dans un buffer (un espace dans la mémoire).*
2 Poser le masque du sprite sur le décor via une opération logique (comme un pochoir en fait).
3 Poser le sprite sur la partie masquée du décor via une autre op logique.
4 Copier le contenu du buffer pour effacer le sprite et restituer le décor une fois la vbl passée.
*Sauf si on a la possibilité de loger l'intégralité du décor dans un gros buffer.

Cette technique est coûteuse en cycles (3 ou 4 transferts, dont 2 avec des op logiques), coûteuse en mémoire (buffer de sav), etc ...

C'est ce procédé (ou un équivalent) qui a été utilisé dans Lionheart (ainsi que dans Chuck Rock 1 et 2, Wonder Dog, Mr Nutz, Agony, etc...) avec les défauts que l'on connaît. Sprites peu nombreux et qui se fondent dans le décor car dans les mêmes biplans que ce dernier (Lion Heart, Kid Chaos, Mr Nutz, Chuck Rock...), des ralentissements dès qu'il y a 4 sprites (Lion Heart , Wonder Dog,...), des sprites en 2 VBL (25i/s) comme dans Agony ou Forgotten World par exemple.
L'image ci dessous est un pot pourri des jeux cités ci-dessus récupérés sur le site Lemon.


Comme vous pouvez le voir, on ne distingue pas au premier coup d'œil les sprites ennemis. Ils sont toujours dans la même palette que le décor d'avant plan (parfois dans le second) et toujours en 7 couleurs ! C'est le plus gros défaut de l'Amiga face aux machines d'arcade et aux consoles de l'époque avec le Dual Playfield.
L'autre constat c'est qu'il y a très peu de sprites dans ces screen-shoot sauf dans 2 jeux (Agony et Forgotten World) qui sont les seul dans le groupe faisant tourner les monstres en 2VBL (25fps)
contre 1VBL pour les autres ! C'est le deuxième plus gros défaut de l'Amiga face aux consoles et machines d'arcades (peu de gros sprites softwares masqués en 1VBL avec le dual playfield).

Pourtant ces défauts n'apparaissent pas dans Beast.
Pour éviter toutes ces contraintes le programmeur a utilisé une toute autre technique qui nécessite qu'un seul transfert! Oui vous avez bien lu UN seul transfert au lieu de 3 ou 4 !!!
Voici la technique:
On pose le sprite soft sur les 3 premiers biplans avec une simple copie sans aucune opération logique et avec du vide autour pour qu'il s'efface lui même quand il se déplace !
Et si SOTB parait plus coloré que dans les autres jeux c'est aussi grâce à cette astuce (voir plus bas).
Évidement cette technique tape à l'œil génèrent des contraintes très très pénalisantes pour le level design ET le game design !

La première contrainte est qu'il ne doit jamais y avoir de décor devant et derrière le sprite car le masquage est réalisé avec la palette ! Voir ci-dessous :



Le premier screen shoot à été pris dans le jeu, le deuxième est un montage qui dévoile le problème si on voulait poser la corne jaune devant la foret (sprite dans la même palette que le décor).

La deuxième contrainte est de taille! On ne peut pas poser ce type de sprite software sur l'avant plan !!! Voila ce que ça donnerait:


Le premier screen shoot à été pris dans le jeu (purée c'est BÔ !), le deuxième est un montage qui dévoile exactement le problème si on voulait poser la corne jaune sur le décor avec cette technique (le sprite trouerait obligatoirement l'avant-plan).

Dans ce jeu, lorsque qu'un sprite passe devant le décor ou un autre sprite, il s'agit toujours d'un des 2 sprites hardwares restants au programmeur.
Il est toujours en 3 couleurs généralement, sauf quand il est concaténé (racine, herse).

La troisième contrainte (la pire !) est tout aussi pénible, les sprites ne doivent pas se chevaucher! il faut s'arranger pour qu’ils soient éloignés de 16 pixels minimum sinon c'est la cata. Voici une séquence réelle prise dans le jeu (il n'y a aucune retouche !) ou l'on peut voir en plus "l'auto effacement"(gros débord transparent autour du monstre):



C'est pour cette raison que les monstres software (majoritaire dans ce jeu) attendent tous bêtement à la "queue leu leu" avec une distance égale avant de vous frapper, car il ne faut pas qu'ils se chevauchent.

Cependant, toutes ses contraintes offre un avantage esthétique car on peu isoler la palette des monstres avec le copper et donc rendre le jeu plus coloré, voir ci dessous:



A gauche la capture dans le jeu et forcement à droite, le jeu tel qu'il le serait sans le changement de palette. Remarquez au passage les monstres placés en rang d'oignon sur une distance minimale de 16 pixels pour éviter qu'ils s'effacent entre eux (c'est pareil avec les biped).

Et la démonstration ne concerne que les sprites soft car d'autres techniques ont été utilisées pour gagner du temps machine (pas de vrai scroll multidirectionnel par ex), ou gonfler artificiellement le nombre de couleurs dans le décor (via le copper), qui sont toutes aussi astreignantes pour le level design.


Bref, toutes ces contraintes techniques dans Beast ne permettent pas de faire un jeu avec un level design pointu et alambiqué. Voilà pourquoi Beast 2 et 3 sont moins beaux mais plus intéressants alors qu'ils sont réalisés par les mêmes personnes ! Ils n'utilisent quasiment plus cette technique et ont trouvé un autre chemin plutôt malin.

Les auteurs ont changé leur fusil d'épaule et ont décidé de faire des jeux avec gameplay et un level design plus élaboré (avec plus ou moins de réussite dans le 2ème opus), adieu le bling bling et place à plus de liberté dans la création pour plus de Fun !

[TotOOntHeMooN]

Merci d'avoir pris le temps de le faire !

[Invité]

Pareil 
Mais je trouve quand même qu'il y a plus un soucis dans le code qu'un problème hardware .

[cryodav76]

merci des explications(hate a la réponse de stapha)
par contre tu compares une machine avec extension de ram voir carte accélératrice contre a amiga500 512ko
d'ailleurs vu l'acceleration que cela procure on peux deviner que le jeu est fait au cpu?
on pu noté que c'est un des seul jeux ou il dominerai en vitesse(quoique et si on le fait en 16couleurs sur amiga aussi?)
tous les autres jeux,demos sont bien bien loin de l'amiga(sauf peu etre un wolfenstein).je trouve par ailleurs lionhearth plus beau sur amiga que la plupart de tous les jeux consoles...

[Zarnal]

L'autre constat c'est qu'il y a très peu de sprites dans ces screen-shoot sauf dans 2 jeux (Agony et Forgotten World) qui sont les seul dans le groupe faisant tourner les monstres en 2VBL (25fps)
contre 1VBL pour les autres ! C'est le deuxième plus gros défaut de l'Amiga face aux consoles et machines d'arcades (peu de gros sprites softwares masqués en 1VBL avec le dual playfield).

Bonsoir, encore une question : si on utilise les sprites hard uniquement pour simuler un second plan en se passant du dual playfield, les contraintes sont elles les mêmes ?

Je pense à videokid ou à flink aga en particulier. Pour ce dernier le souci du nombre de sprites semble se poser.

Videokid : à 12.32 ou 19.45 par exemple.




Merci.

@touko

merci

[Templeton]

cryodav76: par contre tu compares une machine avec extension de ram voir carte accélératrice contre a amiga500 512ko

Heu... je ne suis pas l'initiateur de cette comparaison, hein ! :)
D'ailleurs, j'avais bien préciser quelques pages avant que le IIGS tirais avantage de cette ram supplémentaire.  

cryodav76: on pu noté que c'est un des seul jeux ou il dominerai en vitesse(quoique et si on le fait en 16couleurs sur amiga aussi?)

Tu as raison, j'ai toujours vu les jeux sur IIGS saccadés avec un paquet de déchirure à l'écran. Ce jeu est une aubaine pour les fans de cette machine.
Avec un jeu en 4 biplans, une extension mémoire et le scroll Hard on aurait un frame rate proche du IIGS sans carte accélératrice.

[Templeton]

TOUKO: Pareil  
Mais je trouve quand même qu'il y a plus un soucis dans le code qu'un problème hardware . 

Personnellement, le frame rate de Sword of sodan ne me choque pas dans la mesure ou je n'ai jamais vu un jeu sur Amiga avec des sprites aussi gros et aussi coloré en 1 VBL.

Celui qui se rapproche le plus c'est Final Fight et il a toutes les peines du monde pour faire tourner le jeu en 2 VBL avec 3 monstres en 16 couleurs.

L'amiga est une superbe machine, mais je crois que tu la vois plus belle qu'elle ne l'est. C'est beau l'amour !

[cryodav76]

final fight est pas terrible sur amiga en gros sprites il y a c'est vrai pas grand chose, fighting spirit , final blow 
en fait il faut faire le jeu par rapport au hardware pour que ce soit correct

[Invité]

Celui qui se rapproche le plus c'est Final Fight et il a toutes les peines du monde pour faire tourner le jeu en 2 VBL avec 3 monstres en 16 couleurs.

Oui les sprites au blitter font mal ici, mais pk ne pas avoir utiliser au moins des sprites hard pour le(s) joueur(s) ??
Car eux aussi sont fait au blitter .
Donc 5 persos en 1 joueur et 6 en 2P à l'écran tout au blitter, c'est plutôt pas mal je trouve, même en 2 vbl .
Mais bon final fight a aussi été rushé du fait d'avoir perdu bcp de temps à ripper les gfx directement de la borne .
Ce qui manque le plus à FF amiga, c'est pas la vitesse, 2 vbl pour un BTU c'est largement suffisant, c'est surtout le fait d'avoir supprimé bcp de phases d'anims pour faire tourner le jeu en 512ko .

L'amiga est une superbe machine, mais je crois que tu la vois plus belle qu'elle ne l'est. C'est beau l'amour ! 

Non l'amiga a pas mal de défauts inhérents à son système de sprites et à son année de conception .
Mais on peu pas nier aussi que son hard à permis de belles choses, quelques fois infaisables sur MD ou snes, comme le zoom énorme des boss de Mr nutz avec un changement de palette à la volée et un scroll multidirectionnel sur 2 plans derrière, et le tout en 1 vbl .

https://youtu.be/j5e78_9Eo2Y?t=55m30s

Je trouve ça impressionnant pour une machine de 85 .

[TotOOntHeMooN]

Oui, mais là est tout le problème... L'Amiga brille de part des exceptions.
Après, on ne peut pas nier que c'est une excellente machine d'un point de vu informatique.

[cryodav76]

Comme vous pouvez le voir, on ne distingue pas au premier coup d'œil les sprites ennemis. 

je suis d'accord avec toi mais en même temps les Screenshots sont petits 
en réel bien que gênant pour certains titres, ce n'est pas aussi marqué car ça bouge...
de plus sur un moniteur bien contraster ça ce vois encore moins.
certain titre comme ork malgres une certaine beauté en souffre beaucoup.
apres l'amiga c'est un hard de 1985 et je trouve carrément extraordinaire ce que les développeurs ont pu en faire
j'ai en mémoire une demo d'un jeu spatial en 3D texturé fluide sur a1200 stock+ram ,j'aimerais bien retrouvé la video d'ailleurs

[Invité]

Oui, mais là est tout le problème... L'Amiga brille de part des exceptions.
Après, on ne peut pas nier que c'est une excellente machine d'un point de vu informatique.

Bah personne ne dit que l'amiga est la meilleure machine qui soit, juste que pour une machine de 85, elle s'en sortait vraiment bien et était très polyvalente,et qu'elle se permettait aussi d'en montrer à des consoles sorties 2 ans après .
C'est pas pour ça que les consoles étaient parfaites pour autant,elles ne brillaient pas sur tout non plus .

[TotOOntHeMooN]

Bah personne ne dit que l'amiga est la meilleure machine qui soit [...]

C'est pourtant la raison d'être des amigaïstes, ici ou ailleurs. 
Car trop souvent, ils ne comprennent pas que les prouesses sont des cas isolés et techniquement bien délimités.
Pour cela, qu'il est vraiment intéressant de voir quelqu'un prendre de son temps pour expliquer ce qu'il en est.
Et oui, une console 16 bit fait mieux dans la plupart des cas mais en même temps elles n'ont pas la capacité multimédia d'une telle merveille (surtout du CDTV... Mais ça, c'est une autre histoire).

[Tryphon]

Je tenais à remercier Templeton pour ses posts très instructifs. Il faudrait faire un post fermé où un modo récupère les messages intéressants de ce topic (parce qu'il y en a, perdus dans des centaines de pages ineptes)

Je préviens tout de suite : mon message n'y sera pas :

C'est pas pour ça que les consoles étaient parfaites pour autant,elles ne braillaient pas sur tout non plus .

J'aurais pourtant cru que tu reconnaissais à la Megadrive de brailler surtout !

[Invité]

Non ici c'est amiga vs ST rien d'autre .
Perso y'a des trucs que j'adore sur amiga, des effets incroyables des fois,et des trucs que j'aime pas,comme des défauts gênants aussi quand tu compares aux consoles 16 bits(plus récentes) .
Donne moi un ordi qui faisait aussi bien que le mig (A500) pour le même prix jusqu'en 89 ??
Bien sur qu'un x68000 défonce un amiga, mais défonce tout autant une console 16 bits, seule la NG fait mieux,mais bon à quel prix aussi .
L'archimedes ???
Dans certains domaine oui, pour le jeu non, avec un prix de 2x celui du mig,et l'archie se faisait tout autant défoncer par le x68000 .

Quand le mig est sorti, il y avait quoi comme références en matière de hardware à part l'arcade ??, des ordis/consoles 8 bits .

Et oui, une console 16 bit fait mieux dans la plupart des cas mais en même temps elles n'ont pas la capacité multimédia d'une telle merveille (surtout du CDTV... Mais ça, c'est une autre histoire).

Je suis d'accord, mais si on prend la PCE ou la Md c'est 2 ans après, un gouffre en info,la snes c'est quasi 5 ans .
Que faisait le ST ou mieux le STE ??
Que faisait l'archimedes ??
Le truc c'est pas de prouver que le mig faisait mieux que les consoles 16 bits, mais de dire que pour un hard bien plus vieux, il s'en sortait vachement bien,pour moi le constat est plutôt là,alors que les autres micros étaient largement à la ramasse .

J'aurais pourtant cru que tu reconnaissais à la Megadrive de brailler surtout ! 

Merde petite couillasse, je corrige 

[upsilandre]

Je suis d'accord, mais si on prend la PCE ou la Md c'est 2 ans après, un gouffre en info

Mais pour 10 fois moins chère, un gouffre aussi, c'est de toute facon impossible a comparer.

[cryodav76]

Bah personne ne dit que l'amiga est la meilleure machine qui soit [...]

C'est pourtant la raison d'être des amigaïstes, ici ou ailleurs. 
Car trop souvent, ils ne comprennent pas que les prouesses sont des cas isolés et techniquement bien délimités.
Pour cela, qu'il est vraiment intéressant de voir quelqu'un prendre de son temps pour expliquer ce qu'il en est.
Et oui, une console 16 bit fait mieux dans la plupart des cas mais en même temps elles n'ont pas la capacité multimédia d'une telle merveille (surtout du CDTV... Mais ça, c'est une autre histoire).

les prouesses comme tu dis sont devenu un standard 
lionheart a combien de couleurs de parallaxes? pourtant avec un bon joysctick le gamepla est tres bon
kid chos est rapide , a un nombre incroyable de parallaxe le gameplay est plutot bon aussi
biran the lion a combien de couleurs ? et il est pourtant assez jouable
alors ok le gameplay des jeux console est souvent au dessus mais les console on aussi leur limites
quastion de gouts
et puis l'amiga ce n'est pas que les jeux type console c'est beaucoup de str dune 2, the settler genesia etc
et des jeux d'aventures comme secret of monkey island et ils sont tres nombreux et tres bon.
et l'amiga c'est avant tout un ordinateur complet et un OS incroyable 
les mods c'est lui,le plug and play c'est lui ,le multitache preemtif utilisable c'est l'amiga
quand j'utilise mon A1200 cette un petit peu booster avec un hdd c'est vraiment une machine qui etait tres tres en avance sur son temps.

[cryodav76]

Je suis d'accord, mais si on prend la PCE ou la Md c'est 2 ans après, un gouffre en info

Mais pour 10 fois moins chère, un gouffre aussi, c'est de toute facon impossible a comparer.

j'ai acheté ma megadrive 1890FR a sa sorti 
1 an a peine   apres je m'achetai un amiga en solde pour 990FR

[TotOOntHeMooN]

Rien de standard... Juste des exceptions parmis des milliers de titres commerciaux. 
L'Amiga c'était un ordinateur formidable qui peut encore surprendre aujourd'hui, on est bien d'accord.

[TotOOntHeMooN]

j'ai acheté ma megadrive 1890FR a sa sorti 
1 an a peine   apres je m'achetai un amiga en solde pour 990FR

J'ai acheté une Megadrive à sa sortie au Japon (1988) et je l'ai revendu pour acheter un Amiga (1989).
De souvenir, j'ai plutôt dû ralonger de ma poche les 2000F nécessaires pour avoir un A500...

[Seb]

Templeton: attention, tu vas te faire des enemis sur ce thread si tu expliques que l'Amiga n'est pas aussi puissant que ses fans le pensent, même si tu le fais scientifiquement par A + B

[Invité]

Je suis d'accord, mais si on prend la PCE ou la Md c'est 2 ans après, un gouffre en info

Mais pour 10 fois moins chère, un gouffre aussi, c'est de toute facon impossible a comparer.

heu tu abuses un peu par 10x moins chère, il devait y avoir 1500/2000 francs d'écart grand maxi, et tu peux pas comparer une console avec un ordi, même un ordi 8 bits coûtait plus cher qu'une console 16bits .

Templeton: attention, tu vas te faire des enemis sur ce thread si tu expliques que l'Amiga n'est pas aussi puissant que ses fans le pensent, même si tu le fais scientifiquement par A + B 

Pas du tout, y'a quand même une différence entre un amiga est moins bien qu'une console 16 bits avec de vrais arguments, et un amiga c'est complètement de la merde,sans autre argumentation que le fanboyisme .

De souvenir, j'ai plutôt dû ralonger de ma poche les 2000F nécessaires pour avoir un A500...

Tu as revendu une console en occase pour acheter le mig en neuf ??
Si c'est le cas, ma foi c'est un peu normal .

[cryodav76]

j'ai acheté ma megadrive 1890FR a sa sorti 
1 an a peine   apres je m'achetai un amiga en solde pour 990FR

J'ai acheté une Megadrive à sa sortie au Japon (1988) et je l'ai revendu pour acheter un Amiga (1989).
De souvenir, j'ai plutôt dû ralonger de ma poche les 2000F nécessaires pour avoir un A500...

oui a ses dates l'amiga etait assez cher
tu as du la payé chere aussi la megadrive import

[cryodav76]

Templeton: attention, tu vas te faire des enemis sur ce thread si tu expliques que l'Amiga n'est pas aussi puissant que ses fans le pensent, même si tu le fais scientifiquement par A + B

templeton dit clairement que l'amiga est un super ordi
apres x ou x façon d'allé la ou l'on veux allé c'est bien le principal etant le resultat
mais c'est tres cool d'en apprendre sur sa machine 
en terme technique j'aimerais avoir aussi des explications de certain effet comme le rotor zoom temps reel de l'intro de brian the loin ,la deformation avec effet tunnel temps reel de ce meme jeu
du scrolling parallaxe et nombre de couleur de lionheart de la vitesse d'affichage et des sprites de megatyphon
etc 
on depasse largement les capacités originel jusqu'a ou pourrait t'on allé???....
impossible n'est pas amiga 

[TotOOntHeMooN]

oui a ses dates l'amiga etait assez cher
tu as du la payé chere aussi la megadrive import

La Megadrive coutait 1690F avec un jeu en import à l'époque. Soit moins cher que lors de sa sortie nue en France deux ans plus tard. Pour rappel, à 20980¥ (prix au Japon), c'était équivalent à 990F HT.

[cryodav76]

oui a ses dates l'amiga etait assez cher
tu as du la payé chere aussi la megadrive import

La Megadrive coutait 1690F avec un jeu en import à l'époque. Soit moins cher que lors de sa sortie nue en France deux ans plus tard. Pour rappel, à 20980¥ (prix au Japon), c'était équivalent à 990F HT.

ah oui c'etait l'arnaque pour la version euro mais bon j'ai pas regretté,the revenge of shinobi ,phantasy star 2 ,street of rage ,sonic thunderforce 4 des super jeux
j'ai decouvert l'amiga apres et j'ai eté tres surpris je pensais que c'etait un st avec juste un meilleur son
finalement le son etait meilleur que la megadrive(qui etait deja assez largement devant le st) mais pas mal de  titres etaient au niveau   battlesquadron, turrican2, alien breed, pinball dream, sotb, unreal ,lotus 2, eye of beholder etc
et puis les demos....les mods