Archives de Genesis8 Amstrad Page de 1999 à 2020 à propos de développement, page 1 / 15





PunyInform v3.4 par Fredrik Ramsberg et Johan Berntsson pour écrire des jeux d'aventure texte

-

PunyInform v3.4 par Fredrik Ramsberg et Johan Berntsson est un librairie écrite en langage Inform 6. PunyInform permets de créer des jeux d'aventure (pur texte, pas de support pour des images contrairement à DAAD) utilisant la machine virtuel Z-machine, qui pourront fonctionner sur des ordinateurs 8bit ou plus récents. Il contient un parser, une implémentation de verbes courants, ainsi qu'un framework pour écrire des jeux d'aventure.

PunyInform est basé sur la librairie Inform 6 développée par Graham Nelson. Il est destiné à rendre facile l'écriture de jeux au format Inform 6, un manuel décrit les différences entre les deux librairies.

Les jeux utilisant PunyInform peuvent être compilés au format z3, z5 et z8 (z3 est le plus adapté pour les ordinateurs 8bit, les autres formats ont des fonctionnalités supplémentaires). Comparé à la librairie Inform 6 cela signifie qu'il n'y a pas de support pour la machine virtuelle Glulx mais il y a bien le support du format z3 (que la librairie Inform 6 ne supporte pas).

Pour compiler des jeux utilisant PunyInform, il est recommandé d'utiliser le compilateur Inform 6 maintenu par David Kinder. Les binaires sont disponibles sur if-archive. PunyInform nécessite Inform v6.35 ou plus récent.

Il y a des tutoriels pour écrire des jeux d'aventure avec PunyInform (fin de la page) ainsi que toute la documentation dont une cheat sheet (quick reference) de 8 pages.

Pour essayer votre jeu après sa compilation, vous pouvez utiliser WinFrotz par David Kinder et pour créer une carte de votre jeu il y a Trizbort.

Et enfin pour créer une image disquette pour Amstrad CPC et PCW il vous faudra utiliser Puddle BuildTools.



Quigs pour développer des applications SymbOS (Amstrad CPC, PCW, MSX et Elan Enterprise)

-

L'IDE Quigs est une suite d'utilitaires et éditeurs pour aider les développeurs à créer des applications et autres médias pour SymbOS.

