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

[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)

[Invité]

mais bon c'est le meilleur compromis dans le cas actuel (pas trop de sprites en général et liste partiellement triée)

Exact, j'en ai testé quelques uns plus complexes(et normalement plus efficaces), et les résultats sont moins bons dans les cas simples comme celui d'un jeu 16 bits ,où faut l'avouer reste assez simples dans 99% des cas(peu d'entrées à trier, et Y sur 8 bits) .
Donc effectivement, très bon compromis comme algo(je m'attendais à pire niveau perfs) .

EDIT:
J'ai testé en aléatoire(non déjà trié donc) et je suis à 2 lignes 1/4 pour 8 sprites,c'est pas trop mal finalement,pour un code de 27 octets . 

[Stef]

Tu tries sur quoi comme structure ? un tableau de pointeur ? une liste chainée ?

[Invité]

Un simple tableau indexé contenant les positions Y des sprites,y'a pas la réorganisations des sprites dans la SAT,j'envisageais de le faire faire par le DMA (avec une liste) un jour .
Pas très utile pour des sprites individuels par contre,et il me faudra aussi un second tableau référençant le numéro du sprite(ou du premier sprite en cas de metasprites).

Mais bon c'est une ébauche, j'ai pas réellement un moteur de Y order en cours, je commence juste un peu à explorer certaines possibilités .

[Stef]

Ok tu tris juste un tableau de valeur, dis toi que ça sera un peu plus long dans le cas réel (au moins un facteur 2 ou 3) car tu devras échanger au moins des pointeurs et lire les Y en indirect

[Invité]

Ok tu tris juste un tableau de valeur, dis toi que ça sera un peu plus long dans le cas réel (au moins un facteur 2 ou 3) car tu devras échanger au moins des pointeurs et lire les Y en indirect

Oui, d'ailleurs je pense que je serrai obligé d'avoir une liste chaînée pour les sprite, et la copier en VRAM au CPU,car je suis pas sur que le faire au DMA me facilite la tâche,mais bon j'en suis pas là encore  .
Là je testais juste l'algo de tri pour voir ce que ça donne,et je vais surement rester comme ça pour le tri,trier les sprites en parcourant la liste serra bcp plus lent ..

L'idée est d'avoir les adresses de début de chaque sprite/meta-sprite dans un tableau que je modifierai après le tri .

[Stef]

Ok tu tris juste un tableau de valeur, dis toi que ça sera un peu plus long dans le cas réel (au moins un facteur 2 ou 3) car tu devras échanger au moins des pointeurs et lire les Y en indirect

Oui, d'ailleurs je pense que je serrai obligé d'avoir une liste chaînée pour les sprite, et la copier en VRAM au CPU,car je suis pas sur que le faire au DMA me facilite la tâche,mais bon j'en suis pas là encore  .
Là je testais juste l'algo de tri pour voir ce que ça donne,et je vais surement rester comme ça pour le tri,trier les sprites en parcourant la liste serra bcp plus lent ..

L'idée est d'avoir les adresses de début de chaque sprite/meta-sprite dans un tableau que je modifierai après le tri .

Tu es sur que c'est plus rapide de faire ainsi ? Tu vas être obligé de modifier ces adresses en même temps que le tri, ça revient à modifier un tableau de pointeurs au final je pense :) Au mieux tu peux juste utiliser un index, ainsi en même temps que le Y, tu modifies l'index du sprite (position dans la table), ça tient sur 8 bits... c'est la solution al plus rapide pour toi je pense.

[Invité]

Rooooo ...
Elle marche très bien ta routine !!
Vous pinaillez pour rien là, regarder ma démo avec 44 sprites !! Vous connaissez des jeux MD avec 44 sprites dont le Yorder est a gérer ??
Allez hop, place aux projets !

[ichigobankai]

Attention, gérer X sprites carrés est ultra simple dans une SAT, des metasprites avec des compositions / tailles à la con n'a rien à voir

[Invité]

Tu es sur que c'est plus rapide de faire ainsi ?

Non j'en suis pas sur du tout, mais disons qu'à première vue, c'est ce qui me semble le plus rapide .  
Car si ça se trouve ce que je vais gagner pour le tri, je vais le perdre ensuite,ou alors ce serra tellement bordélique à gérer que je chercherai autre chose ..
Evidemment la liste chaînée est techniquement l'approche la plus simple .

Au mieux tu peux juste utiliser un index, ainsi en même temps que le Y, tu modifies l'index du sprite (position dans la table), ça tient sur 8 bits... c'est la solution al plus rapide pour toi je pense.

Oui c'était ça la finalité, d'avoir avec 1 index accès à plusieurs infos .
Même une adresse 16bits est découpée dans 2 tableaux (1 LOW et 1 HIGH), donc on y accède avec le même index .

Rooooo ...
Elle marche très bien ta routine !!
Vous pinaillez pour rien là, regarder ma démo avec 44 sprites !! Vous connaissez des jeux MD avec 44 sprites dont le Yorder est a gérer ??
Allez hop, place aux projets ! 

LOL, à part un tri elle fait pas grand chose ma routine 

[Invité]

Coucou,

Je viens de réaliser ma démo ultime en terme de Sprites à l'écran/rapidité.
J'ai totalement refondu mon code, mieux architecturé, plus "C Friendly" car avant, j'étais en mode "Manouche EXL 100".

Résultat des courses, je me retrouve avec un résultat vraiment énorme avec :
- 60 sprites.
- Gestion du Yorder avec l'update 1.30 du SgdK.
- Pathfinding simplifié de l'IA.
- Gestion "Anti collision" des 60 unités à l'écran.
- Mode 256x224.
- Emulateur Exodus mode USA.



Aucun ralentissement, pas de clignotement, rien, nada .. Perfect !! 
Pas une seule ligne d'assembleur.
Je pense que le nouveau GCC doit y être aussi pour beaucoup ( en plus de mes optimisations ! )

Pour la démo, j'ai utilisé la toute dernière skin de @Grostonton réalisé juste hier.
Quoi de plus normal par la mettre à l'honneur, 60 Papi Commando qui déambule à l'écran !

@Stef, je peux te dire que ton algorithme défonce grave sa race, c'est vraiment énorme ta Mise à jour.
Encore merci !!!

Je vais donc pouvoir refondre en douceur, le code source de Papi Tennis, il y a de la correction à faire ...
Quoique j'attends des informations importantes de mon côté pour un autre gros projet qui me caresse aimablement mes bijoux de famille ... Wait & see !!

A bientôt !!

[Invité]

Tu t'amuses bien on dirait 

[grostonton]

Ca rend vraiment super bien , et j'essaie de rester objectif ^^

[Invité]

[Stef]

@Vetea> En fait j'ai fait quelques tests et la différence sur le tri global n'est pas si énorme, le nouveau GCC améliore quand même bien les choses et du coup je pense que je vais rester comme ça pour le moment :)
Et bravo pour ta démo ! C'est la preuve que ça tourne déjà bien comme ça =)

