L'ile au trésor ou l'histoire d'un vieux projet

21 septembre 2019

Vive le progrès !

Bonne nouvelle, Le jeu est pour ainsi dire presque terminé.

J'ai aussi terminé le manuel, expliquant comment lancer le jeu, s'en servir et donnant quelques conseils (rien de très long, 5 pages avec beaucoup d'images ;-) !)

De son coté, JB le daron a acheté un clavier midi qui lui permet de jouer directement des notes reconnues par Arkos Tracker II qui lui permettra de faire une musique d'intro pour le jeu.

Une fois terminée, je l'intègrerais aussi vite que possible afin qu'il puisse le faire en stream. Comme il me fournit la musique, je trouve normal de lui accorder la primeur du jeu. Mais je le diffuserais ensuite très vite.

Contrairement à ce que je pensais mon jeu ne sera pas pour l'instant compatible CPC464 + extension de ram et lecteur de disquette, la faute à une gestion de la mémoire en basic légèrement différente. Peut-être que je sortirais un jour, un correctif pour cela, mais cette configuration étant tout de même plutôt rare, ça n'était pas ma priorité. En tout cas, sur l'émulateur sugar box et sur l'émulateur caprice forever, réglés pour cette configuration le jeu plante pendant le chargement.

Je languis de pouvoir enfin diffuser ce jeu.

En tout cas, je suis épaté par tout les moyens à notre disposition pour développer pour le CPC, que ce soit les softs sur CPC comme Gos, ImpDraw, ou les softs sur PC permettant de faire des graphismes comme ConvImgCPC, convwav, Arkos Tracker II, rasm et j'en oublie...

Je savais que le CPC était capable de grandes choses, même si je l'avais lâchement abandonné, mais je n'aurai pas cru que ces possibilités deviennent aussi facilement accessibles à présent !

C'est grâce au travail de tout ces géniaux programmeurs qui ont non seulement partagé leur logiciels, mais aussi leur savoir à coup de streams, de documentation, de publications sur des forums et d'assistance envers les personnes moins expérimentées mais curieuses d'apprendre les arcanes du CRTC ;-) Et après ces initiés pouvaient répondre avec gratitude :

https://www.youtube.com/watch?v=ma7TL8jJT0A

Posté par eric_boulat à 17:53 - Commentaires [0] - Permalien [#]


01 juillet 2019

Rétrospective en prélude à la conclusion ???

Pour rappel, je m'étais donné pour objectif au départ de terminer ce jeu, en hommage à mon ami Bruno, décédé en janvier 2018.

Il y a presque 25 ans, en 1994, j'abandonnais la réalisation de ce jeu, face aux dernières difficultés du développement de ce jeu. Il s'agissait principalement de problème de mémoire disponible pour l'interpréteur basic. La lassitude après avoir testé et codé 40 tableaux sur 50, et ayant codé les 10 derniers à l'arrache sans même les avoir testé une fois, m'avait fait laisser tomber. Qui plus est, je démarrais mon apprentissage du PC, de windows, dont le confort était incomparable. J'allais faire de cet outil, et de cet apprentissage mon métier, et donc le CPC était remisé dans ma chambre, puis dans un carton. Bruno fit de même, mais on se disait qu'on le terminerait un jour.

En apprenant son décés, je me suis dit que si jamais mes disquettes fonctionnaient à nouveau, je terminerais ce projet. A présent, plus d'un an a passé, on pourrait croire que je traine, mais ça n'est qu'une partie de la vérité. La réalité c'est que j'ai fait bien plus que terminer ce projet. Lorsque Tarodius a fait son stream sur ma version béta le vendredi 30 novembre, cette béta représentait déjà une grosse refonte du projet initial et elle avait atteint tout les objectifs initiaux du projet. J'avais même revu l'ergonomie du jeu, d'une façon qui aurait certainement plut à Bruno. J'aurais très bien pu alors terminer de corriger quelques bugs et sortir le jeu, en janvier 2019.

Mais les critiques constructives des spectateurs de ce stream m'ont persuadé qu'il ne fallait pas en rester là. Tout d'abord, leurs remarques ont porté sur l'ergonomie, et il est vrai que même si elle était meilleure que l'initiale, elle laissait encore à désirer. Ce n'était pas forcément grand chose à coder mais ça rendrait le jeu nettement plus compréhensible. Ensuite, il fallait que j'améliore le scénario pour amener des indices. Bruno voulait un jeu exceptionnellement difficile, mais là, il y était allé très fort. On n'avait aucun indice ou presque, et même si la liste des verbes possibles étaient limités par l'ihm, il y en avait tout de même 22 ! Et à l'époque c'était pire encore car l'ihm demander de taper le verbe ! J'ai donc décidé d'utiliser la zone de réponse pour indiquer à chaque écran un petit élément de contexte, pour aiguiller plus ou moins subtilement le joueur. Puis j'ai ajouté comme ça se faisait parfois dans d'autres jeux d'aventures un système d'aide. Il suffira au joueur d'appuyer sur F1 pour obtenir une indication sur le tableau en cours.

Fort de ces évolutions et correctifs, j'ai été tenté de laisser le jeu à ce stade pour le publier enfin. Mais une autre remarque des spectateurs était le manque de son dans le jeu ainsi que d'une musique dans l'introduction. Plus tard, JB Le Daron me proposa même de me faire une musique spécialement pour mon jeu ! Parallèlement à ça, j'ai trouvé l'utilitaire convwav de Ludovic Deplanque, qui m'a permis de faire des samples sur CPC ! Je décidais donc de tenter d'en rajouter quelques uns ici ou là histoire de donner un petit plus que je n'aurais jamais pu imaginer à l'époque.

J'ai donc pour pouvoir jouer la musique du Daron, regardé du coté d'Arkos Tracker 2, et son auteur Julien Névo m'a bien aidé pour ça.

En parallèle, je me décidais enfin à taquiner pour de bon le fullscreen (qu'on appelait overscan avant) grace au logiciel graph'os et à l'aide de son auteur Amaury Durand (alias BDCIron). Je repris l'écran titre qu'avait fait Bruno et j'improvisais un peu avec d'abord gimp et convimgcpc puis graph'os pour faire cette image que j'ai déjà partagé.

L'ultime étape était donc de faire un programme qui affichait l'image que j'avais faite en fullscreen et qui jouait une musique d'Arkos Tracker 2 en même temps. La musique du Daron n'étant pas encore prête, je prenais donc un des exemples fournis avec le soft Arkos Tracker 2.

Avec la routine fournie par Amaury Durand, je faisais donc apparaître mon image, puis en intégrant l'appel à la routine de Julien Névo dans celle d'Amaury, le résultat fonctionnait à merveille. Le lanceur du jeu est donc presque prêt, il me reste plus qu'à intégrer la musique de JB le Daron quand elle sera prête. En attendant, je vais faire intégrer le lanceur tel quel dans le jeu, et refaire une recette complète pour m'assurer que tout fonctionne.

Je compte aussi refaire la documentation du jeu, pour refaire les captures d'écran étant donné que j'ai changé de fonte.

test_arkos

Je partage donc ce lanceur, pour le tester, mettez cette disquette dans un émulateur (testé avec winape, caprice forever, sugar box, retro virtual machine et javaCPC)

 

Posté par eric_boulat à 21:11 - Commentaires [8] - Permalien [#]

23 juin 2019

On touche au but...

Non je ne vais pas me lancer sur une éloge ou au contraire une diatribe sur le foot ! (jeu de mot pourri : checked !).

A présent, après une énième phase de recette de bout en bout, j'ai pu corrigé 8 nouveaux bugs qui m'avaient échappé. Certains n'étaient pas vraiment des bugs, mais plutôt des réponses inadéquates du genre lorsque l'on a fait une action bien particulière, la réponse était juste "OK !" au lieu d'une réponse plus précise qui permet au joueur de vraiment s'apercevoir qu'il a réussi quelque chose.

Aucun de ces 8 bugs n'étaient bloquant, on pouvait quand même terminer le jeu mais ils pouvaient être pénibles. Le plus génant d'entre eux était qu'une des actions à faire n'était pas prise en compte la première fois qu'on la faisait, mais seulement la seconde fois. C'était une erreur dans mon code, une belle démonstration des limites de la programmation spaghettis.

A présent, je suis donc plus dans une phase cosmétique, je rajoute quelques bruitages basic et quelques samples. Pour ces derniers, ma limitation technique étant à 11000 hz et 1 bit d'encodage, font que je ne peux pas forcément mettre tout ce que je voudrais tellement le résultat peut être horrible. Ainsi un bête bruit de tiroir caisse, qui à la limite serait bien passé en encodage 4 bits, devient une agression auditive.

J'essaye aussi de faire une intro digne de ce nom, et du coup, j'ai fait le choix de faire un programme à part, qui affichera une image fullscreen et jouera une musique en même temps. J'ai d'ores et déjà réalisé l'image fullscreen avec Graph'os :

L'auteur de Graph'os Amaury Durand, va me fournir une routine assembleur pour afficher cette image dans mon programme d'intro. Mais avant cela, je dois déterminer à quelle adresse va se charger la routine qui jouera la musique. La musique va être faite par JB Le Daron qui utilisera pour cela Arkos Tracker 2.

Je dois donc étudier comment fonctionne ce logiciel windows qui produit des musiques pour Amstrad (ainsi que spectrum) et comment elles sont jouées sur nos CPC. Le sujet est assez technique, et je n'ai pour l'instant pas trouvé toutes les informations que j'aurai voulu.

Je verrais ensuite, s'il y a lieu de modifier le programme de fin que j'ai déjà fait. Il n'y a pas encore de musique, mais ce n'est pas forcément nécessaire.

En tout cas les choses avancent bien.

 

 

Posté par eric_boulat à 10:26 - Commentaires [0] - Permalien [#]

19 mai 2019

Les outils et leurs limites

Depuis le début de la reprise de ce projet en juin 2018, j'utilise un excellent outil manageDSK de Ludovic Deplanque. Il me permet d'extraire le contenu de disquettes virtuelles et de le modifier.

Sans cet outil, la reprise du projet aurait été fortement compromise. L'outil dispose d'une interface graphique facilitant ces manipulations et après un court apprentissage, on finit par en maîtriser tout les aspects. Le plus difficile a été de trouver comment récupérer les fichiers basic sous un format exploitable (ascii). En effet, lorsqu'un fichier basic est sauvegardé par défaut sur l'amstrad, il est en quelque sorte pré-digéré pour en rendre l'interprétation plus rapide. Sur l'amstrad ça reste transparent, et on peut continuer à éditer son source comme si de rien n'était. Mais par contre, lorsque l'on transfère ce fichier "pré-digéré" sur windows, le source est alors illisible. Heureusement l'outil manageDSK a une parade, et permet de retraduire ce source "pré-digéré" en un fichier ascii parfaitement exploitable sous windows.

Par contre, on constate rapidement 2 petits bugs :

  • Le premier, est qu'il supprime la dernière ligne du programme d'un fichier basic, si celle-ci ne se termine pas par un retour chariot. C'est embêtant, mais une fois qu'on le sait, on peut faire en sorte de contourner le problème.
  • Le second est plus contraignant, en fait tout les caractères accentués àéèê et surtout ù disparaissent lors de l'import de fichiers sur la disquette virtuelle.

Ce second problème implique donc à chaque import d'un fichier basic, de modifier le source directement sur l'émulateur.

Je m'étais habitué à cela, car tout au long du projet, j'ai principalement travaillé directement sur émulateur. Les rares fois, où je me suis servi d'un éditeur sous windows, pour des corrections massives, j'ai fait alors attention à ce détail !

A présent, que le projet est en bonne voie d'être fini, je dois prévoir un script pour construire des disquettes à partir des sources basic et des fichiers binaires du projet. Cela peut paraître surprenant, surtout à la fin du projet, mais il y a 2 raisons à celà :

  • Les dernières modifications que je souhaite faire supposent de beaucoup modifier la répartition des fichiers, en effet, je passe le jeu de 2 faces de disquettes à 4 !
  • J'ai pour objectif de mettre ce jeu en open source et par conséquent faire un script de build est un passage obligé.

Du coup, j'utilise toujours manageDsk qui peut aussi fonctionner en ligne de commande, mais malheureusement le bug sur les caractères accentués reste. Or j'utilise des RSX qui commencent par le caractère ù et donc la disparition de ce caractère entraine des syntax error au démarrage du jeu ! Mes nouvelles disquettes virtuelles nécessitent donc une correction manuelle, ce qui ruine une bonne partie de l'intérêt de faire un script de build.

Je vois 3 pistes pour résoudre cela :

  • Attendre une correction de l'outil manageDsk (je ne saurais pas la faire moi-même !)
  • Trouver un autre outil qui n'aurait pas ce problème.
  • Trouver un moyen de remplacer les appels RSX, par des call

La première solution me laisse du coup quasiment bloqué dans l'attente d'une hypothétique correction. Je me doute que ça doit être un problème complexe étant donné la diversité des jeux de caractères à gérer dans tout les cas.

La seconde solution, que j'ai bien sur déjà tenté sans succès, tout les outils que j'ai pu trouver sont orientés transfert de fichier binaires. A dire vrai, le transfert de fichiers binaires c'est le plus simple, puisqu'on ne touche à rien ! Ça fonctionne donc bien pour les fichiers compilés de l'assembleur, les images, les sons, mais pas pour les fichiers basic (hormis peut-être pour leur forme pré-digérée).

La troisième solution n'est pas vraiment bonne de toutes façons. Certes, l'absence du caractère ù est critique puisqu'elle entraîne une erreur de syntaxe au lancement, mais au delà de ça, j'utilise dans le title screen et dans les remerciements à la fin, des caractères accentués et ça m'embêterait de les supprimer.

Bref, pour le moment, ma seule solution est de me contenter d'un build qui ne fait tout son travail et de corriger mes sources manuellement sous émulateur.

Bon en tout cas, ça ne remet pas en cause, toute la gratitude que j'ai pour l'auteur de ce logiciel sans qui rien n'aurait été possible, et en plus il est aussi l'auteur du logiciel me permettant d'intégrer des samples, et aussi l'auteur de convimgcpc, qui m'a permis de faire le dernier écran manquant du jeu !

Bref, pour conclure, le projet continue d'avancer malgré tout. Je n'ai pas encore de date étant donné que je fais évoluer à la hausse le périmètre de ce que je veux intégrer dans le jeu, au fur et à mesure de mes découvertes.

 

Posté par eric_boulat à 12:47 - Commentaires [1] - Permalien [#]

22 avril 2019

Enfin une avancée

L'outil ConvWav de Ludovic Deplanque est vraiment très pratique.

Encore faut-il avoir les yeux ouverts et savoir lire les exemples fournis. L'utilisation au sein de mon jeu ne pose finalement pas de problèmes pour peu que je me contente de petits samples. La qualité sortant sur le CPC sera du 11000hz 1 bit !

C'est très peu, mais suffisant pour rendre un message audible. Le but n'est pas non plus de refaire un Monkey's island !

Mon premier essai avec un cri pour l'écran de game over était intéressant mais ça n'était pas vraiment du ingame du coup.

Voila du coup, le résultat pour le premier sample ingame ! Les premiers tests semblent indiquer que le jeu se comporte bien.

J'espère que ça me permettra d'en rajouter d'autres.

vous ne passerez pas

Posté par eric_boulat à 20:51 - Commentaires [0] - Permalien [#]


31 mars 2019

Tout est projet

Lors d'une formation à la gestion de projets, le formateur nous avait donné sa définition du projet :

Pour lui un projet c'est une recherche d'une solution nouvelle à un problème. Tout le soucis réside dans le sens que l'on accorde à "nouvelle". En effet, selon notre formateur, un projet ne peut pas être vu comme de la simple prestation vente de solution existante.

Si demain, pour résoudre votre envie de regarder des séries américaines, je vous vends une smart tv avec un abonnement netflix, je ne deviens pas pour autant un chef de projets multimédias !

Pour notre formateur, au commencement du projet, le porteur du projet n'a pas d'idée précise du "comment", il ne peut répondre précisément qu'à deux questions : pourquoi et combien.

C'est donc très différent d'une prestation de services, où la question du comment est bien plus maîtrisé d'emblée. En conséquence, les choix techniques d'un projet peuvent être à postériori discutables mais il faut les voir selon les contraintes du moment où ces décisions ont été prises.

Vous allez me dire et le CPC dans tout ça ? J'y viens justement. Lorsque j'ai lancé ce projet, j'avais eu pour objectif de faire rentrer le jeu sur une seule disquette. Nous partions Bruno et moi sur une base de 40 tableaux, compte tenu du scénario, de la taille des graphismes, je pensais à l'époque à vue de nez que ça rentrerait sans trop de soucis.

Malheureusement en finalisant son scénario, Bruno arrive à 50 tableaux sans compter ceux qui sont modifiés par des actions et donc on arrive finalement à 55 ecrans. A l'époque il y a 25 ans, imaginer prendre une troisième face de disquette pour ce supplément de scénario nous apparaissait comme un gachis. Je me décide donc à optimiser grandement le code, pour gagner en place. Le code devient alors plus compact, plus complexe aussi.

Tout ce temps passé à s'escrimer à faire rentrer le jeu dans une seule disquette finalement a été perdu pour la finalisation du jeu. J'aurais pu sinon consacrer mon temps à la finalisation des derniers écrans plutôt qu'à l'optimisation du code.

A présent, je me retrouve à nouveau face au même dilemme, en intégrant un sample dans mon jeu, pour l'écran de game over, j'ai atteint la limite des 64 fichiers ! J'ai donc le choix de replonger dans le code, chercher à fusionner certains fichiers basic, au risque de manquer de RAM, ou bien coder des routines pour gérer des fichiers autrement, ou bien je consens enfin à utiliser une troisième face de disquette.

A présent que je travaille sur émulateur et que je peux me créer toutes les disquettes virtuelles de mon choix, pourquoi s'embêter ? Car en disposant d'une face de disquette de plus, je pourrais intégrer jusqu'à 64 fichiers de sample en plus, ce qui devrait bien aider à rendre le jeu plus vivant.

De même si j'y intègre une musique d'intro et une musique de fin ça sera nettement plus facile.
Donc le choix est fait, l'ile au trésor nécessitera 3 faces de disquettes standard. Je ne pense pas qu'une quatrième soit nécessaire par contre.
Si j'avais pris cette décision dès le début, le jeu aurait été terminé, ou sinon il aurait même qui sait  été différent. Bruno aurait peut-être étoffé encore plus son scénario pour profiter de la place disponible. On aurait aussi pu envisager de refaire des écrans plus grands du coup bref avec des si on coupe du bois ;-)

Posté par eric_boulat à 15:03 - Commentaires [0] - Permalien [#]

23 mars 2019

Dilemme

Cela fait maintenant plus d'un mois que je n'ai rien publié sur mon jeu et pour cause, il était en stand by.

Je glanais des informations techniques, mais concrétement plus rien n'avançait. Mon récent déménagement n'a pas non plus aidé et il est vrai que la dernière difficulté technique sur les musiques, et bruitages.

Qui plus est, le fait d'atteindre les limites de la mémoire disponible complique singulièrement le développement. Comme je l'ai déjà dit, ce sont ces problèmes qui m'avaient fait laisser tomber le projet sans l'avoir fini. A l'époque j'avais estimé que 40 tableaux faits et vérifiés et les 10 derniers codés à la rache en aveugle suffisaient à prouver ce dont j'étais capable.

Mais ce coup-ci pas question d'abandonner si près du but. Le jeu est trop avancé pour laisser quelques derniers désagréments tout gacher.

Pour prévenir les soucis de mémoire il était important de mesurer précisément ce qui restait comme espace disponible et aviser en fonction. J'ai donc fait apparaître cette information à la fin de chaque message que j'affiche. Pour l'instant, j'ai pu constaté que la mémoire disponible tournait autour des 7-8 kilo-octets, mais pouvait tomber en dessous de 4.

Il va donc falloir être très chiche dans les ajouts de code.

J'ai ajouté un bruit de vagues dans le premier tableau pour voir. Malheureusement, je n'ai pas pu intégrer celui des mouettes qui prenait trop de place. Qui plus est, je voulais mettre ces bruitages en fond sonore, mais cela consomme trop de CPU et ça serait trop complexe. Du coup, les bruitages seront juste présent 1 à 2 secondes en intro si ce sont des bruitages d'ambiance, ou bien ils seront joués lorsqu'une action les déclenchera. Par contre pour la musique de game over, je ne sais pas comment faire ! Même faire un truc tout bête genre sad trombonne sera difficile et je parle pas de mon essai lamentable de rejouer l'air célèbre de Chopin.

J'ai eu aussi un dilemme, sur la fonte que j'utilisais jusqu'à présent. C'était la fonte faite par Bruno, elle nous avait permis par sa petite taille d'afficher plus de lettre en mode 0. Récemment, je suis tombé sur la fonte HalfSize de Stéphane Anquetil, qui outre le fait d'être plus complète me parait plus jolie et lisible. Du coup, est-ce qu'abandonner une partie du travail de Bruno, c'est un peu trahir son travail ? Je garde le fichier d'origine au cas où je changerais d'avis. En tout cas, je pense qu'apporter une amélioration au rendu visuel du texte ne peut être que bénéfique.

Il faudra que je refasse les screenshots du manuel et de la solution !

Un petit screenshot en mode debug, voyez comme la fonde est plus régulière et cohérente. En fin de message, on constate qu'il me reste 8494 octets.

 

 

 

 

Posté par eric_boulat à 22:13 - Commentaires [0] - Permalien [#]

17 février 2019

FFFF is the limit !

Lorsque j'avais lancé le développement de ce jeu, je n'avais qu'une vision parcellaire des limitations de la mémoire de la machine.

Bien sur je savais qu'il n'y avait que 64K de mémoire directement disponible, et que sur ces 64, 16 étaient réservés pour la mémoire vidéo. Mais ensuite, c'était le flou total.

Le soucis est que du coup, on code sans forcément se rendre compte que notre programme n'aura pas l'espace mémoire nécessaire pour fonctionner correctement. Et comme il s'agit d'un programme interprété, ce soucis peut apparaître que tardivement lors de l'éxécution du programme.

C'est ce genre d'ennuis qui m'avait fait laisser tomber le projet avant d'en avoir terminé les derniers tableaux.

L'autre soucis est que lorsque l'on atteint ces limites, l'erreur n'est pas forcément flagrante et surtout le message d'erreur n'est pas forcément le bon. Ainsi lors d'une de mes récentes tentatives pour intégrer des bruitages de mer et de mouettes, dans mon premier tableau, j'ai à nouveau atteint cette limite que j'avais eu tant de mal à repousser.

Ce listing n'est pourtant pas très long, et aurait du passer sans soucis. Mais je n'ai pas eu de messages d'erreur m'indiquant que je n'avais plus de mémoire, ça aurait été trop simple ! Au lieu de ça, j'ai constaté que je n'avais aucun son ! Je corrige mon programme pour forcer le lancement du bruitage,  toujours rien ! Je stoppe l'exécution, je tente directement un goto 3200 pour lancer le dit bruitage, et là patatra, une demi seconde de bruitage, et j'ai une erreur à la ligne 267, qui n'avait rien à voir avec le bruitage. Le soucis est qu'il n'y avait aucune erreur à cette ligne en plus ! Je fais un print free(0) et là, l'explication arrive, je n'ai plus de mémoire disponible ! C'est inquiétant car finalement le tableau 1, n'est pas le plus complexe et l'ajout de ce code ne l'allongeait pas tant que ça !

Le problème est aussi apparu car j'ai du baisser la limite de la mémoire allouée au basic pour laisser de la place à la routine et aux buffers de decrunch qui m'est nécessaire pour faire tenir le jeu sur une seule disquette. Bref c'est une vraie gageure de garantir la non régression de l'ensemble, lorsqu'on apporte des évolutions ou des corrections à un tel projet.

Je pense du coup qu'amoins de trouver une inspiration pour refactoriser tout le code du programme principal du jeu, je vais devoir dire adieu aux bruitages ! Je tenterais quand même encore, histoire de m'en sortir. J'entrevois une solution pour me passer des librairies de décompression OCP qui ne servent que pour 4 fichiers à présent. Si j'arrivais à me passer de Mpack aussi, et en théorie c'est possible, je pourrais du coup libérer une zone de ram à partir de A000 que je récupèrerais pour remonter la limite de la mémoire allouée au basic pour l'instant abaissée à &6b22.

Résultat de recherche d'images pour "there's no limit"

Posté par eric_boulat à 11:59 - Commentaires [2] - Permalien [#]

08 février 2019

Enfers et stagnations

Ca devient une habitude de faire des titres avec des jeux de mots pourris !

Le constat est bien là, peu de progrès sur le jeu ont été réalisés. 3 bugs corrigés, quelques bruitages trouvés ou faits, mais toujours pas intégrés.

La musique du game over inspiré par Chopin me parait longue et désagréable. Je songe à la remplacer par un son de type sad trombonne (http://www.sadtrombone.com).

Seulement ce qui aurait pu paraître l'est nettement moins. Pas moyen de reproduire ce son bien connu sur l'amstrad sans sortir l'artillerie lourde du sampling. Je n'ai pas réussi en utilisant les variations de volume et de tonalité à refaire ce son "wow wow wow waaaaoum" fait au trombonne marquant les "fails" dans les cartoons. Je me dis que ce son serait idéal pour le game over de mon jeu.

Du coup, l'idée de partager ces bruitages et différents effets sonores qui avait été lancé via le groupe Facebook amstrad.eu me parait très bonne. J'espère que ce qui en émergera sera un moyen non seulement de récuperer le code de ces programmes mais aussi de les tester directement sur un site web. Il existe des émulateurs CPC en ligne, il existe aussi des lecteurs de fichiers YM comme sur l'excellent site cpc-power.com. Il y aurait vraiment là quelque chose d'utile à soumettre au public !

Du coup, pour le moment pas de nouvelles releases, je n'ai pas eu encore la motivation de refaire une recette complète du jeu.

J'ai des idées d'évolutions qui me viennent, principalement pour réduire la difficulté. Je pense notamment à une sécurité dans le scénario qui vous préviendrait que vous n'allez plus pouvoir revenir en arrière et demander de confirmer.

Je pense aussi à des évolutions techniques qui seraient de bonnes améliorations :

  • Abandonner le format scr compressé de ocp art studio pour ne garder que le format crunch, ce qui me permettrait d'enlever une routine de la ram
  • Abandonner la routine mpack des logon system pour utiliser directement les banks de mémoire.

Le premier point est assez facile, mais finalement il est relativement peu utile, la routine en question me gêne peu. Le second point est nettement plus complexe. J'ai quelques informations sur le sujet, mais je ne le maîtrise pas encore. Je ne sais d'ailleurs pas si c'est réellement possible du coup pour mon jeu.

Nous verrons bien.

 

Posté par eric_boulat à 17:35 - Commentaires [0] - Permalien [#]

15 janvier 2019

petit screenshot

Posté par eric_boulat à 16:20 - Commentaires [0] - Permalien [#]