Re: Besoin d'aide pour un "redone" de Ghost'n Goblins sur Nes.

par upsilandre Jeu 27 Aoû 2015 - 18:18

Y a surement des bidouilles possibles mais ca sera vraiment du bricolage au cas par cas et y aura toujours un truc qui colle pas, puis ensuite faudra trouver un moyen de simuler les comportement, les interactions, les armes, le boss, le hud... on arrive selon moi dans une zone de perversion du rom hacking, quand faut recoder un jeu pour le transformer en un autre ca devient de la folie car ca peut etre plus ou moins aussi complexe que de le faire "from scratch" mais sans le coté gratifiant (et tres important) d'avoir fait ton truc a toi. Decrypter ce que quelqu'un d'autre a fait pour pouvoir le modifier c'est tres tres fastidieux. Et puis si t'arrive a transformer un jeu en un autre alors c'est que t'as les competences pour faire un jeu de zero.

En tout cas pour ma part et pour te repondre c'est pas quelque chose sur lequel j'aurais envie de passer du temps. Le rom hacking c'est amusant quand c'est des petits truc (y a 3 semaines j'ai fais Dragon Quest 1 en entier puis je me suis amusé a le hacké un petit peu, mettre 60 000 pieces d'or dans le premier coffre ou l'on débute, mettre une clé magique non consommable qui ouvre toutes les portes dans le second coffre, tracé un sentier par dessus la mer pour relier le premier chateau ou l'on débute et le chateau final qui se font face... Ca c'est marrant) mais quand ca nécessite de remodeler vraiment le code ca me tente plus malgres que en décryptant le code de professionnel en général t'apprend forcement des truc donc c'est intéressant mais y a quand meme plus efficace en temps pour apprendre.

Si j'avais du temps pour ca je le consacrerais plutot a démarrer un truc de zero pour le plaisir. Normalement j'avais prevu de porter le premier level de Alex kidd, j'avais deja préparer le terrain mais c'etait y a un an puis j'ai fais d'autre truc au final donc j'ai toujours pas vraiment commencé a coder sur NES j'en suis resté a l'Atari 2600 (qui a quand meme le meme CPU) mais si je dois faire un truc ca sera ca, ca me permettra de m'entrainer et qui sait, une fois que j'aurais un peu d'experience pourquoi pas faire une ebauche de GG MMC5 from scratch a 2. J'aime toujours bien l'idée car je suis fan de cette série et dans un contexte idéal ou je gagne au loto et ou je peux arreter de travailler alors c'est certainement ce que je ferais, dans le monde réel c'est deja beaucoup plus hypothétique comme scénario parce que c'est des centaines d'heures.

par Alucardark Jeu 27 Aoû 2015 - 18:35

upsilandre a écrit:Y a surement des bidouilles possibles mais ca sera vraiment du bricolage au cas par cas et y aura toujours un truc qui colle pas, puis ensuite faudra trouver un moyen de simuler les comportement, les interactions, les armes, le boss, le hud... on arrive selon moi dans une zone de perversion du rom hacking, quand faut recoder un jeu pour le transformer en un autre ca devient de la folie car ca peut etre plus ou moins aussi complexe que de le faire "from scratch" mais sans le coté gratifiant (et tres important) d'avoir fait ton truc a toi. Decrypter ce que quelqu'un d'autre a fait pour pouvoir le modifier c'est tres tres fastidieux. Et puis si t'arrive a transformer un jeu en un autre alors c'est que t'as les competences pour faire un jeu de zero.

En tout cas pour ma part et pour te repondre c'est pas quelque chose sur lequel j'aurais envie de passer du temps. Le rom hacking c'est amusant quand c'est des petits truc (y a 3 semaines j'ai fais Dragon Quest 1 en entier puis je me suis amusé a le hacké un petit peu, mettre 60 000 pieces d'or dans le premier coffre ou l'on débute, mettre une clé magique non consommable qui ouvre toutes les portes dans le second coffre, tracé un sentier par dessus la mer pour relier le premier chateau ou l'on débute et le chateau final qui se font face... Ca c'est marrant) mais quand ca nécessite de remodeler vraiment le code ca me tente plus malgres que en décryptant le code de professionnel en général t'apprend forcement des truc donc c'est intéressant mais y a quand meme plus efficace en temps pour apprendre.

Si j'avais du temps pour ca je le consacrerais plutot a démarrer un truc de zero pour le plaisir. Normalement j'avais prevu de porter le premier level de Alex kidd, j'avais deja préparer le terrain mais c'etait y a un an puis j'ai fais d'autre truc au final donc j'ai toujours pas vraiment commencé a coder sur NES j'en suis resté a l'Atari 2600 (qui a quand meme le meme CPU) mais si je dois faire un truc ca sera ca, ca me permettra de m'entrainer et qui sait, une fois que j'aurais un peu d'experience pourquoi pas faire une ebauche de GG MMC5 from scratch a 2. J'aime toujours bien l'idée car je suis fan de cette série et dans un contexte idéal ou je gagne au loto et ou je peux arreter de travailler alors c'est certainement ce que je ferais, dans le monde réel c'est deja beaucoup plus hypothétique comme scénario parce que c'est des centaines d'heures.

J'avoue que ces derniers jours je me suis bien cassé les dents à essayer de faire ne serait-ce que le sprite d'Arthur au complet (là où j'avais réussi à le faire presque entièrement sur Megaman 4). Comme tu l'as dit, on passe son temps à décrypter le code au lieu d'avancer comme ça devrait être le cas si on repartait de zéro! Du coup, je pense juste à continuer les niveaux pour voir comment ça peut s'intégrer sur NES puis les poster ici pour le jour où toi, ou n'importe qui d'autre, aura suffisamment d'expérience (mais surtout l'envie) de faire un Ghost'n Goblins à zéro. En tout cas merci d'avoir pris le temps de regarder ça.

par upsilandre Jeu 27 Aoû 2015 - 19:00

Sinon pour revenir a GG j'aimerais aussi voir une nouvelle version sur NES. Le GG NES me laisse une impression mitigé.
A la fois c'etait l'une des rare conversion réussit de l'epoque et un jeu qui arrive sur Famicom en 1986 , l'année charnière qui sonne le second départ de la Famicom apres des premières années un peu laborieuse qualitativement.
1986 arrive le Famicom Disk, l'explosion des ROMs et des mappers, et tout ca permet enfin de débloquer les créatif et le potentiel de la machine. Finit ces années a devoir composé des jeux avec 8Ko de pattern graphique non compressé comme budget total. On peut enfin profiter de la rupture du scrolling apporter par la Famicom et faire voyager le joueur.
GG arrive dans ce contexte et participe au lancement de cette nouvelle phase des jeux consoles et a donc marqué son epoque.

Mais d'un autre coté quand tu le décortique un petit peu y a l'aire d'y avoir plein de faiblesse technique, d'approximation. Je pense que le jeu a ete fait assez vite et avec les moyens et l'experience de l'epoque.
C'etait la toute première cartouche 1Mbit au tout debut du boom de la capacité des ROMs et du coup j'ai l'impression que c'etait pas prévu. Je suis convaincu que le jeu a ete concu au depart sur une base 512Kbit car dans la cartouche c'est plein de vide et surtout plein de redondance de pattern de sprite. Les sprites sont en 7,8 voir 9 exemplaire alors meme que c'est la premiere cartouche aussi a utiliser le mapper UNROM qui utilise de la CHR-RAM qui a pour interet justement de pouvoir construire sur mesure ton tileset et eviter toute redondance dans les bank graphiques (puisqu'il n'y en a pas).
Et puis on voit bien que c'est des pools complet de sprite (avec tous les ennemis) qui ne sont pas utilisé, par exemple on retrouve 5 fois le meme pool complet de sprite qui contient chaque fois le meme sprite de zombie qui n'est pas celui utilisé dans le jeu.
Ensuite y a certain pool qui sont probablement des variantes constitué pour simplifier les chargement mais c'est sans doute des choix apres coup pour remplir la place supplémentaire qu'on leur a donnée au dernier moment et pas une volonté premiere. Je pense qu'une equipe expérimenté te fait rentrer le meme jeu dans 64Ko au lieu de 128Ko (parce exemple Rare etaient tres bon sur NES).

Ensuite y a aussi quand meme un probleme d'animation. Le jeu tourne a 20fps alors que la norme c'est 60fps sur NES, 30fps c'est deja rare mais 20fps ca doit se compter sur les doigt de la main. Et en plus c'est pas du 20fps propre, c'est du 20fps avec judder (un coup 4 frames, un coup 2 frames, c'est degeu) et en plus les sprites et le scrolling sont désynchronisé ce qui donne un effet de flottement aux items (qui du coup se déplace pas en meme temps que le background)

Un truc aussi qui m’agaçe dans cette version c'est que dès la premiere seconde de jeu y a trahison avec ces zombies rouge au cheveux bleu alors qu'ils sont censé etre bleu au cheveu rouge. Alors on pourrait se dire que sur NES on choisie pas vraiment ses couleurs car t'as que 4 palettes pour les sprites (dont 2 utilisé pour Arthur, 2 pour les zombies...) et donc faut partager les palettes entre plein de sprites...
Mais au final j'ai quand meme reussit a faire un hack qui rectifie cette faute de gout (meme si c'etait quand meme un peu galère). C'etait donc tout a fait possible alors pourquoi ne pas l'avoir fait?
Besoin d'aide pour un "redone" de Ghost'n Goblins sur Nes. - Page 2 GGhack

