Re: Mr ToutLeMonde et la programmation NES...

[vincent2105]

Oui, c'était pour voir si tu suivais :p

Pour le bankswitching, je pense avoir compris, j'y reviendrai en temps voulu, j'ai un peu la flemme de faire des tests "pour rien", faut quand même bien reflechir et concevoir les tiles pour avoir un effet sympa.

Je pense que je vais revenir à mon apprentissage du scrolling. Je voulais un scrolling à la Super Mario Bros 2... J'en étais pas loin je pense. Par moment j'écrivais une colonne alors qu'il ne le fallait pas (grosso modo quand le joueur changeait de direction plusieurs fois "au même endroit"). Par contre, je vais tout reprendre depuis le début, je préfère partir sur du propre.

Niveau scrolling, t'as deja fait des trucs ? multidirectionnel peut-être ?

[upsilandre]

nan mais moi je programme pas, je regarde les autres faire la salle besogne
Par contre j'ai bien envie d'essayer le python, j'ai un petit truc a faire et j'ai pas envie de relancer le C++ que j'ai a peine effleurer.

[vincent2105]

Tu ne programmes pas ?   C'est ton appréciation alors, parce que j'avais vu sur le forum que tu avais touché à la VCS et que tu avais un projet sur NES :p
Sinon, python on me l'avait conseillé ici même, et je trouve que c'est très pratique pour travailler sur des listes. J'ai pas poussé plus loin pour l'instant, mais je pense que plus tard,je m'en resservirai pour réaliser un éditeur de niveau (avec metatiles). 
Pour revenir au MMC3, quand je vois les possibilités, je trouve qu'il est bien dommage qu'on ai pas eut droit à un "Zelda 3" sur NES

[upsilandre]

J'ai vu qu'a coté ca parlait effet de pluie et justement j'ai un gif pour ca (j'ai un gif pour tout)
J'avais bien aimé la facon dont ils avaient fait l'effet de pluie dans Ducktales



Grace a un simple color cycle, sans aucune animation de tuile (contrairement a l'exemple d'a coté) pour un résultat bien plus reussit (on a l'impression de pouvoir suivre chaque goute et qu'elle tombe pas a la meme vitesse) et moins couteux.
Le color cycle c'est tres sympa pour faire des animations tres economiques, souvent utiliser pour representer les cascades d'eau mais pas au point de faire mieux qu'une bonne animation de tuiles (comme c'est le cas exceptionnellement de cette effet de pluie)

Contra US en color cycle VS Contra JP en animation de tuile





Pour terminer petite interrogation surprise sous forme de question piege. Est ce que quelqu'un sera capable de me dire comment l'on fait sur NES pour faire cette effet comme on le voit ici (un sprite qui passe derriere des colonnes)


Sur Master System c'est simple, suffit de modifier la priorité des tiles du background mais sur NES y a pas d'attribut du coté tilemap mais du coté sprite (l'inverse de la SMS qui n'a pas d'attribut de sprite) comment faire? (j'ai la réponse mais je vous laisse chercher   )

[vincent2105]

Merci pour toutes ces infos upsilandre  
L'effet de pluie est vraiment une réussite... Tout comme le theme musical ´moon' ... Capcom, c'était du costaud !

Spoiler:

[upsilandre]

Merci pour toutes ces infos upsilandre  
L'effet de pluie est vraiment une réussite... Tout comme le theme musical ´moon' ... Capcom, c'était du costaud !

J'adore les ducktales, c'est super bien fichu pour du 128Ko, pour moi c'est le top de ce qu'on peut faire en 128K.

Spoiler:

C'est plus tordu que ca   . Les colonnes sont bien du background et le sprite du joueur a bien une priorité superieur au background donc doit s'afficher devant... mais derriere la colonne y a un mask de sprite noir qui a une priorité inferieur au background mais superieur au sprite du joueur (qui lui est pourtant superieur au background vous me suivez?) en gros c'est un paradoxe mais qui ici se résout quand meme. Les sprites noirs du mask peuvent a la fois etre derriere la colonne et en meme temps devant le joueur (qui lui est pourtant devant la colonne) pour le cacher. C'est une petite astuce non intuitive a connaitre sur l'ordre de traitement des priorités.

[vincent2105]

