Re: MEGADRIVE vs SUPER NINTENDO : Fight !

[Invité]

Oui étouffé, c'est plus ou moins ça, ça fait un peu son de jouet pour les gosses. Sur amiga tu n'as surement pas toute la chip que tu veux non, je dirais même que si le programmeur laissait 150ko pour le son, ben le musicien il avait bien du bol.

J'ai dit si tu veux, CAD que si tu fais un pong rien ne t'empêche d'utiliser le reste de chip pour les sons et ou la musique ..
La snes, c'est 64ko et rien que ça, même pour un pong .

Et non les jeux manquaient pas de pattern d'anim dans les sprites pour les raisons que tu donnes.

Oh que si, l'amiga ne disposant pas de cartouche, tout est plus ou moins en chip /RAM, donc si tu as une bonne zique de qualité 80/100 ko (voire plus) + 50/60 ko pour les sons il te reste pas bcp de place pour les graphismes, sans oublier que l'amiga n'a pas de flip hard H/V sur les sprites (obligé d'utiliser le blitter surement,donc des cycles DMA), ni d'affichage en tile ..
Regardes lion hart, beau jeu, mais animations de sprites moisies car peu décomposée, et donc très rigide .
Et c'est le cas de bcp de jeux amiga .

Les développeurs disaient qu'ils auraient sinon développé pour la mégadrive, plus simple, avec un processeur plus rapide, et tout un paquet de sprites hardware. Il est aussi possible via des astuces de programmation ne nécessitant pas de se péter la nuque au passage d'atteindre plus de 90 couleurs à l'écran sur cette dernière.

J'aimerai bien voir ça !!! 

Le 68000 de la megadrive permet un code propre, simple, concis (les japonais sont d'ailleurs ou étaient du moins des cadors de folie en langage ASM 68000), sans parler d'un fait tout bête : les consoles fonctionnent en gros de la même façon que les machines d'arcade, avec un processeur principal qui n'arrête pas de recharger des données dans les registres du processeur d'affichage vidéo dédié. 

Non, les borne fonctionne comme la NG CAD que les graphs sont directement accessibles par la puce graphique dans la rom, comme la NG .
Sur console les puces graphiques disposent de VRAM pour travailler, et il faut transférer les graphs de la rom -> VRAM, c'est bcp moins puissant, mais bcp moins coûteux aussi .
Sur les bornes d'arcade le CPU sert pas à grand chose, contrairement aux consoles, et plus tu as de fonctions cablées, moins tu as besoin d'un CPU puissant .
Quand je pense que sur NG avec un 68000 @12mhz qui fait pas grand chose il a fallut rajouter une puce dans la cartouche des jeux de la NG-DEV team pour calculer les collisions, ça montre bien l'efficacité de ce CPU .

La snes affiche déjà pas 256 couleurs entières à l'écran

Le snes a 2/3 modes 256 couleurs, mais je me souvient plus lesquels .
Le mode 7 c'est sur .
Et tu crois quoi que la Md affiche 64 couleurs ???
Non elle peut (sans H/S) afficher que 61 couleurs .
Donc même si 120/150 était un chiffre exact, je préfère toujours ça à 61 couleurs .. 
Le H/S permet de tourner entre 56 et 70 couleurs max in game .

L'amiga, du moment qu'on lui sert de la musique sur 4 voix, faut savoir qu'il n'y a aucune charge processeur sur le 68000, du 0% quoi

Comme la snes, elle à un CPU dédié aux samples, ou comme la Md et son Z80 pour la partie FM ..

Après je passe le système de rotation de la console qui est buggé (si tu veux savoir pourquoi, demande-moi  ).

Réellement non, sans façon, dsl 

Peu importe pour rendering ranger, le programmeur est limité par la vitesse du processeur principal, et il doit faire avec.

Un conseil, lances toi dans le dev sur machines 8/16 bit, tu comprendras mieux .
La fréquence ne veux pas dire grand choses, tu t'ai jamais demandé pk capcom ou konami avaient de superbes jeux d'arcade, et faisaient des jeux consoles souvent mal programmés ??

effectivement, comme je disais, Nintendo a bien compris avec l'expérience sa boulette, et rajoutait des puces dans les cartouches, pasque sinon, y a plus d'un jeu qui serait pas sorti sinon. Et comme tu dis, la SNES aurait du avoir un processeur digne de ce nom à sa sortie, et pas dans les cartouches. Petit bras Nintendo sur le coup :)

Non, le CPU d'origine était là juste pour faire baisser les coûts de la console à son lancement, car nintendo savait pertinament que sa console était déjà prévue pour être boostée au besoin, et c'est ce qu'ils on fait, contrairement à SEGA ou même le MCD n'apportait rien de plus à cette pauvre MD,car justement les puces du MCD étaient limitées par l'architecture de la console .. 

Le mac je connais, mais pas l'apple 2GS, donc je peux pas dire.