Besoin d'aide pour un "redone" de Ghost'n Goblins sur Nes. - Page 2 GGhack

Du coup j'ai du regarder un peu comment etait géré les sprites et ca m'a paru aussi comme un sacré bordel mal optimisé comparé au sprite engine de Megaman. Et puis y a par exemple cette superposition de sprite sur les zombies que je ne comprend pas du tout. Ils ont 2 abdomens superposés l'un sur l'autre! ca fait des zombie qui font 3 sprites de large en plein milieu et c'est la fete au clignotement! C'etait a priori completement évitable. Y a en tout cas de la marge pour l'ameliorer je pense.

par upsilandre Jeu 27 Aoû 2015 - 19:02

Alucardark:

Oui faut garder les assets, ils serviront forcement un jour car ils sont chouettes. Et puis continuer comme tu a fais en les intégrant a une demo ou l'on peut se balader dedans juste avec un Arthur complet, c'est deja classe et ca peut motiver des gens, c'est une facon de mette une pierre a l'edifice, c'est deja un projet accomplie en soi.

par Alucardark Ven 28 Aoû 2015 - 15:37

upsilandre :

Oui c'est ce qui m'a fait me lancer sur un "Redone" du jeu ("Remake" n'étant pas approprié étant donné que je veux me rapprocher de l'arcade et non faire une relecture du jeu), autant d'un point de vue graphique pour l'époque ça allait (faut pas oublier qu'ils a été converti sur NES en 9/10 mois) mais il était vraiment discutable au niveau de la physique comme tu l'as dit plus haut (bordel 20 fps au mieux avec des désynchronisations, effectivement je comprends mieux pourquoi le sprite avait l'air de flotter). C'est pour ça que j'ai pris un Rockman comme base pour le GNG, 60 fps, physique très bien foutue et gameplay assez proche d'un GNG. Du coup je me suis dit qu'il y avait moyen de modifier le code pour que ça se rapproche du gameplay de l'arcade, mais au final je me rend compte qu'il faudrait plusieurs hackeurs expérimentés pour effectuer toutes les modifications.

par Alucardark Ven 28 Aoû 2015 - 15:45

upsilandre a écrit:Oui faut garder les assets, ils serviront forcement un jour car ils sont chouettes. Et puis continuer comme tu a fais en les intégrant a une demo ou l'on peut se balader dedans juste avec un Arthur complet, c'est deja classe et ca peut motiver des gens, c'est une facon de mette une pierre a l'edifice, c'est deja un projet accomplie en soi.

Oui ça pourra toujours servir, et qui sait peut-être, motiver d'autres programmeurs à y jeter un œil. Pour la balade d'Arthur, ce n'est malheureusement pas pour tout de suite car je rencontre des difficultés à intégrer toutes les animations, je ne sais pas comment ils ont foutu leur bordel dans Megaman 3, mais c'est vraiment différent d'un Megaman 4 où j'ai pu mettre la quasi totalité des animations (il me manquait que le saut sur place à intégrer).

par upsilandre Ven 28 Aoû 2015 - 18:21

Megaman 3 c'est une configuration de cartouche a base de CHR-ROM alors que Megaman 4 c'est a base de CHR-RAM donc c'est 2 approches differentes (ca a toujours ete un peu un dileme de choisir entre ces 2 possibilités offerte par la NES, y avait pas ce genre de choix sur les autres consoles), ca doit surement se ressentir quelque part car c'est assez different.

par Alucardark Sam 29 Aoû 2015 - 19:01

upsilandre a écrit:Megaman 3 c'est une configuration de cartouche a base de CHR-ROM alors que Megaman 4 c'est a base de CHR-RAM donc c'est 2 approches differentes (ca a toujours ete un peu un dileme de choisir entre ces 2 possibilités offerte par la NES, y avait pas ce genre de choix sur les autres consoles), ca doit surement se ressentir quelque part car c'est assez different.

En tout cas la possibilité du 4 de passer par la CHR-RAM facilite beaucoup les choses concernant les sprites, dommage qu'il n'y ait pas eu de MegaFLE X utilisant le MMC5 pour Megaman 4.
Je vais passer du coq à l'âne, mais saurais-tu comment on lit et modifie la ram avec Fceux (non parce que quand je vois par exemple un "$20" pour chercher une info vue sur une documentation, ben ça m'arrangerai bien de savoir comment faire une modif)?

par upsilandre Sam 29 Aoû 2015 - 19:13

tu ouvres l'Hex Editor et tu selectionnes "nes memory" ensuite suffit de modifier un octet (la RAM s'arrete a $7FF donc ne va pas plus loin c'est de la ROM et on t'autorisera pas la modification par ce menu)