Je vois bien le jeu de priorités, mais les sprites noirs il n'y en a pas en dessous de chacune des colonnes, je me trompe pas ? Si je comprend bien, c'est pas plus économique, c'est un peu plus tordu, donc c'est juste pour le faire le plus académiquement possible non?

[upsilandre]

Ca économise au moins le fait de pas avoir a doubler le tileset de la colonne (coté sprite et background), c'est du sprite 8x8 ici.
C'est d'autant plus vrai si y a une variété d'objet de ce type derrière lesquels tu veux cacher le sprite.

[vincent2105]

Ah oui t'as parfaitement raison. Une seule tile de 8x8 suffit pour tous les objets du même type. Mais depuis que je pense ´bankswitching' et 128 ko de chr rom, je cherche plus trop à économiser, mais plutôt à remplir, du coup j'ai un peu la tête dans le guidon 
C'est une très bonne solution au problème. Je note  et si tu as d'autres astuces ou curiosités de la sorte, n'hésite pas...

[Stef]

Oui c'est assez marrant cette faculté de pouvoir masquer un sprite de priorité haute avec un autre sprite de priorité basse. Sur MD cette astuce est utilisé sur l'écran d'intro de Sonic 2 et au début les émulateurs MD (dont le mien) n'émulaient pas ce cas tordu qui intuitivement te parait illogique :p

[Invité]

Avec le trick de priorité des sprites tu peux faire ce genre d'effet:



La pluie de duck tales est bien faite, réaliste, l'autre moins, avec toujours ce même effet de carré ..

[vincent2105]

Dans ton exemple, si j'ai bien compris, le sprite du perso a une priorité "back" et l'ombre une priorité "front" et le perso a été déclaré avant l'ombre dans l'OAM. C'est ca ?

La pluie de duck tales est bien faite, réaliste, l'autre moins, avec toujours ce même effet de carré ..

et comme l'a précisé upsilandre, moins couteuse.

[upsilandre]

Dans ton exemple, si j'ai bien compris, le sprite du perso a une priorité "back" et l'ombre une priorité "front" et le perso a été déclaré avant l'ombre dans l'OAM. C'est ca ?

Certainement.
Ca exploite le fait aussi de pas avoir de background autre que les colonnes.
Ne pas mettre de background (au moins sur la zone de transition) c'est une autre methode qui pour le coup permet d'eviter d'utiliser des sprites supplementaires, on se sert alors de la zone de transition sans background pour modifier la priorité des sprites



Mais ces galères sur NES et PCE (qui est quand meme une descendante direct) c'est surtout du au fait que ces 2 consoles ont tout miser sur les attributs de sprites mais au détriment des attribut de la tilemap ( on peut dire qu'il y en a pas ) tout l'inverse de la Master System par exemple. Du coup pour ces histoires d'interactions avec l'environnement ca complique les choses.
Je me souviens que dans Ys Master System tu peux passer derriere les arbres, sur NES ils ont laisser tomber l'idée et l'arbre est alors entièrement un obstacle.

[vincent2105]

Ne pas mettre de background (au moins sur la zone de transition) c'est une autre methode qui pour le coup permet d'eviter d'utiliser des sprites supplementaires, on se sert alors de la zone de transition sans background pour modifier la priorité des sprites

Bah la zone de transition, elle se fond bien dans le decor, parce que j'y avais vu que du feu :p

[Invité]

Dans ton exemple, si j'ai bien compris, le sprite du perso a une priorité "back" et l'ombre une priorité "front" et le perso a été déclaré avant l'ombre dans l'OAM. C'est ca ?

Euh on va parler plus clairement   

l'ombre est un sprite noir ,ou peu importe la couleur tant qu'elle n'est pas transparente (couleur 0), il a le même pattern que le sprite du perso(donc le sprite est doublé,cependant il est de priorité inférieure à celui du perso donc derrière .

le sprite du perso est affiché derrière le décors, le noir au dessus du décors, quand tu passes derrière le pilier, le perso principal est caché, l'ombre reste au dessus du décors(ici les piliers) .  
C'est pour ça que le fond est noir et que seul les piliers sont visibles .

regardes seul les sprites persos/ennemis ont l'ombre sur les piliers, pas les trucs qui explosent .

[upsilandre]

Dans ton exemple, si j'ai bien compris, le sprite du perso a une priorité "back" et l'ombre une priorité "front" et le perso a été déclaré avant l'ombre dans l'OAM. C'est ca ?