Et bien si tu te renseigne, tu pourras y lire que le 2GS avec un 65816 @2,68 mhz affichait bien plus vite une image couleur qu'un mac avec un 68000 @8mhz une image monochrome .
Et c'est d'ailleurs pour des raisons commerciales qu'apple à proposé un 2GS si faiblement cadencé .

D'après ce qu'ils en disent oui, franchement la SNES c'était une chiasse à programmer, à toujours faire en sorte de pas étrangler le CPU principal. 

Une foi de plus ça montre que tu ne cherches pas d'infos plus loin que wiki, va sur le site nesdev dans la partie snes, tu verra que le CPU n'y est pour rien, et qu'il est même assez rapide   

Le 68000 a un mauvais rapport instructions / cycle, et n'est surement pas le meilleurs CPU pour une console 16 bit en terme d'efficacité .
Ses avantages, simple a programmer, code C efficace, très connu, et surtout un adressage 24 bit, très utile pour des roms de grosse capacité avec des timing assez haut et donc moins chères .

[sengoku 2]

La super nintendo affichait autant de couleurs que beaucoup de jeux arcade des années 90.
A l'écran, ça tournait à 8O jusqu'à 130-140 couleurs à peu près.
Et lorsqu'il y avait de la transparence, ça montait d'un coup à 160, 180 couleurs.  ( voire 200 mais assez rare )
La neo geo, c'était écrit 4096 couleurs, mais dans les faits, à l'écran il y a beaucoup moins de couleurs affichées à l'écran tout comme ses concurrents arcade.
Les tous premiers jeux ( 1990-1991), ça allait de 90 couleurs à 140 couleurs à l'écran.
Ensuite,c'était du 200 à 300 couleurs à l'écran.
Et plus les années avançaient, plus ça augmentait, certains vs fighting du genre KOF, on peut parfois déceler à peu près 500 couleurs à l'écran.

Ensuite, il y a aussi une histoire de palette à prendre en considération, par exemple le system 16 ( shinobi, golden axe etc...) de sega et la neo geo , c'était écrit 4096 couleurs.
Mais dans les faits, le system 16 avait des limites dans sa palette, d'où l'impression de jeux moins colorés.

Tout ce que je dis, c'est grâce au logiciel GIMP, très efficace pour compter les couleurs des screens format PNG, GIF etc... ( ne prenez pas de screens JPG) à la bonne résolution. ( c'est à dire prendre en compte un screen 256*224 sur SNES etc...)

En comptant les couleurs de jeux arcade CPS 1 etc..., on se rend compte que la SNES était très bien pourvue, digne des systèmes arcade.

Et donc, la megadrive avec 128 couleurs à l'écran, ça aurait été impeccable, proche de certains jeux arcade.

[Invité]

Bien sur que c'est une histoire de palettes, mais la snes à certains mode 8 bit comme le mode 7, donc 256 couleurs .
La PCE peut théoriquement afficher 482 couleurs, mais dans les fait c'est quasi impossible à atteindre, ou alors faut un pixel artist avec bcp de tallent, tout comme la MD fait plus dans les 50/55 couleurs réelles que 61 ..

En comptant les couleurs de jeux arcade CPS 1 etc..., on se rend compte que la SNES était très bien pourvue, digne des systèmes arcade.

C'est surtout aussi grâce à sa palette 15 bit, alors que la PCE et la Md n'ont qu'une palette 9 bit, la snes permet d'avoir des dégradés et un choix de couleurs bcp plus étendu, donc moins répétitif .

[Invité]

C'est surtout aussi grâce à sa palette 15 bit, alors que la PCE et la Md n'ont qu'une palette 9 bit, la snes permet d'avoir des dégradés et un choix de couleurs bcp plus étendu, donc moins répétitif .

C' est d' ailleurs pour ça que des jeux comme donkey kong country peuvent afficher des volumes 3D biens retranscrits en sprites (ou décors) parce que le super nintendo pouvait se permettre de plus grandes nuances et donc des dégradés plus riches .
Toy story est plus beau sur super nintendo car le rendu des objets est plus subtile que sur megadrive.

En même temps, il aurait été dommage que la super nintendo n' est pas cet avantage sur une console sortie quelques années avant.

Cela a aussi permit de sublimer les graphismes des RPGs. En pixel art, parfois quelques nuances en plus peuvent tout changer sur la représentation.

[Invité]

Oui,ça joue bcp dans le ressenti graphique ..

[Invité]

Purée, en parlant de ressenti graphique, je ressens 8 couleurs et je suis gentil :
https://www.gamopat-forum.com/t73619-xenon-2-megablast-sur-megadrive

OK il doit y en avoir au moins 16.

[Invité]

Bah c'est un port merdique des versions micro, avec en plus une musique de merde, donc il reste pas grand chose au final 

[xr4y]

J'ai commencé avec la MD donc gros coup de coeur même si la SNES la surpasse en presque tous points...

