Re: [SNES] Projet A-RPG

[Earthworm jo]

C'est l'immersion qu'entend Touko, mais franchement moi j'attend ça de chaque jeu, à sa façon ! 
Un RPG sera automatiquement plus fournis sur le scénario et les dialogues qu'un shoot, et un shoot sera plus fournis sur le chara du bestiaire/ les décors/ les armes secondaires etc..

Beau projet en tout cas, c'est pas tout le monde qui touche dans ce domaine là.

[Invité]

C'est ça, mais dans un RPG si un des aspects est raté c'est tout le jeu qui morfle, sur un shoot c'est bcp moins dramatique .

[Earthworm jo]

Pour réussir un bon RPG je pense qu'il est bien d'avoir un certain recul de "l'aventure" qu'un lecteur de livres d'aventures possède par exemple, les scénarios complexes avec de vrais rebondissements ça change beaucoup dans ce type de jeu.

À titre d'exemple je suis entrain de me faire Chrono trigger et il est surprenant, on ne s'ennuie pas.

[Invité]

Bien sur c'est très important d'avoir ce genre de trucs dans un RPG, sinon c'est plat et tu te fais chier ..

[anachronox]

Tout à fait d'accord, quitte à faire lire le scénario par une autre personne un peu passionnée par le genre.

[Invité]

Ah oui d'un point de vue scénario , c'est assez capital.
Je ne pense pas que le scénario doit être forcément 'complexe' pour être bon (enfin je vois ou vous voulait en venir).
Mais je prendrait un exemple Zelda Ocarina of Time , le scénario est bien et on dira 'assez complet' pourtant on peut résumé l'histoire par : Link doit sauvé Hyrule et Zelda x)
Si je compare a deux RPG plus récent FF 13 est complexe niveau scénar pourtant je le trouve bidon.
J'ai joué a Tales of Xillia , lui c'est un scénario loupé le scénario aurait pu être complexe mais disons que cela se voit que le scénariste ne maitrise pas du tout le sujet qu'il veut traité du coup ça devient une conclusion et une moral fait par un enfant...
Pour ma part la profondeur du titre se trouve en faite que dans les détails et sur le background des personnage , plus on aura l'impression que les perso ont une histoire et ne joue pas un role plus le joueur je pense s'attachera au différent protagoniste , j'ai en tête Valkyrie Profile ou Alundra.
ça me semble plus évident sur Alundra quand un perso meurt pour ma part ça me fait de la peine , vu qu'on s'attache au personnage , et c'est pas le titre extrêmement complexe scénaristique-ment (et pourtant il est souvent acclamé).

Je compte pas m'occupé du scénario personnellement , j'essayerai de le suivre et de faire les grandes ligne , mais en général c'est au Game designer pour ma part de s’occupé de cette partie.

En faite dans ce projet il y a moi , j'ai un graphiste partant pour m’aidai , un compositeur , donc il me reste de trouver un GD sérieux et compétent (et ça c'est plus chaud a trouvé).

[Earthworm jo]

Ne confond pas histoire et aboutissement non plus, sinon t'es mal barré ! Skyrim = on tue le méchant dragon, Seigneur des anneaux = Frodon supprime l'anneau ! Ça paraît chiant comme la mort ! ^^

Dans Zelda il y a différents peuples, avec un tas de situations sympa. Je préfère les parties "courtes et dispatchables" d'un A-RPG qu'un gros RPG "rébarbatif" à faire des actions dans le seul but d'évoluer son perso... Un A-RPG est plus nerveux, on castagne soi même c'est vraiment moins soporifique !

Bref je pense qu'il te faut procéder comme pour toute construction : les bases puis construire dessus petit à petit, et ça ira au top.
Un thème principal, un objet sacré par exemple. Arme ou armure légendaire, joyau maudit à remettre entre de bonnes mains, quêtes de destruction d'un énorme monstre (ça en jette un max !!).

C'est l'histoire qui va te faire ta toile, sur laquelle tu va peindre tes décors, ça va inspirer ton bestiaire et ton chara design.

[Invité]

Je ne confond pas , j'essaye juste expliqué et d’être bien clair que le mot 'complexité' peut être sujet a une certaine ambiguïté. 

J'ai essayé de faire une longue argumentation pour bien l'expliqué effectivement que le scénario de base peut être basique mais que ce qui fait l'histoire c'est le background derrière.
Mon post n'était apparemment pas suffisamment clair ^^'

[Earthworm jo]

Je faisais d'autres trucs à côté navré si j'ai lu entre les lignes

[vingazole]