par Alucardark Sam 29 Aoû 2015 - 19:29

upsilandre a écrit:tu ouvres l'Hex Editor et tu selectionnes "nes memory" ensuite suffit de modifier un octet (la RAM s'arrete a $7FF donc ne va pas plus loin c'est de la ROM et on t'autorisera pas la modification par ce menu)

Oui voilà, c'est ce signe de "$" que je n'arrive jamais à saisir (même quand je cherche). Evil or Very Mad

En tout cas merci pour ta réponse.

par upsilandre Sam 29 Aoû 2015 - 19:49

Alucardark a écrit:
upsilandre a écrit:tu ouvres l'Hex Editor et tu selectionnes "nes memory" ensuite suffit de modifier un octet (la RAM s'arrete a $7FF donc ne va pas plus loin c'est de la ROM et on t'autorisera pas la modification par ce menu)
Oui voilà, c'est ce signe de "$" que je n'arrive jamais à saisir (même quand je cherche).
En tout cas merci pour ta réponse.

"$" ca veut juste dire que le nombre qui suis est en hexadecimale et pas en base 10. $7FF ca veut dire qu'il faut pas dépasser l'adresse 2047 mais dans hex editor de toute facon les adresses sont indiqué en hexa (et les valeurs aussi) donc c'est les valeurs hexa qui nous intéresse.
L'un des interet d'une valeur en hexa c'est que ca se decoupe facilement en binaire. par exemple un octet (donc 8bit) de valeur $A9 ca se découpe en 2. "A" nous indique les 4 bits de poid fort (les 4 premiers de l'octet) et "9" les 4 bit de poid faible. Du coup meme de tete tu peux faire la conversion en binaire (par exemple si tu veux modifier une pattern) alors que si on te donne la valeur decimale equivalente (169) pour la convertir en binaire de tete c'est compliqué.