[TotOOntHeMooN]

J'aimerai bien voir ça !!! 

Laisse tomber, Turrican 3 c'est une catastrophe. Juste le premier niveau te permet de comprendre que c'est un Turrican sans le Mega devant... Ce jeux aurait du-être fait pour AGA et non ECS...

Les 87 couleurs, tu les as peut-être à un moment ou un raster passe à l'écran... La triste réalité étant que plus tu avances dans le jeu et plus les graphismes virent au monochrome façon C64.

https://www.youtube.com/watch?feature=player_detailpage&v=nEGVnl1yHvI#t=900
https://www.youtube.com/watch?feature=player_detailpage&v=6Nw4kR1zNzk#t=979

Mega Turrican (et même Super Turrican) sont bien supérieur et c'est bien triste pour l'Amiga. La seule chose qui sauve la mise étant évidemment la bande son en TFMX de Chris Huelsbeck qui sonne mieux (merci la RAM). Mais ça ne fait pas un jeu...

[Invité]

@toto:il parle de 90 couleurs sur le turrican MD ..

La seule chose qui sauve la mise étant évidemment la bande son en TFMX de Chris Huelsbeck qui sonne mieux (merci la RAM). Mais ça ne fait pas un jeu...

Pour la musique je suis d'accord, surtout celle d'intro qui est magnifique .

[TotOOntHeMooN]

@toto:il parle de 90 couleurs sur le turrican MD ..

Ecoute, il parlait d'Amiga et il site "Turrican 3", donc permet moi d'avoir eu un doute. 
Mega Turrican est une réussite insolente. On voit que c'est la team d'origine qui a bossé dessus.

[Invité]

Tu as raison il en parle aussi pour T3 ..

Moi c'était de ça dont je parlais

Les développeurs disaient qu'ils auraient sinon développé pour la mégadrive, plus simple, avec un processeur plus rapide, et tout un paquet de sprites hardware. Il est aussi possible via des astuces de programmation ne nécessitant pas de se péter la nuque au passage d'atteindre plus de 90 couleurs à l'écran sur cette dernière.

EDIT: j'ai modifié ma quote, car je m'était trompé de citation lol ..

[Stef]

Ouais la guerre est repartie

Même les musiques sont supérieures à la version Amiga dans Mega Turrican...

Je sais pas combien de foi faudra le dire, le CPU n'y est pour rien... blablabla..

Mais oui bien sur Touko, c'est bien connu, le CPU n'y est pour rien  

c'est l'archi de la console la seule responsable,tout ça pour concerver une compatibilité nes qui n'a jamais fonctionnée .
Tu es obligé de bouffer du CPU pour compenser, donc forcement avec plein de Mhz en plus tu peux développer comme un porc sans que ça rame .
Avec une organisation des données de sprites/background simple et cohérente en VRAM, et une SAT classique et bien organisée,la snes n'aurait pas ramée .
Une foi de plus dlrfsilver je te renvoie au jeu Rendering ranger R² sur snes, programmé par un connaisseur du CPU ..
Ou même super aleste ..

Je rectifie... oui l'archi de la SNES est merdique on est tous d'accord là dessus    mais le cpu aussi ce qui n'arrange rien !

Le 68000 a un mauvais rapport instructions / cycle, et n'est surement pas le meilleurs CPU pour une console 16 bit en terme d'efficacité .
Ses avantages, simple a programmer, code C efficace, très connu, et surtout un adressage 24 bit, très utile pour des roms de grosse capacité avec des timing assez haut et donc moins chères .

