Out Run Arcade AGA (2025 Reassembler) v0.9.2 (21/09/2025)

Out Run Arcade (2025 Reassembler)

Portage d’Out Run en version Arcade pour Amiga AGA par l’auteur de Cannonball (moteur opensource d’Out Run pour ordinateur moderne). La configuration visée serait celle de l’Amiga réel de l’auteur: un A1200 avec 68030. C’est en découvrant les portages sur Amiga RTG de son Cannonball qu’il a eu l’idée de cette nouvelle version native pour Amiga.

Out Run Arcade AGA (2025 Reassembler)

 

 

Configuration requise:
AGA
68030
8 Mo de Fast Ram

 

 

Téléchargement : HDD (itch) / WHDLG / WHDL

 

Autres versions d’Out Run:
Out Run (1988 Probe/Sega/US gold)
Turbo Out Run (1990 ICE Software/US Gold)
Out Run Europa (1991 Probe/US Gold)
Cannonball RTG (2017-2022 Lantus360/Richter)
Out Run Remake AGA (Agermose) WIP

Source:
https://reassembler68k.itch.io/outrun-amiga-edition
https://eab.abime.net/showthread.php?t=120919
https://eab.abime.net/showthread.php?t=116656
http://reassembler.blogspot.com
https://fr.wikipedia.org/wiki/Out_Run
https://www.mobygames.com/game/outrun

Sujet

[Logo Level 6Messages : 258]

Bon courage pour ce portage, on croise les doigts…

[Staff Aladin Level 25Messages : 15862]

Message de Reassembler (10/01/2024)

Pendant les fêtes de Noël, j’ai décidé d’apprendre les bases de la programmation sur Amiga. J’avais déjà une connaissance moyenne de l’assemblage 68k, et j’avais récemment récupéré l’Amiga dans le grenier et l’avais pimpé. Il était temps de faire la fête.

En termes d’outils et de références, j’ai utilisé :
– VSCode Amiga Assembly
– Bare Metal Amiga Programming
– Le manuel de référence du matériel Amiga
– Des montagnes de scripts Python pour traduire les structures de données et remapper les choses pour optimiser la vitesse.

C’était suffisant pour me lancer. Grâce à mon précédent projet CannonBall et à mon travail sur le matériel d’arcade, j’ai décompilé et documenté toute la base de code d’OutRun.

C’est si difficile que ça ?
– Plutôt difficile ! J’ai pris la décision de cibler AGA avec un accélérateur modeste (TerribleFire 1230). Principalement parce que c’est le matériel que j’ai sous les yeux. Et regardons les choses en face : s’il s’agit d’une sorte de portage arcade, plutôt qu’une réécriture ou ma propre interprétation d’OutRun, il ne fonctionnera pas sur l’A500.
– Quoi qu’il en soit, j’ai commencé par porter le code routier et par simuler le matériel routier personnalisé. Cela ne semble pas particulièrement fascinant, et ce n’est peut-être pas très sexy. Mais en réalité, l’intégralité du moteur OutRun repose sur le bon fonctionnement du matériel routier et du code correspondant.
– Pour ceux qui ne connaissent pas le matériel de Sega, il s’agit de 2 processeurs 68000 cadencés à 10 MHz et d’un Z80 pour l’audio. Il y a un nombre important de puces graphiques personnalisées, qui font vraiment tout le travail et représentent le défi de traduction le plus important. Pour vous donner une idée, j’ai essayé un portage naïf mais optimisé du code de rendu routier de MAME sur 68K et il a fallu environ 8 vblanks pour rendre une seule image sur un 030 accéléré ! HAH ! Et cela sans qu’aucun code de jeu ne soit exécuté.
– Pour le rendu routier, OutRun consacre un processeur 68000 entier, ainsi que du matériel de rendu routier personnalisé – plutôt avancé pour l’époque ! En fait, même le 68000 principal est impliqué dans le contrôle de la largeur de la route, l’application des cartes de hauteur, la séparation de la route à la fin du niveau et au-delà. Il y a donc deux 68K qui s’occupent de cette chose.
– C’est évidemment l’une des raisons pour lesquelles OutRun est/était le chef des jeux de course en 2D. Largeurs de route flexibles, palette de routes dynamiques, routes se divisant en voies, paysages ondulés. La route, ou plutôt les routes, puisqu’il peut y en avoir deux, sont importantes.
– Dans la mesure du possible, j’ai essayé de garder le code 68K original intact pour l’instant. Il s’agit d’un portage ligne par ligne. Les principaux changements ont porté sur les structures de données (les palettes, la ROM route et diverses autres folies) dans une vague tentative de les marier avec les attentes du matériel Amiga et mon code Amiga frankenstein.
– Après avoir réécrit toute la couche matérielle de la route environ 7 fois – et je le pense vraiment – j’ai trouvé une solution combinant le Copper et le Blitter avec un peu d’ingéniosité. Il s’agit surtout de l’ingéniosité d’OutRun, par opposition à quelque chose de révolutionnaire pour l’Amiga. Ma programmation Amiga est probablement mauvaise.
– Une chose qui m’excite particulièrement est que j’ai réussi à rationaliser tout le système de priorité des routes, qui est une bête… géré sur une base par pixel sur MAME, où chaque pixel de la route est croisé avec une table de priorité et comparé avec « l’autre route » pour déterminer quels pixels doivent être affichés… à un seul blit minterm par plan et une refonte complète de la façon dont une route est représentée dans la mémoire.

