La Place des Développeurs asmsx par un noob #1: creer et afficher des sprites... ou tentative de creation d'un jeu en asm
Voilà, ça n'a pas l'ambition d'être un vrai tuto sur l'assembleur,( même si la démo s'appelle tuto 
) mais plutôt la description de ce que je sais (ou essaie de ) faire avec asmsx. ça lancera le débat sur le sujet et permettra d'apprendre des trucs (un peu comme sur les posts d'Igal 
) et peut être de réaliser un vrai jeu à l'arrivée...
Il y aura plusieurs posts pour chaque étape...
Pour créer des sprite le plus pratique que j'ai trouvé c'est TinySpritede janone. Il permet de sortir directement les données dans un fichier texte (ici:data_sprites.asm) pour être exploité par asmsx
il suffira d'intégrer le fichier dans le programme par la ligne:
Je passe sur les initialisations des modes écran etc... Pour le reste les commentaires suffisent...
) mais plutôt la description de ce que je sais (ou essaie de ) faire avec asmsx. ça lancera le débat sur le sujet et permettra d'apprendre des trucs (un peu comme sur les posts d'Igal ) et peut être de réaliser un vrai jeu à l'arrivée...Il y aura plusieurs posts pour chaque étape...
Etape1: Création de sprites
Pour créer des sprite le plus pratique que j'ai trouvé c'est TinySpritede janone. Il permet de sortir directement les données dans un fichier texte (ici:data_sprites.asm) pour être exploité par asmsx
il suffira d'intégrer le fichier dans le programme par la ligne:
Code ASM :
.INCLUDE"data_sprites.asm"
Etape2: Affichage de sprites
Je passe sur les initialisations des modes écran etc... Pour le reste les commentaires suffisent...
Code ASM :
;------------------------------------------------ ; Initialisation ;------------------------------------------------ .bios .page 2 .rom .start DEBUT ; ;------------------------------------------------ ; Constantes VRAM ;------------------------------------------------ CHRTBL equ 0000h NAMTBL equ 1800h CLRTBL equ 2000h SPRTBL equ 3800h SPRATR equ 1b00h ;------------------------------------------------ DEBUT: ; sélection screen call DISSCR ; réglage COLOR 11,1,1 ld hl,0f3e9h ld [hl],15 inc hl ld [hl],12 inc hl ld [hl],1 ; SCREEN 2 call INIGRP ; SCREEN ,2 ld bc,06201h call WRTVDP ; Definition des formes sprites ld hl,SPR_PATRON ld de,SPRTBL; + 32 ld bc,8*32 call LDIRVM ; Definition des attributs sprites ld hl,ATT_SPRITES ld de,SPRATR ld bc,8*4 call LDIRVM ; Boucle for the future... LOOP: jpLOOP ; ;---------------------------------------------------------- ; Données ;---------------------------------------------------------- ; ; Patron des sprites SPR_PATRON: .INCLUDE"data_sprites.asm" ; ; Attribut sprites ; ; X, Y, N°, Couleur ATT_SPRITES: db80,80,0,1 db80,80,4,11 db80,160,8,1 db80,160,12,11 db160,80,16,1 db160,80,20,9 db160,160,24,1 db160,160,28,9
Episode suivant
Le MSXien le plus à l'ouest
... ou presque 
Houla c'est excellent ça
Un poil plus d'explications et se serait parfait.
Un poil plus d'explications et se serait parfait.
Fabf :
Houla c'est excellent ça
Un poil plus d'explications et se serait parfait.
Un poil plus d'explications et se serait parfait.
Ce post ne se veut pas un tuto sur l'asm, alors pensez à aller consulter les livres tappés par notre Granced dans la bibliothèque du village.
Toutefois:
call WRTVDP: il écrit la valeur b (&h62) dans le registre c (1), ici ça configure entre autre la taille des sprites.
call LDIRVM: envoie un bloc de mémoire de taille bc(ex.:8(nb sprites) * 32 (nb d'octets par sprites) )d' un emplacement mémoire hl (ex.:SPR_PATRON(patrons de sprites définis par tinysprite)) vers la VRAM à l'emplacement de(ex.:SPRTBL (la table des patrons des sprites!))
Par contre pour les attributs de sprite je suis obligé de mettre N°4 pour afficher le sprite 1, 8 pour le 2, etc. c'est du aux sprite 16x16 ?
Le MSXien le plus à l'ouest
... ou presque
Merci MSXosaure, j'en demandais pas plus
Rien de tel qu'un apprentissage par l'exemple.
Tu compte nous en présenter d'autres ou continuer à rajouter sur celui là ?
Rien de tel qu'un apprentissage par l'exemple.
Tu compte nous en présenter d'autres ou continuer à rajouter sur celui là ?
GDX :
Je n'ai jamais utilisé asMSX. Est-il est obligé d'écrire "ld [hl],15" au lieu de "ld (hl),15" ?
Oui, parce que asMSX utilise les parenthèses dans les évaluations d'expressions numériques et/ou de fonctions mathématiques.
Cela fait 6 ans que j'utilise asMSX et cela ne m'a jamais posé de problèmes, on s'y habitue très rapidement.
C'est un très bon cross-assembleur et il est optimisé pour le MSX (macros spéciales, gestion des mappers, ...).
Je lui trouve juste 2 défauts : l'absence de macro personnelles, et un bug qui apparait de temps en temps sur la définition des étiquettes (mais qui se résout facilement)
MSX1: Daewoo DPC-200 / Yamaha CX5M
MSX2: Sony HB-F9P
MSXVR
Vidéo: V9990 (GFX-9)
Audio: MSX-Music (FM-PAC) / MSX-Audio (Audiowave) / OPL4 (Monster Sound FM Blaster) / OPNB (Neotron)
GDX :
Le problème de TinySprite, c'est qu'il utilise une particularité des Sprites MSX2 qui bogue trop en Basic.
C'est quoi la fameuse particularité des sprites MSX2 qui bogue?
TurboR GT (1Mo), CANON V20! ( en kit, modif 2+ en cours)
Pas encore retrouvés: V9990, Grafx9000, SUNRISE IDE 2x CF, SUNRISE MOONSOUND, FM PAC, MUSIC MODULE, NMS8280, SD SNATCHER,...
Fabf :
Merci MSXosaure, j'en demandais pas plus
Rien de tel qu'un apprentissage par l'exemple.
Tu compte nous en présenter d'autres ou continuer à rajouter sur celui là ?
Rien de tel qu'un apprentissage par l'exemple.
Tu compte nous en présenter d'autres ou continuer à rajouter sur celui là ?
Je compte faire d'autres posts pour éviter que les infos ne se noient dans le flots de réponses/interventions.
Je vais aussi essayer de ne pas trop découper pour éviter de faire trop de nouveaux sujets...
Le MSXien le plus à l'ouest
... ou presque
Petite mise à jour, j'ai perdu un peu de temps à créer d'autres sprites: haut-gauche-droite-bas-tir-plateforme-ennemi. Comme quoi avant de se lancer dans un projet, il faut savoir ou on va.
Je joins le zip contenant les fichiers du programme, des datas des sprites et de la rom:tuto_1.zip
Bon bah c'est bien beau tout ça mais il va falloir que j'essaie de faire bouger ce petit personnage...
Je joins le zip contenant les fichiers du programme, des datas des sprites et de la rom:tuto_1.zip
Bon bah c'est bien beau tout ça mais il va falloir que j'essaie de faire bouger ce petit personnage...
Le MSXien le plus à l'ouest
... ou presque
GDX :
Le problème de TinySprite, c'est qu'il utilise une particularité des Sprites MSX2 qui bogue trop en Basic.
Heu.... je vais faire mon empêcheur de tourner en rond, mais GDX, tu ne nous as toujours pas expliqué quel particularité MSX2 est utilisé par TyniSprite?
TurboR GT (1Mo), CANON V20! ( en kit, modif 2+ en cours)
Pas encore retrouvés: V9990, Grafx9000, SUNRISE IDE 2x CF, SUNRISE MOONSOUND, FM PAC, MUSIC MODULE, NMS8280, SD SNATCHER,...
En basic, dans les modes autres que MSX1, l'instruction PUTSPRITE considère que les sprites liés par la fonction logique des couleurs font un seul Sprite. Ça pourrait être sympa comme fonction si au delà d'un certain nombre de sprite, ça ne buggait pas complètement.
Je ne vois pas ce qui peut être optimisé à part les macros. Un assembleur ne fait qu'assembler les codes machines. C'est au programmeur d'optimiser le programme. Ce n'est pas comme les autres langages. Et puis que veux tu dire par macro personnelles? Edité par GDX Le 14/10/2014 à 09h37
Metalion :
C'est un très bon cross-assembleur et il est optimisé pour le MSX (macros spéciales, gestion des mappers, ...).
Je lui trouve juste 2 défauts : l'absence de macro personnelles, et un bug qui apparait de temps en temps sur la définition des étiquettes (mais qui se résout facilement)
Je lui trouve juste 2 défauts : l'absence de macro personnelles, et un bug qui apparait de temps en temps sur la définition des étiquettes (mais qui se résout facilement)
Je ne vois pas ce qui peut être optimisé à part les macros. Un assembleur ne fait qu'assembler les codes machines. C'est au programmeur d'optimiser le programme. Ce n'est pas comme les autres langages. Et puis que veux tu dire par macro personnelles? Edité par GDX Le 14/10/2014 à 09h37
GDX :
Je ne vois pas ce qui peut être optimisé à part les macros. Un assembleur ne fait qu'assembler les codes machines. C'est au programmeur d'optimiser le programme. Ce n'est pas comme les autres langages. Et puis que veux tu dire par macro personnelles?
Metalion :
C'est un très bon cross-assembleur et il est optimisé pour le MSX (macros spéciales, gestion des mappers, ...).
Je lui trouve juste 2 défauts : l'absence de macro personnelles, et un bug qui apparait de temps en temps sur la définition des étiquettes (mais qui se résout facilement)
Je lui trouve juste 2 défauts : l'absence de macro personnelles, et un bug qui apparait de temps en temps sur la définition des étiquettes (mais qui se résout facilement)
Je ne vois pas ce qui peut être optimisé à part les macros. Un assembleur ne fait qu'assembler les codes machines. C'est au programmeur d'optimiser le programme. Ce n'est pas comme les autres langages. Et puis que veux tu dire par macro personnelles?
GDX, je pense qu'avec un peu de volonté, tu aurais pu faire encore plus cassant comme réponse ...
Mais bon, on a l'habitude ... Soit.
Je ne parle pas d'optimisation du code, bien évidemment. Je veux simplement dire que ce cross-assembleur contient des macros spéciales pour le MSX pour gérer plus facilement les ROMs, les MegaROMs, les mappers, ... Il contient aussi en pré-défini tous les noms des routines du BIOS sur les 4 générations de machines. Bref, il est orienté MSX dès le départ.
Et quand je parle de macros personnelles, je parle de la possibilité offerte par certains assembleurs de définir une macro, c'est à dire d'affecter à un nom plusieurs lignes de code.
MSX1: Daewoo DPC-200 / Yamaha CX5M
MSX2: Sony HB-F9P
MSXVR
Vidéo: V9990 (GFX-9)
Audio: MSX-Music (FM-PAC) / MSX-Audio (Audiowave) / OPL4 (Monster Sound FM Blaster) / OPNB (Neotron)
Répondre
Sujet verrouillé, vous ne pouvez pas poster de message