Re: SgdK Megadrive - Démo d'une gestion de YOrder

[Invité]

C'est quoi un opérateur ternaire ??

[Hpman]

C'est le (condition)?resultat_si_vrai:resultat_si_faux

J'ai pris pas mal de raccourci sur les directions, en affectant un bit par direction (les define up/down/left/right).
Du coup les directions ça donne:
    1
 5    9
4       8
 6    A
    2

On peut donc tester facilement chaque direction plutôt qu'avec des valeurs arbitraires.

Après j'ai mappé mes animations pour que le numéro corresponde à la valeur de direction-1, avec quelques fillers donc:


Il n'y a pas d'anims spécifique quand on va à droite, on flip juste le sprite qui va à gauche, donc le code fait quelques manips avec ça.

[Invité]

Merci Hpman pour le renseignement.

Après, tu as ta méthode, si elle t'apporte entière satisfaction, tant mieux !
La mienne aussi.

Par contre, je vais vraiment utiliser mon petit code source de démo, pour travailler et tester tous vos conseils de pointeurs/Tableaux.
Donc je pense, peut être, créer un topic ensuite pour ça si je rencontre des soucis.
Ca pourra servir à d'autres personnes en plus. :)

[Stef]

C'est quoi ton outil Hpman ? Et tu as les as où les spritesheets de papi ? rippés depuis la démo MD ?

[Hpman]

C'est l'outil d'animation qui est fourni avec ma lib NG.

J'ai un système d'animation plus complet, dans le code du jeu tu positionnes juste le point central du sprite qu'on voit dans l'outil, pas le coin de la frame en cours. Du coup tu peux travailler avec des frames de tailles différentes et derrière ça gère tout seul les offsets.

On peut aussi définir une durée d'affichage différente pour chaque frame de l'animation, la faire se répéter ou embrayer sur une autre une fois finie.

C'est Byzance quoi!

Si tu veux faire joujou (et t'inspirer ) y'a un exemple dans l'archive:
https://www.dropbox.com/s/je72o63555mbvj1/DATlib_0.2.rar?dl=0
(tu ouvres sample\DATdemo\gfx\bmary_spr avec le programme animator)



Pour la spritesheet, elle traine dans une archive donnée un peu plus haut ds le sujet.

[Stef]

Ce genre d'outil manque vraiment dans SGDK, c'est que ça prend du temps à coder... En fait j'ai les structures prêtes pour intégrer tout ça, il me manque juste l'outil ^^ Actuellement j'ai juste un compilateur qui te prend un sprite sheet pour générer les structures derrière mais c'est loin d'être aussi flexible :-/ Même si la MD et la NeoGeo sont bien différentes, je me dis que ton outil (après quelques modifs) serait bien pratique pour SGDK, tu l'as codé avec quel langage ? :)

[Hpman]

Il a été torché en C# assez rapidement, je peux te le refiler si tu veux.

[Invité]

Ca serait trop cool ça !!!
Merci Hpman.
Je fais bien de faire une petite pause sur Papi Tennis.

[Tryphon]

Stef : y'a un outil libre du même tonneau pour Mugen, j'avais commencé à écrire un script python pour générer des ressources en C à partir de ses sorties. Je peux le retrouver si ça t'intéresse.

Edit : c'est Fighter Factory : http://mugen.wikia.com/wiki/Fighter_Factory

Je suis pas sûr qu'il soit libre.

[Stef]

A voir c'est quoi le plus simple à convertir :) Avec la MD une feature importante c'est l'optimisation des sprites, après le reste ça reste assez commun aux autres machines. Gestion d'un sprite avec son offset, ses animations, timing en frame, les loops etc... assez classique :) Je jeterai un oeil à ça quand j'aurai du temps. Je ne suis pas familier du C# mais ça devrait être facile à transcrire en java.

[Hpman]

Voila, problème résolu. C'était tout bête: il suffisait de coder un nouveau moteur de sprites/animations pendant le week end et le début de semaine. 

8 objets, 2 en tiles dynamiques et 6 en statiques pour cette démo.
Le tri en bleu dans le job meter, animation objets en vert.



la ROM: https://www.dropbox.com/s/mbdd2lrspnsmzfv/rom_zsort.bin?dl=0

[Invité]

Elle est pas mal la demo 

[Stef]

Ah qu'il est rapide et fort cet Hpman, quand je vois la vitesse à laquelle il a codé tout ça (parce-que par MP il m'a envoyé tout un tas de truc ^^) ... bien joué pour ta démo
2 en dynamique, ça signifie que tu charge les tiles à la volé pour 2 des 8 sprites c'est bien ça ?

[Hpman]

Oui C'est bien ça. 

[Tryphon]

Du coup je suppose que les 6 autres sont bloqués sur la même animation ?

[Hpman]

Non, en mode statique tout le tileset est chargé donc du as accès à tout.

Bon en l’occurrence sur un sprite comme ça tu rentres pas plus de 2-3 animations en vram:

[Invité]

super sympa, mais c'est vrai que ça mange à max de la VRAM ^^

[Stef]

Oui c'est pour ça sur les gros sprites en général tu as tendance à transférer à la volée. Après certaines jeux (comme les SOR) utilisent la VRAM pour cacher les animations des ennemis (qui sont assez simples) alors que les persos principaux sont rafraichis à chaque frame (donc 2 dynamiques et le reste en cache comme Hpman l'a fait). Sur SNES c'est plus coton car tu as que 16 KB de VRAM de réservé aux sprites alors que sur MD tu répartis comme tu veux... du coup les beat'em all sur SNES c'est un peu la misère :-/

