AMOS Professional 'améliorations'… C'est possible ?
-
Salut,
Effectivement les gars de l’amos factory travaillent depuis longtemps sur l’amélioration d’amos.
Ils ont quand même produit une version patchée qui supprime notamment le bug du dual playfield dans le cas d’un scrolling horizontal. Ce bug n’existait pas dans amos « normal » et a été introduit dans Amos pro.
En pratique j’utilise cette version d’amos pro 2.0 patchée (patch disponible via le forum) à laquelle j’ai ajouté les deux extensions vraiment incontournables selon moi : amos turbo et amcaf. C’est du coup une sorte d’Amos pro 2.5
Ajouter le support de l’aga, c’est super mais pour moi le plus interessant est de faire une version 2.5 standard (ou 3.0 si l’on veut) d’Amos pour améliorer le support de l’OCS.
J’utilise quand même pas mal amos depuis un petit moment, donc pour moi voici un petit retour d’expérience de ce qu’il faudrait faire :
– Fixer les routines de collisions dans le cas d’un scrolling (tous les bobs/sprites col ne prennent pas en compte le changement d’offset )
– Améliorer la gestion des sprites notamment dans le cas d’un scroll. Revoir probablement les routines de gestions des sprites dit calculés dans le jargon amos. Lors de l’utilisation d’un scroll, on ne peut généralement utiliser que 4 ou 5 des 8 sprites hard de l’amiga et c’est bien dommage.
– Remplacer la gestion des mods protracker d’Amos pro (qui a des bugs) par celle d’amcaf qu’il faudrait également fixer au passage (quelques bugs encore et mises à jour à faire). Même choses pour les samples : la version Amcaf est très bien.
– Remplacer la gestion des icons (paste icon) directement par l’implémentation d’amos turbo
– Intégrer la gestion du blitter et des bitplans apportés par amos turbo (set planes, plane update, blit clear) et amcaf (blitter clear, turbo draw, blitter fill). Ces instructions sont vraiment plus performantes que draw et polygon et vraiment orienté amiga dans leur utilisation. Avec ces instructions on peut faire un cube en 3D en calcul temps réél en 50fps et quasi plein écran (si si :-))
– Améliorer la gestion des couleurs par le copper. Amos ne permet que de changer via le copper une couleur par ligne (rainbows). On devrait pouvoir changer plusieurs couleurs et utiliser plus facilement d’autres possibilités d’accès aux registres hard par le copper.
– Revoir un peu l’algo des bobs. Les performances sont déjà correctes, en particulier avec l’ utilisation d’amal mais on doit pouvoir gagner encore un peu sur ce sujet.
Evidemment il faudrait avoir les sources des extensions idéalement ce qui n’est pas gagné. Par ailleurs je ne peux que donner mon avis car je ne peux pas investir du temps dans le développement d’amos en plus de ce que je suis actuellement en train de faire sur Amiga. Mais peut être que cela peut intéresser certaines personnes comme Amidark.
A+
Aghnar
Alors pour les sprites ça me semble normal car pour un scroll tu dois démarrer ton décodage d’écran un poil plus tôt et du coup tu empiètes sur le DMA des sprites. Si tu veux avoir un scroll et tes 8 sprites il faut réduire la largeur de l’écran (par exemple 304 pixels au lieu de 320) et le faire commencer un peu plus tard comme ça tu gardes tous les canaux DMA des sprites.
Bonsoir,
En fait il y a une petite confusion. Amos effectivement a sa propre copperlist (on est sur Amiga, il n’y a pas vraiment le choix :-)).
Les commandes sur les sprites, les écrans etc influencent cette copperlist. Les écrans, cela n’existe pas pour le hardware. Donc les écrans Amos sont en fait une copperlist paramétrée de telle sorte que tu es un ou plusieurs écrans, avec telle ou telle taille, telle ou telle profondeur… Tout cela c’est grâce au copper (un des composants géniaux de l’Amiga) et au travail fait dans Amos.
Cop move, Cop wait… sont des instructions qui te permettent en Amos de faire ta propre copper list. En fait c’est inclus depuis les premières versions d’Amos, tu peux faire un dual playfield « shadow of the beast » en redéfinissant toi même cette copper list. Par contre dans ce cas, tu ne peux plus utiliser les commandes relatives aux écrans, sprites etc… Tu dois effectuer ta propre implem. Interessant pour faire de l’Aga par exemple. Mais pas vraiment dans l’esprit Amos.
Effectivement pour le DMA, mais même en réduisant pas mal, on a des résultats moyens. On perd quasi systématiquement les sprites 6 et 7. Quand à la gestion de la réutilisation des sprites (donc pour avoir l’illusion d’avoir plus de 8 sprites), c’est assez foireux dès que cela scrolle.
En tout cas c’est ce que j’ai observé. Je suis d’ailleurs preneur de tout code permettant d’avoir une bonne utilisation pleine des 8 sprites avec scrolling. J’ai peut être mal paramétré le truc. Dans le truc que je suis en train de faire (http://eab.abime.net/showthread.php?t=98447) je n’arrive à exploiter que 5 sprites.
A+
Ouh la… je crois que ça part dans tous les sens… faire un dual playfield en redéfinissant sa propre copperlist ? le dual playfield est géré en hardware pour permettre une superposition des plans… ce n’est pas pareil que de décaler des bandes sur des hauteurs différentes (sans superposition), comme les bandes de nuages de SOTB…
A500 (1.3 / 2.0 / ACA500+) - A2000 - A1200
@Treesong : Pour tes idées, tu as toi même trouvé le problème « le code source » des extensions … D’ailleurs il faut aussi que les auteurs acceptent qu’on inclue « tout ou partie » de leur code source dans un produit (AMOS) ….
Pour le changement de plusieurs couleurs par lignes, on se retrouve face à un problème similaire à celui des sprites … Ce sont des instructions qui prennent des temps de calcule et le rafrachissement de l’écran se déroule à une vitesse constante …
Pour tout ce qui est sprites, bobs, etc … Je ne suis pas assez calé dans l’utilisation du Blitter pour proposer des solutions efficaces … Je me concentre surtout sur le support des bitplans, résolutions et couleurs …
Sinon, je crois me souvenir que je réalisais la définition de mes sprites avant celles de l’écran (dans des lignes non visibles en haut de l’écran)… J’avais alors un sprite de 32 pixels en 16 couleurs (utilisant 4 sprites à mon souvenir) pour le personnage, et 1 sprite de 32 pixels en 16 couleurs pour le décor de fond (qui utilisait lui aussi 4 sprites) …J’ai toujours le code source, il faudrait que je check ça pour voir exactement comment je faisais … Mais ce n’était pas une utilisation de 8 sprites séparés en 4 couleurs chacun et 16 pixels de large …Sinon, pour les icônes j’avais créé une méthode pour la Personnal.lib qui permettait de gérer des icones de 16×16 pixels assez rapidement ….
Tiens il semble que la réponse que j’avais faite n’a pas été reçue par le forum.
Bon une nouvelle version :
Ce que je voulais dire, c’est que les instructions pour OCS sont très optimisables puisque turbo et amcaf l’ont en partie accompli. Quoi qu’il en soit, c’est très bien ce que tu fais.
Pour une utilisation de quelques gros sprites, voir un autre petit truc que j’ai fait en début d’années (2 sprites de 16 couleurs et 32 et 16 pixels de large) (voir sur amigafrance, amos-beast-engine). Mais evidemment je suis tjrs interessé par tes sources.
EDIT : du coup, est ce que tu pourrais reporter une partie de ton code de personal.lib dans l’implémentation de paste icon ?
Bof, je ne pars dans tout à fait dans tous les sens :-). Ce que je voulais dire c’est que le dual playfield de beast (pas les parallaxes mais bien le mode 2*3 bitplanes utilisés partout dans ce jeu) possède un arrière plan en dizaines de couleurs du fait de la redéfinition des 7 couleurs. Impossible en amos standard sauf par copper off…
@Treesong : Pour mon pasteicon, si je peux, oui.
Pour le scrolling à SOTB, oui je connais (j’ai déjà décortiqué la palette entière de l’écran avec une action replay MKIII physique/Réelle sur Amiga500 en modifiant les couleurs 1 à 1 pour voir où elles étaient (à l’époque), plus de 300 couleurs affichées à l’écran :p
Et je comprends l’idée, mais je ne promets rien … Beast il s’agissait de modifier quelques couleurs, là je sens qu’on va me la pousser genre « je veux 256 couleurs par lignes! » … Ce qui n’est techniquement pas possible (enfin pas simplement je pense, voire pas du tout)…
Ah bien si tu as le temps, c’est top pour les icones. Donc pour info dans Amos turbo on a :
F Paste Icon X,Y,ICON
F 16 Icon X,Y,ICON
F 32 Icon X,Y,ICON
F 16proc Icon X,Y,ICON
F 32proc Icon X,Y,ICON
La première est une version générale beaucoup plus rapide. La seconde doit correspondre à ton extension personnal.Il y en a une aussi optimisée pour des icones de 32 de large.Les deux dernières utilisent le cpu plutôt que le blitter (donc potentiellement interessant dans le contexte du support de l’aga que tu es en train dev avec le 020).
Voilà c’est juste pour la syntaxe et si tu as du temps et de l’inspiration.
C’est quand même amusant de parler de cela en 2019 🙂
A+
Allez-y les gars, faites vivre Amos sur Amiga ! Bravo !!
/me a toujours quelques projets Amos jamais terminés qui ne demandent qu’à être réactivés 😉
Abonnez-vous à ma nouvelle chronique "En Route vers le Futur" sur Youtube !
Bon … J’arrive maintenant à ouvrir un écran en 128 ou 256 couleurs sans plantage complet de l’Amos cependant, la routine de « Cls » initiale de la création d’écran chie … Pourquoi je ne sais pas … Mais c’est une question de blitter.
J’ai commencé à préparer l’intégration de la palette de 256 couleurs dans la copper list … Mais je garde cela pour dès que le problème de « clear screen » blitter sera fixé.Ça avance tout doucement ….
EDIT : Problème fixé … Gestion interne des fenêtres sur 6 plans, mise à jour comme pour les écrans, à 8 bitplans. Mise à jour de la dimension de la structure totale à faire de suite puis je me mets aux couleurs AGA !!!!!
Oui …
En fait je discutai avec un gars de l’AMOS Factory sur ce sujet à l’instant.Mon idée originale serait de coder les couleurs 32-255 directement après les sprites dans la copper list, et avant un quelconque écran
Ainsi chaque écran aurait sa propre palette de couleurs de 0 à 31, et utiliserait une palette unique de 32 à 255 ….
Car sinon, redéfinir les 256 couleurs en 1 ligne, serait apparemment impossible.
- Vous devez être connecté pour répondre à ce sujet.
› Forums › AmigaOS, MorphOS et AROS › Développement › AMOS Professional 'améliorations'… C'est possible ?