par upsilandre Dim 30 Aoû 2015 - 1:29

J'ai peut etre pas compris ce que tu demandais. Je suis partie du principe que tu connaissais deja bien l'Hex Editor car il me semblait t'avoir vu le manipuler.
Modifier $20 en RAM ca veut dire modifier l'octet a cette adresse ou j'ai mis mon curseur
Besoin d'aide pour un "redone" de Ghost'n Goblins sur Nes. - Page 2 Hex

Besoin d'aide pour un "redone" de Ghost'n Goblins sur Nes. - Page 2 Hex

L'autre facon d'ecrire $20 en Hexa c'est 0x20 , c'est ce que tu vois ecrit en haut de la fenetre qui indique l'adresse du curseur.

L'interet de l'hexadecimal dans l'adressage c'est que les chip manipule des valeurs binaire et l'adressage aussi du coup les mémoires on des capacités qui sont des comptes rond... en binaire (2048 octets, 4096 octets ect...)
Et il se trouve qu'un compte rond en binaire est aussi un compte rond en Hexadecimale. Par exemple la valeur binaire 32bit 10000000000000000000000000000000 ca donne aussi un compte rond en hexa $80000000 alors qu'en décimal ca donne un truc qui n'a rien a voir (2147483648), y a toujours une correlation plus direct entre binaire et hexadecimale que ce soit pour les valeurs ou l'adressage.

