Re: Megadrive et Super Nintendo : parlons technique !

[Tryphon]

Sur Game Gear je crois que c'est ---- bbbb gggg rrrr

Concernant l'alpha, certes c'est intéressant, mais je suppose que ça nécessite une architecture beaucoup plus complexe pour être implémenté non ?

[TotOOntHeMooN]

Sur Game Gear je crois que c'est ---- bbbb gggg rrrr

Oui, et certainement aussi sur le design de base de la MD.

Concernant l'alpha, certes c'est intéressant, mais je suppose que ça nécessite une architecture beaucoup plus complexe pour être implémenté non ?

C'est plus complexe, mais partir du moment où tu gères ta CRAM en externe, ça fait partie des choses envisageables.
Il me semble que sur M72 (Irem) les 4bit d'alpha agissent directement au niveau de la sortie analogique pour permettre des effets de rasters ou de fade in/out, mais effectivement pas au niveau de chaque pixel. Ce que la GBA fait.

[Stef]

A mon avis il manquerait des truc dans le VDP pour pouvoir le faire. Je pense pas que ce qu'il reste du mode 128k réponde vraiment a ca. Peut etre meme que Sega n'a jamais envisagé d'avoir un vrai DMA 16bit et qu'il trouvait cette situation suffisante (mais c'est un peu triste quand justement t'as une vrai console 16bit)

