AMOS Professional 'améliorations'… C'est possible ?
-
La vidéo est directement sur la page AmosCoding de Facebook.
(J’ai la flemme de télécharger la vidéo sur youtube).
Voici le lien : https://www.facebook.com/groups/AmosPro/permalink/1004076299930370/
Pour ceux qui voudraient voir un WIP intéressant pour l’AMOS Pro, n’hésitez pas à y jeter un oeil et me laisser un petit commentaire ici … ou là bas …
En tout cas, mettre la main dans le pétrin du code source de l’AmosPRO, ça me dérouille les anciennes connaissances en 680×0 et … et celle sur … Enfin vous verrez avec la vidéo :p
@+
@Lexomil : Comme le dit Treesong, cela ne peux être qu’AGA.
En fait je travaille sur le code source de l’Amos Pro (d’après la version sur le git de Marc365 ( ici : https://github.com/marc365/AMOSProfessional ).
Et du coup j’ai ajouté le support « Natif » avec les commandes d’origines de l’AMOS Professional, pour le mode Dual Playfield en 2 x 16 couleurs. Pour l’instant la précision des couleurs est toujours celles de l’Amiga 500, mais ma prochaine étape sera d’améliorer cela (en plus d’autres fonctionnalités)..
Voici une nouvelle vidéo directement sur youtube et enregistrée avec ShareX :
Mon repository à jour est ici : https://github.com/AmiDARK/AMOSProfessional-X/tree/Dual-Playfields
@MikeDaFunk :
Ce projet part des sources de l’Amos Professional 2.0 et n’est pas un projet « from scratch » comme le fait François Lionet avec son AMOS 2 😉Les objectifs des deux projets sont très différents l’un de l’autre 😉
Ok, je suis allé faire un tour sur le git mais c’est pas évident de s’y retrouver dans les fichiers, surtout quand tu tapes les 20k+ de lignes 🙂
Y’a pas une petite doc d’explication quelque part ? Quand j’aurai le courage je clonerai le repo et je tenterai un build 🙂
Bon courage pour ton dev.
ooooh !
j’ai 2 ou 3 petits jeux en cours
@Kamelito :
J’ai discuté avec l'<<AMOS Factory>> team et j’ai accès à leur travail (et tout ce qu’ils ont fait, c’est à dire beaucoup de choses (et je trouve ce qu’ils ont fait ‘extra’, mais je ne peux pas trop en parler). Ils veulent fournir une version « peanuts » (c’est à dire super bien travaillée et testée).Mon travail sur l’AGA part de la version de marc365 (tu peux voir sur mon GIT : « forked from marc365/AMOSProfessional ». Je pense que c’est une version réorganisée de celle de François Lionet.
Cependant, mon travail devrait être présent dans la version de l'<<AMOS Factory>> team si tout va bien, lorsque cette dernière sortira. Enfin, c’est en gros ce qui a été décidé entre eux et moi … Je ne fais pas vraiment partie de leur équipe (car j’Aime bien être un électron libre), mais on partage beaucoup de choses… De mon coté mon objectif c’est le « challenge » que représente l’AGA… De leur côté c’est fournir une versions bien améliorée et au top en espérant pouvoir y inclure l’AGA.
Bon j’espère ne pas en avoir trop dit …Voilou 🙂
Sympa cette inclusion de l’AGA !
Je trouvais ta vidéo pas très claire, au début je pensais que tu faisais un changement de palette en cours de balayage, avant de comprendre que c’était les 16 couleurs par playfields…
ça fait plaisir de voir qu’on s’interesse encore à améliorer ce beau soft ! Bravo !A500 (1.3 / 2.0 / ACA500+) - A2000 - A1200 Salut,
je lisais, au détour de leur forum (AMOS Factory), que le gros souci concernant un support « transparent » de l’AGA était l’incompatibilité des structures de données existantes et qui nécessiterai un gros « rework » du code. Tu le sens comment de ton coté ?
@Lexomil : C’est ce qui est étrange dans le code source de l’AMOS.
Par exemple le support du 2x16couleurs a été très facile à ajouter sans me prendre la tête.. Juste à gérer le fait que le bit BPU3 qui gère le mode 8 bitplans n’est pas consécutifs des bits BPU0 à BPU2 … Donc faire une condition pour cela :cmp.w #8,d2 ; If 8 bitplanes are requested, we directly set byte #4 of d2 blt sevenOrLowerDPF ; Less than 8 bitplanes, jump to classical way of shifting bytes to set BPU0-2 heightBitPlanesDPF: move.w #16,d2 ; Set byte 04 ( BPU3 ) to 1 and others (BPU0-2) to 0 to define 8 bitplanes bra.s continueDPF sevenOrLowerDPF: ; if less thab 8 bitplanes are requested, we use the default Amos calculation as it fit lsl.w #8,d2 ; in BPU0-1-2 bytes 12-13-14 in BPLCON0 16 bits register lsl.w #4,d2 ; As lsl.w handle max of 8, to shift by 12 AMOS must to 2 Lsl.w calls. continueDPF: ; 2019.11.03 End of upgrade to handle BPU3 for 8 Bitplanes mode.Puis gérer le mode BplCon3 en plus pour la palette de couleur du 2nd écran …
Ainsi que quelques modifications mineures dans le code source.L’AMOS utilise des variables qui sont censées d’après leur utilisation et leur nom, permettre d’ajouter plus de bitplans:
EcMaxPlans equ 6 ; 6 Plans pour le moment! ... EcLogic: rs.l 6 * EcPhysic rs.l 6 * EcCurrent: rs.l 6 *Cependant la modification de ces derniers provoque un crash dans l’Editeur…. Je subodore donc que des références « relatives » d’un objet à l’autre (à la suite) sont utilisées à certains endroits du code au lieu d’utiliser les références directes
genreMove.l D0,#EcLogic(a0,d2)où d2 pointe dans EcPhysic par décalage d’adresse au lieu d’utiliser directement #EcPhysic…
Sinon, pour contrecarrer ces biais dans le code source, j’ai en idée une approche originale qui m’évitera de réécrire tout le moteur… Je vous en dirais plus plus tard si ça avance 😉
@+
- Vous devez être connecté pour répondre à ce sujet.
› Forums › AmigaOS, MorphOS et AROS › Développement › AMOS Professional 'améliorations'… C'est possible ?
