Necstasy

@Cazeysan

Hacks software de type Demon's Blazon, qui suppriment quelques sprites ou simplifient certaines animations pour réduire les ralentissements.

cazeysan a écrit : ↑lun. 06 févr. 2023 16:11 Tu parles des hacks qui utilisent la puce additionnelle destinée à l'origine pour du son ? Genre le Super R-Type ou le Gradius 3 ?

Non, de ceux qui justement passent la ROM en fastrom et/ou corrige du code, comme par exemple pour super ghouls'n ghost ou gradius 3 (même si le hack SA-1 existe aussi,il est arrivé après).

kawickboy a écrit : ↑lun. 06 févr. 2023 16:15Tous ces éditeurs qui avaient brillé sur Nes ont eu bien du mal sur SNES je trouve : Irem, Sunsoft, Taito, même Konami dans une moindre mesure.

Tellement vrai !
Seul Capcom s'en sort avec les honneurs.
À croire que Nintendo fait tout pour qu'on ne se souvienne que des jeux Nintendo sur les consoles Nintendo...

kawickboy a écrit : ↑lun. 06 févr. 2023 16:15 R2 est sorti 5 ans après la sortie de la console. Et Trenz est celui qui avait poussé le C64 très loin. Tous ces éditeurs qui avaient brillé sur Nes ont eu bien du mal sur SNES je trouve : Irem, Sunsoft, Taito, même Konami dans une moindre mesure.

Oui mais pas à cause du CPU, mais bien du hard de la console, qui est mal gaulé et force à puisser justement dans le CPU (qui devient limite du coup) pour compenser .
Par exemple dans le BTU batman returns, tu as plus de 100 sprites affichés pour avoir 3/4 persos à l'écran, du gros n'importe quoi en terme de ressources .

En même temps, un 6502 à 2 MHz en mode slow (fréquent sur SFC), ça ne fait pas de miracle.

C'est 2,58 en slow, les rataillons ça compte lol .
Normalement avec une console au design propre ça aurait suffit, sans faire plus que ce que le hard propose ni extra .
La nes a bien des shoots nerveux avec 1.79mhz,et le 65816 est bien plus performant que le simple 6502.
Rien qu'avec ce qu'a fait hudson pour le hu6280, nintendo aurait pu doubler la fréquence CPU sans toucher à la ROM/RAM et avoir un CPU à 5mhz en slow,le 1/2 cycle d'accès ne sert strictement à rien dans une console,et soulage les accès .

C'est rare de pouvoir lire des critiques de la SNES. Faut dire que depuis la sortie de la Wii et la réécriture de l'histoire du jeu vidéo elle et la NES disposaient d'un sacré totem d'immunité.
Et puis on voit bien que si la NES dispose d'un bon panel de sorties homebrew, la SNES c'est extrêmement pauvre, moins que sur Jaguar. Donc il doit y avoir une raison, notamment que l'architecture n'était peut-être pas aussi fabuleuse, n'en déplaise au mode 7.
Ou alors quelqu'un trouve le moyen de faire des cartouches vierges avec puce dsp intégrée.

C'est tout de même hallucinant cette espèce de revanche que la MD est en train de prendre dans sa vie post-commerciale.

J'y connais pas grand chose en hard mais déjà à l'époque je me disais que la md était quand même sacrement bien conçue pour proposer des jeux aussi avancés techniquement que ceux des années 93-94-95 sans puce additionnelle ou accessoire.

Comme quoi, la qualité d'une entreprise, ce n'est pas simplement de concevoir la meilleure console, et ça Nintendo l'a compris depuis très longtemps

Peut-être le symptôme le plus flagrant sur SNES, c'est l'absence totale de scène chiptune (contrairement à la NES, la MD ou même la PCE).

Le processeur audio SPC700 (de Sony, au passage) a eut pendant longtemps une réputation surdimensionnée, mais c'est quasi l'équivalent d'une toute petite soundfont de type General MIDI, qui ne pouvait rivaliser ni avec l'Amiga ni avec le Roland MT-32. Aujourd'hui, faire un chiptune Super Famicom reviendrait à composer un module ScreamTracker 8 voies, avec des samples minuscules qui doivent tenir dans une RAM audio de 64 Ko. La demoscene est déjà passée par là un milliard de fois sur d'autres bécanes, rien de neuf sous le soleil qui permettrait à la SNES de se démarquer.

Le "son" de la SNES, c'est surtout son générateur de reverb, caractéristique de toutes les productions Square, Enix et les autres. Un reverb que beaucoup de gens préfèrent aujourd'hui désactiver en émulation quand ils écoutent des musiques SPC

cazeysan a écrit : ↑mer. 08 févr. 2023 18:43 Comme quoi, la qualité d'une entreprise, ce n'est pas simplement de concevoir la meilleure console, et ça Nintendo l'a compris depuis très longtemps

Non clairement, la snes est bien sur certains points il y a pas photo, par contre une grosse cata sur d'autres et notamment les sprites hard, un comble qd même pour une machine basée sur les sprites .

J'y connais pas grand chose en hard mais déjà à l'époque je me disais que la md était quand même sacrement bien conçue pour proposer des jeux aussi avancés techniquement que ceux des années 93-94-95 sans puce additionnelle ou accessoire.