Prend l'exemple de la NES, la ROM de la cartouche dans l'adressage mémoire CPU debute a l'adresse binaire b1000000000000000 ou en hexa $8000, dans les 2 cas c'est facile a repérer c'est un chiffre rond alors qu'en décimal ca serait 32768 (et pas 32767 ou 32769).
Ou par exemple pour sauter d'une bank CHR-ROM 8ko a une autre tu sais qu'il faut simplement ajouter $2000 a l'adressage (c'est mieux que de devoir additionner 8192 )

par Woody 90 Dim 30 Aoû 2015 - 1:33

tout dépend de ton editeur héxadecimal,je sais que sur des programmes différent l'adresse est jamais la meme .

par upsilandre Dim 30 Aoû 2015 - 1:36

Woody 90 a écrit:tout dépend de ton editeur héxadecimal,je sais que sur des programmes différent l'adresse est jamais la meme .

mais la on parle du meme, celui intégré a Fceux.

par Woody 90 Dim 30 Aoû 2015 - 1:41

celui intégré pas top je trouve , m'enfin si tu as l'habitude de bidouiller avec...

par upsilandre Dim 30 Aoû 2015 - 1:56

Si tu passe par un Hex editeur externe alors tu n'as plus acces a toute les fonctions que propose celui de Fceux comme justement pouvoir modifier la RAM en temps réel ou meme freezer un octet, les interactions avec le debuger ou le data/code logger, les codes couleurs qui t'indique les changements en temps réel, si c'est du code ou du data ect...

Ou alors tu veux dire remplacer vraiment l'hexediteur interne de Fceux par un autre qui intercepterait alors les memes fonctions? Fceux est assez flexible mais je ne crois pas que ce soit possible de faire ca.

par Alucardark Mar 1 Sep 2015 - 17:54

upsilandre a écrit:J'ai peut etre pas compris ce que tu demandais. Je suis partie du principe que tu connaissais deja bien l'Hex Editor car il me semblait t'avoir vu le manipuler.
Modifier $20 en RAM ca veut dire modifier l'octet a cette adresse ou j'ai mis mon curseur

