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

[Tryphon]

Hmmm va falloir m'expliquer l'histoire de la rotation à 1024°...

Il veut dire que les rotations se font par pas de 1/1024ème de tour (soit 360/1024 degrés), là où, d'après lui, la SNES fait des pas de 1° (ce qui, honnêtement, m'étonnerait, je vois plutôt au pire des 1/256ème de tour, mais c'est au feeling et Kannagi en dira plus).

[Tryphon]

Ah, et sinon Kannagi : bienvenue dans le monde merveilleux des discussions techniques avec dlfrsilver

Tu vas voir, c'est à chaque fois plus fort

[Invité]

Merci de me prévenir , pire que avec toi ?
(Je plaisante ^^ )
Je sens que je vais pas m'ennuyer

Pour les rotation du Mode7 , un peu compliqué à dire vu que c'est une matrice 2x2 (8bits) qui gère les rotations.
Et je pense que oui les japonais avait des game designer dédié , ce qui était assez rare en europe/usa j'ai l'impression, et que c'était quand même une industrie un peu plus grosse au japon (à cette époque).

C'est la console qui a le plus mal vieilli de toutes celles sorties sur le marché.

j'ai montré ça a un jeune (de 14 ans) il a trouvé ça super beau et pas vieux :


Mais j'imagine que c'est super moche et que ça a mal vielli

[dlfrsilver]

Hmmm va falloir m'expliquer l'histoire de la rotation à 1024°...

Il veut dire que les rotations se font par pas de 1/1024ème de tour (soit 360/1024 degrés), là où, d'après lui, la SNES fait des pas de 1° (ce qui, honnêtement, m'étonnerait, je vois plutôt au pire des 1/256ème de tour, mais c'est au feeling et Kannagi en dira plus).

C'est exactement ça. un Amiga, même le 500 peut faire des rotations en "mode7" sur 1/1024ème quand la snes est limité à 360 steps de 1°. 

Les mecs de chez Psygnosis ont découvert ça lors de leurs tests pour Brian the Lion. 

Le pire, c'est qu'ils expliquaient en plus que sur la snes, le mode 7 est buggé et imprécis MDR 

[Tryphon]

Bien pire (j'espérais que tu t'en étais rendu compte )

Sinon si les valeurs de la matrice sont sur 8 bits, c'est de la virgule fixe ? (parce que je suppose que tu codes zoom + rotation avec ta matrice, donc tes coefs sont des matrices du genre :

Code:

k*cos(theta)  -k*sin(theta)
k*sin(theta)  k*cos(theta)

[Urbinou]

Bin... vu que tu fais ta rotation en soft sur l'amiga, je dirais que tu calcules le pas que tu veux en fait.

[Tryphon]

Le pire, c'est qu'ils expliquaient en plus que sur la snes, le mode 7 est buggé et imprécis MDR 