Euh on va parler plus clairement   

l'ombre est un sprite noir ,ou peu importe la couleur tant qu'elle n'est pas transparente (couleur 0), il a le même pattern que le sprite du perso(donc le sprite est doublé,cependant il est de priorité inférieure à celui du perso donc derrière .

le sprite du perso est affiché derrière le décors, le noir au dessus du décors, quand tu passes derrière le pilier, le perso principal est caché, l'ombre reste au dessus du décors(ici les piliers) .  
C'est pour ça que le fond est noir et que seul les piliers sont visibles .

regardes seul les sprites persos/ennemis ont l'ombre sur les piliers, pas les trucs qui explosent .

Je crois que c'est exactement ce qu'il a dit  (c'est en tout cas ce que j'ai compris de son propos)

[Invité]

Oui mais bon j'utilise pas les mots back/front pour parler de priorité ou de OAM 

Mais c'est vrai qu'au final il a dit la même chose 

 Du coup pour ces histoires d'interactions avec l'environnement ca complique les choses.

C'est clair, c'est aussi du au fait que le VDC de la PCE était sensé gérer 128 ko de VRAM, du coup les adresses des tiles sont sur 12 bits alors que 11 auraient suffit pour 64ko (comme sur MD) du coup ça aurait libéré 1 bit pour la priorité .

[upsilandre]

Je l'ai trouvé tellement dégueulasse le gif de JackieChan que j'ai pas pu resister a le refaire     sans l'immonde dithering et l'affreux scaling et en le passant a 60fps en pixel perfect et pour une taille de fichier presque 4 fois plus petite

[vincent2105]

Oui mais bon j'utilise pas les mots back/front pour parler de priorité ou de OAM 

Arf! Désolé pour le dérangement, je croyais que c'était des termes couramment utilisés. 

[Invité]

Nan pas de soucis 

Je l'ai trouvé tellement dégueulasse le gif de JackieChan que j'ai pas pu resister a le refaire      sans l'immonde dithering et l'affreux scaling et en le passant a 60fps en pixel perfect et pour une taille de fichier presque 4 fois plus petite  

Je l'avais trouvé sur un site .

[Stef]

Je l'ai trouvé tellement dégueulasse le gif de JackieChan que j'ai pas pu resister a le refaire     sans l'immonde dithering et l'affreux scaling et en le passant a 60fps en pixel perfect et pour une taille de fichier presque 4 fois plus petite

Haha on voit que tu as l'experience du GIF :p

[upsilandre]

Oui et j'ai encore simplifier le processus .

Je viens seulement de decouvrir Cosmic Epsilon



