La Place des Développeurs [Fusion-C] Détails sur le Screen 5
D'abord Eric, j'aime, que dis-je j'adore Fusion-C
MERCI!
Je fait mumuse avec le Screen 5, je charge mes graphs (avec ton listing "loadscreen5image.c"), j'initialise ma palette, quelque LMMM() pour afficher ma map et un sprite soft 16x24 et.... voila:
Mais j'ai quelque soucis:
Je souhaite placer mes éléments graphique en page 2 donc mon code donne
...Sauf que quoi qu'il arrive l'image vas toujours ce charger en page 0
Autre point dans FT_LoadSc5Image() tu as commenté
L'utilisation de SetActivePage() et de SetDisplayPage() me laisse aussi perplexe.
SetActivePage() joue elle sur les commandes VDP? Edité par Xavier Le 01/08/2019 à 23h55
MERCI!
Je fait mumuse avec le Screen 5, je charge mes graphs (avec ton listing "loadscreen5image.c"), j'initialise ma palette, quelque LMMM() pour afficher ma map et un sprite soft 16x24 et.... voila:
Mais j'ai quelque soucis:
Je souhaite placer mes éléments graphique en page 2 donc mon code donne
Citation :
FT_LoadSc5Image("GRAPH.SC5", 512 ,LDbuffer);
...Sauf que quoi qu'il arrive l'image vas toujours ce charger en page 0
Autre point dans FT_LoadSc5Image() tu as commenté
Citation :
et utilisé des vpokes plus lent à la place, une raison particulière?HMMC(buffer, 0,start_Y,256,nbl );
L'utilisation de SetActivePage() et de SetDisplayPage() me laisse aussi perplexe.
SetActivePage() joue elle sur les commandes VDP? Edité par Xavier Le 01/08/2019 à 23h55
ericb59
Membre non connecté
Conseiller Municipal
Salut Xavier, (Professeur Xavier ?)
Merci d'utiliser Fusion-c, ca me fait chaud au coeur ! Et ça à l'air sympa ce que tu es en train de faire
En mettant 512 en tant que coordonnée Y, oui tu dois charger l'image en page 2.
J'ai sans doute utilisé des Poke car il devait y avoir un bug dans la fonction HMMC. Il me semble que c'est corrigé.
Je vais poster une nouvelle routine de chargement, avec un update de la librairie si nécessaire.
SetActivePage est utilisé par certaines fonctions graphiques, oui. Je n'ai pas en tête toutes les fonctions en question, j'ai dû le noter dans le manuel quand c'était nécessaire.
Par exemple PutText ou Cls, utilisent la Page Active pour fonctionner.
Edité par ericb59 Le 02/08/2019 à 11h18
Merci d'utiliser Fusion-c, ca me fait chaud au coeur ! Et ça à l'air sympa ce que tu es en train de faire
En mettant 512 en tant que coordonnée Y, oui tu dois charger l'image en page 2.
J'ai sans doute utilisé des Poke car il devait y avoir un bug dans la fonction HMMC. Il me semble que c'est corrigé.
Je vais poster une nouvelle routine de chargement, avec un update de la librairie si nécessaire.
SetActivePage est utilisé par certaines fonctions graphiques, oui. Je n'ai pas en tête toutes les fonctions en question, j'ai dû le noter dans le manuel quand c'était nécessaire.
Par exemple PutText ou Cls, utilisent la Page Active pour fonctionner.
Edité par ericb59 Le 02/08/2019 à 11h18
ericb59
Membre non connecté
Conseiller Municipal
Voici la nouvelle routine, vachement plus rapide qui utilise HMMC et un buffer de 2560 Octets soit 20 lignes d'une image en screen5
Utilise Fusion-c 1.1a (La dernière version disponible sur le site) http://www.ebsoft.fr/shop/en/home/66-fusion-c.html
Utilise Fusion-c 1.1a (La dernière version disponible sur le site) http://www.ebsoft.fr/shop/en/home/66-fusion-c.html
Code C :
Edité par
ericb59
Le 02/08/2019 à 15h51
#include "fusion-c/header/msx_fusion.h" #include "fusion-c/header/vdp_graph2.h" #include <string.h> static FCB file; // Initialisatio de la structure pour le systeme de fichiers unsigned char LDbuffer[2560]; // Création d'un buffer de 2560 octets (20 lignes en Sc5) void FT_SetName( FCB *p_fcb, const char *p_name ) // Routine servant à vérifier le format du nom de fichier { char i, j; memset( p_fcb, 0, sizeof(FCB) ); for( i = 0; i < 11; i++ ) { p_fcb->name[i] = ' '; } for( i = 0; (i < 8) && (p_name[i] != 0) && (p_name[i] != '.'); i++ ) { p_fcb->name[i] = p_name[i]; } if( p_name[i] == '.' ) { i++; for( j = 0; (j < 3) && (p_name[i + j] != 0) && (p_name[i + j] != '.'); j++ ) { p_fcb->ext[j] = p_name[i + j] ; } } } void FT_errorHandler(char n, char *name) // Gère les erreurs { Screen(0); SetColors(15,6,6); switch (n) { case 1: Print("\n\rFAILED: fcb_open(): "); Print(name); break; case 2: Print("\n\rFAILED: fcb_close():"); Print(name); break; case 3: Print("\n\rStop Kidding, run me on MSX2 !"); break; } Exit(0); } int FT_LoadSc5Image(char *file_name, unsigned int start_Y, char *buffer) // Charge les données d'un fichiers { int rd=2560; FT_SetName( &file, file_name ); if(fcb_open( &file ) != FCB_SUCCESS) { FT_errorHandler(1, file_name); return (0); } fcb_read( &file, buffer, 7 ); // Skip 7 first bytes of the file while (rd!=0) { rd = fcb_read( &file, buffer, 2560 ); // Read 20 lines of image data (128bytes per line in screen5) HMMC(buffer, 0,start_Y,256,20 ); // Move the buffer to VRAM. start_Y=start_Y+20; } return(1); } void main(void) { char mypalette[] = { // Palette SC5 0, 0,0,0, 1, 2,1,1, 2, 6,5,4, 3, 5,4,3, 4, 5,5,3, 5, 6,5,3, 6, 7,6,4, 7, 3,2,1, 8, 7,5,2, 9, 6,4,2, 10, 4,3,2, 11, 4,3,1, 12, 5,3,2, 13, 3,3,2, 14, 3,1,0, 15, 5,2,0 }; Screen(5); SetColors(15,0,0); Cls(); PutText(0,0,"Page 0-(Push a key to continue)",0); // Page 0 WaitForKey(); // Attend une touche SetDisplayPage (2); // Page 2 SetActivePage(2); Cls(); PutText(0,10,"Page 2-(Push a key to continue)",0); WaitForKey(); // Attend une touche FT_LoadSc5Image("mona.sc5",512,LDbuffer); // On charge l'umage SetSC5Palette((Palette *)mypalette); WaitForKey(); Screen(0); Exit(0); }
Impeccable!
Avec ta correction les graphs ce chargent bien en page 2 et rapidement en plus!
Par contre je pense avoir trouvé une bizarrerie entre LMMM() et fLMMM():
fLMMM(): DX et DY sont effectivement la taille en pixel du bloc à transmettre (ici 16x16)
LMMM(): DX et DY sont les coordonnés du coin inférieur droit du bloc source ( pour le tile 1 ce seras DX=16 et DY=528)
Normal ou bug
PS: Xavier c'est vraiment mon prénom
Avec ta correction les graphs ce chargent bien en page 2 et rapidement en plus!
Par contre je pense avoir trouvé une bizarrerie entre LMMM() et fLMMM():
fLMMM(): DX et DY sont effectivement la taille en pixel du bloc à transmettre (ici 16x16)
LMMM(): DX et DY sont les coordonnés du coin inférieur droit du bloc source ( pour le tile 1 ce seras DX=16 et DY=528)
Normal ou bug
PS: Xavier c'est vraiment mon prénom
ericb59
Membre non connecté
Conseiller Municipal
Xavier :
Impeccable!
Avec ta correction les graphs ce chargent bien en page 2 et rapidement en plus!
Avec ta correction les graphs ce chargent bien en page 2 et rapidement en plus!
Oui professeur Xavier
Xavier :
Impeccable!
LMMM(): DX et DY sont les coordonnés du coin inférieur droit du bloc source ( pour le tile 1 ce seras DX=16 et DY=528)
Normal ou bug
LMMM(): DX et DY sont les coordonnés du coin inférieur droit du bloc source ( pour le tile 1 ce seras DX=16 et DY=528)
Normal ou bug
heuuu ... Je vais vérifier, mais d'ici un jour ou 2 je vais sortir la version 1.1b de Fusion-c
Avec de nouvelles fonctions de copy graphiques et des changements... Attends donc de voir... Car fLMMM pourra etre remplacé par HMMM qui est plus vachement plus rapide si tu n'as pas d'operation logique à faire sur l'image. Edité par ericb59 Le 03/08/2019 à 11h14
Oh oui, je suis preneur pour une fonction de blit plus rapide pour les tiles.
D'ailleurs:
Qu'avons nous là...
Page 0 et 1 servent pour un double buffer
Page 2 stocke le décor construis et le hud
Page 3 contiens les tiles et sprites
C'est fluide et rapide avec 2 sprites soft, à voir avec le gameplay et plus de choses à l'écran.
Le décor de fond reste intact en page 2 et seule les parties altéré par les sprites sont mise à jour dans les 2 première pages sans clignotement
Sur CPC le double buffer m'a collé une dépression sur MSX ça ma pris une petite heure
Concernant la commande VDP YMMM (copie rapide verticale) je soupçonne qu'elle était prévue spécifiquement pour le double buffer puisqu'il faut copier rapidement d'une page à l'autre sans toucher à X. Edité par Xavier Le 03/08/2019 à 17h46
D'ailleurs:
Qu'avons nous là...
Page 0 et 1 servent pour un double buffer
Page 2 stocke le décor construis et le hud
Page 3 contiens les tiles et sprites
C'est fluide et rapide avec 2 sprites soft, à voir avec le gameplay et plus de choses à l'écran.
Le décor de fond reste intact en page 2 et seule les parties altéré par les sprites sont mise à jour dans les 2 première pages sans clignotement
Sur CPC le double buffer m'a collé une dépression sur MSX ça ma pris une petite heure
Concernant la commande VDP YMMM (copie rapide verticale) je soupçonne qu'elle était prévue spécifiquement pour le double buffer puisqu'il faut copier rapidement d'une page à l'autre sans toucher à X. Edité par Xavier Le 03/08/2019 à 17h46
ericb59
Membre non connecté
Conseiller Municipal
j'imagine que tu utilises un OP pour l'affichage de tes personnages (opérateur logique pour utiliser le ode transparence), dans ce cas, tu gagnera pas énormément de vitesse. Mais les fonctions avec OP ont aussi été optimisées donc ... Ca devrait être encore mieux.
J'ai pas prévu d'intégrer YMMM pour l'instant.
Je devrais mettre les nouveautés en ligne la semaine prochaine.
Bravo ... Continue comme ça en tout ... Ca me plait bien ce que tu montre
J'ai pas prévu d'intégrer YMMM pour l'instant.
Je devrais mettre les nouveautés en ligne la semaine prochaine.
Bravo ... Continue comme ça en tout ... Ca me plait bien ce que tu montre
ericb59
Membre non connecté
Conseiller Municipal
@Xavier
J'ai posté ici : http://msxvillage.fr/forum/topic.php?id=3549&pt=9#m81497
les nouveautés de la prochaine version. J'ai intégré toutes les fonctions graphiques qui devraient te permettre de gagner en rapidité...
(Voir Video d'exemple)
J'ai posté ici : http://msxvillage.fr/forum/topic.php?id=3549&pt=9#m81497
les nouveautés de la prochaine version. J'ai intégré toutes les fonctions graphiques qui devraient te permettre de gagner en rapidité...
(Voir Video d'exemple)
Citation :
Où en es tu de ton projet de jeu ?
Ca avance, lentement mais surement .
En plus la licence des graphismes que j'utilise viens d’être élargie. Plus de problème pour les mettre sur MSX.
Quelque point cependant:
1 - La musique + commande vdp = ça rame horriblement
2 - Après avoir joué à "Los amores de Brunilda" (très bon jeux au passage) j'ai eu envie d'utiliser une hirq pour affiché 2 palettes à l’écran, une variable pour la zone de jeux et une fixe pour le hud. J'ai essayé plusieurs méthodes sans résultat mais je manque d'habitude sur msx, quelqu'un a un exemple en c?
3 - Je réfléchie à optimiser le système de map pour être le moins gourmand en mémoire. Existe il un moyen (relativement) simple et propre d’accéder à plus de 64ko sous dos1?
ericb59
Membre non connecté
Conseiller Municipal
Je suis bien content que ça ne soit pas tombé à l'eau.
- Est-ce que tu utilises bien FUSION-C 1.2 ? les commandes VDP y sont optimisées, et j'en ai ajouté d'autre que le fLMMM qui est lent en comparaison des autres fonctions.
Tu trouves que ça rame en faisant quoi au juste ?
Même en assembleur le remplissage complet d'une page écran va faire un peu ramer le reste. De même le chargement depuis une unité de disque fait ramer tout le reste.
- pour le coup des 2 palettes. Je ne sais pas du tout de quoi il retourne...
- Pour ce qui est de la RAM utilisée. La V1.3 qui sortira bientôt sera un peut moins gourmande. Car j'ai optimisé pas mal le code. On devrait gagner quelque Ko.
Quelques trucs que j'utilise pour gagner un peut de RAM. Je ne place pas mes patterns de sprites, ni les couleurs dans le code source. Je défini les sprites dans un programme séparé, je sauvegarde la zone des sprites de la VRAM dans un fichier BIN.
Comme ca je n'ai plus qu'à charger ce fichier dans le jeu final pour retrouver tous les sprites et leurs DATA.
De même pour la plupart des DATA utilisables ... Map, ou longs textes ; si le programme est volumineux, je préfère les placer dans des fichiers externes et les charger au besoin. Certes c'est un peut plus long à charger. Mais à terme si le disk est transformé en ROM (DSKTOROM), les chargement deviennent presque indolores.
Si tu as de la place en VRAM tu peux aussi y stocker des données autres que des graphismes.
Attention au buffers prédéfinis. Si tu définis un : Static Const Buffer[2048]
ca te prends 2Ko de RAM tout le temps.
Tu peux utiliser une Union globale (ou une structure) pour définir des variables polyvalentes, à utiliser partout. Plutôt que des variables locales.
Pour avoir plus de 64K en DOS1, peut être que tu peux utiliser le switch de Bank mémoire sur la Page 2 de la RAM (0x8000 -> 0xBFFF) de la même manière que pour les jeux ROM.
Mais déjà il faut être certain de ce qu'il y a dans ta Page 2. Si il y a du code, ça va planter !
Et je ne sais pas si ça sera stable avec DOS
Edité par ericb59 Le 16/01/2020 à 09h47
- Est-ce que tu utilises bien FUSION-C 1.2 ? les commandes VDP y sont optimisées, et j'en ai ajouté d'autre que le fLMMM qui est lent en comparaison des autres fonctions.
Tu trouves que ça rame en faisant quoi au juste ?
Même en assembleur le remplissage complet d'une page écran va faire un peu ramer le reste. De même le chargement depuis une unité de disque fait ramer tout le reste.
- pour le coup des 2 palettes. Je ne sais pas du tout de quoi il retourne...
- Pour ce qui est de la RAM utilisée. La V1.3 qui sortira bientôt sera un peut moins gourmande. Car j'ai optimisé pas mal le code. On devrait gagner quelque Ko.
Quelques trucs que j'utilise pour gagner un peut de RAM. Je ne place pas mes patterns de sprites, ni les couleurs dans le code source. Je défini les sprites dans un programme séparé, je sauvegarde la zone des sprites de la VRAM dans un fichier BIN.
Comme ca je n'ai plus qu'à charger ce fichier dans le jeu final pour retrouver tous les sprites et leurs DATA.
De même pour la plupart des DATA utilisables ... Map, ou longs textes ; si le programme est volumineux, je préfère les placer dans des fichiers externes et les charger au besoin. Certes c'est un peut plus long à charger. Mais à terme si le disk est transformé en ROM (DSKTOROM), les chargement deviennent presque indolores.
Si tu as de la place en VRAM tu peux aussi y stocker des données autres que des graphismes.
Attention au buffers prédéfinis. Si tu définis un : Static Const Buffer[2048]
ca te prends 2Ko de RAM tout le temps.
Tu peux utiliser une Union globale (ou une structure) pour définir des variables polyvalentes, à utiliser partout. Plutôt que des variables locales.
Pour avoir plus de 64K en DOS1, peut être que tu peux utiliser le switch de Bank mémoire sur la Page 2 de la RAM (0x8000 -> 0xBFFF) de la même manière que pour les jeux ROM.
Mais déjà il faut être certain de ce qu'il y a dans ta Page 2. Si il y a du code, ça va planter !
Et je ne sais pas si ça sera stable avec DOS
Edité par ericb59 Le 16/01/2020 à 09h47
Répondre
Vous n'êtes pas autorisé à écrire dans cette catégorie