> forums jeux > xenon-1
13 posts 2 pages [ Goto page: 1 2 ]
Zarach (admin) Da Vinci code	Posted Tuesday, February 19th 2008 10:44PM
110 posts	Waou ! Super impressionnant Tu as passé combien de temps pour refaire Xenon-1 ? les voyages dans le passé peuvent provoquer un paradoxe temporel dans le continuum espace-temps entraînant la suppression de l'univers
maximus (admin) -> Tasawad *@!!§ !	Posted Wednesday, February 20th 2008 7:17AM
440 posts	Alors là Respect maitre j'ai compris 1 mot sur 3 (je progresse) mais quel effort !! tu dois être un fan de ce jeu pour deployer une telle énergie en tout cas une fois terminé, dis le nous, on pourrait integrer ton adaptation dans le Test avec tes commentaires (si tu le souhaites) bien ja peux retourner taper mon printf("hello world"); back in 1983
jotd Oric-1 48 KB	Posted Wednesday, February 20th 2008 9:59AM
8 posts	C'était pas si long et difficile. Justement, cette technique permet d'aller vite et d'avoir du natif. Pour info, j'ai refait Gods (Amiga/Atari ST) sans le code, et j'ai mis quasiment 1 an pour le terminer. Ca c'est être fan :) En revanche, Xenon 1 j'ai mis moins d'un mois et je suis sûr que le jeu est identique. Donc ça va bon rapport qualité prix.
Author: firstname or nickname...	<table cellspacing=1 cellPadding=3 width="90%" align=center border=0><tr><td><b>jotd a écrit:</b></td></tr><tr><td><table cellpadding=3 cellspacing=0 border=1><tr bgcolor=#FFFFFF><td>Bon c'est assez technique, mais je veux bien expliquer.<br /> <br /> Tout d'abord, le but n'est pas d'émuler fidèlement le jeu au pixel et au son près, les émulateurs font ça très bien. Non, l'idée est d'avoir le même "gameplay" en récupérant les algorithmes (pour Xenon 1 le code des oiseaux est vraiment pas mal, je ne sais pas si j'arriverais à faire pareil sans avoir le code)<br /> <br /> - je me suis codé une API pour certains appels BASIC (text, hires, poke, peek). C'est tout ce qu'il faut pour Xenon.<br /> <br /> - j'ai piqué la routine de refresh écran de MESS quasiment tel quel en adaptant à SDL<br /> <br /> - je me suis codé une API pour les instructions assembleur et les modes d'adressage. L'API gère une zone de mémoire à la manière d'un émulateur.<br /> <br /> - je prends le fichier .TAP et j'extrais le code BASIC, que je "convertis" en C. La conversion est pourrie et il faut quasiment tout reprendre, mais ça fait le + gros (ça change par exemple les mots clé REPEAT UNTIL en do while, ça met des accolades, bref sur un programme de 20 lignes ça va, sinon je vais devoir l'améliorer<br /> L'alternative c'est de porter directement le code BASIC en C.<br /> <br /> - à partir de ce même fichier .TAP, je retrouve l'offset de départ du code machine (planqué dans la zone basic, en $700) et je le désassemble à l'aide d'un programme sympa: ad qui permet de marquer des zones comme "data" c'est à dire de ne pas dumper n'importe quoi quand il s'agit en fait de données.<br /> <br /> - en parallèle, avec une petite moulinette, je génère un gros fichier .h avec le contenu de la mémoire en const char *memory = { ....<br />  Je peux directement bidouiller ce fichier en texte pour adapter les messages, etc... Ce tableau est recopié dans la mémoire utilisé par l'API assembleur et BASIC (poke, peek).<br /> <br /> - à partir du fichier .asm dont le code a été désassemblé (on se fout des data), je passe une moulinette en awk de ma composition qui convertit en syntaxe C:<br />     lda #$02<br />     sta $04<br /> devient<br />     lda_imm(0x2);<br />     sta(0x4);<br /> <br /> - ensuite, je laisse tomber le fichier .asm (je le conserve en référence au cas où je merde en modifiant le .c), et je commence à retoucher le .c<br /> <br /> Il y a pas mal d'approximations: Je me fous des problèmes de zero page ou absolute par exemple, je ne peux pas gérer les jump indirects ni le code auto-modifié, donc il faut comprendre ces parties de code et les refaire avec un bon switch / case des familles.<br /> Egalement, on ne peut pas gérer les JSR autrement qu'en faisant des subroutines (faites automatiquement par le script quand il rencontre RTS), et les jmp, beq, bmi, etc... sont gérés par le goto du C. Donc on est super emmerdés quand on veut faire un goto hors de la procédure courante (le C a un contexte de variables donc on ne peut pas le faire). C'est là que c'est un peu chiant et sujet à erreurs: il faut déplacer/découper/copier/coller le code qui pose problème à la main.<br /> C'est cette opération qui est la plus manuelle. Pour Xenon 1 c'était pas trop chiant. Pour Zorgon c'était plus lourd (et j'ai introduit des bugs qu'il faut encore corriger).<br /> <br /> - Ensuite, il faut virer toutes les boucles actives (dex dex dex bne loop) qui tournent pour rien et à fond la caisse (pas de régulation donc c'est hyper rapide et donc injouable), et remplacer par des timers. Pas trop dur. Mais ça oblige à identifier toutes les phases du jeu.<br /> <br /> - Il faut aussi patcher le clavier pour remplacer par la lecture clavier/joystick SDL, car je ne simule pas le VIA (sauf le timer 1 pour le random).<br /> <br /> - le son n'est pas non plus émulé. Je vire donc les routines de son et je remplace par des samples rigolos. J'ajoute parfois des sons là où il n'y en avait pas.<br /> <br /> En fait à partir du moment où le jeu tourne, on fait ce qu'on veut question son et algorithme. On n'est pas du tout enfermé comme avec un émulateur, on a un code C pourri, mais un code C.<br /> Par exemple, j'ai corrigé 2 bugs dans Xenon 1: le bug qui fait que quand on efface son nom du hiscore, les vieilles lettres restent si le nouveau nom est + long, et surtout le fait de ne pas pouvoir appuyer 2 touches en même temps (du coup le jeu est + facile...)<br /> <br /> Au final, on a un jeu qui est en C "spaghetti" que l'on peut améliorer par bouts (refactoring, renommage de variables et de procédures), profiler, et laisser les parties où on comprend rien de côté sans chercher. ça marche, on est toujours à temps d'investiguer sur telle ou telle partie pour améliorer les perfos ou l'ergonomie.<br /> <br /> En revanche, coté graphisme, c'est plus difficile. J'ai un mode "enhanced" où je ne dessine pas les pixels noirs par exemple, et j'affiche une super image 24 bits en fond avant de dessiner le contenu de l'écran Oric: résultat ça améliore pas mal les graphismes un peu vieillots en ajoutant pas mal de couleur.<br /> Si on arrive à localiser les ennemis ou le vaisseau, on peut aussi "surimprimer" un graphisme différent en plus. Je n'ai pas fait ça sur Xenon, mais j'aurais pu. Question de temps. Et puis c'est assez beau comme ça :)<br /></td></tr></table></td></tr></table><br>

13 posts 2 pages [ Goto page: 1 2 ]
> forums jeux > xenon-1