Son créateur et développeur TrebMint (Rob Buckley) a commencé à le développer à la fin de 2004. Avec l'apparition de l'interface SYMBiFACE en 2004, Quigs (ex SymStudio) a permis les premiers écrans vidéos en plein écran possibles sur CPC (oups pour la traduction je n'en suis pas sûr). Avec Quigs vous pouvez créer des formulaires, du code, des graphiques et même des vidéos et l'exporter pour les cibles de SymbOS : Amstrad CPC et PCW, MSX et Elan Enterprise.

Pour résumer, Quigs est :

  • un kit puissant de construction de formulaires
  • un éditeur de code, assembleur et compilateur
  • un gestinnaire de graphisme et vidéo
  • un convertisseur HTML et Richtext

dans un environnement de développement intégré à base de PC

N'hésitez pas à télécharger la documentation en anglais de Symbos 3.1.



WIP Tetris DotBAS par Francesc ALCAUCER pour Amstrad CPC

-

Tetris DotBAS est le dernier projet en cours de développement par Francesc ALCAUCER après ces deux programmes également écrits en basic Locomotive :



Version 3 du jeu d'aventure Tristam Island par Hugo Labrande (et future version française)

-

La version 3 du jeu d'aventure Tristam Island par Hugo Labrande est disponible pour 3,99 dollars (25% moins cher à partir de lundi 20 décembre). La version démo est limitée au premier chapitre du jeu pour un temps de jeu estimé d'une heure à heure et demi et vous permettra donc de découvrir ce jeu et voir si vous souhaitez l'acquérir à ce prix modique.

Ce jeu d'aventure utilise le framework utilisé par les jeux d'Infocom : la Z-Machine, qui a été rétro-ingénieré et documenté dans les années 90 et implémenté sur des douzaines de plate-formes. C'est de cett façon que "Tristam Island" peut être utilisé sur 36 ordinateurs (8, 16, 32 and 64 bits), incluant les Amstrad CPC et PCW. Ce jeu utilise une librairie optimisée pour la vitesse et la taille : PunyInform par Fredrik Rasmberg et Johan Berntsson.

Une version française sera disponible ce lundi 20 décembre 2021 avec comme d'habitude une version démo française.

Si vous achetez la version anglaise ou française, Itch.IO ne vous permets pas d'avoir l'autre version. Cela dit vu le prix modique rien n'empêche d'acheter les deux versions : une traduction cela demande beaucoup de travail et tout travail mérite salaire. Cela dit Hugo Labrande vous remettra une clé de la version que vous n'aurez pas acheté si vous le lui demandez.



PunyInform v3.3 par Fredrik Ramsberg et Johan Berntsson pour écrire des jeux d'aventure texte

-

PunyInform v3.3 par Fredrik Ramsberg et Johan Berntsson est un librairie écrite en langage Inform 6. PunyInform permets de créer des jeux d'aventure (pur texte, pas de support pour des images contrairement à DAAD) utilisant la machine virtuel Z-machine, qui pourront fonctionner sur des ordinateurs 8bit ou plus récents. Il contient un parser, une implémentation de verbes courants, ainsi qu'un framework pour écrire des jeux d'aventure.

PunyInform est basé sur la librairie Inform 6 développée par Graham Nelson. Il est destiné à rendre facile l'écriture de jeux au format Inform 6, un manuel décrit les différences entre les deux librairies.

Les jeux utilisant PunyInform peuvent être compilés au format z3, z5 et z8 (z3 est le plus adapté pour les ordinateurs 8bit, les autres formats ont des fonctionnalités supplémentaires). Comparé à la librairie Inform 6 cela signifie qu'il n'y a pas de support pour la machine virtuelle Glulx mais il y a bien le support du format z3 (que la librairie Inform 6 ne supporte pas).

Pour compiler des jeux utilisant PunyInform, il est recommandé d'utiliser le compilateur Inform 6 maintenu par David Kinder. Les binaires sont disponibles sur if-archive. PunyInform nécessite Inform v6.35 ou plus récent.

Il y a des tutoriels pour écrire des jeux d'aventure avec PunyInform (fin de la page) ainsi que toute la documentation dont une cheat sheet (quick reference) de 8 pages.

Pour essayer votre jeu après sa compilation, vous pouvez utiliser WinFrotz par David Kinder et pour créer une carte de votre jeu il y a Trizbort.

Et enfin pour créer une image disquette pour Amstrad CPC et PCW il vous faudra utiliser Puddle BuildTools.



Un tutoriel en français pour créer des jeux d'aventure sous DAAD en français

-

Uto a écrit un tutoriel pour écrire des jeux sous DAAD. Ce tutoriel a été traduit en français par Hugo Labrande qui est l'auteur du jeu l'Ile de Tristam actuellement en anglais mais avec bientôt une version en français.



WIP Hyperdrive par Reidrac pour Amstrad CPC

-

Reidrac (Juan Martinez) travaille actuellement sur deux projets, un RPG (à la Ultima) et Hyperdrive qui est un shoot them up, qui me fait penser à l'excellent Light Force.

Vous pouvez aller également lire Reidrac sur Twitter.

Je vous invite à aller lire les derniers posts du blog de Reidrac qui traite notamment de développer ses jeux non plus pour un support cassette/disquette mais cartouche, ce qui est facilité avec le Plus2CPC et la future Play2CPC, les DES ou Dandanator.



WIP CPC Bullet v2 pour Amstrad CPC

-

CPC Bullet est jeu créé pour le concours CPCRetroDev 2021 mais qui n'a pas pu y participer pour cause de délai dépassé de peu. Il a été développé par Cyrille Gouret, musique de Mr Lou et graphisme de Titan.

Vous pouvez télécharger la v2 de CPC Bullet sachant qu'il va être encore amélioré (gameplay, graphisme).

Le gameplay est simple, éliminer votre rival, sans vous tirer dessus avec un mauvais ricochet...

Une vidéo est disponible de CPC Bullet sur la chaine Amstradiens.




PunyInform v3.2 par Fredrik Ramsberg et Johan Berntsson pour écrire des jeux d'aventure texte

-

PunyInform v3.2 par Fredrik Ramsberg et Johan Berntsson est un librairie écrite en langage Inform 6. PunyInform permets de créer des jeux d'aventure (pur texte, pas de support pour des images contrairement à DAAD) utilisant la machine virtuel Z-machine, qui pourront fonctionner sur des ordinateurs 8bit ou plus récents. Il contient un parser, une implémentation de verbes courants, ainsi qu'un framework pour écrire des jeux d'aventure.

PunyInform est basé sur la librairie Inform 6 développée par Graham Nelson. Il est destiné à rendre facile l'écriture de jeux au format Inform 6, un manuel décrit les différences entre les deux librairies.

Les jeux utilisant PunyInform peuvent être compilés au format z3, z5 et z8 (z3 est le plus adapté pour les ordinateurs 8bit, les autres formats ont des fonctionnalités supplémentaires). Comparé à la librairie Inform 6 cela signifie qu'il n'y a pas de support pour la machine virtuelle Glulx mais il y a bien le support du format z3 (que la librairie Inform 6 ne supporte pas).

Pour compiler des jeux utilisant PunyInform, il est recommandé d'utiliser le compilateur Inform 6 maintenu par David Kinder. Les binaires sont disponibles sur if-archive. PunyInform nécessite Inform v6.35 ou plus récent.

Il y a des tutoriels pour écrire des jeux d'aventure avec PunyInform (fin de la page) ainsi que toute la documentation dont une cheat sheet (quick reference) de 8 pages.

Pour essayer votre jeu après sa compilation, vous pouvez utiliser WinFrotz par David Kinder et pour créer une carte de votre jeu il y a Trizbort.

Et enfin pour créer une image disquette pour Amstrad CPC et PCW il vous faudra utiliser Puddle BuildTools.





Benediction cross ASseMbler par Krusty à destination de l'Amstrad CPC pour windows, mac and linux

-

Krusty (Benediction) développe en ce moment Benediction cross ASseMbler (BASM) que vous pouvez récupérer sur son dépot github.

Pour le laisser présenter je me contenterai de laisser Krusty le faire : ces derniers mois j'ai travaillé sur BASM qui sera utilisé dans notre prochaine production. Je ne l'ai pas encore testé dans des conditions réelles, donc en ce moment je n'ai pas idée de son efficience et de son usage.

J'écris ce message pour permettre à d'autres personnes de l'utiliser et de me fournir un retour pour corriger d'éventuels bugs et ajouter de nouveles fonctionnalités pour sa future sortie. Je suppose que la sortie officielle sera accompagnée d'un GUI pour ceux qui ne sont pas encore prêt à utiliser un utilitaire en ligne de commande.

Son but n'est pas de remplacer RASM qui est un excellent assembleur. Mais il peut être utilisé dans des contextes ou RASM ne pourrait pas être utilisé. BASM n'est pas compatible à 100% avec RASM.

Bien sûr, il n'y a pas encore de documentation prête, mais vous pouvez vous rendre compte de ses possibilités en allant lire les fichiers good_xxx.asm de ce dépot github.

Parmi ce qui n'est pas encore disponible pour RASM, vous pouvez vérifier la section basic ou des exemples itératifs.

Notez que BASM utilise deux passes d'assemblage par défaut, mais que vous pouvez vous contenter de la première passe s'il n'y a pas de besoin pour la deuxième ou ajouter d'autres passes si besoin est (ce qui rends les examples ifuse compatible avec BASM mais pas avec RASM).



A la chasse au bug sur la version Amstrad CPC de Shinobi par Richard Aplin

-

Richard Aplin est le développeur du portage Amstrad CPC (1989) de la borne d'arcade Shinobi (1987). Lors de son développement il a cherché durant deux semaines un bug rare de Shinobi, il en parle sur Twitter. Avec sa permission je mets en ligne sur le site tout le texte présent sur Twitter (pour les photos cela va prendre plus de temps).

Pour la traduction du texte ci-dessous, et bien cela prends du temps, donc sous peu.

A l'époque des micros 8bit, dans le cas présent l'Amstrad CPC (à base de Z80 populaire en europe). J'ai travaillé pour une société de jeux, je réécrivais une conversion du jeu d'arcade Shinobi pour l'Amstrad CPC.

There were all sorts of geeky, tweaky technical tricks to make it run fast and look nice (coded in assembly language), and all went well, game turned out pretty nice, ran fast and played pretty well, until one day, when nearly done, play testers reported that it occasionally - crashed on one level. Boom! Reset. It was really hard to reproduce.

Nobody could come up with anything they actually _did_ to make it crash (or not); was about one in ~20 times(IIRC), when fighting a boss.

I had nothing fancy like a logic analyzer or in-circuit-emulator or other hardware debugging tools, just a regular retail computer. So it just crashed, once in a while, when playing one specific part of the game.

Sure, just some coding bug, like any other, not uncommon. But WHERE and WHY and HOW!? ..and why so hard to reproduce? You could play for hours and no problem, but just when it seemed like it was a ghost or maybe fixed for no known reason.... BOOM reset.

This went ON and ON and I was utterly mystified. I just could _not_ induce this bug to happen more often [the key to find/fixing it], no matter what I tried, I could not find even a way to reproduce reliably, let alone the root cause.

I started doing stuff like checksumming the RAM every frame, looking for some sort of random corruption, putting all sorts of checks in there that slowed it down to a crawl, and still nothing. The bug seemingly came and went as it pleased, never in quite the same place.

Until one day I got lucky. I caught it in the act! One single byte in the middle of my program code got trashed - and this time I caught it _before_ the whole thing blew up. But how?! What on earth was causing this? [OH for a hardware logic analyzer !

Finally, _finally_, after probably two weeks of solid bug-hunting and hair-tearing I found it.

So back in those days, it was customary for the game's music to be written by someone else, and provided as a binary blob of code plus data (e.g. 4Kbytes) that you would just call once a frame, and it took care of controlling the sound chip and playing whatever music tracks.

And it turned out that the music player (I didn't have source code) had a bug in it. Not a big bug. A teeeeeny little bug. It didn't audibly affect the music at all, but one _single_ note, on one channel, in one of the tunes on one of the levels, used a wrong data byte.

And normally, when that single duff musical note played, nothing bad happened, it was a fairly harmless bug, however it caused music player to read wrong byte of RAM; not just off by one byte, but off by tens of KBytes... in fact, it ended up reading a byte of the display ram.

If I recall correctly, it ended up - at that instant - reading a single byte of the display right around where this green circle is, in the upper left corner.

And when that single bad musical note in the tune played - IF the top bit (and only the top bit) of that pixel was a 1, it would then take that as a memory address ELSEWHERE in RAM and increment that location which corrupted a single byte inside of my program code, leading to a subsequent - but not quite immediate; a couple of seconds later, when a baddie was decided to shoot at you - crash.

This was a 2D scrolling game of course, so you were constantly jumping around and doing stuff fighting ninjas- the crash only happened if ONE pixel of the display was a certain color at the instant that one single note of ONE background tune played, and it wasn't in my code.

I vividly remember finally discovering the root cause (disassembling and patching the music player, and finally catching it 'in the act', and figuring out the long chain of events..) .. To this day I have never had a bug as hard as that one.. was SO rewarding to find.

I've had a bunch of equally obscure bugs in the decades since then, but the tools got so much better - protected memory, logic analyzers, CPUs that don't just explode on contact with bad data - nothing has ever been as difficult to track down as that one. Was a great lesson which is that if you persevere for long enough you will win in the end against a computer - bugs can't hide forever. Ever since then I've known it's just a matter of time, and patience. Nowadays I relish a good bug, I rub my hands and chuckle - the game is ON! ;-).




La ROM Basic v1.1 de l'Amstrad CPC 6128 désassemblée par Bread80

-

Après le désassemblage du firmware Amstrad CPC du 6128, Bread80 a mis en ligne sur github la ROM Basic v1.1 désassemblée de l'Amstrad CPC 6128. Il en parle sur son site web et Twitter.

Pourquoi utiliser un des compilateurs commerciaux du Basic Amstrad CPC quand on peut améliorer sa vitesse à la base ?



SDCC v4.1.0 disponible (programmation en C pour Amstrad CPC) sur PC et MacOS

-

Une nouvelle version du compilateur C multiplateforme SDCC v4.1.0 est disponible depuis le 8 mars 2021 pour windows, linux et MacOS.



Pour plus d'informations, allez sur la page principale