Pour l’instant, nous avons mis en place les éléments suivants
– Possibilité de charger les données de niveau originales
– Couleurs correctes de la palette
– Couche de matériel routier : Largeur, hauteur, direction, voies, palettes
– Portage de la base de code complète du sous-processeur 68000
– Portage de certains éléments de base de l’unité centrale
– Séparation des routes
– La possibilité de se déplacer dans un niveau avec le clavier

Pour être clair : je ne sais pas jusqu’où j’irai avec ce projet. C’est un projet difficile. J’ai consacré beaucoup d’énergie aux bases et cela a été une expérience d’apprentissage formidable et quelque peu douloureuse. Prochainement, il sera probablement judicieux de rendre des sprites, et peut-être de les mettre à l’échelle. Je serai probablement à court de couleurs, de mégahertz ou de raison d’ici là. Ou alors j’irai simplement au pub.

Vidéo WIP (10/01/2024) : Amiga 68030

https://youtu.be/wU1kXWuO6JM

 

Message de Reassembler (01/02/2024)

En voici les grandes lignes :
– Implémentation du matériel Sprite d’OutRun dans le logiciel : Zoom sur les sprites en temps réel ( !), retournement des sprites en temps réel, rendu des sprites originaux, sans aucune modification, avec toutes les palettes originales, les données, etc.
– Le code CPU principal pour le rendu des décors et l’analyse des données de scène est opérationnel.
– Implémentation d’une mise en cache personnalisée des palettes de sprites. OutRun remplit jusqu’à 128 x 16 palettes de sprites séquentiellement au fur et à mesure de la progression de chaque scène. OutRun aime ses couleurs – les jeepers. Nous n’avons pas le luxe d’avoir autant de couleurs simultanées. Nous devons également réserver de l’espace de palette pour les tilemaps, les Ferrari, les HUD et le trafic à l’avenir.
– J’ai réussi à réduire le nombre de palettes utilisées par le décor de 128 à seulement 8 par scène ! Ce n’est pas en supprimant des couleurs et en créant une monstruosité laide dans le processus. Au lieu de cela, j’ai mis en œuvre un algorithme de mise en cache des palettes AGA. Il surveille les palettes qui ont été utilisées le plus récemment et les fait entrer et sortir des registres de couleurs en temps réel au fur et à mesure que vous avancez dans le niveau (c’est relativement élégant et rapide). (C’est relativement élégant et rapide).
– Je n’ai eu qu’à apporter des modifications mineures aux données des niveaux – elles sont probablement imperceptibles pour 99% des joueurs. C’est relativement facile à faire, car j’ai codé des scripts Python pour exporter toute la structure des niveaux en Assembleur commenté facilement lisible. L’étape 1 est le tour de force le plus techniquement exigeant d’OutRun. Si cela fonctionne, je suis sûr que le reste suivra. En fait, je ne le suis pas, mais faisons comme si je savais ce que je faisais.

Autre chose :
– Devinez quoi – j’ai encore réécrit le code de la route ! J’ai perdu le compte du nombre de réécritures. Non, sérieusement, c’est encore plus rapide maintenant (c’est juste ralenti par le nouveau code – des centaines de sprites à l’échelle en temps réel). L’itération du blitter que j’ai montrée précédemment était un pas en avant – mais en fin de compte une limitation aussi. Mais le travail que j’ai effectué dans ce sens a donné un coup de pouce massif à la dernière version. J’ai réécrit tout ce que le blitter faisait dans le logiciel. En fait, il s’agit de spammer des tas de pixels en mémoire et de fusionner les routes. Quand on pense que la première version nécessitait 8 VBlanks pour rendre une seule image de route. Ceci étant dit, je n’ai pas encore trouvé une façon d’écrire en 68k qui n’implique pas de multiples cycles d’optimisation si elle doit fonctionner à une vitesse fulgurante.
– Conversion du rendu en c2p. Chunky et funky. Je n’ai pas écrit ma propre routine, ça n’a pas l’air amusant.

