La Place des Développeurs Projet Ambidex
Chose promise, chose due, voici des questions en vrac pour mener à bien mon projet Ambidex.
Petite description du jeu :
- Jeu de réflexion et de plateforme 2d ou le joueur joue 2 personnages plus ou moins en même temps.
- Les niveaux sont fixes (on passe d'un niveau à l'autre en arriver à la sortie)
- Les décors serait fait à partir de tiles
- Les personnages (8 max par niveau), on une 10ène d'actions possibles
- Certains objets sont interactifs dans le décors (porte, bouton au sol, etc.) + objet (clef, etc.)
Pour le dev, je pars sur du C + ASM.
Voila, tout d'abord, pour le mode vidéo, je pensai au mode 8 (256x212, 256 couleurs et spirites mode 2).
Est-ce un choix réaliste ?
Dans ce mode, on a droit qu'à 2 screens, ce qui veut dire qu'on devra recréer le décors à chaque frame ; est-ce réalisable ?
(ou faire des grosses copies depuis la RAM)
Ou trouver des infos sur les sprites ? Si j'ai bien compris, en mode 2, on peut avoir des sprites de 16 couleurs ; est-ce vraiment compatible avec le mode 8 qui lui est non paletté !?
D'ailleurs, la seul doc que j'ai sur le V9938 est un scan ; pas pratique pour la recherche. Si qq'un a une version numérique, ça m'intéresse grandement.
Sinon, comment fait t'on pour "charger" une image depuis une ROM. Je suppose qu'il va falloir que je créé un convertisseur bitmap -> fichier binaire et l'inclure directement dans mon code, non ? Comme je suis en C, je pourrai facilement me faire un convertisseur pour générer des .h à inclure dans mon code.
En gros, je maitrise le C, je commence à avoir des notions de Z80, mais pour ce qui est de l'architecture de MSX, je suis encore un peu dans le vague.
Tous les conseils sont les bienvenus.
Le but (c'est important les buts
) serait d'inscrire le jeu pour le MSXDev11 (hors catégorie puisse que ce serait un jeu MSX2). L'espoir fait vivre. 
Edité par
aoineko
Le 11/01/2011 à 02h02
Petite description du jeu :
- Jeu de réflexion et de plateforme 2d ou le joueur joue 2 personnages plus ou moins en même temps.
- Les niveaux sont fixes (on passe d'un niveau à l'autre en arriver à la sortie)
- Les décors serait fait à partir de tiles
- Les personnages (8 max par niveau), on une 10ène d'actions possibles
- Certains objets sont interactifs dans le décors (porte, bouton au sol, etc.) + objet (clef, etc.)
Pour le dev, je pars sur du C + ASM.
Voila, tout d'abord, pour le mode vidéo, je pensai au mode 8 (256x212, 256 couleurs et spirites mode 2).
Est-ce un choix réaliste ?
Dans ce mode, on a droit qu'à 2 screens, ce qui veut dire qu'on devra recréer le décors à chaque frame ; est-ce réalisable ?
(ou faire des grosses copies depuis la RAM)
Ou trouver des infos sur les sprites ? Si j'ai bien compris, en mode 2, on peut avoir des sprites de 16 couleurs ; est-ce vraiment compatible avec le mode 8 qui lui est non paletté !?
D'ailleurs, la seul doc que j'ai sur le V9938 est un scan ; pas pratique pour la recherche. Si qq'un a une version numérique, ça m'intéresse grandement.
Sinon, comment fait t'on pour "charger" une image depuis une ROM. Je suppose qu'il va falloir que je créé un convertisseur bitmap -> fichier binaire et l'inclure directement dans mon code, non ? Comme je suis en C, je pourrai facilement me faire un convertisseur pour générer des .h à inclure dans mon code.
En gros, je maitrise le C, je commence à avoir des notions de Z80, mais pour ce qui est de l'architecture de MSX, je suis encore un peu dans le vague.
Tous les conseils sont les bienvenus.
Le but (c'est important les buts
) serait d'inscrire le jeu pour le MSXDev11 (hors catégorie puisse que ce serait un jeu MSX2). L'espoir fait vivre.
Edité par
aoineko
Le 11/01/2011 à 02h02
On est toujours ignorant avant de savoir.
Salut Aoineko,
C'est marrant que tu parles d'un jeu de plateforme et de réflexion en coopération car justement, je suis en train d'en créer un.
Dans un précédent post je présentais ce que j'avais déjà fait avec une rom.
Tout le développement est en assembleur avec asMSX.
Les graphiques MSX (pattern et la carte) ont été créé avec un outils PC développé par mes soins.
Pour l'instant, les sprites ont été créés à la main et ceux dans la rom ne sont pas la version finale.
Mon jeu était plutot orienté action plateforme avec un système d'interrupteurs colorés permettant à un perso de faire avancer l'autre... Donc casse-tête.
Dans l'évolution, un des perso pourra bouger des caisses et l'autres les détruire. Et des boss à éclater.
Il y a peut être moyen de faire quelques choses ?
C'est marrant que tu parles d'un jeu de plateforme et de réflexion en coopération car justement, je suis en train d'en créer un.
Dans un précédent post je présentais ce que j'avais déjà fait avec une rom.
Tout le développement est en assembleur avec asMSX.
Les graphiques MSX (pattern et la carte) ont été créé avec un outils PC développé par mes soins.
Pour l'instant, les sprites ont été créés à la main et ceux dans la rom ne sont pas la version finale.
Mon jeu était plutot orienté action plateforme avec un système d'interrupteurs colorés permettant à un perso de faire avancer l'autre... Donc casse-tête.
Dans l'évolution, un des perso pourra bouger des caisses et l'autres les détruire. Et des boss à éclater.
Il y a peut être moyen de faire quelques choses ?
RibbSayan :
Salut Aoineko,
C'est marrant que tu parles d'un jeu de plateforme et de réflexion en coopération car justement, je suis en train d'en créer un.
Dans un précédent post je présentais ce que j'avais déjà fait avec une rom.
Tout le développement est en assembleur avec asMSX.
Les graphiques MSX (pattern et la carte) ont été créé avec un outils PC développé par mes soins.
Pour l'instant, les sprites ont été créés à la main et ceux dans la rom ne sont pas la version finale.
Mon jeu était plutot orienté action plateforme avec un système d'interrupteurs colorés permettant à un perso de faire avancer l'autre... Donc casse-tête.
Dans l'évolution, un des perso pourra bouger des caisses et l'autres les détruire. Et des boss à éclater.
Il y a peut être moyen de faire quelques choses ?
C'est marrant que tu parles d'un jeu de plateforme et de réflexion en coopération car justement, je suis en train d'en créer un.
Dans un précédent post je présentais ce que j'avais déjà fait avec une rom.
Tout le développement est en assembleur avec asMSX.
Les graphiques MSX (pattern et la carte) ont été créé avec un outils PC développé par mes soins.
Pour l'instant, les sprites ont été créés à la main et ceux dans la rom ne sont pas la version finale.
Mon jeu était plutot orienté action plateforme avec un système d'interrupteurs colorés permettant à un perso de faire avancer l'autre... Donc casse-tête.
Dans l'évolution, un des perso pourra bouger des caisses et l'autres les détruire. Et des boss à éclater.
Il y a peut être moyen de faire quelques choses ?
Les grands esprits se rencontre, c'est bien connu.
En fait, mon idée de départ était qu'on puisse diriger les 2 personnages en même temps, mais j'avais quand même imaginé que dans les premiers niveaux on aient juste besoin de faire les actions des personnages l'un après l'autre. Ça ne serait que dans les derniers niveaux qu'il faudrait une coordination pointue entre les 2 personnages.
Pour le jeu en versus, j'imaginai un 2 vs 2 en direct link (avec 2 MSX).
Pour les divergences, y a la plateforme : j'aimerai utiliser le MSX2 pour avoir un rendu chatouillant.
Et le langage : As tu déjà essayé le C sous MSX ? Je trouve cela vraiment pratique pour la structure du programme. Et ça permet d'utiliser l4ASM pour tout ce qui a besoin de performance au cycle prêt.
De toute façon, pour l'instant, je me sert de se projet pour mieux connaitre l'architecture du MSX ; c'est un peu mon tutorial.
Du coup, je vais continuer a avancer un peu en solo pour apprendre mais après, je serai évidement très intéressé par une collaboration sur un projet !
On est toujours ignorant avant de savoir.
J'ai déjà développé des jeux en C sur PC (mode 13h,...) mais jamais pour le MSX.
Et je suis d'accord avec toi, un programme avec un langage structuré est plus sympa pour développer.
Pour ma part, je ne connaissais rien à l'assembleur (un peu de 68000 à la fac) J'ai appris avec des tutoriels pour CPC. Le résultat présenté dans la ROM est le fruit de plus d'une centaine d'heures (apprentissage et développement du moteur) j'ai encore beaucoup de choses à apprendre (collision sprite, musique et bruitage, ...)
Mon but étant de créer un jeu de plateforme style Fanstam Soldier en SCREEN4 avec scrolling et tout et tout...
Pas de soucis, nous en reparlerons à l'occasion ou pour partager quelques connaissances.
Et je suis d'accord avec toi, un programme avec un langage structuré est plus sympa pour développer.
Pour ma part, je ne connaissais rien à l'assembleur (un peu de 68000 à la fac) J'ai appris avec des tutoriels pour CPC. Le résultat présenté dans la ROM est le fruit de plus d'une centaine d'heures (apprentissage et développement du moteur) j'ai encore beaucoup de choses à apprendre (collision sprite, musique et bruitage, ...)
Mon but étant de créer un jeu de plateforme style Fanstam Soldier en SCREEN4 avec scrolling et tout et tout...
Pas de soucis, nous en reparlerons à l'occasion ou pour partager quelques connaissances.
RibbSayan :
Pas de soucis, nous en reparlerons à l'occasion ou pour partager quelques connaissances.
Avec grand plaisir.
Pour en revenir au dev, j'ai un p'tit soucis quand j'essaye d'écrire directement dans la VRAM en screen 8 (sans passer par la macro VDP PSET).
Dans l'exemple ci-joint (test.zip), le point mauve est affiché par un accès direct à la VRAM alors que le curseur blanc est affiché via PSET.
Quand on appuis sur les flèches, on voit le curseur blanc qui bouge bien partout à l'écran mais le point mauve (je ne l'efface pas pour que le problème soit plus visible) n'a pas un bon Y et il y a une sorte de modulo dans les Y qui le restreint au haut de l'écran.
Mon code pour écrire dans la VRAM :
Code :
di
;// Set 0 to register 14 (we don't use address bits 14-16)
xor a
out (#0x99),a
ld a,#0x80+#14
out (#0x99),a
;// Set VRAM address to port 0
ld a,4(ix)
out (#0x99),a
ld a,5(ix)
and #0x3F ;// Set 2 last bits to 0
or #0x40 ;// write access
out (#0x99),a
;// Write value
ld a,6(ix)
out (#0x98),a
ei
Ou 4(ix) est ma valeur X, 5(ix) pour Y et 6(ix) est la couleur.
Des idées ?
EDIT : J'ai mis la rom de test à jour. Edité par aoineko Le 11/01/2011 à 14h10
On est toujours ignorant avant de savoir.
Jipe :
c'est le code du C qui travaille avec tous ces (ix) ou bien c'est ta méthode perso ?
j' ai rarement rencontré ce systéme sur MSX les registres sont chargés directement
j' ai rarement rencontré ce systéme sur MSX les registres sont chargés directement
C'est le C. Ça correspond à l'entête de fonction :
Code :
void WriteToVRAM(u8 x, u8 y, u8 value)
On est toujours ignorant avant de savoir.
Jipe :
en tout cas c'est dur a suivre dans un désassembleur
j'ai essayé pour savoir la fonction des touches et lesquelles font monter et descendre et je m'y suis perdu
j'ai essayé pour savoir la fonction des touches et lesquelles font monter et descendre et je m'y suis perdu
Si tu veux, je peut t'envoyer le code C, tu verras, c'est juste un encapsuleur d'ASM.
Pour info, pour faire bouger le curseur, j'utilise :
Code :
char Joystick(char n)
{
n;
_asm
ld a,4(ix)
call 0x00d5
ld l,a
_endasm;
}
On est toujours ignorant avant de savoir.
le C ne m'a jamais attiré et j'ai passé plus d'heures a fouiller les jeux et donc a desassembler que le contraire
ex: traduction de Golvellius , changement de mapper pour faire tourner les jeux Ascii dans une SCC
mais ça m'a permis de fabriquer quelque petites routines en machine dans mes programmes basic
ex: traduction de Golvellius , changement de mapper pour faire tourner les jeux Ascii dans une SCC
mais ça m'a permis de fabriquer quelque petites routines en machine dans mes programmes basic
Jipe :
juste push ix avant la routine et pop ix aprés mais pas garanti
En fait, le système de passage de paramètre d'une fonction C vers du code ASM marche très bien dans tous les autres cas. A mon avis, c'est plutôt un problème ASM. Le X est loadé normalement, mais je suis pas sur de ce qu'est censé faire le code de load du Y :
Code :
ld a,5(ix)
and #0x3F ;// Set 2 last bits to 0
or #0x40 ;// write access
out (#0x99),a
J'avais récupéré ça qq part mais je me souviens plus du contexte (peut-être un autre mode graphique). Edité par aoineko Le 11/01/2011 à 16h44
On est toujours ignorant avant de savoir.
, mais ton AND #0x3F limite ton y à 63 non?
MSXosaure :
ton AND #0x3F limite ton y à 63 non?
Oui, je pense que le problème vient de là ...
Tu élimines systématiquement toutes les valeurs supérieures à 63.
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
Vous n'êtes pas autorisé à écrire dans cette catégorie