Tres impressionnant. Y a des passages (que j'ai pas gifé, pas eu le temps de jouer au jeu) ou ils jouent tres bien avec les couleurs et le dithering pour faire de l'ombrage et donner l'illusion de 3D et aussi d'autres idée sympa. Et en plus c'est un jeu qui utilise les lunette 3D de la Famicom.
Je sais pas exactement quelle est la technique mais beaucoup de bankswitching pendant l'affichage du sol (plusieurs fois par frame donc on est au dela du background switching a 60hz de Crisis Force) et une grosse CHR-ROM de 256Ko dont plus de la moitié dédié aux pattern du sol. C'est tres précalculé mais ca rend super.

[upsilandre]

Ca a de la gueule  

[vincent2105]

Whaou !! Ca, c'est pas commun en effet !
J'ai telechargé la rom de suite, mais j'arrive même pas a finir le premier niveau. :p 
Merci pour le partage

[vincent2105]

En voyant tout le monde sur des projets de jeu, ca me donne envie de me lancer moi aussi dans un exercice un tant soit peu ludique...
 
Je sais scroller dans une direction,  bankswitcher,  repomper/réorganiser des CHR-ROM, j'arrive à faire des p'tits trucs...  C'est le moment de tout mettre en pratique.

Je me suis mis dans la tête qu'un SHMUP serait désormais le fil rouge de mon apprentissage... J'ai cherché un peu et j'ai repéré 3 jeux dont les éléments graphiques sont en CHR-ROM  (donc facilement réexploitables).

On verra à quel point j'ai la tête dure

[vincent2105]

Salut,
J'ai déclaré une variable (8 bits) me permettant de stocker l'état de chacun des boutons d'un pad. Vu que le joueur peut appuyer sur plusieurs boutons simultanément, comment savoir si un bit en particulier est à 1 ou non ?
J'ai googlé un peu et j'ai trouvé ces infos (adapté pour les 2 derniers bits apparemment) mais je n'ai pas bien compris comment mettre ça en pratique. http://wilsonminesco.com/6502primer/PgmTips.html

To quickly test bit 6 or 7 of a byte in memory, you can use the BIT instruction to test them without affecting A, X, or Y.  Regardless of what's in A, BIT FOOBAR will put bit 7 of FOOBAR's contents into the N flag, and bit 6 into the V flag, so you can branch on these bits without loading first.  A good example is flag variables, where you use a byte as just a "yes" or "no" record.  "Branch if the 'ACKnowlege' record is a yes," without affecting A, X, or Y, is as simple as :
BIT ACK_FLAG
BMI _____

merci

[Invité]

Bah avec un and ..

lda entree_pad
and #BOUTON_A

Ou mieux avec BIT (qui ne détruit pas le contenu du reg A)
lda entree_pad
bit _tab_pad    (adresse d'un tableau contenant les valeurs des boutons du pad à tester)

Bit fait un AND entre le REG A et une adresse, mais conserve A .
il permet de connaitre l'état de bit 7 et 6 en modifiant les flags S et V, et le bit 0->5 avec le flag Z

[vincent2105]

Non mais ca me reussit pas de programmer au boulot
Pour le AND, c'est ce à quoi j'avais pensé, mais ca ne pouvait pas marcher avec ce que je faisais par ailleurs...
En fait, ma routine de gestion des inputs s'allonge à vitesse grand V depuis que j'ajoute des combinaisons (plusieurs boutons enfoncés simultanément) Je traitais chaque input possible un par un.  J'avais donc déjà un total de 16 cas comme celui ci dessous en ne traitant que les boutons gauche/droite/bas/haut/B ainsi que les diagonales

Code:

  LDA boutons_j1
  CMP #%00000110      ; diagonale bas/gauche
  BNE .pas_bas_gauche
  LDA joueur_1_X
  SEC
  SBC #$02
  STA joueur_1_X
  LDA joueur_1_Y
  CLC
  ADC #$02
  STA joueur_1_Y
.pas_bas_gauche:

A présent, je veux rajouter le bouton A, donc pas mal de combinaisons possibles à traiter...  Je pourrais continuer  avec des :

Code:

  LDA boutons_j1
  CMP #%xxxxxxxx

... mais je vais essayer de traiter tout ça avec l'instruction BIT comme tu me le suggères aussi.

Bit fait un AND entre le REG A et une adresse, mais conserve A .
il permet de connaitre l'état de bit 7 et 6 en modifiant les flags S et V, et le bit 0->5 avec le flag Z

merci pour l'info, je vais étudier ça

[vincent2105]

Merci pour ta patience TOUKO, j'ai résolu mon petit problème, c'est bien la honte au passage 
J'ai procédé avec l'instruction AND en ne traitant qu'un seul bit à la fois. J'avais encore une fois vraiment la tête dans le guidon avec mes tutos. :/ 
Comme tu le dis c'est pas l'idéal puisqu'il faudrait que j'utilise l'instruction BIT. Je verrai ca plus tard

[vincent2105]

Salut,

Ma routine fonctionne comme prévue :  je peux aller dans toutes les directions, tirer et accélérer.
J'ai fait une boucle pour pouvoir traiter les 2 pads.
Si je les tests l'un après l'autre, les 2 pads répondent correctement.
Simultanément, je ne rencontre pas de problème pour aller dans toutes les directions.

Le problème se pose lorsqu'on appuye simultanément sur une direction et les boutons d'action (B ou A) sur les 2 pads... Au mieux c'est le "pad 2" qui ne repond pas sur la direction "bas", dans le pire des cas, c'est la direction "bas" sur le "pad 2" ainsi que les boutons d'action des 2 pads qui ne repondent pas...
Je relis mes routines, mais je ne vois pas d'erreur jusque là...

Vous avez une idée ?

[vincent2105]

Vous voulez rigoler ? 
Mon bug... il n'a lieu que sur émulateur, pas sur ma NES !!!