Bugs :
– Je n’ai pas travaillé sur les ombres, qui ressemblent donc à des taches brillantes de vomi aux couleurs aléatoires. Au début, j’ai pensé les désactiver pour optimiser les performances. Mais j’ai l’ambition d’implémenter des ombres translucides. C’est probablement un objectif stupide. C’est probablement un projet stupide. Il faut quand même avoir des objectifs un peu plus ambitieux, je suppose.
– Il y a un problème frustrant et bizarre avec la distribution des sprites. Elle n’est pas correcte. J’ai regardé les choses évidentes du moteur et je n’ai pas encore découvert le problème. Il se peut que vous ne le remarquiez pas. Mais ça m’énerve au plus haut point. Cela pourrait se transformer en une session de débogage de 6 heures avec des références croisées à Mame. J’adore ça. Il y a des dizaines de milliers de lignes de code à ce stade. Le pire, c’est que je ne sais vraiment pas s’il s’agit d’un bug dans le portage du moteur principal d’OutRun, de mon code de rendu, ou d’une sorte de bizarrerie de timing. Je pense que je finirai par trouver un symbole ‘+’ mal placé qui incrémente un registre d’adresse, ou une sorte d’octet ou de mot erroné.

Et ensuite ?
– Optimisation du code des sprites. Optimisation dans ce cas = beaucoup de routines spéciales et perte d’une partie de la généralisation que j’ai actuellement. Plus de code à maintenir me rend triste. Plus de vitesse, par contre, c’est bien. J’ai déjà réalisé quelques optimisations. L’optimisation conduit naturellement à casser des choses qui fonctionnent déjà, et à l’illisibilité, c’est donc un équilibre délicat. Mais de manière réaliste, j’ai besoin de tous les cycles que je peux trouver pour ce mauvais garçon.

Note complémentaire :
– je suis retourné voir l’émulateur System 16 – le premier émulateur à reproduire OutRun du milieu des années 90. Il nécessitait un Pentium fonctionnant à 200Mhz pour des performances décentes. Bien sûr, il émulait le code du 68000 et il n’y a pas d’émulation ici – mais il était principalement écrit en assembleur x86 et contenait beaucoup de bidouillages pour supprimer la synchronisation des interruptions entre les CPU. Il faut faire ça avec une fraction de cette puissance.
– Corriger le bug de distribution et de disposition des sprites. Je déteste ce bug.
– Convertir les données de niveau restantes pour que chaque scène soit rendue. Ennuyeux d’un point de vue intellectuel. Excitant d’un point de vue « joli ».
– Régler les ombres. Dans le pire des cas, les désactiver. Dans le meilleur des cas, se prélasser dans une gloire translucide.
– Tilemaps. Elles ne seront probablement plus vraiment des tilemaps. Besoin de ces nuages.
– Je ne me préoccupe pas du gameplay pour l’instant. Je suis plus intéressé par le fait de faire tourner le moteur à plein régime. Je posterai un aperçu dans quelques semaines pour que vous puissiez le faire tourner par vous-même. Ou découvrir qu’il ne fonctionne pas. Ce qui pourrait être utile.

Vidéo WIP (01/02/2024) : WinUAE

https://youtu.be/ZwNcuyVYDec

 

Message de reassembler (16/02/2024):

J’ai eu beaucoup de mal à optimiser les routines de sprites.