En même temps, un angle de 1°, ça fait environ un pixel de décalage tous les 60 pixels environ. Pour une machine dont la résolution est de 256 pixels (et en plus souvent le zoom est centré donc y'a que 128 pixels à partir du centre), ça fait 4 pixels environ d'erreur, c'est pas la mer à boire...

[Invité]

Bin... vu que tu fais ta rotation en soft sur l'amiga, je dirais que tu calcules le pas que tu veux en fait.

Je suis totalement d'accord !

Je trouve ça comparaison puéril ,si on part sur ça , la NeoGeo c'est de la merde ,vu incable de faire du mode 7

Bien pire (j'espérais que tu t'en étais rendu compte )

Non parce que la formule me semble un peu complexe et que par mes test ça me semblait quand meme un peu plus que 256 (meme si par défaut , on fera du 256 , pour avoir une cohérence avec une table precalculer niveau angle)

mode7 calcul
comme  je ne fais pas faire le calcul de toute les combinaisons possible suivant la formule ,je peux pas te dire combien ça fait niveau angle .
Mais vu que c'est ton domaine

[dlfrsilver]

La résolution ultra-basse, le CPU pourri au rabais mis à la place d'un vrai bon 68000@10mhz comme c'était prévu au départ, le blabla de chez Nintendo à vanter des choses sur cette console absolument inexploitable ! (je développe en dessous).

La console a eu des CPU annexes parce que le CPU de la console est une grosse merde, et même par certains côté, même le chipset était pas suffisant (ajout de puce propriétaire en sus).

Le Chipset tient la route. Le problème c'est le CPU qui est sous calibré ! LE chipset tourne trop vite par rapport au CPU.

Explication : c'est le CPU qui donne l'ordre au chipset d'afficher les sprites. Pendant que le chipset s'occupe des graphismes, le CPU fait 
tourner la logique du jeu. 

Problème : comme le CPU pourri de la SNES est lent, il y a contention ! Le CPU est en fait étranglé car le chipset finit toujours le boulot plus rapidement que lui, résultat il lui rend la main avant qu'il ait le temps de dire ouf !

Blabla le CPU est mauvais .
Ce que tu raconte ,c'est du bullshit vraiment , encore heureux qu'on peut donenr les ordre de rendu des 128 sprites avant que le rendu soit fait

AUCUN jeu de la SNES affiche 256 couleurs en cours de jeu ! La console n'en est pas capable ! 99% des jeux affichent 128 couleurs MAXIMUM !

Oui la SNES est incapable de faire tourner des jeux en 256 couleurs ou plus.

Tu voulais un exemple ? Voilà un bobard de chez Nintendo ! Même SSF2 sur SNES ne dépasse pas 170 couleurs à l'écran, tous plans confondus + les sprites !

Et c'est moi qui connaît rien à la console ah ah ?
Si SSF2 n'affiche pas les 256 couleurs c'est qu'elle n'avait pas besoin peut etre ?
(ce qui est logique un sprite ne prend que 16 couleurs).
Du coup cela se fait comme ceci sur SF2 j'imagine :
128 couleurs de BG + 16 couleursx2 perso + 16 couleurs pour les effets , ça nout fait 165 couleurs (je compte la transparence).
Mais il y'a des jeux qui exploite pas mal les couleurs de la SNES (au hasard Seiken dentetsu3).
Mais au pire en prend les pari , si j'affiche 241 couleurs sur SNES ,je gagne quoi ? :)
(et probablement plus avec de la transparence )

Tu connais pas le fonctionnement de la console. l'effet de parallelisation du traitement des données est merdique sur cette console, puisque le CPU est systématiquement à la traine par rapport au chipset ! (Voir mon explication plus haut).

       
Oui je m'excuse ,je suis un peu un noob quand on parle de programmation sur SNES  
Mais je te confirme que le CPU n'est pas à la traine comparé aux chipset , la SNES a des défauts (je l'admet volontiers) , mais toi tu t'y connais clairement pas , pour savoir les forces et faiblesse de cette machines

Ah oui ? J'ai une SNES et je ne sais combien de cartouches dessus. Les jeux sont raides au possible, il y a un lag au niveau des commandes, toujours à cause de ce putain de CPU à la con. Graphiquement c'est du 50 ou 60 fps suivant le modèle, mais on voit bien que les programmes, qui tournent avec le CPU broutent le gazon !

Les latences entre les manettes/affichage à l'écran n'ont rien n'a voir avec le CPU

Mais c'était une merde, c'est comme si on mettait un Z80 pour piloter le chipset de la sega saturn (je caricature, mais c'est exactement ça dans l'idée). pour un chipset donné, tu as besoin d'un CPU en corrélation, autrement : contention, ralentissements, incapacité à utiliser le chipset à son maximum.

C'est parce que tu ne connais ni ce processeur , ni même coder avec , ça reste un proc correct ,et je le redis ,c'est plus l’architecture global qui pose souci que le proc

Si tu veux une version 100% arcade perfect, seul un X68000 peut répliquer Rygar. Même la SNES peut pas !

quand tu parle du jeu Rygar , tu parle de ça ?
https://www.youtube.com/watch?v=FK_OQIgIPqw

Blabla le CPU est mauvais .
Ce que tu raconte ,c'est du bullshit vraiment , encore heureux qu'on peut donenr les ordre de rendu des 128 sprites avant que le rendu soit fait 

C'est tout sauf du bullshit. C'est pour ça que Nintendo a rajouté des puces annexes (CPU ou 3D supplémentaires) dans les cartouches. 