[Invité]

super sympa, mais c'est vrai que ça mange à max de la VRAM ^^

T'as pas le choix si tu veux multiplier les persos à l'écran .

[Invité]

Bon et bien j'ai hâte d'installer le nouveau SgdK et mettre à profit les nouvelles routines de Yorder !!

[Invité]

Coucou,

J'ai mis à jour le SgdK à 1.3 et ...
Le résultat est BLUFFANT !!! 

Le code généré est beaucoup plus rapide, c'est dingue !!
Et surtout, cette nouvelle routine d'Y Sort est juste magique ... Purée, encore merci Stef, Hpman, Alekmaul ( sorry ceux que j'ai oublié ...) et modestement moi avec ce sujet qui a fait un peu bouger les choses !!

Voici le résultat en vidéo d'un Ysort avec 44 sprites à l'écran en 32x32 et en mode 320.



Me reste plus qu'à tout modifier sur mon projet Papi Commando Tennis !! 
Encore merci Stef ... 

Direction Don, tu le mérites.

[Stef]

C'est génial de voir ça sur un cas concret si j'ose dire ! Tu n'as vraiment pas perdu de temps pour passer en version 1.3, j'ai fait la mise à jour hier soir très tard (bon en même temps tu devais l'attendre ^^)... Visiblement tu n'as pas eu de soucis pour passer en 1.3, j'avais quelques craintes avec le nouveau GCC 6.3 (genre une dll nécessaire planquée quelque part dans mon système).
Les performances sont bien meilleures en effet, bien sur ça ne remplacera jamais du bon code assembleur mais vraiment pour du C les performances obtenues commencent à être intéressantes :)

Pour le Y sorting, j'ai finalement intégré la version qui la gère au sprite.. du coup si seule une partie seulement des sprites ont bougé alors seuls ces sprites seront triés, par contre si tout les sprites ont bougés alors le tri doit se faire indépendamment sur chacun d'entre eux, ce qui est plus long qu'un tri global de la liste. Dans la prochaine version je ferai les 2 implémentations pour que le développeur puisse avoir le choix de choisir l'une ou l'autre selon le cas de figure (et le type de jeu) et obtenir les meilleures performances :)

Edit: Je viens de voir ton don, merci beaucoup

[Invité]

quelle méthode tri tu utilises ??, toujours le quicksort ??
Dans le cas des sprites ici(liste courte, et entiers 16 bits max), est ce que le bubble serrait pas plus rapide ??

[Stef]

Non j'utilise un insert sort qui est plus rapide dans le cas où ta liste est presque triée (ce qui est un worst case pour un quicksort). En plus, selon ce qu'a utilisé Vetea, soit je tris uniquement les sprites dont la position Y a changé (bon ici c'est le cas de presque tous ^^), soit je tris la liste dans sa globalité... Mais j'ai fait des tests et même dans un cas défavorable ça tient plutot pas mal. Ma première version du tri global était même plus rapide, je vais surement y revenir (même si ça fait un peu plus de code).

[Invité]

même si ça fait un peu plus de code

bah si ça donne vraiment de meilleurs résultats et surtout mieux adapté à la variété de cas, vaut mieux un peu plus de code .

[Tryphon]

Mais dans quelle situation te retrouves-tu avec un tableau qui n'est pas déjà presque trié ? Il est quand même très rare dans un jeu que l'ordre des sprites soit complètement chamboulé entre deux frames.

[Stef]

Ca arrive très rarement je pense en effet, d'où l'utilisation du "insert sort" pour trier... Après là c'est juste que j'utilise le même code pour mon tri "par sprite" (automatique) et mon tri global (manuel) alors le tri global peut être accéléré avec un code adapté :)

[Invité]

Je viens de tester sur PCE, avec un algo bubble amélioré, 1 ligne 1/2 pour 8 sprites, c'est pas trop mal .

[Stef]

C'est même très rapide ! Mais je dirais 8 sprites c'est encore peu, vu que la complexité est quadratique pour cet algo ça peut vite devenir très lent (à partir de 20 sprites par ex). L'avantage du bubble sort c'est qu'il est très rapide dans le cas d'une liste déjà triée donc c'est une bonne solution ici (il ressemble beaucoup à l'insert sort d'ailleurs)

[Invité]

Ouai j'ai testé dans le cadre d'un BTU(un peu comme la demo/tri de hpman plus haut), 8 sprites ça me parait bien, j'ai aussi testé pour 25, mais j'ai pas compté le nombre de lignes .

EDIT: 12 lignes pour 25 sprites 

L'avantage du bubble sort c'est qu'il est très rapide dans le cas d'une liste déjà triée donc c'est une bonne solution ici (il ressemble beaucoup à l'insert sort d'ailleurs) 

Oui, j'ai pu voir qu'il n' y a pas de meilleure façon, c'est très dépendant de ce que tu dois trier,et le nombre en fait .
Pour un nb de sprites < 16 en avec un Y en 8 bits le bubble et dérivés semblent biens, et surtout simples et économiques en code,par contre le CPU augmente bcp dés que le nb d'entrées augmentent.

[Stef]

Oui exactement, plus tu as de sprites et plus le temps va exploser... mais bon c'est le meilleur compromis dans le cas actuel (pas trop de sprites en général et liste partiellement triée)