Quelques points forts :
– Les 15 Stages sont en place et le rendu est correct avec les données originales du niveau. Vous pouvez progresser à travers eux, via le partage de la route et les touches du curseur. Le moteur et les optimisations que j’ai faites semblent techniquement sains. Tous les niveaux devraient être parfaits au pixel près par rapport à l’original en termes de disposition, de cartes de hauteur de route, de courbes, de disposition des sprites.
– Les routines de sprites sont maintenant beaucoup plus rapides. D’un facteur de 2 à 3 fois les performances. J’ai divisé le rendu des sprites en 6 routines personnalisées qui peuvent chacune faire une variété d’hypothèses sur la façon dont le sprite va être rendu. Ce code est un cauchemar à maintenir, mais il est aussi optimisé que mon cerveau peut le supporter pour l’instant. Seul un nouveau paradigme pourrait améliorer les choses. Ou alors, il suffit de supprimer les décors.
– J’ai optimisé une partie du code original d’OutRun. Pour être honnête, ce n’est pas le chemin critique en terme de performance, mais il y avait des inefficacités dans les routines de sprites les plus appelées. Je pense que je suis la première personne à optimiser le code original depuis 1986, donc c’est assez amusant et satisfaisant.
– Dans un mouvement qui m’a quelque peu surpris, j’ai réussi à faire fonctionner la translucidité des ombres et avec une solution qui n’est pas plus lente que le rendu d’un sprite – enfin, c’est plus rapide que le rendu des blobs que j’avais auparavant ! Donc oui, le moteur peut désigner une ombre à un sprite et il assombrira les pixels sous-jacents de la couche de route selon le matériel. J’utilise en fait les valeurs correctes dérivées de l’analyse du matériel pour l’assombrissement. Je ne sais pas si MAME est encore bogué, mais ses ombres étaient beaucoup trop claires pendant de nombreuses années. Améliorons la version Amiga !
– Il existe un autre mode d’ombrage qu’OutRun utilise également. Je ne pense pas pouvoir le supporter du point de vue des performances car il nécessiterait une vérification du rendu par pixel qui ferait chuter les performances. Mais c’est moins visible et utilisé pour un effet mineur en comparaison.
– J’ai encore optimisé mon code routier. C’est amusant – vous pensez qu’il n’y a plus rien, et puis vous le regardez un autre jour et vous trouvez une série d’idées. Ce sont des gains marginaux à ce stade.
– Globalement, je pense que c’est le projet d’optimisation et de portage le plus complexe que j’ai jamais entrepris. Bien que je ne veuille pas créer un faux sentiment d’espoir, la mise à l’échelle des sprites et le rendu des décors étaient les points qui me préoccupaient le plus. Et cela fonctionne plus rapidement maintenant.
– Je n’ai jamais visé un A1200 stock avec ce projet, pour le meilleur ou pour le pire, car il exécute le code arcade et utilise abondamment la FastRam. (Agermose se bat sur le A1200 stock avec sa version. Un projet encore plus difficile que celui-ci).

Vidéo WIP (18/02/2024) : Amiga 68030

https://youtu.be/AKCf3kaY8jc

[Staff Aladin Level 25Messages : 15862]

Message de reassembler (14/03/2024):

J’ai travaillé sur deux parties un peu ennuyeuses, mais restantes du moteur de rendu.
– Les tilemaps.
– Les fondus de palette entre les transitions de niveau.

Pour le résultat final – qui n’est pas aussi excitant que la route ou les sprites – ces éléments ont pris un temps étonnamment long à implémenter et ont été pénibles à coder.

– Le matériel d’OutRun possède deux couches de tuiles séparées, les couches de tuiles d’avant-plan et d’arrière-plan, qui défilent indépendamment. Chaque couche comprend 4 tables de noms qui peuvent être disposées de différentes manières. L’arrangement d’OutRun consiste en une couche d’avant-plan de 2 048 pixels de large à défilement rapide et une couche d’arrière-plan de 1 536 pixels de large (utilisée pour les nuages géants de l’étape 1, par exemple).
– Les tilemaps sont relativement simples à mettre en cache dans une image géante hors écran avant d’afficher la zone visible à l’écran, ce qui sert en partie de dispositif d’effacement d’écran, ce qui est agréable.
– La difficulté survient lorsque les transitions du niveau et les nouvelles tuiles apparaissent de manière dynamique et fluide. A ce moment, l’utilisation de la palette double, le nombre de tilemaps double et il est nécessaire de décoder les tilemaps et de les rendre sans ralentir l’expérience globale.
– En raison des diverses optimisations que j’ai effectuées pour faire en sorte que les tilemaps soient aussi rapides que possible pendant le jeu normal, cette transition de 5 secondes est devenue incroyablement délicate.
– Quoi qu’il en soit, il semble fonctionner et se comporter de manière identique à l’arcade. Mais, mon dieu, pour une raison ou une autre, c’était juste une expérience de codage horrible. Il a fallu beaucoup de débogage ligne par ligne pour cette transition.
– Les transitions de palette entre les étapes n’étaient pas trop mauvaises. Cette section du code fait disparaître la palette de la route, le ciel et l’arrière-plan lors de la transition entre les étapes. J’ai pratiquement retravaillé ces éléments pour AGA car les originaux utilisaient le format de couleur Sega de 5 bits par pixel.
– A part cela, j’ai optimisé d’autres parties du code. Le code de rendu des routes est encore nettement plus rapide, au détriment de la mémoire.
– Ce week-end, j’essaierai les choses sur le matériel, je prendrai une vidéo si j’en ai l’occasion et, je l’espère, je nettoierai le dernier code et je mettrai un coup de pied dans les pneus pour détecter les bogues.
– L’essentiel – et je vais sans doute regretter de l’avoir dit – c’est qu’une grande partie de la logique de jeu restante devrait être relativement facile. Il s’agit presque d’un copier-coller du code source original. J’ai trouvé des solutions pour tous les rendus nécessaires et il me reste à peu près assez de couleurs. Le jeu n’est pas non plus particulièrement gourmand en performances.

Vidéo WIP (17/03/2024) : Amiga 68030

