Amiga AGA vs Megadrive
-
Concernant Final fight AGA, le problème avec ces jeux de capcom, c’est pas la puissance processeur requise, c’est la mémoire.
Actuellement, il y a une version deluxe de ghouls’n’ghosts CPS1 directement adapté pour l’Atari STE en 4mo de ram 16 couleurs.
Le jeu utilisera le programme de la machine d’arcade hacké pour tourner sur le STE.
en fait, pour les conversions, il y avait donc souci de ram dispo, mais aussi de compétences en terme de programmation. Les japonais des boites de dev de jeux avaient un niveau incomparablement plus fort que leur homologues européens ! Et ça, ça compte !
Concernant Street Fighter 2, pareil, U.S.gold n’a jamais demandé à Capcom le code source et les assets du jeu, résultat, de la merde !
Par contre, Capcom a fourni directement le code source pour SSF2 et SSF2T.Petite anecdote : la version A1200 utilise 128 couleurs seulement et pas 256. De plus, le programme utilise les nouveaux registres du 1200.
Maintenant, le problème ici c’est que le programmeur Amiga a fait plusieurs conneries :
1) il n’a pas retiré le frameskipper de la version PC, résultat le 68030 est obligé de se cadrer sur un framerate fixe en 60 fps! résultat, il y a lors d’une VBL des animations qui ne se jouent pas, et des palettes qui ne sont pas mises à jour !
2) Toutes les étapes d’animations sont présentes….. les boules hein ?
En gros le programme a été plus ou moins massacré à cause du temps alloué pour le développement de la version Amiga.Il aurait fallu qu’il parte directement du code source de la machine d’arcade et pas du code source adapté pour le PC.
intéressant sur les rapports entre Capcom et les différentes versions de SF2.
Pour ce qui est de la différence de niveau entre les développeurs japonais et européens, deux questions :
– qu’est ce qui te fait dire ça?
– quelles en seraient les raisons?
Pour ce qui est de la mémoire, la Megadrive n’avait que très peu de RAM (74 ko + 64 ko de mémoire vidéo), de même que la SNES (128 ko + 64 ko de mémoire vidéo). D’une manière générale, les consoles ont toujours moins de mémoire vive que les ordinateurs de même génération. Comment les programmeurs faisaient-ils pour s’en sortir avec aussi peu de mémoire?
PS : je viens de regarder les caractéristiques du CPS1, la mémoire n’est pas faramineuse non plus… 64 ko + 192 ko de mémoire vidéo!
Le stockage est en cartouche donc les temps d’acces sont ridicules d’ou le peu de memoire et pas d’os en arriere plan ca limite aussi.
ok donc si je comprends bien la cartouche (ou la carte fille en arcade) fonctionne comme un disque dur de taille variable où le programme peut lire à la volée les données au lieu de les charger en RAM.
Du coup, le portage d’un jeu dans une version installée sur disque dur poserait moins de contraintes techniques que le portage sur du même jeu sur disquettes?
Je viens de lire le sujet sur le développement du portage de Ghouls’n’Ghosts, c’est très intéressant et passionnant!
Ghouls ‘n Ghosts
Arcade (le top)
Megadrive (le décor a déjà un peu perdu de sa superbe, mais on reste sur un 68000 à 7.6Mhz)
Amiga (tout le budget est passé dans le .mod d’intro :))
En ce qui concerne l’aspect technique :
Comme cela a été abordé, la présence des cartouches a été un avantage déterminant pour les consoles, qui pouvaient se permettre un temps d’accès aux données très court avec une capacité de stockage bien plus étendue et ce malgré une quantité de RAM embarquée vraiment faible, mais rafraichie en permanence.
C’est pourquoi à la sortie de l’A1200 beaucoup de développeurs de jeux ont poussé Commodore à en faire une console CD. Leur insistance était probablement motivée aussi par une volonté de lutter contre le piratage des disquettes, mais c’est un autre sujet. La CD-32 (et son design de brique) a été la réponse tardive de Commodore.
L’autre différence technique qui rend l’absence de cartouche encore plus cruelle pour les ordinateurs 16/32 bit, c’est que les consoles avaient en hardware la capacité de retourner les sprites (d’inverser la position de leurs pixels horizontalement ou verticalement). Ce point est crucial pour un jeu comme SF2 aux très nombreuses brosses nécessaires pour constituer toutes les animations et dans lequel le personnage peut changer de côté, donc se retourner. En résumé, avec un support de stockage nettement plus petit, nos ordinateurs devaient stocker deux fois plus de brosses.
Plus important que la technique, la différence de résultat entre certains titres sur les différentes plateformes tient souvent au budget de développement. Les parcs installés étaient à l’avantage des consoles, répandues sur tous les continents, là où les micros étaient surtout présents en Europe, aux USA, mais très peu en Asie. Par ailleurs tous les possesseurs de consoles ont acheté au moins un ou deux jeux, c’était loin d’être le cas de tous les possesseurs de micros (copies).
Donc, plus de ventes potentielles, cela fait plus de budget de développement, ce qui fait plus de temps, plus de développeurs, plus de beta tests, et au bout du compte une qualité supérieure pour les versions consoles.
Enfin je rajouterais à l’avantage de la Megadrive, le fait qu’elle était le bébé d’un spécialiste du jeu vidéo, qui lui a fait bénéficier de superbes titres exclusifs et qui avait toute la compétence maison pour en exploiter le potentiel technique, tout en gardant un droit de regard sur les productions tierces, ce qui n’existait pas sur les micros. Même la pire horreur pouvait être commercialisée.
Ce n’était pas du tout le métier ni l’intention de Commodore qui ne s’est jamais vraiment intéressé au jeux vidéo, laissant cela à des studios indépendants, dont même les plus talentueux (Team 17, BitMap Brothers, etc…) travaillaient à la bonne franquette et avec des moyens ultra réduits à côté des équipes de SEGA. Cela pouvait être une force parfois, mais c’était plus souvent un handicap impossible à compenser.
La comparaison n’est donc pas pertinente, mais mon intime conviction est que si le hardware de l’Amiga AGA avait inclus un port cartouche, que le parc installé avait été aussi vaste que celui des consoles et que derrière la machine il y avait eu un grand nom du jeu vidéo (cela fait beaucoup de si…), la Megadrive et même la SNES auraient pris (encore plus) cher dans les dents…
Mais on connait l’histoire… AGA arrivé trop tard bien que prêt depuis longtemps. Pas de mémoire FAST de base ni de lecteur haute densité, etc…
PowerMac - G5 2.0 GHz - 1.7 Go RAM - Radeon 9600P 128 Mo - MorphOs 3.13 et Peg2 - G4 RIP
Mac mini - G4 1.42 GHz - 1 Go RAM - Radeon 9200 32 Mo - MorphOs 3.9
WinUAE sur HP Core2 Quad 8200
Epave de Mist FPGA remplacé par un Sidi
A1200 malade 😉 et A500 512+512Ko RAM Kickstart 1.3bravo, ça fait plaisir de lire quelqu’un qui connait le sujet.
Pour ajouter une info au mécanisme hardware de mirroring des sprites :– ça concerne tous les tiles, y compris sur le décor
– on voit très bien ce que donne l’absence de cette feature sur Amiga : dans Shadow of the Beast, quand on retourne le personnage (de gauche à droite ou réciproquement), le framerate s’effondre de 50 à 25 FPS pendant quelques secondes, le temps que le 68000 retourne tous les sprites du héros (car il est stocké en mémoire dans un sens seulement, pas dans les deux)
– les consoles Japs (et bornes d’Arcade), jusqu’à la Nec32 bits, fonctionnaient en tile, et non en framebuffer bitplan/chunky. Énorme différence sur les perfs, qu’on pourrait détailler si certains sont intéressés.
Edit : pour prendre une analogie pourrie, comparer les performances d’un Amiga et d’une Megadrive, c’est aussi absurde que de comparer une camionnette Renault et un TGV. Ce sont deux véhicules, mais qui ne remplissent pas les mêmes objectifs et ne s’adressent pas aux même marchés, même s’ils ont des caractéristiques communes.
Alors oui, un TGV va 3x plus vite qu’une camionnette. Mais la camionnette est infiniment plus polyvalente.
Un projet existait pour transformer la Megadrive en ordinateur complet, mais le boulot aurait été enorme, et à quel prix ?
Ajouter une mémoire de masse, de la mémoire vive, écrire un OS, former les développeurs, recruter des developpeurs tiers pour réaliser quelques utilitaires « killer apps ».Une console n’est qu’une coquille vide, avec un hardware conçu pour :
– couter le moins cher possible (la MD a été vendue à 40 millions d’unités, donc le cout du moindre condensateur à un impact énorme)
– servir un objectif unique, bien loin de la polyvalence d’un micro (qui peut servir à faire de la compta, de la musique, de la vidéo, de l’éducation, etc).Bisous.
@ leo
http://www.atari-forum.com/viewtopic.php?f=26&t=31479&sid=c5822dc59031cb77f0960c6a9b90e8ba
@ logo
point de vue intéressant. Je suis assez d’accord sur le fait que Sega était un poids lourd et que derrière il y avait des équipes sans commune mesure avec la plupart des studios qui développaient sur ordinateur. Et c’était sans doute vrai des équipes de Nintendo, Capcom, Konami, Taito…
D’accord aussi que le budget (et le temps alloué) sont déterminants dans la qualité finale des jeux.
Par contre, je suis plus dubitatif au niveau de la taille des parcs installés. Les Etats-Unis étant le premier marché équipé, le nombre d’ordinateurs rivalisait probablement avec les consoles. Et le piratage n’explique pas tout, certains jeux sur ordinateurs se sont très bien vendus (je pense à Lemmings par exemple)! En moyenne, je ne pense pas que les possesseurs d’ordinateurs achetaient moins de jeux que les possesseurs de consoles. Par contre, ils jouaient à plus de jeux, c’est sûr!
@ astrofra
Si ton explication est accessible au commun des mortels, je suis preneur 🙂
Les tiles.
pour faire court :– toutes les consoles japonaises avant la Saturn et la PSX fonctionnaient exclusivement en mode TILE (NES, Master System, MSX, Megadrive, SNES, Neo Geo, WonderSwan, PC Engine, GameBoy, et presque tous les jeux d’arcade Japonais jusqu’à 1990, au moins)
– une tile est un bloc de 8×8 pixels (en général), stocké dans la mémoire vidéo de la machine (l’équivalent de la chip ram), accessible en direct par le circuit vidéo. Pour dessiner un écran, la console dispose d’une grille d’index qui pointent chacun sur une tile. Ils peuvent pointer sur la même, ou sur des tiles différentes. On peut donc utiliser une tile autant de fois que nécessaire pour recouvrir l’écran (exemple : un mur de briques, un dégradé dans le ciel).
– le mode TILE des consoles SEGA est historiquement dérivé d’un chip graphique Texas Instrument, qui a commencé à équiper les tous premiers appareils domestiques orienté « jeu » au Japon
– le mode TILE est très rapide, au contraire du mode framebuffer qui équipe tous les ordis occidentaux. Une fois les tiles chargées en vram, la machine peut redessiner TOUT l’écran en modifiant un tableau de ~2000 octets seulement (40*25 tiles *2 octets). Pour faire la même chose sur un Amiga, le CPU (ou le blitter, via le DMA) doit mettre à jour, au minimum, 32000 octets (soit 16 fois plus)
– gros inconvénient : pour tracer un pixel sur une Megadrive, c’est compliqué. On doit d’abord allouer une tile vide en vram, dessiner le pixel dedans, et ensuite faire pointer la grille d’index vers cette tile.
Pour illustrer le fonctionnement des tiles, j’ai grabbé en vidéo un jeu bien connu à l’aide du mode debug de l’émulateur Megadrive « Gens » :
@ Astrofra
merci. Si j’ai bien compris, pour dessiner une image à l’écran :
– une console lit et dessine 40×25 tiles qui sont stockées en mémoire vidéo,
– un ordi dessine 320×200 points un par un (chiffres qui varient en fonction de la résolution).Du coup, est-ce qu’il n’est pas possible d’imiter le fonctionnement par tiles en utilisant le blitter?
Si, c’est ce que font quasiment tous les jeux Amiga (X-out, Turrican, Shadow of the Beast), mais ça ne change rien.
Même avec le blitter, si on doit envoyer 10x la même tile à l’écran, on doit blitter à chaque fois la quantité d’octets de la tile (640 pixels en tout, soit un peut plus d’1 Kilo octet).
Avec l’architecture en mode tile, pour tracer la même tile 10x de suite dans l’écran on a, au pire, seulement 20 octets à mettre à jour.
En fait, le mode tile évite d’avoir à COPIER les données graphiques en permanence, parce qu’il utilise un système d’index.
Sur Amiga, même avec le blitter et le DMA, pour envoyer des donnée dans la ram vidéo, on doit les copier, en entier 🙂
Le seul exemple assez proche, sur Amiga, ce sont les sprites hardware, qui sont envoyés à l’écran sans avoir à copier les données à chaque frame dans la mémoire vidéo.
Mais sur OCS, la limite est de 8 sprites par scanline.
Certains jeux, comme Risky Woods ou Leander se servent du copper pour dépasser cette limite, mais c’est tellement contraignant que ça ne sert qu’à dessiner un arrière plan (quasi) statique :
- Vous devez être connecté pour répondre à ce sujet.
› Forums › AmigaOS, MorphOS et AROS › Général › Amiga AGA vs Megadrive