Oula, on va dire que je le connais mieux c'est sûr, mais je suis loin de bien le connaitre. J'ai effectivement manipulé l'hex editor grace à la doc fournie par Kuja Killer sur le MegaFLEX modifié, il donnait les adresses en "ROM header". C'est pour cela que je voulais connaitre les valeurs commençants en "$" car sur tous les sites ou toutes les autres docs, les adresses sont donnés en "RAM Offsets" (et j'ai vraiment du mal avec ça). Ça montre bien que je ne suis pas du tout programmeur étant donné que je n'ai même pas un début de base en programmation. What a Face

En tout cas merci beaucoup pour ces explications, ça va m'aider un peu plus (même si je vais me concentrer sur autre-chose ces prochains jours, les mises à jours risquent d'arriver au compte goutte mais je continuerai à convertir les assets).

par upsilandre Mar 1 Sep 2015 - 18:58

Oui quand on te donne une adresse a modifier y a 3 cas:

- soit on te donne une adresse dans le fichier ROM (et qui donc va prendre en compte les 16 octet de header qui décale tout et aussi la répartition des bank) pour faire du rom hacking.

- soit on te donne une adresse dans l'espace d'adressage du CPU. A priori ca sera pour modifier la RAM et donc ca veut dire faire la modification pendant l'execution du jeu au moment qu'on t'indique et bien sure ca aura qu'un effet temporaire sur le jeu car tu ne modifie pas la ROM du jeu juste son execution. Une fois reset le jeu il redevient comme avant.

- soit on te donne une adresse dans l'espace d'adressage du GPU ce qui est encore moins probable. La aussi ca ne va pas modifier la ROM, juste l'execution du jeu de facon temporaire.

Dans Hex Editor de Fceux on te propose ces 3 modes dans "view".
L'adresse $20 (ou une autre) existe dans ces 3 modes mais correspond a des choses completements differentes donc faut effectivement bien comprendre ce qu'on te propose.
Mais en général tu sera toujours dans le premier cas si c'est pour du rom hacking. Le reste c'est plus pour les programmeurs.

par Alucardark Mer 2 Sep 2015 - 16:38

upsilandre a écrit:Oui quand on te donne une adresse a modifier y a 3 cas:

- soit on te donne une adresse dans le fichier ROM (et qui donc va prendre en compte les 16 octet de header qui décale tout et aussi la répartition des bank) pour faire du rom hacking.

- soit on te donne une adresse dans l'espace d'adressage du CPU. A priori ca sera pour modifier la RAM et donc ca veut dire faire la modification pendant l'execution du jeu au moment qu'on t'indique et bien sure ca aura qu'un effet temporaire sur le jeu car tu ne modifie pas la ROM du jeu juste son execution. Une fois reset le jeu il redevient comme avant.

- soit on te donne une adresse dans l'espace d'adressage du GPU ce qui est encore moins probable. La aussi ca ne va pas modifier la ROM, juste l'execution du jeu de facon temporaire.

Dans Hex Editor de Fceux on te propose ces 3 modes dans "view".
L'adresse $20 (ou une autre) existe dans ces 3 modes mais correspond a des choses completements differentes donc faut effectivement bien comprendre ce qu'on te propose.
Mais en général tu sera toujours dans le premier cas si c'est pour du rom hacking. Le reste c'est plus pour les programmeurs.

Dans mon cas c'est effectivement le cas numéro 1 qui m'est accessible étant donné que je ne programme pas. En tout cas je commence à mieux saisir pourquoi sur les sites de rom hacking, ils donnent les adresses en CPU ou GPU, la plupart son programmeurs et de plus ils utilisent un désassembleur. Ça leur permet donc de faire (presque) ce qu'ils veulent un peu comme ici :
https://www.youtube.com/watch?v=M6EH-BIHcSM

ou encore là :
https://www.youtube.com/watch?v=EJXwbXB31S8

par upsilandre Mer 2 Sep 2015 - 22:14

En tout cas moi je m'y suis mis pour de bon cette fois. J'ai deja réussit aujourd'hui a afficher et scroller un background (mono screen) et je suis deja contant car ca a marché quasi du premier coup, pas de galère Razz

.

