Structure de donnés pour un système d'animation

Bonsoir !

Voilà, je bosse sur le logiciel d'animation du RayEngine, et j'me trouve assez embêté, j'vous explique :

Je dois stocker 5 variables pour chaque frames (Depth, image_xscale,X,Y et image_index) en soit pas de problème.

Mais c'est quant à la lecture que j'me retrouve un peu bloqué, jvoudrais savoir comment organisé tout ça pour que ce soit le plus propre possible dans la mémoire.. Qu'est-ce que vous me conseilleriez ? Faut-il aussi que je stocke le n° de frame ? (image_index correspond au sprite utilisé pour les morceaux)

Est-ce que c'est plus rapide de stocker chaque animation dans une grille différente ou une autre structure s'impose ? (sachant que je tappe dans les 36 animations pour Rayman à lui tout seul)

Merci de votre aide et bonne soirée !

perso je ne me serais pas cassé la tete, j'aurais fait un tableau double (array[x,y]) avec pour x l'id de la frame et y l'id de la variable correspondante.

du style :

frames[ID,0] = depth;
frames[ID,1] = xscale;
frames[ID,2] = X;
frames[ID,3] = Y;
frames[ID,4] = image_index;

je pense que c'est le plus structuré et surtout le plus optimisé comme système

master47 a écrit:

perso je ne me serais pas cassé la tete, j'aurais fait un tableau double (array[x,y]) avec pour x l'id de la frame et y l'id de la variable correspondante.

du style :

frames[ID,0] = depth;
frames[ID,1] = xscale;
frames[ID,2] = X;
frames[ID,3] = Y;
frames[ID,4] = image_index;

je pense que c'est le plus structuré et surtout le plus optimisé comme système

Yep, mais j'ai oublié de préciser que chacune de ces variables dépendaient des morceaux (bones)

fais un objet par morceau, ça devrait passer

attends j'ai une idée!

frames[ID,0] = depth du morceau 0;
frames[ID,1] = xscale du morceau 0;
...

frames[ID,5] = depth du morceau 1;
frames[ID,6] = xscale du morceau 1;
...

frames[ID,10] = depth du morceau 2;
frames[ID,11] = xscale du morceau 2;
...
........

et pour retrouver le bon, tu décales du nombre de morceaux * 5

c'est pas fabuleux?

Chulien a écrit:

fais un objet par morceau, ça devrait passer

attends j'ai une idée!

frames[ID,0] = depth du morceau 0;
frames[ID,1] = xscale du morceau 0;
...

frames[ID,5] = depth du morceau 1;
frames[ID,6] = xscale du morceau 1;
...

frames[ID,10] = depth du morceau 2;
frames[ID,11] = xscale du morceau 2;
...
........

et pour retrouver le bon, tu décales du nombre de morceaux * 5

c'est pas fabuleux?

Vi, c'est ce dont je t'avais parlé, mais c'est pas pratique à utiliser..

ah ben j'avais pas compris alors à ce moment là

je pense que si tu fais de bonnes fonctions ça peut être très bien.
surtout que une fois que ça sera mis en place, t'auras plus à y toucher normalement.

Chulien a écrit:

ah ben j'avais pas compris alors à ce moment là

je pense que si tu fais de bonnes fonctions ça peut être très bien.
surtout que une fois que ça sera mis en place, t'auras plus à y toucher normalement.

Yep, mais justement c'est là que je galère

aussi question importante !

Admettons que j'ai un perso qui possède ~20 bones, et qu'il possède une dizaine d'animations d'environ 100 frames chacunes.

Donc faut foutre dans la mémoire par exemple 10 array (un par anim) de chacun de 6 en width et 2 000 en height


Est-ce que ça va littéralement me tuer la mémoire, où ça peut tenir la route ?

au pire si t'as peut d'avoir des problèmes avec la gestion foireuse de la mémoire rien ne t'empêche de tout mettre dans une dll

onilink_ a écrit:

au pire si t'as peut d'avoir des problèmes avec la gestion foireuse de la mémoire rien ne t'empêche de tout mettre dans une dll

Toute la gestion des animations ? Faudrait que j'apprenne la prog en C++

juste la gestion de la mémoire. En gros la tu auras le contrôle total sur chaque variable que tu créeras tout en utilisant le moins de mémoire possible. En plus avec les allocations dynamiques tu peut aussi libérer la mémoire inutilisée, etc. Pas besoin d'apprendre complètement le c++ pour ça, je pourrais te faire des exemples aussi si jamais tu a vraiment du mal.

onilink_ a écrit:

juste la gestion de la mémoire. En gros la tu auras le contrôle totale sur chaque variable que tu créeras tout en utilisant le moins de mémoire possible. En plus avec les allocation dynamiques tu peut aussi libérer la mémoire inutilisée, etc. Pas besoin d'apprendre complètement le c++ pour ça, je pourrais te faire des exemples aussi si jamais tu a vraiment du mal.

Gestion de la mémoire j'utilise Cleanmem, mais à la limite c'est intéressant. Faudrait que j'y jette un coups d'oeil

