Hier j’ai programme une petite application pour le GI que j’inclurai dans mon prochain SDK et qui permet de voir l’etat de la memoire en temps reel. Ca permet notamment de voir si la memoire fragmente ou si y’a un usage intensif de la memoire qu’on ne suspectait pas.

J’ai d’ailleurs fait une petite video de Battle For Independence (mon projet actuel donc) afin de montrer comment ca marche.

http://gi.kamron.net/Videos/GIMemMonitor.zip

L’application qui permet de voir l’etat de la memoire est une application independente (qui marche grave au GIMemory) sur la droite du jeu.

Code de couleur:
Noir, c’est memoire intouchee
Rouge, c’est memoire allouee
Blue, c’est memoire desallouee

Si vous etes attentif (pas facile vue la qualitee de la compression), vous verrez que pendant le jeu y’a encore pas mal d’allocation/desallocation en continue. Va falloir que je repare ca.

PS: non aucun portage prevu

Tant que j’y suis, je suppose qu’il n’y a pas de portage Linux/BSD de prevu ?

Ne confonds pas design et implementation. Un singleton c’est un objet qui n’a qu’une seule instance. La ce que tu discutes c’est la facon d’implementer ca. Donc tu peux pas dire “les singletons c’est mal car ca appelle …” sans faire cette grosse confusion.

Ensuite pour ta classe template de laquelle on derrive ouais c’est en effet ce qu’on fait, mais rien n’empeche cette classe de reserver cette memoire avec ton allocateur plutot que celle systeme.

Pour le GI j’ai vire le forum, trop de spam et pas le temps de gerer ca, donc envoie un email si t’as un soucis particulier, mais je le dis tout de suite faut pas etre presse pour les reponses Plus la reponse demande du temps plus je risque de trainer les pieds pour repondre.

Merci aux abrutis de spammer de comprendre qu’on s’en branle de vos links a la con et que tout est modere ici donc y’a aucune chance que j’en laisse passer… Tout de meme 150 qui ont essayes deja… mais bon la je digresse

En fait je crois qu’on c’est pas compris sur ma méthode.
Pour les singletons je ne comprend pas vraiment leur utilité non plus (plus par manque d’expérience mais rien que le fait qu’on empile le pointer this a chaque appelle de méthode me trou le c** autant utiliser une classe statique si l’objet est unique), mais ça permet de déclarer une instance unique. C’est ainsi que je me suis dit plutôt que de déclarer une seule instance de ma classe autant en déclarer un pool de mémoire.
Le résultat est le template présenté plus haut.

Donc si j’ai une classe A en la déclarant ainsi :
Class A : public Cachable inf A, 1024 sup (inf et sup sont les signes off course)
Et donc A hérite automatiquement des opérateur new et delete du template et il possède son propre pool de mémoire.

Pour les exceptions, j’en génère (en mode debug :D) dans 2 cas quand le pool déclaré n’est pas suffisant (plus de 1024 instances de A pour l’exemple). Et quand la taille demandé n’est pas égale à la taille du type du pool (cf. on a une classe B qui hérite de A sans surcharger son propre Cachable). Et si j’ai un gros pb il me suffit de virer l’héritage du template Cachable et hop c’est les new et delete normaux qui prend en charge la mémoire)

Mais je crois que je vais utiliser ta méthode pour les objets dont il est difficile d’être certain du nombre cf les nœud de A*, comme ça je suis certain que le bloc mémoire qui me reste est efficacement géré).

Pour GI c’est ou qu’on en parle?

nicolas

Merci pour le compliment et ta remarque est tres juste a propos de pool de memoire que l’on utilise souvent lorsqu’on a beaucoup d’objets de meme taille (pas forcement en fonction de leur taille memoire).

En revanche je ne suis pas sur que tu aies lu l’article jusqu’au bout en ce qui concerne la surchage de global new et delete et notamment:

“Mais, pourquoi ne pas tout simplement overloader l’operateur global new et delete pour tout me direz vous”

Les macros permettent d’eviter d’avoir a ecrire deux lignes a chaque fois et de pouvoir changer la syntaxe sans avoir a changer le code si besoin etait.