https://youtu.be/VvKbizWZBOg

[Staff Aladin Level 25Messages : 15862]

Test Engine (22/03/2024)

https://eab.abime.net/showpost.php?p=1675539&postcount=145

Il s’agit d’une démo technique, et non d’un jeu jouable, de mes progrès dans le portage de la version arcade d’OutRun sur Amiga. version arcade d’OutRun sur Amiga. Il existe une grande variété de configurations Amiga configurations Amiga dans la nature et je suis curieux de savoir si ce jeu fonctionne sur et comment il se comporte.

Matériel requis :
Processeur 68030
Chipset AGA
2 Mo de CHIP
8 Mo de FAST

Le seul matériel authentique sur lequel j’ai testé cette solution est ma configuration personnelle, qui consiste en un A1200 avec une carte TF1230. qui consiste en un A1200 avec une carte TF1230. Celle-ci ajoute un Motorola 68030 @ 50Mhz avec 128mb Fast RAM. Il peut fonctionner sur du matériel basé sur une 020, mais pas à une vitesse utilisable.

Qu’est-ce qui a été porté et émulé jusqu’à présent ?
– Données de niveau pour les 15 étapes
– 30% de la base de code 68k principale
– 100% de la base de code Sub 68k
– Matériel Sega Tilemap (2 couches)
– Matériel de mise à l’échelle des sprites Sega, ombres translucides partielles
– Matériel de route Sega

Limitations connues
– La palette de l’Autobahn de l’étape 5 est incorrecte.
– Ligne horizontale entre les tilemaps et la couche de route par moments. Difficile à résoudre car c’est le résultat d’une difficile à résoudre car c’est le résultat d’optimisations de rendu extrêmes (mais nécessaires). rendu (mais nécessaire).
– Quelques problèmes temporaires de palette de sprites si le moteur revient à l’étape 1 à partir de l’étape finale.

https://youtu.be/rxKWThBZcXk

 

Message de Reassembler (18/04/2024)

Quoi de neuf ?
– Tous les portages logiques de la voiture ont été faits
– Ferrari Sprite, Shadow & Palette ajoutées. (Y compris les feux de freinage, le mouvement des pneus)
– Sprites de passagers animés ajoutés
– Simulation des contrôles analogiques et digitaux (via le clavier Amiga)
– Mise en place d’un moyen de réduire les palettes dans mon outil python. J’ai dû réduire les sprites des passagers de 2 palettes de 16 couleurs à 1 palette de 16 couleurs. Mais c’est à peine si l’on s’en aperçoit.

Quelle est la prochaine étape ?
– Effets hors route
– Fumée lors de l’accélération, des virages et des changements de vitesse
– Accident contre des objets

Pour l’instant, je me concentre uniquement sur l’introduction de nouveaux éléments. Je n’ai pas fait de passe d’optimisation sérieuse sur quoi que ce soit de récent. Il faut que j’aille plus loin dans le processus de gameplay, sinon je vais me faire mal.

Vidéo WIP (18/04/2024) : WinUAE

https://youtu.be/QaP7Tn2cqUs

 

Message de Reassembler (11/05/2024)

J’ai le plaisir de vous annoncer que tout ce qui précède est maintenant terminé.

– Le code de crash d’OutRun représente à lui seul plus de 1 300 lignes d’assembleur et utilise plusieurs formats d’animation de données – c’est plutôt costaud. Si vous êtes familier avec OutRun, vous savez qu’il y a au moins quatre façons différentes de se crasher :
. Le crash au ralenti, où la voiture s’élève doucement dans les airs
. Crash à vitesse moyenne, où la voiture tourne à 360°.
. Le crash rapide, qui renverse les passagers dans le paysage.
. Crash super rapide, où le sprite de la voiture « zoome » vers l’écran et le remplit.
– De nombreuses séquences d’animation sont également jouées entre les passagers de manière aléatoire – les doigts se pointent, la femme frappe l’homme, etc.
– Il y a également de nombreuses séquences d’animation jouées entre les passagers de manière aléatoire – les doigts pointés, la femme frappant l’homme, etc.
– J’ai dû faire des choses bizarres pour que cela fonctionne avec mes optimisations actuelles.
– En termes de jeu jouable, la seule chose qu’il reste à faire est d’implémenter le trafic… mais il y a beaucoup plus que cela en termes de score, de HUD, d’optimisations et ainsi de suite.
– Je suis moyennement confiant d’avoir quelque chose de jouable sur la 030 une fois que j’aurai sorti ma tronçonneuse. Mais voyons voir.

Message de Reassembler (15/05/2024)