Rien que pour le zorder , j'ai du outre de bien les mettre dans l'ordre et  de manière eu couteuse en CPU faire en sorte aussi que le perso soit couper si il est a gauche de l'écran (mais de manière dynamique vu qu'il y a un zorder) , et la je vient de coder un zorder aussi avec le BG , donc un perso pourra être devant ou derrière un objet (arbre , chaise , rocher ect).

Salut Kannagi !

Désolé pour le déterrage, mais tu as pris quelle méthode pour ton zorder, un quicksort ou bien ?

[Invité]

Salut,

A vrai dire le projet est pas mort mais disons que comme j'utilise 100% du CPU , je peux pas rajouter autre chose.
Je retravaille sur une version plus optimisé et  surtout que maintenant que je connais toute les pièges et les contraintes , je pourrait faire une version propre et optimisé.

Pour ta question , tu vas rire mais c'est un simple tri a bulle , mais un quicksort peu être plus approprié , après pour différente raison je n'afficherait pas plus de 8 perso a l'écran , donc le tri a bulle me semblait pas très gourmand sur mon utilisation.

Mais a vrai dire comme je refait mon code il est probable que je ferai plusieurs test de tri pour voir lequel reste le meilleur par rapport a mon cas :)
(Et il est clair que la version Neo Geo je serait a peine regardant)

Je me permet me poser une question en retour tu on a besoin pour quel type d'utilisation ?
Un jeu sur Master system (son processeur a une meilleur cadence que celui de la SNES en tout ca) ? et c'est je trouve une console très agréable a programmer :)

[vingazole]

Je suis en train de (re-)coder en ASM un clône de Bomberman/Dynablaster sur Master System.

Pour la partie multijoueurs j'utilise aussi un tri à bulles vu que je n'ai que 4 persos à gérer au max (j'utilise b,c,d,e pour les coordonnées Y et b',c',d',e' pour le numéro d'ordre en sortie).

Je me posais la question pour la partie solo, mais il y a de fortes chances que j'utilise encore un tri à bulles.
D'autant qu'avec la limite très basse de sprites par ligne sur Master System (8 sprites de 8 pixels de large) je vais être obligé de gérer du clignotement entre les sprites ennemis, donc peut-être pas la peine de faire un zorder ?

C'est vrai que c'est une console très agréable à programmer (en raison de sa simplicité), la difficulté (et donc l'intérêt, à mon goût) c'est d'essayer d'optimiser le code z80

[Invité]

On faite disons que les boucle c'est gourmand et faire trop de if aussi (ouais j'en suis a ce point la) du coup mon tri a bulle est coder en dur donc assez rapide a l’exécution.

Sur Master System je voulais refaire un wonder boy 3

ça dépend combien il y a des ennemis a gérer au total (et donc continuer a faire un tri a bulle ou pas)mais tu devrais gérer le z-order parce que si il y a bomber-man et un ennemi il est probable qu'il n'y aura pas de clignotement :)

Une astuce que j'ai trouver pour connaître le temps de calcul c'est d'incrémenter une variable pendant que tu attend le VBlank.
Et ensuite tu regarde combien faut cette variable ça peut donner une mesure pour connaître le temps de calcul restant :)

