Citation de RedBug le 15 juin 2020, 21 h 04 min

@cpcitor BriXen n’utilise pas cpctelera. Juste quelques fonctions de la cpcrslib, sdcc et ses propres fonctions asm.

pour les mouvements a l'écran, il y a bien plus que la boule 😉 Chaque brique affichée est animée lorsque l’interrupteur est actif. Et je garde aussi du 50fps tous le long du jeu ce qui fait que le jeu reste fluide tout le temps.

J’ai débuté un tuto sur la creation de BriXen sur http://crazypiri.eu en espérant que cela puisse inspirer de futur de développeurs sur notre machine préférée 

 

Citation de cpcitor le 16 juin 2020, 7 h 50 min

Merci @miguelvanhove pour ces précisions.

Très bien d'avoir commencé une série de petits tutoriels. Je regarderai.

J'ai l'impression que cptc-docker existe mais n'est pas public.

git clone git@github.com:Crazy-Piri/cptc-docker.git

Clonage dans 'cptc-docker'...
ERROR: Repository not found.
fatal: Impossible de lire le dépôt distant.

Veuillez vérifier que vous avez les droits d'accès
et que le dépôt existe.

Citation de RetroPoke le 16 juin 2020, 8 h 27 min

@RedBug super ton tuto, je vais installer un système Linux sur un vieux PC pour tester tous ça ! 

Citation de RedBug le 16 juin 2020, 9 h 26 min

@cpcitor

Oups, il était effectivement en privé.. C'est corrigé.

@retropoke

Pas besoin d'un linux 😉 Un pc suffit. Cela demande juste d'installer docker qui est multiplateforme

 

 

Citation de cpcitor le 16 juin 2020, 21 h 51 min

réécriture

Merci @miguelvanhove pour l'accès au repo. Je vois que tu as regardé le contenu de cpc-dev-tool-chain, notamment les options pour compiler SDCC (avec juste les modules intéressants pour le Z80) et repris les lignes pour extraire les adresses du log de hex2bin ou sdcc. Et tu as écrit un court script en remplacement du sdcc-project.Makefile.

C'est très minimal, j'apprécie beaucoup les choses minimales. C'est comme ça que cpc-dev-tool-chain a commencé. cptc est comme une réécriture en piochant quelques pourcents de l'existant.

cpc-dev-tool-chain, qualités, défauts

J’ai essayé divers environnements de developpement tels que CPCtelera, cpc-dev-tool-chain mais aucun ne m’a satisfait à 100%.

Ce serait très intéressant si tu pouvais détailler un peu. cpc-dev-tool-chain a plein de fonctionnalités avancées, mais un peu comme un couteau suisse tu vois plein de lames sans trop savoir à quoi elles servent de si formidable. Je le maintiens un peu comme je contribuerai à un projet tiers : en regardant dans l'historique git comment les fonctionnalités ont été ajoutées, par exemple Integrate exomizer. · cpcitor/cpc-dev-tool-chain@8583e4d . Rasm est un ajout récent par exemple. Tout est architecturé autour de make, donc confortable si on connaît make : "j'explique comment transformer un fichier source X en fichier Y, et l'outil se débrouillera tout seul pour arriver au but".

Cela fait quelques temps que j'envisage de réécrire cpc-dev-tool-chain avec d'autres outils avec une approche complètement différente. L'écriture actuelle est conçue dans l'idée de dépendre du moins de choses possibles, et de choses universellement disponibles (type gcc, make). Maintenant que Docker est répandu c'est plus souple, c'est un bon moment pour revoir. Je verrai quand j'aurai un peu de temps...

cpcrslib

Je pensais que cpcrslib était considéré comme surpassé par CPCtelera.

Note pour ceux qui n'ont pas testé, cpcrslib est supporté par cpc-dev-tool-chain aussi : dès qu'un des fichiers C du projet fait un #include de cpcrslib, la toolchain ajoute automatiquement les chemins pour l'étape compilation et l'étape édition de liens.

cptc ?

@miguelvanhove quel avenir vois-tu pour cptc ? Est-ce un outil pour toi que tu partages par transparence ? Quelque chose que tu souhaites développer, mettre en avant, documenter, différent de ce qui existe ? (Une des forces de CPCtelera est le gros travail de documentation. Je trouve que CPCtelera est alourdi par certains choix qui ont été faits, mais au moins c'est très bien documenté.)

Fiou, je pose beaucoup de questions... 🙂

 

Citation de RedBug le 17 juin 2020, 13 h 57 min

Ehéh.. Mes réponses dans le désordre:

• Je n'ai aucune idée de l'avenir du cptc. Actuellement, je l'ai mis sur GitHub juste par transparence. Pour expliquer mon process de développement dans BriXen. Chaque mise à jour du toolchain peut casser la compatibilité avec un ancien projet et je ne mettrai pas de numéro de version du toolchain (et donc, je ne conseille pas de l'utiliser)
• Pour cpcrslib, comme tu as vu, il n'est pas dans le toolchain mais dans le projet template. Je m'en sers juste comme étant un repository de fonction ASM pouvant accélerer l'éxecution de mon code. Si je trouve une fonction dans la cpctelera, je ferais un extract de cette fonction (si c'est possible) et l'utiliserai aussi.
  Et c'est justement pour ça que j'utilise cpcrslib, une fonction peut-être retirée de son contexte facilement. Après, j'avoue ne pas bien connaitre cpctelera même si leur documentation est effectivement bien faite (rien que la description du temps machine pris par une fonction est déjà excellent). 
• Pour cpc-dev-tool-chain, je le trouvais trop verbeux et pas facile à intégrer à mon flux de developpement avec Visual Studio code. Il me fallait facilement pouvoir compiler mon projet et avoir un retour des mes erreurs lors de la compilation. Après, il est excellent et à conseiller pour les personnes à la recherche de rigueur. 
  Je suis effectivement parti de ton travail pour cdtc et du dockerfile que je t'avais envoyé (9 décembre 2019) pour faire le docker Crazy Piri ;). Si je n'étais plus dans l'urgence du developpement de BriXen, j'aurai du approfondir ton toolchain. Je ne suis pas convaincu de l'utilité de multiplier les environnements de developpement sur Amstrad. Nous ne sommes pas assez de développeurs que pour disperser tout le monde.
• Pour l'utilisation du make, je l'ai retiré parce que je ne le connais pas assez que pour faire des scripts complexes. (Mais je l'utilise dans CrocoDS :p)