Par contre je ne suis pas sur d’avoir compris l’interet des macros ?
pourquoi ne pas simplement surcharger new et delete, je me vois mal integrer un gestionnaire memoire dans un projet existant et devoir repasser sur tous les news du codebase et les remplacer par le define correspondant !

Oui faut pas melanger new/free et malloc/delete. Ce que je vouais dire c’est ca (exemple concret):
Tu crees operator new(int size, void* mem, int dummy).
Et bien dans ce cas, tu as interet a creer un operator delete(void* ptr, void* mem, int dummy). Pourquoi ? Si jamais une exception est lancee dans le constructeur (donc juste apres TON operator new), si le delete correspondant n’existe pas, la memoire ne sera pas liberee. Si ce delete “associe” existe, la memoire sera correctement liberee. C’est de ca que je voulais parler. Sinon si tout se passe bien, c’est toujours le delete “normal” qui est appele

Par rapport au template, j’ai egalement utilise la macro sur un int Et ca compile ! Donc si la ligne de template s’evanouit Essaye tu verras …

Non non tu peux continuer a rester a ce niveau ca ne me derange pas ^^

“Par exemple, quand tu fais un operateur placement new, tu as interet a faire le delete “equivalent””

Oui mais ca c’est normal, c’est ce que je disais dans le post, tu melanges pas new et free ou malloc et delete non plus.

Juste pour info le destructeur est automatically ajoutte lorsque tu as une class (ou meme une struct) et que tu compiles en C++.
Je doute que la ligne de la template d’evanouisse

Mais si ca pose probleme t’es pas oblige d’utiliser la macro non plus! Des fois j’alloue un bloque de memoire comme avec malloc, faut que j’utilise mon allocateur.

Promis, mon prochain topic en prog sera plus simple

Mon client ne voulait pas de macros differentes pour delete les types C primitifs (ou les classes sans destructeur mais ca c’est pas conseille) et les classes. Du coup j’avais fait un delete global, mais j’avais un probleme sur Symbian qui avait deja redefini le delete global, qui se trouve dans une lib et non une dll… Juste a cause de Symbian, j’allais etre a deux doigts de faire deriver toutes les classes (les miennes plus celles du client) d’une classe vide qui redefinissait juste l’operateur delete, avec toutes les merdes eventuelles (integrations d’autres libs, creation d’une classe derivant de deux classes differentes…).

Et la je me suis dit, je perds rien a essayer le coup du template… Et BINGO !!! Le compilo, quand il genere le code template, elimine tout seul comme un grand la ligne qui contient _pPointer->~T() si il s’agit d’un type primitif ou d’une classe sans destructeur Du coup plus besoin de creer de classe de base, ni d’avoir deux macros de delete differentes… Le bonheur… Teste sur compilos Microsoft et gcc…. Trop fort, je pars en week end heureux…
En revanche implementer l’appel des destructeurs dans le delete d’un tableau de classes, ca fait une macro absolument horrible !!!

Voili, voilou

En fait je trouve qu’en C++ c’est vraiment pas pratique de faire son gestionnaire memoire. Il y a tout plein de petits details qui font qu’il faut faire vachement gaffe. C’est vraiment pas pense simple.

Par exemple, quand tu fais un operateur placement new, tu as interet a faire le delete “equivalent”, sinon si il y a exception dans le constructeur appele par un placement new, la memoire allouee avant ne sera pas liberee.
Autre chose, j’utilisais aussi l’appel du destructeur explicite “myClass->~MyClass()” mais evidemment un client a voulu pouvoir utiliser le new sans differencier les classes et les types C primitifs. Autant dire que “a->~int()” ca compile pas vraiment ! J’ai donc du changer de systeme et ca s’est avere etre une vraie galere.
Sans compter que si tu veux gerer les tableaux de classe, ca devient vraiment subtil suivant si ta classe a un destructeur ou pas par exemple…

Au final on y arrive, mais quelle prise de tete, surtout quand on travaille avec des environnements “exotiques” genre Symbian qui redefinit deja plein de trucs.

