Hardcore Retrogaming

Passer de 7 a 4 couleurs ca passe tres bien, on garde l'identité du personnage (notement la tenu rouge indissociable du personnage)
Mais passer de 4 a 3 c'est un carnage.

Faut bien comprendre que ce genre de personnage est composé de plusieurs sprites 8x8
au moins 6 en général




Donc on peut toujours s'amuser a combiner plusieurs palettes de sprites. Alors c'est un peu embetant car t'as seulement 4 palettes de 3 couleurs au total pour tous les sprite a l'ecran donc si t'en utilise 2 pour le personnage c'est des contraintes suplementaires et puis ca demande a utiliser + de sprites

j'ai quand meme fais des tests en combinant 2 palettes differentes (une pour la tete et une pour le corp que j'ai donc dissocié) et ca donne quelque chose d'asser interressant.


l'original a gauche, ma version NES a droite




En gros ca me coute chaque fois 2 sprites supplémentaires (en plus d'une seconde palette mais c'est 2 palettes asser differentes donc peut se recycler pour des objets noir/rouge ou noir/bleu ou noir/blanc ou noir/beige)
Mais par contre comme je dissocie la tete du corps ca me permet de recycler les meme tiles de tete pour les 3 derniers sprites par exemple (en plus du gros poing qui lui doit aussi etre dissocié et recyclé sur MS) et du coup en nombre de tiles total different dans la table de pattern ca me donne le meme resultat sur ce petit echantillon.

Bon par contre je suis un peu obligé de lui mettre des genres de gants rouges qui disparaissent quand il fait le gros poing mais je pense que ca choque pas trop, l'essentiel est que le code couleur global soit la.
Ca me plait pas mal finallement.

Certain emulateurs permettent d'afficher ce qu'il y a dans les differentes memoires graphiques de la NES. On peut voir ce qu'il se passe en temps réel pendant qu'on joue, si vous voulez voir l'envers du décors ca peut toujours etre interressant d'utiliser ce genre d'emulateur.
Par exemple l'emulateur FCEUX vous affiche cela

Avec la palette NES ca donne plutot ca (meme si y a aucun consensus sur l'interprétation RGB de la palette NES donc ca dépend de l'emulateur)






par contre je me rend compte qu'avec cette solution ca me donne jusqu'a 6 sprites sur la meme scanline soit 75% de la capacité d'affichage de sprite. ca laisse peu de marge avant de se retrouver avec des clignotements.
C'est pour ca que c'est toujours interressant de se mettre dans la position du programmeur meme partiellement car y a que comme ca que tu te rend compte de toutes les contraintes. Quand on joue a ces jeux simplistes on se rend pas compte

Honnêtement ton sprite est pas dégueulasse, c'est même mieux que 80% des sprites des jeux NES.

oui mais pas sur que ce soit tres viable, 5-6 sprites sur la meme scanline juste pour afficher Alex alors que le max affichable c'est 8....
ca veut dire que par exemple sous l'eau si je casse un bloc j'ai deja atteint le max (5 sprites sur la meme ligne pour Alex en nage + 1 sprite pour son gros point + 2 sprites pour les debris du bloc qui explose)  et donc si y a un ennemie sur la meme ligne ca va clignoter a ce moment la (meme si ca sera pas trop visible puisque le gros poing et les debris ne reste pas). un seul ennemi c'est 2 a 3 sprites de large (le bras de la pieuvre peut faire jusqu'a 8 sprites sur la meme ligne, du coup la ca clignote aussi sur MS)
et encore je compte pas par exemple les sacs d'argent dispersé un peu partout et qui sur master system sont des sprites (2 sprites de large) mais les sacs ne bouge pas donc je pense qu'on pourait les integrer plutot dans les pattern de background pour economiser des sprites (ou alors ils sont peut etre deja disposé de facon a ne pas etre sur la meme ligne que les ennemies, c'est probable)

Y a quelques bidouilles possible mais ca serait compliqué mais bon ces derniers jours j'ai testé pas mal de jeu NES/MS et les jeux ne s'embarasse pas de cela, ca clignote un peu tout le temps. Je pense qu'avoir un Alex kidd qui a de la gueule et qui soit bien reconnaissable (meme si le reste est moche) c'est le plus important

Un truc tout simple mais qui est compliqué a faire sur NES aparement c'est d'avoir une bande "HUD" ou "Score" en haut ou en bas de l'ecran alors meme que t'es dans un jeu a scrolling car cette bande fera partie du background mais faut pas qu'elle scroll avec le reste du jeu et la NES est pas prevu pour faire cette distinction donc faut bidouiller.
Aparement certain mapper de cartouche integre des features pour aider a faire ca. de ce coté je crois que la Master system est mieux lotie et integre dans son GPU la possibilité de pour pouvoir diviser l'ecran en 2 (une partie qui scroll et une partie fixe) sans passer par des bidouilles (mais dans Alex y a pas de HUD donc c'est reglé).