De toute façon, je peux quand même faire tout mon code, et si ça se révèle mange-mémoire, j'pourrais faire cette DLL, non ?

oui, mais tu perdrais certainement moins de temps a coder directement ta dll je pense. Enfin a toi de voir

onilink_ a écrit:

oui, mais tu perdrais certainement moins de temps a coder directement ta dll je pense. Enfin a toi de voir

Hm.. le truc c'est que je vois pas comment faire cette DLL pour qu'elle soit maniable (le principe quoi)

tu déclare les variables (ici des tableaux) dans ta dll et tu fait des fonction pour récupérer/modifier/libérer.

onilink_ a écrit:

tu déclare les variables (ici des tableaux) dans ta dll et tu fait des fonction pour récupérer/modifier/libérer.

Donc accès/modification des tableaux via une DLL.. mais en quoi est-ce que ça pourra alléger le code dans la mémoire ?

chaque variable de GM prend 8 octets de mémoires, donc pour des tableaux ça peut faire très lourd.
Par contre en C++ tu peut choisir tes types de variables, et donc optimiser la mémoire.

Hélas, la plupart de ces variables sont des flotants...
Mais en effet, utiliser un float à la place d'un double, ça devrait déjà aider...

Après, c'est du genre :

typedef struct
{
short depth;
float xscale;
float yscale;
float x;
float y;
long image_index;
}struct_data;

pi une DMA avec ce genre de déclaration :
struct_data DATA[nb_ID][nb_bones];


Pour la lecture un truc du genre :
return DATA[ID][Bone].depth;

L'écriture, idem etc ...

Ouais je vois, du coups, vu que c'est que des variables integer ça prendra largement moins dans la mémoire

Bon, jvais tâter tout ça, merci à tous !

Bon, j'viens de capter un truc.
Dans le fichier binaire, ça ressemble à ça :

image_xscale (1b), depth(1b),part_index(1b),x(2b),y(2b)

au total 7bytes. Etant donné que GM signe ses variables sur 8Bytes, y'aurait pas un moyen pour que je foute toute ces variables en une seule signée sur 8bytes, et qu'ensuite je puisse la décomposer pour récupérer les donnés séparés ?

Voir Les opérateurs binaires

Par contre tu risque de rencontrer des problèmes étant donné que la mémoire de GM n'est pas toujours fiable .... et arrivé a certains gros chiffres les valeurs sont arrondies, ou un truc du genre

onilink_ a écrit:

Voir Les opérateurs binaires

Par contre tu risque de rencontrer des problèmes étant donné que la mémoire de GM n'est pas toujours fiable .... et arrivé a certains gros chiffres les valeurs sont arrondies, ou un truc du genre

Yes, j'connais les opérateur binaires et j'arrive à m'en servir ! (merci à toi d'ailleur )

Arf, je vois.. effectivement il me change FFFFFFFFFFFFFF en FFFFFFFFFFFFFE...

Y'a moyens de corriger ça ?

Bah la seule solution a mon avis est d'utiliser moins de bytes.... après tout la c'est carrément un bug de GM.

onilink_ a écrit:

Bah la seule solution a mon avis est d'utiliser moins de bytes.... après tout la c'est carrément un bug de GM.

Ouais, mais c'est pas trop trop possible...

Bon, du coups, la meilleur solution reste la DLL, non ?

oui je pense

onilink_ a écrit:

oui je pense

Hm, et ça se ferait comment ?
J'peux faire une DLL qui fasse genre (dans GM) var = int(x), où int permet de signer x sur 2bytes dans la mémoire ?

bah si tu fait var = int(x) bah y auras la création de var et donc tu prendras 8 byte pour rien.

Tu as 2 possibilités :
-Soit tu fait un système ou tes variables on toutes été déclarés dans ta dll et tu fait 2 fonctions, une pour lire et l'autre pour écrire
-Soit tu fait un système d'allocation dynamique (plus compliqué) ou les variables seront crées avec une fonction, par GM pus stockées dans ta dll

onilink_ a écrit:

bah si tu fait var = int(x) bah y auras la création de var et donc tu prendras 8 byte pour rien.

Tu as 2 possibilités :
-Soit tu fait un système ou tes variables on toutes été déclarés dans ta dll et tu fait 2 fonctions, une pour lire et l'autre pour écrire
-Soit tu fait un système d'allocation dynamique (plus compliqué) ou les variables seront crées avec une fonction, par GM pus stockées dans ta dll

1ère option alors !

vu que je compte m'en servir que pour ces énormes grilles

pour moi qui suis dans à peu pres la même situation, est-ce que je devrais hésiter à passer mes fichiers anim en binaire? estce que c'est pas mieux de les garder en txt à cause de ces bugs? sachant que je n'irai pas toucher les dll...

Pour les sauvegardes en fichiers binaires il ne devrait pas y avoir de problèmes a mon avis. Après sa dépend surtout de la précision.

ça reste que des entiers, pas de virgule, mais ça m'embête de perdre de la précision rien que sur ça :/