C'est vrai que c'est une console très agréable à programmer (en raison de sa simplicité), la difficulté (et donc l'intérêt, à mon goût) c'est d'essayer d'optimiser le code z80

totalement d'accord , je la conseillerai volontiers a ceux qui veulent se lancer dans la prog des vielles consoles
Pour l'optimisation chez moi c'est une obligation , pas le choix si je veux faire un A-RPG , il y a trop de chose a gérer pour un cpu moisi :/

[vingazole]

Oui, moi aussi pour gagner en vitesse je "déplie mes boucles".

Voilà mon tri (enfin le test) pour 4 coordonnées y:

Code:

y_order:      ld       b,8
              ld       c,7
              ld       d,9
              ld       e,5

              exx
              ld       b,0
              ld       c,1
              ld       d,2
              ld       e,3
              exx
              
              ld       a,e           ; tri : 120 cycles dans le meilleur des cas,
              cp       d             ;       282 cycles dans le pire des cas
              jr       nc,+
              exx
              ld       a,d
              ld       d,e
              ld       e,a
              exx
              ld       a,d
              ld       d,e
              ld       e,a


           +: ld       a,d
              cp       c
              jr       nc,++
              exx
              ld       a,c
              ld       c,d
              ld       d,a
              exx
              ld       a,c
              ld       c,d
              ld       d,a

          ++: ld       a,c
              cp       b
              jr       nc,+++
              exx
              ld       a,b
              ld       b,c
              ld       c,a
              exx
              ld       a,b
              ld       b,c
              ld       c,a

         +++: ld       a,e
              cp       d
              jr       nc,++++
              exx
              ld       a,d
              ld       d,e
              ld       e,a
              exx
              ld       a,d
              ld       d,e
              ld       e,a

        ++++: ld       a,d
              cp       c
              jr       nc,+++++
              exx
              ld       a,c
              ld       c,d
              ld       d,a
              exx
              ld       a,c
              ld       c,d
              ld       d,a

       +++++: ld       a,e
              cp       d
              jr       nc,++++++
              exx
              ld       a,d
              ld       d,e
              ld       e,a
              exx
              ld       a,d
              ld       d,e
              ld       e,a

     ++++++:                       ; (fin du tri)

          -:  exx
              jr       -



Pour connaître le temps de calcul j'utilise soit le trick de la border color (pour avoir une idée approximative en nombre de lignes de scan), soit le comptage de cycles sur émulateur : on a (au moins) deux émulateurs permettant de compter les cycles sur Master System (Meka et Emulicious) :)

[Invité]

Je vois que tu utilise wla-dx , j'apprécie énormément la possibilité de faire des label temporaire , on y gagne en productivité tout de même :)

Je vois que tu utilise 4 registre faudra faire preuve de gymnastique pour gérer plus
J'ai survoler ton code mais qql fois c'est pas simple de modifier un code qui est fait pour gérer un certain nombre de cas .
J'utilise meka qui un excellent debugger et mednafen pour test rapidement.

[vingazole]

Nan, mais là j'optimise au maximum pour le mode 4 joueurs à cause du nombre limité de tiles dispo en VRAM sur la console (je suis obligé de charger à la volée 6 tiles pour deux des quatres persos (384 octets) : ça charge déjà pas mal la bête (d'autant que j'ai la tilemap à mettre à jour simultanément le plus rapidement possible)...

Pour le mode solo ce sera moins tendu et j'utiliserai un tri de N entités

PS: oui, wla-dx est mon ami

[Invité]

4 joueurs avec les bombes ect , c'est vrai que en transfert ça pompe D:
Ah oui si tu as le tilemap a gérer dynamiquement mea culpa , ça doit être assez tendu niveau code
C'est horrible de gérer dynamiquement ce genre de chose sur ces consoles :/
Du coup certain jeux sont plus simple a faire que d'autre par rapport a ce que tu vas devoir envoyer en VRAM ou pas (tout en étant assez rapide pour que l'affichage se fasse).

du coup je suis curieux de voir ce que tu as pondu

[vingazole]

J'hésite encore, mais si mon "collègue" est d'accord je vais peut-être ouvrir un sujet sur ce forum pour montrer l'avancement de notre jeu

[ichigobankai]

Tu peux y aller mon Vingazole

Peut être que j'ouvrirais un topic pour mon Cimmerian dans la foulée...

[vingazole]

Cool !

Il faudra que tu penses à mettre tes signatures à jour...

[ichigobankai]

Pas faux ^^
Entre le changement de nom et le temps qui défile à vitesse grand V...pas simple d'être up-to-date 

[Invité]

@vingazole
Alors pour ma part mon zorder n'est pas aussi optimiser que le tien et pourtant j'arrive a faire tourner ma démo , donc je pense que t'a pas de souci a t'en faire la ^^
(Après le mien est prévu pour 12 perso max a l'écran).

Pour ma démo je sais pas si cela intéresse encore du monde mais voila les news :

Donc j'ai recoder a zéro ma nouvelle démo (je ne pensais pas arrivé a tel extrémité) mais bon la SNES reste une console éprouvante a programmer surtout quand on veut faire un jeu gourmand en CPU comme un A-RPG ^^ , mais maintenant je connais très bien la SNES , les pièges a évité mais aussi les bonnes astuces pour bien exploiter le matériel.
Le code est totalement optimisé , seul le code des collisions que j'ai repris de mon ancienne démo (même si il y a eu pas mal optimisation faite) , d'ailleurs peut être que vous verrez pas trop la différence même si le code interne est complètement changé et en plus assez modulaire pour que je puisse rajouter des trucs.

Voila j'ai codé le menu (j'ai mis toute de même une semaine pour le faire) :



