Re: La programmation Mega Drive pour les Nuls expliquée par les Pros

[Stef]

Et sous gimp tu peux utiliser des plugins pour faire une réduction de couleurs au format MD (ou autre). Pour ça j'utilise les plugins XiColorDither et XiQuantizer de XiMagic qui sont réellement efficaces !
Tu peux d'ailleurs les utiliser dans pas mal d'autres softs d'imagerie...
J'utilise aussi mtPaint, il est assez simple et qui permet de modifier facilement l'ordre de la palette (ce que j'apprécie beaucoup).

[Invité]

J'utilise aussi mtPaint, il est assez simple et qui permet de modifier facilement l'ordre de la palette (ce que j'apprécie beaucoup).

CAD ?? la palette, ou les couleurs de la palette ??

[Stef]

Heu je voulais l'ordre des couleurs dans la palette. Genre si tu veux remettre le noir à la position 0 rapidement.

[Invité]

Ah c'est bien ce que j'avais compris alors   
Bah gimp le fait, pas besoin de passer par mtpaint, j'aime bien mtpaint car tu peux tester un cyclage de couleur .

[Stef]

Oui oui on peut le faire aussi dans Gimp mais l'opération est plus simple dans mtPaint (ou alors je m'y prend mal sur Gimp). Cyclage de couleur ? tu veux dire rotation de palette ?

[Invité]

Cyclage de couleur ? tu veux dire rotation de palette ?

Oui, il intègre cette fonction,avec un délai paramétrable, pour tester le rendu c'est pas mal .
Sous gimp pour changer les couleurs je fais couleurs -> carte -> réorganiser la palette .
Ensuite je déplace les couleurs via glisser/déposer .

[Stef]

Cyclage de couleur ? tu veux dire rotation de palette ?

Oui, il intègre cette fonction,avec un délai paramétrable, pour tester le rendu c'est pas mal .
Sous gimp pour changer les couleurs je fais couleurs -> carte -> réorganiser la palette .
Ensuite je déplace les couleurs via glisser/déposer .

Ah oui en effet, ça me dit quelque chose ce cyclage de palette en effet, enfin perso pour le moment je n'ai jamais eu besoin de l'utiliser
Sinon c'est bien la manip que je fais sous gimp, c'est juste un peu plus long que dans mtPaint ou tu fais juste un drag & drop tout en maintenant SHIFT enfoncé

[Invité]

ah ok, effectivement c'est plus rapide    ..

Le cyclage j'ai eu 2/3 fois à l'utiliser, et puis j'y pense pas à l'utiliser, donc je fais ça à la main .

[Invité]

Je fais remonter le topic, vu que je me relance pour de bon dans mon projet.
De plus, il y a, j'en suis sûr, des tas de choses à ajouter dans l'index pour ceux qui, comme moi, veulent apprendre à parler Klingon.

[Invité]

Premier essai avec GIMP 2. Un tunnel tortueux avec une lumière au bout, fait en 5 minutes avec la résolution et les contraintes couleurs de la Mega Drive.

[Invité]

C'est pas mal .
Le début est toujours délicat, c'est le moment où tu doit trouver tes marques, aussi bien niveau caractéristique de la machine, que les logiciels à utiliser .

Pour le dernier point y'a pas de recette miracle, en fait chacun trouve le truc qui lui convient .

[Stef]

Premier essai avec GIMP 2. Un tunnel tortueux avec une lumière au bout, fait en 5 minutes avec la résolution et les contraintes couleurs de la Mega Drive.

C'est pas mal en effet, je trouve peut etre le choix du bleu clair un peu bizarre. Comme si tu étais restreint par la master palette de la MD alors qu'avec 512 couleurs tu dois bien avoir une nuance de gris ou de marron qui colle un peu mieux ?
Enfin si tu l'as vraiment fait en 5 minutes tu es très balaise moi je suis vraiment incapable de pondre du pixel art correct, et surtout pas en 5 minutes  

[Invité]

Merci pour les encouragements, les mecs, ça fait plaisir.   

Sinon, Stef, concernant les 3 nuances de bleus que j'ai utilisé (dont l'électrique), c'est totalement voulu. C'était pour donné un côté magique à la scène, pour souligner que la lumière qui se trouve au bout de ce corridor n'est pas naturel mais d'ordre mystique.

[Stef]

Merci pour les encouragements, les mecs, ça fait plaisir.   

Sinon, Stef, concernant les 3 nuances de bleus que j'ai utilisé (dont l'électrique), c'est totalement voulu. C'était pour donné un côté magique à la scène, pour souligner que la lumière qui se trouve au bout de ce corridor n'est pas naturel mais d'ordre mystique.

Ah ok dans ce cas c'est vraiment une réussite de bout en bout  

[Invité]