C'est pas la question de l'ordre de rendu des 128 sprites ! T'as pas compris ce que j'ai dis. J'ai pas dis que la SNES pouvait pas gérer 128 sprites, j'ai dis que le CPU était trop lent par rapport au chipset, qui est bien trop rapide pour lui. 

J'ai lu des articles techniques ou c'était expliqué, et mieux encore des programmeurs professionnels le confirmer. 

Et c'est moi qui connaît rien à la console ah ah ?    
Si SSF2 n'affiche pas les 256 couleurs c'est qu'elle n'avait pas besoin peut etre ?

La console ne peut pas monter à 256 couleurs ou au delà en cours de jeu. ça par exemple, c'est du mytho de chez nintendo. Si tu veux monter à 256 couleurs, ou au delà genre donkey kong qui affiche des images fixes en 382 couleurs, ok. Mais dans un jeu en 50 ou 60 fps tu peux te brosser. 

(ce qui est logique un sprite ne prend que 16 couleurs). Du coup cela se fait comme ceci sur SF2 j'imagine : 128 couleurs de BG + 16 couleursx2 perso + 16 couleurs pour les effets , ça nout fait 165 couleurs (je compte la transparence).

C'est ça grosso merdo effectivement.

Mais il y'a des jeux qui exploite pas mal les couleurs de la SNES (au hasard Seiken dentetsu3).
Mais au pire en prend les pari , si j'affiche 241 couleurs sur SNES ,je gagne quoi ? :)  
(et probablement plus avec de la transparence )  

Y a aucun jeu commercial SNES qui affiche autant de couleurs. On est sur SNES coco, pas sur PC engine ou Neogeo   ! 

Oui je m'excuse ,je suis un peu un noob quand on parle de programmation sur SNES   
Mais je te confirme que le CPU n'est pas à la traine comparé aux chipset , la SNES a des défauts (je l'admet volontiers) , mais toi tu t'y connais clairement pas , pour savoir les forces et faiblesse de cette machines 

T'es le seul à pas le savoir. Les programmeurs japonais haissaient la SNES si tu le sais pas. A leur yeux c'était de la merde. Ils préféraient tous la sega megadrive ! Les studios ne bossaient sur SNES que parce que nintendo arrosaient tout le monde de fric ! 

Et le CPU pourri de la console, les programmeurs de l'époque en parlent ! Certains expliquaient même qu'ils étaient dégoutés de pas avoir pu mettre en place des effets graphiques ou des éléments plus complexes à cause de cette saleté de 65816 ! 

Les latences entre les manettes/affichage à l'écran n'ont rien n'a voir avec le CPU 

Nan mais t'es sérieux ??? Les latences sur n'importe quel machine entre manette et affichage sont du à une contention du CPU sur la logique du programme/jeu ! C'est parce que le CPU est la ramasse que ça ne répond pas aux commandes de façon souple ! 

C'est parce que tu ne connais ni ce processeur , ni même coder avec , ça reste un proc correct ,et je le redis ,c'est plus l’architecture global qui pose souci que le proc 

C'est un proc correct, mais pas sur la SNES. Sur n'importe quelle autre hardware si tu veux, mais pas sur cette console, qui a été castrée pour des raison de budget.

le 65816 ne vaut pas l'ongle d'un 68000, même cadencé à 7mhz ! 

quand tu parle du jeu Rygar , tu parle de ça ? 
https://www.youtube.com/watch?v=FK_OQIgIPqw

Oui ce jeu d'arcade, qui utilise un Z80 pour piloter un chipset 16/32 bits qui est au niveau du chipset du X68000 


Sauf que, Le hardware arcade de Rygar est tellement mieux conçu et agencé que le hardware de la SNES 

[Invité]

C'est la console qui a le plus mal vieilli de toutes celles sorties sur le marché.

j'ai montré ça a un jeune (de 14 ans) il a trouvé ça super beau et pas vieux :


Mais j'imagine que c'est super moche et que ça a mal vielli

je resterais avec ma fille pour voir si elle préfère ma Snes, ma 7800 ou mon intellivision

[dlfrsilver]

