Voici quelques exemples d'images digitalisées pour Amstrad CPC. J'aimerais créer un jeu d'aventure graphique en mode 0. Pour l'instant, je m'intéresse aux graphismes. Le mode visé est le mode 0, avec 16 couleurs choisies parmi la palette de 27 couleurs (0 à 26). Il y a un tramage des pixels afin d'avoir plus de teintes possibles.
Réalisées avec le logiciel de retouche d'image Gimp sous Linux. Palette personnalisées Amstrad CPC 27 couleurs. Contactez-moi pour toute question concernant la technique ou le projet de jeu d'aventure.
Bugatti :
Pièce jointe :
cpc_2_Bugatti_Chiron.jpg
Sun rise :
Pièce jointe :
cpc_bigislandsunset2_mt5j0r.jpg
Montagne :
Pièce jointe :
6oVknb_cpc_jpg.jpg
Temple et cygnes :
Pièce jointe :
nature_cpc2.jpeg
Digitalizer
Vous n’êtes pas autorisé(e) à consulter les fichiers insérés à ce message.
Inscription : 13 Jan 2010, 14:25 Message(s) : 2163
Bonjour et bienvenu,
Il y a un logiciel du nom de ConvImgCpc qui fait de même en activant l'option "Trame TC", tout en proposant d'enregistrer le fichier binaire au format d'affichage CPC. (vous postérisez à 5 et tramez les couleurs intermédiaires)
Je vais aller voir le programme dont tu me parles. Effectivement, avec Gimp, je postérise à 4 ou 5, puis je bascule sur une palette cpc, tramée ou pas, mais avant cela, j'effectue une balance des blancs, une augmentation de 200% de la saturation des couleurs, voire 300%, car celle du CPC sont saturées. Je programme un peu en assembleur en utilisant Winape. Je sais afficher un sprite, mais je dois apprendre à gérer l'affichage du fond ou pas, la transparence (couleur de fond du sprite). Je pratique le cpc en mode basic avec un peu d'asm. Je ne programme pas encore orienté objet sur cpc... Devrais-je ? Est-ce possible ? Et aussi, comme en mode 0, un octet fait 2 pixels entrelacés, il faut tester le pixel gauche genre AND &x10101010, etc ... Idem pour déplacer un sprite d'un demi octet (donc 1 pixel). Faut-il prévoir des sprites de demi-octet ?
Si vous pouvez m'éclairer sur ces points, encore faut-il que mes questions vous parlent, car je sors tout juste du basic.
La transparence des sprites, vaste débat et nombreuses idées reçues => Il y a beaucoup de façons de gérer la transparence des sprites et réserver une couleur pour la transparence est une possibilité mais c'est loin d'être une obligation. On peut avoir tout simplement des masques associés aux sprites et conserver toutes les couleurs. Oui, c'est deux fois plus de mémoire. Avec du code généré, le masque n'existe plus. On affiche ou on n'affiche pas le pixel et c'est tout. Certains testent les octets sans tenir compte des pixels (le masque est alors sur l'octet et non les pixels). Plutôt que tester pixel droite et pixel gauche, on préférera utiliser une table de conversion octet vers masque, ensuite on masque, on mélange, on remet.
Concernant les demi-octets (en fait, déplacer un sprite au pixel) il y a plusieurs écoles là encore mais la majorité préfère éviter de le faire, on bouge à l'octet et basta
C'est ça qui est bien avec le CPC, c'est que comme il faut tout faire soi même, on peut adapter la technique à ses besoins. Il n'y a pas de bonne méthode, il y a des méthodes adaptées ou non à ce que tu veux faire
Inscription : 13 Jan 2010, 14:25 Message(s) : 2163
Oui, un ajustement de la colorométrie de l'image source est forcément nécessaire pour tous types de conversions/retouches de l'image. Et effectivement, postériser à 4 permet souvant de simplifier la conversion d'images non tramées en gardant un maximum de teintes intéressantes. Aussi, tous ces traitements en amont permettent de gagner du temps, mais ne dispensent pas de devoir retoucher les pixels des images par la suite pour gagner en finesse. C'est là que s'arrête l'assistance de la machine.
Ah ben ça, la conversion seule a ses limites... ça met souvent pas mal de gris partout, pire, les macroblocks JPG des sources ressortent avec le forçage de la saturation, etc.
ça demanderait déjà tant de traitements auto supplémentaires pour avoir un meilleur résultat...
Ou alors on fait du machine learning chez les graphistes?
Merci. Je ne connais pas DAAD. L'idée était de bricoler un moteur en point and click, ou en mode saisie. J'aimais bien Monkey Island et Indiana Jones sur Amiga, mais mes premières amours vont au cpc, Rick Dangerous II une merveille d'animation, au pixel.
Bravo pour les images ! un travail bien original !
Mais que vois-je, - sacrilège! - des fichiers JPG ?! je suggère fortement un format d'image qui compresse sans destruction, cf. PNG ou BMP, pour partager ton travail. Car sinon, ton image pourrait être malheureusement "améliorée" par l'introduction de nouvelles couleurs, mais aussi "altérée" par l'introduction de "zones carrés" dues a la compression JPG.
Le gros avantage de DAAD est que ton jeu pourrait être disponible sur de multiples ordinateurs 8, 16 bit et msdos avec un seul source du langage de DAAD, ce qui permettrait de te concentrer plus sur l'histoire et les graphismes.
Mais je peux tout à fait comprendre que tu veuilles travailler sur ton propre moteur.
Utilisateur(s) parcourant ce forum : Aucun utilisateur inscrit et 2 invité(s)
Vous ne pouvez pas publier de nouveaux sujets dans ce forum Vous ne pouvez pas répondre aux sujets dans ce forum Vous ne pouvez pas éditer vos messages dans ce forum Vous ne pouvez pas supprimer vos messages dans ce forum Vous ne pouvez pas insérer de pièces jointes dans ce forum
Connexion
Inscription
FAQ
