Upsilandre

Non celui là est bien en mode 7, je parle justement de cet exemple parmi d'autre dans le billet que j'ai mis en lien 🙂

Le fait d'avoir qu'une seul tilemap et de ne pas pouvoir profiter du warping en mode 2 joueurs pour une update classique de la tilemap et du scrolling est très pénalisant et rend le truc impossible à 60fps.

Ah génial je connaissais pas ce jeu! effectivement j'ai regardé, c'est infernal, ca remet à jour constamment l'intégralité des tilemap 512x512 pour adapter le PoV. En effet c'est pas très tenable en 60fps 😅.

Voilà donc, selon moi, 4 exemples de mythes et légendes techniques erronées sur SNES, souvent fondés sur du bon sens, ce qui explique leur longévité.
N'hésitez pas à en partager d'autres ici. J'en suis très friand et il y en a probablement plein que je ne connais pas 😀.

Voici une image de comparaison de la taille des circuits de Mario Kart, tous au même format 1024x1024 pixels, avec le plus grand un circuit F-Zero (7168x3824).

C'est donc la taille minuscule des circuits qui implique de réduire la vitesse, pas une impossibilité technique. L'idée du karting découle alors de là.
Je vous avais aussi déjà détaillé toute cette histoire dans un billet: upsilandre.over-blog.com/2022/06/debu... .

Ajouter un mode 2 joueurs oblige à faire tenir les circuits intégralement en VRAM ce qui limite leur taille à 1024x1024 pixels comme dans Mario Kart ou Street Race. C'est une contrainte technique qui n'est pas vraiment contournable dans ce contexte.

La véritable raison technique de cette impossibilité vient de la taille des circuits, pas de la vitesse. Ce qu'il est impossible de faire sur SNES c'est un F-Zero à 2 joueurs en gardant la même taille de circuit.

Le mythe vient plutôt de la raison technique évoquée. Ce serait la vitesse très élevée de scrolling dans F-Zero qui empêcherait irrémédiablement de faire un équivalent à 2 joueurs.

Vous connaissez probablement l'histoire de Mario Kart qui émerge de la volonté de faire un F-Zero à 2 joueurs ce qui se révèle techniquement impossible et qui donnera donc Mario Kart.

4️⃣ On termine avec Super Mario Kart 4️⃣

En réalité tous ces freezes viennent d'une très mauvaise gestion du loading des samples audio dans la RAM audio de la SNES en plus de les charger plusieurs fois. Ce problème à été corrigé récemment avec le patch MSU-1.

Le but étant de faire cette décompression de manière dynamique pendant le round car dans un versus fighting il faut constamment charger de nouvelles frames d'animation. Donc il n'est surtout pas là pour interrompre le déroulé du jeu, bien au contraire.

En effet la cartouche embarque un chip S-DD1 conçu par Nintendo et Ricoh et utilisé aussi dans Star Ocean. C'est un chip de décompression de tuile graphique qui est là justement pour décompresser les tuiles de manière transparente pour la SNES, à la volée.

Comme on le voit sur le gif ci dessus, en début de round il y a 3 freezes consécutif. Un long, un court et un long, pour un total cumulé assez conséquent de 7 secondes.
La légende raconte que c'est la décompression des données graphiques qui cause ces freezes.

3️⃣ Parlons maintenant du cas Street Fighter Zero 2 3️⃣

Le seul moment in-game du jeu ou le mode 7 est utilisé c'est pour animer la rotation de la tête du boss ED-209.
Mais tout ça je vous l'avais détaillé dans un billet dédié: upsilandre.over-blog.com/2023/02/axel... .

Un mythe des plus classique qui raconte qu'on doit cet effet rouleau étonnant au mode 7 de la SNES alors qu'il n'en est rien. C'est du mode 1 avec un simple raster effect aidé par sa fonction hardware HDMA.
Je m'étais amusé à reproduire l'effet sur une NES ⬇️

2️⃣ Restons dans les shmups avec Axelay 2️⃣

Par exemple dans Super Aleste on retrouve des phases comme celle ci, souvent utilisés sur les shmups 8bit pour avoir des scènes de shoot intense à moindre coût car les tests de collision avec les tuiles de background sont sensiblement moins coûteuses que celles entre sprites.

Si le jeu tourne si bien c'est avant tout grâce à l'expertise de Compile qui ont fait leurs armes sur toutes les machines 8bit même les plus limitées et savent parfaitement faire des shmups spectaculaires avec peu de ressource.

J'ai quand même creusé et je n'ai rien trouvé. A priori le SPC700 ne s'occupe que de la musique et des bruitages comme attendu. Aucune trace de quoique ce soit d'autre.

Ca semblait peu probable car les communications entre le CPU principal et le CPU audio sont très lentes et laborieuses. Donc difficile de trouver une tâche pertinente à déférer qui puisse avoir un réel impact.

La légende autour de Super Aleste raconte que si ce shmup tourne si bien sur SNES, comparé à d'autres, c'est parce qu'il décharge certaines tâches sur le CPU audio (le SCP700) pour soulager le CPU de la console.

Un thread rapide sur 4 mythes et légendes techniques ,souvent partagés mais erronés, concernant 4 jeux SNES. Ça m'a pris comme ça ce matin 😀.
N'hésitez pas à en ajouter en commentaire, j'adore ces mythes.⬇️
#Retrogaming #SNES

1️⃣ Commençons par Super Aleste... 1️⃣

Tout ca est très direct et revient a lire directement l'état des boutons selon moi. C'est un processus qui se compte plutôt en microseconde qu'en milliseconde.

Effectivement même sur NES les inputs sont lu en série. De ce que j'en sais, quand tu lis les inputs du pad tu envoie un signal par le port qui va induire le chargement instantané d'un registre à décalage dans le pad avec l'état exacte de chaque input, ensuite tu lis ce registre par shift successif.

Voila a peu prêt tout ce que j'ai compris pour l'instant.
Je vous met le lien du thread précèdent sur l'input lag.
bsky.app/profile/upsi...

Logiquement il est censé être peu significatif aussi même avec un microcontrôleur bas de gamme mais difficile de savoir quelle tambouille interne font certaines manettes, notamment pour économiser de l'énergie (pour le wireless). D'autant que c'est très difficile à mesurer.

Il y a aussi le temps de traitement par le driver de la machine hôte mais qui en toute logique est insignifiant. Par contre c'est un peu plus flou pour le temps de traitement interne à la manette. Combien de temps le microcontrôleur consacre à la préparation du paquet de données?