[Invité]

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

je déterre un peu le topic, mais finalement je suis curieux de savoir comment tu fais le tri, directement dans la SAT ou dans un tableau externe ??
Ton tri varie entre 2 et 9 lignes, cette variation est due au fait que tu testes pas les sprites hors écran,ou c'est justement la modification des liens des sprites qui fait ça ??

Attention, gérer X sprites carrés est ultra simple dans une SAT, des metasprites avec des compositions / tailles à la con n'a rien à voir 

Je suis justement arrivé à la même conclusion, en général pour un BTU tu utilises un meta sprite composé de plus de sprites pour les 2 joueurs (et les boss) que pour les ennemis et le objets/armes,donc galère à trier dans une structure,à moins que tous les metas sprites aient le même nombre de sprites hard .

Donc sur PCE je vois ça comme ça:
Organiser la SAT en RAM en code automodifié et exécutable mais organisée en liste chaînée, avec à la fin de chaque meta sprite/sprite un saut vers le sprite suivant .
Enregistrer la position y de chaque sprite/metasprite dans un tableau, avec un second pour le numéro de sprite, donc le tri va déplacer les valeurs Y ansi que le num de sprite qui correspond, ça va pas consommer bcp plus .
Une fois que tout est trié, les numéro des sprites vont chercher les adresses de chaque sprites/measprite qui sont en statique pour renseigner la SAT,donc évidement les objet supprimés ne seront pas traités .

Un sprite dans la SAT de la PCE se représenté en VRAM comme suit:
posY     1 word 
posX     1 word 
pattern 1 word 
attribs   1 word 

l'idée est d'organiser la SAT en RAM comme une liste chaînée exécutable (st1 et st2 sont des opcodes du 6280 pour copier directement des valeurs en immédiat dans les ports du VDC en 5 cycles):
Sprite_1:
st1  LOW_X
st2  HIGH_X
st1  LOW_Y
st2  HIGH_Y
st1  LOW_PATTERN
st2  HIGH_PATTERN
st1  LOW_ATTRIBS
st2  HIGH_ATTRIBS
jmp Sprite_4

Sprite_2:
st1  LOW_X
st2  HIGH_X
st1  LOW_Y
st2  HIGH_Y
st1  LOW_PATTERN
st2  HIGH_PATTERN
st1  LOW_ATTRIBS
st2  HIGH_ATTRIBS
jmp Sprite_1

Sprite_3
st1  LOW_X
st2  HIGH_X
st1  LOW_Y
st2  HIGH_Y
st1  LOW_PATTERN
st2  HIGH_PATTERN
st1  LOW_ATTRIBS
st2  HIGH_ATTRIBS
jmp xxxx

Sprite_4
st1  LOW_X
st2  HIGH_X
st1  LOW_Y
st2  HIGH_Y
st1  LOW_PATTERN
st2  HIGH_PATTERN
st1  LOW_ATTRIBS
st2  HIGH_ATTRIBS
rts

lors de la maj de la SAT en VRAM, il suffit de faire un jsr premier_sprite(par exemple ici ce serra sprite_2) qui correspond au sprite trié à la priorité la plus haute,et la MAJ se ferra d'elle même, car le dernier sprite/metasprite ne ferra pas un jmp, mais un rts,et ça finira la maj de la SAT en VRAM . .
De ce fait seuls les objets encore vivants se mettront à jour en VRAM.

Bien sur je ne fait pas d'allocation dynamique des sprites, trop lourd pour moi et finalement pas utile .