La MD hormis la partie couleurs et FM (perso), est une machine équilibrée, ses faiblesses n'impactent pas ou peu l'expèrience de jeu .
Nintendo a toujours été connu depuis la nes pour faire un max de cheapos pour vendre son matos le moins cher possible, quitte à foutre des add-ons par la suite, cela à super bien marché avec la nes, ils ont juste poussé le truc plus loin avec la snes, enfin surtout niveau CPU .
Pour moi nintendo savait dés le départ que mettre une puce par la suite pour aider le CPU, coûterait bien moins cher que de faire un add-on à la con style MCD .
On peu critiquer, mais on sait quelle stratégie a été payante .Le PCE est encore mieux conçue que la MD, mais elle a un manque sur les petits plus qui caractérisent la gen 16 bits, du fait de son positionnement .

Le "son" de la SNES, c'est surtout son générateur de reverb, caractéristique de toutes les productions Square, Enix et les autres. Un reverb que beaucoup de gens préfèrent aujourd'hui désactiver en émulation quand ils écoutent des musiques SPC

La Puce audio de la snes est sans conteste la plus puissante de cette gen, mais comme pas mal de choses intéressantes dans cette console, largement castrée par les 64ko d'audio RAM, le pire c'est que la partie audio n'a même pas un accès direct à la ROM, il faut passer par un système lourd et lent pour transférer les samples dans la mémoire .La MD elle a d'autres soucis pour les samples, et c'est clairement pas la panacée non plus,les contraintes sont différentes, mais avoir des samples de qualité est très difficile .

C'est rare de pouvoir lire des critiques de la SNES. Faut dire que depuis la sortie de la Wii et la réécriture de l'histoire du jeu vidéo elle et la NES disposaient d'un sacré totem d'immunité.

Aucune des 3 n'est parfaites, elles ont chacune leurs défauts et leurs avantages, c'est justement ce qui fait que l'on peut faire des jeux uniques sur chacun de ces 3 systèmes, impossibles à faire sur les autres sans concessions .Et c'est facile de trouver des défaut dans un jeu comme RR ou TF3 par exemple .Mais est ce les défauts qui comptent ou le plaisir d'y jouer ?

touko a écrit : ↑jeu. 09 févr. 2023 09:23[...]Aucune des 3 n'est parfaites, elles ont chacune leurs défauts et leurs avantages, c'est justement ce qui fait que l'on peut faire des jeux uniques sur chacun de ces 3 systèmes, impossibles à faire sur les autres sans concessions .Et c'est facile de trouver des défaut dans un jeu comme RR ou TF3 par exemple .Mais est ce les défauts qui comptent ou le plaisir d'y jouer ?

Amen

Ça fait très longtemps que j'ai pas codé, à part une petite démo sur unity pour montrer à mon fils comment on faisait un jeu. Je fais des jeux avec lui sur GBStudio, plus simple pour lui.
Mais ça me dit bien d'essayer de m'initier au code PC engine ou SGX si je trouve un peu de temps. C'est une activité sympa à faire avec mon fils qui est passionné du sujet.

J'ai beaucoup codé en C/C++ mais la dernière fois que j'ai fait de l'assembleur c'était pour du retro-engineering pour remplacement par un FPGA...ça devait être en 2002

Vous conseilleriez de commencer par quoi?

Le problème du développement PCE est qu'il n' y a pas de porte d'entrée idéale... Les outils sont anciens (plus de 20 ans), la doc est spartiate et chaque codeur doit réinventer la roue dans son coin. Pour un néophyte comme moi, c'est un énorme challenge, que ce soit en assembleur ou en C.

Oublie Unity et compagnie, la PC Engine n'a pas de kit de dev à proprement parler. L'Amiga dispose de Scorpion, le Spectrum de Nirvana... Sur PCE, il y a Magic Kit pour l'assembleur 6502 et HuC pour le C. Ce sont simplement des compilos avec quelques macros graphiques préprogrammées (très utiles mais souvent incomplètes ou expérimentales).

Un point intéressant est que HuC avait été pensé comme une sorte de "version C" de Magic Kit. Les macros sont donc très similaires, avec la syntaxe évidemment propre à chaque langage. J'ai commencé en assembleur avec Magic Kit, et le passage à HuC s'est fait dans une certaine continuité.

Si tu as déjà codé en C, je pense que HuC 4 ne devrait pas te poser de gros problème. Il va quand même falloir te familiariser avec les fonctions PCE, et la vieille doc de Magic Kit (incluse dans HuC) peut rendre service à ce niveau.

Merci beaucoup pour le retour.
J'ai parcouru les discussions sur le sujet sur le forum. Je me familiarise avec les concepts.
J'ai bien compris que la PCengine était pauvre en outils pour faciliter le dev.
Je suis en congés pour le moment mais je vais essayer de regarder ça de plus prêt à mon retour.

Si je comprends bien, on peut débuter en C en HuC et éventuellement compléter avec de l'assembleur pour se faire la main petit à petit sur des fonctions non présentes en C? (Car à ce stade je me moque des performances)
Les compilateurs et outils sont dispos sur Linux et Mac ou juste sur Windows?