– Je ne vais pas me lancer dans l’implémentation de « nouvelles » fonctionnalités dans la version Amiga. J’ai vraiment fait cela dans le cadre de CannonBall (machines modernes) et OutRun Enhanced (fonctionne sur le matériel Arcade). Il s’agit plus d’un effort pour faire fonctionner le jeu. Ceci étant dit, j’ai corrigé quelques bugs simples présents dans le jeu original.
– En fait, j’ai fait beaucoup d’optimisation. Beaucoup. Mes chiffres m’indiquent que cela a fonctionné. En fait, même si la majeure partie de la logique du jeu fonctionne et que le jeu est jouable, il tourne plus vite que la démo précédente. Cela dit, la vitesse n’est manifestement pas encore suffisante.Je ne vais pas me lancer dans l’implémentation de « nouvelles » fonctionnalités dans la version Amiga. J’ai vraiment fait cela dans le cadre de CannonBall (machines modernes) et OutRun Enhanced (fonctionne sur le matériel Arcade). Il s’agit plus d’un effort pour faire fonctionner le jeu. Ceci étant dit, j’ai corrigé quelques bugs simples présents dans le jeu original.
– En fait, j’ai fait beaucoup d’optimisation. Beaucoup. Mes chiffres m’indiquent que cela a fonctionné. En fait, même si la majeure partie de la logique du jeu fonctionne et que le jeu est jouable, il tourne plus vite que la démo précédente. Cela dit, la vitesse n’est manifestement pas encore suffisante.
– De plus, le code d’Attract AI / Logic d’OutRun est tellement merdique… il ne peut rien faire de correct ! J’ai écrit une version améliorée pour CannonBall. Mais l’original était là, en 68k, prêt à être utilisé, alors je l’ai rapidement porté.

Vidéo WIP (15/05/2024) : Amiga 68030

https://youtu.be/CLaedlbr4wg

[Staff Aladin Level 25Messages : 15862]

Etat d’avancement (27/02/2025)

Message de Reassembler : (EAB)

– Les choses se sont très bien passées avec ce projet. Le jeu entier est maintenant porté et fonctionne. Je viens « juste » de trouver l’audio à faire ensuite.
– Pour faire court, ça tourne à environ 15 fps sur ma 030 maintenant – avec très peu de sacrifices. Et je pense qu’il tournera à la vitesse arcade maximale sur une 040 potentiellement.
– Honnêtement, ce projet a été plus difficile que je ne l’aurais cru, mais je ne sais pas à quoi je m’attendais. Malgré l’héritage 68k d’OutRun, et le fait que ce soit techniquement un portage du code arcade, presque chaque ligne a dû être examinée et reconsidérée.
– Les aspects les plus complexes étaient les performances globales, ou leur absence, et les limitations du matériel graphique de l’AGA. Alors que les 256 couleurs simultanées de l’AGA semblent être une quantité substantielle, le matériel d’arcade peut en gérer plusieurs milliers. Et, ce qui est peut-être plus important, il s’attend à pouvoir les appeler à tout moment.
– En ce qui concerne les performances, la meilleure analogie que je puisse faire est de retirer la carte Geforce de votre PC et de vous rendre compte que vos jeux tournent à une fraction de la vitesse sans elle. Le matériel d’arcade de Sega était spectaculaire, et le matériel de Commodore a été construit avec un budget familial à l’esprit, pour le dire gentiment.
– J’ai travaillé cinq mois de manière productive au début de l’année 2024, puis j’ai perdu ma motivation. Il est préférable, pour moi en tout cas, de s’attaquer à un projet de cette ampleur dans un état de flux profond. Quelques heures par semaine ne suffisent pas. Mais pour continuer à travailler avec cette intensité, je dois continuer à m’amuser. Et une fois l’été arrivé, il y a eu d’autres distractions.
– Revenir sur le projet cette année m’a donné une nouvelle perspective et j’ai pu optimiser considérablement le rendu vidéo. En fait, j’ai probablement accéléré le moteur par un facteur de deux, au point qu’il semble jouable sur du vrai matériel 030. Je suis assez confiant dans le fait que ce jeu tournera à une vitesse proche de celle de l’arcade sur un 040 à 30fps.
– Non seulement cela, mais ce portage contient de nombreuses petites corrections de bugs par rapport au jeu original, et il est complet. Cela inclut les séquences de fin animées, les effets d’ombre translucide, les fondus de palette, l’écran de la carte routière, l’écran des meilleurs surclasseurs et presque tous les moindres détails recréés avec amour. Bien sûr, le jeu devrait être identique à l’original, donc les exploits du gameplay hardcore comme le gear gacha et le démarrage turbo boost fonctionneront.
– J’ai dû faire des compromis dans certains domaines. Mais j’espère que vous serez d’accord avec moi pour dire que ce jeu aura l’air, jouera et surtout se sentira comme il faut lorsqu’il sortira. La version familiale la plus proche en termes de qualité de l’époque est celle de la Sega Saturn, qui n’a été disponible qu’en 1996, sur un matériel de qualité supérieure.
– Bien que j’aie franchi une étape importante, je n’ai pas encore terminé. Je dois travailler sur l’audio et la musique. Peut-être composerai-je la bande-son moi-même, ou peut-être regarderai-je ce qui existe déjà. Une fois que j’aurai entendu le crissement des pneus et les ouvertures de Passing Breeze, la construction sera disponible gratuitement.
– La question qui se pose est la suivante : pourquoi s’embêter avec tout cela ? De nos jours, n’importe qui peut jouer parfaitement à OutRun sur Mame, sur une Nintendo Switch ou en utilisant Cannonball. Pourquoi passer d’innombrables heures sur ce qui est en fait un projet de vanité pour mon propre amusement ?
– Pour moi, la partie intéressante de ces projets est de surmonter des défis techniques apparemment impossibles et de concevoir des solutions créatives folles – certaines d’entre elles me sont apparues en rêve, ce qui est un peu inquiétant ! Je suppose que c’est le fait de terminer quelque chose que l’on n’aurait jamais cru possible.
– C’est la résolution des problèmes qui est finalement la partie addictive et moins le résultat final. C’est pourquoi je cherche à approfondir chaque aspect du jeu avec une série de documentaires YouTube accompagnés d’un exemple de code source.