Mais quand meme le scrolling cablé c'est une sacré invention. ca fait partie des rares etapes/revolutions technique du jeu video avec l'arrivée des polygones 3D (et bientot la VR). Ca a ouvert une fenetre vers des mondes a explorer, ca a quand meme tout changé.

Dailleurs si j'ai eu une Atari 2600 tres tot et que j'ai bien aimé joué avec, la passion du jeu video elle a commencé seulement avec les consoles 8bits (et l'arcade) quand le scrolling a ouvert cette porte vers un nouveau monde. Alors que je voyais dans l'atari juste un jouet tres amusant, la master system c'etait plonger dans le monde des reves et c'est principalement grace au scrolling je pense.

le scrolling cablé en hard c'est finalement pas grand chose techniquement, c'est juste une gestion un peu plus complexe de l'incrementation de l'adressage de la VRAM pendant l'affichage pour pouvoir faire boucler une portion de memoire selon certaines regles et valeurs plutot que de lire la VRAM betement de facon séquenciel de l'adresse 0 a l'adresse XX.

Mais combiné a la gestion de l'affichage par tile c'est sacrement economique et efficace. Un scrolling horizontal sur NES a une vitesse classic de 1 pixel par frame idealement ca ne necessite d'ecrire en VRAM que 4 octets par frame!
Alors forcement meme avec un CPU tres faible comme dans la NES et un temps tres court (modifier la VRAM ca se fait pendant le Vblank entre 2 frames soit a peine plus de 1 milliseconde) t'arrive a t'en sortir pour faire ton scrolling, charger la table de sprite et 2 ou 3 autres truc.

Bah après c'est à toi de voir si tu veux être le plus fidèle à l'esthétisme de la version MS au risque d'avoir des clignotements, ou une adaptation qui sera plus NES friendly (sac d'argent de 1 tile de large) et propre.