Petite precision: chaque dll peut avoir son new/delete global. Ce n’etait pas tres clair dans les commentaires.

Au final c’est super, mais si on veut faire les choses bien, c’est pas si evident que ca en a l’air a premiere vue.

Pour le 1) tu alloues normallement toutes la memoire dispo sur console lorsque tu crees ton allocateur.
Apres c’est simple de savoir quand y’a plus de memoire, ton allocateur te le dit et t’as pas eu besoin de t’embeter avec des exceptions.

Ca sert a que dalle les exceptions handling pour des jeux sur console, a part rendre le code plus difficile a debugger et perdre de la place memoire (meme si c’est qu’en debug)

2) Comme disait Mark (ouais le meme pour lequel j’ai enormement de respect) les singletons sont la sources du mal hehe, mais bon je reviendrai une autre fois la dessus.

Bah dis donc, content que tu trouve le GI tres propre. Generallement les gens ont un peu de mal a comprendre comment on utilise des interfaces en C++.
Quake c’etait du C quoi qu’on en dise donc c’est clair que c’est pas vraiment ce qu’il faut prendre comme exemple si on veut progresser en programmation oriente objet

Merci pour les compliments sur le GI, ca fait plaisir. le GIMemory est l’une des dernieres libs que j’ai faite donc les plus vieilles sont bien moins propres malheureusement et pas vraiemnt le temps de tour reconcevoir.

Et comme disait encore Mark lorsqu’on faisait du code review ensemble (decidemment une grande source d’inspiration pour moi en prog ce Mark), la seule chose qui compte c’est les headers file et la defintion des interfaces car si c’est bon le reste (comprendre l’implementation) peut etre changee si besoin est sans impacte.

1)Le signalement pour le manque de mémoire n’est activé que pour la version debug et les beta test. Juste pour être certain qu’il y a bien assez de mémoire.

2)La méthode vient de la déclaration de singleton que j’avais trouvé dans un bouquin. Mais c’est vrai que si de nombreuses classes héritent de ce template, j’aurais beaucoup de définition des méthodes.

Je crois que je vais effectivement mixer les méthodes. Utiliser la surcharge pour les objets dont je suis certain à 100% du nombre (ex. je ne veut pas qu’il y ait plus de 1024 Clients en même temps) et ta méthode pour tout le reste.

Et vraiment l’implémentation dans GI est vraiment très propre et agréable à lire (Infiniment plus que certain jeu commerciaux cf quake). GI à l’air assez simple à prendre en main, faut que je regarde l’ensemble de plus prêt.

Nickaru

je decouvre un peu ce blog au hasard, un petit de plus pour mon agregateur RSS ^_^

je vais un peu plus fouiller, mais ca fait plaisir de trouver un blog de programmeur dans le jeu, bonne continuation !

Alors dans l’ordre

1. Si t’as plus de memoire ca sert a rien de prevenir l’utilisateur.
“Desole vous n’avez plus assez de memoire rebooter votre console” comme dirait un dev principale sur XBox, interceptez pas les exceptions ca sert a rien.
On utilise pas les exception handling pour les jeux (de maniere generalle), c’est une perte de memoire de l’activer.
Pour les outils en revanche c’est plus qu’important pour pas perdre ses donnees.

2. Tu parles en fait d’overload de new et delete de class. C’est en effect possible et recommander pour les objets de la meme taille que tu vas allouer/desallouer souvent. C’est assez courant sur console mais la generalisation que tu fais me semble etre plus lourde qu’interessante.

Maintenant l’allocateur dont je parle dans l’article devrait etre appele dans ton implementation de new et delete de classe.

J’ai lu avec attention cette article que je trouve vraiment intéressant. Mais en même temps ça chamboule un peu ma méthode préférée qui est comme suit :

template
class Cachable
{
public :

void * operator new (size_t t) throw (int)
{
//…ici on retourne un objet libre du stack
//…ou on envoie un exception si on n’a pas la place
//…qu’on réoccuper la ou on a appeler new pour faire un jolie
//.. output de débugage
}

void operator delete(void * c)
{
//.. on indique que l’objet utilisé est libre maintenant
}

protected :

static void * stack; // le tas d’objet utilisable
};