Quand est ce que tu comprendras qu'on s'en contrefiche du rapport instruction / cycle ? ce qui compte c'est l'efficacité de l'architecture du CPU et à ce niveau le 68000 est de loin supérieur au 6502 / 65816.
Le 6502 / 65816 nécessite une mémoire qui tourne à la même fréquence que lui alors que le 68000 nécessite une mémoire a une fréquence 4 fois moindre. Sur SNES la mémoire centrale tourne à 2.68 Mhz, ce qui limite le 65816 à... 2.68 Mhz. Avec la même mémoire on aurait pu avoir un 68000 (ou plutot 68008 car le BUS de la SNES est 8 bits) qui tourne à 10 Mhz et à cette fréquence le 68000 est de très loin plus performant que le 65816, voilà pourquoi les 6502 et dérivés c'est des CPU de merdes (ce n'est pas pour rien que ce sont les cpu les moins cher du marché), même le Z80 que je trouve vraiment pas terrible a une meilleur efficacité que le 6502... La fréquence interne du CPU on s'en fout un peu au final, ce qui est important c'est de voir la fréquence mémoire (d'ailleurs dans les datasheets les instructions sont souvent exprimées en cycle BUS) et dans ce cas, on a un 65816 à 2.68 Mhz d'un côté contre un 68000 à 1.92 Mhz de l'autre. Et c'est là que tu te rends compte de l'inefficacité du 65816.

Il y a un post interessant sur ce sujet chez smwcentral (tu pourras pas me taxer de tirer mes sources depuis des sites pro sega) :
On y trouve un certain dragonboy qui pense s'y connaitre mais en fait pas vraiment et smkdan un gars qui s'y connait vraiment et qui tente de lui expliquer la vie (ça me rappelle quelque chose   )

http://www.smwcentral.net/?p=viewthread&t=14402

Mais le pire c'est que ce n'est là qu'un partie du problème, le 65816 a bien d'autre tares comme son bus de données 8 bits, son système d'accès mémoire par banque, son instruction set hyper limité... bref avec le 65816 tu reviens au niveau des CPU 8 bits (et pas les meilleurs :p)

Et pour les perfs compares juste l'affichage d'un mac avec un 68000 avec l'apple 2GS et son 65816 @2,68 mhz
....
Et bien si tu te renseigne, tu pourras y lire que le 2GS avec un 65816 @2,68 mhz affichait bien plus vite une image couleur qu'un mac avec un 68000 @8mhz une image monochrome .

oui oui, et la marmotte...
Le système graphique des 2 machines n'a surement rien à voir, pas la même résolution, pas le même mapping mémoire. Un 68000 à 8 Mhz, ça défonce complètement un 65816 @2.68 Mhz, y'a même pas à discuter.

Une foi de plus ça montre que tu ne cherches pas d'infos plus loin que wiki, va sur le site nesdev dans la partie snes, tu verra que le CPU n'y est pour rien, et qu'il est même assez rapide  Wink

Oui oui (encore une fois) A part les fanboys Nintendo qui n'y connaissent rien je ne vois pas où tu as lu ça. Ceux qui s'y connaissent bien (et particulièrement Byuu, le gars qui a écrit Higan) ont plutot tendance à dire qu'il est bien pourrave comme il faut :p

Faut admettre que je ne comprendrais jamais ton entêtement sur ce point, c'est peut être là ta limite... mais c'est bête car pour moi ça décrédibilise absolument tout ce que tu peux dire à côté. Je pense que c'est lié au fait que ta console fétiche (la PCE) partage un CPU similaire. Mais cette machine reste une bizarrerie, le cpu tourne "anormalement" vite comme j'ai pu le lire sur un autre forum    Ce qui le rendait correct en terme de performance (mais toujours aussi chiant à programmer).

[dlfrsilver]

Et non les jeux manquaient pas de pattern d'anim dans les sprites pour les raisons que tu donnes.

Oh que si, l'amiga ne disposant pas de cartouche, tout est plus ou moins en chip /RAM, donc si tu as une bonne zique de qualité 80/100 ko (voire plus) + 50/60 ko pour les sons il te reste pas bcp de place pour les graphismes, sans oublier que l'amiga n'a pas de flip hard H/V sur les sprites (obligé d'utiliser le blitter surement,donc des cycles DMA), ni d'affichage en tile ..
Regardes lion hart, beau jeu, mais animations de sprites moisies car peu décomposée, et donc très rigide .
Et c'est le cas de bcp de jeux amiga .

Je connais plusieurs personnes (personnellement) qui ont développé des jeux pour amiga. Ils mettaient en priorité un maximum de graphismes en RAM, optimisaient autant que possible le code, et après on demandait au programmeur de garder de la place (un peu) en RAM. Final fight sur amiga fait du flip H/V en temps réel, et ça ne ralenti pas le jeu :) L'affichage en tile, l'amiga gère très bien avec de bonnes routines (grâce au blitter).