Bin... vu que tu fais ta rotation en soft sur l'amiga, je dirais que tu calcules le pas que tu veux en fait.

la rotation est faite en hard. Tu ne peux pas faire de rotation comme celles présentes dans Brian the lion, avec le 68000, c'est impossible à faire.

C'est pour cette raison que Brian the lion est impossible à convertir sur Atari ST (ou STE par extension).

Les effets de rotations de BTL repose entièrement sur le chipset de l'Amiga.

[Invité]

Blabla le CPU est mauvais .
Ce que tu raconte ,c'est du bullshit vraiment , encore heureux qu'on peut donenr les ordre de rendu des 128 sprites avant que le rendu soit fait 

C'est tout sauf du bullshit. C'est pour ça que Nintendo a rajouté des puces annexes (CPU ou 3D supplémentaires) dans les cartouches. 

C'est pas la question de l'ordre de rendu des 128 sprites ! T'as pas compris ce que j'ai dis. J'ai pas dis que la SNES pouvait pas gérer 128 sprites, j'ai dis que le CPU était trop lent par rapport au chipset, qui est bien trop rapide pour lui. 

J'ai lu des articles techniques ou c'était expliqué, et mieux encore des programmeurs professionnels le confirmer. 

Au lieu de blablater ,c'est juste que il y'a une démo qui montre 113 sprites (qui peut monter à 128 sprites ) et c'est un danmaku qui fait du 224 test de collision/frame ,du coup je reste très étonné par ce que tu me raconte là  

La console ne peut pas monter à 256 couleurs ou au delà en cours de jeu. ça par exemple, c'est du mytho de chez nintendo. Si tu veux monter à 256 couleurs, ou au delà genre donkey kong qui affiche des images fixes en 382 couleurs, ok. Mais dans un jeu en 50 ou 60 fps tu peux te brosser. 

   
Non mais arrête ,afficher 256 couleurs sur SNES, ça vaut 0% de cout CPU, il suffit juste de mettre les palettes en VRAM  
Donc dans un jeu même à 60 FPS , ben c'est totalement possible ...

(ce qui est logique un sprite ne prend que 16 couleurs). Du coup cela se fait comme ceci sur SF2 j'imagine : 128 couleurs de BG + 16 couleursx2 perso + 16 couleurs pour les effets , ça nout fait 165 couleurs (je compte la transparence).

C'est ça grosso merdo effectivement.

Donc ce que tu en conclus c'est que c'est impossible ?
Je t'explique par A + B que c'est juste qu'il y'avait plus besoin d'afficher plus , donc forcément moins de palette utilisé.

Y a aucun jeu commercial SNES qui affiche autant de couleurs. On est sur SNES coco, pas sur PC engine ou Neogeo   ! 

Je viens de t'en citer des titres , alors arrête de nier  

Et le CPU pourri de la console, les programmeurs de l'époque en parlent ! Certains expliquaient même qu'ils étaient dégoutés de pas avoir pu mettre en place des effets graphiques ou des éléments plus complexes à cause de cette saleté de 65816 ! 

ou qu'il manquait de temps peut être ?  

Les latences entre les manettes/affichage à l'écran n'ont rien n'a voir avec le CPU 

Nan mais t'es sérieux ??? Les latences sur n'importe quel machine entre manette et affichage sont du à une contention du CPU sur la logique du programme/jeu ! C'est parce que le CPU est la ramasse que ça ne répond pas aux commandes de façon souple ! 

Je suis plus sérieux que toi , la lecture d'un pad ,c'est quoi 50 cycles max ?
c'est plutôt toi qui me semble avoir fumé ^^

le 65816 ne vaut pas l'ongle d'un 68000, même cadencé à 7mhz ! 

Ayant codé sur les deux proc ,c'est plutôt entre 30-40% de plus entre un 65816 et le M68000 (à 7 MHz)

Oui ce jeu d'arcade, qui utilise un Z80 pour piloter un chipset 16/32 bits qui est au niveau du chipset du X68000 

Sauf que, Le hardware arcade de Rygar est tellement mieux conçu et agencé que le hardware de la SNES 

Sans vouloir te casser ton trip , mais ce jeux est largement faisable sur SNES , il est même un jeu qui l'exploiterai pas du tout ,tellement que le jeu est pauvre graphiquement....

