ECS/OCS WB copper funky !
-
(edit: nouvelle version au 1er juillet)
Je cherche à mettre en valeur mon amiga 600 avec 1Mb de ram, et je veux booter sur un WB qui laisse le max de ram, pour le max de confort.
Je reste donc en 4 couleurs (pour la vitesse c’est important aussi). Problème: ça fait gris et triste. Insupportable ! 😡
J’ai donc fait un petit exe qui patche les couleurs du WB avec des dégradés copperlist. C’est fait en asm , l’exe pèse 484 octets, idéal pour booter vite.Seulement 1kb de ram est gaspillé par ce patch. ( le patch aga qui existe pour ça ne fonctionne pas sur ecs/ocs) Je fourni avec le source asm pour ceux qui veulent modifier les couleurs (avec devpac ou phxass, c’est pas trop compliqué, j’ai commenté, et non je ferais pas de tool de préférence ! )
un premier dégradé affecte la barre du haut (noire et moche sur OS2, couleur 1), un deuxiéme bariole la couleur « bleu » (couleur3) sur tout l’écran. Ensuite jouer avec wbpattern OS2 et la couleur 3 donne des choses interessantes.
(edit: vendredi 24 juin: update nouvelle version avec borderblank ET compatibilité OS1.3 )
WBcopperOCSECS.lha a télécharger en exclu ici
Faut juste copier WBcopper dans c: et le lancer en fin de startup ou à la volée.
Bug connu: un CloseWorkbench() (avec dpaint par exemple) annule le patch.
Si vous connaissez des patchs ou des trucs de config sympa sur os2 ou pour avoir plus de ram au boot je suis preneur.
ah oui tant que j’y suis: les mecs de pURE m’avaient montré à la fin des années 90 un ensemble d’outil workbench qui enregistrait les phases d’un dessin à la souris et permettait de « rejouer le dessin » tout seul, dans une fenêtre du WB. (on voyait le dessin se faire pas à pas)… c’était quoi ce truc ? Quelqu’un à ça ?
edit: allez je me suis déchiré a faire une conf 2.x sous uae pour faire des screenshots:
WITHOUT:
BEURK ! ON DIRAIT UN MINITEL }:-@ !!
WIZZ !!!!: (edit:update)
OH ! CELA ETINCELLE DE MILLE FEUX !!! POUR LE COUT DE SEULEMENT 1ko MADAME ! 😮
ah oui tant que j’y suis: les mecs de pURE m’avaient montré à la fin des années 90 un ensemble d’outil workbench qui enregistrait les phases d’un dessin à la souris et permettait de « rejouer le dessin » tout seul, dans une fenêtre du WB. (on voyait le dessin se faire pas à pas)… c’était quoi ce truc ? Quelqu’un à ça ?
si je me souviens bien, c’était l’équipe de dev’ de TVPaint qui avait crée cet outil, j’ai ce programme quelque part mais où..
dAn ?
Cool l’ours ! je chercherais plus d’info sur le net peut être… pulp doit savoir aussi.
Au fait pour mon petit tool: ça ne peut marcher qu’a partir de OS2.x ! graphics.library/VideoControl() n’est dispo que depuis la v36 ! (donc ok pour A500+/A600/A3000) mais pas pour A500/A2000) … j’ajouterais un test de version.
J’ai également ajouté le « hack » BORDERBLANK, qui mets les bords tout noir, ça utilise également videocontrol().
C’est connu des utiliateurs d’AGA également. Ca mets du noir sans utiliser aucune des couleurs WB. J’ai découvert qu’à l’origine c’est un feature fait pour du genlock. (les bords ne sont alors pas dessiné du tout par le beam).
Bien joué Krabob, tu as eu une idée lumineuse !
dans la fenêtre y’a marqué vertical rainbow alors qu’il est horizontal… Il peut le faire vertical aussi donc ?
disons que « les couleurs changent de haut en bas », donc pour moi il est vertical… façon de parler.
Allez un petit cours de copperlist pour hivernaal pour répondre à sa question:
sur ces écrans on est en 4 couleurs, soit 2 plans en 2 couleurs (ocs/ecs peut monter en 32 couleurs avec 5 plans,…). Normalement, la palette de couleurs est fixe pour tout l’écran.
… hors, le chipset graphique de l’amiga excute lors du balayage vidéo une « copperlist », qui est une suite d’instructions habituellement trés courte: il y a 2 instructions possible: « Wait » et « Move ».
en gros, « wait » attend une position du beam qui trace l’écran (ici on attend le début d’une ligne ) et move peut changer une valeur quelconque du mode graphique, dont les couleurs de la palette. (mais peut changer aussi le reste, c’est comme ça qu’on peut voir 2 écrans intuitions avec des résolution et des couleurs différentes.).
note: faire un « move » avec la coppprlist prends « 8 pixels ».
Dans le cas d’un fake comme au dessus, on a trés peu de wait et de move pour faire un dégradé.
en théorie, on peut faire de très grosse copperlists pour changer une couleur horizontalement, et on est alors obligé de le refaire a chaque ligne ! … ça prendrait en gros 40ko de ram pour changer de couleurs tout les 8pix, 20ko pour changer tout les 16…
mouai bon, à essayer… aprés, on a ce qu’on appelle un écran « copper chunky » avec des gros pixels mais en 4096 couleurs quoi.
edit: a priori ça doit pas etre possible sur le wb a cause des fonctions systèmes qui permette de modfier la copper… et qui autorisent que certains trucs….
(redit: après vérif, si, l’attente horizontale est possible.)
OK, merci pour le cours
sur ECS ? parce que celui qui était livré avec magicwb ( ou je sais plus quel truc de vapor software) demandait obligatoirement l’AGA. ( celui que je prépare à également la particularité de changer plusieurs couleurs, mettre le BORDERBLANK et être short-sized). Donc je pense qu’il est problable que plusieurs softs de ce genre existe de toute façon (facile à faire quand on connait le trick)
note: faire un « move » avec la coppprlist prends « 8 pixels ».
Merci pour l’info Je me suis toujours demandé pourquoi les dégradés étaient si « grossiers » sur Amiga… malgré les 4096 couleurs théoriques. Maintenant j’ai la réponse!
On ne peut donc pas (via le copper du moins), avoir de dégradés plus fins que 8 px de hauteur pour chaque couleur ?
leo a écrit :
note: faire un « move » avec la coppprlist prends « 8 pixels ».
Merci pour l’info Je me suis toujours demandé pourquoi les dégradés étaient si « grossiers » sur Amiga… malgré les 4096 couleurs théoriques. Maintenant j’ai la réponse!
On ne peut donc pas (via le copper du moins), avoir de dégradés plus fins que 8 px de hauteur pour chaque couleur ?
ah ben si, en hauteur on peut le faire au pixel, mais en horizontal, le move du copper prend l’équivalent de 8 pixels basse résolution en temps d’exécution.
(edit: oopse pas vu réponse gilloo) non, un move prend 8 pixel de temps « horizontal », ça correspond a 8 pixels de largeur et 1 pixel de hauteur. On peut donc changer la palette a chaque ligne, mais changer 32 couleurs prendrait…256 pixels de large.
techniquement, on peut donc faire ce genre en 1ne couleurs, voit sans mémoire bitmap du tout !
là ya surement un trick avec 2 couleurs pour l’effet sinusscroll:
….
Ensuite on a 16 teintes possible pour le rouge , le vert et le bleu, soit 4096 couleurs sous ecs/ocs … donc si on veut étendre un dégradé le long de l’écran, on peut pas faire aussi fin qu’en aga.
- Vous devez être connecté pour répondre à ce sujet.
› Forums › AmigaOS, MorphOS et AROS › Développement › ECS/OCS WB copper funky !