Sonic the Hedgehog - STE - Page 1

Hmm, c'est… succinct comme news.

Je viens de le tester sur mon mega ste, ça fonctionne bien et la vitesse est aussi au rendez-vous, c'est assez bluffant

C'est quoi concrètement ? Un port du sonic méga drive ?

Salut les copains.

Je suis le "responsable" de la chose.
C'est donc en effet un port de Sonic MD, sur STe.
J'y suis depuis un moment, la sortie de la proof of concept de Sonic sur A1200 m'a incité à finalement montrer cette version :-)
Le port est basé sur le génial travail de désassemblage de Sonic 1 de Sonic Retro (s1disasm).

J'ai repris le dev depuis, je mettrais bientôt à jour la version publique sur Github.

Le STe permet (mais on l'a vu à de nombreuses reprises) de faire de chouettes choses, ce qui coûte vraiment c'est le deuxième plan derrière, mais ça on le sait tous.
Il faut une machine avec 4mo de ram, je sais c'est pas marrant, mais du coup on a son DMA et un scrolling fluide.
Sur un Mega STe, ce sera plus rapide, le parallaxe sera quasi fluide sur la version à venir.

Une fois les 4 niveaux en cours de dev terminés, je mettrais les sources à dispo pour qui veut voir comment ça marche.

Sympa je peux pas tester n'ayant pas le hardware. Je vois que tu as réussi à réduire les couleurs sans grand massacre
Ça donne quoi comme framerate à l'heure actuelle ? Et ça serait fluide avec un seul plan ?

=> vous y trouverez le dépôt du jeu.

Brunni, avec un seul plan, c'est plutôt "vivant" : 27-34 fps (les zones les plus lourdes comme le sol qui s'effondre font chuter).

Si tu veux voir le jeu tourner, j'avais mis une video sur le vrai hardware qu'a mis en ligne sur son blog notre brave Jacques Atari : https://jacquesatari.blogspot.com/2026/09/sonic-hedgehog-sur-atari-mega-ste.html
Il tourne mieux maintenant, j'essayerai de refaire une video bientôt, avec une video de la version Falcon aussi.

C'est déjà impressionnant !

Ceux qui ont une petite carte accélératrice sur leur Falcon qui overclock le 68030 à seulement 32 MHz pourraient avoir une version parfaite si tu vas au bout de ton projet car sur Hatari c'est souvent en 1VBL à cette fréquence !
Cela dit même sur STE c'est déjà impressionnant.
Tu procèdes comment pour les routines de scrolling et de sprites pour les deux machines ?
Est-ce que tu utilises les routines incroyables au Blitter de Anima /Douglas Little (AGT) ?
J'espère que tu vas garder ta motivation car c'est assez génial à voir, en plus c'est un super jeu.

Merci Zerosquare et Xerus.

Actuellement, la version 030 stock est pas à 1VBL. On est à 35fps en moyenne, tu peux tester si tu veux : https://github.com/guybrush-atari/Sonic-Falcon
La version Falcon est le parent pauvre : j'ai commencé par celle-ci puis la version STe m'a pris beaucoup de temps. Au début, je voulais maximiser le code commun, puis comme toujours, ça devient intenable
Tout ça pour dire que la version Falcon peut viser les 50 fps : sous Hatari avec un 030 à 32 MHz, on est déjà quasiment à 1 VBL. Sur un 030 d'origine, il faudrait optimiser pas mal.

Sur STe, pas de sprites matériels :
Scrolling : scrolling matériel du STE sur deux grands écrans en RAM.
Sprites : phases précalculées, dessinées au blitter en deux passes.
Le HUD (hideux je sais...) : écran séparé de 8 lignes, avec un raccord en timer B.
Parallaxe : les colonnes du fond sont gardées d'une image à l'autre et ne sont recomposées que lorsque le fond s'est décalé par rapport au décor (il scrolle à mi-vitesse) ou que l'eau s'anime.

Sur Falcon, c'est le 68030 qui fait l'essentiel des copies, toujours en 4 plans. J'ai essayé le blitter sur les gros blocs du fond, mais c'était plus lent.

AGT : je ne l'utilise pas directement, mais j'ai beaucoup lu le travail de Douglas Little, c'est une référence (il est dans les crédits). Même chose pour le Hardware Phase Scrolling de Jeffrey Young + les articles de Leonard et de Paranoid sur le blitter.
Ici le blitter fait toutes les grosses copies, comme les blocs de décor qui arrivent, le fond de parallaxe et l'affichage des sprites.