Le plus long c'etait de bien préparer mon environnement de devs (je l'ai deja dit mais je suis pas programmeur, j'ai aucun automatisme ni habitude de ce coté, la mise en place est toujours laborieuse), surtout bien comprendre le fonctionnement et les subtilités du compilateur ASM (j'ai pas prit le meme que pour la VCS) pour maitriser la production du fichier ROM avec les bons octets au bon endroit, bien placer le Header iNES, la PGR-ROM, la CHR-ROM, les pointeurs IRQ... avoir une bonne procedure de reset de la machine et d'initialisation, bien mettre en place la routine nmi (interruption vblank) et avoir dès le depart un fichier source propre et organisé.
Une fois cette etape un peu chiante passé le reste est deja plus agréable car on commence vraiment les choses concrètes.

par Alucardark Jeu 3 Sep 2015 - 0:36

upsilandre a écrit:En tout cas moi je m'y suis mis pour de bon cette fois. J'ai deja réussit aujourd'hui a afficher et scroller un background (mono screen) et je suis deja contant car ca a marché quasi du premier coup, pas de galère .

Le plus long c'etait de bien préparer mon environnement de devs (je l'ai deja dit mais je suis pas programmeur, j'ai aucun automatisme ni habitude de ce coté, la mise en place est toujours laborieuse), surtout bien comprendre le fonctionnement et les subtilités du compilateur ASM (j'ai pas prit le meme que pour la VCS) pour maitriser la production du fichier ROM avec les bons octets au bon endroit, bien placer le Header iNES, la PGR-ROM, la CHR-ROM, les pointeurs IRQ... avoir une bonne procedure de reset de la machine et d'initialisation, bien mettre en place la routine nmi (interruption vblank) et avoir dès le depart un fichier source propre et organisé.
Une fois cette etape un peu chiante passé le reste est deja plus agréable car on commence vraiment les choses concrètes.

Ah, et ça donne quoi en mouvement? Est-ce que t'as une petite démo? Razz

par upsilandre Jeu 3 Sep 2015 - 0:59

Y a strictement rien a voir, juste un ecran (composé vite fait avec le tileset de mario) qui scroll en boucle Razz

https://drive.google.com/open?id=0B399kteofpYuT0tnd0lzZmFHcjQ
Ce qui compte c'est d'avoir mis le doigt dans l'engrenage mais je suis pas pressé.

par Alucardark Jeu 3 Sep 2015 - 16:29

upsilandre a écrit:Y a strictement rien a voir, juste un ecran (composé vite fait avec le tileset de mario) qui scroll en boucle
https://drive.google.com/open?id=0B399kteofpYuT0tnd0lzZmFHcjQ
Ce qui compte c'est d'avoir mis le doigt dans l'engrenage mais je suis pas pressé.

Ah ben c'est un début très prometteur! Vivement de voir tes évolutions dans le domaine (en tout cas pour quelqu'un qui n'est pas programmeur, tu maitrises plutôt bien).

par upsilandre Jeu 3 Sep 2015 - 22:58

J'ai commencé a toucher les sprites, j'ai donc ajouté l'affichage d'un sprite ou plutot d'un metasprite (8 sprites) en la personne d'Alex kidd bien sure. Je suis loin d'avoir un veritable sprite engine mais au moins ca s'affiche comme il faut.
Puis j'ai commencé a toucher les inputs aussi donc maintenant le scroll n'est plus automatique, faut le faire au pad.
toujours le meme lien
https://drive.google.com/open?id=0B399kteofpYuT0tnd0lzZmFHcjQ

par Alucardark Ven 4 Sep 2015 - 19:46

Tu évolues vite quand même, la prochaine étape c'est le contrôle du sprite? En tout cas j'ai hâte de voir jusqu'où tu vas aller. ^^

par upsilandre Ven 4 Sep 2015 - 21:52

Oui j'aimerais bien avoir au moins une demo de controle du sprite d'alex kidd dans un mini décore d'alex kidd (mono screen comme celui la). Quand j'aurais deja ca j'ouvrirais peut etre un topic.