[Stef]

@dlfrsilver> Kannagi developpe sur SNES donc à n'en pas douter il l'a connait bien mieux que toi.
Après il a quand même un certain parti pris pour cette console, car objectivement oui le CPU est une purge et indigne du reste de la machine, et je suis certain qu'effectivement les développeurs de l'époque détestaient développer sur SNES pour cette principale raison (mais pas que car d'autres aspects du hardware est assez bancal). Après concernant les détails techniques Kannagi a parfaitement expliqué les choses, il n'y a pas d'histoire de CPU trop lent par rapport au chipset, ça n'a pas de sens de dire ça vu le fonctionnement de la SNES. Par contre je suis assez d'accord sur l'animation assez rigide, le manque de vivacité des jeux SNES en général, et ça oui c'est directement imputable au CPU (et certains défauts du processeur vidéo accentuent le problème). Kannagi va rétorquer qu'il a fait un shump avec plus de 100 sprites sur SNES. Certes mais Kannagi est un obsédé de l'optimisation et avec les mêmes efforts tu iras bien plus loin sur une MD :-p

[Invité]

Certes mais Kannagi est un obsédé de l'optimisation et avec les mêmes efforts tu iras bien plus loin sur une MD :-p

Je suis totalement d'accord
Et la facilité de dev sur MD et un plus j'avoue

[TotOOntHeMooN]

Non non non M'sieur Toto ! Rygar est un jeu d'arcade a processeur 8bits et chipset 16-32bits ! 

Hum... Plus c'est gros, plus ça passe ? Car bon, de souvenir les schémas du système d'arcade montrent que tout est en 8-bit. Après, je ne dis pas que l'électronique dédiée à l'affichage n'est pas performante, mais plutôt que l'Amiga est à la rue à coté. Car contrairement à ce que tu laisses entendre, écidemment qu'une SNES peut faire tourner ce jeu.

[dlfrsilver]

Blabla le CPU est mauvais .
Ce que tu raconte ,c'est du bullshit vraiment , encore heureux qu'on peut donenr les ordre de rendu des 128 sprites avant que le rendu soit fait 

C'est tout sauf du bullshit. C'est pour ça que Nintendo a rajouté des puces annexes (CPU ou 3D supplémentaires) dans les cartouches. 

C'est pas la question de l'ordre de rendu des 128 sprites ! T'as pas compris ce que j'ai dis. J'ai pas dis que la SNES pouvait pas gérer 128 sprites, j'ai dis que le CPU était trop lent par rapport au chipset, qui est bien trop rapide pour lui. 

J'ai lu des articles techniques ou c'était expliqué, et mieux encore des programmeurs professionnels le confirmer. 

Au lieu de blablater ,c'est juste que il y'a une démo qui montre 113 sprites (qui peut monter à 128 sprites ) et c'est un danmaku qui fait du 224 test de collision/frame ,du coup je reste très étonné par ce que tu me raconte là  

La console ne peut pas monter à 256 couleurs ou au delà en cours de jeu. ça par exemple, c'est du mytho de chez nintendo. Si tu veux monter à 256 couleurs, ou au delà genre donkey kong qui affiche des images fixes en 382 couleurs, ok. Mais dans un jeu en 50 ou 60 fps tu peux te brosser. 

   
Non mais arrête ,afficher 256 couleurs sur SNES, ça vaut 0% de cout CPU, il suffit juste de mettre les palettes en VRAM  
Donc dans un jeu même à 60 FPS , ben c'est totalement possible ...

(ce qui est logique un sprite ne prend que 16 couleurs). Du coup cela se fait comme ceci sur SF2 j'imagine : 128 couleurs de BG + 16 couleursx2 perso + 16 couleurs pour les effets , ça nout fait 165 couleurs (je compte la transparence).

C'est ça grosso merdo effectivement.

Donc ce que tu en conclus c'est que c'est impossible ?
Je t'explique par A + B que c'est juste qu'il y'avait plus besoin d'afficher plus , donc forcément moins de palette utilisé.

Y a aucun jeu commercial SNES qui affiche autant de couleurs. On est sur SNES coco, pas sur PC engine ou Neogeo   ! 

Je viens de t'en citer des titres , alors arrête de nier  

Et le CPU pourri de la console, les programmeurs de l'époque en parlent ! Certains expliquaient même qu'ils étaient dégoutés de pas avoir pu mettre en place des effets graphiques ou des éléments plus complexes à cause de cette saleté de 65816 ! 

ou qu'il manquait de temps peut être ?  

Les latences entre les manettes/affichage à l'écran n'ont rien n'a voir avec le CPU 

Nan mais t'es sérieux ??? Les latences sur n'importe quel machine entre manette et affichage sont du à une contention du CPU sur la logique du programme/jeu ! C'est parce que le CPU est la ramasse que ça ne répond pas aux commandes de façon souple ! 

Je suis plus sérieux que toi , la lecture d'un pad ,c'est quoi 50 cycles max ?
c'est plutôt toi qui me semble avoir fumé ^^

le 65816 ne vaut pas l'ongle d'un 68000, même cadencé à 7mhz ! 

Ayant codé sur les deux proc ,c'est plutôt entre 30-40% de plus entre un 65816 et le M68000 (à 7 MHz)

Oui ce jeu d'arcade, qui utilise un Z80 pour piloter un chipset 16/32 bits qui est au niveau du chipset du X68000 

Sauf que, Le hardware arcade de Rygar est tellement mieux conçu et agencé que le hardware de la SNES 

Sans vouloir te casser ton trip , mais ce jeux est largement faisable sur SNES , il est même un jeu qui l'exploiterai pas du tout ,tellement que le jeu est pauvre graphiquement....

Au lieu de blablater ,c'est juste que il y'a une démo qui montre 113 sprites (qui peut monter à 128 sprites ) et c'est un danmaku qui fait du 224 test de bullet/frame ,du coup je reste tres étonné par ce que tu me raconte là 

'tain j'ai l'impression de lire les totos du ST qui viennent nous bassiner vis à vis de l'amiga : 

"nan mais tu comprends y a une démo qui fait mieux que Beast là mvoyez" 

N'importe quel programmeur de renom te dirait qu'une démo c'est pas un jeu, un jeu c'est bien plus compliqué à faire tourner et à mettre en oeuvre ! 

Les programmeurs pro de l'époque ont poussé la SNES au maximum, et clairement son CPU est son plus gros point faible.

[TotOOntHeMooN]

Je me demande si c'était pas aussi surtout un problème financier. Parce qu'un game designer ou un testeur, c'est pas forcément un codeur, un graphiste ou un musicien. Ça fait du monde en plus dans l'équipe

Au Japon, le jeu vidéo était une histoire d'industrie et de procédures créatives quand c'était encore une "curiosité" pour boutonneux par chez nous. Très tôt, tu vois apparaitre des game designer aux crédits de jeux 8-bit alors qu'il faudra attendre bien 10/15 ans de plus pour que cela soit pris au sérieux ici. Ooui c'est un coût, mais en même temps ça se vend plus quand la qualité est au rendez-vous.

[dlfrsilver]

Non non non M'sieur Toto ! Rygar est un jeu d'arcade a processeur 8bits et chipset 16-32bits ! 

Hum... Plus c'est gros, plus ça passe ? Car bon, de souvenir les schémas du système d'arcade montrent que tout est en 8-bit. Après, je ne dis pas que l'électronique dédiée à l'affichage n'est pas performante, mais plutôt que l'Amiga est à la rue à coté. Car contrairement à ce que tu laisses entendre, écidemment qu'une SNES peut faire tourner ce jeu.

Les spécifications précises de l'arcade sont fournies dans un fichier txt sur la disquette originale de Rygar sur X68000.

C'est la partie sonore qui est full 8 bits.

Je te garanti que ce hardware va même au delà de ce qu'une super nes peut faire. que ce soit en animations ou affichage de couleurs. 

L'amiga 500 est hors course sur un jeu comme rygar. Trop de couleurs, trop de sprites. 

Le jeu utilise 2mo de ram sur X68000 (malgré l'aide côté sprites hardware, tiles et autres qui font économiser de la RAM).

[Invité]

Non mais tu comprend rien ,c'est ça la nuance
Il y'a des jeux SNES qui exploite lle CPU de la machine super aleste ça te dit quelque chose ?
Oui la démo c'est nul , elle pourra pas tourner en vrai dans un jeu , on en reparlera  

N'importe quel programmeur de renom te dirait qu'une démo c'est pas un jeu, un jeu c'est bien plus compliqué à faire tourner et à mettre en oeuvre !

c'est vrai ça dépend de la démo surtout , si c'est un démo qui refait un jeu in game ,c'est un poil plus crédible ,je dis ça je dis rien

Les programmeurs pro de l'époque ont poussé la SNES au maximum, et clairement son CPU est son plus gros point faible.

Et moi je te dis ,son plus gros point faible ,ce trouve sur le hardware qui  obligeait au CPU de faire plus qu'il ne devait pour le gerer correctement , mais rien ne l’empêche d’exploiter a machine , les gros titre de la SNES c'est pas ce qui manque et exploitait la machine , après si t'as joué que à ultraman sur SNES ,je comprend mieux

[dlfrsilver]

Non mais tu comprend rien ,c'est ça la nuance
Il y'a des jeux SNES qui exploite lle CPu de la machine super aleste ça te dit quelque chose ?
Oui la démo c'est nul , elle pourra pas tourner en vrai dans un jeu , on en reparlera  

N'importe quel programmeur de renom te dirait qu'une démo c'est pas un jeu, un jeu c'est bien plus compliqué à faire tourner et à mettre en oeuvre !

c'est vrai ça dépend de la démo surtout , si c'est un démo qui refait un jeu in game ,c'est un poil plus crédible ,je dis ça je dis rien

Les programmeurs pro de l'époque ont poussé la SNES au maximum, et clairement son CPU est son plus gros point faible.

Et moi je te dis ,son plus gros point faible ,ce trouve sur le hardware qui  obligeait au CPU de faire plus qu'il ne devait pour le gerer correctement , mais rien ne l’empêche d’exploiter a machine , les gros titre de la SNES c'est pas ce qui manque et exploitait la machine , après si t'as joué que à ultraman sur SNES ,je comprend mieux

j'ai super Aleste dans ma collec SNES. C'est pas mon préféré.

PS : j'ai pas ultraman sur ma SNES, mais y parait que c'est un des meilleurs titres de la console 

[Invité]

[
PS : j'ai pas ultraman sur ma SNES, mais y parait que c'est un des meilleurs titres de la console 

n'hésite pas à l'acheter ,je pense qu'il vaut Rygar en terme de perf

[dlfrsilver]

[
PS : j'ai pas ultraman sur ma SNES, mais y parait que c'est un des meilleurs titres de la console 

n'hésite pas à l'acheter ,je pense qu'il vaut Rygar en terme de perf

Le hardware de Rygar est supérieur à celui de la SNES, are you aware ? 

[Invité]

Le hardware de Rygar est supérieur à celui de la SNES, are you aware ? 

Je regarde le code source de MAME voilà ce que ça dit :
Rygar à une ROM de 50ko
Une RAM de 4ko
une VRAM de 8ko
-2 BG hardware
-2 CPU un de  Z80 un de 6MHz (0,87 MIPS) et un (qui semble pour être le proc sonore )Z80 à 4 MHz (0,580 MIPS)
Pour les sprites/limite line faudrait que je lise le driver video pour ça  

C'est plus puissant qu'une SNES vraiment
la SNES :
-une ROM entre 512 ko et 2Mo (certain jeux montait à 6Mo)
-RAM de 128ko
-VRAM de 64ko
-3 BG
- 65816 à 2,67 Mhz ( 1 MIPS) et un SPC700 (0,4 MIPS)
ah et pour faire des calculs 16 bits sur un Z80 , ça réduit ces perf par deux , précisions importante je pense  

[Tryphon]

Non parce que la formule me semble un peu complexe et que par mes test ça me semblait quand meme un peu plus que 256 (meme si par défaut , on fera du 256 , pour avoir une cohérence avec une table precalculer niveau angle)

mode7 calcul
comme  je ne fais pas faire le calcul de toute les combinaisons possible suivant la formule ,je peux pas te dire combien ça fait niveau angle .
Mais vu que c'est ton domaine

Arf, désolé, ton image n'est pas lisible

[TotOOntHeMooN]

L'argument des 3 BG sur SNES est, je pense, dispensable. 
Le soucis c'est de vouloir comparer l'Amiga à autre chose que le ST ici, seule configuration où il est gagnant. 

[Invité]

Je suis d'accord que le 3eme BG est dispensable , mais ça évite de "rogner" un peu un BG (voir les deux) pour faire un HUD , comme dans Rygar ou quelque jeux MD.

Pour tryphon

[Tryphon]

Ok, merci, mais je pense que ça répond pas à ma question (précision des 4 nombres qui définissent la matrice). Mais t'embêtes pas, je chercherai

(1024x1024, c'est la taille du plan ?)

[Invité]

Les 4 nombres sont bien en 8 bits îl me semble.

(oui , sur MD c'est je crois 512x512 il me semble , pareil sur SNES , sauf en mode 7 ou cela prend plus (et donc prend la moitié de la VRAM avec la texture 128x128).

[drfloyd]

Le hardware de Rygar est supérieur à celui de la SNES, are you aware ? 

Je regarde le code source de MAME voilà ce que ça dit :
Rygar à une ROM de 50ko
Une RAM de 4ko
une VRAM de 8ko
-2 BG hardware
-2 CPU un de  Z80 un de 6MHz (0,87 MIPS) et un (qui semble pour être le proc sonore )Z80 à 4 MHz (0,580 MIPS)
Pour les sprites/limite line faudrait que je lise le driver video pour ça  

C'est plus puissant qu'une SNES vraiment
la SNES :
-une ROM entre 512 ko et 2Mo (certain jeux montait à 6Mo)
-RAM de 128ko
-VRAM de 64ko
-3 BG
- 65816 à 2,67 Mhz ( 1 MIPS) et un SPC700 (0,4 MIPS)
ah et pour faire des calculs 16 bits sur un Z80 , ça réduit ces perf par deux , précisions importante je pense  

le hardware des bornes d'arcade Jap était autrement mieux exploité que celui des consoles et micro...

[upsilandre]

Même une SNES qui affiche à peine 170 couleurs dans les jeux les plus colorés ne pourrait pas afficher les 1024 couleurs du jeu !

Je te met au défi de trouver une image de Rygar avec disons... 150 couleurs, je suis gentil.  

Le hardware de Rygar est supérieur à celui de la SNES, are you aware ? 

Je regarde le code source de MAME voilà ce que ça dit :
Rygar à une ROM de 50ko
Une RAM de 4ko
une VRAM de 8ko
-2 BG hardware
-2 CPU un de  Z80 un de 6MHz (0,87 MIPS) et un (qui semble pour être le proc sonore )Z80 à 4 MHz (0,580 MIPS)
Pour les sprites/limite line faudrait que je lise le driver video pour ça  

Nan les gars faut pas exagéré, tu fais pas un jeu comme Rygar avec 50Ko, vous êtes fous
La ROM fait 520Ko (qui sert donc aussi de VRAM)

[Tryphon]

Les 4 nombres sont bien en 8 bits îl me semble.

Oui mais c'est pas des entiers, et je suppose que tu peux multiplier la matrice par un facteur pour un zoom, donc il faut réellement avoir des nombres avec une partie entière et une partie décimale. Du coup ça m'intéresse de savoir s'ils sont en virgule fixe ou flottante (à moins que le facteur de zoom soit codé séparément, mais je doute parce que ça n'aurait pas trop de sens de préciser alors les 4 entrées de la matrice).

(oui , sur MD c'est je crois 512x512 il me semble , pareil sur SNES , sauf en mode 7 ou cela prend plus (et donc prend la moitié de la VRAM avec la texture 128x128).

Mais du coup t'as qu'un plan ?

(sur MD tu peux faire n'importe quelle taille de 256 à 1024 pixels sur les 2 coords, tant que ça dépasse pas 8 ko au total, donc tu peux faire du 1024x256, du 512x512, mais pas du 1024x1024) (de mémoire, pour Shinobi c'est du 512x256 il me semble).