Par info les couleurs ne sont pas une modification precalculer , elle sont modifié en temps réel et je peut vous dire que modifier 16 couleurs x 8 palette , c'est super gourmand :aie:
Donc je modifie qu'une palette par frame et quand toute sont faite , je l'envoie en VRAM , de même que j'ai préférer qu'il ne soit pas possible d'envoyer la palette du BG et des Sprites en même temps , c'est soit l'un soit l'autre , en espérant que j'ai fait le bon choix niveau archi
Pour le ring menu c'est un casse tête en gros j'ai testé plusieurs façon de faire des multiplications , mais comme ce n'est pas des float , la précision est très mauvaise , a virgule fixe j'y est pensé mais comme j'utilise au moins 3 octet pour l'entier , me reste que 1 octet pour les virgules de plus le code serait pas jolie jolie :aie:
Pour le moment j'ai prévalu a un precalcul , même si je trouve l'apparition des icon est legerement saccadé , je pense (enfin j'espere) que si je precalcul avec des positions plus petite , que cette fois ci le résultat visuel sera au rendez vous .
Normalement ça marche sur une machine réel mon dernier test (y'avait pas le menu) était concluent et j'ai rien fait de spécial depuis.

Pour la suite finir deux trois petit truc et commencer la prog pour les combats.
Je compte pas faire IA des pnj pour le moment je voudrait encore faire quelque test (et donc s'il bouge pas cela m'arrange).
Mais normalement au total pour un village/ville je pourrait afficher 12 sprite en même temps (3 hero + 9 pnj) , en sachant que il y a les collisions/zorder ect derrière , pour le moment j'ai 2 hero + 5 pnj et ça marche plutôt bien.
Ah et on peut enfin pousser les pnj ^^
Sinon pour finir , pour des raisons optimisation CPU et que la VRAM de la SNES est contraignant  sur les 8ko disponible , j'utilise 6-7ko :aie:
bon je reste confiant normalement j'ai pas besoin de plus , sur les ko pris je compte évidement les persos/pnj/ennemi ,je leur réserve 4ko tout de même mais bon un perso a besoin de 64 octets pour ces données et donc ça me fait 64 perso max pour une map (64x64 = 4096 octets).

Pour ceux qui veulent tester rapidement j'ai uploader sur NesBox
http://pixelretro.hebergratuit.net/NesBox/snes.html

Pour ceux qui veulent test la rom directement :
http://www.mediafire.com/download/wxkh7ue4fv4xsdp/main.smc.zip

[Top l'âne]

J'avais pas encore eu l'occasion de tester ces émulateurs en ligne.
J'ai fait mon petit paquet de PNJ, je l'ai promené ici et là, RAS. ^^

[Invité]

Cet émulateur malgré son nom marche pour la Mega drive
Sinon oui j'avais passé mon temps a les mettre par paquet pour voir si tout vas bien ^^
Mais dans la version fini , ça sera plus difficile quand ils bougeront

[vingazole]

Pour le ring menu c'est un casse tête en gros j'ai testé plusieurs façon de faire des multiplications , mais comme ce n'est pas des float , la précision est très mauvaise , a virgule fixe j'y est pensé mais comme j'utilise au moins 3 octet pour l'entier , me reste que 1 octet pour les virgules de plus le code serait pas jolie jolie :aie:
Pour le moment j'ai prévalu a un precalcul , même si je trouve l'apparition des icon est legerement saccadé , je pense (enfin j'espere) que si je precalcul avec des positions plus petite , que cette fois ci le résultat visuel sera au rendez vous .
Normalement ça marche sur une machine réel mon dernier test (y'avait pas le menu) était concluent et j'ai rien fait de spécial depuis.

Je trouve que ça donne pas mal, quand même, l'apparition de ton ring menu (par contre il me semblerait plus logique d'inverser le sens de rotation du menu quand on appuie sur droite ou gauche)

Par contre je ne comprends pas ton histoire de multiplications (j'imagine que tu fais L x sin(angle) - avec une LUT pour les sin/cos - en faisant diminuer L et en modifiant l'angle pour placer tes items) : tu utilises des nombres avec 3 octets de partie entière !? C'est énorme, non ?

[Invité]

Merci , bah j'imagine que j'ai parce que je l'ai regardé en ralenti pour vérifier, du coup c'est moins jolie.

par contre il me semblerait plus logique d'inverser le sens de rotation du menu quand on appuie sur droite ou gauche

Tu as sûrement raison ,j'ai pas regarder sur Secret of mana , si c'est bien inverser ou pas ^^

Pour les multiplications , je ne les faits pas mais j'essaye d'expliquer pourquoi ça m'a pris une semaine pour faire un ring menu , Bon avec des entiers ça rend saccadé , je voulais utilisé les virgules flottantes.

On me relisant je me suis mal exprimé , sur 2 octet ben j'ai besoin de 12 bits en partie entière , du coup 4bits en virgule c'est assez maigre enfin j'imagine que je peux optimiser en 9 bits entière et 7 bit en virgule.
Enfin je verrais si je repart sur cette configuration ou pas.
Actuellement c'est que tu precalculer donc oui un cos/sin mais precalculer pour chaque Rayon (je dois avoir besoin de 16 rayon en tout).

[vingazole]

Ok, ça me paraissait beaucoup 3 octets pour la partie entière :)

Sinon bravo pour tout ce que tu as déjà implémenté, c'est nickel !

[Invité]

Salut Kannagi,


J'ai pu tester ta démo, c'est trés impressionnant !
Le Z-Order est vraiment parfait, et techniquement ça envoie du paté surtout quand on sait que c'est du 100% Assembleur.
Chapeau bas "Maitre" !  
J'aime beaucoup le 2eme personnage qui suit le main, avec un petit pathfinding pas dégueulasse et aussi le fait de pousser les pnj, techniquement top.
Par contre, je déteste les animations non stop quand les personnages sont immobiles, berk ...  
Mais c'est facile à régler j'imagine !


Vraiment bon boulot Kannagi ! :)

[Invité]

Merci a vous deux , sachant que ben j'ai passé beaucoup de temps pour ce résultat.
Le deuxième personnage sera plus intelligent (et avec un meilleur pathfinding) on fait le but c'est qu'il ne quitte pas l'écran (pour que je puisse test).

Ouais ben pareil j'aime pas trop l'animation des persos quand ils sont fixe et c'est facile a régler , mais je ne le ferait pas tout de suite , la aussi le but c'est pour les performances s'ils sont en animation non-stop ils veulent envoyer en VRAM.
Pour cela aussi que il n'ont pas de IA les pnj , au moins je sais qu'il ne bougeront pas ^^

Bref l'erreur que j'avais faire sur ma première démo c'est justement ne pas regarder assez les performances de mon jeu du coup je me suis retrouvé avec un code qui ne pouvait plus évolué :/
Donc la je ne ferait pas la même erreur , et je peux voir a peu prés les perfs max utilisé

Cela explique aussi que si vous parler a un PNJ la fenêtre s'ouvre au milieu  (pour que je garde un oeil au CPU).

[dub]

J'ai testé ton "ring". Je le trouve impeccable. Pour moi, y pas besoin de rajouter des étapes. Il faut que ça reste rapide.

Moi aussi, j'utilise des tableaux pré calculés, + simple à gérer et moins coûteux en temps de calcul surtout.

[Invité]

Re Bonjour tout le monde ,
Eh ben faire un moteur 3D me semble plus simple sérieusement xD

J'ai donc rajouter quelque perso a l'écran , il y a 11 perso a l'écran en même temps en 32x32 avec tout ce que cela implique (l'envoie en VRAM pour les animations , tout les calculs , Zorder , text box , collision map et perso ect).
Et il me reste encore du temps de calcul , j'ai bien optimisé

J'ai enfin rajouter la partie battle , la hitbox déconne un peu c'est normal je fignolerait cela.
Plus de petit détails que j'ai fait , qui est un changement du code de la map , pour qu'elle soit plus facile pour les transitions , j'ai bien changer l'ordre du menu .
Et j'ai du modifier aussi mon éditeur perso pour la map , en gros maintenant je gère totalement les tileset des BG1 et 2 (donc pour rappel 4 tileset de 128x64 et 2 tileset de 128x128).
Avec encore + qql modif par ci par la (la liste risque d’être longue ).
Par contre un truc très chiant c'est l'arme , pour la position bien comme il le faut sur chaque frame , ce n’était pas une partie de plaisir :/
Le projet sera legerement en pause , je compte faire un game document pour y voir plus clair et voir les besoins du jeu dans son ensemble.
De mon point de vue les principaux contraintes technique en était surpassé , le reste est du fignolage , certes cla peut prendre un peu de temps mais vraiment rien d'insurmontable , cela se reposera sur mon moteur qui est maintenant assez costaud.

J'ai fait une vidéo ici :


Je rappel au cas ou mon lien vers NesBox , émulateur en ligne :
http://pixelretro.hebergratuit.net/NesBox/snes.html

Et bien sur la rom :
http://www.mediafire.com/download/wxkh7ue4fv4xsdp/main.smc.zip

Je compte au final faire une démo beaucoup plus abouti (donc jouable), voir si ça intéresse du monde ensuite je verrais si je continue ou pas , (si ça intéresse que 2-3 personne pour 1 an de boulot en full asm sur SNES ).