Aujourd'hui j'ai surtout travaillé a faire un vrai moteur d'affichage de sprite. Du coup maintenant j'ai juste a remplir une liste de metasprite avec leurs coordonnées et le moteur affiche ce qu'il y a dans la liste (et donc tous les sprites qui composent les metasprites) jusqu'a tomber sur une ID nulle.
https://drive.google.com/open?id=0B399kteofpYuT0tnd0lzZmFHcjQ

Pour l'instant j'en ai pas vraiment besoin puisque j'ai qu'un seul metasprite a afficher, celui de Alex kidd, mais c'est quand meme mieux de partir sur une bonne base au niveau de l'affichage. (Reste quand meme a gérer le cas d'un dépassement de la capacité d'affichage de sprite a l'ecran mais c'est pas tres urgent.)
Malgres la contraintes des 5 couleurs de mon sprite d'alex kidd (j'y tenais car en 3 couleurs tu peux pas faire un alex kidd correct) j'ai réussit a bien optimisé mes sprites pour eviter les superpositions et aussi eviter un surcout de pattern (mais ca je l'avais deja fait y a longtemps mais je m'etais arreté la).

par Invité Ven 4 Sep 2015 - 22:44

Bonsoir,

J'ai eu la curiosité de télécharger un émulateur NES et tester ton travail.
Et bien, pour une personne qui n'est pas programmeur, chapeau ... Et en assembleur en plus !
C'est propre, le scrolling est fluide !

Non sérieux, tu sais programmer et quand je lis tes posts, tu m'a l'air de maitriser la technique, beaucoup plus que pas mal d'entre nous.

En tout cas, bonne continuation, c'est avec plaisir que je testerai vos travaux ! Wink

par upsilandre Ven 4 Sep 2015 - 23:17

Merci.
Quand je dis que je suis pas programmeur je veux dire que j'ai pas l'experience d'un vrai programmeur. L'informatique c'est pas du tout mon metier ni mon cursus scolaire. J'ai une experience pratique limité a quelques courtes periodes dans ma vie donc j'ai pas les automatismes d'un vrai programmeur.
Par contre je ne renie pas que j'ai quand meme un certain nombre d'aquis et de connaissance et je me sent capable si je me donne le temps. Le probleme de la programmation en hobby c'est la difficulté a concilier ca avec un emploi quotidien du coup j'ai jamais réussit a m'y investir plus que quelques semaines. Je pense que c'est une activité qui est surtout chouette quand t'es en full temps libre car ca occupe tres bien le temps, c'est peu de le dire.

ps: pitié stop le vouvoiement Mr. Green

par Invité Sam 5 Sep 2015 - 0:02

Dans ce cas, on est deux, je ne me considère pas non plus comme un programmeur, mais plutôt comme un créateur de jeu vidéo.
Sinon, je parlais à vous deux, d'ou les "Vous" ! Wink

Bon courage pour le déplacement du Sprite et la gestion des collisions.

par upsilandre Sam 5 Sep 2015 - 0:24

Vetea a écrit:Sinon, je parlais à vous deux, d'ou les "Vous" !

a oui c'etait claire en plus Very Happy

Faut que j’arrête de polluer le topic de Alucardark mais je me considère pas vraiment sur un projet, peut etre ouvrir un topic plus généraliste sur la programmation NES.

je ne me considère pas non plus comme un programmeur, mais plutôt comme un créateur de jeu vidéo

J'en suis meme pas la. Je ne crée pas de jeu, j'aime juste le coté ludique de la programmation et elle m'aide aussi a comprendre en profondeur le fonctionnement de ces machines (pour ca que je m'intéresse qu'a l'assembleur) et ca j'aime bien.

par Alucardark Sam 5 Sep 2015 - 13:22

Non mais vous ne polluez en rien mon topic (au contraire je dirais, tellement les mises à jours sont sporadiques ^^! ). Sinon pour des "non-programmeurs" vous êtes plutôt balèzes (ça fait quoi, deux jeux que tu développes Vetea ^^).
Pour ma part je rêve de développer un jeu sur Supergrafx (et depuis que j'ai touché au MMC5, à la NES). Malheureusement il me manque un programmeur (un problème récurrent chez moi malheureusement Sad

).