La Place des Développeurs FUSION-C Codez en C pour MSX les doigts dans le nez !
Donc en résumé, c'est comme le basic avec des instructions de base sauf qu'en plus on peu utilisé des instructions supplémentaires sous forme de library, dans l'exemple "stduo.h" qui ajoute les instructions peintf et scanf.
C'est certain que ce n'est pas trop compliqué, enfin pour cette exemple, car si on n'est pas capable de faire un casse brique sous basic (faut quand même une certaine maîtrise et connaissance du MSX), ça sera pas plus évident en C
Après si je comprend bien, ça doit être plus facile de traduire un programme en C d'une machine a une autre en changeant simplement les library instructions spécifiques a cette machine, comme un lego
C'est ça, ou j'ai rien compris 
C'est certain que ce n'est pas trop compliqué, enfin pour cette exemple, car si on n'est pas capable de faire un casse brique sous basic (faut quand même une certaine maîtrise et connaissance du MSX), ça sera pas plus évident en C
Après si je comprend bien, ça doit être plus facile de traduire un programme en C d'une machine a une autre en changeant simplement les library instructions spécifiques a cette machine, comme un lego
C'est ça, ou j'ai rien compris
MSX 1&2 + Moniteurs+divers (environ 0.70Tonnes)
TurboSEB :
Après si je comprend bien, ça doit être plus facile de traduire un programme en C d'une machine a une autre en changeant simplement les library instructions spécifiques a cette machine, comme un lego
C'est ça, ou j'ai rien compris
C'est ça, ou j'ai rien compris
Sur les machines modernes, ont programme dans un environnement "indépendant du hardware" et c'est effectivement les librairies qui font que le code va fonctionner sur les différentes machines.
Par exemple, le moteur de jeu Unreal Engine fonctionne sur ce principe.
Si vous voulez vous lancer, je suis dispo pour assistance (je suis exceptionnellement pas trop occupé pour les semaines/mois qui viennent).
@ericb59 : J'ai fait fonctionner le build sur Windows (je te ferai plein de retours, mais j'attends de finir mes tests).
En attendant, une ch'tite question : Est-ce qu'il y a des fonctions pour afficher du texte dans les modes graphiques ?
J'ai pas l'impression, mais j'ai p'être raté un truc.
On est toujours ignorant avant de savoir.
aoineko :
@ericb59 : J'ai fait fonctionner le build sur Windows (je te ferai plein de retours, mais j'attends de finir mes tests).
En attendant, une ch'tite question : Est-ce qu'il y a des fonctions pour afficher du texte dans les modes graphiques ?
J'ai pas l'impression, mais j'ai p'être raté un truc.
@ericb59 : J'ai fait fonctionner le build sur Windows (je te ferai plein de retours, mais j'attends de finir mes tests).
En attendant, une ch'tite question : Est-ce qu'il y a des fonctions pour afficher du texte dans les modes graphiques ?
J'ai pas l'impression, mais j'ai p'être raté un truc.
Oui
void PutText( int X, int Y, char *str, char LogOp );
(MSX2_fusion.h)
La couleur du texte est la couleur foregroud dernièrement utilisée, la couleur de l'arrière plan du text est la couleur background dernièrement utilisée.
void SetColors ( char foreground, char background, char border); Edité par ericb59 Le 13/11/2020 à 19h09
@ericb59 : Bon, finalement j'ai fait la fonction d'affichage de texte moi-même.
Ca tien en qq lignes si ça t'intéresse. J'ai fait la version pour les modes 4-bits-par-couleur comme le Screen 5 mais ça serait rapide de faire les autres versions.
Ca tien en qq lignes si ça t'intéresse. J'ai fait la version pour les modes 4-bits-par-couleur comme le Screen 5 mais ça serait rapide de faire les autres versions.
On est toujours ignorant avant de savoir.
ericb59 :
Oui
void PutText( int X, int Y, char *str, char LogOp );
(MSX2_fusion.h)
La couleur du texte est la couleur foregroud dernièrement utilisée, la couleur de l'arrière plan du text est la couleur background dernièrement utilisée.
void SetColors ( char foreground, char background, char border);
void PutText( int X, int Y, char *str, char LogOp );
(MSX2_fusion.h)
La couleur du texte est la couleur foregroud dernièrement utilisée, la couleur de l'arrière plan du text est la couleur background dernièrement utilisée.
void SetColors ( char foreground, char background, char border);
Flute, j'ai pas été assez patient
On est toujours ignorant avant de savoir.
@jipe et les autre que ça intéresse.
SI j'avais le temps j'ouvrirais volontiers un topic d'aide / Tuto pour le C.
A l'origine, en C il y a assez peut d'instructions, et rien qui ne traite du son ou bien des graphismes.
Les librairies C pour les ordinateur MSX ou Amstrad ou autre sont effectivement comme le dis Turbo-seb des briques qui s'empilent.
L"avantage du C, c'est qu'il est facile de créer son propre "jeux" d'instructions. Que ces instructions soient écrite elles même en C, ou en Assembleur.
En fait, Fusion-c ne fait à peut près rien de plus que d'empiler des bouts de code ASM... Jipe, tu connais l'assembleur Z80, c'est pas le C qui va te résister
tu vas tout de suite reconnaitre ceci :
C'est la fonction PutSprite de Fusion-C.
Comme tu vois, c'est de l'assembleur.
La definition de la fonction en C donne ceci :
void PutSprite( char sprite_no, char pattern_no, char x, char y, char ec_color );
Dans la définition, le premier mot avant la fonction indique si la fonction en question retourne une valeur, et sous quelle forme.
ici "void" veux dire que PutSprite ne retourne aucune donnée.
Après le nom de la fonction, entre les parenthèses sont indiquée les valeurs qui rentre dans la fonction, et sous quelle forme.
char sprite_no : la première valeur à entrer est le numéro de sprite, il est sous la form 'char' c'est à dire une valeur en 0 et 255
char pattern_no : la seconde valeur à entrer est le numéro du pattern à utiliser, lui aussi doit être une valeur en 0 et 255
puis on a les coordonnées x, y, et la couleur à utiliser.
Lorsque le compilateur C va trouver l'instruction PutSprite dans mon listing, il va aller chercher (Linker) le bout de code Assembleur qui se trouve dans la librairie et le mettre dans le programme final.
Si PuSprite est utilisé plusieurs fois, le compilateur ne va pas copier plusieurs fois code, mais il va simplement générer un appel à la routine qui existe déjà dans le code qu'il est en train de construire.
Bon après ce que fait le compilateur on s'en fou un peu...
L'important c'est de voir que c'est un langage totalement modulaire, et qui s'adapte très bien à chaque façon de programmer. Chacun y trouve son compte, les débutants comme les pros.
Edité par ericb59 Le 13/11/2020 à 19h36
SI j'avais le temps j'ouvrirais volontiers un topic d'aide / Tuto pour le C.
A l'origine, en C il y a assez peut d'instructions, et rien qui ne traite du son ou bien des graphismes.
Les librairies C pour les ordinateur MSX ou Amstrad ou autre sont effectivement comme le dis Turbo-seb des briques qui s'empilent.
L"avantage du C, c'est qu'il est facile de créer son propre "jeux" d'instructions. Que ces instructions soient écrite elles même en C, ou en Assembleur.
En fait, Fusion-c ne fait à peut près rien de plus que d'empiler des bouts de code ASM... Jipe, tu connais l'assembleur Z80, c'est pas le C qui va te résister
tu vas tout de suite reconnaitre ceci :
Code ASM :
void PutSprite( char sprite_no, char pattern_no, char x, char y, char ec_color ) __naked { sprite_no,pattern_no,x,y,ec_color; __asm push ix ld ix,#0 add ix,sp ld a,4(ix) ; sprite_no rlca rlca ld hl,(#0xF928) ; add HL to A add a,l ld l,a adc a,h sub l ld h,a di call _SetVDPwrite di ld c,#0x98 ld a, 7 (ix) ; y out (c),a ld a, 6 (ix) ; x out (c),a ld a, 5 (ix) ; pattern_no out (c),a ld a, 8 (ix) ; ec_color out (c),a ei pop ix ret __endasm; }
C'est la fonction PutSprite de Fusion-C.
Comme tu vois, c'est de l'assembleur.
La definition de la fonction en C donne ceci :
void PutSprite( char sprite_no, char pattern_no, char x, char y, char ec_color );
Dans la définition, le premier mot avant la fonction indique si la fonction en question retourne une valeur, et sous quelle forme.
ici "void" veux dire que PutSprite ne retourne aucune donnée.
Après le nom de la fonction, entre les parenthèses sont indiquée les valeurs qui rentre dans la fonction, et sous quelle forme.
char sprite_no : la première valeur à entrer est le numéro de sprite, il est sous la form 'char' c'est à dire une valeur en 0 et 255
char pattern_no : la seconde valeur à entrer est le numéro du pattern à utiliser, lui aussi doit être une valeur en 0 et 255
puis on a les coordonnées x, y, et la couleur à utiliser.
Lorsque le compilateur C va trouver l'instruction PutSprite dans mon listing, il va aller chercher (Linker) le bout de code Assembleur qui se trouve dans la librairie et le mettre dans le programme final.
Si PuSprite est utilisé plusieurs fois, le compilateur ne va pas copier plusieurs fois code, mais il va simplement générer un appel à la routine qui existe déjà dans le code qu'il est en train de construire.
Bon après ce que fait le compilateur on s'en fou un peu...
L'important c'est de voir que c'est un langage totalement modulaire, et qui s'adapte très bien à chaque façon de programmer. Chacun y trouve son compte, les débutants comme les pros.
Edité par ericb59 Le 13/11/2020 à 19h36
@aoineko
Ben j'utilise juste un appel au bios pour l'affichage graphique du texte en mode graphique ...
y a déjà tout ce qui faut dans Fusion-c
Edité par
ericb59
Le 13/11/2020 à 19h38
Ben j'utilise juste un appel au bios pour l'affichage graphique du texte en mode graphique ...
Code C :
GRPACX = #0xFCB7 GRPACY = #0xFCB9 LOGOPR = #0xFB02 FORCLR = 0xF3E9 ; foreground color BAKCLR = 0xF3EA ; background color BDRCLR = 0xF3EB ; border color .area _CODE ;---------------------------- ; MODULE PutText ; ; PutText( int X, int Y, char *str, char LogOp ) ; ; Print string on graphics screen at position x,y using LogOperator ; (ignores \n\l\t and other text features) ; ; _PutText:: push ix ld ix,#0 add ix,sp ld l,4(ix) ld h,5(ix) ld (GRPACX),hl ; X ld l,6(ix) ld h,7(ix) ld (GRPACY),hl ; Y ld a,10(ix) ld (LOGOPR),a ; LogOp ld l,8(ix) ld h,9(ix) push iy lb_ptlp: ld a,(hl) or a jr z, lb_ptEx ld iy,(0xFCC0) ; mainrom slotaddress (reference) ld ix,#0x008D ; bios (api) address call 0x001c ; interslotcall ei inc hl jr lb_ptlp lb_ptEx: pop iy pop ix ret
y a déjà tout ce qui faut dans Fusion-c
Edité par
ericb59
Le 13/11/2020 à 19h38
quand on voit les fonctions scant, et printf pour la première fois, c'est vrai qu'on se demande comment ça marche 
Avec Fusion-C on peut effectivement écrire le programme tel que dans ton exemple, mais j'ai aussi des fonctions alternatives.
il pourrait devenir :
La limitation étant que x et y doivent être compris entre 0 et 255 Edité par ericb59 Le 13/11/2020 à 19h49
Code TEXT :
long double x, y;
int main(void)
{
printf("Calcul de moyenne\n"); /* Affiche le titre. */
printf("Entrez le premier nombre : ");
scanf("%Lf", &x); /* Entre le premier nombre. */
printf("\nEntrez le deuxième nombre : ");
scanf("%Lf", &y); /* Entre le deuxième nombre. */
printf("\nLa valeur moyenne de %Lf et de %Lf est %Lf.\n",
x, y, (x+y)/2);
return 0;
}
Avec Fusion-C on peut effectivement écrire le programme tel que dans ton exemple, mais j'ai aussi des fonctions alternatives.
il pourrait devenir :
Code C :
char x,y; void main(void) { Print("Calcul de moyenne\n\r"); Print("Entrez le premier nombre : "); x = InputChar (); Print("\n\rEntrez le deuxième nombre : "); y = InputChar (); Print("\n\rLa valeur moyenne de "); PrintNumber (x); Print (" et "); PrintNumber(y); Print (" est : "); PrintNumber((x+y)/2); Exit(0); }
La limitation étant que x et y doivent être compris entre 0 et 255 Edité par ericb59 Le 13/11/2020 à 19h49
ericb59 :
y a déjà tout ce qui faut dans Fusion-c
Ce qui m'embête avec les routines du Bios, c'est que je sais pas ce qu'elles font exactement et si elles sont bien optimisés (ce qui n'est pas le cas pour l'affichage dans mon souvenir).
Là, avec une poignée de HMMC j'écris avec la font et la couleur que je veux.
Après, je respecte tes choix pour Fusion-C.
Pour l'exemple que je suis en train de faire pour MathTable, je vais prendre la fonction via le Bios (je garde l'autre sous le coude pour ma propre lib
).
On est toujours ignorant avant de savoir.
@Ericb59
Voici le sample d'exemple d'utilisation de MathTable avec Fusion-C : MathTable_FusionC130.zip
Bon, la table de 360 c'est vraiment pas top pour la précision (surtout en Q8.8), mais bon, c'est p'être plus parlant pour l'exemple.
Si ça te va, je peux clean un peu et push sur GitHub (je le mettrai dans fusion-c\examples\ex_MathTable.c et les tables dans fusion-c\header\mathtable).
Je te ferai des retours sur la lib ce week-end.
Voici le sample d'exemple d'utilisation de MathTable avec Fusion-C : MathTable_FusionC130.zip
Bon, la table de 360 c'est vraiment pas top pour la précision (surtout en Q8.8), mais bon, c'est p'être plus parlant pour l'exemple.
Si ça te va, je peux clean un peu et push sur GitHub (je le mettrai dans fusion-c\examples\ex_MathTable.c et les tables dans fusion-c\header\mathtable).
Je te ferai des retours sur la lib ce week-end.
On est toujours ignorant avant de savoir.
Citation :
Bon, la table de 360 c'est vraiment pas top pour la précision (surtout en Q8.8), mais bon, c'est p'être plus parlant pour l'exemple.
Si ça te va, je peux clean un peu et push sur GitHub (je le mettrai dans fusion-c\examples\ex_MathTable.c et les tables dans fusion-c\header\mathtable).
Si ça te va, je peux clean un peu et push sur GitHub (je le mettrai dans fusion-c\examples\ex_MathTable.c et les tables dans fusion-c\header\mathtable).
Ca me va
ericb59 :
Ca me va
C'est fait.
J'ai ajouté des macros pour récupérer la partie entière et décimal des nombres à virgule-fixe (header\mathtable\macro.h).
La plupart des calculs sont statiques et seront résolus directement par le compilateur.
J'ai pas inclus l'outil MathTable dans tes tools ; il est dispo sur https://github.com/aoineko-fr/mathtable si jamais tu veux l'ajouter.
On est toujours ignorant avant de savoir.
Voici mes retours sur mes premiers tests de la préversion de Fusion-C 1.3.
Y a certaines choses qui ne me semblent pas optimales, mais qui s’expliquent par le positionnement "tout-en-un" et "débutant" de la librairie. J’ai essayé d’en tenir compte, mais pour avoir utilisé des dizaines de libraires C ces 20 dernières années, il y a des conventions qu’il me semblerait quand même important à respecter.
Je remets certains commentaires que j’avais fait sur la 1.2 comme ça tu as tous les retours au même endroit.
1) compil
- Je ne sais pas pourquoi tu as pas mis le "e" de "compile" mais de toute façon, vu le contenu du script (compile + link + deploy) il devrait plutôt s’appeler "build". Ceci dit, ça serait bien d’avoir aussi un script qui ne fait que la partie compilation car c’est très pratique de pouvoir compiler les fichiers C indépendamment depuis l’IDE.
- Ensuite, je déconseille fortement de demander à l’utilisateur de copier hex2bin.exe dans le dossier de System32 de Windows. C’est une façon de faire qui n’est plus "legit". Chez moi j’ai corrigé le script pour qu’il aille chercher directement hex2bin dans le répertoire \Tools\.
- Il faudrait garder les fichiers intermédiaires (à mettre dans un répertoire \out\ ou \intermediate\).
- Je conseillerai d’extraire la partie configurable du script de build (pour avoir un fichier léger par projet et "cacher" l’usine-à-gaz de la partie commune). Par ex., tu pourrais avoir un fichier .proj au format batch avec juste des SET de la liste des répertoires à include, des fichiers à compiler et des librairies à link. Le script de Build pourrait prendre le .proj en entrée et avec un "CALL %1" ça setterait toutes les variables nécessaires pour le Build. Je peux te faire un exemple si tu veux.
2) deprecated
- Il faut vraiment éviter de supprimer des fonctions d’une version à l’autre. Quand c’est possible, la méthode la plus propre c’est de garder les anciennes fonctions, de les marquer comme "deprecated" et de les faire pointer vers la nouvelle fonction. J’ai pas regardé dans SDCC mais normalement, dans les compilateurs, il y une syntaxe pour marquer ces fonctions qui fera apparaître un warning quand les gens les utilisent (__declspec(deprecated) dans GCC). J’ai que tu avais fait des defines de redirection pour certaines fonctions, mais ta doc parle de fonctions supprimées.
3) headers
- Ils devraient se trouver dans un répertoire "Include" (c’est une convention quasi-universelle)
- Normalement on tâche de bien différencier 3 types d’includes :
-- Les fichiers de descriptions des fonctions d’un module → Ils devraient avoir le même nom que le .c correspondant.
-- Les headers "purs"(structure, enum, typedef, macro, etc.) →Ils ne doivent contenir aucune description de fonctions pour pouvoir être inclus sans avoir de besoin en link.
-- Les fichiers de données (font, table précalc, etc.) → Ils devraient être facilement identifiables par l’utilisateur car l’include à un impact important sur le programme (il fait augmenter sa taille). L’emplacement de l’include est également important car les données vont se retrouver incorporé au binaire à cet emplacement. C’est pour ces raisons que perso j’utilise toujours l’extension .inc pour ces fichiers. Si tu préfères garder des .h, tu pourrais décider d’une convention de nommage du genre *-data.h.
4) Naming convention
- On sent une volonté d’harmonisation dans les noms de fichiers, fonctions, structures, etc. mais y a encore beaucoup de boulot. Ca peut sembler un peu anodin, mais perso je pense que c’est vraiment essentiel pour avoir un outil vraiment user-friendly.
- Je trouve dommage que tout le code ne soit pas encapsulé dans du C. Ça coûte rien en perf et je trouve que ça rendrait la lib moins intimidante pour un programmeur C.
5) perf
- Bien faire attention à n’utiliser les int (16-bits) comme type de paramètre de fonctions que quand c’est vraiment nécessaire. En dehors du fait que ça rend la copie dans la pile un peu plus longue avant le CALL, c’est surtout que ça génère souvent du code ASM pas du tout optimal (ou il est obligé de jongler avec les registres pour faire des opérations 16-bits alors qu’il y en a pas besoin).
- Actuellement, toute la lib est link même si on utilise qu’une poignée de fonction. Il faudrait au minimum split la lib en différents modules.
- Je vois pas l’intérêt d’avoir mis un marqueur de traçage dans le programme (Made with FUSION-C 1.3 R11211 (c)EBSOFT:2020) ? C’est pas le genre de chose qu’on est censé trouver dans une lib gratuite et open-source. Surtout que ça fait perdre quelques précieux octets.
Voilà pour les remarques pour le moment.
Malgré ces quelques réserves, je trouve que la libraire est effectivement bien riche et qu’elle est déjà très cool.
Ma lib perso correspond mieux à mes besoins, mais j’suis sûr que Fusion-C corresponds aux attentes de bcp de gens et que ça sera encore plus le cas avec cette version 1.3.
Je dirais que le seul vrai problème actuellement, c’est le côté parfois un peu fouillis pour s’y retrouver, mais ça devrait pouvoir s’améliorer facilement.
J'espère que ces retours te seront utiles.
Je vais travailler sur le module de son de ma lib ; j’en profiterai pour regarder le problème dont tu m’avais parlé avec ton code pt3.
Y a certaines choses qui ne me semblent pas optimales, mais qui s’expliquent par le positionnement "tout-en-un" et "débutant" de la librairie. J’ai essayé d’en tenir compte, mais pour avoir utilisé des dizaines de libraires C ces 20 dernières années, il y a des conventions qu’il me semblerait quand même important à respecter.
Je remets certains commentaires que j’avais fait sur la 1.2 comme ça tu as tous les retours au même endroit.
1) compil
- Je ne sais pas pourquoi tu as pas mis le "e" de "compile" mais de toute façon, vu le contenu du script (compile + link + deploy) il devrait plutôt s’appeler "build". Ceci dit, ça serait bien d’avoir aussi un script qui ne fait que la partie compilation car c’est très pratique de pouvoir compiler les fichiers C indépendamment depuis l’IDE.
- Ensuite, je déconseille fortement de demander à l’utilisateur de copier hex2bin.exe dans le dossier de System32 de Windows. C’est une façon de faire qui n’est plus "legit". Chez moi j’ai corrigé le script pour qu’il aille chercher directement hex2bin dans le répertoire \Tools\.
- Il faudrait garder les fichiers intermédiaires (à mettre dans un répertoire \out\ ou \intermediate\).
- Je conseillerai d’extraire la partie configurable du script de build (pour avoir un fichier léger par projet et "cacher" l’usine-à-gaz de la partie commune). Par ex., tu pourrais avoir un fichier .proj au format batch avec juste des SET de la liste des répertoires à include, des fichiers à compiler et des librairies à link. Le script de Build pourrait prendre le .proj en entrée et avec un "CALL %1" ça setterait toutes les variables nécessaires pour le Build. Je peux te faire un exemple si tu veux.
2) deprecated
- Il faut vraiment éviter de supprimer des fonctions d’une version à l’autre. Quand c’est possible, la méthode la plus propre c’est de garder les anciennes fonctions, de les marquer comme "deprecated" et de les faire pointer vers la nouvelle fonction. J’ai pas regardé dans SDCC mais normalement, dans les compilateurs, il y une syntaxe pour marquer ces fonctions qui fera apparaître un warning quand les gens les utilisent (__declspec(deprecated) dans GCC). J’ai que tu avais fait des defines de redirection pour certaines fonctions, mais ta doc parle de fonctions supprimées.
3) headers
- Ils devraient se trouver dans un répertoire "Include" (c’est une convention quasi-universelle)
- Normalement on tâche de bien différencier 3 types d’includes :
-- Les fichiers de descriptions des fonctions d’un module → Ils devraient avoir le même nom que le .c correspondant.
-- Les headers "purs"(structure, enum, typedef, macro, etc.) →Ils ne doivent contenir aucune description de fonctions pour pouvoir être inclus sans avoir de besoin en link.
-- Les fichiers de données (font, table précalc, etc.) → Ils devraient être facilement identifiables par l’utilisateur car l’include à un impact important sur le programme (il fait augmenter sa taille). L’emplacement de l’include est également important car les données vont se retrouver incorporé au binaire à cet emplacement. C’est pour ces raisons que perso j’utilise toujours l’extension .inc pour ces fichiers. Si tu préfères garder des .h, tu pourrais décider d’une convention de nommage du genre *-data.h.
4) Naming convention
- On sent une volonté d’harmonisation dans les noms de fichiers, fonctions, structures, etc. mais y a encore beaucoup de boulot.
Ca peut sembler un peu anodin, mais perso je pense que c’est vraiment essentiel pour avoir un outil vraiment user-friendly.- Je trouve dommage que tout le code ne soit pas encapsulé dans du C. Ça coûte rien en perf et je trouve que ça rendrait la lib moins intimidante pour un programmeur C.
5) perf
- Bien faire attention à n’utiliser les int (16-bits) comme type de paramètre de fonctions que quand c’est vraiment nécessaire. En dehors du fait que ça rend la copie dans la pile un peu plus longue avant le CALL, c’est surtout que ça génère souvent du code ASM pas du tout optimal (ou il est obligé de jongler avec les registres pour faire des opérations 16-bits alors qu’il y en a pas besoin).
- Actuellement, toute la lib est link même si on utilise qu’une poignée de fonction. Il faudrait au minimum split la lib en différents modules.
- Je vois pas l’intérêt d’avoir mis un marqueur de traçage dans le programme (Made with FUSION-C 1.3 R11211 (c)EBSOFT:2020) ? C’est pas le genre de chose qu’on est censé trouver dans une lib gratuite et open-source. Surtout que ça fait perdre quelques précieux octets.
Voilà pour les remarques pour le moment.
Malgré ces quelques réserves, je trouve que la libraire est effectivement bien riche et qu’elle est déjà très cool.
Ma lib perso correspond mieux à mes besoins, mais j’suis sûr que Fusion-C corresponds aux attentes de bcp de gens et que ça sera encore plus le cas avec cette version 1.3.
Je dirais que le seul vrai problème actuellement, c’est le côté parfois un peu fouillis pour s’y retrouver, mais ça devrait pouvoir s’améliorer facilement.
J'espère que ces retours te seront utiles.
Je vais travailler sur le module de son de ma lib ; j’en profiterai pour regarder le problème dont tu m’avais parlé avec ton code pt3.
On est toujours ignorant avant de savoir.
@aoineko
Merci pour ces remarques que je vais prendre en compte. Même si sans doute je ne vais pas toutes les appliquer, ca me fait progresser.
Il y a certaines de tes remarques que je ne comprend pas, je te demanderai plus d'explications ultérieurement.
Pour "justifier" un peut ce joyeux "bordel" et mon manque de respect des conventions, c'est que je ne suis pas un pro dans le domaine, je fais tout un peu à ma "sauce"
A l'origine ce projet de librairie était destiné à mon seul usage, puis je me suis dit que c'était un peu bête de ne pas partager mon travail avec la communauté, car très certainement d'autres personnes pourraient en avoir usage. Donc, j'ai poussé un peu plus les choses pour faire quelque chose de sympathique à utiliser sans trop se prendre la tête sur les moyens de programmer en C pour MSX, et surtout quelques chose d'automatisé.
Bref, je ne suis pas contre le fait de standardiser tout ça Et ton aide est précieuse, vu que dans une seule t^te il y a moins d'idées que dans plusieurs
Je reviens plus tard avec des modifs et des question ...
Edité par ericb59 Le 16/11/2020 à 11h32
Merci pour ces remarques que je vais prendre en compte. Même si sans doute je ne vais pas toutes les appliquer, ca me fait progresser.
Il y a certaines de tes remarques que je ne comprend pas, je te demanderai plus d'explications ultérieurement.
Pour "justifier" un peut ce joyeux "bordel" et mon manque de respect des conventions, c'est que je ne suis pas un pro dans le domaine, je fais tout un peu à ma "sauce"
A l'origine ce projet de librairie était destiné à mon seul usage, puis je me suis dit que c'était un peu bête de ne pas partager mon travail avec la communauté, car très certainement d'autres personnes pourraient en avoir usage. Donc, j'ai poussé un peu plus les choses pour faire quelque chose de sympathique à utiliser sans trop se prendre la tête sur les moyens de programmer en C pour MSX, et surtout quelques chose d'automatisé.
Bref, je ne suis pas contre le fait de standardiser tout ça
Et ton aide est précieuse, vu que dans une seule t^te il y a moins d'idées que dans plusieurs Je reviens plus tard avec des modifs et des question ...
Edité par ericb59 Le 16/11/2020 à 11h32
Répondre
Vous n'êtes pas autorisé à écrire dans cette catégorie