Vidéo WIP (27/02/2025) : WinUAE puis Amiga 68030 (4 mn 20 s)

https://youtu.be/dcVYEUC2gNM

[Staff Aladin Level 25Messages : 15862]

Le jeu est entré en phase de beta test

Reassembler: « J’ai presque fini de le porter ! J’ai été ravi de constater qu’il tourne beaucoup plus vite sur la carte 030 Blizzard III que sur la Terriblefire 030. »

[Staff Aladin Level 25Messages : 15862]

Le jeu est disponible (v0.9)

[Staff Aladin Level 25Messages : 15862]

Slave WHDL par JOTD.

/Mise à jour du slave 19/07/2025

[Pseudaxos Level 3Messages : 85]

Ne fonctionne pas avec la V4 icedrake (il n’y a que des dégradés de couleurs).

- Amiga 1200 + IceDrake V4 + CoffinOS R64
- Amiga 1200 + Pistorm avec CM4 en cours de montage
- Raspberry Pi400 (X2) + AmigaOS 3.9
- RaspberryPi500 + Pimiga5

[Staff Aladin Level 25Messages : 15862]

Pseudaxos wrote:

Ne fonctionne pas avec la V4 icedrake (il n’y a que des dégradés de couleurs).

C’est ce qui a été rapporté dans le topic sur EAB. Tu devras attendre le correctif. (j’espère rapidement, pour que tu puisses profiter de cet excellent portage).

[Pseudaxos Level 3Messages : 85]

Oui, ça a l’air très bien fait.

Par contre, j’ai un portage prévu pour la V4 qui est exactement comme l’arcade disponible. Je ne comprends pas la différence avec le portage actuel ? J’ai quand même grand hâte de le tester.

- Amiga 1200 + IceDrake V4 + CoffinOS R64
- Amiga 1200 + Pistorm avec CM4 en cours de montage
- Raspberry Pi400 (X2) + AmigaOS 3.9
- RaspberryPi500 + Pimiga5

[Staff Aladin Level 25Messages : 15862]

A chaque Amiga, son OutRun :)

Celui que tu parles, cannonball (du même auteur), est pour amiga RTG 060+ (il ne lui manque que les ombres et les SFX. Sacrifice de la version PC SDL pour pouvoir être jouable sur Amiga). Ce nouveau portage est pour Amiga AGA 030+. Le prochain, celui d’Agermose, sera pour Amiga AGA (020). Et l’ancien portage d’Us Gold de 1988 est pour Amiga OCS :)

[Pseudaxos Level 3Messages : 85]

Ah ok, c’est plus clair merci.

- Amiga 1200 + IceDrake V4 + CoffinOS R64
- Amiga 1200 + Pistorm avec CM4 en cours de montage
- Raspberry Pi400 (X2) + AmigaOS 3.9
- RaspberryPi500 + Pimiga5

[Staff Aladin Level 25Messages : 15862]

Mise à jour v0.9.1 (28/08/2025)

https://reassembler68k.itch.io/outrun-amiga-edition/devlog/1018884/outrun-amiga-edition-091-released

Changelog:

– Une version distincte pour les processeurs 68040+ . Elle offre des optimisations spécifiques pour les processeurs 040 et supérieurs. Elle peut fonctionner plus rapidement que la version 030 sur ces systèmes, mais si vous rencontrez des problèmes, restez sur la version 030. Il est difficile de dire à quel point elle est plus rapide, car cela dépend d’un certain nombre de facteurs : la vitesse du processeur, la vitesse de la RAM (puce et vitesse), ce que fait le moteur du jeu à ce moment-là, etc.