Le Teradrive (Un PC couplé à une Megadrive) a 128Ko de VRAM avec 16 Ko associé au Z80 (ce qui correspond au design initial, là encore sur le memory map du Z80 ça se voit) et ça fonctionne parfaitement avec (je crois qu'il y a un ou 2 jeux sur lesquels les 16 Ko de RAM du Z80 pose problème), et Tiido a déjà essayé de mettre 128K de VRAM sur une MD standard avec succés. La question que je me pose, c'est à quoi ressemblait le design d'origine (64K / VRAM 16 bit) en terme de chip du coup

[Stef]

J’ai suggéré le RGB444 à Analogue.

Un projet en cours ?
le RGB444 c'est un peut la première chose à laquelle on pense quand on souhaite refaire une MD, non ?

Sachant que la CRAM interne code le pixel ainsi : ---- -bbb -ggg -rrr 
On peut limite se douter qu'à la base ils avaient : ---- bbbb gggg rrrr

Sur MD l'encodade CRAM c'est ça : ---- bbb- ggg- rrr-
Donc bon on voit clairement que c'était prévu RGB444 au début... Mais en faisant sauter le bit de poids faible, tu préserves les couleurs pour les jeux développés avec les "vieilles specs" donc ça avait plus de sens de faire sauter ce bit là.
D'ailleurs c'est assez cocasse, il y a un jeu Mega-CD (The Secret of Monkey Island) qui encode toutes ses palettes de la manière suivante :
---- -bbb -ggg -rrr 
Du coup en réalité le jeu passe en ---- -bb- -gg- -rr-
On est réduit à 64 couleurs de master palette et bien sur le jeu est hyper sombre C'est juste incroyable que le jeu ai pu être vendu dans l'état  
Je me souviens quand j'ai vu le jeu se lancer la première fois dans mon émulateur j'étais convaincu qu'il y avait un bug obscure quelque part qui aboutissait a un shift des valeurs envoyées en CRAM, j'ai cherché pendant longtemps jusqu'à me rendre compte que non, c'est vraiment le jeu qui est buggé    enfin bon du coup c'est facile de restaurer les couleurs d'origine si on le souhaite ^^

[TotOOntHeMooN]

Au temps pour moi, c'est juste une coquille au niveau de ma notation, mais je pensais bien à cela.
Pour The Secret of Monkey Island, ça a dû leurs rappeler le bon temps de l'EGA... C'est bon les gars, on boucle ! 

Je ne vois malheureusement pas comment avoir 64K de VRAM 16-bit avec ce type de mémoire. (sinon on aurait eu cela)
Un indice est du coup sur le Teradrive. (je l'apprend, merci)

Hormis si NEC a sorti des puces de 16K x4bit... Et dans ce cas tu en colles 8 (4 par paires en 8bit sur chaque port) et tu arrives à tes 64K en 16bit. Mais j'imagine que ça prendrait trop de surface et couterait plus cher, juste pour laisser une ligne d'adresse du package non connectée. 

Il me semble bien que c'est sur les dernières GameGear qu'ils ont mis des puces de 32K de RAM pour en utiliser que 8K...

[Invité]

Il me semble bien que c'est sur les dernières GameGear qu'ils ont mis des puces de 32K de RAM pour en utiliser que 8K...

Sérieux ?? 

[TotOOntHeMooN]

Il me semble bien que c'est sur les dernières GameGear qu'ils ont mis des puces de 32K de RAM pour en utiliser que 8K...

Sérieux ?? 

C'est le même pinout (voir package), juste que tu ne vas pas connecter la ligne d'adresse de poids fort qui sera mise à VCC ou GND.
Donc oui, à partir du moment où c'est plus facilement dispo et moins cher, pourquoi pas. 

[Orion_]

D'ailleurs c'est assez cocasse, il y a un jeu Mega-CD (The Secret of Monkey Island) qui encode toutes ses palettes de la manière suivante :
---- -bbb -ggg -rrr 
Du coup en réalité le jeu passe en ---- -bb- -gg- -rr-

Non mais c'est une blague ? J'hallucine qu'un bug pareil soit passé en production !
en plus monkey island quoi ! La programmation Mega CD est quand même assez complexe, je comprend pas que le programmeur n'ai pas vu ce bug
faudrait un patch pour rajouter un petit add.w d0,d0, parceque c'est pas possible la !

[TotOOntHeMooN]

Non mais c'est une blague ? J'hallucine qu'un bug pareil soit passé en production !

Je disais ça en rigolant tout à l'heure, mais s'ils sont parti des graph EGA de la version PC, ça ne change rien.

[upsilandre]

J’ai suggéré le RGB444 à Analogue.

Un projet en cours ?
le RGB444 c'est un peut la première chose à laquelle on pense quand on souhaite refaire une MD, non ?

Sachant que la CRAM interne code le pixel ainsi : ---- -bbb -ggg -rrr 
On peut limite se douter qu'à la base ils avaient : ---- bbbb gggg rrrr

Sur MD l'encodade CRAM c'est ça : ---- bbb- ggg- rrr-
Donc bon on voit clairement que c'était prévu RGB444 au début... Mais en faisant sauter le bit de poids faible, tu préserves les couleurs pour les jeux développés avec les "vieilles specs" donc ça avait plus de sens de faire sauter ce bit là.
D'ailleurs c'est assez cocasse, il y a un jeu Mega-CD (The Secret of Monkey Island) qui encode toutes ses palettes de la manière suivante :
---- -bbb -ggg -rrr 
Du coup en réalité le jeu passe en ---- -bb- -gg- -rr-
On est réduit à 64 couleurs de master palette et bien sur le jeu est hyper sombre C'est juste incroyable que le jeu ai pu être vendu dans l'état  
Je me souviens quand j'ai vu le jeu se lancer la première fois dans mon émulateur j'étais convaincu qu'il y avait un bug obscure quelque part qui aboutissait a un shift des valeurs envoyées en CRAM, j'ai cherché pendant longtemps jusqu'à me rendre compte que non, c'est vraiment le jeu qui est buggé    enfin bon du coup c'est facile de restaurer les couleurs d'origine si on le souhaite ^^

J'adore toujours cette anecdote.
Du coup je me suis dit c'est vraiment honteux d'avoir un jeu MegaCD qui se retrouve au final avec une palette Master system (2:2:2) et ca a attisé ma curiosité donc je suis aller voir des screenshots mais en fait non. On voit bien effectivement qu'il manque le bit de poid fort mais le jeu semble utiliser assez massivement le highlight/shadow (ce qui serait logique pour un jeu de ce type) et du coup on se retrouve quand meme avec des composantes RGB sur 3bit (donc pas la palette Master System) mais au lieu des 4 visés.
Mais c'est vrai qu'on comprend pas comment l'erreur a pu etre possible, surtout si ils se sont cassé la tete a en plus prendre en compte le highlight/shadow pour étendre au mieux la palette. Comment personne n'a pu repérer ca?

[Stef]

Ah oui effectivement ils utilisent le highlight / shadow mais de mémoire il me semble que c'est pour de petites parties interactives (curseur / item sélectionné, ou des choses dans le genre) du coup une très grande partie des graphismes restent en RGB222... Ou alors les background en bénéficie aussi (ce qui est facile pour des écrans fixes) mais j'en ai pas l'impression. Enfin si vous allez voir des vidéos du jeu vous allez tout de suite vous rendre compte qu'il y a un gros problème
Enfin c'est quand même dingue que le jeu soit sorti ainsi car déjà c'est une licence assez connue, mais en plus d'être mal coloré du coup le jeu est super sombre à cause de ça (forcément on est à la moitié de la luminosité max).

[Hpman]

Vous êtes sur pour ces palettes MI ?

A vue de nez les palettes ont l'air ok, c'est le layer B qui passe tout en shadow  



Bon j'ai pas été bien loin gens passe pas cet écran


Edit:

Ouaip c'est un mic mac improbable avec les plans et le shadow pour composer l'écran. A vue de nez y'a pas de sprites à part le curseur.

[Stef]

Ah mais tu as raison, les palettes ont l'air correctes, c'est juste qu'il y a un shadow sur tout le plan (je viens de regarder dans un émulateur)... Ah c'est trop bizarre je jugerai que j'avais fait pas mal de debug et avoir vu ce problème de palette, à moins que je confonde avec un autre jeu
Mais bon ça n'empêche que le jeu final est sorti quand même 2x trop sombre, mais là du coup on se demande s'ils n'ont pas développé leur jeu sur un espèce d'émulateur qui n'implémentait pas correctement le shadow/highlight.

[Invité]

A vue de nez les palettes ont l'air ok, c'est le layer B qui passe tout en shadow  

Ca sent le S/H activé sans le faire exprès en paramétrant le VDP .

[upsilandre]

Ah mais tu as raison, les palettes ont l'air correctes, c'est juste qu'il y a un shadow sur tout le plan (je viens de regarder dans un émulateur)... Ah c'est trop bizarre je jugerai que j'avais fait pas mal de debug et avoir vu ce problème de palette, à moins que je confonde avec un autre jeu
Mais bon ça n'empêche que le jeu final est sorti quand même 2x trop sombre, mais là du coup on se demande s'ils n'ont pas développé leur jeu sur un espèce d'émulateur qui n'implémentait pas correctement le shadow/highlight.

ah oui t'as raison si ils utilisent uniquement la palette shadow ca explique ce que je voyais sur le color histogram des screenshots puisque le shadow revient a un décalage de bit. Ca parait plus logique comme erreur potentiel.

[Stef]

Oui en effet c'est le shadow appliqué par erreur... mais quand même c'est juste dingue d'avoir laissé un bug pareil

(j'essaierai quand même de retrouver le jeu dont je parle, je suis presque certain d'avoir vu un jeu qui encodait mal ses palettes)

[Invité]

Peut être qu'ils ne savaient pas d'où venait le souci, je suis sur qu'ils s'en sont rendu compte qu'il y avait un souci de luminosité, c'est pas possible de passer à côté .

[TotOOntHeMooN]

Ils on changé la luminosité de la TV, et voilà ! 

[upsilandre]

Sur Space Harrier GameGear y avait une erreur de conversion de la palette Master System. Suffirait d'une petite correction pour avoir une luminosité +25% sans consommer plus de pile.

[Invité]

Ils on changé la luminosité de la TV, et voilà ! 

[upsilandre]

https://vgdensetsu.tumblr.com/post/179656817318/designing-2d-graphics-in-the-japanese-industry?fbclid=IwAR1a1zxaexcLepmYhkZ9mYoSMkbB-YgTn4tHPD8CuEGYs6ldf5FTOzaS2w4

[sengoku 2]

J'ai encore mieux mon cher Upsilandre, j'ai lu cet article cet après-midi mais en français, c'est mieux pour notre confort.  

https://vgdensetsu.tumblr.com/post/179039509353/la-cr%C3%A9ation-de-graphismes-en-2d-dans

[upsilandre]

oui c'est mieux :)

[Invité]

Ca parait dingue que les graphistes aient fait leur taf au joystick voire direct sur la borne !

[Tryphon]

Au joystick c'est assez naturel. D'ailleurs, j'avais écrit un petit éditeur de sprites sur MO6 à l'époque qui se pilotait au clavier et au joystick (je trouve le clavier vachement plus précis que la souris) (et le crayon optique Thomson était un modèle d'imprécision). C'est rigolo de voir que les pro faisaient pareil

Par contre, sur la borne direct...

[TotOOntHeMooN]

Ca confirme une chose évidente : Les studios avaient à l'époque des outils de créations plus spécialisés qu'on a aujourd'hui pour des homebrews... Donc, à la question "comment ils faisaient" ... Je dirais, mieux et ils n'avaient pas à se plaindre. 

Sinon, grapher au clavier (ou joystick spécialisé) en mode zoom est une pratique encore utilisée de nos jours par des inconditionnels des années 80/90, et souvent le résultat du pixel art est au dessus de ce que fera quelqu'un avec sa palette graphique et photoshop. A chaque travail son outil... Même si la souris reste un très bon compromis.

[Tryphon]

Ça donne presque envie de dev un éditeur de sprites sur MD

[upsilandre]

C'est certain que le crayon optique c'est la pire idée pour un graphiste, c'est physiquement bien trop fatiguant si c'est ton travaille. Y a aucun doute que meme le joystick est préférable.

[Hpman]

Le concept du crayon optique à pourtant fait son come back avec succès

[TotOOntHeMooN]

Ça donne presque envie de dev un éditeur de sprites sur MD

Carrément, oui ! 

[upsilandre]

Le concept du crayon optique à pourtant fait son come back avec succès  

Sauf que tu travaille plus sur un CRT