template
void * Cachable::stack = malloc(sizeof(T)*STACKS_SIZE); //on alloue la mémoire pour le tas d’objet de taille STACKS_SIZE

Ainsi on a plus qu’a dériver une classe a partir de celle-ci comme suit

class Client : public Cachable

L’appelle devient vite encombrant a cause de try catch (mais c’est seulement dans la version debug donc ça va) . En plus pour déterminer la meilleur taille de cache il faut créer une classe équivalente a Cachable mais qui sert juste à logger l’utilisation de la mémoire en fonction de l’état du jeu.

Comme je ne suis pas le plus grand spécialiste de la gestion de la mémoire je me demande la quelle est la plus utilisé dans l’industrie.

Nickaru

Je suis d’accord, ODE est trop naze (d’ailleurs dans la 0.5 y’a pas d’allocs pendant l’update alors que la 0.7 y’en a une à chaque update, raison pour laquelle je suis resté en 0.5). Mais c’est le seul que je connaisse qui marchotte ET qui soit fournit avec les sources. Et justement grâce à ça, contrairement à ce que tu dis, ça fonctionne pas que sur PC. Mon projet perso tourne aussi sur Xbox (ouais ok c’est x86 aussi mais bon) et en utilisant Bullet à la place de Ice on doit pouvoir compiler aussi sur Xbox 360 (je pense que c’est des vieux asm {} de Ice dont tu parles pour le code x86 ?). Tokamak/Newton/Ageia: les consoles faut oublier puisque ni les sources ni les libs consoles ne sont fournies. Il y a aussi Bullet et TrueAxis, mais je ne sais pas encore ce qu’ils valent. Donc si tu connais un truc super (un ode en mieux quoi), je suis preneur, parce que ODE c’est le seul choix possible dans mon cas, faute de mieux.

darjul : “Ne me dit pas que tu croies sincèrement que la concurrence fait des allocations dynamiques pendant les séquences de gameplay? Même sur 4d1bou PS2 il n’y en a pas. Je le sais, j’en ai dégagé quelques unes qui trainaient en fin de projet :=)”, “Content de voir qu’4d1bou etait a la pointe des techniques ”
j’ai déjà bossé avec des mecs issus d’4d1bou et je peux te dire qu’ils laissent plein d’allocations dynamiques à tout les niveaux du jeu (même pendant la phase gameplay). La leçon de la PS2 ne leur a pas servi (pour une majorité sauf darjul ). Je me suis même fais taper sur les doigts en voulant développer “sans allocation pendant la phase gameplay”. Mais bon c’est le nombre d’années d’XP (à rien glander) qui compte.

darjul :”Effectivement après vérif, 0DE passe par une structure, donc pas étonnant que j’ai pas eu de problème de link. Faut que je fasse gaffe moi”
0DE c’est trop naze. ça fonctionne que sur PC (y a du code assemleur x86 à l’interieur)… c bon j’arrete le troll

ps: désolé du poste

Y’as plusieurs techniques, t’as certains programmes qui se demerdent pour allouer dans le meme ordre et toujours desallouer dans le sens inverse (je crois que ca s’appelle frame allocation ou du genre).

Sinon tu peux avoir plusieurs allocateur pour plusieurs parties du jeu.
Sur black n white on avait dumpe la stack apres loading. Ensuite une fois une partie finie on remplacait directement la memoire avec le dump sans se faire chier avec ce qui etait encore alloue. huhu. Ca permettait de pas avoir de probleme en multiplayer surtout. Mais bon c’etait un peu extreme comme technique et je recommande pas.

Puis comme t’alloue/desalloue pas pendant une partie y’a pas de soucis normallement.

C’est pas une solution parfaite mais elle a l’avantage de pouvoir s’intégrer rapidement dans le code que tu as écris.

Pour les debutants en prog qui voudraient copier la fonction, oubliez pas le sinon le compilateur va pas comprendre T

template
inline void CallDestructor(T* _pPointer)
{
_pPointer->~T();
}