– Prise en charge de la puce personnalisée Akiko du CD32. Vous pouvez en savoir plus sur cette puce ici, mais en bref, elle facilite la conversion des graphismes de type « chunky » en graphismes « planar ». Malheureusement, en raison de l’architecture matérielle du CD32, l’augmentation des performances n’est pas aussi impressionnante qu’elle pourrait l’être. Mais… pour ceux d’entre vous qui possèdent un accélérateur 030 classique, le jeu sera désormais plus rapide sur le CD32.

– Manettes à un seul bouton ! (Reassembler n’est pas fan des manettes à un seul bouton. Mais il a suscité une petite polémique en refusant de les prendre en charge auparavant. Donc, dans l’intérêt de la diplomatie Amiga entre nous, amigos, vous pouvez désormais dépoussiérer votre bonne vieille manette des années 80. Je recommanderais tout de même un pad à 2/3 boutons ou le clavier, mais bon, qui suis-je pour vous dire comment profiter de la vie ?)

– Configuration. Il existe un fichier config.txt que vous pouvez modifier pour définir les paramètres par défaut. Ceux-ci peuvent toujours être modifiés dans le menu frontal.

– Améliorations des performances. J’ai passé un temps fou à essayer d’optimiser les performances du moteur pour ceux d’entre nous (comme moi) qui utilisent un processeur 030. Après plusieurs jours d’optimisation, les gains sont au mieux marginaux. Cela dit, certaines parties du jeu fonctionnent désormais un peu plus rapidement. Ne vous attendez pas à des miracles sur ces systèmes aux spécifications minimales, le véritable goulot d’étranglement étant la quantité considérable de données traitées par image plutôt qu’une faille flagrante dans le code.

– Autres corrections mineures. Plusieurs corrections mineures ont été apportées, notamment la résolution d’un crash qui pouvait se produire sur certaines configurations pendant la route Autobahn de l’étape 5.

/ Le slave WHDL devrait bientôt être mis à jour. Mais le slave d’origine de JOTD est déjà compatible avec les nouveaux exécutables 030/040. Vous n’avez qu’à remplacer le exe d’OutRun. Ou utiliser le WHDLG mis à jour.

[Staff Aladin Level 25Messages : 15862]

Mise à jour v0.9.2 (21/09/2025)

https://reassembler68k.itch.io/outrun-amiga-edition/devlog/1037487/outrun-amiga-edition-092-released

Changelog:

1/ Nouvelles fonctionnalités : des options de jeu déjantées qui n’étaient pas disponibles dans la version arcade !

Vous pouvez les activer ou les désactiver dans le fichier config.txt ou dans le menu SETTINGS -> GAMEPLAY du jeu. Elles sont désactivées par défaut.

– Rolling Stop : ralentissez progressivement jusqu’à l’arrêt complet lorsque le temps est écoulé… (comme demandé dans les commentaires ici sur itch)
– Vitesse turbo : la vitesse maximale est augmentée d’environ 50 km/h !
– Pneus tout-terrain : roulez hors route sans ralentir !
– Pneus adhérents : prenez les virages très facilement !
– Autos tamponneuses : percutez les autres véhicules avec moins d’impact !

Inutile de dire qu’il n’est pas recommandé d’activer toutes ces options en même temps, mais les combiner peut être très amusant.

2/ Nouvelle fonctionnalité : enregistrement des meilleurs scores

Oui, vos meilleurs scores seront enfin enregistrés ! Vous devrez quitter le jeu correctement depuis le menu principal pour que vos scores soient enregistrés sur le disque. Si vous souhaitez réinitialiser vos meilleurs scores à tout moment, supprimez le fichier hiscores.bin.

(Si vous n’aimez pas l’idée que le jeu enregistre des données sur le disque, cette fonctionnalité peut être désactivée dans le fichier de configuration config.txt.)

3/ Correction d’un bug : problème de dérive vers la gauche

Il s’agit d’un bug dans le code source original de l’arcade que j’avais oublié. La séquence d’actions suivante provoquait une dérive vers la gauche :
– Roulez un peu dans le niveau.
– Arrêtez-vous.
– Maintenez le volant vers la gauche pendant un certain temps, puis laissez-le se centrer.
– Accélérez.
– La voiture dévie vers la gauche, même si le volant est désormais centré.

4/ Correction d’un bug : problème mineur d’affichage des routes

Un petit problème visuel, introduit dans la version 0.9.1 et passé inaperçu, a été corrigé.

[Auteur]

Réponses