Et là encore non, désolé de te reprendre, mais Lionheart est tout sauf l'exemple à prendre pour dire que l'animation des sprites est moisie : 1) c'est une insulte à l'égard du meilleur graphiste 2D européen 2) Tu n'as pas en main les sprites sheet originales du jeu, donc comment tu peux affirmer ça sans avoir les dits fichiers en question ? Moi je les ai et même mieux, j'ai le code source du jeu Lionheart (un jeu 16 bits de 3ème génération) avec tout les graphismes dans leur forme originale, et le sprite principal de Lionheart dispose (comme à l'habitude avec Henk nieborg) d'une tétrachiée de pattern d'animation. Maintenant, je suis d'accord sur le fait que nombre de jeux sont des adaptations pourries et baclées venant du ST. (dernièrement j'ai mis la main dans le code du jeu black tiger sur amiga que j'ai ressourcé, c'est un portage en mode gros porc venant du ST, aucun accès blitter, copper, rien, que des routines pilotées par le 68000, et on voit la lenteur horrible du jeu). Les conversions venant du ST sur amiga, utilisent un nombre d'animation totalement pitoyable, genre pas plus de 12 pattern d'anim pour le personnage principal dans un bon nombre de jeu.

Les développeurs disaient qu'ils auraient sinon développé pour la mégadrive, plus simple, avec un processeur plus rapide, et tout un paquet de sprites hardware. Il est aussi possible via des astuces de programmation ne nécessitant pas de se péter la nuque au passage d'atteindre plus de 90 couleurs à l'écran sur cette dernière.

J'aimerai bien voir ça !!! 

C'est pas du j'aimerais voir ça, MegaTurrican sur megadrive affiche sans souci 87 couleurs à l'écran sur le niveau 1. 

Le 68000 de la megadrive permet un code propre, simple, concis (les japonais sont d'ailleurs ou étaient du moins des cadors de folie en langage ASM 68000), sans parler d'un fait tout bête : les consoles fonctionnent en gros de la même façon que les machines d'arcade, avec un processeur principal qui n'arrête pas de recharger des données dans les registres du processeur d'affichage vidéo dédié. 

Non, les borne fonctionne comme la NG CAD que les graphs sont directement accessibles par la puce graphique dans la rom, comme la NG .

Oui, le 68000 sert à charger les tiledata dans la puce graphique, et s'occupe de la logique interne du jeu.

Sur console les puces graphiques disposent de VRAM pour travailler, et il faut transférer les graphs de la rom -> VRAM, c'est bcp moins puissant, mais bcp moins coûteux aussi .

C'est comme ça que fonctionne le CPS-1, avec ses 192ko de VRAM (et ces cartes coutaient très cher).

Sur les bornes d'arcade le CPU sert pas à grand chose, contrairement aux consoles, et plus tu as de fonctions cablées, moins tu as besoin d'un CPU puissant .

C'est faux. J'ai désassemblé je ne sais pas combien de code programme de jeux CPS-1 protégés par pile afin de créer des sets sans pile (en mode dit d'usine sur CPS-B-21).

(Et faut voir les protections que les ingés de capcom ont mis dans leur code, les pire protections sur amiga, c'est du flan ! Protection style copylock hardware, vérification de la puce PPU via son registre d'identification, vérification du mot sur 16 bits d'activation des layers qui change sur tout les jeux, et qui doit être envoyé 60 fois par seconde au PPU sinon l'affichage dégage avec un bel écran noir, etc etc.....)

Et non là encore je suis pas d'accord avec toi. Le 68000 sur CPS-1 gère la logique interne du jeu, et balance sans arret les tiledatas en direction de la puce CPS-1-A, dont le rôle est de permettre l'utilisation au code programme de fonctions matérielles non graphiques (exemple : effectuer des rotations hardware sur le personnage de Damnd de Final Fight, ahaha qui aurait cru ?). Le CPS-1-B lui permet l'utilisation de fonctions hardware mais sur les graphismes (scrolling, clipping des sprites en position X/Y).

Le CPS-1 est un moteur d'animation hardware, pour lequel, au vu de toutes les fonctions à gérer, et vu la quantité de données à envoyer, les 10mhz du 68000 des cartes CPS-1 c'est pas de trop.

J'ai découvert tout ça en bossant sur un portage de final fight pour amiga AGA, je rippe directement les tiles via mame avec la bonne palette pour un perso donné, et je recompose les patterns exactes des sprites à l'aide des tiledata qui sont présentes dans le code programme 68000 du jeu. Donc tu vois, si tu veux de l'info sur le CPS-1 demande, j'ai des infos sur le sujet :)

Quand je pense que sur NG avec un 68000 @12mhz qui fait pas grand chose il a fallut rajouter une puce dans la cartouche des jeux de la NG-DEV team pour calculer les collisions, ça montre bien l'efficacité de ce CPU .

là encore je suis pas d'accord. J'ai découvert le code source du jeu Art of Fighting pour neogeo dans l'archive d'un PC Nec-9821 (la bécane de développement de la neogeo chez SNK!), sur lequel le programmeur bossait sur la version arcade PC-engine CDROM. Il avait à dispo le code source d'AOF pour le convertir ligne par ligne pour le CPU de la PC-engine CDROM.

Le code Source d'AOF est un mélange d'assembleur (le gros du code) et d'un peu de code C pour les conneries par importantes. le 68000 gère l'activation des musiques et sons via pilote du z80, les tiledatas, la logique interne du jeu, l'affichage des textes, etc, etc.

Donc là encore, comment tu peux dire que le 68000 sert à rien ? Télécharge le code source d'AOF, et regarde comment c'est fait dedans, ça t'éclaircira les idées

La snes affiche déjà pas 256 couleurs entières à l'écran

Le snes a 2/3 modes 256 couleurs, mais je me souvient plus lesquels .
Le mode 7 c'est sur .
Et tu crois quoi que la Md affiche 64 couleurs ???
Non elle peut (sans H/S) afficher que 61 couleurs .
Donc même si 120/150 était un chiffre exact, je préfère toujours ça à 61 couleurs .. 
Le H/S permet de tourner entre 56 et 70 couleurs max in game .

J'ai fais des vérifs, en dehors de donkey kong, et encore uniquement sur écran fixe, aucun jeu n'affiche 256 couleurs. Par contre, et ça je l'ai vérifié aussi, MegaTurrican affiche 87 couleurs à l'écran soit 23 de plus que la normale. Donc ton histoire de H/S avec 70 couleurs max in game, c'est faux.

L'amiga, du moment qu'on lui sert de la musique sur 4 voix, faut savoir qu'il n'y a aucune charge processeur sur le 68000, du 0% quoi

Comme la snes, elle à un CPU dédié aux samples, ou comme la Md et son Z80 pour la partie FM ..

Sauf que la SNES, elle a des soucis de charge côté sample, pas l'amiga.

Après je passe le système de rotation de la console qui est buggé (si tu veux savoir pourquoi, demande-moi  ).

Réellement non, sans façon, dsl 

Le programmeur de Brian the lion a fait des tests sur une SNES pour voir les rotations. Figure toi que l'amiga fait les rotations en hard via le copper mieux que la SNES justement LOL. Fact !

Peu importe pour rendering ranger, le programmeur est limité par la vitesse du processeur principal, et il doit faire avec.

Un conseil, lances toi dans le dev sur machines 8/16 bit, tu comprendras mieux .
La fréquence ne veux pas dire grand choses, tu t'ai jamais demandé pk capcom ou konami avaient de superbes jeux d'arcade, et faisaient des jeux consoles souvent mal programmés ??

J'ai déjà hacké/désassemblé presque tous les code programmes des cartes CPS-1, et toi ?
Le 68000 fait office de chef d'orchestre. Si il est pas cadencé assez vite, il rame, et si il rame, alors il y aurait ralentissement à l'écran, puisque ces systèmes nécessitent un rechargement permanent des registres pour les animations, les scrollings et j'en passe. La SNES est bien doté en puces co-pros, mais jamais elles n'ont pu être utilisées à fond les balais (sauf en cas de puces additionnelles dans les cartouches) car le CPU ne pouvait pas suivre. Tout les chargement de fonctions en directions des co-pros pour afficher les effets à l'écran ont un cout processeur, peut importe la machine. Ensuite pour te répondre : les jeux capcom et konami utilisaient certes des fonctions cablées de partout, mais surtout un processeur principal puissant, pourquoi tu crois que les japonais ont servis le 68000 dans la majorité des cartes ? Parce que c'est le processeur le plus simple à programmer, c'est le processeur de référence sur lequel on demande aux étudiants de bosser en premier !

Non la raison elle est autre, les processeurs des machines (consoles) qu'on avait à la maison étaient sous-calibrées tout simplement, et les ingés faisaient ce qu'ils pouvaient pour convertir le code d'une machine à l'autre. Final fight par exemple, a un code source de 12Mo, pour un code assemblé 68000 de 1Mo. Le gros du programme, c'est les tiledata des sprites, et des décors, et la logique du jeu en soit n'est pas très grosse.

effectivement, comme je disais, Nintendo a bien compris avec l'expérience sa boulette, et rajoutait des puces dans les cartouches, pasque sinon, y a plus d'un jeu qui serait pas sorti sinon. Et comme tu dis, la SNES aurait du avoir un processeur digne de ce nom à sa sortie, et pas dans les cartouches. Petit bras Nintendo sur le coup :)

Non, le CPU d'origine était là juste pour faire baisser les coûts de la console à son lancement, car nintendo savait pertinament que sa console était déjà prévue pour être boostée au besoin, et c'est ce qu'ils on fait, contrairement à SEGA ou même le MCD n'apportait rien de plus à cette pauvre MD,car justement les puces du MCD étaient limitées par l'architecture de la console .. 

Justement, l'architecture de la MD/MCD est beaucoup plus simple que celle de la SNES, y a pas photo, et mieux que ça, avec un CPU très rapide pour charger/décharger le VDP à très grande vitesse.
La SNES il a fallu lui pousser au cul avec des proc ou des co-pros additionnels pour aller plus haut.

Le mac je connais, mais pas l'apple 2GS, donc je peux pas dire.

Et bien si tu te renseigne, tu pourras y lire que le 2GS avec un 65816 @2,68 mhz affichait bien plus vite une image couleur qu'un mac avec un 68000 @8mhz une image monochrome .
Et c'est d'ailleurs pour des raisons commerciales qu'apple à proposé un 2GS si faiblement cadencé .

si tu le dis.....

D'après ce qu'ils en disent oui, franchement la SNES c'était une chiasse à programmer, à toujours faire en sorte de pas étrangler le CPU principal. 

Une foi de plus ça montre que tu ne cherches pas d'infos plus loin que wiki, va sur le site nesdev dans la partie snes, tu verra que le CPU n'y est pour rien, et qu'il est même assez rapide   

ah le fanboyisme :)

Le 68000 a un mauvais rapport instructions / cycle, et n'est surement pas le meilleurs CPU pour une console 16 bit en terme d'efficacité. Ses avantages, simple a programmer, code C efficace, très connu, et surtout un adressage 24 bit, très utile pour des roms de grosse capacité avec des timing assez haut et donc moins chères .

Je suis absolument pas d'accord avec toi. Le 68000 a fait ses preuves dans le monde entier, que ce soit dans le militaire ou dans le civil, dans les systèmes embarqués ainsi que les ordinateurs, les consoles dignes de ce nom, et les machines d'arcade.

Un ingénieur peut se tromper, mais surement pas des millions d'entre eux. Le 68000 est un processeur cultissime au même titre que le z80 de zilog.

Les logiciels de qualité fabuleuse parlent pour lui (arcade, X68000, amiga, megadrive, neogeo).

Le 65C816 est globalement peu connu. Il n'a été utilisé que sur peu de machines, et bon non quoi.

[Stef]

Ca serait cool que tu corriges tes quotes dlfrsilver car on n'y comprend rien :p

Mega Turrican utilise le highlight / shadow donc effectivement tu peux dépasser les 64 couleurs assez facilement. Touko se basait sur l'exemple de Vectorman pour les 70 couleurs max, réellement avec le highlight / shadow, si le jeu de base est bien coloré et si tu l'utilises bien tu dois monté plutot à 80/90 couleurs assez facilement... Après si tu considères les effets de transparence sur la SNES, ben là tu pètes le plafond en terme de couleurs (tu dois dépasser le millier assez facilement) Mais bon c'est jute bon pour faire un effet et pas vraiment pour ajouter des nuances de couleurs

[christophe4559]

Et cette vidéo ?

[christophe4559]

[Stef]

Ha bah je pense que c'est la vidéo à laquelle Touko pensait... On voit que Vectorman tourne souvent entre 60 et 70 avec une pointe à 88 couleurs. En même temps ce jeu n'est pas hyper coloré à la base donc on imagine bien qu'un jeu exploitant un peu mieux les palettes pourrait avoir une moyenne de 80 à 90 en dépassant les 100 couleurs par moment

[dlfrsilver]

Franchement c'est n'imp' ! Mega Turrican c'est 87 couleurs en permanence à l'écran, pas un jeu avec des pointes seulement à 88 ! Pffff.....

[Stef]

dlfrsilver> certainement pas, on est loin des 87 couleurs en permanence...
Si encore y'avait du changement de couleurs par raster mais ce n'est pas le cas. Par contre je sais que dans le premier niveau y'a du highlight / shadow (la fumée en transparence, les ombres dans les colonnes) ce qui augmente le nombre de couleurs là où c'est utilisé. Après le nombre de couleurs ne fait pas tout... suffit de voir Vectorman et Flink, Vectorman en affiche plus mais on jugerait que c'est l'inverse.

[dlfrsilver]

j'ai vérifié le nombre de couleurs, histoire de faire la comparaison avec la version amiga de MegaTurrican. Le screenshot non compréssé, affiche 87 couleurs, et c'est comme ça dans tout le niveau (j'ai pris plusieurs écrans un peu plus loin dans le level 1, et le chiffre ne bouge pas.

[Stef]

Si le chiffre ne bouge pas, c'est qu'il y a clairement un soucis !



Nombre de couleurs : 35 ... on est loin des 87 !
J'ai regardé un peu plus loin, on monte à 50, mais bon du coup, les 87 couleurs sur ce jeu.. pas sur qu'on y arrive.

[dlfrsilver]

ça veut juste dire que l'astuce pour afficher plus de couleur est permanente. Quand tu vois toutes les parties de l'écran, c'est juste évident que le jeu utilise une ou des astuces pour afficher plus de couleurs.

[Stef]

T'as surement fait un screen shot avec un émulateur qui t'ajoute un filtre foireux ou je ne sais quoi...

[dlfrsilver]

ah ok, mais oui, sauf que sur ce screen, tout du moins cette partie la du level, au début, y a pas la parallaxe ! Avec la parallaxe + les sprites à l'écran, on a les 87 couleurs.

[dlfrsilver]

EDIT : la chiotte, les 87 couleurs c'était du à un filtre

Sans filtre et en mode brut j'ai 39 couleurs......

[sengoku 2]

Pas de puce spéciale sur les ng dev team à ma connaissance, HP Man m'avait confirmé cela.
Les PCB sont faits maison et les composants viennent de fabricants extérieurs.
Tant mieux pour ces PCB maisons, car ça empêche pour le moment (mais juqu'à quand ?), les conversions de jeu pirate.

Ton screen Stef est du 640*448, je ne sais pas si ça fausse ou pas.

Le screen de ce lien est du png  320*224 ( soit la résolution de la MD ) et ça affiche 47 couleurs.

http://www.emuparadise.me/Sega%20Genesis/Snaps/Mega%20Turrican%20%28E%29.png

[Fellock]

dlfrsilver> certainement pas, on est loin des 87 couleurs en permanence...
Si encore y'avait du changement de couleurs par raster mais ce n'est pas le cas. Par contre je sais que dans le premier niveau y'a du highlight / shadow (la fumée en transparence, les ombres dans les colonnes) ce qui augmente le nombre de couleurs là où c'est utilisé. Après le nombre de couleurs ne fait pas tout... suffit de voir Vectorman et Flink, Vectorman en affiche plus mais on jugerait que c'est l'inverse.

Peut-être que je me trompe, mais j'ai l'impression qu'Ex-Ranza (Ranger X) est le (ou tout du moins un des) jeu(x) MD qui affiche le plus de couleurs. 64 de mémoire.

[Invité]

Hum...
Je pense pas qu' en jouant à sonic, ranger x ou quelques autres jeux on puisse se dire que la megadrive n' affiche que 64 couleurs et que c' est un problème.
C' est surtout la faible palette (si on l' oppose à celle de la snes) qui limite les possibilités.
Il est plus facile d' exprimer plus d' ambiances quand on a 32000 couleurs (en théorie) pour le faire contre 512.
Quand je dessinais sur deluxe paint, sur mon st, je me sentais restreint dans les variantes de telle ou telle nuance.
Avec une plus grande palette, les possibilités de contraste, variation, composition sont plus importante et laissent plus de liberté.
Les jeux megadrive ne sont finalement pas plus ternes (y' a qu' a regardé un ristar ou gunstar heroes), mais il est plus difficile de renouveler des teintes quand on a à la base moins de couleurs.
En 88, c' était énorme -ou suffisant pour modérer.
EN 91-92, ça devient une vraie tare surtout si on compare avec sa rivale.
Mais pour le coup, les derniers jeux megadrive s'en sortent vraiment bien.
Sauf les jeux multi-support qui accusent d'une comparaison forcément moins avantageuse.

[Stef]

Plus que le nombre de couleurs c'est plutot en nombre de palettes dont il faut parler et 4 palettes de 16 couleurs en tout et pour tout, c'est vraiment faible ! Prenons pour exemple Street Fighter 2. Tu as 2 persos différents à l'écran, déjà paf, tu n'as pas le choix, tu es obligé minimum d'y consacrer 1 palette pour chaque, ça te fait 2 palettes de claqué rien que pour les sprites, il t'en reste donc 2 pour le décor et HUD. Bref c'est la merde :-/ Sur SNES, tu as 8 palettes pour les sprites et 8 pour le décor, tu es déjà bien plus à l'aise ! Ca te fait 4 palettes par perso si tu le souhaites et il te reste 8 palettes pour les décors et le HUD. Sur PCE c'est encore mieux, tu as 16 palettes pour les sprites et 16 pour les décors. Là limite c'est dommage car avec son ensemble de 512 teintes c'est du gachi d'avoir autant de palettes (disons que ça apportera que peu de gain). Je pense qu'un bon rapport pour la MD (et la PCE) aurait été 4 + 4 palettes, ça aurait été vraiment bien plus équilibré et je pense que la MD aurait beaucoup moins souffert de la comparaison avec la SNES avec cette configuration. C'est d'autant plus dommage que c'était la configuration prévue à la base mais pour des raisons de cout Sega a fait des coupes sur la CRAM (qui était particulièrement couteuse à l'époque vu le design du VDP de la MD). Cela dit c'était un mauvais calcul, je pense que virer le highlight / shadow pour doubler la CRAM aurait un choix plus judicieux par exemple, même virer toute la retro compatibilité SMS pour passer en 4096 teintes avec 4+4 palettes (puisque le VDP était designé pour ça à la base) aurait été un meilleur choix mais ça je comprends que c'était un choix risqué pour eux (ça aurait pourtant surement couté moins cher).
Je pense que le problème du nombre de teintes est quand même réel mais moins grave que le nombre de palette globalement.

[Stef]

Ton screen Stef est du 640*448, je ne sais pas si ça fausse ou pas.

Le screen de ce lien est du png  320*224 ( soit la résolution de la MD ) et ça affiche 47 couleurs.

http://www.emuparadise.me/Sega%20Genesis/Snaps/Mega%20Turrican%20%28E%29.png

Pour mon screen shot j'ai bien pris garde de n'appliquer aucun filtre donc le nombre de couleurs est réelle, j'ai juste doublé la taille de l'image pour la rendre plus "visible". C'est vrai qu'il n'y a pas d'ennemi affiché sur mon screen shot ce qui explique la différence avec le tien. Enfin le fait est quand même avec 64 couleurs tu peux avoir des beaux résultats mais ça t'oblige vraiment à faire des efforts, et certains jeux où tu pourras difficilement partager les palettes (comme SF2 ou les mortal kombat où les persos changent de couleur) vont toujours poser des problèmes...