AMOS Pro community 2020.1
-
@Sbai
Il faut faire une executable avec l’Amos compiler de ton programme amos.
Ensuite on part d’un disque ADF formatté en bootable (faisable avec winuae par exemple).
On suppose que tu as copié les ressources nécessaires (musiques, graph…) et l’exe qu’on va appeler monExe sur ce disque.
Il faut créer le fichier texte « startup-sequence » dans un répertoire « s ». Ce fichier contient le texte « monExe ».A+
Super initiative, merci pour le boulot, mais je comprend pas tout:
Quand tu dis: « les extensions gratuites et incontournables Amos Pro 1.9 et Amcaf 1.5 « , je ne connais pas ce Amos pro 1.9, c’est quoi donc ?
Le patch de Amos Factory, tu parles duquel ? La nouvelle lib qui régle le bug du dual playfield ? Amos 2.1 ? Les deux ? Autre chose ?
Quelle est la méthode d’installation que tu préconise si on veut garder l’acces aux accessoires ? Installer Amos Pro 2 et écraser avec le contenu de la disquette minus le fichier de config ?
Dans tous les cas c’est bien cool, merci
@Clad
C’est bien sur Amos turbo 1.9 et non Amos pro. Merci pour la remarque.
Le patch est celui du Dual Playfield. J’ai entendu parlé d’une version 2.1 mais je ne sais pas si elle existe vraiment. En tout cas je ne l’ai pas.
Je ne préconise aucune méthode d’installation 🙂 Il y a le compilateur que l’on peut charger comme accessoire à partir de la disquette fournie. Pour le reste il y a tellement de configuration et donc c’est à la discrétion des développeurs.Par curiosité que programmes tu donc en Amos ?
PowerMac - G5 2.0 GHz - 1.7 Go RAM - Radeon 9600P 128 Mo - MorphOs 3.13 et Peg2 - G4 RIP
Mac mini - G4 1.42 GHz - 1 Go RAM - Radeon 9200 32 Mo - MorphOs 3.9
WinUAE sur HP Core2 Quad 8200
Epave de Mist FPGA remplacé par un Sidi
A1200 malade 😉 et A500 512+512Ko RAM Kickstart 1.3Pour le moment surtout un utilitaire pour comprendre et régler un problème très spécifique de couleur sur ma machine.
J’ai perdu mes sources et routines que je réutilisais quand mon disque SCSI est mort, et mes quelques sprites dessinés à la main, ça m’a mis un coup mais j’y reviens petit à petit.
Pour le moment j’ai un petit problème avec ta community edition: sur ma machine (A2000, KS13, OS13) j’ai un guru quand je quitte l’éditeur Amos Pro.
Avec ma version installée depuis les disques normaux (+ lib debuggé + amos compiler 2 + tinyshell, mais sans amcaf ni amos turbo) ça quitte proprement.
Ça marche chez toi ?
Peut être que Amcaf n’aime pas les machines non-AGA ?
Oui effectivement Amcaf introduit des problèmes en rom 1.3 (pas en 2.0+) sur la fonction de retour au Wb par exemple mais je ne l’ai remarqué que dans le cadre d’un retour d’un programme (d’où le reset dans mes démos en fin et non un retour au dos :-)).
Je ne sais pas si ton pb est lié à Amcaf, c’est possible effectivement. Hors développement d’un utilitaire, cette bibliothèque est malheureusement incontournable (pour la lecture des modules protracker).
En pratique je dev sous émulateur, ce qui est plus productif (mais certes moins rigolo).
Chaque extension développée pour AMOS possède une méthode startup et une méthode quit.
La méthode startup est appelée au début du lancement de l’IDE de l’Amos Pro ou de l’exécutable compilé et permet à l’extension de mettre en place les initialisations dont elle a besoin (allocation mémoire, etc…)
Le méthode quit est appelée lorsque le programme exécutable est terminée ou que l’on quitte l’Amos Pro (ou faisons la commande Default (pour celle là, pas sûr si cela fait le quit et le startup à la suite), je vérifierai).Donc si le retour WB ne se fait pas, et ce uniquement lorsque l’extension AMCAF est installée, c’est que c’est quelque chose dans sa méthode QUIT qui bloque. La question est : est-ce que cela le fait aussi quand l’extension est installée mais pas utilisée ?
Il me semble qu’à l’époque où j’ai rencontré le problème j’avais essayé sans extension amcaf et le problème de quit d’un programme compilé (pas d’essai sur l’éditeur) n’avait pas lieu. Ce problème n’a lieu que pour les roms <2.0.
@clad
Je suppose que tu a testé l’installation d’amcaf sans utiliser une fonction amcaf (puisque ta version originale d’amos n’avait pas cette extension), mais ce n’est pas certain et donc à toi de le confirmer 🙂Au passage, quelques autres problèmes rencontrés :
– si on active la possiblité de mettre un raster sur les couleurs 16 – 31 (amcaf), le cyclage de couleur (flash) ne marche plus. Workaround: chgt de couleurs à la main…
– la fonction rainbow del ne marche plus (sans doute à cause de Amcaf). Workaround : faire un screen offset noEcran,0, pour la faire fonctionner.
– les sprites n’apparaissent pas avec rom 2.0+. Workaround : Doke $DFF096,$81FF pour réactiver le canal DMA des sprites
– le quit ne marche plus sous 1.3. Je n’ai pas trouvé de vrai workaround
– Les fonctions cos et sin ne marchent plus dans les codes compilés. Workaround : utiliser qcos et qsin de Amcaf
– Le bug peut-être le plus pénible : si on utilise le timing CIA dans un mod tracker (99% des cas), il y a un conflit avec les bitplanes et les sprites qui peut amener un clignotement de temps en temps (un blink). Donc même si Amcaf est la meilleure solution que j’ai trouvé pour lire des mods avec un 68000 (il y a une extension 60820 utilisé avec super bubble remix qui marche nickel), il y a ce petit problème. Donc il faudrait en fait faire une lib avec les derniers trucs pour lire un mod (je pense au code de Stingray là).
@Amidark
Malheureusement, je ne peux pas utiliser Amos unity pour l’essentiel du code que j’ai actuellement (et je commence à en avoir quelques dizaines de milliers de lignes 🙂 ).
Pour New Bubble Story, je ne peux pas l’utiliser à cause de la fonction qui permet de mettre un raster sur les couleurs 16 à 31 (donc sur un sprite évidemment) et pour la lecture de mod. Je n’utilise que les fonctions d’amos standard pour tout le reste. Donc je pourrai presque l’utiliser si tu es d’accord pour intégrer la fonction de raster sur un sprite (assez intéressant comme possibilité d’ailleurs) et si tu fixes le problème de lecture de mod pourri d’amos standard, sujet avec lequel je t’ai déjà embêté hé hé hé. @TreeSong:
Pour la fonction de rainbow sur les couleurs des sprites je suis en train de préparer (surprise non dévoilée pour l’instant), quelque chose de très intéressant je pense et qui pourra ravir les fans de rainbows (tout en les rendant plus simples à utiliser et RGB24 en même temps (retro compatible ECS/OCS bien sûr ) 😉Par contre, si tu veux voir mes dernières améliorations et des sprites aga et un triple playfield, regarde mon post sur l’Amos Professional Unity 😉
J’apporte pas mal de choses pour qu’il devienne vraiment intéressant.@Amidark
Oui c’est super.
Il est évident que ce que tu es en train de faire est vraiment bien. C’est pour cela que j’essaye de te faire des petits retours. Par exemple, as-tu fixé le truc du dual playfield avec la version OCS ?J’ai fait une petite démo il y a pas longtemps avec une petite « implémentation » de street fighter 2 (en terme d’affichage) et c’est sûr que si on portait cela dans ta version d’amos (AGA), cela pourrait être sympathique. Rien que de passer en 2*16 couleurs plus une amélioration des rainbow (peut-être permets tu l’utilisation de plusieurs « rainbows » sur une même ligne pour pouvoir changer plusieurs couleurs, qui sait ?), on aurait un affichage quasi identique à la version d’arcade. Cela pourrait faire une pub pas mal pour ton langage qui le mérite largement.
@TreeSong :
Je n’ai pas bossé sur la version ECS depuis un moment, mais quand je vais intégrer ce système de playfield sur la version ECS, j’en profiterai pour fixer le problème de scrolling 😉Pour les rainbows, je vais devoir faire comme les fading, implémenter quelque chose de spécifique … Mais cela devrait pouvoir permettre (si l’on ne mets pas de sprites en playfield), de gérer plusieurs rainbows en simultané.
- Vous devez être connecté pour répondre à ce sujet.
› Forums › AmigaOS, MorphOS et AROS › Développement › AMOS Pro community 2020.1