Concernant la motivation... C'est surtout le temps (comme tout le monde) qui fait défaut.
Mon but c'est d'avancer encore un peu, puis de documenter à mort le moteur et de rendre publique le tout.

Falcon :

Sur Falcon, c'est le 68030 qui fait l'essentiel des copies, toujours en 4 plans. J'ai essayé le blitter sur les gros blocs du fond, mais c'était plus lent.

Merci pour tes explications.
Le blitter est plus intéressant si tu l'utilises pour faire des opérations logique du genre pour afficher des sprites, pour une simple copie c'est un peu mieux d'utiliser le 030 en effet, ça doit dépendre aussi comment on profite du cache.
Après vu que le Falcon a un paquet de mémoire, peut-être que des blocs pré-décalés pourrait être intéressant en terme de perfs... si ça rentre dans les 4 Mo.
En tout cas bon courage, hâte de voir la suite.

Ha oui impressionnant. C'est pas un portage du jeu d'origine dans ton cas, mais recodé de zéro ? Je vois que la physique est un peu différente.

Bonjour,

quelle est la part d'IA impliquée dans le projet et dans quelle mesure elle s'inspire du portage Amiga ?

@Brunni : tu as l'oeil, il y a encore du travail sur la physique c'est vrai

@Yoshi Noir : Bonjour,
c'est un projet entamé il y a un bail, je ne me suis pas du tout inspiré du portage Amiga (qui je l'avoue est vraiment sympa, et bien présenté).
Depuis que j'ai décidé de m'y remettre (la sortie de la version A1200), l'IA me sert pour "l'outillage" : compilation et benchs, c'est magique, ça fait gagner un temps fou.

Oui je vois merci. Le gars qui fait la version Amiga justement il fait tourner le code d'origine, donc il n'a pas à implémenter la physique

@Guybrush14 Je ne connais pas les plateformes Atari, mais le résultat est impressionnant bravo 👏

Une question. En quoi la physique serait elle différente du jeu d’origine, puisque basée sur le projet de désassemblage du code « s1disasm » ? Ils ont forcément retrouvé les instructions pour la « physique » dans le code et je ne vois pas pourquoi ils les auraient modifiées.

Guybrush14, sur Falcon, par rapport au décor de fond, est-ce que tu fais un masquage avec la palette (donc profitant de la particularité du mode planar) ou bien tu utilises un masque via des opérations logiques ?

Le gros du travail au début c'était l'affichage : sur MD le chip graphique fait tout, sur nos machines c'est le processeur et le blitter qui doivent tout dessiner, je ne vous apprends rien, ON EN A ASSEZ SOUFFERT

Pour tester et faire un proof of concept, j'ai travaillé avec une physique provisoire, avec les valeurs de s1disasm (accélération, gravité, saut…), sans reprendre le code ligne par ligne.
Comme Sonic se comportait à peu près bien, je suis pas revenu dessus, le magique "on verra plus tard", je me suis concentré sur l'affichage.
D'où les petites différences qu'on peut sentir (vitesse max, hauteur de saut en boule), je vais reprendre la physique au propre pour une prochaine release.

Xerus : chouette question.
J'ai commencé par le masquage classique, mais avec un fond qui bouge partout, c'était pas sympa fallait s'en douter. Je suis passé au masquage par la palette en profitant du mode planar : fond et terrain sur des plans séparés, la palette fait passer le terrain devant et le fond se recopie sans masque du coup. Si ça t'intéresse je veux bien de l'aide sur la version Falcon

Merci pour vos retours.

Voilà une gestion du "masquage" par couleur optimisée, à toi de l'appliquer dans ton code:

Tu peux découper l'arrière plan en 4 bandes et ne copier que les plans utiles, voir même faire un simple remplissage si il n'y a qu'une seule couleur dans la bande comme c'est le cas dans la bande n°2.
Ensuite tu peux appliquer le même genre d'optimisation dans l'avant plan, tous les éléments mobiles (le pont, le sol qui s'écroule, etc.) ou les blocs animés (fleurs, flotte, etc.) n'ont besoin que de 3 bitplanes si la palette est triée astucieusement, voir même 2 bitplans si on fait des consessions sur les couleurs !
Les fontes du HUD pourraient être en 2 ou 3 bitplans, ça pourrait donne un gain pas mal également.
Ce schéma n'est pas forcément le plus optimal mais permet déjà un gain sympathique.
Autre optime possible, une rotation de palette pourrait peut-être aider dans certains cas plutôt qu'une copie comme tu sembles le faire.

Ces méthodes ont fait leurs preuves sur ce moteur de plateformes dédié au Falcon, multiples parallaxes, 1VBL et c'est pourtant écrit 100% en C avec des routines blitter très lentes !

Un Falcon bien exploité peut faire des merveilles même pour les jeux d'arcades.

Maintenant si tu veux te focaliser uniquement sur le code, on peut t'aider.
Je peux m'occuper de finir la partie audio selon ta méthode et mon frangin des palettes et des retouches à faire sur les sprites ou décor.

Sur la démo du jeu d'Orion, il n'y a pas de musique parce que le Falcon est full ?

Non, c'est parce que mon frangin ne s'est intéressé qu'à l'aspect technique et visuel de son moteur, l'audio n'était pas sa priorité.
Il suffirait d'implémenter la routine DSP de Bitmaster (qui gère 4 canaux sonores pour les bruitages et 4 pour la musique) pour avoir un vrai environnement sonore avec quelques trucs sympas comme du surround ou de l'écho quand tu entres dans une grotte par exemple.
Il y a de la marge pour faire encore mieux à tout point de vue !

Je suis impressionné par la transparence de l'eau (enfin un peu radioactive). D'ailleurs Orion le fait aussi dans le jeu d'origine ?

Au final il utilise combien de bitplanes ? Et c'est Falcon non, le STe en a moins ?

Et c'est quoi le truc du boss à la fin étiré en x2 horizontalement ? Il y a une raison technique ? Même chose pour le fait qu'il soit en 2 bitplanes "seulement".

Je ne crois pas que Orion ait fait ça mais il pourrait le faire, c'est dans ses cordes.
L'eau est un tri de palette, ça consomme 0% de temps machine et ça apport 16 couleurs en plus, ça doit faire un jeu en 48 couleurs. On pourrait avoir plus de couleurs avec des rasters splitt mais personne n'a réussi jusqu'à présent à faire ça proprement sans parasites à l'écran, ça marche qu'avec 4 plans. Un mystère du Falcon qui n'est pas résolu pour l'instant ! Mais des génie du code comme Douglas Little pense que c'est possible, on verra ça le jour où il portera sa superbe libraire STE (AGT) sur Falcon, à mon avis si il le fait, tout le monde va encore tomber de sa chaise, il est coutumier du fait, probablement le meilleur codeur 68k/DSP toutes plateformes confondues selon moi !!!

C'est un moteur qui utilise 8 bitplans (le STE en a 4) donc maximum théorique 256 couleurs mais en pratique en jouant avec les plans si tu veux pas faire des masques pour gagner de la perf, ça peut vite descendre, genre 32 couleurs.
Mais c'est un choix du codeur ou du graphiste, si tu veux faire sans parralax, t'auras beaucoup plus de couleurs qu'une Mega Drive.
Cela dit, en fonction des jeux, tu as aussi un mode true color donc autant dire que si par exemple tu veux faire des rpg, jeux d'aventures, stratégie ou autres, tu pourras faire beaucoup mieux que les autres ordis (PC VGA 256 couleurs) ou consoles de l'époque, y compris NeoGeo !

En ce qui concerne le boss final, c'est pas une contrainte technique, c'est jusque mon frangin a rippé ça d'un jeu C64, il aimait bien le design et l'animation. Il aurait pu le retravailler mais il a eu la flemme lol
Je pense qu'avec une routine blitter comme celle de Douglas Little ou Anima, tu peux faire un boss bien plus gros et plus coloré sans problème sur Falcon.

En fait je ne comprends pas, je n'ai jamais vraiment bossé avec du planaire, je connais le concept de base utilisé par James Pond 2 sur AMIGA par exemple pour avoir étudié, mais je ne comprends pas le terme « tri de palette » ni la notion de plan "1-2", "1-3" etc. en ./19.

Je comprends qu'on peut faire de la transparence en réservant un bitplan effectivement (palette custom pour les couleurs 16-31 par exemple), mais c'est assez coûteux du coup.

Je ne comprends pas aussi l'idée des 48 couleurs, ni les contraintes techniques que ça implique dans la démo d'Alice. On dirait que l'avant-plan est essentiellement en 3 bits, donc t'as 7 couleurs mais pour le plan entier ? Et les trucs plus colorés comme les champis tu les blites séparément ? Et donc tu dois les effacer d'abord avant de scroller puis les redessiner ensuite ? Ou alors t'as un arrangement 3 bits (BPLAN) + 5 bits (APLAN + sprites) et tu redessines l'entier du APLAN + sprites à chaque frame ?

Je ne comprends pas le terme « tri de palette » ni la notion de plan "1-2", "1-3" etc. en ./19.

C'est pas "Tri" mais "Trick" que je voulais dire, j'ai tapé trop vite désolé.

Je comprends qu'on peut faire de la transparence en réservant un bitplan effectivement (palette custom pour les couleurs 16-31 par exemple), mais c'est assez coûteux du coup.

Non, il ne faut pas réserver un bitplane pour créer cet effet de transparence.
Il faut juste ajuster la palette globale entre les bitplanes pour que la couleur de l'eau devienne transparente.
Il n' y a aucune contrainte pour le coder. C'est 100% gratuit.

On dirait que l'avant-plan est essentiellement en 3 bits, donc t'as 7 couleurs mais pour le plan entier ? Et les trucs plus colorés comme les champis tu les blites séparément ?

Non l'avant plan utilise 4 bitplanes donc 15 couleur + une couleur "de transparence" pour laisser apparaitre l'arrière plan.
Et rien n'est "blitté" dessus sauf les vagues animées (le cpu serait plus efficace pour ça en +).

Dans ces 15 couleurs, seule la couleur de l'eau est transparente, mais n'importe quelle autre couleur pourait être transparente.
On pourait rendre l'herbe et le feuillage des arbres légèrement transparent par exemple, ce qui augmenterait considérablement le nombre de couleur affichés à l'écran et le tout gratuitement.

Ce qui est redessiné à chaque frame, c'est l'arrière plan et les sprites (sur les bitplanes 4-5-6-7) et le Hud (sur les bitplanes 0-1-2-3).
Mais pour accélérer la copie du décor du fond, la palette a été agencée sur les bitplane pour que ces derniers ne soit pas tous copiés.
Seul une partie du décor de fond n'utilise que les 4 derniers bitplanes. le ciel et les nuages n'utilisent que 2 bitplanes et la partie inférieur du fond 3 bitplanes.

C'est ce genre d'optimisation qui est proposé pour Sonic par Templeton via son schéma ci-dessus.
Pour optimiser l'affichage, il faut bien connaitre les couleurs qui sont associées aux bitplanes.

Voici un autre exemple si tu voulais faire un PACMAN en s'attardant avec les sprites:

Il n'est pas nécesaire d'utiliser tous les plans pour afficher les couleurs des sprites.
En choisisant l'ordre des couleurs dans la palette, les fantomes et pacman n'ont besoin que de 2 ou 3 bitplanes.
Cela économise beaucoup de temps machine, avec en bonus, une compression plus efficace des datas dans la mémoire vive et le support physique.

Si ta fonte est blanche par exemple, tu ne copieras que le bitplane 2 car la couleur blanche (la couleur 02) est associée à ce bitplane.
Si tu avais choisi de mettre la couleur blanche tout au bout de la palette (couleur 015) il aurait fallu afficher les 4 bitplanes.
D'ou l'importance de bien choisir l'ordre des couleurs dans sa palette si on veut optimiser la vitesse d'affichage.
Ce qui est amusant c'est que tout le monde imagine que tous les fantomes prennent le même temps machine (et ça serait le cas avec la majorité des programmeurs) mais en fait dans cet exemple, le fantome rose et verts sont plus gourmands !

L'AGT tool de Doug Little ne permet pas encore de choisir le nombre de bitplanes pour les sprites ou les copies de blocs. Il en avait parlé un moment il me semble.
Peut être qui le fera avec l'engouement actuel pour sa librairie, ça rendrait son moteur parfait (il est déjà génial).
Si l'on devait convertir par exemple Hybris sur STE, il faudrait que les vaisseaux enemies et les tirs du joueur soit en 3 couleurs (donc 2 bitplanes) comme sur Amiga pour le faire tourner en 50 fps.
Avec l'AGT Tool on ne peut pas le faire, donc il y aurait trop de ralentissement quand l'écran serait surchargé.
Et même avec cette optimisation ce serait compliqué, il serait préférable d'utiliser des sprites en code généré...


Concernant la transparence et le masquage.
Voici un schéma avec la palette de pacman si tu veux poser un sprite jaune sur le bitplane 2:

4 versions différentes:
1: Voici le résultat avec l'opération de type AND pour le masque et OR pour le sprite.
2: Ensuite le résultat sans les opération logiques.
3: Toujours le résultat sans les opération logiques, mais en modifiant simplement la couleur N°06 avec un jaune très clair pour obtenir... une transparence !
4: Et pour finir, si tu remplaces la couleur 06 par la couleur 04 tu obtiens... un masquage sans opération logique ! C'est donc gratuit en temps machine, mais tu perd une couleur.

C'est pour cela que tu peux faire un dualplayfield rapide sur Sonic Falcon (si tu utilises cette fameuse méthode) mais pas sur Sonic STE car tu as 2 fois moins de bitplanes et 240 couleurs en moins.
Le résultat serait très pauvre en couleurs sur STE ,10 couleurs au total avec la méthode de Joefish (cf sa démonstration remarquable d'un Shadow of the Beast ST revisité).

Ce qu'il faut retenir, c'est que pour obtenir une couleur avec le mode planar, tu dois associer entre 1 à 4 Bitplanes.
Pour obtenir la couleur violette (Couleur N°015) il faut additionner les 4 bitplans.
Pour obtenir la couleur bleue foncé (Couleur N°05) il faut additionner les bitplans 1 et 3.
Pour obtenir la couleur verte foncé (Couleur N°014) il faut additionner les bitplans 2,3 et 4.

Il faut vraiment programmer l'Atari ST pour comprendre le fonctionnement de l'affichage, c'est très particulier (comme l'Amiga qui est assez proche dans le principe).
En fait ce n'est même pas un trick en réalité, c'est une fonction prévue par le hardware.
La transparence sur Atari est cablé, c'est l'un des avantages du planar sur le chunki, pas besoin de calcul !

Bruni > sur le mode 8 plans 256 couleurs du falcon, en utilisant le système de plan tu peux faire un arrière plan qui scroll en parallax d'un avant plan grace a une répétition de palette.
exemple avec un arrière plan qui utilise 3 couleurs (plus une 4éme couleur de fond)
et un avant plan qui utilise 63 couleurs et une couleur transparente

il y a une répétition de la palette de 64 couleurs 4 fois, avec a chaque fois, la première couleur de la palette qui contiens une des 4 couleurs de l'arrière plan
si tu met en rose ces 4 couleurs tu aura ce résultat:



Maintenant on remplace les 3 palettes "recopié" par des couleurs bleu/vert/rouge pour bien comprendre l'astuce et ça donne ça:



on vois bien ici qu'en fait il n'y a pas de masking entre l'avant plan et l'arrière plan, le masking est fait par l'astuce de palette, ce qui evite de faire un masking manuellement et fait gagner beaucoup de temps CPU
c'est pas evident a expliquer en détail, mais il faut regarder ce qu'il ce passe en binaire pour bien comprendre
je n'ai pas utilisé cette astuce sur mon portage d'Alice sisters Falcon car je l'ai découvert après coup, donc sur la version falcon il n'y a simplement pas d'arrière plan comme sur la version megadrive, je n'ai même pas réussi a faire des rasters car instable sur falcon VGA.
j'avoue que j'ai un peu la flemme de revenir sur ce projet pour ajouter ça et surtout après avoir vu la version de Templeton qui m'a définitivement démoralisé sur mes capacités de programmeur.

D'abors super boulot de l'auteur.

Coucou le Xerus, ca fait plaisir de te revoir. Gros bisous a toi et on twin.


GT

Petit H.S. pour Xerus :

Pour la routine de sprite de DML et ton idée de pouvoir sélectionner les plans, j'ai une petite idée pourquoi il propose pas l'option.

Tu perds du temps a sauter les plans que tu veux pas. Sur le blitter ca te coute rien de sauter un plan avec un 68000 si. Car par exemple dans le cas d'un masque (And), mettre après un and et après une instruction pour faire sauter le plan va te couter plus cher que de faire le and sur un long et faire 2 plans simultanément.

ou meme si tu a juste a copier sans masquer tu peux copier un bon morceau du sprite en une instruction (enfin deux avec le chargement dans les registres, en utilisant par exemple movem.l ) etc.

Je suppose que c'est pour cela que l'option est pas proposé.

GT Plus rapide d'un coup

Hey GT le fan d'ASM invétéré
Oui tu as raison sauf si tu veux sauter 2 bitplans d'un coup (de 0-1 à 2-3 par exemple).

Orion, c'est juste que t'es passé à côté d'un truc (beaucoup de programmeurs ne l'ont jamais fait), ça change pas ton skill en programmation et t'as plus rien à prouver avec ton CV en terme de jeux
Rien ne t'empêche d'utiliser cette technique dans un de tes prochains jeux, d'autant plus que tu l'as compris !

Cerebral Vortex Rulez !

Bravo pour ce portage, reste plus qu'à le tester !