Out Run Arcade AGA (Reassembler) en développement

Out Run Arcade (Reassembler)

Portage en cours 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 (Reassembler)

 

 

Configuration requise:
AGA
68030
8 Mo de Fast Ram

 

 

Téléchargement (test engine 03/2024): HDD (EAB) / WHDLG

 

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://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 : 257]

Bon courage pour ce portage, on croise les doigts…

[Staff Aladin Level 25Messages : 15178]

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

 

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

 

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

[Staff Aladin Level 25Messages : 15178]

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

[Staff Aladin Level 25Messages : 15178]

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.

 

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

 

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

[Staff Aladin Level 25Messages : 15178]

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)

[Auteur]

Réponses