Tu travailles sur un projet en ce moment, Stef ?
Je te pose la question car je me dis qu'avant de me lancer sur le mien, je travaillerai volontiers en tant que graphiste avec quelqu'un qui connait bien son sujet, afin d'en apprendre d'avantage sur les contraintes et la façon de procéder pour éviter les erreurs de débutants justement.

[Stef]

Je travaille toujours sur ma librairie qui permet de développer sur Megadrive mais à côté de ça je n'ai pas de vrai projet de jeu (en fait je viens de terminer un mini jeu mais on va dire que c'était une "commande spéciale" ^^).
J'aimerai me remettre sur ma petite démo "Starfox" version MD dés que j'aurai du temps mais du coup, côté graphique je n'ai que de la conversion à faire, pas de vraie création.

Pour les contraintes graphiques, déjà il faut connaitre les contraintes "techniques" hard de la machine. Par exemple l'affichage se fait avec des tiles de 8x8 pixels. Chaque tile pointe sur une palette de 16 couleurs dont la couleur 0 est transparente. Ces 16 couleurs sont définis parmis une master palette de 512 couleurs (3 bits par composante RGB).
La grosse difficulté sur MD c'est que tu n'as que 4 palettes de 16 couleurs pour tout (les sprites et les 2 plans) ! Autant dire que tu as plutot intérêt à bien "préparer" ce que tu veux faire pour faire en sorte que beaucoup d'éléments aient des couleurs en commun

Après y'a les autres contraintes plus liées au développement. Par exemple ne pas utiliser trop de tile différents pour tes arrières plan car la mémoire vidéo est limitée (sur MD tu tournes au alentours de 1400 / 1500 tiles en VRAM avec le reste à côté). Si tu utilises trop de tiles différents il faut mettre à jour la VRAM en temps réel ce qui peut rendre la programmation complexe, voire meme occasionner des ralentissements si trop de nouveaux tiles doivent être chargé. La solution simple est de n'utiliser qu'un set de tile (tout en VRAM) pour un même niveau mais du coup ça devient assez pauvre graphiquement... une solution intelligente est de limiter le nombre de tiles à recharger selon le scrolling, pour que l'animation reste fluide. Enfin là on arrive dans des considérations plus techniques.

A ton niveau, si tu veux faire du graphismes pour la MD, n'oublie pas de prendre en compte qu'elle a 2 plans qui se superposent (et donc 2 images, avec des priorités HIGH / LOW par tile). J'ai souvent vu des gens dessiner tout leur level sur une seule image (le fond et l'avant plan) ce qui est tout à fait inexploitable, il faut bien penser à séparer les 2 images

[Invité]

Pour débuter je te conseille d'utiliser 2 palettes pour les fonds donc 1 pour chaque plan, et les 2 restantes pour les sprites .
Ca t'évitera des prises de tête .

[Stef]

Pour débuter je te conseille d'utiliser 2 palettes pour les fonds donc 1 pour chaque plan, et les 2 restantes pour les sprites .
Ca t'évitera des prises de tête .

Oui effectivement, c'est un bon conseil pour démarrer simplement   

[Invité]

Je travaille toujours sur ma librairie qui permet de développer sur Megadrive mais à côté de ça je n'ai pas de vrai projet de jeu

C'est à dire ? Qu'appelles-tu une librairie ? Tu veux dire que t'es en train de développer un logiciel graphique pour la Mega Drive ou bien pour programmer sur Mega Drive ?

