Prenez un succès incontournable du jeu vidéo des années '90 (allez, 1989): Prince of Persia. Prenez un briscard de la programmation sur une machine mythique et merveilleuse: MrSid et son C64. Arriva ce qui devait arriver: après la SNES, le PC, l'Amiga, les téléphones Java et l'iPod et la calculatrice HP48, le titre à succès de l'Apple II arrive sur Commodore 64.
Au départ, je pense à une ancienne version qui aurait refait surface, mais non: MrSid refait bel et bien le jeu entre 2008 et 2011 -- chacun son hobby. L'Apple II et le C64 tournent avec le même processeur, le MOS 6502. C'est énorme. Ca signifie qu'en prenant simplement le "binaire" de PoP sur Apple II, une partie du jeu "tournerait" directement sur C64 ... toute la "logique" du jeu, en fait. Les mécanismes graphiques et sonores des deux machines sont totalement différentes, en revanche. Et à relire pour la 3eme fois le peu d'information que je trouve sur le graphisme de l'Apple II, j'aime autant dire que cette différence est importante. La machine de Steve Wozniak travaille essentiellement avec un gros 'framebuffer' (une image bitmap unique, remise à jour à chaque étape du jeu) alors que le C64 a un hardware inspiré des consoles et machine d'arcade de l'époque: caractères reprogrammables et sprites hardware. Le moteur de rendu devra donc être intégralement refait.
Well, if you read English, you can simply head to MrSid's post "Why would anyone want to port Prince of Persia on the C64". I guess he'll explain his reasons and give you crunchy details and videos much better than I could ever do ;)
La tâche à laquelle MrSid s'attelle donc, c'est de reprendre le binaire de la version Apple II, le désassembler et le cartographier. Il s'est évidemment mis en chasse du code source d'origine, qui a été perdu corps et bien ... eh oui, on travaillait sur floppy à l'époque >_<. Ce qui a survécu, en revanche, et que MrSid exploite au maximum, c'est la "documentation" du jeu. Quelques schémas qui expliquent les grandes lignes du moteur graphique, la liste des animations, l'organisation en mémoire des objets, leur position, les animations, et tout ça. Ca fait toute la différence! Au milieu de l'inconnu, il y a maintenant des points de repère qui permettent de comprendre le code parfois curieux de Jordan Mechner. Code-trampoline, liste d'instructions ... Si tout ça vous parle, ne vous en tenez pas à ce que je vous raconte: allez lire le blog dans lequel MrSid raconte en détail sa réalisation étape par étape... vidéos à l'appui.
Au fait, MrSid, c'était aussi le portage de Giana Sister (version C64) et International Karate sur DS. ^_^
(pour le blog Commodore Users Charleroi
this is the right place for quickstuff
héhé terrible,... comme quoi il a travaillé dans les deux sens !
ReplyDeleteallé tu postes cela aussi sur C64Charleroi :)
L'implémentation des commandes PLOT, HGLIN et autres dans AppleSoft BASIC (le BASIC Microsoft pour l'Apple II) peut nous donner une idée du fonctionnement du mode grapique sur cette machine.
ReplyDeleteEn plus de son mode "bitmap", il avait un mode "texte" à 40 colonnes et un mode "LOGO" avec du bitmap sur presque tout l'écran, sauf les 4 dernières lignes en texte. Contrairement à pas mal de machine, le "split screen" est ici câblé directement et le split ne peut pas être déplacé.
contrairement au PC, la plupart des "switches softwares" de l'AppleII occupent 1 byte dans l'espace d'adressage et sont modifiés aussi bien par un READ que par un WRITE. Donc "LDA sw.hires" possède effectivement un effet de bord. Il existe des addresses spécifiques pour "lire" certains des switches, p.ex. RDHIRES, ou des addresses différentes pour "activer" ou "désactiver" certaines fonctions (SETTXT / CLRTXT)
ReplyDeleteVoir aussi la cartographie de la mémoire de l'Apple II
ReplyDeleteet maintenant, attention: la version NES
ReplyDelete