Inscription : 13 Jan 2010, 14:25 Message(s) : 2270
Bonjour à tous,
Ce topic est dédié à la partie graphique du moteur SCUMM Z80 pour CPC. Je le met dans la même section que celui sur la partie code, car il sera aussi question de parler de la réalisations des outils de conversions. Un cahier des charges sera établi en fonction.
Nous avons tous vu la quantité de sprites et autres décors, animations et écrans en tous genres dont regorge ce jeu. (ça se compte en milliers) Il est donc exclu qu'un graphiste les reprennent 1 à 1 pour en faire une version CPC, sauf si l'on veut que le jeu soit prêt en 2015.
L'idée est donc de partir des banques graphiques de la version EGA (16 couleurs) pour faire des banques graphiques CPC (mode 0) en convertissant les images aussi bien au niveau palette que résolution.
Pour ce faire, voici un exemple d'interprétation de la palette EGA (64) vers CPC (27) :
Ce n'est pas parfait, et demande à être ajustée en fonction des couleurs réellement utilisées pour le jeu.
Il faudrait donc : - réaliser une "moulinette" (script avec soft de dessin ?) pour appliquer la palette aux graphismes - convertir la résolution en faisant un resize vertical (50% - 200%) afin de passer ça à la sauce "mode 0". C'est le rôle de Fano si je m'abuse ... Désolé !
Au final, c'est une banque complètes en 16 couleurs pour tout le jeu, puisque le EGA n'en affiche pas plus.
Niveau présentation à l'écran, il faut donc considérer la zone de jeu en mode 0 et l'interface en mode 1. - Les dialogues seront à afficher dans la zone de jeu en mode 0 avec une police adaptée. (masquage ?) - L'interface servira pour afficher les actions ainsi que les choix dans les dialogues.
Il sera en suite possible d'adapter des screens, et autres scènes "spécifiques" en y mettant tout notre coeur en utilisant les spécificités du CPC.
Voila pour les grandes lignes de ce que devrait contenir le cahier des charges que je vais rédiger. En attendant, vos critiques sont les bienvenues.
Je pense personnellement que c'est dommage de partir d'une version tramée (EGA) avec des couleurs fades pour faire un resize. C'est partir d'un truc moche pour obtenir un truc encore plus moche.
Je pense qu'il faudrait : - partir de la meilleure version existante (VGA, par exemple), - baisser la résolution via un algorithme de type bilinear ou bicubic resize (mais pas un bête "un pixel sur deux") - passer par un algorithme de dithering adapté à la résolution et à la palette CPC, qui pourrait même faire du tramage intelligent si on le souhaite
Tout cela est à notre portée sur les machines d'aujourd'hui, donc profitons-en.
Inscription : 13 Jan 2010, 14:25 Message(s) : 2270
trance007 a écrit :
Je pense personnellement que c'est dommage de partir d'une version tramée (EGA) avec des couleurs fades pour faire un resize.
Je suis bien d'accord, mais cela permet d'avoir rapidement un jeu de graphisme pour faire tourner le moteur. Le tout en 16 couleurs (comprenant background, sprites et dialogues), sans engager de travaux gargantuesques.
trance007 a écrit :
partir de la meilleure version existante (VGA, par exemple)
Partir d'une versions VGA ne serait pas un soucis pour une version CPC+ (32/4096). Pour le CPC, pourquoi pas dans un second temps. Je vais quand même jeter un oeil à la version Amiga, voir ST (idem EGA il me semble). Il faut bien penser que tout doit tenir dans la palette.
trance007 a écrit :
baisser la résolution via un algorithme de type bilinear ou bicubic resize (mais pas un bête "un pixel sur deux")
Il n'est pas possible d'utiliser un algo de resize bilinear ou bicubic sur une image avec palette indexée. De plus, ce n'est pas le but ; Il faut réellement réduire par deux la résolution horizontale, afin que l'aspect ratio redevienne correct une fois affiché en mode 0.
trance007 a écrit :
passer par un algorithme de dithering adapté à la résolution et à la palette CPC, qui pourrait même faire du tramage intelligent si on le souhaite
Oui, pour les décors c'est la solution à envisager depuis une version VGA par exemple.
Il n'est pas possible d'utiliser un algo de resize bilinear ou bicubic sur une image avec palette indexée.
Ca, c'est juste une limitation des soft de graphisme. Il faut effectivement passer en 16 millions de couleur, afin d'avoir un resize fondu, qui conserve les détails de l'image. Ca donne une meilleure base pour repasser en 16 couleurs.
TotO a écrit :
De plus, ce n'est pas le but ; Il faut réellement réduire par deux la résolution horizontale, afin que l'aspect ratio redevienne correct une fois affiché en mode 0.
Diminuer la résolution par deux, ce n'est pas "prendre un pixel sur deux". On pensait comme ça dans les années 80, mais depuis, on a des techniques bien plus efficaces.
Inscription : 13 Jan 2010, 14:25 Message(s) : 2270
Je comprend bien ce que tu dis, car je le fais avec PSP depuis des années. Le soucis, c'est que ton resize bicubic (ou autre) va utiliser des couleurs qui ne sont pas dans la palette du CPC, pour simuler un pixel intermédiaire. (voir de l'alpha) Et ça, ce n'est pas gérable quand au final tu veux garder que 16 couleurs.
Dans tous les cas, bicubic ou non, au final tes pixels seront étirés ... Ton gain est donc juste "virtuel".
Bon alors moi j'ai déjà fait du resize 50% horizontal... Or il se trouve que la version VGA est elle même tramée (et pas qu'un pezu) et qu'on retrouvce aussi le problème des lignes horizontales... Car le VGA c'est pas non plus du true color, lol...
Avec convimgcpc il y a une option de lissage qui permet de ne pas avoir ces lignes horizontales, au prix que ça use un peu plus de couleurs par contre, et necessite d'être quand même bien retouché... affiné et surtout nétoyé des artefacts parasites inévitables, le problème est que convimgcpc est pas adapté : il ressort les images en format CPC seulement, pas moyen de récupérer une version 1 pixel = 1 pixel (donc réellement 160x200) exploitable sous PC...
Presque domamge car ça peut aussi permettre d'avoir une bonne base de départ quand même...
la je vais voir les redimensionnements avec divers utilitaires variés genre Gimp et paint.net, en variant les options de qualité de redimensionnement, avec VGA et EGA...
Sinon avec les outils de selection "magique" on peut par exemple séléctionner toute la zone de telle ou telle couleure... avec ou sans les trames, donc en faisant de la manip en peut sélectionner seulement les zones de couleur franche, les passer sous une autre teinte en attendant, puis les zones tramées et elle même les fusionnées avec une autre couleur tièrce, fait le redimensionnement, puis remplir avec de la trame telle ou telle zone ainsi séparées...
Bref je travail sur diverses méthodes...
De ce que j'ai vu, les principaux problèmes viennent des rendus des bois (le orange vas bien en fait) mais aussi les rochers (sur l'ile de monkey, la carte, pas simple) et le fait que la version EGA utilise systématiquement 2 gris...ce qui reste toujours problématique on le sais, lol...
Mais parfois en reprenant la pixélisation (approximative donc) du EGA mais un rendu de couleurs plus VGA ça peut limite passer.
Sinon euh... Passer les graphismes sous Graphicwizard permet de trés vite avoir une version CGA/Monochrome en fait...avec un rendu pas si mauvais quand même mais je me doute bien que euh...vous m'envooyez chier d'office d'avoir suggéré une version Mode1, lol...
Mais n'oublions pas qu'un CPC est plus un CGA amélioré qu'un EGA...
Et surtout ça permet avant tout d'avoir quelques pages et sprites tout de suite exploitable pour faire la mise au point du moteur...
Et oui, il faut penser qu'on doit bosser sur des images en 160x200 car je suppose qu'on vas garder les proportion d'un CGA/EGA/VGA/Atari ST donc le pseudo 320x200 donc 160(doubles)x200x16... passque bon, déjà qu'en mode0 ça va pas être simple si en plus on se retrouve comme trop souvent en format spectrum soient 256... 128pixels euh... beurk quoi. La fenètre rikiki ça va bien 5 minutes lol...
Pour une version PLUS, bin euh, à part implémenter peut être les Scrolls horizontaux en Hard, et quelques effets spéciaux/patches en sprites Hards (mais pas boucoup) et facilité une rupture d'écran donc pour les actions/inventaire en Mode1... LE reste sera juste un re-travail graphique donc une palette plus évidente forcément, bien que avoir plus de gris et marrons risque de faire en fait des pages carrément conçues différament...à voir.
Aussi je recommende aux graphiste de prendre un poil de temps (pas trop) en essayant d'adapter aussi une version PLUS, mais vu qu'on reste en pixels doubles, ça change assez peu de choses en fait je pense, le plus difficile étant plus le travail de pixels que celui des couleurs, car les bleu verts, jaunes, Rouges/oranges, on a largement ce qu'il faut sur CPC quoi.
Bon tien, je m'y remet moi...
Ah oui tien, il y aurtait une tache assez délicate à faire, concernant les sprites... Bon déjà, je ne sais pas trop comment on vas se démerder pour le masquage des sprites, peut être c'est déjà inclu dans les Datas qu'on a récupéré ? MAis en gros :
3400+ sprites, il faut classer et trier tout ça, passque quand j'ouvre le fichier et demande a mon pauvre PC d'afficher ça en miniatures, bin euh, il a vite du mal et met presque une minute pour ouvrir tout ça lol... Donc séparer les différents persos... et aussi les sprites courants (normaux : marche, parle, etc...) des sprites spéciaux (cinématiques genre la bitaille final où LeChuck frappe par exemple...) Genre euh, certains sprites (les sauvages) ne sont présents que sur l'ile au singe, qui aura une autre palette que l'ile de mélée (pleins de bleus par exemple) et des pirates en fait...
Bref oui il y aurait un petit travail de triage des sprites et cartes en fait...
C'est con à dire mais ça aiderai bien je pense. Notament pour se partager le boulot... Et donc tant qu'on y est, voir quelles frames d'anim virer... on doit logiquement pouvoir diviser par 2 les animes je pense, et ça resterai pourtant largement trés bien...
C'est je pense le sacrifice necessaire pour qu'un tel jeux tourne sur un ordi 8bit en 128K et du sprite soft seulement... C'est pas comme si je demandais de tout tirer vers le bas non plus, si ?
Et enfin bin, se partager le boulot donc une fois que les datas sont triés et empaquetés par séquences, on se les partages...
Et oui, définir comment les sprites seront gérés notament pour la transparance (masquage) mais là je pense qu'un encre le fera bien...)
Mais déjà les décors sont un bon départ...
Citer :
Diminuer la résolution par deux, ce n'est pas "prendre un pixel sur deux". On pensait comme ça dans les années 80, mais depuis, on a des techniques bien plus efficaces.
Bin franchement, moi mes premiers essais font plus ou moins ça, ce qui explique que les superbes trames régulières EGA sont remplacées par de longues lignes horizontales... Mais à voir avec d'autres utilitaires et réglages...
Inscription : 15 Oct 2007, 02:49 Message(s) : 402 Localisation : Les Sucres en Morceaux
Concernant les conversions graphiques, quel est le but : - Obtenir des gfx temporaires rapidement pour avoir un jeu fonctionnel le plus vite possible ? > Dans ce cas, la pire des méthode est la meilleure pourvu qu'elle soit rapide.
- Mettre des graphistes sur le coup pour avoir un jeu le plus beau possible ? > Dans ce cas, et au vu de mes nombreux essais sur d'autres exemples, il est TOUJOURS mieux de partir d'une image de bonne qualité. Car sauf à compter que le transfert soit raté, les détails sont aussi transférés. Ils ne sont peut-être pas lisibles, mais il existent. Dans certains cas, il m'arrive même de voir les laideurs du JPG après transfert !
Autres questions en vrac : - Combien le jeu comporte-t-il d'écrans complets à transférer ? - Sur combien de personnes pouvez-vous compter ? - Que comptez-vous afficher pendant les accès disc (compte tenu que les rasters gicleront) ?
Tiens, dans l'esprit de ce que je disais sur quelques transferts mode1... en fait c'est complètement fait à l'arrache bien sûr, avec le bon vieux graphicWizard cpc...
l'avantage c'est que euh, c'est loing d'être parfait mais c'est super rapide et "praticable" je pense...
Citer :
il est TOUJOURS mieux de partir d'une image de bonne qualité.
à la rigueur on aurait presque mieux en redimensionnant la version moderne true color, et partir de ça... Passque comme je l'ai dit, le VGA n'est absolument pas du true color, ça reste pixelisé et tramé à donf...donc les passages en mode0 16 couleur laisse aussi apparaitre les trames en lignes horizontales...
Mais franchement, il convient de s'inspirer des 2 (EGA et VGA) au final.
Vous n’êtes pas autorisé(e) à consulter les fichiers insérés à ce message.
Inscription : 27 Jan 2010, 09:04 Message(s) : 117 Localisation : Barcelona, España
Pour ma part, je me suis fait une petite moulinette avec Photoclope et, du coup, de façon assez rapide, j'obtiens des résultats acceptables pour tester le moteur en partant de la version VGA... (Il est bien évidemment possible d'obtenir bien mieux en passant du temps à faire des retouches manuelles, on est d'accord, hein... ^^ En plus, là, je n'utilise que 10 couleurs...)
Vous n’êtes pas autorisé(e) à consulter les fichiers insérés à ce message.
Malheureux, pour ces séquences plein écran, tu n'as pas autant de limitations en fait...
Vu que euh, y'a en fait pas vraiment de sprites... Juste du texte soient 2 couleurs maxi, et un pointeur, sachant que le type GUI souris n'est même pas necessaire : surbrillance menu au clavier/joy...
Les portraits VGA sont superbes il est vrai, par contre il y a souvent un superbe dégradé en fond, qui euh... bin en fait il gène souvent pour le transfert, idéalement on devrait plus passer un fond noir ça laisse alors de la couleur pour les visages et vêtements et fait ressortir les visages en fait...
Bon, moi j'ai tenté ma métode à partir de séléctions de teintes (outil magique de selection de chez paint.net...) à partir de divers transferts bruts mais rêglés différaments... à partir autant de VGA que EGA en fait... Genre je redimensionne un premier coup le VGA et le EGA sous paint.net (testé plusieurs méthodes, certaines laissent la trame en lignes, d'autres merges harmonieusement). Puis je fait des passages en 16 couleur notament avec convimgcpc, plein de rêglages divers en fonction de si j'aime telle partie ou telle autre sur la base du VGA ou du EGA... Genre la montagne, elle rend mieux a partir de je ne sais plus lequel (EGA je crois) de même que la flotte, mais le VGA permet un meilleur rendu de la rivière ou de la foret voire des plages... Et en jouant avec les contrastes voir tramages légers, on arrive a ce qu'on veut. Donc touche imprimé écran, collé dans paint.net, découpage propre, recollage avec un 320x200 pixels parfaitements doublés, redimensionnement... aillé j'ai mes bases de travail. donc j'ouvre tout ça sous paint.net, avec une page vierge en 160x200... et je commence les selections "magiques", quitte a intervertir des teintes dans le process histoire que un re-collage n'éfface pas les bons trucs voulus... et quand ça prend bnne gueulle, bin refignolage grossier de la palette (comptage aussi...) histoire de virer les trucs trop superflus...
Puis passage sous Grafix2 histoire de fignoler la palette, faire les dernières retouches aussi et vérifier le nombre de couleurs, etc...
Ne reste plus qu'a fignoler les choix artistiques par contre entre le tramage ou pas pour la montagne par exemple (y'a un petit bout de marron tramé dans l'ombre du cratère à l'intérieur... à voir)... le tramage de la flotte, je l'avais fait à la main sur mon premier transfert à l'arrache d'il y a une semaine (avec les trames passées en lignes horizontales...) Pour la flotte je pense que ça y fait bien, mais pour le reste bof (montagnes et fôrêts...) niveau tramage régulier et généralisé... quoique la plage j'en ai mis, mais à voir.
et donc bien sur tramer subtilement la montagne, trés légèrement, et fignoler la côte par endroit...et la forêt aussi peut être.
Je vous montre...
commentaires bienvenus.
oh, c'est en mode pixel simple, donc à visionner avec Grafix2 ou ConvimgCPC... Quoique non mon visionneur Xnview semble le passer en pixels doubles, merci le passage png par grafix2 je pense...
sous grafix2, y'a 16 encres mais 2 sont doublées en fait... le bleu clair et le vert clair sont doublés donc je n'utilise que 14 couleurs logiquement, ce qui peu laisser 2 teintes pour du texte... ou pour affiner du dégradé (vert en plus et/ou bleu en plus pour la mer...)
Vous n’êtes pas autorisé(e) à consulter les fichiers insérés à ce message.
Inscription : 13 Jan 2010, 14:25 Message(s) : 2270
Supersly a écrit :
Concernant les conversions graphiques, quel est le but : - Obtenir des gfx temporaires rapidement pour avoir un jeu fonctionnel le plus vite possible ? > Dans ce cas, la pire des méthode est la meilleure pourvu qu'elle soit rapide.
C'est le but dans un premier temps. Il faut un contenu "viable" pour tester le moteur avant tout. A quoi bon se lancer dans des travaux d'Hercule, tant que ça ne tourne pas. Donc, la version EGA remplira parfaitement ce rôle.
Supersly a écrit :
- Mettre des graphistes sur le coup pour avoir un jeu le plus beau possible ? > Dans ce cas, et au vu de mes nombreux essais sur d'autres exemples, il est TOUJOURS mieux de partir d'une image de bonne qualité.
Oui, il n'y a pas de miracles. Maintenant, à moins d'embaucher un studio de 10 chinois travaillant régulièrement, il faut toujours que se soit automatisable. Pour cela, la version Amiga semble la mieux adaptée (pas de tramage) ; Je vais aussi faire des essais. Sachant qu'il y aura toujours un vrai travail de graphiste possible sur les écrans fixes.
Supersly a écrit :
Autres questions en vrac : - Combien le jeu comporte-t-il d'écrans complets à transférer ? - Sur combien de personnes pouvez-vous compter ? - Que comptez-vous afficher pendant les accès disc (compte tenu que les rasters gicleront) ?
- Je n'ai pas la banque sous les yeux ... J'aurais dit une vingtaine. Si quelqu'un à la réponse ? - Pas suffisamment pour faire tout le travail à la main en tout cas (2 ou 3), but you are welcome ... - Bonne question. Si c'est trop fréquent, peut-être faudra-t-il trouver un compromis.
le dossier EGA de base fait 76 fichiers, ça comprend me semble t'il les "décors" (panorama ou on se ballade, intérieur des bateaux maisons...rues...) les portraits (dialogues voire certaines cinématiques), et les maps (cartes de l'ile mélée ou du singe...)
Certains décors faisant je pense maximum 3 écrans de large, mais en gros 320 pixels (1 écran) pour la plupart, et 2 écrans à la parfois (640). le plus long fait 1008 de large... soient 3 écrans donc ? Quelques un font un truc batard genre un poil plus que 1 écran de large...
et tous font 144 pixels de hauteur car il y a la place du texte/action/inventaire... Mais les cartes et quelques portraits de type cinématique sont en 320x200 donc "plein écran"...
Mais je ne sais pas trop si c'est complet...
Quand au fichier avec les sprites il comprend pour le premier batch (partie 1) 3433fichiers. Après je ne sais pas trop si j'ai réussit a décompressé la 2ème partie, car ça buggait, ou alors il fait le mix des 2 parties, lol...
Faudrait voir comment ce cher Hwiikaaaa il a découpé/séparé ça...
sachant que pour les sprites, ça vas des variantes de tête, de la souris qui se ballade, juqu'aux gros trucs de cinématiques presque plein écran, genre Guybrush qui se fait ejecté d'un canon depuis le bateau vbers l'ile, en plein écran et 2 frames, a la parlote ou le fait de marcher en 12 frames facile pour chaque angle de vue...
Citer :
MacDeath > je trouve le résultat satisfaisant, la trame sur l'eau fonctionne bien...
Merci. Le tramage de l'eau je l'avais fait plus ou moins a la main en convertissant les lignes en trémage mais je pense qu'il est facilement poible de faire plus efficace comme méthode. Mais là il respecte la version EGA en fait...qui a l'avantage donc de donner des indications pour un bon tramage alors.
le problème que j'ai trouvé, c'est que les outils de conversion ont vite tendance a mal choisir les bleu pour la flotte... Genre il ne partent pas vraiment du bleu foncé mais du bleu moyen, et collent le bleu grité qui euh, fait un peu tache, je lui préfère le bleu subtilement violacé...puis bien sûr les 2 bleu clairs (là j'ai mis le clair foncé de base, pas le superméga clair presque blanc...lol) mais vu qu'il me reste 2 slots, je pourrai en rajouter aussi...
Idem pour les Verts...pleins de doublons, pas toujours simple. mais les 2 verts de base vont bien je trouve, vu qu'il y a du jaune, du noir et du marron voir le jaune foncé...
pour le coup, j'ai d'ailleurs mis les 3 jaunes, mais idem on peu surement s'en passer de par le tramage avec le blanc.
Citer :
J'aurais dit une vingtaine. Si quelqu'un à la réponse ?
Haha, petit joueur !!! Si seulement c'était si peu, on aurai déjà tout torché lol.... Nan je déconne.
Mais honètement les décors, c'est pas ce qui me fait le plus peur... les sprites (j'ai qu'un seul des 2 dossiers) contiennet par exemple les effet de variation du décors (animation, quand on passe derière les éléments, non ?) et là bin entre le travail de trie, et le nombre tout simplement... Enfin les sprites, c'est ce qui nécessite la finesse et l'expression, or au passage mode0 vas y avoir de la casse je pense...
Que de la texture de rochers, de mur ou de flotte, ça passe bien plus facilement...
Juste un petit truc en passant, les sources de ConvImgCpc sont disponnibles, pour faire des adaptations spécifiques par exemple. Ou si il y a un truc un peu spécifique à faire, je peux peut-être trouver un peu de temps pour l'implémenter
Utilisateur(s) parcourant ce forum : Aucun utilisateur inscrit et 81 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