(en fait je viens de terminer un mini jeu mais on va dire que c'était une "commande spéciale" ^^).

On peut savoir ce que t'entends par "commande spéciale" ? Tu m'intrigues, là...

J'aimerai me remettre sur ma petite démo "Starfox" version MD dés que j'aurai du temps mais du coup, côté graphique je n'ai que de la conversion à faire, pas de vraie création.

Là, pour le coup, ça ne me dit rien s'il n'y a pas d'aspect créatif. T'aurais pas un vieux projet dans tes cartons que t'aurais abandonné à cause des ambitions artistiques auxquelles tu ne pouvais pas forcément prétendre ? Parce-que si c'est le cas, dépoussière-le et mettons-nous au boulot !   

Pour les contraintes graphiques, déjà il faut connaitre les contraintes "techniques" hard de la machine. Par exemple l'affichage se fait avec des tiles de 8x8 pixels. Chaque tile pointe sur une palette de 16 couleurs dont la couleur 0 est transparente. Ces 16 couleurs sont définis parmis une master palette de 512 couleurs (3 bits par composante RGB).

Du coup, si tu dessine un sprite composée de 8 tiles, vaut-il mieux :
- dessiner l'ensemble en gardant en tête les contraintes au niveau des couleurs, puis le programmeur découpera l'ensemble en tiles par la suite
- dessiner tile par tile pour ensuite les assembler (ce qui est très chiant pour un graphiste car ça empêche d'avoir une vue d'ensemble et de respecter des règles de dessin aussi basiques que les proportions

Ensuite, une question qui va vous paraitre conne mais, si je décide de changer une couleur qui est déjà dans mon sprite ou (ma tile), est-ce que je peux simplement recoloré par-dessus ou dois-je effacer le précédent auparavant ? Je pose la question car je me dis que l'informatique c'est telleemnt con parfois que la Mega Drive va peut-être prendre en considération celui qui se trouve en dessous, même si on ne le voit pas à l'écran.

La grosse difficulté sur MD c'est que tu n'as que 4 palettes de 16 couleurs pour tout (les sprites et les 2 plans) ! Autant dire que tu as plutot intérêt à bien "préparer" ce que tu veux faire pour faire en sorte que beaucoup d'éléments aient des couleurs en commun  

Pour ce qui est de préparer mon travail et la réutilisation de couleur, ce n'est pas un problème. Mes études d'arts graphiques m'ont laissé quelques automatismes et une méthodologie de précision. Néanmoins, certains outils m'aideraient fortement mais je ne sais pas s'ils existent.
Tout d'abord, j'aimerai savoir comment accéder aux 4 palettes de 16 couleurs sur GIMP 2 car, ça je n'ai toujours pas compris. En gros, une fois que j'ai choisi mon outil de création (crayon, pinceau, bombe, etc) et que je dois ensuite choisir la couleur, je me retrouve avec ça :

Sur cette première image, je n'ai pas bien compris le principe, l'intérêt et l'utilisation des couleurs du premier et second plan (le rectangle noir avec un rectangle blanc derrière). Peut-on m'expliquer ?

Spoiler:

Sur la série d'images suivantes, on peut discerner les 5 onglets pour la sélection des couleurs. Malheureusement, je ne trouve pas un onglet avec les couleurs de la Mega Drive. Du coup, je ne sais pas si ce que je fais pourra être affiché par la console ou non. Et comme je n'ai pas envie de travailler pour rien, ça me bloque totalement et je n'avance pas. Quelqu'un pourrait-il me détailler la procédure à suivre pour parfaitement configurer GIMP 2.8 ?

Spoiler:

Dans le même ordre d'idée, existe-t-il une option qui permettrait d'afficher toutes les couleurs utilisées dans le sprite sur lequel je travaille ? Une sorte de petit tableau que je visualiserai facilement et qui permettrait également de réutiliser directement une couleur déjà choisie auparavant, sans prendre le risque de dépasser le quota autorisé ?

Après y'a les autres contraintes plus liées au développement. Par exemple ne pas utiliser trop de tile différents pour tes arrières plan car la mémoire vidéo est limitée (sur MD tu tournes au alentours de 1400 / 1500 tiles en VRAM avec le reste à côté). Si tu utilises trop de tiles différents il faut mettre à jour la VRAM en temps réel ce qui peut rendre la programmation complexe, voire même occasionner des ralentissements si trop de nouveaux tiles doivent être chargé. La solution simple est de n'utiliser qu'un set de tile (tout en VRAM) pour un même niveau mais du coup ça devient assez pauvre graphiquement... une solution intelligente est de limiter le nombre de tiles à recharger selon le scrolling, pour que l'animation reste fluide. Enfin là on arrive dans des considérations plus techniques.

Quand tu parles d'arrière-plans, j'imagine que tu fais référence à des jeux qui possèdent des scrollings différentiels. Du coup, je suppose que ce genre de problème ne se pose pas avec un Zelda-like ?

A ton niveau, si tu veux faire du graphismes pour la MD, n'oublie pas de prendre en compte qu'elle a 2 plans qui se superposent (et donc 2 images, avec des priorités HIGH / LOW par tile).

Je ne comprends pas du tout ce "concept" de 2 plans. J'ai du mal à matérialiser tes propos et à visualiser ce que ça signifie. Du coup, je risque de faire pas mal de conneries...   
Et sinon, concernant les HIGH et LOW, c'est quoi exactement ? Une version plus claire et une version plus foncée d'une couleur existante sur la palette, c'est ça ?

J'ai souvent vu des gens dessiner tout leur level sur une seule image (le fond et l'avant plan) ce qui est tout à fait inexploitable, il faut bien penser à séparer les 2 images

Ah ? Ce n'est pas possible de faire comme ça ? Je veux dire, autant je comprends que pour un shoot them up ça pose problème mais pour un Zelda-like, par exemple, il n'est pas possible de dessiner toute la région vu de haut (verdure, arbres, maisons, enclos, etc) et définir ensuite les endroits où le joueur peut aller ou non ?

Pour débuter je te conseille d'utiliser 2 palettes pour les fonds donc 1 pour chaque plan, et les 2 restantes pour les sprites.

Vraiment, je vous jure que j'essaie mais, des fois (souvent ?), je ne comprends pas ce que vous m'expliquez. Par exemple, l'histoire des deux fonds c'est très abstrait pour moi. Franchement, si vous pouviez imager vos exemples et vos conseils (1-ce qu'il ne faut pas faire + 2-ce qu'il faut faire), ce serait super !

PS : je m'excuse vraiment pour toutes mes questions qui doivent vous paraitre d'une bêtise sans nom mais je vous assure que, même avec la meilleure volonté du monde, c'est très compliqué de comprendre. En fait, je suis sûr que ce serait infiniment plus simple si j'avais quelqu'un à côté de moi qui m'expliquai en temps réel avec des exemples et me montrait les différentes manipulations.

[Starfox18]

Youp,

Pour ton problème de rectangle blanc/noir, je crois que c'est si tu veux alterner entre 2 couleurs sans te casser le crâne à le retrouver dans la liste de toutes les couleurs.

Ce changement peut être fait grâce à une touche, mais je ne sais pas laquelle...

[oofwill]

Du coup, si tu dessine un sprite composée de 8 tiles, vaut-il mieux :
- dessiner l'ensemble en gardant en tête les contraintes au niveau des couleurs, puis le programmeur découpera l'ensemble en tiles par la suite
- dessiner tile par tile pour ensuite les assembler (ce qui est très chiant pour un graphiste car ça empêche d'avoir une vue d'ensemble et de respecter des règles de dessin aussi basiques que les proportions

Je pense qu'il vaut mieux dessiner ton sprite en une seule fois, en faisant des cotés multiples de 8 et en utilisant une seule palette de 16 couleurs.

Ensuite, une question qui va vous paraitre conne mais, si je décide de changer une couleur qui est déjà dans mon sprite ou (ma tile), est-ce que je peux simplement recoloré par-dessus ou dois-je effacer le précédent auparavant ? Je pose la question car je me dis que l'informatique c'est telleemnt con parfois que la Mega Drive va peut-être prendre en considération celui qui se trouve en dessous, même si on ne le voit pas à l'écran.

Si tu veux changer une seule couleur, tu peux redessiner par dessus en utilisant une couleur de ta palette de 16.
Par contre, admettons: tu as utilisé du noir pour les cheveux, mais aussi pour les chaussures du perso: si tu veux changer la couleur des cheveux, deux solutions à mon avis. Soit tu rajoutes une couleur (en prenant garde de ne pas dépasser les 16 couleurs (ou 15+transparence), soit tu changes la couleur sur ta palette (du marron à la place du noir par ex) mais tes chaussures vont prendre aussi la couleur marron.
Par contre, si tu remplaces une couleur, l'ancienne couleur est écrasée et au moment d'inclure le sprite dans le projet c'est comme si l'ancienne couleur n'avais jamais existé

Dans le même ordre d'idée, existe-t-il une option qui permettrait d'afficher toutes les couleurs utilisées dans le sprite sur lequel je travaille ? Une sorte de petit tableau que je visualiserai facilement et qui permettrait également de réutiliser directement une couleur déjà choisie auparavant, sans prendre le risque de dépasser le quota autorisé ?

Perso j'utilise toshop, mais ça me parait très peu probable que tu ne puisses pas afficher la palette des couleurs en cours d'utilisation.

Quand tu parles d'arrière-plans, j'imagine que tu fais référence à des jeux qui possèdent des scrollings différentiels. Du coup, je suppose que ce genre de problème ne se pose pas avec un Zelda-like ?

En fait, tu pourrais utiliser les deux plans pour un zelda like. Un plan pour faire le décor, et un autre pour faire les nuages ou la cime des arbres par exemple. On verrait alors le sol, les maisons, etc en transparence à travers les nuages, qui ne défileraient pas à la même vitesse que le décor puisque plus près de nos yeux par rapport au point de vue. Ou le sprite disparaitrait en passant sous un arbre...
Les plans ne servent pas forcément à faire un scrolling différentiel, mais peuvent permettre toutes sortes de choses.
Pour ma première version d'Alex kidd, je n'utilisais néanmoins qu'une seul plan, mais graphiquement c'est très simple.
Par ailleurs, je ne sais pas encore comment intégrer les jauges de vie et toutes les infos d'un jeu classique, mais une possibilité est de le faire avec un des plans (c'est pour donner un exemple d'utilisation parce que je suis pas sur que ce soit judicieux de "gaspiller" un plan pour ça...)

Je ne comprends pas du tout ce "concept" de 2 plans. J'ai du mal à matérialiser tes propos et à visualiser ce que ça signifie. Du coup, je risque de faire pas mal de conneries...   
Et sinon, concernant les HIGH et LOW, c'est quoi exactement ? Une version plus claire et une version plus foncée d'une couleur existante sur la palette, c'est ça ?

Le high/low dont parle Stef, je pense que c'est la priorité d'affichage.
Si un élément du décor a une priorité d'affichage haute (HIGH) alors que ton sprite à une priorité d'affichage basse (LOW) alors ton sprite passerait derrière le décor.
Pour les couleurs tu confonds avec Highlight/Shadow ^^

J'ai souvent vu des gens dessiner tout leur level sur une seule image (le fond et l'avant plan) ce qui est tout à fait inexploitable, il faut bien penser à séparer les 2 images

Ah ? Ce n'est pas possible de faire comme ça ? Je veux dire, autant je comprends que pour un shoot them up ça pose problème mais pour un Zelda-like, par exemple, il n'est pas possible de dessiner toute la région vu de haut (verdure, arbres, maisons, enclos, etc) et définir ensuite les endroits où le joueur peut aller ou non ?

C'est possible bien sur, comme je le dis un peu plus haut, mais pour moi qui débute, le fait d'utiliser deux plans me permet de simplifier la programmation en fait   
Ca doit pouvoir avoir une meilleure utilité mais bon ^^

Pour débuter je te conseille d'utiliser 2 palettes pour les fonds donc 1 pour chaque plan, et les 2 restantes pour les sprites.

Vraiment, je vous jure que j'essaie mais, des fois (souvent ?), je ne comprends pas ce que vous m'expliquez. Par exemple, l'histoire des deux fonds c'est très abstrait pour moi. Franchement, si vous pouviez imager vos exemples et vos conseils (1-ce qu'il ne faut pas faire + 2-ce qu'il faut faire), ce serait super !

Un autre avantage d'utiliser deux plans pour le décor, c'est que tu vas pouvoir attribuer une palette à chaque plan. Ce qui signifie pouvoir faire un décor facilement en 32 couleurs au lieu de 16.

PS : je m'excuse vraiment pour toutes mes questions qui doivent vous paraitre d'une bêtise sans nom mais je vous assure que, même avec la meilleure volonté du monde, c'est très compliqué de comprendre. En fait, je suis sûr que ce serait infiniment plus simple si j'avais quelqu'un à côté de moi qui m'expliquai en temps réel avec des exemples et me montrait les différentes manipulations.

J'ai peut être des idées qui ne sont pas très justes, donc n'hésitez pas à me corriger, mais voilà comment je vois les choses, globalement.
Pour comprendre les plans, tu peux télécharger Genskmods, l'émulateur MD, tu as une option pour désactiver un ou les plans.
Prends un jeu et amuse toi a désactiver l'un ou l'autre, tu comprendras un peu mieux les histoires de plans je pense ^^

[Invité]

oofwill a bien résumé .

Pour les priorités je vais essayer de t'expliquer simplement .
Les 2 fonds, ce sont les décors, donc tu as 2 décors totalement indépendant c'est ce qu'on appelle les plans.
regarde là : https://youtu.be/pT8GlFiyQGo?t=52s
Quand les immeubles passent devant le reste de la ville,les immeubles représentent le plan A, et le reste de la ville le plan B .

On a 2 plans qu'on va appeler A et B et des sprites qu'on va appeler S je ne parlerai pas de la window .

Donc pour faire simple, en général par défaut on a ça

S > A > B en résumé les sprites sont au dessus du plan A et B, le plan A est au dessous des sprites et au dessus du plan B, les plan B est au dessous de tout .

Ca veut dire que les sprites on la priorité haute sur les 2 plans, que le plan A a une priorité LOW sur les sprites, et HIGH sur le plan B, et que le plan B est en priorité LOW sur les sprites et la plan A .

Bien sur ces priorités peuvent être modifiées, exemple certains sprites seront au dessus de A et B, d'autres derrières A et dessus B par exemple.

Mais ça c'est le codeur qui va se charger de ça, le graphiste doit juste savoir qu'il ne doit pas mélanger sprites, plan A ,plan B sur un même dessin .
Tu dois faire chaque partie à part, en gardant en tête le résultat final de tout en même temps à l'écran .

[Stef]

[
C'est à dire ? Qu'appelles-tu une librairie ? Tu veux dire que t'es en train de développer un logiciel graphique pour la Mega Drive ou bien pour programmer sur Mega Drive ?

C'est entre les deux on va dire :p
Je développe un outil qui permet de programmer sur Megadrive "plus facilement", tu peux voir ça comme un petit kit de développement pour la Megadrive. Attention quand je dis "plus facilement" c'est pas non plus accessible à tout le monde, il faut être développeur quand même !
Tu peux voir cette librairie (que j'ai mis à jour hier :p) ici :
https://code.google.com/p/sgdk/

Un exemple concret de ce que permet de faire cet outil :
Imagine tu as une image BMP en 16 couleurs (pour faire simple), habituellement pour afficher cette image sur megadrive tu aurais besoin de pas mal de ligne de code et d'outils pour convertir l'image au bon format.
Avec mon outil, tu dois juste déclarer cette image comme une ressource de type image et ensuite avec une ligne de code tu peux l'afficher.
Bon c'est un cas simple, mais disons que l'idée est de faciliter la vie à ceux qui veulent développer sur cette machine =)

On peut savoir ce que t'entends par "commande spéciale" ? Tu m'intrigues, là...

J'ai réalisé un petit jeu sous contrat mais vraiment rien de bien excitant

Là, pour le coup, ça ne me dit rien s'il n'y a pas d'aspect créatif. T'aurais pas un vieux projet dans tes cartons que t'aurais abandonné à cause des ambitions artistiques auxquelles tu ne pouvais pas forcément prétendre ? Parce-que si c'est le cas, dépoussière-le et mettons-nous au boulot !   

Non mais j'y tiens à mon Starfox   
Plus sérieusement j'ai d'autres projets mais qui ne se réaliseront probablement pas avant 10 ans vu mon rythme actuel   

Pour toutes tes questions plus techniques sur l'aspect graphique, Oofwill et Touko t'ont déjà donné de bons éléments de réponses, et je pense que je t'ai plutot embrouillé avec des considérations très techniques alors qu'on est loin d'en être là
Une bonne méthode pour commencer, c'est de faire tes graphismes en 16 couleurs (enfin 15 puisque la couleur 0 est transparente). Comme ça au moins tu es sur de ne pas te planter

[Invité]

Ozoran, l'avantage de connaitre les caractéristiques de la machine, va te permettre de faire directement des grafs utilisables par le codeur, sans qu'il ait à faire un travail des retouches et de réorganisation derrière  .

Ex: tu fais un sprite, sachant les contraintes, tu éviteras de faire un sprite en 9x9 pixels par exemple, car tu vas bouffer 2 cells en plus, juste pour 1 ligne en X et en Y .

[Invité]

Ok, je commence à comprendre le concept et l'utilité des plans, ainsi que le principe des priorités d'affichage. Et c'est vrai que c'est tout à fait logique. Merci oofwill, Stef et Touko.   
Du coup, d'autres questions me viennent tout de suite à l'esprit.

1ère question

Si la Mega Drive est limitée à 2 plans et que je souhaite intégrer dans mon jeu des conditions météorologiques, tout en proposant une priorité d'affichage (et transparence) lorsque mon personnage passe derrière certains éléments du décors, que dois-je faire ?

1- utiliser un plan pour le sol de la zone + utiliser un plan pour la météo + créer des sprites pour chaque élément du décor (maison, poubelle, arbre, poteau, etc) que je positionnerai sur la zone et auxquels seront attribués des priorités high/low selon l'emplacement du perso

2- utiliser un plan pour le sol de la zone + utiliser un plan pour les éléments du décor (maison, etc) avec système de priorités high/low + une technique secrète que je ne connais pas pour la météo

2ème question

Si je souhaite intégrer un système de temps dans mon jeu avec un cycle matin/midi/fin d'après-midi/nuit, comment dois-je procéder pour l'impact visuel sur les décors ?

1- je dois redessiner chaque zone/sprite/etc pour modifier les couleurs

2- il existe un moyen de modifier les teintes que j'ai utilisé dans les modèles de base sans avoir à tout redessiner

3ème question

Toujours avec cette histoire de temps qui s'écoule, est-il possible de déterminer et programmer un emploi du temps quotidien pour chaque PNJs sans que cela bouffe trop de ressources ou de mémoire sur la cartouche ? Par exemple, Robert sort de chez lui à 9h00 le matin, à 10h00 il arrive au travail, à 12h30 il prend sa pause déjeuner dans le parc à côté, à 13h30 il retourne au travail, à 19h00 il termine sa journée et va boire un verre au bar du coin, à 21h30 il rentre chez lui... ce genre de choses. Et tout ça pour quelques dizaines de PNJs.

4ème question

Cette fois, c'est un peu plus technique. J'aimerai que le jeu soit beau. Du coup, je compte bien me servir des Highlights/Shadows. Si j'ai bien compris, il s'agit d'un effet qui s'applique à une couleur déjà existante et qui la rend soit plus claire, soit plus sombre. C'est bien ça ? Si oui, c'est cool, ça permettra plus de subtilités dans le choix des couleurs. Ma question est donc la suivante : si par exemple, j'utilise dans un même sprite de 8x8 la couleur jaune, jaune+highlight, jaune+shadow, est-ce que ça comptera pour une seule couleur ou bien pour 3 ? Si vous me répondez "une seule", ce serait super car ça permettrait de proposer quelque-chose de beaucoup plus riche graphiquement.

[oofwill]

Ok, je commence à comprendre le concept et l'utilité des plans, ainsi que le principe des priorités d'affichage. Et c'est vrai que c'est tout à fait logique. Merci oofwill, Stef et Touko.   
Du coup, d'autres questions me viennent tout de suite à l'esprit.

1ère question

Si la Mega Drive est limitée à 2 plans et que je souhaite intégrer dans mon jeu des conditions météorologiques, tout en proposant une priorité d'affichage (et transparence) lorsque mon personnage passe derrière certains éléments du décors, que dois-je faire ?

1- utiliser un plan pour le sol de la zone + utiliser un plan pour la météo + créer des sprites pour chaque élément du décor (maison, poubelle, arbre, poteau, etc) que je positionnerai sur la zone et auxquels seront attribués des priorités high/low selon l'emplacement du perso

2- utiliser un plan pour le sol de la zone + utiliser un plan pour les éléments du décor (maison, etc) avec système de priorités high/low + une technique secrète que je ne connais pas pour la météo

Je commence à peine à faire des essais à ce niveau la, donc ce que je vais te dire sera peut être incomplet, mais ce sera déjà un début.
On t'a expliqué pour les plans, mais le système de priorité peut s'appliquer à un tile uniquement. C'est à dire que dans un même plan, des éléments peuvent être derrière le perso jouable, et d'autre devant. ça après, c'est au programmeur de gérer son affichage, évidemment, c'est un poil plus chiant que de gerer la priorité d'un plan complet ^^

Pour la pluie, je ne sais pas, il faudrait que j'y réfléchisse lol
S'il faut passer sur tous les autres en terme de priorité, il faudra sans doute lui consacrer un plan je pense...
Je ne connais pas de techniques secretes!


2ème question

Si je souhaite intégrer un système de temps dans mon jeu avec un cycle matin/midi/fin d'après-midi/nuit, comment dois-je procéder pour l'impact visuel sur les décors ?

1- je dois redessiner chaque zone/sprite/etc pour modifier les couleurs

2- il existe un moyen de modifier les teintes que j'ai utilisé dans les modèles de base sans avoir à tout redessiner

Un tile peut changer de couleur sans avoir à changer le tile. En fait, ton tile est défini par des couleurs. Si tu changes la couleur sur la palette, ton tile va prendre la nouvelle couleur sans que tu aies à faire quoique ce soit. Plutôt cool ^^
 La encore je n'ai pas assez expérimenté, mais ça me parait faisable sans trop de difficulté.

3ème question

Toujours avec cette histoire de temps qui s'écoule, est-il possible de déterminer et programmer un emploi du temps quotidien pour chaque PNJs sans que cela bouffe trop de ressources ou de mémoire sur la cartouche ? Par exemple, Robert sort de chez lui à 9h00 le matin, à 10h00 il arrive au travail, à 12h30 il prend sa pause déjeuner dans le parc à côté, à 13h30 il retourne au travail, à 19h00 il termine sa journée et va boire un verre au bar du coin, à 21h30 il rentre chez lui... ce genre de choses. Et tout ça pour quelques dizaines de PNJs.

Oui, ça me parait faisable. je ne suis pas très calé pour évaluer ce que ça mangerait en ressources par contre.
Quelques dizaines?   

4ème question

Cette fois, c'est un peu plus technique. J'aimerai que le jeu soit beau. Du coup, je compte bien me servir des Highlights/Shadows. Si j'ai bien compris, il s'agit d'un effet qui s'applique à une couleur déjà existante et qui la rend soit plus claire, soit plus sombre. C'est bien ça ? Si oui, c'est cool, ça permettra plus de subtilités dans le choix des couleurs. Ma question est donc la suivante : si par exemple, j'utilise dans un même sprite de 8x8 la couleur jaune, jaune+highlight, jaune+shadow, est-ce que ça comptera pour une seule couleur ou bien pour 3 ? Si vous me répondez "une seule", ce serait super car ça permettrait de proposer quelque-chose de beaucoup plus riche graphiquement.

Alors la, c'est une question que je me pose aussi. Ce serait vraiment trop facile si ça se passait comme ça, mais tripler plus ou moins le nombre de couleurs en ajoutant deux nuances, sur le papier, c'est alléchant...
Bunshin no jutsu!

[Invité]

D'autres réponses ? Stef ? Touko ?

oofwil --> concernant les highlights/shadows, s'il j'ai bien compris de quoi il s'agit (une version plus claire et plus sombre pour chaque couleur de la palette), il est possible de penser que la console ne les considère pas comme des nouvelles couleurs à proprement parler mais plutôt comme une sorte de filtre qu'il est possible d'appliquer sur chaque pixel de ton choix. Si c'est bien ça, cela permettrait effectivement de "tricher" en multipliant le nombre de teintes à l'écran. Et ça expliquerait surtout pourquoi les deniers jeux développés sur Mega Drive sont beaucoup plus colorés, même si au final ce sont juste les 3 nuances d'une même couleur. Après, je suis peut-être complètement à côté de la plaque et ce n'est pas du tout ça. Mais je trouve que mon raisonnement se tient, non ?  

EDIT : je viens de lire un truc sur deux techniques appelées respectivement "palette swap" et "dithering" qui permettraient d'augmenter le nombre de couleurs à l'écran. Ça consiste en quoi exactement ?

[Invité]

Q1
1: pour la pluie soit tu utilises des sprites, mais faut faire attention à la limite des sprites / ligne, si c'est un jeu de plateforme, tu n'auras pas de soucis, ou tu sacrifies un plan .

2: si j'ai bien compris, si tu utilises un plan juste pour le sol, la partie du haut de ce plan pourrait servir pour la pluie, sachant qu'elle ne viendra pas au dessus du sol (puisque c'est le même plan) .
Ici on pourra même utiliser la technique du swap de palette pour faire la pluie .

Q2
1: Non comme on travaille en couleurs indexées, une simple modification de palette suffit .
oofwill a bien résumé sinon .

Q3: comme oofwill.

Q4: oublies le HS, d'une c'est difficile à utiliser, surtout qd tu débutes, et de deux y'a des contraintes, c'est pas du tout le saint graal, sinon tout les jeux Md l'utiliseraient .
Et puis faut aussi que ton dev sache l'utiliser .

EDIT : je viens de lire un truc sur deux techniques appelées respectivement "palette swap" et "dithering" qui permettraient d'augmenter le nombre de couleurs à l'écran. Ça consiste en quoi exactement ?

Le palette swap c'est quand tu changes les couleurs d'une ou plusieurs palette pour faire une animation .
Tu sais les fameuses enseignes qui clignotent dans les jeux de baston ??
Ou aussi dans certains jeu quand tu simules de l'eau et que l'on voit le décors à travers avec une sorte de transparence ??

La technique est aussi nommée le cyclage de couleur (color cycling)

Le dithering, c'est juste une fonction que tout les logiciels de dessin ont pour éviter la cassure entre 2 couleurs, par exemple si tu as 2 bandes horizontales , 1 rouge et 1 bleu par défaut tu vas voir la séparation des 2 couleurs, le dithering met un peu de chaque couleurs autours de cette séparation pour l'adoucir, ça n'augmente pas du tout le nombre de couleurs, mais adoucit les démarcations .

Sur Md il est utilisé de façon trop importante, ce qui rend les fonds moches qd c'est le cas .
Car il y a évidemment plusieurs niveau de dithering .

[Invité]

Tu as un jeu homebrew qui utilise toutes ces techniques ..



Tu pourras voir les autres niveaux et essayer de comprendre comment c'est fait  

[Stef]

OZoran> Est-ce que tu pourrais nous en dire un peu plus sur le style graphique que tu as en tête ? Perso j'ai l'impression que tu vois ça comme un zelda like (vue du dessus donc) mais peut être que je suis à côté de la plaque. Selon le style, les choix techniques peuvent être complètement différents !
La manière simple serait d'utiliser un plan pour la basse priorité et un plan pour la haute priorité. Ensuite pour les éléments météo tu peux utiliser des sprites (pluie, nuage) sachant que tu ne pourras pas non plus en mettre des tonnes.

Avoir une gestion du temps qui passe n'est pas un problème, visuellement les palettes te permettront de simuler assez facilement les différents moments de la journée (nuit, aube, jour, soir, crépuscule, nuit...) sans toucher aux graphismes. Pour les PNJ, je ne vois pas de soucis non plus... ça représente bien peu de données comparé aux graphismes par exemple.

Pour les highlight/shadow y'a effectivement des contraintes dans leur utilisation. Elles sont "liées" à la priorité des tiles, si tu prends le cas simple dont j'ai parlé avant (un plan low et un plan high) alors ce n'est pas un problème, par contre si tu utilises plus finement les priorités des plans le highlight / shadow va s'appliquer selon les priorités des tiles et tu risques d'avoir des effets indésirables. De manière générale ça reste assez contraignant à utiliser (mais possible si tu le penses en amont).

[onaryc]

Hello,

J'ai un peu regardé le sdk publié dans les pages précédentes (par stef je crois) et je n'y vois pas de référence au 32x, ni au mega CD. J'ai mal regardé, c'est prévu?

En tout cas, chapeau pour le taf, je vais essayé de faire quelques petits tests :)