La Place des Développeurs FUSION-C Codez en C pour MSX les doigts dans le nez !
Reprise du message précédent
pour les curieux, voila ce que ça donne actuellement S......... W... Edité par RibbSayan Le 25/07/2020 à 11h31
J'ai trouvé aussi une solution qui finalement s'apparente à ta solution de changer de page active !
Et je viens juste de lire ton message aussi en allant écrire ma réponse.
Solution :
VDPwriteNi(2,0b00111111);
En gros, on demande au vdp d'afficher l'écran à partir de l'adresse 0x8000 (équivalent à la page active 1) et non plus en 0x0000 (qui correspond la page active 0)
Du coup, plus besoin de déplacer les tables de sprites, de patterns, de couleurs et de palette (qui effectivement se trouve bien dans la partie invisible -entre 212 et 255- de la page 0)
Merci encore.
Et je viens juste de lire ton message aussi en allant écrire ma réponse.
Solution :
VDPwriteNi(2,0b00111111);
En gros, on demande au vdp d'afficher l'écran à partir de l'adresse 0x8000 (équivalent à la page active 1) et non plus en 0x0000 (qui correspond la page active 0)
Du coup, plus besoin de déplacer les tables de sprites, de patterns, de couleurs et de palette (qui effectivement se trouve bien dans la partie invisible -entre 212 et 255- de la page 0)
Merci encore.
Pas mal du tout RibbSayan. J'espère que tu iras au bout de ce projet et que tu fourniras le code source. Je suis un militant de la libération des codes source 
comme le dit TurboSeb, c'est un Set Page 1 que tu fais avec : VDPwriteNi(2,0b00111111);
Registre 2 du VDP
dans les mode graphique MSX2,
bits 0 à 4 : sont toujours à 1
bits 5 et 6 : déterminent le numéro de page (Ce qui effectivement change l'adresse comme tu le dis)
bit 7 : toujours à 0
donc tu peux remplacer ça part un SetDisplayPage(1);
ce qui aura pour avantage de mettre les variables système à jour, lesquelles qui sont utilisées par d'autres fonctions.
Edité par ericb59 Le 26/07/2020 à 10h57
comme le dit TurboSeb, c'est un Set Page 1 que tu fais avec : VDPwriteNi(2,0b00111111);
Registre 2 du VDP
dans les mode graphique MSX2,
bits 0 à 4 : sont toujours à 1
bits 5 et 6 : déterminent le numéro de page (Ce qui effectivement change l'adresse comme tu le dis)
bit 7 : toujours à 0
donc tu peux remplacer ça part un SetDisplayPage(1);
ce qui aura pour avantage de mettre les variables système à jour, lesquelles qui sont utilisées par d'autres fonctions.
Edité par ericb59 Le 26/07/2020 à 10h57
C'est bizarre, j'avais cru avoir essayé SetDisplayPage(1) et que cela n'avait pas fonctionné... Mais là, ça fonctionne bien (et c'est sûrement à cause de moi 
)
Effectivement, je n'écris pas de code secret, il sera libéré.
Allez j'y retourne, parce que je suis une équipe de un. Et si je ne m'y mets pas, ca n'avance pas
)Effectivement, je n'écris pas de code secret, il sera libéré.
Allez j'y retourne, parce que je suis une équipe de un. Et si je ne m'y mets pas, ca n'avance pas
Salut Eric,
Déjà bravo pour ta lib Fusion-C ; je commence tout juste à jeter un œil mais ça à l'air bien complet !
Je me demandais pourquoi tu n'utilisais pas l'envoie séquentiel des commandes aux VDP ? Ou j'ai raté un truc ?
Avec les outi tu peux envoyer toutes tes commandes les unes derrières les autres bien plus vite à ce qu'on m'avait dit.
La seule contrainte c'est que tes paramètres soient séquencés dans le bon ordre coté RAM CPU.
Dans ma mini-lib, j'utilisais une structure pour m'assurer que les données à envoyer étaient toujours bien agacées.
EDIT : Ah si, en fait tu utilises la technique pour fLMMM. Du coup, j'image que tu as juste pas encore eu le temps de faire les autres fonctions.
Déjà bravo pour ta lib Fusion-C ; je commence tout juste à jeter un œil mais ça à l'air bien complet !
Je me demandais pourquoi tu n'utilisais pas l'envoie séquentiel des commandes aux VDP ? Ou j'ai raté un truc ?
Avec les outi tu peux envoyer toutes tes commandes les unes derrières les autres bien plus vite à ce qu'on m'avait dit.
La seule contrainte c'est que tes paramètres soient séquencés dans le bon ordre coté RAM CPU.
Dans ma mini-lib, j'utilisais une structure pour m'assurer que les données à envoyer étaient toujours bien agacées.
EDIT : Ah si, en fait tu utilises la technique pour fLMMM. Du coup, j'image que tu as juste pas encore eu le temps de faire les autres fonctions.
On est toujours ignorant avant de savoir.
effectivement...
Dans la version 1.3 (a venir) j'ai utilisé cette technique autant que possible pour toutes les fonctions VDP.
ce qui m'a permis d'augmenter la vitesse d'exécution...
Dans la version 1.3 (a venir) j'ai utilisé cette technique autant que possible pour toutes les fonctions VDP.
ce qui m'a permis d'augmenter la vitesse d'exécution...
J'avais fait une fonction générique qui gère toutes les commandes VDP via une structure C.
Et voici le code C :
Je ne me souviens plus exactement pourquoi j'avais mis une série de [font= courier new]outi[/font] plutôt qu'une boucle [font= courier new]outir[/font] ; c'était p'être une question de performance.
Et sinon, j'aurais 2 remarques sur Fusion-C :
Après, c'est juste des préférences personnelles. Mais comme tu bosses sur une nouvelle version, je pense que ça pouvais être utile de partager mon point de vue.
Encore bravo pour tout le boulot accompli et bonne continuation !
Code C :
//---------------------------------------- // M A C R O S #define VDP_REG(num) #(0x80+num) #define HMMC(dx, dy, nx, ny, ram) { vdp.cmd.DX = dx; vdp.cmd.DY = dy; vdp.cmd.NX = nx; vdp.cmd.NY = ny; vdp.cmd.CLR = ((u8*)ram)[0]; vdp.cmd.CMD = VDP_CMD_HMMC; VPDCommand36((u16)&vdp.cmd+4); VPDCommandLoop(ram); } #define YMMM(sy, dx, dy, nx, ny) { vdp.cmd.SY = sy; vdp.cmd.DX = dx; vdp.cmd.DY = dy; vdp.cmd.NX = nx; vdp.cmd.NY = ny; vdp.cmd.CMD = VDP_CMD_YMMM; VPDCommand32((u16)&vdp.cmd); } #define HMMM(sx, sy, dx, dy, nx, ny) { vdp.cmd.SX = sx; vdp.cmd.SY = sy; vdp.cmd.DX = dx; vdp.cmd.DY = dy; vdp.cmd.NX = nx; vdp.cmd.NY = ny; vdp.cmd.CMD = VDP_CMD_HMMM; VPDCommand32((u16)&vdp.cmd); } #define HMMV(dx, dy, nx, ny, col) { vdp.cmd.DX = dx; vdp.cmd.DY = dy; vdp.cmd.NX = nx; vdp.cmd.NY = ny; vdp.cmd.CLR = col; vdp.cmd.CMD = VDP_CMD_HMMV; VPDCommand36((u16)&vdp.cmd+4); } #define LMMC(dx, dy, nx, ny, ram, op) { vdp.cmd.DX = dx; vdp.cmd.DY = dy; vdp.cmd.NX = nx; vdp.cmd.NY = ny; vdp.cmd.CLR = ((u8*)ram)[0]; vdp.cmd.CMD = VDP_CMD_LMMC + op; VPDCommand36((u16)&vdp.cmd+4); VPDCommandLoop(ram); } #define LMCM(sx, sy, nx, ny, ram) /* not implemented */ #define LMMM(sx, sy, dx, dy, nx, ny, op) { vdp.cmd.SX = sx; vdp.cmd.SY = sy; vdp.cmd.DX = dx; vdp.cmd.DY = dy; vdp.cmd.NX = nx; vdp.cmd.NY = ny; vdp.cmd.CMD = VDP_CMD_LMMM + op; VPDCommand32((u16)&vdp.cmd); } #define LMMV(dx, dy, nx, ny, col, op) { vdp.cmd.DX = dx; vdp.cmd.DY = dy; vdp.cmd.NX = nx; vdp.cmd.NY = ny; vdp.cmd.CLR = col; vdp.cmd.CMD = VDP_CMD_LMMV + op; VPDCommand36((u16)&vdp.cmd+4); }
Et voici le code C :
Code C :
/** * Commande VDP (écriture registres 32 à 46) */ void VPDCommand32(u16 address) { WaitForVDP(); __asm ld l,4(ix) ld h,5(ix) //; Envoi données VDP ld a,#32 //; R32 avec incrémentation di out (VDP_ADDR),a ld a,VDP_REG(17) out (VDP_ADDR),a //; Ecriture séquentielle ld c,VDP_ADDR+#2 //; Port séquentiel outi outi outi outi outi outi outi outi outi outi outi outi outi outi ei //; "EI" anticipé outi __endasm; } /** * Commande VDP (écriture registres 36 à 46) */ void VPDCommand36(u16 address) { WaitForVDP(); __asm ld l,4(ix) ld h,5(ix) ;// Envoi données VDP ld a,#36 ;// R36 avec incrémentation di out (VDP_ADDR),a ld a,VDP_REG(17) out (VDP_ADDR),a ;// Ecriture séquentielle ld c,VDP_ADDR+#2 ;// Port séquentiel outi outi outi outi outi outi outi outi outi outi ei ;// "EI" anticipé outi __endasm; }
Je ne me souviens plus exactement pourquoi j'avais mis une série de [font= courier new]outi[/font] plutôt qu'une boucle [font= courier new]outir[/font] ; c'était p'être une question de performance.
Et sinon, j'aurais 2 remarques sur Fusion-C :
- Je trouve dommage que toutes tes fonctions ASM ne soient pas encapsulées dans du code C. Il n'y a pas de surcout (j'avais check le code ASM généré) et je trouve ça plus facile à lire, ça permet de pouvoir utiliser les macros C dans le code ASM et de centraliser le code.
- Je trouve également dommage que ton code ne soit pas vraiment rangé par "lib". Dans le philosophie C, tu devrais avoir un fichier .C et un fichier .H avec une liste de fonctionnalité. Là, il y a pas toujours unicité entre les fichiers sources et les headers. Du coup, c'est pas simple de s'y retrouver. J'ai l'impression que tu as beaucoup subdivisé le code pour que l'utilisateur puisse n'inclure que ce qu'il souhaite (et limiter la taille du programme final), mais tu pourrais avoir le même résultat avec par ex. une grosse lib "Graphic1.c/h" contenant toutes les fonctions nécessaires pour l'affichage MSX1 et un système de macro qui permet à l'utilisateur de sélectionner les fonctions dont il a besoin.
Après, c'est juste des préférences personnelles. Mais comme tu bosses sur une nouvelle version, je pense que ça pouvais être utile de partager mon point de vue.
Encore bravo pour tout le boulot accompli et bonne continuation !
On est toujours ignorant avant de savoir.
Oui j'ai aussi ajouté une fonction VDP générique dans la Version 1.3
Elle s'appelle : fVDP (void *parameters)
On lui passe une structure de ce type :
Pour gagner de Laplace dans le code c'est bien, mais je trouve que la lisibilité des sources et moindre quand in utilise des fonctions générique.
J'ai donc gardé chaque fonction en indépendant aussi.
Pour l'encapsulation du code... Oui... Ben ca depends de quoi j'ai besoin en fait. Si j'arrive à tout faire en ASM ou pas...
Je destinais FUSION-C plus aux codeurs débutants et intermédiaires, qui s'en foute du code source en fait.
C'est exacte il n'y a pas de liens directes avec les headers et les sources. J'ai pas trouvé ça nécessaire, encore une fois, aux vus de l'objectif que je m'étais fixé.
Par contre c'est vrai que j'ai trop subdivisé les codes sources en de multiples petits fichiers. C'était une erreur, car on ne s'y retrouve plus.
Je suis revenu sur ça, j'ai regroupé beaucoup les sources dans des fichiers plus organisés, et j'ai aussi créer un "Catalogue de sources" qui indique par fonction, où se trouve le code source.
Je ne comprend pas ce que tu veux dire
Actuellement le linkage se fait de façon dynamique depuis le fichier pré-compilé fusion-c/lib/fusion.lib, seules les fonctions utilisées dans le listing C sont intégré dans programme final.
Je suis preneur de toute idée pour améliorer Fusion-C
Edité par ericb59 Le 05/11/2020 à 15h06
Elle s'appelle : fVDP (void *parameters)
On lui passe une structure de ce type :
Code C :
typedef struct { unsigned int SX; // source X (0 to 511) unsigned int SY; // source Y (0 to 1023) unsigned int DX; // destination X (0 to 511) unsigned int DY; // destination Y (0 to 1023) unsigned int NX; // width (0 to 511) unsigned int NY; // height (0 to 511) char COL; // color used by some commands. or 0 if not used char DI; // Parameters set the direction : opDOWN | opRIGHT char CMD; // VDP Comd + Logical Operator : opLMMM | LOGICAL_TIMP } FastVDP;
Pour gagner de Laplace dans le code c'est bien, mais je trouve que la lisibilité des sources et moindre quand in utilise des fonctions générique.
J'ai donc gardé chaque fonction en indépendant aussi.
Pour l'encapsulation du code... Oui... Ben ca depends de quoi j'ai besoin en fait. Si j'arrive à tout faire en ASM ou pas...
Je destinais FUSION-C plus aux codeurs débutants et intermédiaires, qui s'en foute du code source en fait.
C'est exacte il n'y a pas de liens directes avec les headers et les sources. J'ai pas trouvé ça nécessaire, encore une fois, aux vus de l'objectif que je m'étais fixé.
Par contre c'est vrai que j'ai trop subdivisé les codes sources en de multiples petits fichiers. C'était une erreur, car on ne s'y retrouve plus.
Je suis revenu sur ça, j'ai regroupé beaucoup les sources dans des fichiers plus organisés, et j'ai aussi créer un "Catalogue de sources" qui indique par fonction, où se trouve le code source.
Citation :
tu pourrais avoir le même résultat avec par ex. une grosse lib "Graphic1.c/h" contenant toutes les fonctions nécessaires pour l'affichage MSX1 et un système de macro qui permet à l'utilisateur de sélectionner les fonctions dont il a besoin.
Je ne comprend pas ce que tu veux dire
Actuellement le linkage se fait de façon dynamique depuis le fichier pré-compilé fusion-c/lib/fusion.lib, seules les fonctions utilisées dans le listing C sont intégré dans programme final.
Je suis preneur de toute idée pour améliorer Fusion-C
Edité par ericb59 Le 05/11/2020 à 15h06
ericb59 :
Actuellement le linkage se fait de façon dynamique depuis le fichier pré-compilé fusion-c/lib/fusion.lib, seules les fonctions utilisées dans le listing C sont intégré dans programme final.
Tu as vérifié ? Dans mon souvenir, c'était pas le cas.
Une fonction même "non utilisée" était compilée et linké dans le programme final (augmentant sa taille).
Ce qui me semble logique vu que tu peux avoir des pointeurs de fonctions C et que le compilateur ne peux donc pas savoir à l'avance les valeurs qu'ils auront et donc les fonctions qui seront appelées.
En tout cas, l'idée était de pouvoir supprimer du code directement à la compilation sans avoir besoin de toucher au linker en utilisant des macros.
Par ex. :
Code C :
#define USE_GROUP1 1 #define USE_GROUP2 0 #if USE_GROUP1 void A() { /* some code */ }; void B() { /* some code */ }; #endif // USE_GROUP1 #if USE_GROUP2 void C() { /* some code */ }; void D() { /* some code */ }; #endif // USE_GROUP2
Après, c'est pas nécessairement une bonne idée de le faire fonction par fonction, mais si dans une librairie tu as une poignée de fonctions que tu voudrais rendre optionnelles, dans certains cas, cette technique peut être intéressant plutôt que de créer une lib à part.
Je vais essayer de faire un p'tit programme de test avec Fusion-C comme ça je pourrais te faire d'autres retours.
On est toujours ignorant avant de savoir.
Citation :
Tu as vérifié ? Dans mon souvenir, c'était pas le cas.
Une fonction même "non utilisée" était compilée et linké dans le programme final (augmentant sa taille).
Ce qui me semble logique vu que tu peux avoir des pointeurs de fonctions C et que le compilateur ne peux donc pas savoir à l'avance les valeurs qu'ils auront et donc les fonctions qui seront appelées.
Une fonction même "non utilisée" était compilée et linké dans le programme final (augmentant sa taille).
Ce qui me semble logique vu que tu peux avoir des pointeurs de fonctions C et que le compilateur ne peux donc pas savoir à l'avance les valeurs qu'ils auront et donc les fonctions qui seront appelées.
Oui oui j'en suis certain.
Si tu utilises le script de compilation fournis avec avec fusion-C, ca n'intègre que le code des fonctions utilisées.
Example pour l'exemple fournis : Sprite-MSX1.c
voici la liste des objets linké
Code TEXT :
Files Linked [ module(s) ]
test.rel [ test ]
/Users/ericboez/Desktop/WorkingFolder/fusion-c/include/crt0_msxdos.rel
[ ]
Libraries Linked [ object file ]
/Users/ericboez/Desktop/WorkingFolder/fusion-c/lib/fusion.lib
[ CallBios_Functions.rel ]
/Users/ericboez/Desktop/WorkingFolder/fusion-c/lib/fusion.lib
[ vram.rel ]
/Users/ericboez/Desktop/WorkingFolder/fusion-c/lib/fusion.lib
[ VDPWrite_functions.rel ]
/Users/ericboez/Desktop/WorkingFolder/fusion-c/lib/fusion.lib
[ readmsxtype.rel ]
/Users/ericboez/Desktop/WorkingFolder/fusion-c/lib/fusion.lib
[ spritecollision.rel ]
/Users/ericboez/Desktop/WorkingFolder/fusion-c/lib/fusion.lib
[ setspritepattern.rel ]
/Users/ericboez/Desktop/WorkingFolder/fusion-c/lib/fusion.lib
[ call.rel ]
/Users/ericboez/Desktop/WorkingFolder/fusion-c/lib/fusion.lib
[ setbordercolor.rel ]
/usr/local/bin/../share/sdcc/lib/z80/z80.lib
[ puts.rel ]
/Users/ericboez/Desktop/WorkingFolder/fusion-c/lib/fusion.lib
[ vdpstatus.rel ]
/Users/ericboez/Desktop/WorkingFolder/fusion-c/lib/fusion.lib
[ printf.rel ]
/usr/local/bin/../share/sdcc/lib/z80/z80.lib
[ crtenter.rel ]
/usr/local/bin/../share/sdcc/lib/z80/z80.lib
[ modsigned.rel ]
/Users/ericboez/Desktop/WorkingFolder/fusion-c/lib/fusion.lib
[ vpoke-vpeek.rel ]
/usr/local/bin/../share/sdcc/lib/z80/z80.lib
[ divsigned.rel ]
/Users/ericboez/Desktop/WorkingFolder/fusion-c/lib/fusion.lib
[ CallDos_Functions.rel ]
/usr/local/bin/../share/sdcc/lib/z80/z80.lib
[ divunsigned.rel ]
/usr/local/bin/../share/sdcc/lib/z80/z80.lib
[ _itoa.rel ]
/usr/local/bin/../share/sdcc/lib/z80/z80.lib
[ _ltoa.rel ]
/usr/local/bin/../share/sdcc/lib/z80/z80.lib
[ _divulong.rel ]
/Users/ericboez/Desktop/WorkingFolder/fusion-c/lib/fusion.lib
[ port_in-out.rel ]
/usr/local/bin/../share/sdcc/lib/z80/z80.lib
[ modunsigned.rel ]
/usr/local/bin/../share/sdcc/lib/z80/z80.lib
[ _modulong.rel ]
Tu peux choisir les objets que tu link, mais toutes les fonctions que contiennent ces objets seront ajoutées dans le binaire de ton programme final, même si tu n'en utilises qu'une seule.
Après, c'est cohérent avec ton choix d'avoir une librairie statique.
Perso, j'ai besoin de modularité et de pouvoir facilement optimiser ma lib au besoin de mon programme. C'est pourquoi j'ai inclut la compile/link de ma lib en même temps que celle de mon programme (c'est tellement rapide avec SDCC qu'on voit pas la différence). Ca me permet de pouvoir contrôler précisément ce que contient mon programme (via les macros).
Après, c'est cohérent avec ton choix d'avoir une librairie statique.
Perso, j'ai besoin de modularité et de pouvoir facilement optimiser ma lib au besoin de mon programme. C'est pourquoi j'ai inclut la compile/link de ma lib en même temps que celle de mon programme (c'est tellement rapide avec SDCC qu'on voit pas la différence). Ca me permet de pouvoir contrôler précisément ce que contient mon programme (via les macros).
On est toujours ignorant avant de savoir.
Alors, après quelques tests, voici des commentaires en vrac. Encore une fois, c’est un avis subjectif que j’espère utile :
1) Dans la version 1.2, tous les fichiers de \source\lib\ sont inclus dans ta lib ; tu devrais split un peu. Par ex., tout ce qui concerne le traitement des chaînes de caractères devraient être à part car ce n’est pas utile pour pas mal de jeux.
2) Généralement dans les libs C, les fichiers d’entête se trouvent dans un répertoire /include/ ; ça me fait bizarre qu’ils soient ailleurs et qu’on y trouve les libs compilés que je m’attendrais à trouver dans /libs/.
3) Ca serait bien que tes scripts de build ne supprimer pas les fichiers intermédiaires. Tu devrais les stocker dans un répertoire /out/ ou /intermediate/ car ils sont essentiels pour débuguer.
4) Tu devrais définir plein de #define ! Par ex., c’est tellement plus lisible je trouve d’écrire while(Inkey() != KEY_ESCAPE) que d’écrire while(Inkey() != 27).
L’avantage d’inclure ton code ASM dans des fichiers C, c’est que tu peux utiliser les macros du coup. Par ex., un truc du genre :
Voilà pour le moment.
Y a des trucs vraiment très sympa mais personnellement, je trouve ça trop monolithique pour mes besoins.
Ce qui serait génial, c’est que tu regroupes ce qui concerne un même sujet dans un module avec 1 fichier .h et 1 fichier .rel (et le .c).
Un module FILE, un module MOUSE, un module PT3PLAYER, etc.
Ca t’empêche pas de faire un package tout en un pour les gens que ça intéresse, mais ça permettrait à ceux qui ont déjà une base de programme en C, de pouvoir inclure juste les modules Fusion-C dont ils ont besoin dans leur propre environnement.
Je sais que ça dépasse le cadre de ton projet, mais je pense pas être le seul à qui ça pourrait être utile.
Pour l'ex., je vais essayer de porter le player de Pt3 dans ce format ; tu me dira ce que tu en penses.
1) Dans la version 1.2, tous les fichiers de \source\lib\ sont inclus dans ta lib ; tu devrais split un peu. Par ex., tout ce qui concerne le traitement des chaînes de caractères devraient être à part car ce n’est pas utile pour pas mal de jeux.
2) Généralement dans les libs C, les fichiers d’entête se trouvent dans un répertoire /include/ ; ça me fait bizarre qu’ils soient ailleurs et qu’on y trouve les libs compilés que je m’attendrais à trouver dans /libs/.
3) Ca serait bien que tes scripts de build ne supprimer pas les fichiers intermédiaires. Tu devrais les stocker dans un répertoire /out/ ou /intermediate/ car ils sont essentiels pour débuguer.
4) Tu devrais définir plein de #define ! Par ex., c’est tellement plus lisible je trouve d’écrire while(Inkey() != KEY_ESCAPE) que d’écrire while(Inkey() != 27).
L’avantage d’inclure ton code ASM dans des fichiers C, c’est que tu peux utiliser les macros du coup. Par ex., un truc du genre :
Code ASM :
out (VDP_ADDR),a ld a,VDP_REG(17)
Voilà pour le moment.
Y a des trucs vraiment très sympa mais personnellement, je trouve ça trop monolithique pour mes besoins.
Ce qui serait génial, c’est que tu regroupes ce qui concerne un même sujet dans un module avec 1 fichier .h et 1 fichier .rel (et le .c).
Un module FILE, un module MOUSE, un module PT3PLAYER, etc.
Ca t’empêche pas de faire un package tout en un pour les gens que ça intéresse, mais ça permettrait à ceux qui ont déjà une base de programme en C, de pouvoir inclure juste les modules Fusion-C dont ils ont besoin dans leur propre environnement.
Je sais que ça dépasse le cadre de ton projet, mais je pense pas être le seul à qui ça pourrait être utile.
Pour l'ex., je vais essayer de porter le player de Pt3 dans ce format ; tu me dira ce que tu en penses.
On est toujours ignorant avant de savoir.
aoineko :
Tu peux choisir les objets que tu link, mais toutes les fonctions que contiennent ces objets seront ajoutées dans le binaire de ton programme final, même si tu n'en utilises qu'une seule.
.
.
Ha oui tu as raison. J'étais persuadé qu'il n'intégrait que les fonctions de chaque objet.
Je vais devoir scinder mes fonctions qui n'ont aucune dépendance dans ce cas.
Ta méthode est très bien. Mais cela nécessite un travail que je ne souhaites pas imposer aux utilisateurs de Fusion-c. Ca complique les choses, meme si cela s'avère interessant au final.
Citation :
2) Généralement dans les libs C, les fichiers d’entête se trouvent dans un répertoire /include/ ; ça me fait bizarre qu’ils soient ailleurs et qu’on y trouve les libs compilés que je m’attendrais à trouver dans /libs/.
Oui j'ai fait cette erreur au début avec la version 1.0
Est-ce que je dois corriger aujourd'hui pour me conformer à l'usage quitte à perdre ceux qui ont fini par s'y faire ? Je me pose la question.
Citation :
3) Ca serait bien que tes scripts de build ne supprimer pas les fichiers intermédiaires. Tu devrais les stocker dans un répertoire /out/ ou /intermediate/ car ils sont essentiels pour débuguer.
Oui je peux faire ça.
Citation :
4) Tu devrais définir plein de #define ! Par ex., c’est tellement plus lisible je trouve d’écrire while(Inkey() != KEY_ESCAPE) que d’écrire while(Inkey() != 27).
Je considère que c'est au codeur final de faire ce travail. Je ne vois pas pourquoi j'imposerais mes propres macros et défini si je peux l'éviter.
Citation :
Pour l'ex., je vais essayer de porter le player de Pt3 dans ce format ; tu me dira ce que tu en penses.
Pour la version 1.3 j'ai un nouveau code pour jouer PT3 + AYFX en même temps. Mais il y a bug avec certains sons qui ne veulent pas s'arrêter.
J'ai soumis le problème à un autre codeur, qui n'a pas trouvé d'où venait le problème.
Est-ce que tu peux y regarder ?
Pour tout ce qui touche au [font= courier new]define[/font] c'est des choses que tu peux ajouter dans des [font= courier new].h[/font], donc optionnels.
Par rapport à la philosophie user-friendly de ta lib, je trouve que ça rendrait les choses plus simple. Mais bon, c'est à toi de voir.
En parlant de [font= courier new].h[/font], j'avais fait un p'tit tool pour générer des tableaux de transformation mathématique pour pouvoir faire des calculs bcp plus rapide.
On peux choisir une opération (sqrt, cos, sin, etc.), le format (virgule fixe avec shift sur 8/16 bits) et la taille du tableau (la précision).
Si tu veux, je peux te fournir les fichiers [font= courier new].h[/font] générés et/ou le tool pour les générer (en CC-BY-AS).
Je suis pas super à l'aise avec l'ASM, mais je vais jeter un œil.
Ca fait 22 ans que je fais du C en pro, mais l'ASM, c'est juste pour le plaisir.
Si tu veux, je peux beta-téster la version 1.3.
Par rapport à la philosophie user-friendly de ta lib, je trouve que ça rendrait les choses plus simple. Mais bon, c'est à toi de voir.
En parlant de [font= courier new].h[/font], j'avais fait un p'tit tool pour générer des tableaux de transformation mathématique pour pouvoir faire des calculs bcp plus rapide.
On peux choisir une opération (sqrt, cos, sin, etc.), le format (virgule fixe avec shift sur 8/16 bits) et la taille du tableau (la précision).
Si tu veux, je peux te fournir les fichiers [font= courier new].h[/font] générés et/ou le tool pour les générer (en CC-BY-AS).
ericb59 :
Pour la version 1.3 j'ai un nouveau code pour jouer PT3 + AYFX en même temps. Mais il y a bug avec certains sons qui ne veulent pas s'arrêter.
J'ai soumis le problème à un autre codeur, qui n'a pas trouvé d'où venait le problème.
Est-ce que tu peux y regarder ?
J'ai soumis le problème à un autre codeur, qui n'a pas trouvé d'où venait le problème.
Est-ce que tu peux y regarder ?
Je suis pas super à l'aise avec l'ASM, mais je vais jeter un œil.
Ca fait 22 ans que je fais du C en pro, mais l'ASM, c'est juste pour le plaisir.
Si tu veux, je peux beta-téster la version 1.3.
On est toujours ignorant avant de savoir.
Répondre
Vous n'êtes pas autorisé à écrire dans cette catégorie