Mais sinon comme tu le dis, un jeu NES ... ça clignote. (c'est d'ailleurs pour ça que j'avais pris une MS, plus de couleurs et moins de clignotements)

en theorie la MS n'est pas meilleur sur ce point, ca clignote autant dans les meme condition sauf si sur NES tu te met a bidouiller comme j'ai fais pour compenser les lacunes en couleurs affichable chose que n'a pas besoin la master system et ca fait la difference.

OK, si tu le dis, mais dans mon souvenir, les jeux NES clignotaient quand même vachement plus mais bon faudrait que je rematte des jeux pour me refaire une idée réelle

Sinon pour ton problème de sprites, je pense comme toi que garder un Alex aussi fidele que possible est une bonne chose car le personnage est vraiment la référence graphique du jeu, pour le reste, je suppose que tu peux tricher en diminuant le nombre de sprites par objets histoire de soulager un peu la NES sans que cela dénature trop le jeu.
Surtout que tu va te retaper tout le codage et pas reprendre de l'existant, donc c'est pas comme si tu devait te faire chier a nettoyer et modifier du code existant.

patataboy a écrit:

OK, si tu le dis, mais dans mon souvenir, les jeux NES clignotaient quand même vachement plus mais bon faudrait que je rematte des jeux pour me refaire une idée réelle

ouaip les consoles ont la meme capacité en nombre de sprite affichable a l'ecran, taille de sprite et nombre de sprite affichable par scanline.
j'ai verifié moi meme sur les jeux et effectivement chaque fois que t'aligne plus de 8 sprites ca glitch que ce soit sur MS ou NES

mais comme je dis doit y avoir des jeux sur NES qui superpose des sprites pour avoir plus de couleur et donc plus de jeux NES qui clignote.

le PPU est optimisé et calibré au poil de cul
le PPU a besoin de 2 cycles pour acceder a un octet en VRAM
y a 340 cycles PPU pendant une scanline (donc pendant le balayage d'une ligne ecran)
Ca veut donc dire que le PPU peut lire 170 octets en VRAM pendant le tracage d'une ligne et quand on fait le calcule entre les acces a la "name table", la table d'attribut, les tables de pattern (backround et sprite) il y a besoin de lire 168 octets par scanline pour avoir toutes les données nécessaire
Donc la VRAM est occupé a 99% pendant le tracage des lignes (ca inclut meme les blanking horizontaux, c'est a dire le moment entre 2 ligne ou y a rien a tracé et ou le PPU prepare quand meme la suite notement les sprites) pas la peine d'essayer d'y acceder.
Et heureusement que le PPU a aussi une petite memoire interne (qui n'est donc pas en VRAM) pour la table des sprites et donc y acceder et la trier pour evaluer quelle sont les 8 sprites affichables la ligne suivante et ainsi pouvoir le faire simultanement au tracage de la ligne en cours (la Master system elle gere tout dans une unique memoire donc forcement avec des acces plus rapide)


Donc pendant le tracage le PPU et la VRAM sont vraiment busy.
C'est pour ca qu'on ne peut acceder a la VRAM (pour modifier ce qui est affiché) que pendant le VBlank, ce moment entre 2 frames ou le PPU est au repos et qui en NTSC ne dure que le temps de 20 ligne sur 262

Finallement en NTSC la NES affiche bien 240 lignes, c'est du 256x240. Je pensais que ca ne concernait que l'ecran virtuel mais c'est bien aussi ce qu'elle affiche réellement sauf qu'on considere que la zone vraiment exploitable c'est 224 lignes et que le reste est dans l'overscan hors de l'ecran. Mais alors je comprend pas pourquoi ne pas avoir éteint le PPU audela de 224 lignes et ainsi laisser la VRAM accessible?
Ca aurait permis d'avoir un Vblank de 36 lignes au lieu de seulement 20, j'imagine que c'est pas du luxe pour avoir le temps d'utiliser certain tricks (sur la master system tu peux te contenter de 192 lignes affichable) d'autant qu'avoir 16 lignes non affiché c'est utile aussi dans certain cas de scrolling pour cacher certain glitch (qui le sont par l'overscan en theorie mais quand meme). Mais non y a apparemment rien dans les registres PPU qui permet de reduire l'affichage a 224 lignes, vraiment curieux. (si ton jeu est a scrolling horizontal rien ne t'empeche de mettre des tiles noirs en haut et en bas et de gerer l'affichage en 224 lignes mais ca n'empechera pas que le GPU sera occupé et non disponible pendant l'affichage de ses lignes noirs, ton VBlank restera limité a 20 lignes)

Pour l'instant ce choix de 240 lignes affiché est un mystere pour moi et le seul truc que je trouve mal fichu.
Du coup en PAL ca affiche aussi 240 lignes (mais qui ont toute les chances d'etre visibles a l'ecran cette fois) mais le Vblank dure 70 lignes donc une situation bien plus confortable. Y a pas de jeux NES sortie seulement en PAL?

purée le gouffre entre le sound chip de la Mark 3 (MS japonaise) et de notre master system    
la Mark 3 avait un super sound chip superieur a la NES et au final nous on se retrouve avec un sound chip (integré au GPU il me semble) inferieur a celui de la NES

La claque dans la tronche !

C'est d'autant plus surprenant que je connais pas mal de thèmes venant de la Master System, voir par coeur, et entendre cette différence ! vla comment on a été volé pour le coup !

Violent la différence putain!   

et les japonais avait se pure son en 1985 et nous un son tout pourri en 1987

Je me suis amusé a tester des jeux NES qui ne sont sortie qu'en PAL pour voir si certain avait exploité le fait qu'en PAL le Vblank dure 3x plus longtemps qu'en NTSC (et donc plus de temps pour modifier la VRAM)

j'ai testé Super Turrican mais rien vu de particulier

Par contre ensuite j'ai testé Asterix et la on constate qu'ils ont effectivement exploité le Vblank plus long du PAL dans le superbe sprite d'Asterix.
Deja on constate que c'est un gros "sprite" composé de 12 sprites (3x4) et tres bien animé.
Pour animer le sprite d'un personnage (par exemple animer le mouvement de marche) la solution ordinaire c'est de stocker toutes les versions differentes des tiles qui compose le sprite dans toutes les positions et donc de switcher entre ces differents sprites pour changer l'apparence du sprite du personnage et ca consiste juste a modifier la table de sprite (la liste des sprite affiché a l'ecran) ce qui n'est pas couteux. Mais comme y a seulement 256 tiles dans la table de pattern pour stocker toutes les tiles de tous les sprites c'est compliqué de faire de belle animation.

Dans Asterix ils ont utilisé une autre solution qui consiste a n'avoir qu'un seul set de tile, une seul etape d'animation stocker dans la table de pattern (donc seulement 12 tiles pour representer Asterix dans une seul position, comme si il n'etait pas animé) et de modifier directement la table de pattern entre 2 frames pour remplacer ces 12 tiles par 12 autres qui represente une autre etape d'animation.
C'est une methode que j'ai deja vu utilisé pour ajouter des petites animes dans le décor (par exemple animer les vaguelettes a la surface de l'eau) mais ca se limite en general a 2 tiles car modifier une seul tile dans la table de pattern ca veut dire modifier 16 octets de VRAM ce qui est deja pas mal.

Ici dans Asterix il faut donc modifier 12 tiles d'asterix + 2 tiles du decors (car y a de l'animation aussi dans le decor) entre 2 frame donc pendant le blanking.
14 tiles ca veut dire modifier 224 octets de VRAM pendant le blanking! J'ai calculé que ca prendrait minimum 1100 cycle CPU soit l'equivalent de 19 lignes de balayages NTSC alors que le blanking en NTSC dure 20 lignes et qu'il y a d'autre chose a faire (comme mettre a jour la table de sprite qui prend minimum 5 lignes) donc ca ne passerait pas. Heureusement en PAL y a 70 lignes de Vblank

Donc on peut dire que Asterix ne pourait pas tourner en l'etat en NTSC (mais avec un mapper asser evolué y a un autre moyen je pense qui consisterait a utiliser un bank switching pour la CHR-ROM avec une granularité tres fine de 1ko et de switcher juste 1ko de la table de pattern ou se trouve le sprite d'Asterix pour l'animer, le bank switching c'est instantané, ca prend a peine quelques cycles CPU mais par contre ca oblige a switcher minimum 64 tiles de sprite et pas juste 14. C'est surement utiliser dans quelques jeux)

Si vous avez un emulateur sous la main jeter un oeil dessus, le sprite est asser chouette pour de la NES.
Infogramme a toujours fait cette effort technique sur l'esthetique des jeux a défaut d'autre chose.

upsilandre a écrit:

Infogramme a toujours fait cette effort technique sur l'esthetique des jeux a défaut d'autre chose.

Tu m'étonnes ....

Sinon Asterix a 4 couleurs ??!!

Et pour revenir à la MS avec et sans le Mark III ils nous ont refait le coup par la suite avec les deux versions de la MD et la MD2 et un son vraiment différent (à chier pour la MD2)
SEGA .... enculés

patataboy a écrit:

Sinon Asterix a 4 couleurs ??!!

c'est pas la meme palette sur les 6 sprites du haut et le 6 sprites du bas mais au moins leur sprite est calibré pour ca donc sans gachie ou superposition en ayant bien séparé le haut du bas du corp
sur mon alex j'ai 5 couleurs mais je suis obligé de gacher de l'espace et de superposer des sprites, c'est le probleme de porter un sprite qui n'est pas calibrer pour la machine

Je me doutais bien que les palettes des sprites haut et bas étaient différentes, c'est juste dommage que tu ne puisse pas utiliser cela pour ton alex sans gâcher autant.
Mais c'est vrai qu'avec une couleur de plus c'est largement plus compréhensible et flexible1.

Je suis pas un expert des emulateurs NES mais j'ai pas l'impression qu'il y a mieux que fceux
http://www.fceux.com/web/home.html
Non seulement il marche tres bien mais surtout il est bien equipé en outils de debuguage (et de TAS). J'ai pas l'impression qu'il y ai beaucoup d'autre choix.

J'ai pas encore beaucoup creusé mais pour l'instant j'ai l'impression que la communauté homebrew NES est moins active que celle de la VCS. je pensais que la communauté NES serait de loin la plus active mais la communauté homebrew VCS de ce que j'ai pu en voir quand je m'y suis mis c'est vraiment enorme, c'est peut etre finalement la plus active et la mieux documenté (ou alors peut etre SNES?).

Dailleurs j'ai meme pas trouvé ne serait ce qu'une intention de portage d'Alex kidd sur NES en homebrew. C'est quand meme étonnant. si vous trouvez trace sur le web d'un projet equivalent faite le moi savoir. Sinon ca pourrait etre ma base de travaille pour tester la programmation NES

Tente de contacter ce gars, il aura peut-être des sources :

Sinon il y a lui

Ou lui


Sinon j'ai l'impression que certains types de ce site pourrons avoir des tuyaux
http://callanbrown.com/index.php/basic-nes-reproduction

Et celui là, je pense que tu le connais déjà
http://forums.nesdev.com/viewtopic.php?t=8137

oui de la doc y en a quand meme pas mal et y a nesdev

Moi je suis toujours a fond sur la doc NoCash
http://nocash.emubase.de/everynes.htm

Sur l'atari 2600 j'utilisais uniquement ce document qui etait toujours ouvert dans un onglet car ca regroupe toutes les informations a savoir de facon condensé (et un peu aride car c'est pas la pour t'expliquer en details les chose mais j'aime bien car y a toutes les infos en un seul document et en prenant son temps on comprend).

quand j'ai découvert qu'il en avait fait un aussi pour la NES je me suis jeté dessus d'autant que je me suis habitué a la forme du document.
Ce mec est un malade, il a deja codé 10 emulateurs/debuggeur de console differente et donc produit aussi ces documents enorme.
Faut dire le gars n'a jamais travaillé, il ne fait que ca (c'est malheureux mais y a 2 monde, ceux qui doivent bosser et qui au final ne feront jamais grand chose d'autre et ceux qui peuvent s'en passer)
Faire des emulateurs ca m'aurais bien botter, pour le coup il sagit vraiment de comprendre la machine.


Mais ce que je cherchais c'est plutot a savoir si y a deja quelqu'un qui a fait un Alex kidd NES.

upsilandre a écrit:

Mais ce que je cherchais c'est plutot a savoir si y a deja quelqu'un qui a fait un Alex kidd NES.

Pas trouvé non plus, tout au plus un truc zarby fait sur SNES, mais rien sur la NES.
Mais il y a plein d'autres jeux MS passé sur NES : Space harrier

Rein a voir mais toujours pour pleurer de la version en papier de la master system qu'on a eu voilà le startup de la MS MarkIII
putain c'est pratiquement le son d'une mégadrive